Objective Development Forums

Windows may have cached this info for your VID/PID pair. You can somehow flush that cache, but I'm not a Windows expert.

You need a USB host for that. V-USB is a USB device only.

You must look at the assembler listing and count the CPU cycles between every CLI and SEI instruction pair and the length of all interrupt routines until they either hit RETI or SEI. The longest count plus ~ 10 cycles is your maximum interrupt latency.

All driver versions should be compatible. Just drop in the new version in place of the old.

The code size exceeds the size of your AVR's flash, probably because the 12.8 MHz version is quite a bit bigger than the other versions of the driver. Your best option is to switch to the next bigger AVR.

Here are the code sizes of the driver for various options when you use gcc 3: Variation Flash RAM +F +RAM Minimum_with_16_MHz 1152 45 +0 +0 Minimum_with_12_MHz 1202 45 +50 +0 Minimum_with_12_8_MHz 1522 45 +370 +0 Minimum_with_15_MHz 1258 45 +106 +0 Minimum_with_16_5_MHz 1274 45 +122 +0 Minimum_with_...

And you will either have to run the AVR on 3.3 V or use zener diodes to limit the voltage on D+ and D-.

Of course. That's why the project is under GPL. The only requirement is that you put your modified version under the same license.

These errors indicate that you forgot to write your own code , or at least you did not include it in the compile. The compiler did not find your main() function and your usbFunctionSetup() function.

I can only answer the last of your questions: You can't build an MMC based data storage with V-USB because it's low speed USB only. Not only that it would be too slow, the standard does not allow bulk endpoints for low speed devices.

Please post the diffs here in the forum so that others who are interested can apply them. I'm not sure whether we should change the default implementation. I have tested it with most of the available 8 pin devices and am therefore reluctant to change anything. Our circuit has a only a programming so...

I doubt that it's an advantage to have the same configuration in the boot loader and the main application. You want to know whether you are talking to the boot loader or the main app, after all. It may be an advantage to use HID, though, since you need no separate drivers.

Using sei() as the first instruction of the interrupt routine is not the best solution. It's better to declare the interrupt with attribute ISR_NOBLOCK (macro which expands to the gcc atribute __attribute__((interrupt))). Gcc will insert the sei automatically as the first instruction of your handler...

It might be possible to use the main firmware for flashing firmware updates or it might be possible to re-use at least the AVR-USB part of the code in the boot loader and the main firmware. But it's much easier to sped 2k for a boot loader. These 2k are really worth the reduced complexity.

If you compile with -DDEBUG_LEVEL=0 or omit the define for DEBUG_LEVEL, all debug code is omitted. odDebugInit() emits code only if your debug level is at least 1. Having that said: You can of course omit the debug functions if you don't compile with debugging enabled.