On Thu, 2004-09-16 at 14:15, Philip Pemberton wrote:
> That's effectively what I'm doing now - grabbing 1024 bytes, blasting them to
> the host, then grabbing another 1024 bytes (8 rows). I haven't tried doing
> the imaging cycle like that, though. I'll have to try that :)
> 
> The other option, of course, is to hook up a 16k RAM (62128?) and a pair of
> 4040 counters - use one 8-bit port to read/write the data lines, then use
> another five I/O lines to run /CS, /RD, /WR, COUNTER_CLK and COUNTER_RST.
> Blast the data into the RAM (framebuffer), then come back and read it out
> later.

This sounds like something that a CPLD would be perfect for. Let the
CPLD generate the addresses and write pulses for the SRAM. Have a look
at my logic analyzer project:

http://repatch.dyndns.org:8383/pic_stuff/logan

It uses a CPLD to "run" the SRAM. I'm pretty sure you could use most of
what I've got to do what you want.

Only limitation is you'd have to record the data linearly (not a problem
since that's how it comes out of the camera) and you'll only be able to
read it easily linearly (not a problem since that's probably how you
want to do it anyways). TTYL
 
-----------------------------
Herbert's PIC Stuff:
http://repatch.dyndns.org:8383/pic_stuff/

_______________________________________________
http://www.piclist.com
View/change your membership options at
http://mailman.mit.edu/mailman/listinfo/piclist