Getting started with AVR-USB

[christian]

There are two issues with Automator:

1. 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.
2. The firmware is not transient-safe. If a transient triggers a false USB packet, little checking is done and the EEPROM may be overwritten. More status checking is required in usbFunctionWrite().

It is also true that PCs store all devices which have been connected so far. Devices are identified by VID/PID pair. They can be removed in the Device Manager.

[Rich]

ah right, will try attaching the zener diodes first.

with respect to issue 2:

would this stop the device from operating on all pc's? it currently works on one that we know of but not on others.

as we are using the supplied automator code could false USB packets occur?

regards

Rich

[christian]

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 with the supplied code. We have not yet identified the real cause, whether it's a hardware problem (brownout?) or whether it can be worked around in firmware (e.g. by parameter validation).

[Rich]

adding the two zener's did the job, havnt had any enumeration problems since and the automator appears to work on all computers.

i've just been having a go with the AVR-CDC - a USB to Serial Converter, the device attaches to pc's fine but the instructions on the terminal seem a bit strange. i've got some LED's hooked up to port C of the circuit and am jus try to get them lit using a command such as:

FF PORTC = (as specified by the readme + website)

my understanding is that this should set portC high and my LED's should light.

Im using Docklight V1.6 as my terminal. Initially i could only get the "!" character out of it which upon inspecting the code was a good sign as its the error character. now as the error code was being returned i wasnt surprised that the LED's didnt appear to be working.

i tried flipping the command strings in the terminal (= CTROP FF). i now get a return off of every command, however the data at an address always takes the value 08 or 00??? even after setting it to something else which appears to work correctly an give the correct error code.

does this project work properly? i cant see in the code where the later following PORT is checked and used? can you suggest a better terminal to use on windows? and any hints for making this project work? i cant see any good reason why it shouldnt be straight forward to implement.

regards

Rich

[christian]

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 Apple iBook running Linux), although I never implemented Osamu's original project. I used CDC in AVR-Doper, our AVR programmer. Others get consistent failures, sometimes after transferring several kB without error.

[Rich]

yeah i see what you mean. i'll have it working quite nicely with hyper terminal one minute and then the terminal crashes. noteably its always the 4th time i go to send a text file it always seems to crash on the open file dialog box. however putting the baud rate down to 110 appears to give consistent behaviour...not ideal really.

[Reza]

I have exactly the same problem as Rich. D you mind email me your libhid.a please.?


thank you

[christian]

No problem to mail you libhid.a, but I need your email address. Can you please get in contact with us through the support web form?