Breadboarded AVRcam Experiment

[ryan]

Hey all,
I'm trying to develop a totally breadboarded version of the AVRcam, so I'm plugging all of the components into breadboard for development. It's a daunting task! The first problem that I have run into is simply communicating with the AVR. I think it's a clock/baud issue because I'm getting junk back from the UART port of the AVR. Which means that the AVR is trying to send something but its rate is not correct. All of the parts are straight from component suppliers without firmware or settings of any kind so I have to set my own fuses for the clock options.

I am wondering what exactly should be the fuse settings for the Mega8 and the Tiny12? (High Byte + Low Byte for CKOPT, CKSEL, SUT, etc.)

I see in this thread http://www.jrobot.net/Forums/viewtopic.php?f=2&t=219&p=576&hilit=fuse#p576 that John said it should have "only the CKOPT bit asserted". For fuses does that mean lowbyte=0xFF and highbyte=0xEF? This does not seem to make any sense since this would disable the SPI for in-circuit-programming. So what should my bytes be? (I also tried highbyte=0xCF to no avail as well.)

You can check the values with the AVR fuse calculator here:
http://palmavr.sourceforge.net/cgi-bin/fc.cgi?P_PREV=&P=ATmega8

And fuses for the tiny12? What should they be?
Also- I've substituted a Tiny13 for the Tiny12, do you think this could cause any problems?
Thanks!
R

[ryan]

Any ideas?
-R

[johno]

Hi Ryan,
Indeed, I can imagine trying to build an AVRcam on a breadboard could be a daunting task...I wish you luck On to the questions...

The OV6620 is responsible for providing the clock source for the mega8. The OV6620 will output its clock signal (at 17.7 MHz) on one of its output lines, but it doesn't do this by default. This is where the tiny12 comes in. Its sole purpose in life is to send an I2C command to the OV6620 at power-up so that the OV6620 will output its 17.7 MHz clock signal for use by the mega8. The UART timing on the mega8 depends upon this signal being present.

Yes, the only fuse that should be asserted is the CKOPT fuse (indicating an external, rail-to-rail clock signal will be provided, i.e., the signal I mentioned above). All the remaining fuses are not asserted. I usually do the fuse programming with PonyProg; in PonyProg terms, the only fuse with a check-mark is the CKOPT fuse.

The fuse settings for the tiny12 are the factory default (I don't recall what they all are, but simply leave them as is). I don't see why a tiny13 couldn't be made to work, though I haven't played with the tiny13s. It may just take some minor code tweaks.

Good Luck,

[johnd]

I'm doing something similar and use lfuse = FF, hfuse = CF and it seems pretty happy.

If you're using a white plugboard type of breadboard you might have some problems with the high frequency. I'm using a perfboard with point to point wiring and don't seem to have any problems. Copper tape makes a good quasi ground plane, though I'm not too picky about coverage. It makes power and ground distribution pretty clean.

I also pulled the crystal off the 3088 board and put a 16 MHz one on the mega8, undefined the crystal define and recompiled. The Xtal2 line has to be routed to the 3088 socket of course, but that allows the tiny 13 to be eliminated. Probably a good tradeoff if you're only making a few.

If you're downloading a prebuilt hex file from jrobot the comments below aren't relevant, but if you're compiling from source with a recent version of avr-gcc there might be some minor glitches.

Compiling with avr-gcc 4.2.2 with the default optimization of 1 caused a problem. ( this was with the stock AVRcam, current UBUNTU ) I could get the board to do one capture, then it went stupid on me and had to be power cycled. I didn't have a good way of diagnosing the problem, so I'm not sure what was going on. Eventually I tried an optimization of 2 and it seems to work fine.

There are a few library header references (signal.h I think) that have become obsolete, and one warning about signed/unsigned in the serial input .c file. There's a problem with coff conversion, but since I don't plan to use the debugger I just don't do it. Otherwise the make file worked pretty well.

I've used the stk500 with the 10 pin ribbon cable for incircuit programming with no problems over the years. AVRdude likes it fine.

Serial ports are hard to come by around here, so for the breadboard I'm using a UM232R USB adapter from FTDI. It's pretty much the FTDI FT232RL chip with a couple of jumpers. Just connect it to TX/RX and power and you should be talking (under WinXp anyway)

Under my UBUNTU system the camera view program doesn't find the camera. It looks like there might be some permission thing going on with the X server, but I haven't looked in to it yet. I'll report in if I find anything useful.

- johnd