Objective Development Forums

The simplest approach is to get one (or two) USBasp hardware boards and flash USBaspLoader on it. Then you can load a new program into the board and use it as a development board with I/O and USB. If you have two of these or one and another ICSP programmer, I'll post one that's configured and ready ...

USBaspLoader and variations allow this on devices with bootloader support (separate interrupt vectors for bootloader). I use such a setup all the time and it's great. Some allow various ways of entering bootloader: for a few seconds on device being plugged in, when reset is pressed, etc.

Yes, that was me helping a bit with your Pippin controller interfacing. I'd say that considering all the work I did to get V-USB working with something that required disabling interrupts, it would have made more sense to just use an atmega32u4 Arduino board that has hardware USB. I actually tried th...

That is crazy coincidental, I was just talking to a guy person that did the ADP keyboard thing, I was working with the pippin controller. Haha, that was probably me. This issues is with a UART. I'm well aware that USB for windows is 8ms apart, 2ms for linux and there are hacks for windows. Though I...

The ADB protocol involves signal edges as often as every 25us, and V-USB's interrupt handler can take over 100us (and is cycle-timed, so cannot be interrupted). This requires that we synchronize with USB interrupts and do ADB transactions *between* them. Even doing ADB using the AVR's capture and PW...

I thought that it was something like 27 cycles for an arbitrary disabling of interrupts. If you synchronize to USB packets, you can disable them longer. The keyboard I'm using right now is connected via V-USB with code that disables interrupts for almost 4ms every time it polls the keyboard. It's in...

The 1M pulldown resistor isn't something I see in V-USB designs. Also, I couldn't find a pinout for your USB connector to verify that you have D+ and D- connected as listed in the schematic. If these don't yield anything, I'd put a very basic USB project on it first. Even an LED blink to be sure tha...

Go back to the topic list and click New Topic and ask the question there. This will keep is from being mixed with this one.

Thanks for updating us. Interesting how you got away with it on the PC but not the hubs. Another piece of evidence of hubs being more picky, and one more reason for my personal avoidance of hubs.

V-USB has some hand-timed assembly code for each supported speed. Adding a speed requires new code. Also, I wasn't aware of 120MHz AVR microcontrollers.

Oh, I wonder whether it's the level-shifting zener diodes etc. Hub might be more picky about that too. Have you tried a minimal USB program on the Atmega in case there's some bug in the Midi adapter code? I think there's one that acts like a phantom key press that wouldn't need any external hardware.

Hubs can be more picky about timing. Are you using a clock crystal for the Atmega?

Get one of the basic vusb examples to see what all its makefile compiles in. You need at least usbdrv/usbdrv.c and usbdrv/usbdrvasm.S, as you're getting linker errors due to not linking these in.

I like your approach for when the mainline code might sit in some routine for a while and you don't want to litter it with calls to USB polling. I like it and will keep it in mind in case it ever is useful. What's the context where you have a USB keypad and something else significant that would hog ...

You definitely don't want to have the main loop call any USB functions if you also have an interrupt calling them, unless you ensure that any calls to vusb disable the timer during the call. As long as your timer interrupt is non-blocking (ISR_NOBLOCK) I don't see any problem. Do USB initialization,...