[kenz0r]

Polling GPIOs is bad, because you miss events. Looking through the source code, the author has functions to get the state of GPIO pins, which send a command over the USB serial port, then read the output. This is fine for things that don't change very often, but if you've got a keypad, or something that may have a relatively short pulse width, you really want a notification that something has happened (GPIO 4 just transitioned from 0-1). The simple way of doing that for this project would be for the hardware to send a message when that happens - its easy to set up interrupts on the MCU, and then send a message back down the serial channel saying what happened. Latency won't be great, but you shouldn't miss things. The Serial interface (over USB) isn't too bad, but will add latency over a raw USB interface.

[8note]

You can still miss things -- you can only have so many interrupts fire at once. if all the pins change at the same time, you'll miss a few of em, especially if you're sending a serial message in the interrupt.

you're also more likely to get more than you want, and have to debounce on the processor side.

I'd go for a small fpga->ftdi usb controller. do a low pass filter on each pin, and when it goes above your threshold, throw it in a fifo that feeds the USB chip. your latency goes up with the number of changes that happen at once, but you're still using raw USB and not miss events that you're interested in.

[jononor]

Don't send serial messages in an interrupt, that is crazy. Just set a flag indicating what happened (or use a queue). Then in your main loop check the flag. If the loop is not able to clear it fast enough, report it as an error. You can handle signals at 100kHz+ with such a technique.

But yes, might very well want some configurable low-pass/debouncing logic.

[rezzo]

> I'd go for a small fpga->ftdi usb controller

Is there any specific product you can recommend for a hobbyist's project?