Objective Development Forums

If Windows does not quote the device name, there's a fundamental communication problem. Are you sure you have flashed the fuse bits? And do you use the voltage regulator? Not all hosts understand 5 V levels on the USB Data lines.

It uses the standard HID driver on the host side. No kernel level driver is required.

There is no (easy) way to port it to 89Cxxx controllers since these have a different instruction set.

And are you sure you have changed the makefile to compile for the right target?

We have not tested AVR-USB with the ATMega128 yet, but I see no reason why it should not work. If there would be any address range problems, the compiler or assembler should print an error or at least a warning.

Have you checked the obvious things: ⋅ Are the fuse bits configured for external crystal oscillator? The default is the internal RC oscillator. ⋅ Might the I/O pins used for D+ and D- be used for alternate functions? ⋅ Do you get any warnings from the compiler or assemb...

Simply use D0 for D+ and another bit for D-. Newer versions of AVR-USB accept any bit numbers for D+ and D-.

We have released a new version of AVR-USB today. The essential changes are: ⋅ Code size improvements. The driver is now more than 100 bytes smaller. ⋅ No more alignment requirements for the usbRxBuf variable. ⋅ The entire driver an all our reference projects are now pub...

The value is an "educated guess". Anything between 30 and 100 Ohms should work well enough.

No, at least not easily. The mkII USB interface uses bulk endpoints. And bulk endpoints are the problem why serial emulation mode is somewhat instable.

1.5 Mbit is the bit rate on the physical layer. The actual data rate is MUCH slower for low speed devices. The spec mentions something between 30 to 40 kBytes/s, as far as I remember.

For actual speeds achieved with AVR-USB, see the thread "How fast is Software-USB".

USB hosts must support at least Full Speed, that's 12 Mbit. Much too fast for a firmware-only implementation on the AVR.

AVR-CDC is a bit problematic because it goes somewhat beyond the USB specification. If you look at Osamu's documentation, you'll see that the device does not work with all PCs and operating systems. I had good experiences with my hardware (an Apple iBook, a PC notebook running Windows XP and an Appl...

I've checked the latest version (2007-02-01). The hex file shipped with it was compiled for the Mega8.

The remaining checks are:

• Make sure that the fuse values are correct.
• Make sure that you have the zener diodes at D+ and D-.

Issue 2 is independent of the PC. The effect is that you store a sequence, everything works well and you leave the site. After two weeks you get a call that it stopped working. When you look at the contents of the EEPROM, parts of it have been overwritten with simple patterns. This problem occurs wi...

Looks like a very fundamental problem to me. Have you flashed the fuses? Have you connected the zener diodes at D+ and D-? And have you compiled for the right device (ATMega8 vs. ATMega88)?

The operating system is Linux, right?

There are two issues with Automator: ⋅ The first version of the circuit did not have zener diodes on USB D+ and D-. On some PCs and hubs, this exceeds the common mode range of the input driver. Simply add 3.6 V zener diodes at D+ and D-, directly at the connector pins. ⋅ The firm...