That looks good -- the "mating height" of those connectors is 1.5 mm -- "H1_5"
The pitch is 0.4 mm -- "P0_4".
They are "4.4 mm connectors", which is the "4_4", most likely, that is the distance of pin centers on one side (0.4 * 11, for 12 pins).
Not sure what the "6_9" is about...
I have seen various connectors being referred to as CSI, some are FPC for ribbons, others like this are a type of framed connector. They are using it as an 8bit communication with Pclock, hsync, vsync, mclock(?) and I2C control. It would be painstaking but In the past on these devices that are in use on the Arduino, it is possible to translate their C demo code to SPIN. In this case it will require PASM, which will be a lot of work but hopefully worth the effort since it sets gets the learning curve underway for Omnivision products.
Edit. The schematic they are showing is the Pc Duino board components, including 1.8V reg and 3.0 reg, not the ribbon cable components.
Here are three spin files... the one with the longest name is where I left off. It has a variety of calls that do nothing because I decided to just leave the camera in the default state and convert from yuyv to rgb in software. It has a serial user interface for calling various functions... but again, some of these are disabled or do nothing. If you look in the main spin loop,
you will see register settings to put the camera into RGB mode commented out... I think these work and don't remember exactly why I wasn't using them...no doubt because I was having a problem setting ALL the registers right and decided to just go with the defaults.
The other two don't write to an sd card, but have complete user interfaces and examples of all the calls and some register settings for other camera modes that I culled from the web.
If my memory serves me right, my modules all have an oscillator or the OV5642 has an onboard oscillator... anyway the take home rule is: don't assume that because you are feeding it a clock it really is taking the clock. I have methods in there to look at the camera's pixel clock.
Thanks rjo, look forward to studying this later this eve. Maybe the 5640 is similar enough to 5642. I have a ways to go before having the dedicated P1 camera board.
I don't see any pins for parallel 0..7, is that being handled in the PASM code? I just did a quick glance. Or is this some special MIPI protocol not using 8 bit parallel reads?
Yes... to get the signal out of ina in one instruction I have the data pins 0-7.
At 24MHz, there aren't a lot of clocks to play with:)
Normally, I only write one of the yuyv bytes and then skip a byte... to get gray scale. The code works for gray scale, but I'm not sure it is going to work for color... gut feeling is it will. You might want to play with the timing of the second byte. At the time, I thought it was ok,
today I'm not so sure. Could be this is why I got confused on color issues.
Nevermind, just discovered that the pins 23 and 24 are marked on the ribbon! Very easy to understand now.
Any thoughts on how they would have numbered these header/sockets? The header info says it is not marked for orientation. Some headers use a numbering scheme of staggering, versus going straight down a row.
1 2
3 4
5 6
7 8
9 10
The schematic provided with the camera is for the PCDuino PC Mounted header, and the ribbon cable attached to the camera has the mating 24 pin socket. I believe they are not polarized and could be inserted either way. I suppose the worst case is to order a PCDuino and it should be easy to determine where ground is as there are a number of locations on the header. I would only be guessing based on this info.
I got started on the P1 Camera Streamer Module today. The idea is to learn about cameras with the OV5640 module that sparkfun sells, linked earlier. I found the header for the ribbon connector so that is solved. There are 12 pins free on the P1. The goal is to stream higher quality images as fast as possible, even if it is 1 frame per second. The end result is an 800x480 display that I want to fill as much as possible with the camera. There is going to be a receiver module, maybe better described as a multiplexer or distributor. This receiver module will have many cameras connected via CAT5, from distances up to hundreds of feet. I found a QUAD high speed RS485 sender and receiver combo that may reach 20Mb at 200 feet. It is assumed that the camera output will be either JPEG or raw RGB 565. This needs much more study to see what is best. With jpg, it may be fast and easy to transmit a single data stream via RS485 and this may be fine. Or, 565 RGB may be needed and that would mean two bytes per pixel. I had a crazy idea earlier that if I could xmit on two sets of RS485 at a time, receive on two sets at the other end and store in ram, that would transfer twice as fast. However, this was delusional as what device will buffer the camera output for a single image, then allow two reads at once? A dual port RAM maybe? Anyways I parked the Hyperram on it thinking there may be a trick to output two bytes as a time from the Hyperam as it may allow reads on each clock edge. With some trick, I could send a rising edge data to one of the RS485 xmits, then on falling edge send on the other. Thoughts?
Worst case is to buffer an image in the Hyperram, then just transmit the entire buffer on a single channel and deal with the time. It takes. The receiver puts it in ram, then distributes it to the master controller screen for display. The master tells the receiver which camera to pull from, or it may scan any number for the purpose of showing live streaming thumbnail views, then click on a thumbnail to expand to full screen.
Problems with this idea, it looks like the Hyperram needs 12 pins. There are only 12 pins free, so that means none for RS485 unless I use p30/31. Unless, D0..D7 from cam and Hyperram could be tied together? If the camera has an output of 8bits on it's D0..D7 pins, why can't they be tied direct to Hyperram io and P1 io. That would really depend on if the cam D0..D7 could be set to High z for the hyperram to be accessed for getting the buffer to send to RS485. Sounds like a potential train wreck. 8io Mux/demux?
Comments
The pitch is 0.4 mm -- "P0_4".
They are "4.4 mm connectors", which is the "4_4", most likely, that is the distance of pin centers on one side (0.4 * 11, for 12 pins).
Not sure what the "6_9" is about...
Edit. The schematic they are showing is the Pc Duino board components, including 1.8V reg and 3.0 reg, not the ribbon cable components.
you will see register settings to put the camera into RGB mode commented out... I think these work and don't remember exactly why I wasn't using them...no doubt because I was having a problem setting ALL the registers right and decided to just go with the defaults.
The other two don't write to an sd card, but have complete user interfaces and examples of all the calls and some register settings for other camera modes that I culled from the web.
If my memory serves me right, my modules all have an oscillator or the OV5642 has an onboard oscillator... anyway the take home rule is: don't assume that because you are feeding it a clock it really is taking the clock. I have methods in there to look at the camera's pixel clock.
At 24MHz, there aren't a lot of clocks to play with:)
Normally, I only write one of the yuyv bytes and then skip a byte... to get gray scale. The code works for gray scale, but I'm not sure it is going to work for color... gut feeling is it will. You might want to play with the timing of the second byte. At the time, I thought it was ok,
today I'm not so sure. Could be this is why I got confused on color issues.
Nevermind, just discovered that the pins 23 and 24 are marked on the ribbon! Very easy to understand now.
Any thoughts on how they would have numbered these header/sockets? The header info says it is not marked for orientation. Some headers use a numbering scheme of staggering, versus going straight down a row.
The schematic provided with the camera is for the PCDuino PC Mounted header, and the ribbon cable attached to the camera has the mating 24 pin socket. I believe they are not polarized and could be inserted either way. I suppose the worst case is to order a PCDuino and it should be easy to determine where ground is as there are a number of locations on the header. I would only be guessing based on this info.
I think this is it... but that is without caffeine in my system
Worst case is to buffer an image in the Hyperram, then just transmit the entire buffer on a single channel and deal with the time. It takes. The receiver puts it in ram, then distributes it to the master controller screen for display. The master tells the receiver which camera to pull from, or it may scan any number for the purpose of showing live streaming thumbnail views, then click on a thumbnail to expand to full screen.
Problems with this idea, it looks like the Hyperram needs 12 pins. There are only 12 pins free, so that means none for RS485 unless I use p30/31. Unless, D0..D7 from cam and Hyperram could be tied together? If the camera has an output of 8bits on it's D0..D7 pins, why can't they be tied direct to Hyperram io and P1 io. That would really depend on if the cam D0..D7 could be set to High z for the hyperram to be accessed for getting the buffer to send to RS485. Sounds like a potential train wreck. 8io Mux/demux?