Objective Development Forums

I was under the same impression (that the V types use the same silicon but are selected by parameters), but users reported that the same circuit works with a non-V type while it fails with a V type. This was at 16 MHz, as far as I remember.

The 12 MHz module needs the precision of a crystal, the 12.8 MHz module does not. The additional 0.8 MHz are spent for a software PLL. Regarding the conflict between table 7-6 and figure 24-35: The table documents guaranteed values, the diagram real, measured values. The diagram reflects reality ver...

You can still try to get it running with the 12.8 MHz module. This should work on devices rated at 10 MHz.

Yes, something is broken with this example. Don't know what, though. The data arrives at the AVR, as far as I remember, but it's not written to the EEPROM correctly.

Just modify the example to set some I/O pins instead. You'll see that it works.

Avoid CDC mode if at all possible. The transfer rate with AVR-USB is lower than with all other modes because it eats so much (AVR-) CPU time. And it's not compatible with many Linux kernels and Windows Vista.

If you enable the interrupt, you must supply an implementation for the vector. Otherwise the reset vector is called. Where in your code do you read the ADC data? If you don't need the accuracy of an interrupt, you may poll for it instead. Leave ADIE zero and check for ADIF regularly. If it is set, w...

There's nothing special with AVR-USB and free running mode of the ADC. It looks as if your code crashes, maybe because you enabled an interrupt which has no vector assigned or the vector is called recursively. If you need an interrupt for the ADC, you must make sure it enables global interrupts with...

As far as I know, Mac OS X does this if it can't identify the keyboard otherwise. You can just ignore this dialog if your keyboard does not have these keys.

Did you do a "make clean" after the change? There is no explicit dependency on usbconfig.h in Makefile.

You need to pass additional compiler flags. Most importantly: -DF_CPU=12000000 (or whatever your clock frequency is) and -Iusbdrv unless you move all the usbdrv files into your main source directory.

You also need to add the assembler file usbdrvasm.S to the project.

Just enjoy

You have found out most of the details yourself. R0 is used for temporary results and R1 should always be zero. If you make the routine naked, you have to push registers from inline assembler without knowing what to push. A new compiler version might assign registers in a different way. But at least...

Without looking at the details: I think the 12 and 16 MHz module have the same latency from start of interrupt to reading the first bit. It should therefore be OK to scale the 25 cycles with 16/12. This would be 33 cycles. You can probably reduce the number of pushes in your interrupt if you avoid s...

At how many cycles starts "too slow"? See the comment at the beginning of the respective assembler module. For 12 MHz: ;max allowable interrupt latency: 34 cycles -> max 25 cycles interrupt disable Your interrupt takes 3 cycles until it executes, 2 cycles for the jump to the vector and 18...

For USART_UDRE, you probably need to write an assembler routine. Executing sei() after resetting the pending flag might be too slow. But look at the disassembler listing to be sure. In an assembler routine, you may push only one or two registers, handle the pending flag and then execute sei. Btw, yo...