Using NEC 16 bit 78K0R-KG3 ~14.7 MHz (uPD78F1166) 256kb Flash / 12 kb RAM with IAR EW 4.62 and Minicube2 on WinXP SP3.
I have consulted the forum earlier regarding time critical issues in relation to handling asynchronous events (RX data to a UART at very high speed without flow control). As I understood it, the problem is inherent using an RTOS like FreeRTOS, and it was suggested to use the build-in DMA controllers to handle the low level data management. So far, so good – I made it work to a certain extend, but was forced to reduce the maximum allowed baudrate to 9600 bps.
Since then, another time critical problem has emerged. The product, I am developing, is required to automatically detect the baudrate of the incoming serial data and re-configure the internal interface. The NEC uC has clever array of timers, that can perform the basic parts of these measurements, but the more logic part of the operation has to be executed in an ISR routine. As one can imagine, the required resolution is a factor 10 higher than the actual baudrate (because I have to synchronize some of the operations within 1-2 bit times) – hence I was back at the original problem.
I have measured the maximum period FreeRTOS disables interrupts (with portENTER/EXIT_CRITICAL) toggling an IO to approximately 500 us – i.e. way more than a bit time for 9600 bps (~100 us). I find it rather difficult to find the actual function, which is responsible for this rather long “outage”.
That was the problem - now for the solution as I image it. Please feel free to comment:
My plan is to “bend” the meaning of portENTER/EXIT_CRITICAL. Instead of executing the assemble instruction “DI/EI” I will selective mask/unmask interrupt sources manually – and never mask my 4-5 ultra time critical interrupts. The interrupts do not in any way use any FreeRTOS API calls and will never require portYIELD_FROM_ISR to be executed.
The system will restore the processor registers and stack after an interrupt – I see no problem in implementing this concept.
I image, that this strategy cannot be implemented as a general behavior in FreeRTOS due to the inherent design differences across the supported micro processor platforms.