I am new to the RTOS world. I am planning to use some RTOS on a Raspberry Pi 3 (may be FreeRTOS). Can anyone suggest which RTOS would be good for the beginners?
Since they have not released a datasheet on the BCM2837 yet, is it even possible to load RTOS onto a Raspberry Pi 3?
Although the original project only supports Raspberry Pi 1, I have succesfully compiled this fork on a Raspberry Pi 2, and it says to support 3 also.
Until now I tested the following RTOS without success for raspberry pi 3, that will help someone to not lose time (I wast 3 month) : FreeRTOS, Xenomai, RTEMS, BitThunder, ChibiOS/RT
For RISC OS it is not an a RTOS.
The only one that I was able to run on raspberry pi 3 until now is Fuchsia OS's kernel (Magenta), but it is in a earlier stage and low documented
Another way is to build you RTOS by your self, yes it is possible, using ULTIBO CORE, and following those tutorials: - http://www.valvers.com/open-software/raspberry-pi/step01-bare-metal-programming-in-cpt1/ - https://www.youtube.com/watch?v=TCfpb8M0WeQ
ARM, the ISA family used by the Broadcom processors on all current Raspberry Pi models, is based on RISC, for which RISC OS is written. RISC OS I think predominated on ARM devices for their first decade, as the same UK based tech company (Acorn) originally designed both ARM and RISC OS. In fact, ARM initially stood for "Acorn RISC machine", and part of the reason the Raspberry Pi is called what it is is because of a tradition in the UK of naming computer systems after fruits or nuts.
RISC OS is not a true real-time operating system, however, it does use cooperative multi-tasking, meaning you can run a process that can voluntarily refuse to surrender itself to another process. What consequences this may have I don't know, but I would assume that:
You can get things configured to allow this without problems, but it may involve restrictions on what the OS can accomplish (e.g., with respect to networking).
Context switches to kernel mode will only occur because of system calls made by the process in order to complete its goals.
That's pretty close to real time functionality, depending on how "real time" you need to get. Further, there is some confirmation that RISC OS runs on the Pi 3.
Since the definition of an RTOS varies on the application, usually a computer pretending to be something much simpler, RISC OS is an RTOS for the medium-complex applications, and isn't necessarily for high-complex ones, although a highly-complex RTOS sounds like a contradiction in terms. The example by Mahmoud Almostafa RABBAH refers to no OS, and running a single-tasking program straight from the boot-loader, which isn't an RTOS either.
The only way reasonable way of making sense of this is to split the RTOS definition into three levels:
Low-complexity would be something like a washing machine or a data logger, and you're probably better off with simpler hardware eg Arduino or maybe a simpler MCU, or even just sequential logic, in the first place. It'll consume less power, and there'd be a lot less to worry about: Never make things more complicated than they have to be.
High-complexity would be something like a full multi-tasking system, which a RTOS isn't. It'd probably be better to run your GUI on a separate device, if you want that. High-complexity could also be monitoring processes that call other processes, and some must be prioritised, but again you're better off with some kind of parallel processing there, or it fails the capability of responding in real-time.
Medium-complexity would be where you need the interfaces a normal OS can provide, eg USB, and perhaps a small display output, but you want to process a stream of data and not be interrupted by anything. This sounds like the level of an automotive application.
For that, you could compile something without an OS, using a host machine to develop it, or you could use the version of RISC OS which boots directly into BASIC and develop on the target machine, which is usually easier.
That will run a single task which can be fast enough to poll for a number of events, without being interrupted by other things. Hardware interrupts would still run unless they're disabled (fairly easy to do), and those are necessary in order to make the display/USB etc work. Other hardware interrupts run timers and IO you may not be using.
Another advantage of RISC OS in RTOS applications, is you can only use the modules you require, something that makes no sense in traditional GUI applications, and had been used by eg STD/AdvantageSix[1] although they use the term "embedded systems" instead of "RTOS". The advantages this brings are simplified design, lower power requirements, lower memory usage, and faster boot times (some I/O device interfaces require mini booting themselves, and the OS has to participate in this, although the timescales are usually too short to notice).
I hope that both fills in some gaps in the info above, and makes clear the gaps in my own knowledge.
[1] http://www.advantagesix.co.uk/about_us.html (Other examples from memory, are no longer available online.)
