How does one select an RTOS ? - Page 1
Forum section: electronics / general

author: metebalci
author_rank: Frequent Contributor
timestamp: December 04, 2023, 05:34:10 pm
content: I wonder the major factors that are important for selecting an RTOS. I am asking only for Cortex-M and similar level MCUs and considering only the ones with open source/free licenses but feel free to mention commercial ones. To have a more concrete question, I can ask, why/when should I not choose FreeRTOS, and why/when should I use X (mbed, rtx, apache projects, embOS, threadx etc.) ?

author: uer166
author_rank: Super Contributor
timestamp: December 05, 2023, 05:08:49 am
content: What is your application? More often than not an RTOS is not required, and it's overused "just because". That can end up as a very suboptimal choice for a project.

author: JPortici
author_rank: Super Contributor
timestamp: December 05, 2023, 05:51:24 am
content: I only used FreeRTOS, because it is the only RTOS that provided example projects for my architecture of choice, that i could use to verify it was actually working there. Also the only one that provided some RTOS debugging tools that talks with my IDE/Debugger (a state viewer, number of tasks, queue, timers and their status, memory occupied and address. Not much but that helped me debug a ton of things i couldn't have done otherwise, unless i would search variable by variable for the same information. And the OS's statistic functions are basically useless once a stack has overflown)I wouldn't mind trying something else to see if i like it better (ucos, or threadx/zephir as both seem to be all the rage for anything connected these days) but it needs the above for me to really consider it

author: SiliconWizard
author_rank: Super Contributor
timestamp: December 05, 2023, 06:06:21 am
content: FreeRTOS is the default choice indeed, it's relatively lightweight, well known and there's nothing much bad about it.I have used uC/OS in the past, but back when it was at an earlier version, and it required a commercial license. I don't know exactly how it stands now in terms of licensing. The source code is released with an Apache 2.0 license, but I don't know if they still have a commercial licensing scheme for commercial applications, something to check. The source code is there:https://github.com/weston-embedded/uC-OS3It's usually better regarded for "safety-critical" applications than FreeRTOS. Again, haven't had a look at it in a while. But I'd say it's an alternative worth a look.I would personally not touch ThreadX. Zephyr looks interesting, but much heavier than the two above and with a steeper learning curve.Of course, not everything requires an RTOS, so that's the first thing to settle before picking one.

author: eleguy
author_rank: Regular Contributor
timestamp: December 05, 2023, 06:31:14 am
content: We use Zephyr but as said above the learning curve is worse than a right angle and documentation is more than often in a miserable state when you actually need it. BUT, once you get something working which happens typically with the help of crawling source files and breaking out zillion undocumented macros it works for good. Maybe as a Linux guy I am bit biased to say but the Zephyr comes for example with the shell built in which is pretty cool and extendable.https://docs.zephyrproject.org/latest/services/shell/index.htmlI don't see reasons why one should not select FreeRTOS. I have used it as well (with ESP-IDF) and found it much more easy to approach than the Zephyr. However, I am not sure if it is fair to compare those two as is. The FreeRTOS is closer to the bare metal and the Zephyr towards the Linux world.

author: westfw
author_rank: Super Contributor
timestamp: December 05, 2023, 07:05:24 am
content: QuoteIf I were to select a "commercial" (or at least externally developed) RTOS, an important thing I would look for isportabilityto all the chips I'd be likely to use. That may sound simple, but it immediately disqualifies vendor-specific things like TI-RTOS. MBED-OS similarly does not seem to have much support for Atmel/Microchip CPUs (or any non-ARM architectures?) Similarly, do the chip vendors support the OS, or is it all from 3rd parties?Second is whether it supports peripheral "stacks" that I'm not interested in writing myself. USB? TCP/IP? Wireless protocols? (Vendor-proprietary wireless protocols, ie ROM or "required" SDKs.) Multi-core scheduling? Security features?Third is support and reputation of the OS and stacks...

author: eleguy
author_rank: Regular Contributor
timestamp: December 05, 2023, 07:35:03 am
content: Quote from: westfw on December 05, 2023, 07:05:24 amThis is the main reason why we selected Zephyr in the past. It did sound very tempting to have something "portable" in our hands. I just wanted to say that it does not come for free. It is possible unlike in the many vendor specific solutions but one really has to have a need for that. Pretty easily you are the one who is then writing implementation for the selected MCU. It is good to check (often misleading) Zephyr "supported list" page and notice at how "lightly" or well something is actually supported. Sometimes you find only very basic things like GPIO and UART in the list.

author: Siwastaja
author_rank: Super Contributor
timestamp: December 05, 2023, 07:48:30 am
content: Often the reason for any particular choice would be, "others made the choice". Maybe you want to use manufacturer example projects, and they use, say, Zephyr. I don't think anyone in their right mind would voluntarily choose Zephyr for a project they make from scratch with no such constraints.I usually do not use an RTOS at all, but have had no problems adapting into projects which use FreeRTOS; it's quite simple and does not force a completely different thinking pattern on parallelism; for example you can still write interrupt handlers.

author: metebalci
author_rank: Frequent Contributor
timestamp: December 05, 2023, 08:11:10 am
content: Thanks for the replies, really very helpful.I think I do not know the RTOS market share, who are the lets say top 3 or 5 and covering how much of the market ? Again, maybe I should say I am interested about not too small MCUs (definitely not smaller than Cortex-M0) and not large chips (definitely not bigger than the largest Cortex-M).Also, nobody mentioned embOS or Keil RTX, is it because they are commercial or they are not popular ?

author: shtirka
author_rank: Contributor
timestamp: December 05, 2023, 08:31:23 am
content: Quote from: metebalci on December 04, 2023, 05:34:10 pmHello,There are several factors that I usually use when choosing an RTOS for any of my projects (no matter if its open source or commercial):- RTOS ecosystem and support - how much support is there for an RTOS from the various tools like compilers and how easy is it to get the support from the original authors?- RTOS licensing model- RTOS source code distribution and modification constrains?- Does the RTOS need to be certified for a specific industry or application?- Performance?- Features?- Additional middleware components?- How labour intensive is it to integrate with current project?- Cost?- Will it make my life easier to solve a specific problem?- Is there a requirement for a minimum "effective throughput" that an RTOS can deliver (in comparison to other solutions)?Hope that helps you to get startedIlya

author: fchk
author_rank: Frequent Contributor
timestamp: December 05, 2023, 08:45:11 am
content: I had to choose an RTOS, and I ended up with NuttX.I wanted/needed a complete package with not only the kernel but also stacks and drivers for Ethernet and TCP/IP and USB, and I absolutely didn't want to mix and match products from different vendors for support reasons. This eliminated FreeRTOS, which in itself is only the kernel.

author: westfw
author_rank: Super Contributor
timestamp: December 05, 2023, 08:45:21 am
content: QuoteAh yes. One of the reasons that environments like Arduino are so important is that vendors need to catch engineers when they're "Playing."Because the number of times a company will delay for a couple of months while their engineers "evaluate" competitive architectures or chip families is ... very small. Most of the time you get stuck with "something compatible with the last thing we used" (which is much better than "something a sharp salescritter sold to middle management.")

author: Berni
author_rank: Super Contributor
timestamp: December 05, 2023, 09:07:20 am
content: Most often the best RTOS choice is none.You can do plenty of simple multitasking in a more efficient way using plain C with hot loops, state machines, interrupts..etc. So you don't want to get too comfortable with an RTOS where every problem starts to look like a 'multithreaded nail'.But there are some more complex applications where it does indeed make sense to have a RTOS where the simultaneous functionality is too complex to reduce down to functions that return in reasonable amounts of time. For that i like to use FreeRTOS because it is fairly simple as far as an RTOS goes while giving plenty of features and good support for pretty much any platform you would want to use.

author: AVI-crak
author_rank: Regular Contributor
timestamp: December 05, 2023, 09:33:31 am
content: Everyone should write their own OS, if only as an experiment.

author: tggzzz
author_rank: Super Contributor
timestamp: December 05, 2023, 09:53:36 am
content: Quote from: Berni on December 05, 2023, 09:07:20 amAgreed, but I would expand "multithreaded nail" to "pretending to be a simple linear flow of control but introducing different problems nail"

author: metebalci
author_rank: Frequent Contributor
timestamp: December 05, 2023, 11:16:37 am
content: I think I should have said this from the beginning, that I do not have an application in mind asking this question and I am aware RTOS might be unnecessary.A few people mentioned the peripheral support/stacks, which I had also in my mind. Not all, but I looked at some RTOSs, and it seems some of the peripherals are usually supported like network, but for example USB is not.

author: shtirka
author_rank: Contributor
timestamp: December 05, 2023, 11:55:32 am
content: Quote from: metebalci on December 05, 2023, 11:16:37 amAs far as I am personally aware, Apache's NuttX is one of the very few RTOSes (QNX is another example - but it is a closed source and commercial RTOS) out there where you also get inbuilt support for a variety of hardware and stacks, and not just a "naked" kernel.I will be speaking from my personal experience here (others may have other views on the matter), but generally speaking an RTOS is a tool you just dont use on a whim because there's only a very limited number of use cases where it truly shines (like when you need a highly deterministic system behaviour, or when you have strict demands on system performance or effective/maximum throughput) so using an RTOS will normally cause you more grief than it's worth (because usually it takes more effort to develop a solution to a problem or the solution becomes more complex than it needs to be - and also the system becomes more difficult to support in the long run). I would suggest you revisit my earlier message on how I would approach choosing an RTOS - at least as a starting point since your initial question on how to choose an RTOS was a bit theoretical and quite often a choice of an RTOS (or whether it should even be chosen as a tool to begin with since there might be an alternative way to solve a problem) would be very contextual for your project/team/organisation needs.Ilya

author: JPortici
author_rank: Super Contributor
timestamp: December 05, 2023, 12:30:07 pm
content: Quote from: metebalci on December 05, 2023, 11:16:37 amWell, USB is still pretty low level and it's usually easy to adapt the existing vendor stack to whatever RTOS. This is because you either process everything in a loop (and the loop just becomes a thread) or using interrupts and the whole thing is self contained. The most the RTOS has to do is manage the queues that exchange data from/to the endpointsIMHO you should just pick one that's supported by whatever hardware you have in front of you right now, compile the example project and see the LED blink.Of course there is MUCH MORE in writing a firmware using whatever RTOS than just knowing the API, but luckily major firmware offers also provide books to learn generic RTOS concepts alongside with examples (i like the RTOS and uC/OS ones)

author: tggzzz
author_rank: Super Contributor
timestamp: December 05, 2023, 12:31:00 pm
content: Quote from: shtirka on December 05, 2023, 11:55:32 amI don't disagree, but I will highlight that if you need "highly deterministic system behaviour" and "strict demands on system performance" then you need to look at much more than the RTOS.The best overall solutions I have seen forhardrealtime performance guarantees are FPGAs and XMOS' xCORE processors running xC. The RTOS is, to all intents and purposes, implemented in hardware,the IDEtells you the min/max code execution times (none of this "measure and hope you have bumbled across the worst performance" rubbish!), USB and Ethernet libraries, 4000MIPS MCUs, buy them at DigiKey.Example of hard realtime capabilities: software captures/generates 100MB/ Ethernetbitstreamsor USB comms, performance guaranteed while the processor isalsodoing all the interesting things with hard realtime guaranteesNaturally, as willalltechnologies, there are swings and roundabouts. I have found the devices fun and easy to program with no late surprises due to, say, errata sheets. I had my first capture+process+USB comms to PC application running within a day of receiving the boards.

author: metebalci
author_rank: Frequent Contributor
timestamp: December 05, 2023, 12:51:46 pm
content: Quote from: shtirka on December 05, 2023, 11:55:32 amThanks Ilya, great feedback.

author: metebalci
author_rank: Frequent Contributor
timestamp: December 05, 2023, 01:12:57 pm
content: Quote from: JPortici on December 05, 2023, 12:30:07 pmMaybe. I dont know what the USB stack in an RTOS provides, it might be easier to use.Quote from: JPortici on December 05, 2023, 12:30:07 pmThat is what I am doing at the moment, which made me question why I picked this one (FreeRTOS), hence the question.

author: metebalci
author_rank: Frequent Contributor
timestamp: December 05, 2023, 01:18:49 pm
content: Quote from: westfw on December 05, 2023, 07:05:24 amNot directly related to my question but is it common to make such a big change (change the architecture) during the lifetime of a normal product ?

author: 5U4GB
author_rank: Super Contributor
timestamp: December 05, 2023, 01:29:12 pm
content: Another comment specifically on the commercial-RTOS side, VxWorks for example is big and bloated and expensive but like Windows it's the 800-pound-gorilla that everything has to learn to play with, meaning that (almost) every bit of hardware and (almost) every device vendor has support with/for it. With open-source/volunteerish projects OTOH you either hope someone else has written the drivers you need and they're still current and maintained, or write them yourself. So it really depends on whether it's a small-scale/cheap/personal-project thing or a large-scale/heavy-duty commercial thing.

author: tggzzz
author_rank: Super Contributor
timestamp: December 05, 2023, 01:37:42 pm
content: Quote from: metebalci on December 05, 2023, 01:12:57 pmWell, in the XMOS ecosystem it provides an interface to a PC and/or IDE.Thus development: debugging, single stepping, peek/poke, etc. Deliverables: any GUI/logging you want your application to have on the PC. And all without disturbing the guaranteed timing of the hard realtime parts of your code. That's the wonder of multi-core MCUsWhether that is a benefit for you is for you to assess

author: gpr
author_rank: Contributor
timestamp: December 05, 2023, 01:57:45 pm
content: Quote from: Berni on December 05, 2023, 09:07:20 amSounds good for a simple hobby projects or as a learning experience. Or if you have very limited resources and trying to save a few kb of memory.In practice, implementing your own multitasking tends to become a chunk of spaghetti with subtle bugs and hacks, especially with multiple developers.

author: tggzzz
author_rank: Super Contributor
timestamp: December 05, 2023, 02:57:24 pm
content: Quote from: gpr on December 05, 2023, 01:57:45 pmEspecially when you factor in the effects of caches (and interrupts) on multi-threaded C code, written by typical developers, who apparently live inLake Woebegon

author: Siwastaja
author_rank: Super Contributor
timestamp: December 05, 2023, 03:39:11 pm
content: Quote from: metebalci on December 05, 2023, 01:18:49 pmYes and no. You don't switch MCU families like you change underwear, but having theoptionto redesign into different MCU while having anideathat "oh, it will take two weeks to port" instead of "I have no idea whatsoever, maybe month, maybe a year!?" is a great safety net.If you write your whole app to depend on features of an RTOS which is not available on different MCU family you have painted yourself into corner. Similarly, if you base your code into availability of vectored, priorized hardware interrupt controller with software interrupts available, like I usually do, this rules out some weird architectures without major modifications, too.Most important, by far, is the separation of your application logic and peripheral access, using good interfaces which make sense, so that rewriting the peripheral part is trivial. This is totally orthogonal to the RTOS issue. And BTW, this is exactly where stuff like "STM32 HAL" drives you in the wrong direction: now your whole codebase depends on ST's interfaces and you can't switch, not even to different STM32 families without doing modifications here and there as the underlying hardware leaks to the abstractions. What you can do, instead, is to write abstractions that match your application exactly, and then the underlying peripheral code is easy to rewrite.

author: metebalci
author_rank: Frequent Contributor
timestamp: December 05, 2023, 04:31:39 pm
content: Quote from: fchk on December 05, 2023, 08:45:11 amThanks for mentioning NuttX, I just tried it. I had something more similar to FreeRTOS in mind when I posted this topic, but NuttX seems different/almost like an OS and pretty interesting.

author: metebalci
author_rank: Frequent Contributor
timestamp: December 05, 2023, 04:35:32 pm
content: Quote from: SiliconWizard on December 05, 2023, 06:06:21 amWhen the application requires a certification or compliance, is a commercial product a must ? So things like aerospace, automative and maybe medical are mostly covered by the commercial vendors ?

author: eutectique
author_rank: Frequent Contributor
timestamp: December 05, 2023, 05:11:28 pm
content: Quote from: metebalci on December 05, 2023, 04:35:32 pmIf you want to certify your product (hardware and software) for safety and don't have a certificate for an RTOS yet, you would need to certify that RTOS as well.Good luck.

author: shtirka
author_rank: Contributor
timestamp: December 05, 2023, 08:11:17 pm
content: Quote from: tggzzz on December 05, 2023, 12:31:00 pmI will admit that I may have been perhaps a bit too categorical in my wording - perhaps I should have just said "deterministic behaviour" and "a bit higher effective throughput than you can achieve if you are sloppy" since in quite a few projects you still have quite a bit of leaniancy that would still allow the microcontroller+RTOS combination (where an RTOS may well also act as a bit of a "glue" or perhaps for managing the project complexity as well as increasing the performance) rather than going all in on it like in commercial/military aviation. So I guess this is part of the overall "context of applicability" of an RTOS - the part of the problem here being that the original question was a bit theoretical to begin withIlya

author: tggzzz
author_rank: Super Contributor
timestamp: December 05, 2023, 08:27:51 pm
content: Quote from: shtirka on December 05, 2023, 08:11:17 pmUnderstood and accepted. I deliberately pushed the interpretation of the phrases beyond your intended meaning.Nonetheless, it is useful to appreciate the limits and whatcanbe achieved by using non-mainstream technology. If nothing else it concentrates the mind on what ordinary mainstream technologiesdoesn'tachieve.Whether it is worth pushing to achieve such limits is a separate issue to be decided on a case-by-case basis

author: cv007
author_rank: Frequent Contributor
timestamp: December 05, 2023, 08:54:13 pm
content: Azure RTOS is/was licensed by manufacturers, such as stm32, microchip, nxp, renesas, and will soon become Eclipse ThreadX-https://techcommunity.microsoft.com/t5/internet-of-things-blog/microsoft-contributes-azure-rtos-to-open-source/ba-p/3986318https://threadx.io/I briefly tried it on a Renesas RA series mcu and it seemed ok to me (meaningless). It is pretty lightweight, and was not hard to use. I also tried FileX and I guess it gives you an alternative to FatFS with maybe a better way to deal with exFat with respect to licenses.

author: SiliconWizard
author_rank: Super Contributor
timestamp: December 05, 2023, 09:01:44 pm
content: Quote from: metebalci on December 05, 2023, 11:16:37 amYes, actually many network/radio stacks not only support RTOSs (often at least FreeRTOS), but often are not usable (at least without going through gigantic hoops) without one.Which is a pretty common reason, from ME, for people to start using some RTOS. Just to be able to use a network or radio stack. And they build from there.It's an "ecosystem" matter. Just like when people choose a programming language because of some available libraries, and then they build everything around it.

author: shtirka
author_rank: Contributor
timestamp: December 05, 2023, 09:31:22 pm
content: Quote from: tggzzz on December 05, 2023, 08:27:51 pmThat's exactly it! And also one of the potential issues (this isnt something that I have personally come across because I dont mix C++ and RTOS concept - at least to the point of it becoming an issue) is the use of C++ exceptions in an RTOS (at least this is something that can potentially cause issues in FreeRTOS): apparently they can cause havoc with deterministic behaviour on an RTOS because of how compilers treat them (I dont remember the exact details of that, but I can certainly dig up the link to that discussion should you wish to). So you do need to be aware of not just of the context of applicability of an rtos as a tool but also of any potential issues in order to avoid a potential mess (which could be epic)Ilya

author: Smokey
author_rank: Super Contributor
timestamp: December 05, 2023, 09:37:58 pm
content: I've always selected the RTOS because it was dictated by the built in vendor stack I had no control over anyway.If I wanted the have the BLE functionality of the chip I selected I was going to use freeRTOS. End of story.

author: tggzzz
author_rank: Super Contributor
timestamp: December 05, 2023, 10:00:00 pm
content: Quote from: shtirka on December 05, 2023, 09:31:22 pmI played around with C++ in 1988, and quickly decided that it was more trouble than it was worth. The alternatives were better: C, Smalltalk, Objective-C, later Java.For more "fun" with C++, the FQA (frequently questioned answers) is entertaining and very pointed.https://yosefk.com/c++fqa/The C++ mob tend to squeal that it is out of date, but many.most of the points are still valid. yes, both Tektronix and HP built test equipment with embedded and/or headless SmalltalkC tended to be used for the "boring" low-level hardware interface.

author: westfw
author_rank: Super Contributor
timestamp: December 05, 2023, 10:19:58 pm
content: QuoteOver the life of a single product? Probably not.Over the span of am emgineer's career at a company? Yes.Lots of companies transitioned from CISC to RISC processors, or to x86 as competing high-end CPUs died out. (Consider Sun, or Apple.)And lots of microcontroller-sized applications are now looking at the transition from 8bit to 32bit architectures (probably the only thing that makes an RTOS worth considering!)Not that having to switch to a different programming paradigm isn't "good for you." :-)

author: metebalci
author_rank: Frequent Contributor
timestamp: December 06, 2023, 03:40:46 am
content: Quote from: cv007 on December 05, 2023, 08:54:13 pmThis is a pretty big news.

author: Siwastaja
author_rank: Super Contributor
timestamp: December 06, 2023, 06:55:24 am
content: Quote from: SiliconWizard on December 05, 2023, 09:01:44 pmYeah. External libraries which are written using linear code flows that assume multithreading is the #1 reason to use an OS which implements such threads. Own code can be written event-driven (e.g.: state change is an event) so that it runs in interrupt handlers, but modifying a large library to fundamentally different tyoe of impelemtation is a gigantic task, especially given that event-driven code is sometimes more tedious to write, although it offers inherent possibilities to log state changes etc. and as such in many ways is more understandable than many pieces of parallel linear flows that mutex on each other.

author: SiliconWizard
author_rank: Super Contributor
timestamp: December 06, 2023, 07:31:33 am
content: Yep. Network stacks are typical examples, but FatFs is another example (I remember having talked about it before). As all calls are blocking, if you're not using some kind of preemptive OS, it can be a royal pain to use without causing various issues elsewhere, or otherwise having to hack your way around it in very (IMO) ugly ways, such as calling your own "idle" function inside FatFs callbacks - yuck. No thanks. That's actually one reason I wrote my own (ex)FAT library for SD cards rather than use FatFs.

author: tggzzz
author_rank: Super Contributor
timestamp: December 06, 2023, 08:49:25 am
content: Quote from: Siwastaja on December 06, 2023, 06:55:24 amExactly.Newbies often don't recognise the differing characteristics and relative advantages/disadvantages of FSM vs "conventional linear" flow.Choose the right tool for the job, and don't try to sharpen a hammer so it can be used with screws

author: 5U4GB
author_rank: Super Contributor
timestamp: December 06, 2023, 09:35:59 am
content: Quote from: gpr on December 05, 2023, 01:57:45 pmIt's not so much the multitasking that adds value, its the device drivers and protocol stacks that come included. I could quite happily live with little more than a single task, just a tight control loop that does everything, if in return I get someone else's device drivers and protocol stacks thrown in.

author: 5U4GB
author_rank: Super Contributor
timestamp: December 06, 2023, 09:41:03 am
content: Quote from: Siwastaja on December 05, 2023, 03:39:11 pmThis was particularly apropos a year or two back when a response to "we want to order another 50K of xyz" would often be "sure, there's a 70-week lead time*** on that and you're #726 in the queue", at which point being able to switch to whatever happens to be available that doesn't have a 70-week lead time becomes a huge benefit. I don't know how many redesigns I witnessed or was affected by at that time due to previously jellybean parts suddenly becoming unavailable, thus my earlier comment about the downsides but also the benefits if you need them of something like VxWorks.*** It was always given as 52 weeks but never really was 52 weeks, I think that's just as far out as the unavailable-meter went.

author: 5U4GB
author_rank: Super Contributor
timestamp: December 06, 2023, 09:48:51 am
content: Quote from: metebalci on December 05, 2023, 04:35:32 pmFor that you're going to be going with highly specialised RTOSes like ARINC653 ones or AUTOSAR stuff, alongside equally specialised development processes (have a look at the MISRA docs for an example of the automotive case) and running on top of equally specialised hardware, so unless you're at least a moderate-sized enterprise that's not really something you'll be playing with.The one exception might be the FreeRTOS -> SafeRTOS upgrade path, but then getting that certified/approved is a lot more work than just retargeting your FreeRTOS project to SafeRTOS.

author: metebalci
author_rank: Frequent Contributor
timestamp: December 06, 2023, 01:28:25 pm
content: Quote from: 5U4GB on December 06, 2023, 09:48:51 amI know MISRA, but first time heard ARINC and AUTOSAR, thanks for the info.When you say specialized hardware, do you mean redundant hardware components or something else ?

author: 5U4GB
author_rank: Super Contributor
timestamp: December 06, 2023, 02:43:16 pm
content: Quote from: metebalci on December 06, 2023, 01:28:25 pmI mean SIL/ASIL-compliant SoCs. They're interrelated, SIL = safety integrity level, ASIL = automative safety integrity level, another equivalent being DO-178C design assurance levels for avionics. So you'd be required to use, for example, an ASIL-D compliant SoC, and a full headache's worth of design assurance, for automotive systems like brake control where failures can be catastrophic, but only ASIL-B for things like headlights. ASIL-B is also the point where the effort and cost required goes from annoying to painful, so staying within ASIL-B is a useful goal.In practice this means things like dual cores in lockstep that cross-check each other, ECC on everything, lots of diagnostic and self-checking circuitry, isolation of functional units, massively overengineered clock and power subsystems, etc. For an example, look at the TI TMS 570 SoCs, they're quite nice because you can buy their LaunchPad dev kits with an ASIL-D certified SoC for pocket change compared to what other devices will cost you.

author: metebalci
author_rank: Frequent Contributor
timestamp: December 06, 2023, 03:12:33 pm
content: Quote from: 5U4GB on December 06, 2023, 02:43:16 pmMany thanks for the detailed answer.