Hacker News Reader

Comment by kenz0r | Hacker News Reader

Serial interface, and GPIO reads are polled. Its a good first or second year uni project, but its not a product.

Sorry, just a curious passerby - why are those things bad?

Polling usually is not considered to be a real time method. To reduce latency it will consume unnecessary CPU cycle, I think

for the operating systems version of real time, i'd consider it polling to be real time. you ensure that part of your code will always take the same amount of time.

it actually is, as long as your polling interval is deterministic and meets the requirements of your target application (polling interval < state change interval).

If you look at real hardware (or FPGAs) they will basically do polling: The input gets sampled at each clock cycle and will then get processed. And hardware is definitely realtime :)

The downside of polling is that you burn CPU resources when actually nothing happens. Interrupt driven designs help there.

> If you look at real hardware (or FPGAs) they will basically do polling: The input gets sampled at each clock cycle and will then get processed. And hardware is definitely realtime :)

Smiley noted; I think we can agree that "polling at 10s of MHz on an input pin" becomes something quite different than "polling at 10s of kHz on the other side of a USB link".

USB link to a PC with a general-purpose OS likely kills the determinism requirement.

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.

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.

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

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

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.

There is nothing bad about it as long as one is aware of the limitations. A $25 hobbyist IO module is perfectly fine and fully appropriate for a fleeting appearance on HN.

Reply on news.ycombinator.com