[wkz]

The OS comparison table leaves me somewhat puzzled.

Contiki's "C Support" is listed as "partial" without any explanation. What does this even mean? It seems to me that this should be between you and your compiler.

Linux is supposedly "partially modular", whereas RIOT is fully modular. That's a bold statement.

I get that they are trying to differentiate their product. But without motivations, statements like these sound a bit hollow to me.

[fermigier]

Obviously one needs to provide bold statements to get people's attention these days. I guess the details and precise statements are in the research papers, such as:

http://riot-os.org/docs/riot-ieeeiotjournal-2018.pdf

[rcxdude]

Contiki uses protothreads, so I would class that as 'partial' C support, since you can't really use local variables (due to the hair-raising nature of how protothreads works).

[wkz]

TIL about protothreads. Thank you. That does indeed look hair-raising!

[anonymousDan]

Linux is a monolithic kernel for the most part, would seem to make sense to me without digging into the details.

[wkz]

I disagree. Sure, it is a monolith as apposed to a micro-kernel, i.e. everything in the kernel shares the same address space. But it is highly modular in that most drivers and filesystems can be dynamically loaded/unloaded.

[TickleSteve]

Dynamic loading and unloading of drivers in a single-purpose embedded system is not a good point.

In this level of devices, everything should be statically allocated for the worst-case situations. This is for reliability, simplicity, determinism, etc.

The space taken by the code involved in handling dynamic loading could be better used by giving you a cheaper, simpler, more reliable device.

What seems 'nice' on a desktop system is (in a lot of cases) inappropriate for a resource-constrained embedded system.

[ramzyo]

Interesting points, but have to challenge your strong assertions here.

1) Dynamic loading and unloading of drivers in a single-purpose embedded system is not a good point.

- Yes, but who said anything about Riot being used only for single-purpose embedded systems?

2) In this level of devices, everything should be statically allocated for the worst-case situations.

You seem to be conflating embedded systems with safety-critical systems. There are plenty of embedded systems that are neither safety critical nor single-purpose. Also, plenty of non safety-critical embedded systems use microcontrollers that don't have the resources (RAM) to run Linux effectively, even MMU-less Linux, but could benefit from dynamic loading and unloading of drivers for hot-plugging events to support external hardware/accessories.

3) The space taken by the code involved in handling dynamic loading could be better used by giving you a cheaper, simpler, more reliable device.

- For certain problems, sure. But I'd challenge your assertion that resource-constrained always equals single-purpose device where dynamic loading for things like hot-plugging events isn't useful

What seems 'nice' on a desktop system is (in a lot of cases) inappropriate for a resource-constrained embedded system.

- It's hard to argue this point with the caveat "in a lot of cases", but I'll try. What makes this inappropriate for resource-constrained embedded systems? Again, it seems you're conflating resource-constrained embedded systems with safety-critical embedded systems, where formal methods/functional verification/regulatory certification are necessary and therefore dynamic code loading/unloading isn't feasible

[TickleSteve]

Safety-critical systems imply a lot more than that, been there, done that.

Its an accepted, general premise in embedded systems to always avoid dynamic behaviour, that includes memory allocation, storage behaviour, etc. Implying that that kind of behaviour is only for safety-critical systems is not correct, its mainly for robustness and simplicity reasons. I would argue that it applies to the vast majority of embedded systems (prototypes excepted).

An embedded system is also (generalising again here) always single-purpose. By definition its a part of another system and you do not interact with the device itself, you interact with the system.

You could argue that not all embedded systems are resource-constrained (again, been there, done that). but typically for this level of system (i.e. microcontroller based), if you're not resource-constrained, you've not optimised your BOM cost and hence you're in prototype stage.

[pantalaimon]

RIOT does not allow dynamic loading and unloading of modules/drivers at run time. You can choose which modules/drivers you want to include at compile-time.

[wkz]

I never argued that it was. Though, "embedded" covers a wide spectrum of systems. For microcontroller-based projects, then no. For bigger SoCs paired with hundreds of MBs of FLASH/RAM it can be very useful.

My original point was that claiming that Linux is partially modular while RIOT is fully modular feels like a stretch to show N lines of red crosses and orange circles, followed by one line of only green check marks.

Linux's FLASH/RAM requirements are enough to disqualify it from projects targeted by RIOT, IMHO. No need to make dubious claims of limited modularity.

[PinguTS]

And in IoT some would not need a modular kernel at all. A monolith kernel would fit the purpose. Because an IoT device normally has a fixed purpose depending on the additional hardware. There is no plug'n'play requirement.

The only problem with the Linux kernel these days is its sizes. Because with Cortex M3/M4 processors we still have sizes constraints.