🢀 Back to programming guide
Once you have selected the hardware platform, you must decide which OS you will run on it. The options are:
Your choice of OS will be limited by which MCU/CPU or SoC you have chosen. Small, low cost MCU class devices (cortex M and similar) will usually only have enough flash, ram and processing power for a small RTOS and a well optimised application. With MCU class devices we have used FreeRTOS successfully, although Zephyr, Azure RTOS and others should also work fine. The core features of an RTOS that are required for a successful AVB endpoint development on MCU class hardware are:
!!! info The Sienda TSN Stack requires the standard C++14 library, so please consider that when budgeting flash and ram in your design. Newlib-nano may be used.
If your device is based on a slightly larger ‘MPU’ class device, such as a Cortex A, then you may have a greater choice of OS, as small embedded RTOS’s can generally run on such devices, but so can larger OSs such as QNX and linux. If you are using a multicore SoC then we would not recommend FreeRTOS, as FreeRTOS has no SMP support. We have successfully used TI-RTOS on multicore TI SoCs. It is also possible to run linux on such devices, and develop an AVB application to run on top, but you should be cautious of interrupt latencies and context switch times when doing so. You should carefully profile your system and measure the worst case interrupt latency and context switch times if considering linux. We have experienced worst case interrupt-to-handler-task latencies exceeding 62uS on some linux based systems. In comparison, most embedded RTOS’s achieve <4uS worst case interrupt-to-handler-task latencies, even on M4 devices!
If you are developing for a multicore desktop/server class processor (Atom, core i etc) then linux would be a viable option. Even if the worst case interrupt-to-handler-task latencies are high, there are probably enough cores and enough remaining CPU cycles to still do a lot of work. You should pay attention to the audio subsystem that you plan to use, and ensure that it can function reliably at a very low latency (ideally with 125uS half-buffers), and it should be able to generate an interrupt or signal on each half-buffer completion, which the application can use to drive the 8kHz system tick.
Another consideration in the RTOS vs. linux debate is overall system latency and AVB presentation time latency. If you are aiming for the lowest possible latency from AVB talker to listener output, then you need to process all AVB packets quickly, generally within 125uS of them arriving. If your application doesn’t demand such low latencies, then you can process AVB packets less often (in larger bunches), which relaxes the requirement of interrupt-to-handler-task latency slightly. Sienda can advise on OS and platform selection if required.