Posted on February 02, 2014 at 13:09> if we set a leading edge interrupt on the frame and toggle another gpio, it is rock solid and the signal matche
>
> if we turn off interrupts and sit in a loop reading the pin and doing the same toggle, it misses about 30% of the time
You need to understand, that these 32-bitters are not microcontrollers built for tight timing control, and definitively not from software. Rather, these are SoC, stitched together from various modules, bound together quite loosely as far as timing goes, with the manufacturers not caring to document these relationships (which are admittedly complex, far beyond a simple description). Think of a traditional control board, built from a processor, memories, various IO ICs, held together with some glue logic - all integrated onto a single piece of silicon.
What might happen at you is, that while interrupts have a fairly high latency, the interrupt signalling goes through a path separate from the data bus, i.e. its timing is independent from what happens on that bus, so that there are no conflicts on that bus which would alter the time until the interrupt servicing thus writing to the port happens. In other words, the latency is high, but jitter is low. This all given there is no jitter because of various timing of interrupted instructions (i.e. you run a null loop or similar), because of FLASH wait states/FLASH accellerator/jumpcache issues, other interrupts/DMA influence. In other words, your artificial test case might be unrepresenting of the real-program behaviour, unless you plan to have nothing else running in the mcu just that serial stream capturing.
On the other hand, reading from the port in a loop involves traffic through the AHB/APB bus, where there are synchronisation delays depending on the relative state of the two buses at the moment of reading. That might possibly explain some jitter. It's hard to say more without seing the actual code.
> we're using the stm32 lib, but i changed it to a simple loop that just inlines
> GPIO_ReadInputDataBit to the one IDR.
Oh, c'mon. If you want to go down to one-cycle timing level, C is not an option.
> DMA was our next thought. Currently reading over the datasheets/examples to set this up.
Yes, you want to avoid software as much as possible. OTOH, note, that DMA in itself is not panacea and has its sources of latency/jitter, too.
While others suggested here ideas, I would repeat mine, to use some timer's capture and transfer the captured value using DMA. It's hard to be more specific without knowing more of your application. It appears, that the original clock is unavailable, that there is more than only one leading sync pulse and more than 8 bits of data, and that you have already allocated the input pin... ?
JW
