Apologies in advance for the newbie-ish question, and for re-posting on the BeagleBoard list (I had just sent this to the BeagleBone list - didn’t realize there were two separate lists).
I have an application where I’m reading in serial data stream with variable time between bits, and an unknown total number of bits(**). The data comes in as serial-data-in, and serial-data-clock. There’s also a serial-data-present signal that indicates that turns on just before the serial data transmission.
The quick hack I put together runs a fast loop in userland code that directly reads off the GPIO registers. This works ok, but I’m wasting a lot of time polling i/o. (Boo hiss.)
lf I was doing this with added hardware, I’d just slap on a programmable logic for serial-parallel shift register with a bit of extra logic to pad the final parallel word to “flush” the last bits before the data-present signal would turn off.
The most obvious approach is putting together a character driver that runs an ISR off the serial-clock edge to read the data-in pin, and output the data as series of 1’s and 0’s, plus additional characters for transitions of signal-present. And that’s probably good enough. (And that’s what I’m already working on.)
But it feels vaguely unsatisfactory. I’ve not fully grokked the OMAP documentation, but I feel like there must be a way to use edge-triggered DMA, or some other OMAP-hardware assistance (the DSP, perhaps?) to make the deserializer operate outside of the kernel’s interrupt timing latency/masking.
What I’m getting at is – is there a higher-performance BeagleBone / OMAP+Linux way to do this? I may be overkilling the problem, but it seems like I should ask the group for ideas on The Right Thing To Do.
Thanks!
** The variable timing is because the data ‘reader’ is operated by hand. The unknown number of bits owes to the analog nature of the front end generating spurious bits, which has to be post-processed from the data that was read in. The bits come in at around 4 kHz, but as low as 400 Hz, and up around 10 kHz. It depends on the data source, and the human operator. The analog world is so messy…