On Wed, Jul 29, 2020 at 2:35 PM Robert Faron <robe...@cmslaser.com> wrote:
> > Once I an get the system to boot I will need to be able to run a compiled > program. I assume I will have to rewrite my little linux test program using > nuttx. At it's simplest the test program can be hard programed to the > correct bar address given by uefi and since it is on it's own but, no other > devices are on bus 1, it should continue to be assigned the same bar > address. This test program will really be as simple as turn on isolated > bit, sleep, turn off sit, sleep again, repeat. This will allow me to test > for jitter, in a true RTOS the outputted square wave will remain > consistently the same. If the OS interrupts the process jitter will appear > and can be measured on an oscilloscope. On ARM, I am using Zero Latency Interrupts for the really critical (and not time-consuming) stuff. That would be things like sampling inputs and updating outputs. I haven't used NuttX on amd64, so I don't know how to implement that there. Zero Latency Interrupts (sometimes called unmanaged interrupts on other RTOSes) execute "outside" the RTOS. They interrupt whatever the RTOS might be doing (even if it's in a critical section). The disadvantages are: (1) They can't make any OS calls because the OS doesn't "know" about them. (2) No floating point in the interrupt because FPU context isn't saved. (3) A bit more conplexity. But (at least on ARM), there is pretty much ZERO latency. :-) Nathan
