usbPoll() from a timer interrupt?

[guscrown]

I've been working on making a USB Keypad for a project I'm doing, and so far it is working fine. I decided to utilize timer1 to create a timer interrupt (overflow type) that triggers every 5ms. I use the interrupt to run the usbPoll() function for my keypad. Is this a bad idea? Is it just better to stick it in a forever loop where I'm scanning the keypad matrix?

My concern is what would happened if the timer interrupt happens when usbSetInterrupt is called.

[blargg]

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, enable timer interrupt and enter main loop. At that point it's just like the main loop is calling usbPoll(), as far as vusb is concerned.

[guscrown]

Thanks for the reply. I've been reading the example project's code and nobody does it like that, everybody is simply polling in the for() loop. Might as well use a proven method. In my mind guarantying a 5ms usbPoll() cycle would provide more stability to the system.

[blargg]

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 main loop time? I figure most code just polls from the main loop because it's not doing anything else as it's just a keyboard-to-USB interface.

[guscrown]

My main routine is not clogged at all, it's basically scanning the keypad matrix and sending the keypress data to the host, and that's it. I just thought it would be more elegant to guarantee a constant usbPoll() every x milliseconds if I did it with a timer interrupt.

By the way, since you have tons of more experience than me on v-usb; is there a way to confirm a correct USB enumeration? We've had other controllers in the past that fail to enumerate and they show up on the cost as VID 0000 and PID 0000 and the host can't do anything about it, until you physically disconnect the device. Is there a way to verify from within the AVR that the device was enumerated correctly, and then if not attempt re-enumeration?