4 ms·
In my experience, RTEMS works great if your scheduling/timing is in the ms-range but if you need precise timing in the us-range, especially on smaller MCUs, the
by okl 4y ago
In my experience, RTEMS works great if your scheduling/timing is in the ms-range but if you need precise timing in the us-range, especially on smaller MCUs, then you will run into lots of trouble with jitter from different sources, for example because certain timers are checked sporadically, messing with your cache. I don't know if the situation has improved since then.
- adrian_b 4y agoI believe that what you say is correct when you use RTEMS with one of the existing BSPs, with no changes. Because RTEMS is open-source and also because its internal structure is many orders of magnitude easier to understand than that of something like Linux, or even of some *BSD, extreme customization can be done with relatively modest work. When you do not need them, it is easy to remove completely the implementations of many parts of the API and of many classes of kernel objects, to obtain a much leaner RTOS kernel. Any causes of jitter from the kernel or device drivers (if they occur in higher priority tasks, as the lower priority tasks should not be able to interfere) should be relatively easy to identify and patch. I have used once RTEMS for an application with many channels of synchronous multiplexed telephony, with very tough jitter requirements, and there have been no problems, but it was not RTEMS out-of-the-box, it was customized for the application, i.e. with about half of the kernel removed, a new interrupt handler added, and with custom device drivers.