M2OS: A Small and Lightweight Ada RTOS for Microcontrollers | Hacker News Reader

M2OS: A Small and Lightweight Ada RTOS for Microcontrollers

m2os.unican.es

97 pointspjmlp34 comments

This:

> allows to apply the advanced techniques used in high integrity systems (i.e. aircraft flight control, medical devices, critical industrial control) to the smallest MCUs used by industry and hobbyists

But also this:

> M2OS implements one-shot non-preemptive scheduling policy

Uhm, what? Those two paragraphs cancel out each other pretty much.

> The STM32F4 board is based on the ARM Cortex-M4 microcontroller. The amount of memory available in this board does not justify the use of a small RTOS as M2OS, however we have decided to port M2OS to this board to explore its implementation on ARM microcontrollers.

STM32F4 is a controller family, not a board. Is this some GPT-3 output?

The list goes on ...

Seriously, what am I even looking at? Is this just some SEO optimized site with a bunch of buzzwords and some seemingly valid content?

If you look at ST's product chart page, STM32F4XX microcontrollers can have anywhere from 512K to 2056K of flash, maybe they're suggesting that 512K doesn't justify the use of small rtos?

It can be as low as 64K in the case of the STM32F410 but I can't tell whether it would be supported.

While I am aware of the technical specs, my point is about the wording itself. This was just an example. The "Docs" section for example doesn't actually hold any documentation.

Something about this website feels uncanny, hence my (joking) guess regarding GPT-3.

They're probably talking about boards like this that also have megabytes of SDRAM. https://www.st.com/en/evaluation-tools/32f429idiscovery.html

It's usually not the amount of flash that's the problem with an RTOS on an embedded microcontroller. It's the amount of RAM. Because each process requires it's own stack. That said STM32 parts generally have enough.

What particular concern do you have with the scheduling policy? As I understand it, it's an RTOS for embedded devices. They're most likely just referring to SPARK's formal proofing.

As for the STMF4, they're possible referring to the STMF4DISCOVERY boards.

It likely refers to the popular STM32F4 Discovery board [0], which is a devkit for that family of uCs. Good for prototyping, has an onboard programmer and everything. It has 1MB of flash, so I think this line means "if you wanted to use this board, you'd be better off with a full RTOS that can make use of that code space, rather than M2OS which is optimized for single-kB flash sizes".

The rest of your comment I agree with. It seems to be a half-baked academic project. Might be interesting if you know anything about Ada, which I don't.

[0] https://www.st.com/en/evaluation-tools/stm32f4discovery.html

The Software engineering and real-time group at the Universidad de Cantabria seem to be pretty well credentialed in this area. They produced a viable RTOS some years ago called MarteOS ( https://marte.unican.es/ ) This is no small feat.

That had me scratching my head too. I have a board next to me based on the STM32F407, which is the same MCU as the Discovery board (we prototyped on the Discovery board actually) and it definitely has the capability to run an RTOS.

I interpreted it the other way: it has too much RAM to justify a micro-OS.

Also:

> smallest MCUs used by industry and hobbyists

> ARM Cortex-M4

Hardly the smallest MCUs used.

That core is a mainstream choice for safety-critical embedded systems these days. Usually running in a lockstep configuration of course, unlike some of the boards discussed here.

They claimed it was an OS for the smallest MCUs in use, though, not just for mainstream ones.

There's a mini-RTOS in my language!

https://blog.adacore.com/theres-a-mini-rtos-in-my-language

Fascinating.

There's quite a lot of OSS RTOSs.

https://www.osrtos.com/

When did Ada become popular in the embedded RTOS space? First I've heard of it and I've been working in the space for two decades.

In aerospace and/or defense?

No. Is that where Ada is used?

Breaking into automotive slightly I think too.

It's technically "allowed" by ISO26262, but I've never encountered anybody using it for anything in automotive. The automotive software ecosystem is dominated by C and firmly kept that way by the bevy of tools in use (e.g. flavors of AUTOSAR, Mathworks Simulink, etc.).

That's not to say that nobody is using, or hasn't used, Ada in automotive, but it would seem likely vestigial rather than up and coming based on my exposure to that industry.

https://blogs.nvidia.com/blog/2019/02/05/adacore-secure-auto...

I was thinking of this, which is a little vague, but the software will have some ASIL classification I'm sure, but maybe is not typical automotive software. Article mentions certain firmware.

It was written as part of a DoD project https://en.wikipedia.org/wiki/Ada_(programming_language)#His...

I remember when it came out. It was a bear when it came to CPU time for compilation. At UIC, where CPU time was subject to weekly quotas, students in the Ada team had to work in teams because they'd use up their quota of CPU time (you'd get a fresh allocation of CPU each week and once you went over your quota you couldn't log back in until you got a new allocation) in one programming session and would have to log in to a different account to continue working the next day.

I don't have any practical experience with the language, but based on the spec, it sounds like Ada generics would have much the same problem wrt compilation times as C++ templates do, at least if you try to fully optimize them (i.e. avoid boxing and similar techniques to allow generic code to be compiled just once, instead of once for every unique instantiation in every translation unit).

Not really, they need to be explicitly defined before use.

Which then thanks to packages, they can be reused across several projects when similar type parameters are required.

So you only generate List(T => Integer) once for the whole project, when project architecture is properly done.

A scenario that eventually might be possible in C++, around C++23 time frame, taking into consideration how long the modules infrastructure might need to mature.

Sounds like Rust, hah.

In many ways Rust fills part of the conceptual space that Ada was attemptiong to fill. Both are very concerned with safety.

Except Ada was military/government mandated, and the syntax is probably the opposite of Rust: very verbose, very wordy. And the concept of type inference is anathema to the Ada mindset, where everything is explicitly... explicit.

I've never used Ada for work but I went through a couple years where I enjoyed playing with the language as a sort of C++ alternative. I ... kind of? like it, but then I learned Pascal and Modula-2 before I ever learned C, so...

One of the nice things about the verbosity is that it's really easy to read. I've been working with code from the late 90's for some aircraft and it makes it really easy to review and get into the code (when well-written). The other thing is that the strong types are really powerful. If Ada compiles, then the only things that you have to worry about is if your logic is right or if you remembered to init an array.

Also, whereas Ada is perfectly fine with introducing runtime overhead, Rust takes a zero runtime cost approach when possible, otherwise it doesn't offer that feature as part of the language.

Yup; there's real-time Ada in half the things flying around, and most all of the ones painted grey.

That is amazing. There are so many good links in the peer comments. I worked at STMicro, then briefly at Arm, then at IAR. I never once encountered Ada. Two separate worlds!

NASA. https://space.stackexchange.com/questions/36538/what-makes-a...

Airbus. https://www.adahome.com/Ammo/Success/aerofws.html

Boeing. http://archive.adaic.com/projects/atwork/boeing.html

Robotics (as in 6dof teach-in industrial robot arms you'd find on a factory floor). At least that used to be the case 30 years ago, but I doubt that changed.

Reply on news.ycombinator.com