RTOS - REAL beginner...

Hi,

I need to know that:

For learning RTOS ... is it necessary to learn 32 bit microcontrollers ...?

I am mostly familiar with 8 bit microcontrollers...

Regards,

Simran

Since nobody else has bothered...

No, 32 bit controllers and RTOSes are not directly related so the answer is no, you don't need to learn 32 bit architectures for that. It could still be a good idea in general, though.
If you check the popular FreeRTOS web pages, you will find a port of the OS to 8 bit AVR MCUs, specifically the ATMega328. So you can even run an RTOS on Arduino Uno

To be blunt, an "operating system" on an embedded device where the end user cannot load programs is completely nonsensical, a gimmick.

An OS allows changes to the loaded / running programs while the computer is functioning. That never happens with an MCU.


And, multitasking is so ludicrously simple that many beginners just miss the obvious - if something needs a delay or is not ready, you jump forward rather than looping back.

ie. You go on to the next task that may need attention, and check the stalled or waiting one again the next time through the main loop.

You never use delay() type functions, in other words; they are an anathema in real-time systems, other than possibly in the initial setup sequence.

Add one timer triggering a regular interrupt that can be used to count down times or set flags to notify the main loop that a scheduled task needs attention etc., and you have a complete real-time system.

Sorry about the wall of text, i didn't have the time to make it shorter.

Well, it is obvious from your reply that you are not familiar with embedded OSes. If you wish to blink a LED and read a couple of switches sure, an OS would be overkill. Also, an embedded OS is not the same as a desktop OS such as your Windoze, MacOS or Linux, nor does it try to be. The priorities are elsewhere.

Some elementary facts regarding the embedded OS i am most familiar with; FreeRTOS (applies to many other kernels as well):

- The main thing is deterministic latency in reacting to events external as well as internal. This is the key definition of a hard real time system and in many applications it is a mandatory feature. The point here is that it is a feature of the OS kernel, not a case-by-case ad hoc implementation. The kernel is tested and validated to an extent an individual developer can never match. This matters greatly when the system gets more and more complex.

- the OS supports all the things you otherwise juggle manually: task creation/deletion/priorization/suspension, task scheduling according to rules, messaging between tasks, mutexes and semaphores to guard common resources and suchlike, dynamic memory allocation using several different algorithms if your application allows/needs such a thing, interrupt handling and interrupt-to-task communication and much more, as they say.

- provided the HW is able, the OS has a file system library that you may include in the build. Presto: loadable programs, persistent file storage. Mostly you don't need anything like that so you don't have to include it.

- provided the HW is able, loadable Ethernet and TCP/IP support so you can have networking as well. Don't include it if you don't need it.

- If you wish, you can include a CLI so you will have a command line on a suitable terminal



As just one real life example, i am at this time developing the HW and SW of a supersonic small rocket telemetry and attitude/aspect control system. This system has a 9-axis gyro, 3 axis high-g accelerometer, a barometric pressure sensor, a GPS receiver with an active antenna, a communications radio with 2 selectable antennas and HF amp, 8 servo channels for airfoil control, 3 pyrotechnic channels for initiating 2nd stage, drag chute and landing chute. It also has an on-board SD card slot for program selection and sensor data storage. The processor in this case is a i.MX RT1064, a 600MHz ARM Cortex-M7 targeted for real-time applications. This MCU can optionally boot from a variety of sources such as internal or external flash, SD card, USB etc etc and this feature is used in the system.

The system tasks consist roughly of: a supervisor managing and monitoring the overall state and phase of flight of the rocket; the flight aspect and attitude control task(s) - a MIMO state control subsystem; a sensor fusion task to integrate the sensor data into relevant flight state information; device drivers and sampling tasks for all the sensor peripherals as well as drivers for all the actuators.

If controlling all of the above is "ludicrously simple" (your words) then perhaps i should hire you and be done with it? But maybe not. The simple truth is that you have a snowballs chances in hell to implement the system without some kind of embedded kernel. Even then the word "simple" will probably not enter the discussion very often.

It is true that not every problem needs an OS as the solution. But saying that they are nonsensical gimmicks is just exposing your ignorance. Ignorance is OK but willful ignorance is just burying your head in the sand.

Kremmen said:

As just one real life example, i am at this time developing the HW and SW of a supersonic small rocket telemetry and attitude/aspect control system. This system has a 9-axis gyro, 3 axis high-g accelerometer, a barometric pressure sensor, a GPS receiver with an active antenna, a communications radio with 2 selectable antennas and HF amp, 8 servo channels for airfoil control, 3 pyrotechnic channels for initiating 2nd stage, drag chute and landing chute. It also has an on-board SD card slot for program selection and sensor data storage. The processor in this case is a i.MX RT1064, a 600MHz ARM Cortex-M7 targeted for real-time applications. This MCU can optionally boot from a variety of sources such as internal or external flash, SD card, USB etc etc and this feature is used in the system.

Click to expand...

And this sounds like a system where an RTOS would slow the whole thing down.

Mike.

Pommie said:

And this sounds like a system where an RTOS would slow the whole thing down.

Click to expand...

100% agree.

I've been developing commercial products for over 30 years, some of which are extremely tight on timing.

The basic fact is that if adding someone else's software can reduce latency, you can reduce it even more yourself without that added software - the code will be smaller and waste less time.

Kremmen said:

HW and SW of a supersonic small rocket telemetry and attitude/aspect control system.

Click to expand...

Would you consider that more complex than a high-speed sub-micron accuracy machine tool control system with multi axis coordination?
One CPU, doing everything including all the operator and machine control interface functions.

Running on a 4MHz 8 bit CPU by the way, back in the early 80s...

Those machines made parts for everything from the channel tunnel borers through bearing races and military tank components!


Or a four independent output, 256 level PWM with 100 / 120Hz update in software with PLL sync and serial comms included on an 8MHz PIC?


Saying something like your project is difficult on a 600 MHz, 32 bit (or is that one 64 bit?) CPU is the laughable comment.

Oh well. I am not interested in a pissing contest so whatever floats your boat. Let me just note that i too have done embedded programming since the late 70s for heavy paper and steel industries where failure is not really an option. In that context i have found embedded OSes useful starting from the venerable Intel iRMX and onwards from there.
So maybe we should just agree do disagree and let it rest at that.

rjenkinsgb said:

To be blunt, an "operating system" on an embedded device where the end user cannot load programs is completely nonsensical, a gimmick.

Click to expand...

My TV tuner is Linux based. Busybox. My actiontec router by verizon is Busybox.

https://en.wikipedia.org/wiki/BusyBox

KeepItSimpleStupid said:

My TV tuner is Linux based. Busybox. My actiontec router by verizon is Busybox.

Click to expand...

Somewhat different as they have multiple network interfaces, RF, web & telnet user interfaces, even if not a full built-in GUI.
A very large part of what is essential for the overall function in that case is existing off-the-shelf code.

The runtime module configuration can be changed by the user, eg. services started and stopped - effectively controlling the loading of program modules.

A bit different to a something where it's a PIC or whatever, where it's all custom code.

Real Time essentially means a guaranteed response to an event.
The OS part "helps" you get that especially when there is a lot of stuff going on.

The PID algorithm has to run once/second for 7 devices. That was the real-time part. Display, logging and the recipes were the non-real time part.

I had to do the equlivelent of "move film" every two minutes. The film was clear and kept a quartz window from getting dirty. We were passinig UV light through the window to make the reaction work. Windows required hardware (external counter/timers), a real0-rime OS didn't, Input was turns count from a mechanical counter.

KeepItSimpleStupid said:

Real Time essentially means a guaranteed response to an event.

Click to expand...

How does an RTOS do it quicker than an interrupt?

Mike.

Te concept is "Determinism". See https://en.wikipedia.org/wiki/Deterministic_system#In_computer_science

If your building a motor controller, you might not want the response to a routine to be between 1 mS and 2 mS. that's what might happen if you wrote the program to run under Windows 10.

I wrote an OS once and your not concerned with a deterministic response, but rather an equitable sharing of resources. The old MacOS used to "hand off" execution in their "Multifinder" OS. In a typical OS, you have to save the state of the program and you could just time-slice.

It's really how you handle that interrupt and can you make the process deterministic to be a RTOS.

i think we would lump a microwave into an embedded system.

Here https://en.wikipedia.org/wiki/RT-11 is a RTOS tat I'm familiar with.

Pommie said:

How does an RTOS do it quicker than an interrupt?

Click to expand...

It doesn't, an RTOS is no such thing, and will always be considerably slower than a properly written non-RTOS application on the same hardware.

Essentially (in my opinion) an RTOS is a 'sledge hammer approach' to a problem, throw massive hardware at it (600MHz ARM for example) and it doesn't matter much how sloppy your programming is

For those of you who remember the Commodore Amiga?, the OS was based on UNIX style commands, and much of the disk control system was actually stored on it's floppy disk (disk copy, file transfer etc.) - it was all written using Lattice C, and a bunch of enthusiasts rewrote all the disc based commands in assembler. This reduced the file sizes to about 25%, and increased their speed four or five times.

The same applies to Windows, Windows programming is incredibly sloppy, with absolutely massive file sizes and requiring incredibly fast and extensive hardware to run at a decent speed. Going back to the afore mentioned Amiga, it ran under 8MHz, only had 512K of RAM, yet produced amazingly fast graphics and games, because it was written in assembler and for efficiency.

I can remember the first CD-ROM's coming out - what a revelation, you could have all of your games and programs on a single disc - not for long you couldn't, more space simply means sloppy programmers use more of it, and it wasn't long before programs came on multiple CD-ROM's.

I wonder how fast correctly written DOS software would run on modern PC hardware?, with the huge overheads of Windows or Linux removed it would be pretty damn fast For that matter, how fast would the above mentioned 600MHz ARM be without the crippling OS?.

KeepItSimpleStupid said:

Real Time essentially means a guaranteed response to an event.

Click to expand...

Exactly.

KeepItSimpleStupid said:

The OS part "helps" you get that especially when there is a lot of stuff going on.

Click to expand...

Only if there is a load of other people's really crappy programming involved, that you cannot get rid of.


I'd say that anyone working with embedded systems (and not using other peoples software) who's never got down to the assembly/machine code level and counted instruction cycles to optimise routines has never done true real-time programming.

As Nigel says, adding an OS to try and make your own code work better [as opposed to someone else's] is a sledgehammer approach - it's far less efficient than properly written code without the OS.

thanks all...