Was there a particular moment in time when RTOSs became common on micros?

[e100]

(I'm not an engineer).
Were they always used in things like PLCs from way back 20-30 years ago?
Did they only appear on general purpose microcontrollers once RAM sizes increased. (Perhaps I'm not making sense.) I started with the Atmega 328 but now it seems that every new chip popular with the maker community has some type of RTOS by default.

[tszaboo]

It was already part of university courses 15-20 years ago, where it was clearly stated that it is the future for microcontroller based systems. There will be 8 bitters, which will work as much as a  "programmable AND gate" and 32 bit micros with lots of processing power.
I think in the end C will disappear, since there is so much brainpower is spent nowadays on mundane tasks like sorting arrays, manipulating strings, writing into databases and tracking down bugs in systems like this.

[westfw]

Some sort of muti-tasking kernel started being common on Motorola 68k and Intel x86 systems with as "little" as 256k of memory.  Not to mention PDP-11s and similar with less.  When microcontrollers got up to similar quantities of memory, it was only natural to put similar kernels on them.  (especially when RAM increased.  multi-tasking tends to be very ram-intensive, what with the usual stack per task.)  (an Original SUN-1 ran "unix", and was a 68k with 1M of meomry.  Minix ran on the original IBM-PC, IIRC.)
IMO, the verdict is still out on the exact sorts of features that a microcontroller OS ought to provide.
Certainly the whole IoT craze has inspired acceptance of such kernels.  It's pretty difficult to do a network stack without an OS, especially if you're trying to keep the networking code separate and only semi-visible to the "user code", and maybe proprietary (all those microcontrollers with built-in secret BT stacks, for example.)

[tellurium]

It's pretty difficult to do a network stack without an OS, especially if you're trying to keep the networking code separate and only semi-visible to the "user code"

That's true.

However, IMO most difficulty comes from the fact that a BSD sockets interface got adapted for networking applications. The socket/select/send/recv API requires socket buffers and synchronisation primitives. An RTOS provides those primitives, and that's why it is easier to implement BSD API with RTOS. Implementing a blocking recv() without an RTOS would be difficult.

If networking API is not BSD, but something else - for example, an event-based, then RTOS might not provide much advantage. It won't be as familiar as sockets API, but avoiding RTOS scheduling/synchronisation can achieve a considerably higher performance. Some experiments show a 2 orders of magnitude difference, when using e.g. FreeRTOS + lwip (sockets) versus baremetal, no sockets.

[Doctorandus_P]

An RTOS has some advantages, but also disadvantages.

It is possible to run an RTOS on an AVR (Both FreeRTOS and ChibiOS fit, and some other too) but an RTOS is not a good fit for an AVR.

Firstly, the ATmega328 only has a few kB of RAM, and you have to cut this in peaces to have a stack for each task.
ATmega series also have 32 registers which all have to be saved (and others popped again) on each task switch.
ATmega's also only have a single ISR level, there are no different priorities, and because ISR's are also used for the task switching itself, this increases the ISR latency for all ISR's a lot.

An RTOS is also not a magic bullet. It can help with keeping overview in a program, but it comes at a price of extra complexity, both for the added overhead of the RTOS kernel itself, but also for the added complexity of inter process communication. You need to use semaphores queues and message boxes to keep your program "thread safe".

Multi tasking systems have existed from the early days of computers, simply because a computer was very expensive in those days and a single computer had to be shared with many users. In the very early days it was only batch processing. You prepared a program in the form of a stack of punched cards, and someone else put the stack in the machine and you got notified when your program was ready. Multitasking allowed a lot of users to interact with a single computer (via terminals) at the same time, and those users had to be separated from each other, and thus preemptive multitasking was a must.

In these times microcontrollers have outgrown computers which were considered quite capable in their time. My first pc was a 80sx386 at 16MHz and 4MB of RAM, and now (apart from the temporary shortage) you can buy a microcontroller for EUR10 that has more memory and can add a uSD card that has much more storage capability than hard drives of that era. Using an RTOS also makes it easier to use libraries as modules such as Wifi or FSFat.

Microcontrollers with multiple processor cores are also becoming more common, such as the ESP32 or the Raspi4020, and adding an RTOS which is aware of this also makes it easy to use of both processor cores.

[westfw]

It's pretty difficult to do a network stack without an OS

However, IMO most difficulty comes from the fact that a BSD sockets interface got adapted

I dunno.  I was mainly thinking of the sorts of side-hustles that go into a network stack that "naturally" end up as separate processes.  ARP, ICMP, TCP Retransmission...

[Kjelt]

The RTOS indeed became popular when the microcontrollers got more RAM.
It is a fancier version of what most companies already did themselves IMO.
At least for the five companies I worked for in the past, even on their small 8 bit microcontrollers with only a couple of kB of RAM, they had their own custom (task) schedulers.

The SWengineers still followed Rate Monotonic Analysis courses where you learn to fit all tasks into the available time. You had to make sure that time critical tasks such as sampling, calculations and results were done within the required timeslots. You could have eventdriven tasks on ISR basis or timebased tasks that were started on a timer IRQ, or tasks that could be started after some result was available etc. But also many combinations which could cause havoc if not timed properly.

An RTOS is just a 3rd party fancy task scheduler which costs resources but if you have them to spare, it is the way to go since every sw  engineer can work with it.
But you still have to make sure everything fits, I still saw colleagues thinking it is a magic real time bullet that will take care of everything which it does not. As the product grows and the idle cycles disappear you still have a scheduling timing puzzle to solve.

[tellurium]

An RTOS is just a 3rd party fancy task scheduler which costs resources but if you have them to spare, it is the way to go since every sw  engineer can work with it.

Agreed.

I'd add, that along with the task management API, an RTOS often provides synchronisation API as well, like mutexes/queues - because as soon as one introduces a scheduler that can interrupt any task mid-way of some operation, one needs to take care about concurrent accesses. Which is one of the major complications in comparison to the non-RTOS approach.

[janoc]

It's pretty difficult to do a network stack without an OS

However, IMO most difficulty comes from the fact that a BSD sockets interface got adapted

I dunno.  I was mainly thinking of the sorts of side-hustles that go into a network stack that "naturally" end up as separate processes.  ARP, ICMP, TCP Retransmission...

Indeed. The problem is the inherent asynchronicity and parallelism of networking (many things happening simultaneously and in arbitrary order) that makes it difficult, nothing whatsoever with BSD sockets. You will have exactly the same kind of problems if you talk to an Ethernet network,  CAN bus or even Bluetooth, with no sockets in sight.

While this can be done without an OS, an operating system makes it a lot easier to manage without having to constantly focus on juggling resources and making sure the timing constraints are met.

[janoc]

An RTOS is just a 3rd party fancy task scheduler which costs resources but if you have them to spare, it is the way to go since every sw  engineer can work with it.

Agreed.

I'd add, that along with the task management API, an RTOS often provides synchronisation API as well, like mutexes/queues - because as soon as one introduces a scheduler that can interrupt any task mid-way of some operation, one needs to take care about concurrent accesses. Which is one of the major complications in comparison to the non-RTOS approach.

You will have that as soon as you introduce interrupts, even with no RTOS and a single core CPU. Many people don't realize this - and then weird bugs and problems happen because an interrupt occurred when it was not expected. Or code disables interrupts as a matter of course in order to avoid having to deal with this, leading to terrible, non-responsive and poorly performing applications.

[tellurium]

You will have that as soon as you introduce interrupts, even with no RTOS and a single core CPU. Many people don't realize this - and then weird bugs and problems happen because an interrupt occurred when it was not expected. Or code disables interrupts as a matter of course in order to avoid having to deal with this, leading to terrible, non-responsive and poorly performing applications.

That is true, good point.