PerLindgrenRTFM

Thanks! RTFM-core embeds C code, and is as such not particularly safe. However, as an experiment an object (component like) abstraction RTFM-cOOre was drafted (along with a prototype implementation). The cOOre language "could" be safe (just using rtfm-core/C as an intermediate representation). But developing and "selling" a new language requires huge amount effort and resources. Many of the sought features for the cOOre language are already in place with Rust (just that the concurrency model was not there). So that is where it all started, RTFM for Rust, is at present just a subset of the rtfm-core language, but extensions towards timing semantics and object orientation are already in the making. Disclaimer: Myself being fairly new to Rust, so all the Rust type system wizardry is due Mr. Japaric. /Per

"Its not concurrency". I would argue that. Its not parallelism (at least not in the current state, but the RTFM-core language that originated this work offers true parallelism, implemented onto of Windows Threads, and Pthreads (Linux/OSX). On multicores, deadlock freeness is not guaranteed, but the rtfd-compiler detects potential deadlocks at compile time for the implementer to fix (so no spurious deadlocks from a system passing compilation). As the multicore implementation is being based on threads, response time analysis for such systems are basically out the window... (Also such multicore systems are very hard to predict, due to cashes, etc...) /Per

Hi There. A number of factors. 1) FreeRTOS is ineffective, in many cases you have to code around the kernel to get sufficiently good response times. 2) FreeRTOS does not offer any means to schedulability analysis, as the internal overhead is very hard to predict and data dependent (and lacks proper characterisation). 3) The threading model as such is not particularly suited to concurrent programming (RTFM is event driven, reflecting the reactive nature of the hardware as well as the application). 4) Thread based programming is hard to get right, see e.g., https://www2.eecs.berkeley.edu/Pubs/TechRpts/2006/EECS-2006-...). 5) Regarding FreeRTOS, the current license disallows to make comparisons with FreeRTOS without their permission, how about that for starters!!! /Per