Here we go! Choose one of the download links below (the same file!). At the site, you will be said to wait a llittle bit until the download link appears. You DO NOT have to pay.
Yes, it is stored in YUV411 format (see http://en.wikipedia.org/wiki/YUV#Y.27UV411). This helped to reduce the data amount per line from 640 down to 480 bytes (4 lumina bytes vs 1 choma pair) and thus under 512 bytes limit for one block write.
The SD card is pre-formatted with FAT32 and one big file which fills almost the whole memory of the card. I make use of Microchip’s FatFs File System to find the first sector of this file at the start. Then, data is written in Multiple Block Write mode with automatic sector number increment in the card.
PIC24 is run at 40MIPS (FCY = 40MHz) and the cam is clocked at 13.333 MHz resulting in appx. 16 fps. I use the output compare feature of the PIC24. So, it is just 1/3 of FCY. Just wondering if I could achieve 1/2 of FCY = 20 MHz. It did not work so far. I could use a T-flipflop to devide FCY externally. Edit: D-type 74V1G80CTR sold by Farnell can do this as well.
The DMA transfer to SPI is started right after the line scan begins and it takes appx. 150us for a block. There are only 2 external interrupts used: at line sync starting line scan and on Frame sync resetting the line counter. PIC24’s programm flow is well predictable (no cache). So, I do a “blind scan” of the line whereas short delays are done with NOPs (25ns).
I redrew the PCB and achieved 23x15mm size using microSD socket and a PIC in QFN-44 housing.
regards,
Dmitri
P.S. just thinking of implementing some audio. There are 30 empty bytes in each line block. 16fps * 240 lines * 30 = 115200 bytes per second for a raw audio stream.
Yesterday I managed to make my TCM8230MD camera work. It was sending data. Today it doesn’t work anymore. I have disconnected camera board from main board and, connected a power only and measured voltage on pins. DOUT, HD, VD, DCLK pins have precise IOVDD level, RESET is little less than IOVDD, EXTCLK is little less than DVDD, SCL and SDA pins are ok (even more, camera still receives i2c commands!). I was tested pins with multimeter (in mode with diode image) relatively to IOVSS and IOGND. Each case they have resistance and only in one way. Same results was been when it worked ok.
artem88:
Yesterday I managed to make my TCM8230MD camera work. It was sending data. Today it doesn’t work anymore. I have disconnected camera board from main board and, connected a power only and measured voltage on pins. DOUT, HD, VD, DCLK pins have precise IOVDD level, RESET is little less than IOVDD, EXTCLK is little less than DVDD, SCL and SDA pins are ok (even more, camera still receives i2c commands!). I was tested pins with multimeter (in mode with diode image) relatively to IOVSS and IOGND. Each case they have resistance and only in one way. Same results was been when it worked ok.
IOVDD, PVDD - 3.3V
DVDD - 1.5V
Are camera digital circuits (except i2c) dead ?
Hi Artem,
you write it still receives I2C commands. Does it mean you get ACK to what you send?
3V3 is IMHO way too much. I did not go that far. I supply the unit with 3VDC, then, I have 2 LDOs for 1.5V and 2.8VDC. I2C lines are pulled up to 3VDC, and the cam seems not to take any harm because of 3V EXTCLK.
you write it still receives I2C commands. Does it mean you get ACK to what you send?
3V3 is IMHO way too much. I did not go that far. I supply the unit with 3VDC, then, I have 2 LDOs for 1.5V and 2.8VDC. I2C lines are pulled up to 3VDC, and the cam seems not to take any harm because of 3V EXTCLK.
Yes, I get ACK.
I was afraid to supply it with 3.3V but some people wrote in this topic that 3.3V works fine. Thank you !
I know about these tricks about delays and I repeat, it worked yesterday. I didn’t change code since that. It always was low levels after powering on. Now there are high levels immediately after power on an they holds all time regardless of I resetting camera, sending extclk or after command was send. Pay attention, there are high levels on inputs (reset and extclk) too.
On what basis? I’m sure I killed it with ESD. Because I perfectly remember all the time I worked, I always discharged on house heating battery. But yesterday it was first time when I finished erecting work and loundged on armchair for coding. My fluffy cat jumped on my knees and I stroked her a long enough. Then I turned off my device and computer and went sleep. It was last time my cam worked… Now I’ll use antistatic wrist strap…
This happens sometimes to one of my cams too. To get it working again I have to disconnect power to it for a bit, then restart my app and re-init the camera.
On what basis? I’m sure I killed it with ESD. Because I perfectly remember all the time I worked, I always discharged on house heating battery. But yesterday it was first time when I finished erecting work and loundged on armchair for coding. My fluffy cat jumped on my knees and I stroked her a long enough. Then I turned off my device and computer and went sleep. It was last time my cam worked… Now I’ll use antistatic wrist strap…
Put your cat on a "mice and water" diet for a month. This might help to save money for a new cam :P
I never had ESD problems in my long long electronic career.
KreAture:
This happens sometimes to one of my cams too. To get it working again I have to disconnect power to it for a bit, then restart my app and re-init the camera.
Sometimes, the cam stops accepting I2C commands. I had to disconnect it from the power as well.
It’s hard to hold cam powered during a whole disconnection and testing, and connecting back and so on… I think it was being disconnected at least 1000000 times. Isn’t enough ?
I very lucky, that microcontroller outputs are ok. They didn’t expected that other-side inputs (reset and extclk) magically became outputs.
I measured the power consumption of my design. It is about 100mA from a 3VDC source which is good indeed. Since the firmware is interrupt-driven, some more miliamps could be saved by going IDLE where CPU is stopped while DMA, SPI & Co are still running.
BTW, SPI clocks the SD card at incredible 40MHz (FCY of the chip). I don’t know why but it works with many different SD cards of different flavors (noname included).
2.5MBytes/s are possible. Practically, not theoretically
artem88:
Thanks for video ! What framerate and extclk frequency was used during capture (not in resulted video) ?
Privet Artem!
The cam is configured to output 30 frames per second. Since EXTCLK frequency is 13.33MHz - around a half of what it should be, the framerate is down to 16 fps. EXTCLK is generated by the PIC24 itself, so it is 100% synchronous with the program execution flow.
13.33 MHz is one third of the PIC24’s internal execution clock (40 megaops per second). In this QVGA mode (320x240), the resulting DCLK is a half of EXTCLK. Thus, I have 6 machine clocks to store an incoming byte in the DMA buffer array.
I noticed that the resulting DCLK and EXTCLK are equal in frequency in modes with higher resolutions. It is not a half of it any more.
Hmm… I suppose, you have duty cycle of extclk is not equal 50%. It is 1/3 or 2/3, isn’t it ? I’ll be happy, if so, because I can’t produce 50% at desired frequency.
I noticed that the resulting DCLK and EXTCLK are equal in frequency in modes with higher resolutions. It is not a half of it any more.
Let's send these 23 pages of topic to toshiba for their datash*t best replacement :)
