Objective Development Forums

This message means that your WinAVR installation is broken. Please check whether you can compile anything else.

Note that you cannot interrupt the USB interrupt! When the USB driver's interrupt is active, there's no way to perform higher priority tasks (unless they are implemented completely in hardware).

The USB driver stays active for an entire USB dialog: Request from the server and response from AVR-USB.

You replace the zeners with LEDs, no other change is required. However, you must use so many LEDs in series that the (measured) forward voltage is ~ 3.3 V. The LEDs must be in reverse direction compared to the zeners, since zeners have their breakdown voltage in reverse direction.

When you generate the signals from software (which may be required if you need more than one output), you get glitches from time to time when USB traffic interrupts the output pulse. The USB interrupt runs for ~ 100 microseconds and blocks all other activity during this time. This may be acceptable ...

No! I mean something like that (it does not work as described below, but you get the general idea): Configure timer 0 for PWM and enable the overflow interrupt. In the overflow interrupt routine (which enables global interrupts immediately, of course) set the PWM value to 0 so that no pulse is gener...

I didn't mean to use timer 0 in PWM mode. Use it to turn a port pin on or off (or leave it as it is) at a given count. This is rather complex, admittedly, but it should be possible. BTW: Servos have a dead range to avoid oscillation around the target position. This results in a resolution of ~ 100 s...

It IS possible, but I have not done this myself. There are some code examples here in the forum from people who used PCINT for USB.

Please note that you should not use any higher priority hardware interrupts than PCINTx.

If you compile from the source code, edit firmware/stk500protocol.c and change the constants /* The following versions are reported to the programming software: */ #define STK_VERSION_HW 1 #define STK_VERSION_MAJOR 2 #define STK_VERSION_MINOR 4 appropriately. The other issue: Don't know why there ar...

You can't disconnect and re-connect 50 times a second, the procedures take much too long for such a frequency. You also must not disable interrupts for more than a couple of cycles because AVR-USB MUST react within microseconds to a USB request. Your best option is to work on the PWM code. You can u...

2.2 kOhm may be too high. Did you check the voltage levels? Also make sure that your zener diodes are really low power types. You do use zeners, do you?

Setting DWEN to 1 disables it, setting it to 0 enables it. This is "fuse" logic: a logic 0 means that the fuse is "blown", 1 is the default state.

Some answers: (1) You can't call usbPoll() from a timer interrupt. You must call it from the main code. usbPoll() usually returns within microseconds, but since your usbFunctionSetup(), usbFUnctionRead() and usbFunctionWrite() routines are called from there, the maximum duration depends on your rout...

Adding to my comment from a year ago: An option for 16 bit message size has been added in one of the recent releases. This was necessary to allow descriptors above 254 bytes. You can now experiment with bigger messages sizes, if you like.

The exact value is not critical. 500 uH should work as well, or values up to several mH. As long as the 12 V are generated and are stable under a slight load, the inductivity is OK.

Probably not. If you don't have the right zeners at hand, you may consider LEDs in series which have the same forward voltage drop as the zener would have.