Just a quick question.
Does someone have experience with connecting an Omnivision OV5640 CSI camera to an Apalis iMX6 developmentboard? It’s running Windows embedded compact 2013.
I already have troubles with getting the serial communication (~I2C) to work. It might by the connected hardware, camera & interface, that can be faulty or just the startup sequence is wrong.
Thanks in advance.
Kind regards,
Remco
Currently the camera capture interface is not supported on our Windows CE BSP, this feature is on our roadmap, but not yet available.
For I2C can you please describe in more detail the issue? Are you getting errors, wrong data, no reply?
Just to make things clear for me.
Is it possible to make an own program that can access the CSI data from the camera? Or would it be a rather tricky process for someone with above average knowledge of embedded programming but less knowledge about Windows CE?
With respect to I2C. I think it’s just me that is making an error. But I try the following:
hI2C = I2c_Init(L"I2C1");
success = I2c_SetConfigInt(hI2C, L"ioScl", IOAPALISPIN(211), StoreVolatile);
success = I2c_SetConfigInt(hI2C, L"ioSda", IOAPALISPIN(209), StoreVolatile);
success = I2c_SetConfigInt(hI2C, L"BitRateHz", 100000, StoreVolatile);
success = I2c_SetConfigInt(hI2C, L"SlaveAddr", 0x003C, StoreVolatile);
success = I2c_SetConfigInt(hI2C, L"SlaveAddrSize", 7, StoreVolatile);
success = I2c_SetConfigInt(hI2C, L"RegisterAddr", 0x300A, StoreVolatile);
success = I2c_SetConfigInt(hI2C, L"RegisterAddrSize", 16, StoreVolatile);
I2c_Open(hI2C);
wdata[0] = 0x30;
wdata[1] = 0x0A;
I2c_Write(hI2C,wdata,1);
But when measuring I get the following: 0x78.
There is no extra bytes transmitted, but i would have expected 2 (I2C device address and the send value).
0x78 is 0x3C shifted one bit up, meaning address 0x3C + LSB set to 0 to mean write operation. If the transmission stops is means that the controller did not receive an ACK on the address, meaning that no device replies to that address. Two most likely reasons is that the device can’t reply (ex: it’s kept in reset because reset pin is not switched to the right state or something like this) or it’s not using that address. Sometimes specs describe I2C address as highest 7 bits, other times they specify the full 8 bits, including LSB that will be 0 for writes and 1 for reads. Can you try to use 0x1E as the address?
I knew I was forgetting something. I just remembered it and checked it just before you post it.
But I think it’s something that I cant measure anymore. Only when I use 0x3C I get an ACKNOWLEDGE, any other device address returns a NACK.
I also check the data that is transmitted, and that seems correct. To read the low byte of the ID i first set the register address, output stream is: 0x78, 0x30, 0x0A. Than I read the register address, output/input stream is: 0x78, 0x00. But the 0x00 should be 0x56.
Ok, sorry I understood that you got only 0x78 out, so I thought you were getting a NACK.
But there is still something strange in your code.
You use 0x300a as register address, but you send out the same value (just the first byte actually), so output should be something like 0x78 0x30 0x0A 0x30
This is what you see?
Can you upload a full dump of the I2C transaction?
No problem, but it is also my fault. And it is an effect of a “problem” that I have.
I have an “old” oscilloscope at my disposal, this is a hybrid (if you may call that) between an digital and analog. I have to chose with this to see the whole communication without the chance to dissect it or just a small part (let say ~12 bits) to be able to dissect it. Therefore i have to tweak each time the trigger settings to be able dissect the whole communication. This enables me to see some sort of verification but it’s difficult to make a dump of it.
And I changed to code a bid, because I get confused every time how your functions work in sending the data because the data needs to be aligned in DWORD. But bluntly said you need to assume that the DWORD will contain 2 bytes. So if you want to send 7 bytes you have to use 3.5 DWORD (I hope I assumed this correct). This result in a slightly changed code:
wdata[0] = 0x300A; //Address of the High byte ID
I2c_Write(hI2C,wdata,2); //Set the register to the High byte ID
Sleep(50);
bytesread = I2c_Read(hI2C, rdata, 1); //Get the register value (byte)
This will result in the output stream of: 0x78 0x0A x30 (I2c_Write)
delay of ~100 us.
This will result in the input stream of: 0x79 0x00 (I2c_Read)
I don’t understand why I should see 4 different bytes because i;m only sending 3 bytes (1 for device address and 2 for register address).
In addition the “screen shots” off the oscilloscope, but it isn’t much[upload|1lfYJtMUqMQTJzQgINK+dqH06/Q=][upload|rLduJq4bQmXuae2LQUSXj438Zos=].
So far my part I think the I2C works fine now and think the problem lies somewhere in the camera.