4 ms·

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

by wkz 8y ago

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 8y ago
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 http://riot-os.org/docs/riot-ieeeiotjournal-2018.pdf
anonymousDan 8y ago
Linux is a monolithic kernel for the most part, would seem to make sense to me without digging into the details.
- wkz 8y ago
  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.
  - PinguTS 8y ago
    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.
  - TickleSteve 8y ago
    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 8y ago
      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 8y ago
        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.
rcxdude 8y ago
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 8y ago
  TIL about protothreads. Thank you. That does indeed look hair-raising!

by wkz 8y ago

fermigier 8y ago

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 http://riot-os.org/docs/riot-ieeeiotjournal-2018.pdf

anonymousDan 8y ago

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

wkz 8y ago
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.
- PinguTS 8y ago
  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.
- TickleSteve 8y ago
  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 8y ago
    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 8y ago
      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.

rcxdude 8y ago

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 8y ago
TIL about protothreads. Thank you. That does indeed look hair-raising!