(Egg on face -- I meant to say exaHz-class processor, not attoHz :-) ) --Andrew
-------------------------------- Andrew E. Kalman, Ph.D. On Sun, Apr 25, 2021 at 12:02 PM Andrew Kalman <[email protected]> wrote: > Just a comment on real-time programming. > > Obviously the accuracy of the real-time performance is a function of the > hardware/software system's clock speed -- if you have an attoHz-class > microprocessor (MCU), most things are going to look real-time to most > people (except time nuts, of course :-) ) no matter how they are coded ... > > In the real world, where clocks are usually in the MHz range, you can > achieve the real-time performances of your hardware (say, of a 32-bit > output compare timer peripheral or a 12-bit DAC) as long as the overlaid > software does not interfere with the peripheral's proper functioning. With > a "set-and-forget" peripheral that is easy. With one that e.g. needs to be > "fed" by the overlaid software (say, a DAC that is fed by DMA from data > coming from outside), that is a bit more difficult. And if some of that > real-time performance needs to happen in a task, then you really need a > couple of software architectural features to get you there. > > As an example, an MCU-based system that uses queues to manage priority is > not going to achieve real-time task performance, because e.g. the time to > enqueue a task will not be constant-time, and it will thereby introduce > timing jitter into the execution of all tasks. If, OTOH, in this example > the queuing mechanism were implemented via a hardware timer and ISR that > handles queueing via a an array (so that the queuing algorithm is > constant-time), AND that ISR is elevated to the highest priority, then the > task jitter in that system will be rather minimal, subject only to time > deltas due to the system serving any other interrupts (regardless of > interrupt preemption, etc). I.e. if the MCU is serving say a UART interrupt > when the "main" timing interrupt occurs, either the system has to (HW) > context-switch out of the UART interrupt to go service the timer ISR (and > (SW) context-switch), OR it has to wait for the UART ISR to end, before > servicing the timer interrupt. In the former, jitter will be a function of > the MCU's interrupt handling; in the latter, it'll be a function of your > code. > > While hardware preemption is always your friend, software preemption (in > the general case) is not a panacea. For example, in a preemptive RTOS, > every context switch is going to involve an interrupt. That "extra" > interrupt will affect the responsiveness and jitter of your other > interrupts. A cooperative RTOS does not involve any interrupts when > context-switching, and so (from one of several perspectives), a cooperative > RTOS (that in theory is not as responsive as a preemptive one) may in fact > yield certain better real-time performances than a preemptive RTOS. > > So, bottom-line rule of thumb: if you want to get minimal timing jitter > out of an MCU application, it is possible to run an RTOS (of any sort, most > are soft real-time, very very few are hard real-time) on that MCU, and with > careful attention to how you architect the system split between hardware > peripherals and firmware on the MCU, you can get to the exact hardware > timing specifications of the MCU itself. IMO the use of an RTOS makes a ton > of sense here, because you can e.g. implement a complete GUI, comms system, > terminal or other as part of the MCU application, safe in the knowledge > that all this "RTOS overhead" has _zero_ impact on the real-time > performance you hoped to get out of the MCU. This does require careful > coding in certain areas ... > > I am a huge proponent of loosely-coupled, priority-based, event-driven MCU > programming. Assuming it's coded well, it is not incompatible with > nearly-real-time programming. For high-performance MCU programming, I > generally follow these rules: > > - For 1-to-100-instruction-cycle timing accuracy, use straight-line > (uninterrupted) instructions (Assembly, or C if your compiler is good) > while interrupts are disabled. Here, your jitter is your fundamental clock > jitter as it passes through the MCU. > - For 100-to-1000-instruction-cycle timing accuracy, code it using an > interrupt. Here, your jitter is dependent on the interrupt handling of the > MCU. > - For greater than 1000-instruction-cycle timing accuracy, hand it > over to the (properly configured) RTOS. Here, your jitter is dependent on > how the foreground (interrupt-level) vs. background (task-level) code > operates in your application. > > > --Andrew > > -------------------------------- > Andrew E. Kalman, Ph.D. > > > On Sun, Apr 25, 2021 at 7:14 AM Lux, Jim <[email protected]> wrote: > >> On 4/25/21 6:40 AM, Bob kb8tq wrote: >> > Hi >> > >> > >> >> On Apr 25, 2021, at 9:31 AM, Lux, Jim <[email protected]> wrote: >> >> >> >> On 4/25/21 6:02 AM, Bob kb8tq wrote: >> >>> Hi >> >>> >> >>> The thing that I find useful about a GPS simulator is it’s ability to >> calibrate the >> >>> time delay through a GPS based system. In the case of a GPSDO, there >> may be >> >>> things beyond the simple receiver delay that get into the mix. >> Getting the entire >> >>> offset “picture” all at once is nice thing. Yes, that’s a Time Nutty >> way to look at it….. >> >>> >> >>> So far, I have not seen anybody extending this sort of calibration to >> the low cost >> >>> SDR based devices. Without digging into the specific device, I’m not >> sure how >> >>> well a “generic” calibration would do. Indeed, it might work quite >> well. Without >> >>> actually doing it … no way to tell. >> >>> >> >>> So if anybody knows of the results of such an effort, I suspect it >> would be of >> >>> interest to folks here on the list. >> >>> >> >>> Bob >> >> >> >> A double difference kind of relative measurement might be useful - >> compare two (or three) GNSS receivers. Then the absolute timing of the >> test source isn't as important. >> > Well …. it is and it isn’t. If you are trying to get “UTC in the >> basement” (or even >> > GPS time) to a couple nanoseconds, then you do need to know absolute >> delays >> > of a number of things. Is this a bit crazy? Of course it is :) >> > >> > Bob >> > >> Good point.. >> >> For many SDRs, it's tricky to get the output synchronized to anything - >> a lot were designed as an RF ADC/DAC for software SDR (like gnuradio). >> The software SDRs are sort of a pipeline of software, with not much >> attention to absolute timing, just that the samples come out in the same >> order and rate as samples go in, but with a non-deterministic delay. >> Partly a side effect of using things like USB or IP sockets as an >> interface. And, to a certain extent, running under a non-real time OS >> (where real time determinism is "difficult programming" - although >> clearly doable, since playing back a movie requires synchronizing the >> audio and video streams ). >> >> If your goal is "write software 802.11" you don't need good timing - the >> protocol is half duplex in any case, and a millisecond here or there >> makes no difference. >> >> A SDR that has a FPGA component to drive the DACs might work pretty >> well, if you can figure a way to get a sync signal into it. One tricky >> thing is getting the chips lined up with the carrier - most inexpensive >> SDRs use some sort of upconverter from baseband I/Q, and even if the I/Q >> runs off the same clock as the PLL generating the carrier, getting it >> synced is hard. >> >> The best bet might be a "clock the bits out and pick an appropriate >> harmonic with a bandpass filter". If the FPGA clock is running at a >> suitable multiple of 1.023 MHz, maybe this would work? Some JPL >> receivers use 38.656 MHz as a sample rate, which puts the GPS signal at >> something like 3/4 of the sample rate. >> I'd have to work it backwards and see if you could generate a harmonic >> that's at 1575... >> >> >> _______________________________________________ >> time-nuts mailing list -- [email protected] -- To unsubscribe >> send an email to [email protected] >> To unsubscribe, go to and follow the instructions there. > > _______________________________________________ time-nuts mailing list -- [email protected] -- To unsubscribe send an email to [email protected] To unsubscribe, go to and follow the instructions there.
