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.
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.
Hi,
I started out with these settings which worked:
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.
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:
//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
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.
I posted a new lib here:
The 8230 I have done uses less pads under the chip to avoid shorting some of the other pads that are very close to the edge.
Hey all,
I’ve developed a new breakout board / interface to an FPGA starter board.
The board consists of the TCM8240 camera, as well as the Cypress Semi Cy768013A. This board then connects to the Spartan 3E starter kit via the board-board extension connector.
So far the camera is producing the proper full size MEGA images without JPEG. I’m currently working on getting the USB development suite set up on this PC (windows 7 driver problems argg). From using the cypress chip in the past it shouldn’t be too bad to get it working.
Cool tidbits about the board:
8 bit/48 Mhz interface to usb FIFOs.
All signals routed to the FPGA, including I2C.
Optional interconnection via header to connect USB MCU and camera’s I2C pins. Currently the camera is controlled by the FPGA.
If anyone is interested in the eagle files/pcb/or a built board, please let me know as I have 3-4 extras.
Sorry for the craptastic image, it was taken through a magnifying glass with an iphone 
Look forward to getting this working!
Chris](ImageShack - img0169r.jpg)](ImageShack - spartancam.png)
chrisjp, I have dropped the 8240 due to the craptastic images it has delivered. If you have settings that may solve my issue, I’d be veryy happy.
The AVR32 with linux appears to have no problems handling the data flow from the TCM8240 and my V4L2 integration appears to work well, but no matter what I do with the settings, I get over-exposed pink images that usually are off-centered or contain other black marks/divisions.
I have entire sets of images captured automatically as the settings are cycled and they all give horrible results. I may be able to post a video of the images tomorrow.
Has anybody yet found out, how to configure the cam to operate the TCM8230MD with 2.5V PVDD/IOVDD?
The datash**t :roll: says:
*If using 2.5V, must input setting command. (Default setting is 2.8V.)
I think :idea: they mean the SCMD register, which is a 20 bit register spanning from 2B to 2D. It’s all 0s per default except bit B2.
Also I wonder, how am I supposed to configure IO to a different voltage using IO with the wrong voltage :?:
I’d really love to power this device with 2.5V as I want to connect it to a FPGA (Spartan 3E) where I could power one bank directly with 2.5V and wouldn’t need level shifters.
Here’s a picture I took at 352x288.
I tried a tonn of settings and the best I ended up with gave this.
Here is a video (jpeg stream) from my TCM8230MD (Ignore the timing):
http://www.lilalinux.net/cgi-bin/ng-stream
The compression rate has been choosen so that it can be streamed via WLAN with 640x480@30fps from one of these quadrocopters:
Very nice lilalinux!
That looks like it is behaving much better than the TCM8240.
My breakout for the 8230 is done now and I am adjusting my TCM8240 V4L2 driver to allow avr32Linux support for the TCM8230 too.
Hey KreAture, lilalinux,
Can you share the I2C register settings you are using?
I am getting those pinkish pictures at all resolutions and even the color bar test screen has funny colors…
I am using the default YUV mode and use ImageMagick to display it.
Thanks,
Thomas
If your colorbar test patters look funny, you are using the wrong YUV or RGB interpretation. For RGB mode remember, the cam outputs GBR.
For YUV, check the doc, I don’t remember the sequence, but it is odd.
Here’s a pic from the tcm8230 btw:
http://kreature.org/ee/avr32/tcm8230/tcm8230_test1.png
The banding is probably noise from my poor interfacing. Looking into fixing that. (2.8v doesn’t talk well to 3.3v at 20 MHz.)
I’m using the cam in RGB mode and extend the 16 bits to 24 bits by mirroring the LSBs of each channel. e.g. if you have 5 bits 43210 you can extend that to 8 bits 43210012. That gives nicer results than just shifting and is cheaper to implement than spreading, as you don’t need arithmetics (especially no division).
For my TCM8230 I use only 3 registers and in this order:
02 : fps_30, acf_60, dclk_pol_normal, acf_det_auto
1e : d_mask, codesw_off, codesel_orig, hsyncsel_blanking, testpic_no, picsel_colorbar
03 : doutsw_on, datahz_out, picsiz_vga, picfmt_rgb, cm_color
KreAture:
For RGB mode remember, the cam outputs GBR
Oh yeah, I almost forgot about that!
KreAture,
I figured it is the UYVY 4:2:2 coding, but I guess this could be wrong. I’ll try shuffling this around a bit.
I saw some sort of banding too. But when I set DCLKP to inverse it worked. (I capture into a dualport BRAM in a Spartan6)
Thanks
Thomas
lilalinux,
Interesting expansion method! If I don’t get the YUV stuff to work I’ll try this.
Thanks for the registers! Makes all sense, but what did you set:
1e : d_mask to?
Thomas
I only change the bits I am supposed to.
My driver reads all registers off camera and stores em in a struct with bitfields.
Whenever I need to change anything I can adjust the values I want and write the reg back to cam. In some cases I read the reg from cam first, if it’s a flag that can change by itself.
I keep all values on default, in d_mask case it is supposed to be 01 I believe.
KreAture:
I keep all values on default, in d_mask case it is supposed to be 01 I believe.
Yes, d_mask is 01.
@linalux
Have you found the answer to 2.5V issue?
I’m having exactly the same problem
If it is the SCMD register, what value must it have for 2.5V, anything except
the default value ?
And can it be done starting from 2.5??
