|
![](/i/fill.gif) |
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] npgcable com> 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
|
![](/i/fill.gif) |