On 11/14/2010 3:27 PM, Patrick Elliott wrote:
> On 11/13/2010 12:25 AM, Nekar Xenos wrote:
>> On Sat, 13 Nov 2010 06:34:47 +0200, Patrick Elliott
>> <sel### [at] npgcablecom> wrote:
>>
>>> Seems the biggest issue with this is finding the right controller,
>>> with enough memory/ability to expand it, and *then* figuring out how
>>> to attach the bloody parts to it. lol Going to need to do some
>>> thinking on this...
>>>
>> i-phone?
>> B)
>>
>> -nekar Xenos-
> Uh, don't think so.. lol For one, it only processes one image source,
> and two, it probably costs about 50 times what off the shelf parts
> would. ;) lol
>
Had to head to work, so.. now going to be more specific. As I understand 
the issue, the CCD is tied to a "driver". This basically works like the 
reverse of what the LCD would do, where you poll the device for the 
data. I am not sure how complex the polling is, but with the LCD at 
least you have basically a memory that tracks the "state" of the pixels, 
and a bus, which you pump data into, based on a set of coordinates for 
the data in the memory. At least, I assume this is more or less the way 
pixel ones work, since the one I read up on was a text display (so, 
obviously a bit different). Either that, or you ping the driver and it 
dumps the whole block of image data to your controller's input bus. This 
means you are either driving directly from a bus, or you *might* if it 
is something like a web cam, driving a USB from the bus, which then 
talks to the camera's driver. Either way, before you can alter the 
image, or even just move it over to the output display, you need to 
store the total pixels "in memory", for the microcontroller, before 
passing this to your LCD driver, what ever it then does with it. For a 
"cheapish" camera, that is 1MB+- per frame, you are pulling in two 
frames, one for each camera, changing the result, with fonts or the 
like, to add hatch marks, range, etc., like a real one would show on its 
display, then feeding that out to the LCD. Figure.. At least 2MB, not 
including "software" to run the program that pulls the image, blits data 
to it, then passes it on to the next stage. Oh, and some additional code 
(maybe), to handle when to do the "software" zoom, control the motors to 
move the physical system, and what ever else you may need to do. 
Figure.. for good measure you might want at least 4MB, minimum. Most of 
them support up to 512*k*, and its not clear how/if they even allow you 
to tack on more memory.

And, as I said, existing designs do not support more than one camera 
input, like your existing cameras, cells phones, etc. Though.. I suppose 
if you wanted to spend idiot amounts of cash, you could buy one of the 
new 3D cameras... :p

Almost be easier to take a newer, faster, lower power, 65C816 chip, and 
"build" something with enough memory. At least I would understand the 
damn machine code in one of the things. lol

-- 
void main () {

     if version = "Vista" {
       call slow_by_half();
       call DRM_everything();
     }
     call functional_code();
   }
   else
     call crash_windows();
}

<A HREF='http://www.daz3d.com/index.php?refid=16130551'>Get 3D Models, 
3D Content, and 3D Software at DAZ3D!</A>

Post a reply to this message