I'm an undergraduate member of a research team working on a project that involves an RF-transmitting ASIC, and its wireless receiver which should ultimately send data to a PC.
The receiver outputs a fast, continuous, asynchronous, non-standard serial signal (i.e. not SPI, I2C, UART, etc) so my job is to write microcontroller software to interface the receiver to the computer. Currently my approach is to use edge-triggered interrupts to place the data in a circular buffer and do the whole bit-by-bit decoding process in the main loop. The microcontroller must simultaneously output this data using USB (virtual com port) to the computer.
Here is a problem I'm having, and one I'm anticipating:
I can not process the buffered data fast enough even with my quite powerful 72 MHz ARM Cortex M3 processor. The bitrate is 400 Kbps (2.5 us / bit). For reference that leaves only 180 cycles per bit (including the decoding AND the ISR, which has ~30 cycles of overhead ouch!). The MCU also has to handle a lot of other tasks which it polls for in the main loop.
The USB virtual com port driver is also interrupt based. This makes me almost certain that the driver will eventually have the processor interrupted for so long that it misses the 2.5 microsecond (180 cycle) window in which a bit may be transmitted. I am unsure how interrupt conflicts/races like this are normally resolved.
So the question is simply, what might one do to resolve these issues or is this not the right approach at all? I'm willing to consider less software-centric approaches as well. For example, using a dedicated USB chip with some kind of hardware state machine for the decoding, but this is unfamiliar territory.