TCM8240MD connector and example

Archive New Product Ideas
161

I’ve got this camera on a PCB with a 2.8V reg, a 1.5V reg, pullups on SDA, SCL and RESET and all the pins going to a 20 pin connector that leads to an ARM STM32 F103 VBT6, which is running at 72MHz.

While the ARM has a DMA controller I can’t see how to use it to clock in data on an input port, it seems more designed to clocking in/out data from its peripherals e.g. the SPI or I²C interfaces. I may be wrong on this count and would love to hear it if so.

Before I start sending any data, though, I’m worried that the 3.3V of the ARM will upset the camera (which gives a max of 3V on its inputs).

I could add a series resistor to the ribbon cable, but have no idea what value to use to get a suitable voltage drop. Alternatively, if this will work without the series resistor (i.e. the camera can take 3.3V) that’d be great.

Also, I’m only familiar with programming these things in C - while I could learn assembler if needed it would be quicker to get this off the ground in C. With my ARM running at 72MHz and giving the camera a 6MHz clock, divided by two for 3MHz data I calculate 24 operations per data, roughly?

Is that enough that I could realistically write this in C or not?

While it would be nice to get an actual image output, my application just needs the centre of mass of colours matching a threshold - I’m not sure if this will be easier or harder but essentially I just need to see if incoming data is within a colour threshold and store its x,y values if so. The ARM only has 20KB of RAM and 128x96 at 565 needs some 24KB, so if I have to store an entire image before processing I’ll need to cut some off or something.

Thanks for any help or advice!

162

Are you talking about putting 3.3V on the SDA and SCL lines for I2C?

That’s what I’m doing and it seems to work fine. My datasheet says 3.3V max for those pins, so I guess I’m living on the edge.

(I’m using the TCM8240MD, I don’t know the specs for the TCM8230MD.)

The datasheet doesn’t specify a max for EXTCLK and RESET, so I figure 3.3V is okay there, too.

I wouldn’t try putting 3.3V on PVDD and IOVDD since the datasheet does specify that it should be either 2.8V or 2.5V.

You also need a 1.6V power supply for DVDD.

Now that I look again… in the MAXIMUM rating sections, it says the maximum input voltage Vin (max)=VDD+.3, which equals 3.1V in my case since I’m supplying 2.8V to the chip. So I guess I’m exceeding that.

Maybe that’s why Kreature put resistor pads in his breakout board?

Good luck.

-David

163

I’ve got two voltage regulators giving 1.50V and 2.79V for the right power supplies, so that should be fine, but I was concerned about the SDA and SCL lines. I guess I’ll just have to try it and see.

Thanks for the information!

164

I got a clock pulse coming out of my ARM, and while I can’t measure the frequency it is at least the right duty cycle so with any luck it should also be 6MHz. (I only have a DMM and no oscope yet).

The I²C lines are pulled to 2.8V and since it’s all open-drain that should mean my ARM (3.3V) happily talks to it at 2.8V. I tried sending it the initialisation command and got 1.3V on the DCLK line which I guess means it turned on and there’s a clock pulse there, but couldn’t access the data lines to see if anything was being sent, and couldn’t see if it was an actual clock pulse.

At any rate I then reprogrammed my microchip to read the DATA pins and turn on an LED when the MSB was 0, with the intention of shining a torch at the thing. Uploaded the new code and now it hangs on sending the START condition, no voltage on the DCLK line, the camera apparently isn’t responding or my micro’s just holding the line low for some unapparent reason.

Any ideas why it might be holding SDA low after sending START? Could I have fried the camera? (I wish it was socketed!)

Thanks!

165

Update: I made an LA using my parallel port ([tfla) and hooked it up to SDA and SCL. I instantly noticed that the address was shifted by one! silly mistake, the but stm32 library asks for a 7bit address - turns out it wants a shifted 7bit address! (I wish the documentation would mention this kinda thing… )

https://randomskk.net/u/traces/tcm8230m … ilure1.png

Anyway, I quickly fixed that and now have a lovely trace of the ARM sending the camera’s address, 0x03 for the register, 0x00 for the new value. The camera should now be initialised!

https://randomskk.net/u/traces/tcm8230m … ialise.png

Sadly this thing is only good for about 500k samples a second, nowhere near fast enough to watch the clock or data lines, but it’s already got me started. Next step: trying to read the data!](http://tfla-01.berlios.de/)

166

I can get you traces from my 40 msps digital logger if you like.

They are, however, not very interesting.

It’s a shame the cams don’t have a full internal readout-buffer so we could have read out data at our leisure via SPI or I2C.

Tell me if you can get some images from it. I still only get mostly garbage from mine…

167

Thanks for the offer but I think I’ve got the I²C all working now, just gotta try and read the data itself!

I’ve got the '30, which is the smaller 640x480 max one, which Twingy has already got pictures from so I probably can’t be of much help in terms of registers etc if I get images from it.

168

Hey!

I’ve been watching this thread for quite a while now, since i got one myself. Finally it’s time for me to share my own thoughts since i work with this cam on a project. I’m a masters student on embedded systems and don’t have a lot of exp in the field but still i have quite a lot of ideas and i’d like to know your thought! My goal is to read data at minimum 640x480 at 1 fps, controlled outside the cmos.

  1. an at-tiny initialises an sd-card. A cpld working at ~50mhz collects the parallel data from the cmos to the sd-card by SPI. The data is stored as RAW and read by a special program on a PC.

  2. an at-tiny controls a cpld and sd-card. The cpld reads data from the cmos, stores in onto a sram as fifo. The at-tiny makes sure the cpld stops reading from cpld, and then reads from the sdram throught the cpld and outputs the data as fat onto the sd.

  3. some reaaaaally fast uC does the reading and writing to an SD which seems impossible at the datarate.

169

Hehe. All good options in my book.

The reason why I am working so hard on a MCU only solution is because of the circuit size. I really want to put this all together at a low a weight and size as humanly possible.

I am looking for other cam chips though as this onne does not have a readout-buffer. If it had, the mcu could read the data when it wanted instead of having it delivered at the inconvenient rates this cams are supplying.

170

I’m having some trouble with the JPEG data that is coming off the camera.

I’ve attached a picture that shows what the JPEG data looks like. After the SOS (Start of Scan) structure, the same data repeats over and over.

The camera sets the error flag register (Addr 0xFA) to 0x80, which corresponds to “FULL_ERRN.”

Also, I noticed that if I set the PLL mode to 0x1 instead of 0xF, both error flags become set (“ENC_ERRN” in addition to “FULL_ERRN.”)

How is PLLMODE supposed to be set?

The application note says “0:PLL Off” and “1-F:PLL On”.

What’s the difference between the different “PLL On” settings?

Here are some other things that I’ve noticed:

In the DQT structure, I received a “length of field” of 0x84. This matches the length of the DQT data that I received, but does not match the length mentioned in the datasheet (pg. 21 says it should be 197bytes=0xC5).

The other structures match what the datasheet says as far as length of field goes (SOF, DHT, and SOS).

(As long as you realize that the datasheet has a typo in the SOF length of field - it should be 0x11 instead of 0xC5 - someone forgot to change it after copying and pasting.)

I have circled the JPEG marker codes in the image generated by the TCM8240MD:

Any ideas as to why the image data repeats and why I’m getting the error code?

http://www.prism.gatech.edu/~gth681s/bu … G_Data.gif

Thanks,

David

171

Also, I am uncertain about my setup for the image size.

I’m trying to output JPEG for the “full mega” images, since I’m not sure if it’s possible to do JPEG for the smaller images.

I tried setting up the registers for an image size of 1280x1024, since that is the size mentioned on pg. 20 of the datasheet.

Based on the application note, I set the following registers:

	I2CWrite(0x02,0x00); //Set Camera Active
	I2CWrite(0x03,0xCF); //PLL On (last nibble correct?)
	I2CWrite(0x04,0x50); //JPEG On, DOUT On, PICMODE:1280x1024
	I2CWrite(0x05,0x80); //0x80 = max framerate, 0x00 = 1/4 framerate
	I2CWrite(0xE6,0x08); //0x08 = 4 byte output units (was 0x00)
	I2CWrite(0x0E,0xB0); //Changed b/c of PICSIZ (was 0xAC)
	I2CWrite(0x11,0x6A); //Changed b/c of PICSIZ (was 0x02)
	I2CWrite(0x14,0x33); //Changed b/c of PICSIZ (same as default)
	// Need to change SPCOUNT (on addresses 0x1F and 0x1E) ?

The application note says that after you select the image size, you have to change the registers 0x0E, 0x11, and 0x14. However, looking at the default values for those registers, they don’t match what the application note says they should be for the default image size. Does anyone know why?

Thanks,

David

172

I am also having issues getting the camera to capture proper data but so far I am running it in raw (rgb 565) mode.

As you see from my images, the data transfer is correct and I can enter/exit testmodes correctly. It appears that the imaging parameters and/or framing settings are wrong causing me to fetch data from wrong area of sensor/memory or capturing garbage…

173

Kreature,

A few questions for you:

– Are you getting any error flags (Register 0xFA)?

– How are you initializing the camera registers? (for your current tests with RGB mode)

----- What image size were you going for?

----- How did you calculate SPCOUNT?

– Have you tried YUV?

Thanks,

David

174

I will look at error flags tonight.

The SPCOUNT was done according to datasheets, but with little results.

I’ve been trying to run the lowest rez just to see if it worked.

I have 5 cams, currently using 2 for dev. Both give exact same “images”.

I’ve only used rgb as I can output that serially as a file to the computer. (BMP supports RGB 565 format if you set up the header with data type bitfield!)

175

How are you calculating SPCOUNT, exactly?

I don’t quite understand how HCOUNT and VCOUNT are determined.

Based on the default register values (Initial Hex from the Datasheet), I obtained the following:

Datasheet:
H_COUNT = 0x2B3 = 691

V_COUNT = 0x21B = 539

SP_COUNT = 0x400 = 1024

However, the Application Note quotes different numbers:

Application Note:
HCOUNT = H_COUNT (default:713) + 677 = 1390

VCOUNT = V_COUNT (default:539) + 513 = 1052

SPCOUNT = 2 x (H_COUNT + 183)

SPCOUNT = … (slightly different formula for different sizes)

The application note doesn't say it, but plugging in their H_COUNT into their formula gives 2x(713+183)=1792. This is very different than the number programmed into SP_COUNT=1024. What's going on here?

Needless to say, the only Application Note number that matches the initial register value is V_COUNT.

Here are my calculations, based on what I can piece together…

There are 960H+92H(blank)=1052H in one VBLK.

This is equal to VCOUNT, so V_COUNT=539 (the default value)

Edited:

It seems that the HCOUNT calculation is based on counting the clocks in a single row of image data at 1/2 the DSP clock frequency.

So for the Full Mega size, note that the data output is output at 1 x DSP frequency. This means you divide the number of clocks by two when calculating HCOUNT.

Smaller images are output at 1/4 the DSP clock rate, so you need to multiply the number of clocks by 2.

The result is that for every picture size, HCOUNT comes out to be approximately the default value of 713 (after you subtract the offset of 677). (I actually calculate 715.)

Also, is there a difference between:

SPCOUNT and SP_COUNT?

HCOUNT and H_COUNT?

VCOUNT and V_COUNT?

My understanding is that “No Underscore” means the actual value that corresponds to some physical phenomena (like the number of clock periods in a certain region of the image). This is in contrast to “With Underscore,” which is the way the value is stored in the register after subtracting some arbitrary offset.

Is this remotely correct?

Thanks,

David

176

good to see some data coming out of these cameras.

This question may have been asked before, but has anyone thought of using a DOSonCHIP chip to write the camera data to an SD card?

We’d need a discrete logic shift register circuit running at eight times the camera clock speed to produce an SPI stream. Don’t know if there are discrete parrallel to SPI circuits out there…but it doesn’t seem a difficult idea.

The idea would be the micro would setup the file creating commands to the DosOnChip then unleash the camera which would squirt out parrallel data which would be converted to an SPI stream. At the end of the frame the micro would take over and finish up. The DosOnChip would handle the FAT management and SD card stuff.

Anyway, just my two thoughts about getting closer to a micro controlled camera without exotic CPLD or FPGAs. I doubt we’d get maximum clock speed, but surely something reasonable.

Phil

177

Phil,

I hadn’t heard of the DOSonCHIP module. It’s pretty cool.

But it’s maximum SPI frequency is 2.4Mhz.

[CD17B10 Datasheet

It takes about 10 serial bits to send a byte of data using SPI.

So the limit is about 0.24 MB/s.

I’m working on a single image buffer using a 256KB SRAM chip. As the data is captured into SRAM, a PIC32 microcontroller pulls it off and stores it to flash memory (USB, SD card, or CF card).

EDIT:

To be more specific, it will use a counter to address the RAM.

(Need 18 bits to address all 256K x 8bits - this can be made by cascading smaller counters.)

It also requires some simple logic (AND gates, possibly a NOT gate).

Some tristate buffers are needed to prevent the camera from driving the SRAM I/O pins while the PIC is reading data from memory.

Altogether, you’ll need a custom PCB to make this work, especially since the SRAM is surface mount and we’re dealing with high frequencies.](porkbun.com | parked domain)

178

you know I looked and looked for a maximum speed for this device…and it was staring at me all the time.

2.4MHz…oh well, that scratches that idea.

The SRAM buffer idea looks the best. You probably won’t need a PIC32 micro then, unless you want higher frame rates. Not sure you’d get that much of a frame rate increase compared to a 16Bit micro like a PIC18F4550.

When you’ve got the logic figured out, the PCB design should be no problem, I can help there if need any though you sound like you know your stuff.

I wonder how fast a micro can stuff data into an SD card? That’d be a limiting factor.

Once the not inconsiderable task of getting a frame out of the camera is worked out, we probably need to think of some sort of user interface.

For my application, I’m after a circuit I can stuff into a head mounted arrangement like a LED headlight, so I was thinking of doing configuration etc on a PC and only having a single button or two. Particularly if motion JPEG can be achieved (maybe with a PIC32). Not thinking of any LCD displays or such for frame counts or whatever…with a big enough card this wouldn’t be necessary anyway.

The circuit should probably have some other triggers for other applications like a PIR input for security systems or capturing wildlife etc. If the media is removable then a USB FAT client probably won’t be necessary but a USB client for configuration would be handy, perhaps a USB charger cct. Got that under my hat when the frame capturing is ready.

Phil

179

Phil,

We are definitely on the same page…even on the details.

The PIC32 will handle the FAT file system. It can read from the SRAM using the parallel master port (PMP). It can even do it in the background using DMA. Then it can write to a SD card over SPI (also using DMA).

rgbphil:
I’m after a circuit I can stuff into a head mounted arrangement like a LED headlight

Funny you should say that. I'm planning on putting it in an LED flashlight as well.

The battery I picked out was a rechargeable CR123A (lithium ion). However, the choice of battery will probably depend on how much current the final device draws. The charger is a Maxim MAX1555 (for single cell lithium ion). The MAX1555 charges the battery off the USB port and the PIC32 can serve as the USB client. :slight_smile:

The device I’m working on is called the “buffercam” since it continuously records video and preserves the 30 seconds before and after an “trigger” occurs. It’s designed to be mounted on bicycles, motorcycles, and cars to record vehicle accidents. The video footage can be used to determine who was at fault for the accident. (The device is triggered by an accelerometer or by manually pressing a button.)

Now, if I could only get some valid data off the camera…

-David

180

Its been previously mentioned before (in this ever expanding thread!)…a FIFO RAM might be of more use than a SRAM.

http://www.semiconductorstore.com/cart/ … duct=10565

I’ve had no experience in using RAMs though.

I imagine getting the data out of the FIFO/SRAM to SD card would still be the bottleneck for this project.

A couple of questions to others…

Is there a more comprehensive list of commands to various registers than the sparse datasheet on Sparkfun?

Is a motionJPEG file simply a conglomerated bunch of jpeg frames put together? This would affect the processing needs of the micro if there were additional information needed.

Phil