There's clearly some misinformation in this thread. For those serious about learning RTOS, I highly recommend this book: Real-Time Embedded Components and Systems with Linux and RTOS. After having taken Dr. Siewert's course, I can say that any RTOS, properly designed, will be head and shoulders above any best effort system.

Here's an example of a RTOS...
In the course, for the final project, we used a webcam to take video of an analog clock with a Raspberry Pi. We then analyzed each frame to provide images of the second hand at each individual second, without any skips or blurred movement in the second hand, for 30 minutes. I found this to be pretty easy... I generally had 30 frames to work with. I did some image processing to determine when the hand of the clock didn't move much and saved that image. Another requirement was that you had to use at least two threads on the processor. You could do this all on one thread, but that defeats the purpose of learning about RTOS.
A poor persons Rolex:

For extra credit, we used a digital clock to take images every 100ms without any blurs. This was much more difficult - you needed to save 1 frame in 3 so you had to somehow synchronize your camera to your digital clock. I was unsuccessful in this endeavor, so I don't have a video to share, but I was close. It's a project I'll likely circle back around to when I have more time. Here's a few images to give you the idea.
You can clearly see the last digit from 600ms to 700ms is blurred, and would not be acceptable to complete the project. Only one student in our class was successful, and there were maybe 5 that were close. About 30 total people were in the class.


Frankly, this was the best academic course I've ever taken.

 

Also - one of the original RTOS...

 

There's clearly some misinformation in this thread. For those serious about learning RTOS, I highly recommend this book: Real-Time Embedded Components and Systems with Linux and RTOS. After having taken Dr. Siewert's course, I can say that any RTOS, properly designed, will be head and shoulders above any best effort system.

I've designed, programmed and build Linux embedded systems and kernel drivers so yes, that's a proper use of a RTOS at that system applications scale but RTOS programming at the level of 8-16-bit hardware functionality level is usually not the best use of resources. If there was a clear use case to be made at the small embedded level, people would use a RTOS for blinking LEDS but they don't, not because they are ignorant, it's because they are smart.

Would you use a Linux based RTOS for real-time generation of three-phase power wave-forms that require very close timing interfaces with hardware? You might but the actual hardware functionality would still be interrupt driven and mainly isolated from the RTOS environment. The RTOS environment in that case usage would be for non-hardware functionality like networking, user functionality and other applications related requirements.

For smaller systems event-driven modern state machines are superior to the normal super-loop method of programming or designing task blocking RTOS-based systems in that environment.

https://embeddedgurus.com/state-space/category/event-driven-programming/

RTOS and State-Machines are not mutually exclusive... You don't need a RTOS to manage the time resource and many people with hardware experience find it constraining on modern hardware specialized peripherals. This is especially true if you don't use a time splice task, per processing unit, task scheduling for your embedded model. Event State and State Machines with the proper hierarchy be used to eliminate the RTOS blocking model entirely in most controller applications with controller level LOC complexity.

 

Also - one of the original RTOS...

An incredible system but it also shows IMO how old RTOS is as a embedded programming paradigm. It was an improvement over the original super-loop sequential paradigm but it's not the only modern way to improve the software development environment at the embedded level.

 

So I made conclusions that if an application has one or two or three up to five critical task , I would use the traditional method. Interrupt

if there are multiple critical task like more than five . I would use real time operating system. Maybe an aircraft flight control system....too many sensors and inputs and data streams competing for real time attention.

 

@nsaspook
I think we are generally in agreement.

Blinky LED's is clearly not a time-critical application - with no real deadline - and does not require an RTOS. That's something that is pointed out in the book - hence the reference to the book. It's clear that some people here (not you) want to better understand RTOS and the use cases. I was really just trying to provide an excellent (world class?) resource for learning about these systems and the theory behind them (Least Upper Bound, Rate Monotonic, Deadline Monotonic, Priority Preemptive, Earliest-Deadline First, Worst-Case Execution time, CPU/IO/Memory Bound applications, etc).

Three-phase power waveforms are clearly time-critical, with a deadline, that must be met - on-time - every time. I would never* use a Linux RTOS for a hard real-time system like a power system. A simple cyclic executive works perfectly well in most applications. However, Linux is perfectly capable for RTOS in soft real-time systems - think Roku, Amazon Fire Stick, bluetooth headphones, non-critical robotic systems, etc.

I design power based RTOS systems for a living - embedded - not Linux based. Keep things simple when you can keep them simple, but I clearly have done both and find value in each.

* - Maybe not never, but I would be extremely cautious.

 

So I made conclusions that if an application has one or two or three up to five critical task , I would use the traditional method. Interrupt

if there are multiple critical task like more than five . I would use real time operating system. Maybe an aircraft flight control system....too many sensors and inputs and data streams competing for real time attention.

I wouldn't put such a hard and fast rule to this. Read the book. It all depends on the Worst-Case Execution Time and the deadline of each service!

It's worth noting that using an 'real-time operating system' (Linux with POSIX threads, FreeRTOS, Windriver, VxWorks, whatever...) doesn't make it an RTOS, in and of itself. Having deadlines makes it a RTOS. If you have a main() loop in a 8-bit PIC and are servicing interrupts and have deadlines that must be met, you still have an RTOS, it's just a cyclic executive version rather than a true 'operating system' with all the bells and whistles. My professor called these RTEmbeddedS RTES... to make this distinction, but this terminology gets thrown around a bit in industry.

 

@nsaspook
I think we are generally in agreement.

Blinky LED's is clearly not a time-critical application - with no real deadline - and does not require an RTOS. That's something that is pointed out in the book - hence the reference to the book. It's clear that some people here (not you) want to better understand RTOS and the use cases. I was really just trying to provide an excellent (world class?) resource for learning about these systems and the theory behind them (Least Upper Bound, Rate Monotonic, Deadline Monotonic, Priority Preemptive, Earliest-Deadline First, Worst-Case Execution time, CPU/IO/Memory Bound applications, etc).

Three-phase power waveforms are clearly time-critical, with a deadline, that must be met - on-time - every time. I would never* use a Linux RTOS for a hard real-time system like a power system. A simple cyclic executive works perfectly well in most applications. However, Linux is perfectly capable for RTOS in soft real-time systems - think Roku, Amazon Fire Stick, bluetooth headphones, non-critical robotic systems, etc.

I design power based RTOS systems for a living - embedded - not Linux based. Keep things simple when you can keep them simple, but I clearly have done both and find value in each.

* - Maybe not never, but I would be extremely cautious.

My main irritation is that some see the RTOS paradigm of Sequential (single or multi tasks) Programming With Blocking as the latest refinement of embedded programming. Sure we should use it when needed but event-based or event-driven models can be used to implement concurrency and IMO a paradigm shift from a traditional Sequential RTOS is what's really needed for the next generation of embedded systems as they become even more connected. There are usually real-time active transformational embedded processes like computationally demanding/exacting waveform generation for a BLDC motor or a inverter that are resource locked and there are real-time reactive processes with event time constraints like anti-lock braking that must be met in a typical embedded system. The real-time reactive processes are usually where we have concurrency programming issues.

The Mars Pathfinder is a classic case of where Sequential Programming With Blocking can bite you.
https://web.archive.org/web/20191014204826/http://knusbaum.com/mars/Authoritative_Account

The failure was identified by the spacecraft as a failure of the bc_dist task to complete its execution before the bc_sched task started. The reaction to this by the spacecraft was to reset the computer. This reset reinitializes all of the hardware and software. It also terminates the execution of the current ground commanded activities. No science or engineering data is lost that has already been collected (the data in RAM is recovered so long as power is not lost). However, the remainder of the activities for that day were not accomplished until the next day.

The failure turned out to be a case of priority inversion (how we discovered this and how we fixed it are covered later). The higher priority bc_dist task was blocked by the much lower priority ASI/MET task that was holding a shared resource. The ASI/MET task had acquired this resource and then been preempted by several of the medium priority tasks. When the bc_sched task was activated, to setup the transactions for the next 1553 bus cycle, it detected that the bc_dist task had not completed its execution. The resource that caused this problem was a mutual exclusion semaphore used within the select() mechanism to control access to the list of file descriptors that the select() mechanism was to wait on.

The select mechanism creates a mutual exclusion semaphore to protect the "wait list" of file descriptors for those devices which support select. The vxWorks pipe() mechanism is such a device and the IPC mechanism we used is based on using pipes. The ASI/MET task had called select, which had called pipeIoctl(), which had called selNodeAdd(), which was in the process of giving the mutex semaphore. The ASI/ MET task was preempted and semGive() was not completed. Several medium priority tasks ran until the bc_dist task was activated. The bc_dist task attempted to send the newest ASI/MET data via the IPC mechanism which called pipeWrite(). pipeWrite() blocked, taking the mutex semaphore. More of the medium priority tasks ran, still not allowing the ASI/MET task to run, until the bc_sched task was awakened. At that point, the bc_sched task determined that the bc_dist task had not completed its cycle (a hard deadline in the system) and declared the error that initiated the reset.

 

I design power based RTOS systems for a living - embedded - not Linux based.

I've designed, programmed and build Linux embedded systems and kernel drivers

Do you make state machine for RTOS system before to start coding

 

For competitive reasons I cannot say how I do things, just what I do.

To backup my comment about RTOS being superior to Round Robin systems: (Courtesy of Dr. Sam Siewert)
http://mercury.pr.erau.edu/~siewert...-1-above-LUB-harmonic-showing-RR_failure.xlsx
http://mercury.pr.erau.edu/~siewert...-2-above-LUB-harmonic_showing_RR_failure.xlsx

RTOS systems are clearly able to do more, on time, and with absolute determinism. RR will miss deadlines, and not be able to process as much data. RR is fine for a desktop, but loses most of it's luster in most other scenarios.

 

My main irritation is that some see the RTOS paradigm of Sequential (single or multi tasks) Programming With Blocking as the latest refinement of embedded programming. Sure we should use it when needed but event-based or event-driven models can be used to implement concurrency and IMO a paradigm shift from a traditional Sequential RTOS is what's really needed for the next generation of embedded systems as they become even more connected. There are usually real-time active transformational embedded processes like computationally demanding/exacting waveform generation for a BLDC motor or a inverter that are resource locked and there are real-time reactive processes with event time constraints like anti-lock braking that must be met in a typical embedded system. The real-time reactive processes are usually where we have concurrency programming issues.

The Mars Pathfinder is a classic case of where Sequential Programming With Blocking can bite you.
https://web.archive.org/web/20191014204826/http://knusbaum.com/mars/Authoritative_Account

There's a lot that can bite you in RTOS... deadlock is another.

Blocking was one reason I couldn't get my 10Hz clock working. The SDcard write was a blocking event, and it was happening so often at 10 Hz that I was having difficulty getting the data thru and getting all the images. I was able to solve that problem by using a different image compression for quicker writes, but writing to the SDcard was still a blocking event. Even though it was shorter - it was still a killer and I couldn't seem to get around it so I'd loose frames occasionally. I think if I had fully fixed that I would have gotten the camera and the clock to sync.

Clearly, the Frame_Write service was blocking - the 10s write happened, then the next write, and it would lock up the entire CPU - all 4 processors until the write was completed, then it would eventually catch up. I could never figure out why. Unfortunately, I can't display the whole architecture in order to maintain the integrity of the course.

 

Again, highly recommend the book and the course. You learn a ton about the kernel, POSIX threads, multi-threaded applications, RTOS, Computer Architecture, memory-mapped IO, circular buffers, C, C++, message queues, etc, etc... Really one of the best (and hardest) courses I've ever taken - highly recommended.
Real-Time Embedded Systems | Coursera

Dr Siewert also informed me that the course is FREE! All four parts:
1) https://www.coursera.org/teach/real-time-embedded-systems-concepts-practices
2) https://www.coursera.org/teach/real-time-embedded-theory-analysis
3) https://www.coursera.org/teach/real-time-mission-critical-systems-design
4) https://www.coursera.org/teach/real-time-project-embedded-systems

Starter Code:
https://github.com/siewertsmooc

 

@tindel

Thank you for sharing useful materials

 

Thanks for bringing up such an interesting topic... this is an area of expertise many experts don't touch in their lifetime, so it doesn't get a lot of discussion here. It's a relatively young area of study compared to say - Newtonian physics - so I tend to gravitate towards these things. The first proof of a sufficient system was only published in 1973 and the first necessary & sufficient proof was published more than a decade later in 1989 - just over 30 years ago. These are things you will study in the class. Since NASA/Apollo was clearly using RTOS's, before the proofs existed, it's a subject field that is just catching up to practice which is fun too.

I'm not going to claim to be up-to-date on all the current research, but I know enough to build RTOS's and I personally think most systems will be RTOS as we learn more about AI, robotics, and ML and that these areas of study will be all closely related.

To talk about these things was also good review for me as I enter into my newest design.

 

There's a lot that can bite you in RTOS... deadlock is another.

Blocking was one reason I couldn't get my 10Hz clock working. The SDcard write was a blocking event, and it was happening so often at 10 Hz that I was having difficulty getting the data thru and getting all the images. I was able to solve that problem by using a different image compression for quicker writes, but writing to the SDcard was still a blocking event on that processor. Even though it was shorter - it was still a killer and I couldn't seem to get around it so I'd loose frames occasionally. I think if I had fully fixed that I would have gotten the camera and the clock to sync.

Clearly, the Frame_Write serevice was blocking - the 10s write happened, then the next write, and it would lock up the entire CPU - all 4 processors until the write was completed, then it would eventually catch up. I could never figure out why. Unfortunately, I can't display the whole architecture in order to maintain the integrity of the course.

View attachment 250150

Things like SD cards writes (SPI I/O streams) are real-time active transformational embedded processes that can require low-level hardware solutions for good concurrency beyond the scope of the task scheduler or RTOS. This normally requires non-blocking functionality at the driver level. This is where hardware assisted event driven concurrency features like DMA are needed. It greatly reduces the usage of CPU and interrupts so real-time reactive processes can meet time schedules.

Code fragment to clear display buffer memory with zeros

// some defines from elsewhere
#define DMA_MAGIC    1957
#define USE_DMA // use DMA spi driver

#ifdef USE_DMA
#define    DMA_GAP        1    // set to 0 for SPI byte gaps in DMA transmissions
#define DMA_STATE_M
#endif

#ifndef DMA_STATE_M
#define USE_INT // SPI driver uses interrupts
#endif

#define    cbOledDispMax        3840 //max number of bytes in display buffer
// stuff

/***    OledClearBuffer
 **
 **    Parameters:
 **        none
 **
 **    Return Value:
 **        none
 **
 **    Errors:
 **        none
 **
 **    Description:
 **        Clear the display memory buffer.
 */

/* just clears a output timing flag bit */
void CBDmaChannelHandler(DMAC_TRANSFER_EVENT event, uintptr_t contextHandle)
{
    if (event == DMAC_TRANSFER_EVENT_COMPLETE) {
        DEBUGB0_Clear();
    }
}

void OledClearBuffer(void)
{
    uint8_t * pb;

    DEBUGB0_Set();
    if (disp_frame) {
        pb = rgbOledBmp0;
    } else {
        pb = rgbOledBmp1;
    }

#ifdef USE_DMA
    /*
     * DMAC_ChannelCallbackRegister in OledInit
     */
    while (dstate != D_idle);
    wait_lcd_done();
    /* setup the source and destination parms */
    DMAC_ChannelTransfer(DMAC_CHANNEL_1, (const void *) rgbOledBmp_blank, (size_t) 4, (const void*) pb, (size_t) cbOledDispMax, (size_t) cbOledDispMax);
    DEBUGB0_Clear();
    DEBUGB0_Set();
    DCH1ECONSET = _DCH1ECON_CFORCE_MASK; // set CFORCE to 1 to start the transfer
#else
    int32_t ib;

    /* Fill the memory buffer with 0.
     */
    for (ib = 0; ib < cbOledDispMax; ib++) {
        *pb++ = 0x00;
    }
#endif
    DEBUGB0_Clear();
    DEBUGB0_Set();
}

Code fragment to send display buffer memory to display via SPI. The DMA method uses a event driven non-blocking state machine in the DMA completion callback 'SPI3DmaChannelHandler' to update the next DMA to SPI transfer for handling the display paging commands between display memory bank updates.

/***    OledUpdate
 **
 **    Parameters:
 **        none
 **
 **    Return Value:
 **        none
 **
 **    Errors:
 **        none
 **
 **    Description:
 **        Update the OLED display with the contents of the memory buffer
 */

void OledUpdate(void)
{
#ifdef DMA_STATE_M
    wait_lcd_done();
    SPI3DmaChannelHandler_State(0, DMA_MAGIC); // set DMA state machine init mode to start transfers
    return;
#else
#ifdef EDOGS
    int32_t ipag;
    uint8_t* pb;

    if (disp_frame) {
        pb = rgbOledBmp0;
    } else {
        pb = rgbOledBmp1;
    }
    rgbOledBmp_page[4] = 0;

    for (ipag = 0; ipag < cpagOledMax; ipag++) { // mainline code loop for GLCD update
        /* Set the page address
         */
        //Set page command
        //page number
        /* Start at the left column
         */
        //set low nibble of column
        //set high nibble of column
        lcd_moveto_xy(ipag, 0);
        /* Copy this memory page of display data.
         */
        OledPutBuffer(ccolOledMax, pb);
        pb += ccolOledMax;
    }
    DEBUGB0_Clear();
#endif
#endif
}

/*
 * start a GLCD update: Called in user code with contextHandle set to DMA_MAGIC for a background screen update,
 * during background transfers this function is used as the callback for DMA transfer complete events to
 * sequence commands and data to the GLCD via the SPI port using the dstate ENUM variable
 * dstate is set to 'D_idle' when the complete set of transfers is done.
 */
void SPI3DmaChannelHandler_State(DMAC_TRANSFER_EVENT event, uintptr_t contextHandle)
{
    static int32_t ipag; // buffer page number
    static uint8_t* pb; // buffer page address

    DEBUGB0_Set(); // back to mainline code, GLCD updates in background using DMA and interrupts
    LCD_UNSELECT();
    if (contextHandle == DMA_MAGIC) { // re-init state machine for next GLCD update
        dstate = D_init;
    }

    switch (dstate) {
    case D_init:
        ipag = 0;
        if (disp_frame) { // select flipper buffer
            pb = rgbOledBmp0;
        } else {
            pb = rgbOledBmp1;
        }
    case D_page: // send the page address commands via DMA
        LCD_SELECT(); // enable the GLCD chip for SPI transfers
        dstate = D_buffer;
        lcd_moveto_xy(ipag, 0); // calculate address data nibbles and store in rgbOledBmp_page array
        /*
         * DMAC_ChannelCallbackRegister and SPI setup in OledInit
         */
        LCD_CMD();
        DMAC_ChannelTransfer(DMAC_CHANNEL_0, (const void *) rgbOledBmp_page, (size_t) 4, (const void*) &SPI3BUF, (size_t) 1, (size_t) 1);
        break;
    case D_buffer: // send the GLCD buffer data via DMA
        ipag++;
        if (ipag <= cpagOledMax) {
            LCD_SELECT(); // enable the GLCD chip for SPI transfers
            dstate = D_page;
            LCD_DRAM();
            DMAC_ChannelTransfer(DMAC_CHANNEL_0, (const void *) pb, (size_t) ccolOledMax, (const void*) &SPI3BUF, (size_t) 1, (size_t) 1);
            pb += ccolOledMax;
        } else {
            dstate = D_idle;
            LCD_UNSELECT(); // all done with the GLCD
        }
        break;
    case D_idle:
    default:
        LCD_UNSELECT();
        break;
    }
    DEBUGB0_Clear();
}

Without USE_DMA defined (using OEM interrupt drivers) we have blocking and a large usage of interrupts and cpu power that cause cause timing jitter and task latency.


With USE_DMA defined (display internal DMA driver) we have removed the major cause of blocking (memory clears and display updates run without cpu intervention), increased function speed and greatly improved system timing stability.

 

Duh - I wasn't using DMA, clearly that would have saved me clock cycles on the processor. I'm guessing the Broadcom chip on the RPi has a DMA - I just didn't put everything together. However, a CPU dedicated to the task should have been able to keep it going just fine I think, and the prof. has confirmed this more than once. He may have even restricted the use of DMA for the sake of the project. It's been a year since I was in the class.

I suspect I just have a small error in code somewhere.

 

Duh - I wasn't using DMA, clearly that would have saved me clock cycles on the processor. I'm guessing the Broadcom chip on the RPi has a DMA - I just didn't put everything together. However, a CPU dedicated to the task should have been able to keep it going just fine I think, and the prof. has confirmed this more than once. He may have even restricted the use of DMA for the sake of the project. It's been a year since I was in the class.

I suspect I just have a small error in code somewhere.

The RPi does have DMA and the modern SPI driver on the RPi can use DMA if if prodded in the right way. Using dedicated cores on the RPi is an option that I've used on a few kernel drivers to improve timing jitter.
https://forum.allaboutcircuits.com/threads/raspberry-pi-daq-system.75543/post-867538

I used kernel threads with a dedicated core per thread.

devpriv->ai_spi->daqgert_task = kthread_create_on_node(&daqgert_ai_thread_function, (void *) dev,
     cpu_to_node(devpriv->ai_node), "%s_a/%d", name_ptr, devpriv->ai_node);

I then create a wait queue for that core thread and make it TASK_UNINTERRUPTIBLE for the scheduler while running.

static DECLARE_WAIT_QUEUE_HEAD(daqgert_ai_thread_wq);

static int32_t daqgert_ai_thread_function(void *data)
{
    struct comedi_device *dev = (void*) data;
    struct comedi_subdevice *s = dev->read_subdev;
    struct daqgert_private *devpriv = dev->private;
    struct spi_param_type *spi_data = s->private;
    struct spi_device *spi = spi_data->spi;
    struct comedi_spigert *pdata = spi->dev.platform_data;

    if (!devpriv)
        return -EFAULT;
    dev_info(dev->class_dev, "ai device thread start\n");

    while (!kthread_should_stop()) {
        while (unlikely(!devpriv->run)) {
            if (devpriv->timer)
                schedule();
            else
                wait_event_interruptible(daqgert_ai_thread_wq, test_bit(AI_CMD_RUNNING, &devpriv->state_bits));

            if (kthread_should_stop())
                return 0;
        }

// rest of code
}

https://www.halolinux.us/kernel-reference/wait-queues.html

A userland DMA example: https://iosoft.blog/2020/11/16/streaming-analog-data-raspberry-pi/

 

I personally think most systems will be RTOS as we learn more about AI, robotics, and ML and that these areas of study will be all closely related.

I read in some article that machine learning AI project requires powerful CPU, fast speed, large memory. Like I asked for a room cleaning robot in one of my thread. what microcontroller should i use if i really think about making it. I mean what should be the capability of the microcontroller

 

Like I asked for a room cleaning robot in one of my thread. what microcontroller should i use if i really think about making it. I mean what should be the capability of the microcontroller

For every MCU implementation, firstly decide how many external connections (for sensors and actuators) you need. This determines how many and what kind of peripherials the MCU must have. Secondly you must decide how complex will be the algorithm and what is the sensors/actuators data speed rate (and also the collected amount of data). This determines how much speed and data memory the MCU must have. From this data you can also determine minimal data bus widh for MCU/CPU/GPU (8 to 64 bit). So you can control a room cleaning robot with 8-bit MCU or if you want to use cameras for sensors then you will maybe need some 64-bit CPU or even more.

 

For every MCU implementation, firstly decide how many external connections (for sensors and actuators) you need. This determines how many and what kind of peripherials the MCU must have. Secondly you must decide how complex will be the algorithm and what is the sensors/actuators data speed rate (and also the collected amount of data). This determines how much speed and data memory the MCU must have. From this data you can also determine minimal data bus widh for MCU/CPU/GPU (8 to 64 bit). So you can control a room cleaning robot with 8-bit MCU or if you want to use cameras for sensors then you will maybe need some 64-bit CPU or even more.

I am providing a basic idea without going into more detail,

Here is the basic list of hardware parts.

Raspberry Pi 3
Motor drivers
Motors
Camera.

Need to develop an intelligent software that can make its own decisions and clean any room.

Edit : Mostly my question is focused on software. Which machine learning algorithm will be suitable for developing this type of system?