SparkFun Forums 

Where electronics enthusiasts find answers.

Have a good idea for a new product for SFE or Olimex? Let us know!
By drmn4ea
#86106
Dmitry's right... so far, I have run the TCM8230MD with DVDD=1.5V (low-dropout linear regulator) and with PVDD and I/O voltage up to 3.3V (for PIC18F2450/4450 microcontroller) without any trouble, and no sudden ramp-up in current that would indicate protection diodes becoming active. (Fair warning - PIC18xxxx do not have much memory, so you may be limited to buffering and sending 1 line at a time at 320x240 or 640x480 at full color, depending which. But the TCM8230 at least handles the voltage well.)

For anybody interested, I have posted a free EAGLE footprint for the '8230: http://tim.cexx.org/projects/tcm8230/tcm8230.lbr
By KreAture
#86141
Undocumented registers is the worst thing I know of... Next to stuff that doesn't work at all ofcource.

I have been writing a driver for the TCM8240 for Linux. (Running Linux on NGW100 card with AVR32.) I can thusly handle the data fairly easy now and am running the camera at 20 MHz input clock with PLL off.

I have tried using the initial values of the regs as well as the calculations in various sources but am having a hard time accepting the quality of the results. I get a lot of lines and such in the images, as well as horrible color reproduction.

I am grabbing data at 1280x960 for the moment. (4VGA)
Setting the cam to CBMODE 4 gives me lovely colorbars and comfirms that my transfer algorithm and driver structure is sane.

Has there been any more progress on the registers? Can we recap what we have learnt so far?
By KreAture
#86147
The datasheet and the appnote does not agree on many values.
For instance, SP_COUNT defaults to 1024 in the docs which also sais PICSIZ defaults to 0. It also states that H_COUNT defaults to 691.
When I check form power-on, All this is correct.

Appnote sais H_COUNT defaults to 713 and that internally 677 is added to make the count 1390.
It then states the formula SP_COUNT = (H_COUNT + 183) * 2 for PICSIZ=0. This would give an SP_COUNT of 1792 for H_COUNT=713 and of 1748 for H_COUNT=691.

This doesn't make sence. Why should some stuff be correctly initialized and other stuff not?

I've also fiddled with some of the other registers and many seem to have the same effect of sliding the image left/right or corrupting it with vertical lines. If the H or V_count is too far off it looks like one is missing the image alltogether.

This really doesn't add up at all.
Any insight would be apprechiated.

I could post some examples but without all the settings, they are meaningless.
By ma4826
#86226
I did this test a year ago. Hope you helps.
Code: Select all
Address        Value
-------	     -----
0x0D           0x01      //Optional?
0x0B           0x00      //White Line OFF
0x6D           0xA1      //ABW_SW -> ON
0x58           0x10      //Exposure time
0x05           0x80      //Frame Rate full
0x1A           0xFF	
0x1B           0xB3
0x0E           0x14
0x11           0x6A
0x14           0x33
0x1F           0x0B
0x1E           0xE7
0x04           0x18      //RGB Full Size 1280x1024, OUT ON
In my SRAM only fit 200 of the 1024 lines.

http://webs.ono.com/ma4826/pbbmp_0x1F=0 ... LL_OFF.png

Best regards,

ma4826
By KreAture
#86228
Thankyou.

I will see if I can reproduce that today.

Are you still using registers or have you started using the bitmapped fields I set up? I find the fields are great as they keep track of the different bits for you. Just be sure about the endian.

I had to rewrite the fields for the avr32 as the silly thing is big endian...
I guess the only safe way to use the structs is to use a define or something for the endianness. (I have it defined both for little and big now.)

ONe wierd platform I tried had bit fields internally as little endian, but addressing in memory was big endian... That was a nightmare.
By KreAture
#86250
Finally got around to testing it ma4826!
It works sortof. I am still getting banding though.

After doubling the caps on my board it looked different.
Adding even more made it different again.
I say different, not necessarily better, but less blue though.

I think my regulators are not fast enough to handle the frequencys I run at. Maby there is also an issue with their rating. The TCM8240 can draw up to 150mA on the 1.6v rail.

I am running at 20 MHz so maby that amplifies the problem.

http://kreature.org/ee/avr/cmos_cam/128 ... ings_8.png

That said. Is is atleas possible to recognise furniture...
By KreAture
#86275
halane34
Your issue will be the datarate, but it is possible.
You will have to use a clock frequency to the sensor that is high enough for it to function even if it is lower than the specified 6 MHz minimum.
Further, you can reduce the output rate by setting the H and V count high I think.

If you want to save yourself a lot of issues with image quality, I do suggest you use TCM8230 instead of TCM8240 as it has a complete manual and is fully automatic. Very little has to be done to it's registers in order to make it output good pictures. TCM8240 is a nightmare untill we manage to understand and document it fully.
By KreAture
#86402
ma4826
What clock did you give the cam as input?
(Do you think it has any effect on the results?)

My linux platform runns great and my driver for ISI-hardware and capture works well, but I can't get those nice shiney pics you guys have...

I've tried running it at 10 and 20 MHz but the images look identically awful.

Edit:
Sorry, just reread your post and you did say 12.5 MHz...
Hmm. Must be something else then.
By KreAture
#86426
In case anyone has issues getting data transfered to image sensor interfaces, here are the right rez for each picsize mode. (Image Sensor Interface on AVR32 will fail if you have it set up for different rez than cam is outputting!)

Mode / Rez
0: 1280x960 (unless PICMODE=1, then it becomes 1280x1024)
1: 640x480
2: 320x240
3: 160x120
4: 128x96
5: 352x288
6: 176x144
7: Undefined ?

Hope this helps someone.
By KreAture
#86428
ma4826 :
I tested your settings for 352x288 now.

Used the following settings translated from your post: (numbers in decimal)
address 0x0B = 0
ls_es_lim = 2
h_count = 1023
0x0E = 14
0x11 = 74
0x14 = 51
sp_count = 3011

In addition I have to use YUYV mode (as that's what my codec is set up for right now.)
I also used 12.5 MHz external clock with no PLL.

The result seem to be lacking. I get a pink stipe on the right side of the image. Nothing more. (The stripe is a horribly burned image piece.)

Question: When your cam was not correctly adjusted. Did you see pink/blue images, or was it just clipped?
Maby there is something wrong with my cam.

There can't be anything wrong with the codec/transfer as the color-bar modes look beautiful.
By johandc
#87446
Hi,

I started out with these settings which worked:
Code: Select all
	image_sensor_twi_write(0x1A,0xFF);  // H_COUNT = 0x3FF = 1023
	image_sensor_twi_write(0x1B,0xB3);  // V_COUNT = 0x21B = 539 // Assuming Register 0x1C is left at the default (0xA1)
	image_sensor_twi_write(0x1E,0xC3);  // SPCOUNT[7:0]
	image_sensor_twi_write(0x1F,0x0B);  // SPCOUNT = 0xBC3 = 3011 // Doesn't match formula?
But then i tried to do a dynamic calculation of the H_COUNT, V_COUNT and SPCOUNT variables, and inserting into registers 0x1A, 0x1B and 0x1C, and SPCOUNT in 0x1E and 0x1F, just like the example above. But it didn't work, even though i was using the same values as above! Then i noticed that nobody sets register 0x1C, even though it's the correct thing to do. And i found out that when i write to register 0x1C, i also overwrite bit's D7 and D6, which should be empty. however, these two bits make the picture to go completely black!

Here is my H/V_COUNT + SPCOUNT code that works for FULL resolution.
Code: Select all
	uint16_t hcount = 713;
	uint16_t vcount = 539;
	uint16_t spcount = 2*(hcount+183);

	image_sensor_twi_write(0x1A, hcount & 0xFF);
	image_sensor_twi_write(0x1B, ((vcount & 0x0F) << 4) | ((hcount >> 8) & 0x03));
	image_sensor_twi_write(0x1C, (vcount & 0x3F0) >> 4 | 0x80); // And with 0x80 to keep first bit set, otherwise pic will be black
	image_sensor_twi_write(0x1E, spcount & 0xFF);
	image_sensor_twi_write(0x1F, (spcount & 0xF00) >> 8);
Still for some reason the formula 2*(hcount+183) as described in the app note is not correct, it simply won't work. The value for spcount 3011 worked for us in full mode.

Our images are typically very pink'ish disregarding what resolution we use. When in test mode, there are no problems. A list of test modes are shown below:
Code: Select all
	//image_sensor_twi_write(0x2D,0x7E);	// Grayscale test-pattern
	//image_sensor_twi_write(0x2D,0x6E);	// Same as 5E but brigt
	//image_sensor_twi_write(0x2D,0x5E);	// Grayscale horizontal gradient bars
	//image_sensor_twi_write(0x2D,0x4E);	// Color gradient bars
	//image_sensor_twi_write(0x2D,0x3E);	// Dimmed Color gradient bars
	//image_sensor_twi_write(0x2D,0x2E);	// Vertical Bright Color bars on white
	//image_sensor_twi_write(0x2D,0x1E);	// Vertical Dimmed Color bars on black
By KreAture
#87454
johandc
I use bitfields to simplify my handling of the unrelated bits in the registers.
Even then I also get the same issues you describe. Very pink images and often with noisy lines in them.

I have ordered some TCM8230 chips and will be comparing the results to them later. Hopefully they work better.

Hopefully I will be allowed to release my linux driver for the NGW100 platformfor this camera so others can join in the debugging. The drivers have debugfs support and integrate with the V4L2 framework and ISI driver from Atmel allowing 20+ MHz input clocks without software intervention.
  • 1
  • 17
  • 18
  • 19
  • 20
  • 21
  • 31