The report analyzes and compares, in a qualitative fashion, existing
operating systems eligible to power IoT devices, to conclude that none of
them is appropriate to serve the whole spectrum of devices/requirements
making the IoT. The report thus motivates the design of a new OS that
provides all the necessary features, and outlines the key characteristics
of RIOT which fulfill all the requirements identified in the report.
Your feedback on this report would be very useful. In particular,
discussions on the following points would be great:
1 - suggestions for how to potentially develop this qualitative analysis
further, and
2 - suggestions on what comparative measurements to carry out now, in order
to complement this qualitative analysis with an appropriate quantitative
analysis.
here are some brief and quick annotations to the suggested paper:
- I think the two network stacks in Figure I are mixed up
- The data in Table I seems very optimistic to me: With those memory footprint we could not send pakets or use the network, we also have no stdout support, etc. Contiki and TinyOs both support multithreading. I never heard about supporting c++ in our system and I think it cannot be achieved on a msp430. What do you mean with full c support, we're not fully POSIX compatible, we are even not fully newlib compatible and cannot achieve even one of those.
- Contiki supports preemptive scheduling.
- We only support MCUs with vectored interrupt controllers and I rarely heard about MCUs without one.
In general the paper reads more like a marketing whitepaper than a scientifical paper to me.
Best regards,
Heiko
P.S.: could you please add thomas to this mailing list.
achieved on a msp430. What do you mean with full c support, we're not
fully POSIX compatible, we are even not fully newlib compatible and
cannot achieve even one of those.
The core is mostly libc independent. We support standard C as language,
without full Ansi-C base libraries or POSIX. The point is to
differentiate from Contiki (using protothreads which turn C into
something weird) and TinyOS (written in nesC).
- Contiki supports preemptive scheduling.
... but not through it's standard API (the protothreads thing), right?
- We only support MCUs with vectored interrupt controllers and I rarely
heard about MCUs without one.
Which could be rephrased as "you rarely heard about MCUs which we don't
support".
May sound like marketing, but since when are we idealistic about out
science work?
achieved on a msp430. What do you mean with full c support, we're not
fully POSIX compatible, we are even not fully newlib compatible and
cannot achieve even one of those.
The core is mostly libc independent. We support standard C as language,
without full Ansi-C base libraries or POSIX. The point is to
differentiate from Contiki (using protothreads which turn C into
something weird) and TinyOS (written in nesC).
But the core doesn't fulfill all the advertised features.
- Contiki supports preemptive scheduling.
... but not through it's standard API (the protothreads thing), right?
wrong.
- We only support MCUs with vectored interrupt controllers and I rarely
heard about MCUs without one.
Which could be rephrased as "you rarely heard about MCUs which we don't
support".
No. I heared about several Intel processors which we do not support, but they all have vectored interrupt controllers.
- The data in Table I seems very optimistic to me: With those memory
footprint we could not send pakets or use the network, we also have
no stdout support, etc.
It's definitely true that it's hard to compare these numbers without defining
a specific application. The numbers for RIOT are taken from a basic
application that includes stdout, but no network stack.
Contiki and TinyOs both support multithreading.
As far as I know, they only support light-weight multithreading with a single
stack for all threads.
I never heard about supporting c++ in our system
We have C++ support running on the MSB-A2 for the Wiselib, for example.
I think it cannot be achieved on a msp430.
Why not? mspgcc supports C++. Do you see any particular problem with it?
P.S.: could you please add thomas to this mailing list.
>>achieved on a msp430. What do you mean with full c support, we're not
>>fully POSIX compatible, we are even not fully newlib compatible and
>>cannot achieve even one of those.
>The core is mostly libc independent. We support standard C as language,
>without full Ansi-C base libraries or POSIX. The point is to
>differentiate from Contiki (using protothreads which turn C into
>something weird) and TinyOS (written in nesC).
But the core doesn't fulfill all the advertised features.
I don't know any library within RIOT that is not ANSI C99 compatible.
We didn't claim to be fully POSIX compatible - not yet.
>>- Contiki supports preemptive scheduling.
>... but not through it's standard API (the protothreads thing), right?