Well, yeah, if the bandwidth is what you say, it sounds vaguely possible 
to do this and use the SD card bus to communicate IF you code in assembly.

24F series is limited to 16MIPs.  That's really really hard to read 
1.3MB/sec off the parallel port and move it out another parallel port. 
The 24F series doesn't have any hardware support for the parallel port 
which causes a speed problem.  That is really problematic when you have 
to capture based on an external clock.  If your part sources the 
parallel clock, great, you can time it without a loop or interrupt to 
check the clock pin status.  Otherwise... you've only got *10* 
instructions per byte.  It's just not enough.

Try the 24H or 33F series.  40MIPs.  THAT will work, if your solution is 
in assembly and efficient.

On the spec sheet though, I thought I saw 12MHz for the parallel clock, 
which would be impossible to read with a 24F.  With a 40MIPs part, I 
don't think this could be read.  And even if this is a burst of frame 
data followed by off-time, I don't think there's enough RAM to buffer a 
frame.

You're going to use I2C to configure the camera, then... well, no 
hardware parallel, so probably use an interrupt or bus read to check the 
clock, horizontal/vert sync pins, read the bus, separate into high and 
low bytes for the SD card 4-bit transfer, and write the data to the port 
while strobing the clock. 

You'll need code that understands the FAT system on the card to open up 
a file for writing prior to streaming in all this data.

Danny

alopes wrote:
> sorry, it will no be 2MB/s, but 1.3MB/s.
>   

-- 
http://www.piclist.com PIC/SX FAQ & list archive
View/change your membership options at
http://mailman.mit.edu/mailman/listinfo/piclist