TCM8240MD connector and example

Archive New Product Ideas
401

@maxwell86

did you get your code working for Arduino? I am trying to configure my device but am also getting the response code ‘3’ from endTransmission()… I changed my library to account for Fast I2C bus at 400k. Interestingly enough, I get response code ‘0’ for success when I send the instructions to camera for setting active and reset. Here is a sample of my code:

int end_RTN; //debug for Wire.endTransmission()

Wire.begin();//All slave devices to listen

delay (100);

Wire.beginTransmission(cam_address);//Select slave device

Wire.send(0x02); //0x02 register_address

Wire.send(0x00); //0x02 ← 0x00 Set Camera Active

end_RTN = Wire.endTransmission();

delay(100);

Serial.println(end_RTN, DEC);//debug

Wire.beginTransmission(cam_address);//Select slave device

Wire.send(0x02); //0x02 register_address

Wire.send(0x40); //0x02 ← 0x40 Set Camera Reset

end_RTN = Wire.endTransmission();

delay(100);

Serial.println(end_RTN, DEC);//debug

Wire.beginTransmission(cam_address);//Select slave device

Wire.send(0x02); //0x02 register_address

Wire.send(0x00); //0x02 ← 0x00 Set Camera Active

end_RTN = Wire.endTransmission();

delay(100);

Serial.println(end_RTN, DEC);//debug

Note that the above gives success response on serial line (‘0’ is output). The next sample just gives ‘3’ though for NACK…

Wire.beginTransmission(cam_address);//Select slave device

Wire.send(0x0B); //0x0B register_address

Wire.send(0x00); //0x0B ← 0x00 White Line OFF

end_RTN = Wire.endTransmission();

delay(100);

Serial.println(end_RTN, DEC);//debug

Any suggestions??

edit1: I should note that cam_address has already been defined as ‘61’ as per the specs of camera.

edit2: Uh oh… i think you are using 230 and I am using 240… that prob the issue… maybe I’ll switch to 230 also. heh

402

Well it has been some time since my first post. Issue was with my clock signal’s duty cycle. That is fixed up so my I2C is configuring the camera without any problems… Moving onto actually getting data to PC via arduino. Hopefully will post something soon with some successes.

403

Hi, this post seems quite dead nowdays.

There is good info in this post about this camera, but who put the camera work just use only the datasheet on the sparkfun website? That is not much information, is there any user guide or implementation guide?

“Twingy” and “Kreature” is there any library with some configuration codes?

That could help me to inicialize this camera?

Best Regards

404

rgbphil:
Hi,

I’m tossing some ideas around for a circuit, eventually I’ll post it or if anyone knows of a site where a collaborative effort can be done it’ll be added there for comment and improvement.

Just need some sanity checking. Can anyone check their interpretation of the datasheet on my assumptions please?

  1. The device clock is via the EXTCLK pin, and the internal clock rate can be set with the PLL to various settings via I2C commands

  2. When the device outputs a JPEG file (or other image formats) data is presented to the D0…D7 pins and is valid on the rising edge of the DCLK pin which is an output of the device. A data frame or jpeg frame is indicated by a high on the VBLK pin. The HBLK pin indicates the device pausing while it is doing JPEG compression.

  3. The DCLK pin is actively clocking along, even when the device isn’t doing anything, data is only valid when the VBLK pin is high.

  4. We can just take the JPEG output of the imager chip as a valid JPEG file without further processing (assuming we can get the data to a memory card).

So from these assumptions we could build a circuit that takes the VBLK pin and enables a SRAM chip. The DCLK pin can then be used to perform a write enable operation and also clock a binary counter chip (or chips depending on the address space needed). This would automatically clock the data into the ram chip for later retrieval by the micro.

To complete the circuit we need a way to disengage output operations from the imaging chip so the micro can look at the ram. The micro could control the reset of the binary counter chip to reset to the start of the frame, then take over (possibly by a little extra logic) the clocking of the counter, reading it and writing to the SD card as needed.

I can’t see a pin to disable output from the imager…so I presume there is an I2C command to do it…does anyone have an idea where the command set for the chip is? I can see a list of registers, but no list of what the register values should be for different operations.

Also any suggestions on a suitable oscillator frequency to clock the imaging chip with?

If the assumptions are wrong, please indicate this and any suggestions you might have.

Phil

I have this cam writing frames directly into an SRAM chip I pulled off an old hard drive. Which I then read with an ATMega.

I currently have the cameras EXT CLK line connected to a 12MHz crystal clock. Higher clock rates are possible it will depend on the write time for the SRAM. I just happened to have some 5V 12MHz modules laying around. At 12MHz I am capturing 14.65 fps.

The SRAM address lines are connected to 74HC161 binary counters which are clocked by the cameras DCLK line.

The counters active low reset lines are connected to the cameras VD so that each new frame resets the SRAM back to address 0.

The counters Count Enable is connected to the cameras HD so that the counters only advance during a valid line. The counters will pause during horizontal/vertical blanking.

DCLK is also fed to the SRAM Write Enable line which is active low.

The 8 bit camera data bus is connected to the SRAM data bus via a 74HCT574 latch. Using an HCT here acts as an a bit logic level converter. The latch is active on a rising edge clock so the cameras DCLK is used to drive the latch clock.

The counters control lines are fed into the A bus of a 74HC157 1 of 2 4-bit data switch. The B bus is connected to the ATMega. The bus selection line is connected to the ATMega which allows it to control if the clocks and SRAM are driven automatically or by the ATMega.

When the SRAM is being driven automatically the following happens:

  • VD resets all counters to 0 which in turn sets the SRAM to address 0.

  • HD rises when the first byte of pixel data is available on the cameras data bus enabling DCLK to advance the counters.

  • DCLK rises and the first pixel is latched via the 74HC574 onto the SRAM data bus.

  • DCLK falls and the SRAM Write Enable is active which writes the byte latched by the 74HC574 into the first SRAM memory location.

Bytes are successively written into SRAM until HD falls at the end of the line at which time the counters pause until HD rises signaling the start of the next line.

After a complete frame is written into SRAM, VD will fall causing the timers to reset and the whole process repeats itself at a nice high frame rate.

An 8 bit I/O port on the ATMega is connected to an 74HC245 8-bit bus tranciever. The enable is connected to the 74HC157 select line and to the 74HC574 enable via a 74HC04 inverter so that only the camera or the ATMega is connected to the SRAM data bus at one time.

Changing the select line of the 74HC157 from “SAMPLE” to “HOLD” gives control of the counters reset and clock lines over to the ATMega. My dump frame function then just resets the counters, reads a byte from SRAM, sends it out the serial port, clocks the counters to the next address and repeats for the length of the frame.

This allows me to capture frames at a high frame rate and then use a low speed mcu to read/analyze the frame at it’s own pace without worrying about trying to keep up with DCLK in some tightly woven assembly function.

I have been able to dump frames to my pc from all modes from 320x240 down. As long as you have enough counters and SRAM to cover the resolution you want to run in it works pretty good so far. I happen to be using a CYM1464, 512k x 8bit SRAM with 25ns r/w but you could scale down to a 32k x 8bit SRAM if you stay in the low resolutions.

I’m also thinking of dividing the VD in half so that two sequential frames are written to the SRAM making it easy to compare frames. There is also the possibility of connecting the counter presets to the ATMegas external SRAM interface so that it can randomly access frame data instead of sequentially, however all the stuff I want to do with the data involves reading the data sequentially so I’m not sure how much advantage this would hold.

Using surface mount versions of the mentioned chips would make this a fairly small package.

A lot of fun for a $10 camera and a hand full of dime-a-dozen parts from all those past grab bags :slight_smile:

**All registers at default values except AWB disabled under a 40w incandescent light**

http://wickedmindselectronics.com/image … egaCam.jpg

405

Finally we finish the test board for TCM8240 … Hope it works. I´m trying to port my old code there but it seems to be easier to make it new.

http://www.ifrdesign.com/79-devboards/dvrboard

406

I started experimenting with object tracking. Using CMVisions “YUV466” color map I found at http://www-2.cs.cmu.edu/~jbruce/cmvision/ to threshold the image, I got the following results :slight_smile:

http://www.wickedmindselectronics.com/i … %20YGB.jpg

P.S. Turns out my old Rubiks Cube is a great model for testing colors since you can just twist up any old color combination to test!

407

Hi WickedMinds

What is the hardware that u are using to interface the camera with the pc?

regards

408

FET_Destoyer:
Hi WickedMinds

What is the hardware that u are using to interface the camera with the pc?

regards

The camera is connected directly to a static ram chip as described in my previous post. I use an ATMega128 to read frames from the static ram chip and send the data via serial to the PC which is processed by a C# .NET application I threw together.

409

Wow! Been a long time!

Just wanted to mention I hope to publish a updated version of Atmels ISI driver with tcm8230md and tcm8240 driver module for avr32linux. It has all the cameras registers available in debugfs for hacking directly from linux userspace.

It still has issues but it’s also a lot of fun.

It makes it a lot easier to fiddle with these cams. (as long as you have a old ngw100 card lying around that is…)

410

KreAture:
Wow! Been a long time!

Just wanted to mention I hope to publish a updated version of Atmels ISI driver with tcm8230md and tcm8240 driver module for avr32linux. It has all the cameras registers available in debugfs for hacking directly from linux userspace.

It still has issues but it’s also a lot of fun.

It makes it a lot easier to fiddle with these cams. (as long as you have a old ngw100 card lying around that is…)

Hi KreAture

I’ll wait fot that driver.

I read all the posto but I’m with a little dificult to understand registers of tcm8240, is there any APPnote for this camera?

Cause the datasheet the register are not clear of what they do.

Regards

EDIT: I just saw that the appnote is on sparkfun website, even so I think your driver will be welcome here for those who are strating this camera. =)

411

Hi WickedMinds,

your direct SRAM interface to the TCM8240MD sounds very interesting. Can you please post a circuit diagram of it?

Even a sketch would be very useful.

Another question - what is the minimum distance of that camera to get a sharp image?

Thx

Leo

412

Can anybody tell me the exact weight of this camera module. The weight is a big concern in my project…

its weight should be less than 15 grams. :expressionless:

413

leonix:
your direct SRAM interface to the TCM8240MD sounds very interesting. Can you please post a circuit diagram of it?

Even a sketch would be very useful.

Here is the schematic of the last time I had it bread boarded. I’ve added on to it for stuff specific to my project but this still remains the core method of how I have been able to grab frames with an ATMega128.

http://www.wickedmindselectronics.com/i … 0final.jpg

leonix:
Another question - what is the minimum distance of that camera to get a sharp image?

I have had good results with my tests that have objects from inches to about 3 feet from the camera using QCIF Zoom.

414

Does anybody know what is the size of a compressed image after the jpeg compression feature of this camera has been implemented?? :?:

415

KreAture:
Just wish I had solder-masks…

http://kreature.org/ee/avr/cmos_cam/breakout_1.1.jpg

If this board was to be made professionally I’d ofcource do it 2-sided to tidy up the routing. Then I’d add silkscreen to connector-side so one would always have the pinout of the connectors available.

edit:

The large 1206 resistors are for all spots where user might want to change stuff. Only the power-system is set up with tiny stuff as that will be a 1-time affair. (0603 and 0805 for power system.)

KreAture can you tell me from were do you buy the blue pcb?

416

More images [here.[/size][/b]
Camera and Color Mapping Board
http://www.wickedmindselectronics.com/i … d%20Up.jpg
Client Application to edit on board Color Map and display frame dumps.
http://www.wickedmindselectronics.com/i … 20Cube.jpg](http://wickedmindselectronics.com/serendipity/index.php?/archives/2012/02/19.html)

417

Hi all!

I’m new to forum and I’m pleased to see so much work being done with the TCM82x0 cameras.

I’m using TCM8230MD camera in my project. But currently I’m facing a problem: the register values of the camera are not changing from their default. And hence the camera is not getting started at all. I checked it by reading the values by I2C. I’m getting the ACK for write though. I have used pull-ups of 4.7kOhm. I have connected the camera pins SDA and SCL to that of PIC18F2455 (operating at 2.8V, same as IOVDD of camera). I have given 16MHz clock to EXTCLK. The clock for PIC is 24MHz and SCL frequency is set to 400kHz. Since reading operation is being performed correctly, I’m getting confused.

Please suggest me a remedy for this! Unless the register bytes are written properly, I can’t move ahead!

Thanks in advance! :slight_smile:

418

Here is a snip of code I use with the Arduino Wire library to start up my cam.

#define TCM_DEV_ADDR                    0x3C
#define TCM_REG_SLEEP                   0x1F
#define TCM_SOFT_RESET	               0x06
#define TCM_REG_AWBSW	                0x0A
#define TCM_REG_PICTURE                 0x03
#define TCM_DOUTSW_ON	                0
#define TCM_DATAHZ_OUT                  0
#define TCM_PICFMT_YUV422               0

// Picture Formats
#define TCM_PICSIZE_VGA          0
#define TCM_PICSIZE_QVGA         1
#define TCM_PICSIZE_QVGA_Z		 2
#define TCM_PICSIZE_QQVGA		  3
#define TCM_PICSIZE_QQVGA_Z		4
#define TCM_PICSIZE_CIF			 5
#define TCM_PICSIZE_QCIF		   6
#define TCM_PICSIZE_QCIF_Z		 7
#define TCM_PICSIZE_SUB_QCIF	  8
#define TCM_PICSIZE_SUB_QCIF_Z	9

void WriteCameraRegister(unsigned char reg, unsigned char data)
{
	Wire.beginTransmission(TCM_DEV_ADDR); 
	Wire.write(reg);
	Wire.write(data);              
	Wire.endTransmission();    // stop transmitting
}

void CCD_Init(unsigned char pic_format)
{
	// Send a Reset
	WriteCameraRegister(TCM_REG_SLEEP, (1<<TCM_SOFT_RESET));
	_delay_us(500);
	// AWB
	WriteCameraRegister(TCM_REG_AWBSW, 0x80);
	// Enable Picture
	WriteCameraRegister(TCM_REG_PICTURE, TCM_DOUTSW_ON | TCM_DATAHZ_OUT | (pic_format<<2) | TCM_PICFMT_YUV422);

}
419

Hi again! Thanks for the reply!

Just wanted to tell that I solved the problem! :slight_smile:

It was a stupid error in my I2C program (as stupid as missing a semicolon!) (I’m using PIC18F2455)

I’m getting a decent image output. But the colour saturation is poor and the picture is getting slightly over-exposed. So, now will try some tweaking of the image-related registers. I’m currently extracting only one frame. So, next milestone would be accepting a 30fps video. Will keep posting! :slight_smile:

420

The default settings do give a washed out appearance. Set the brightness to 0xDC.