No, the camera doesn't have its own screen buffer. I have to grab it as I see it. That's why I'm only able to keep up with one line at a time.
I like the idea of using HC245's to share lines. My problem now is that I've used up all my available pins and need more.
I'm thinking a second Propeller that does nothing but read the camera, store the data in SRAM and transfer it to a display would be best. It could have a simple interface to the main Propeller.
I also like the idea of doing the camera read and store completely with hardware. This doesn't seem like it should be too hard.
The board I'm using right now is designed only for testing the camera and sending display data to my touchscreen. I've attached a picture of the schematic.
The camera lines I'm using are 2.8V and 1.5V supplies and ground. Besides these are the 8 pixel data lines going to P0-P7, the two clock lines, xclk and pclk, the h/v control signals, a reset line and the two comm lines.
I have access pins for all of the camera and Prop pins, as well as a breadboard area.
Take a look and let me know if you have any suggestions.
You asked if the link you sent was the camera I'm using. Basically yes, but there is an autofocus added to the model I have. There are only 24 pins available on the connector supplied.
Also, the pixel data come out on pins Data[2:9]. [0,1] are not used. You can set the output to various modes, YUV, raw, RGB565, RGB555, etc. I've chosen to go with RGB565 since it matches the touchscreen I'm using for display.
There is no 'serial' data output. Just a serial interface for the command I/O.
The documentation for this chip is REALLY HARD to find. I have a lot of it, including their SCCB serial interface spec sheet. This is where I discovered that it's almost, but not quite, i2c. I2c won't work!
I'm happy to supply the documentation I have if you're interested in it.
The CPLD would be fine, except that I've never used one. One of these days...
It seems like it shouldn't be hard to do with discrete logic chips, an address counter, and use the PCLK to clock the data in after the vsync whenever the hsync goes high. The vsync could be AND'd with a Prop pin to 'enable' a start frame. The Prop could then look at the vsync pin to see when it's started (waitpne) and when it's done (waitpeq), since it's negative true.
Good food for thought.
Anyone want to lay it out? If it looks good, I'll get a board made.
I haven't followed this thread too closely, but regarding the address counting, you can use the 23K256's in a mode that auto increments with each clock pulse. They even wrap around when they hit 256kbits (I think)... You might need 8 of them to do the parallel capture, but 320Hx240V is only 76800 bits, so you probably grab 3 frames before reading with the prop.
Comments
No, the camera doesn't have its own screen buffer. I have to grab it as I see it. That's why I'm only able to keep up with one line at a time.
I like the idea of using HC245's to share lines. My problem now is that I've used up all my available pins and need more.
I'm thinking a second Propeller that does nothing but read the camera, store the data in SRAM and transfer it to a display would be best. It could have a simple interface to the main Propeller.
I also like the idea of doing the camera read and store completely with hardware. This doesn't seem like it should be too hard.
The board I'm using right now is designed only for testing the camera and sending display data to my touchscreen. I've attached a picture of the schematic.
The camera lines I'm using are 2.8V and 1.5V supplies and ground. Besides these are the 8 pixel data lines going to P0-P7, the two clock lines, xclk and pclk, the h/v control signals, a reset line and the two comm lines.
I have access pins for all of the camera and Prop pins, as well as a breadboard area.
Take a look and let me know if you have any suggestions.
Thank you for your help and support.
Jim
You asked if the link you sent was the camera I'm using. Basically yes, but there is an autofocus added to the model I have. There are only 24 pins available on the connector supplied.
Also, the pixel data come out on pins Data[2:9]. [0,1] are not used. You can set the output to various modes, YUV, raw, RGB565, RGB555, etc. I've chosen to go with RGB565 since it matches the touchscreen I'm using for display.
There is no 'serial' data output. Just a serial interface for the command I/O.
The documentation for this chip is REALLY HARD to find. I have a lot of it, including their SCCB serial interface spec sheet. This is where I discovered that it's almost, but not quite, i2c. I2c won't work!
I'm happy to supply the documentation I have if you're interested in it.
Jim
Start with a 64 macrocell part, (3v3 models like LC4064V, or ATF1504ASVL), and you might manage to fit into a 32MC one later.
This could do clock mux, gated counters/rst and mono-flop capture
The CPLD would be fine, except that I've never used one. One of these days...
It seems like it shouldn't be hard to do with discrete logic chips, an address counter, and use the PCLK to clock the data in after the vsync whenever the hsync goes high. The vsync could be AND'd with a Prop pin to 'enable' a start frame. The Prop could then look at the vsync pin to see when it's started (waitpne) and when it's done (waitpeq), since it's negative true.
Good food for thought.
Anyone want to lay it out? If it looks good, I'll get a board made.
Keep thinking.
Jim
Interesting concept. Keep in mind that 320x240 pixels from this camera take 153600 BYTES of storage, at 2 bytes per pixel.
Maybe I could parallel 8 of these chips and still get good results.
Thanks,
Jim