Do you have any project in your mind for which you will write real time kernel instead of traditional program.

RTOS used only when we need guaranteed response time. when we cannot miss the deadline.

I have read in many posts, articles that many programmers believe that RTOS is a waste of time, while many programmers believe that writing kernels is very useful.

This is a question like a puzzle to me, the more I try to understand it the more I keep getting lost in it. I thought hundred times before posting question should I post it or not post it on forum and finally thought I should try once let's see what is the result.

 

This is because you do not have the experience needed. Take some simple but relevant problems, solve the by various means, then you will understand better.

Try all of these methods to solve the same problem:

1. Polling loop
2. Interrupt driven
3. State machine
4. Cooperative multitasking
5. Preemptive multitasking
6. Ad hoc (invent your own way)

All have their uses, their advantages and their disadvantages. Learn by doing how well they apply to different problems.

Bob

 

I do not agree with the statement

RTOS used only when we need guaranteed response time. when we cannot miss the deadline.

RTOS in my view can be sluggish.. Time dependent, Yes! missing input responses, I would think RTOS WASN'T better for this.
I used to play with a high level RTOS It was .net based and was terrible with instant responses.. It barley coped with human interfaces... I would use single task and interrupts if that be the case..

 

One reason for using RTOS is when you do not have the time and knowledge to implement the required functions on your own. One example is, write a file to removable memory.

 

Try all of these methods to solve the same problem:

1. Polling loop
2. Interrupt driven
3. State machine
4. Cooperative multitasking
5. Preemptive multitasking
6. Ad hoc (invent your own way)

Bob

I have used the first 3 method to blink three LED's with different timing. I use timer, interrupt. That's why I'm focusing on cooperative multitasking.

main problem is to choose the relevant example. Like what would be a relevant example for RTOS? There are many examples available on the internet, but I am having trouble finding which one is the relevant example.

I liked your list @BobTPH

 

You could build on that example by adding buttons that affect the blinking. That gives you a response to asynchronous stimulus, which is essential to why we might want multitasking.

Bob

 

Do you have any project in your mind for which you will write real time kernel instead of traditional program.

RTOS used only when we need guaranteed response time. when we cannot miss the deadline.

A RTOS is mainly used in small embedded because it's what you know, what you have and what's expected. Guaranteed response time (what's the deadline? 50ms, 50us, 50ns, etc ...) is IMO seldom the driving factor for RTOS usage on small embedded systems. Most systems are programmed in a style (Trust and Control of code) that lies between "bare-metal" and RTOS using manufacturer supplied SDK's and drivers. "Real-time" here means 100s of nanoseconds / low microseconds range. That's easily handled with traditional (super-loop non-preemptive task loop with interrupts and DMA) embedded programming methods. Designing good multi-threaded code is not trivial and once you go down that road porting that code to a single single thread of execution is also not trivial.

 

Here is a simple project that can be done in a few ways.

One of the first projects I had in my first job was a flow meter simulator.

I can't remember the exact details, but the unit that I was simulating was a pulsed output signal where the duty cycle was always (something like) 20% duty cycle, but the frequency changed between 0Hz and 50Hz (a little bit of jitter was okay) - The faster the meter spun, the higher the frequency.

The way the simulator was controlled was a potentiometer input.

So far easy, right?

The thing was that one chip needed to emulate 3 flow meters.

You now need to figure a way to multitask between the 3 input/outputs.

 

Here’s a thread that discusses techniques for multi-tasking without an RTOS. it is an implementation of a run-time module for a proprietary language which runs multiple tasks in a cooperative environment. Up to 255 tasks can execute in pseudo parallel (they actually run sequentially, given that the individual execution times do not exceed the available execution time.

 

I've used the 300 series of flow meter with this type of pulsed output. https://proteusind.com/wp-content/uploads/2016/06/300TRM.pdf

With the right 8-bit controller the basic PWM signal generation could be done with hardware modules for all three outputs with minimal cpu processing.
https://ww1.microchip.com/downloads/en/DeviceDoc/40001412G.pdf

 

A RTOS is mainly used in small embedded because it's what you know, what you have and what's expected. Guaranteed response time (what's the deadline? 50ms, 50us, 50ns, etc ...) is IMO seldom the driving factor for RTOS usage on small embedded systems.

@nsaspook
What do you mean by small embedded system. Is 8 bit and 32 bit micro related to small and large embedded systems?

 

Why don't you try and make those traffic lights from the other thread, but make one microcontroller control 2 sets of traffic lights independently.

For bonus points, you can have a serial interface that reads the states of both sets of lights using semaphores

 

You could build on that example by adding buttons that affect the blinking. That gives you a response to asynchronous stimulus, which is essential to why we might want multitasking.

Bob

The button will input for the whole system and the LED will output.

Now what would be the relevant problem for multitasking.

I am showing some example. is the relevant problem?

1. as soon as the button is pressed, the LEDs should blink one by one in sequence.

2. When the button is pressed the three LED should blink for a certain amount of time and the next time the button is pressed again the LED should blink for a certain amount of time

 

Why don't you try and make those traffic lights from the other thread, but make one microcontroller control 2 sets of traffic lights independently.

For bonus points, you can have a serial interface that reads the states of both sets of lights using semaphores

yes in this thread my work is incomplete. I have also explained the reasons why the traffic light system seems complicated to me. i am having trouble with the pedestrian logic.

 

yes in this thread my work is incomplete. I have also explained the reasons why the traffic light system seems complicated to me. i am having trouble with the pedestrian logic.

Australian lights work a bit different, that's why I was not involved in that topic.

If I were you I'd start with just the traffic lights without the pedestrian lights, otherwise you're probably not going to do anything.

Another thing you can do is find a video of some lights in operation and just write down what state they are in during each transition.

Doing two sets of lights that operate independently will be a great project because it will combine everything that you've been learning on here over the past month.

 

@nsaspook
What do you mean by small embedded system. Is 8 bit and 32 bit micro related to small and large embedded systems?

By small I mean something project complexity, not the physical size or bits of the controller.

 

This is what I mean by small. The 8-bit board on the left is a MODBUS master for testing a three phase low power inverter (32-bit board on the right) with a MODBUS client for remote control.

The MODBUS master software (adapted from another MODBUS project) is written in C for a PIC18F1320 8-bit processor. It repeats a series of test commands to send and query data on the inverter via the RS485 link running at 57.6 kb/s. The critical deadline for this task is to be able to receive serial data from the client and store it for later processing before the next byte of serial data arrives. This happens in an ISR that processes the USART receive interrupt.
https://raw.githubusercontent.com/nsaspook/vcan/i400_fix/firmware/pat/ihc_vector.c

    if (PIR1bits.RCIF) { // is data from RS485 port
        cc_stream_file = RCREG;
        /*
         * error check the receiver
         */
        if (RCSTAbits.OERR || RCSTAbits.FERR) {
            cc_stream_file = 0x00; // nulls for data on errors
            RCSTAbits.CREN = OFF; // clear overrun
            RCSTAbits.CREN = ON; // re-enable
            if (c_error++>MAX_C_ERROR) {
                c_error = 0;
                V.error++;
            }
        } else {
            /*
             * process received controller data stream
             */
            cc_buffer[V.recv_count] = cc_stream_file;
            if (++V.recv_count >= MAX_DATA) {
                V.recv_count = 0; // reset buffer position
            }
        }
    }

There is a main super-loop state machine for sequencing the transmission of commands and the replies.
https://github.com/nsaspook/vcan/blob/i400_fix/firmware/pat/ibsmon.c

/*
* simple modbus master state machine
*/
int8_t controller_work(void)
{
    static uint8_t mcmd = G_MODE;
    static comm_type cstate = CLEAR;
    static cmd_type modbus_command = G_MODE;

    switch (cstate) {
    case CLEAR:
        clear_2hz();
        clear_10hz();
        cstate = INIT;
        modbus_command = mcmd++; // sequence modbus commands to client
        if (mcmd > G_LAST)
            mcmd = G_MODE;
        /*
         * command specific tx buffer setup
         */
        switch (modbus_command) {
        case G_SET: // write code request
            rvalue.value = i400_pwm;
            modbus_cc_freset[4] = rvalue.bytes[1];
            modbus_cc_freset[5] = rvalue.bytes[0];
            req_length = modbus_rtu_send_msg((void*) cc_buffer, (const void *) modbus_cc_freset, sizeof(modbus_cc_freset));
            break;
        case G_AUX: // write code request
            rvalue.value = i400_power;
            modbus_cc_clear[4] = rvalue.bytes[1];
            modbus_cc_clear[5] = rvalue.bytes[0];
            req_length = modbus_rtu_send_msg((void*) cc_buffer, (const void *) modbus_cc_clear, sizeof(modbus_cc_clear));
            break;
        case G_ERROR: // read code request
            req_length = modbus_rtu_send_msg((void*) cc_buffer, (const void *) modbus_cc_error, sizeof(modbus_cc_error));
            break;
        case G_MODE: // operating mode request
        default:
            req_length = modbus_rtu_send_msg((void*) cc_buffer, (const void *) modbus_cc_mode, sizeof(modbus_cc_mode));
            break;
        }
        break;
    case INIT:
#ifdef    FASTQ
        if (get_10hz(false) >= CDELAY) {
            get_2hz(false);
#else
        if (get_2hz(FALSE) >= QDELAY) {
            get_10hz(false);
#endif
#ifdef LOCAL_ECHO
            RE_ = 0; // keep receiver active
#else
            RE_ = 1; // shutdown receiver
#endif
            DE = 1;
            V.send_count = 0;
            V.recv_count = 0;
            cstate = SEND;
            clear_500hz();
        }
        break;
    case SEND:
        if (get_500hz(false) > TDELAY) {
            do {
                while (BusyUSART()); // wait for each byte
                TXREG = cc_buffer[V.send_count];
            } while (++V.send_count < req_length);
            while (BusyUSART()); // wait for the last byte
            cstate = RECV;
            clear_500hz();
        }
        break;
/// code omitted for example
}

void main(void)
{
    init_i400mon();
    /* Loop forever */
    while (true) { // busy work
        controller_work();
    }
}

The important time related tasks (serial comms, delay timing, led blinking, etc...) that need to run independently of the main loop are handled in interrupt routines. To convert something small like this to an RTOS is overkill and generates bloatware that's unlikely to fit on a 8-bit chip with 256 bytes of ram and a few K of flash. The 32-bit machine could easily handle the RTOS overhead but it's programmed much the same way as the 8-bit processor without an RTOS while using the 32-bit controllers advanced hardware capabilities to reduce the amount of number of software tasks to a single main thread of execution while handling all realtime inverter functions mainly in background of the main task.

 

I do not agree with the statement

RTOS in my view can be sluggish.. Time dependent, Yes! missing input responses, I would think RTOS WASN'T better for this.
I used to play with a high level RTOS It was .net based and was terrible with instant responses.. It barley coped with human interfaces... I would use single task and interrupts if that be the case..

If you had a problem with an RTOS being unresponsive- it was a problem with the designer not understanding how to actually write an RTOS. You chose the wrong RTOS to use Not you're fault, they misled you.

RTOS's do two things- JUST two things: They manage time and resources. A properly written RTOS makes everything responsive because it establishes independent time loops based on requirements (heuristics, limits, required responsiveness). Time is the fundamental key- or stated another way, managing different rates of time coherently so that everything is serviced appropriately all the time.

For anybody developer who doesn't understand the value of an RTOS, they are missing the point. An RTOS alleviates mundane management of resources- one of those methods is by providing drivers that a developer doesn't have to write (for keypad input, or display work, or RFID reading, or communications protocols, or as an interface to an adjunct piece of hardware.

Letting an RTOS provide these resources, usually in a far more concise way than most developers can manage, means less memory, less processor horsepower and less stack are used, and allowing the developer to write fewer files- in many cases, a simple core file is all a developer has to write, to manage an incredibly robust, powerful, and capable real-time embedded system.

One of the fundamental problems with developers today is just that- they aren't developers, they are amateur hacks. Without the skill, knowledge, drive, and experience to dig into the machine and understand just how powerful any given MCU is, IMHO. Even an 8-bit MCU is far more powerful than most embedded developers will ever need. More than capable of running a full RTOS that is responsive to managing many seemingly simultaneous things at once to 1ms accuracy without missing anything- without MCU horsepower saturation.

 

I've personally found many RTOS drivers to be mundane lowest common denominator bloated monstrosities that seldom take advantage of advanced hardware capabilities because it's an abstraction of a general I/O model with a requirement for task mutex and blocking requirements not needed for most simple embedded programming jobs.

1ms is a lifetime with something as basic as fast serial data so it's likely the RTOS driver will be interrupt driven like the simple non-rtos example with the added (due to multitasking software design) requirement of interacting with the RTOS scheduler.

My simple 8-bit non-rtos interrupt example easily handles task switching requirements at 172us per-character on basic 8-bit hardware with no hardware receiver FIFO buffering.

 

If you had a problem with an RTOS being unresponsive- it was a problem with the designer not understanding how to actually write an RTOS. You chose the wrong RTOS to use Not you're fault, they misled you.

RTOS's do two things- JUST two things: They manage time and resources. A properly written RTOS makes everything responsive because it establishes independent time loops based on requirements (heuristics, limits, required responsiveness). Time is the fundamental key- or stated another way, managing different rates of time coherently so that everything is serviced appropriately all the time.

For anybody developer who doesn't understand the value of an RTOS, they are missing the point. An RTOS alleviates mundane management of resources- one of those methods is by providing drivers that a developer doesn't have to write (for keypad input, or display work, or RFID reading, or communications protocols, or as an interface to an adjunct piece of hardware.

Letting an RTOS provide these resources, usually in a far more concise way than most developers can manage, means less memory, less processor horsepower and less stack are used, and allowing the developer to write fewer files- in many cases, a simple core file is all a developer has to write, to manage an incredibly robust, powerful, and capable real-time embedded system.

One of the fundamental problems with developers today is just that- they aren't developers, they are amateur hacks. Without the skill, knowledge, drive, and experience to dig into the machine and understand just how powerful any given MCU is, IMHO. Even an 8-bit MCU is far more powerful than most embedded developers will ever need. More than capable of running a full RTOS that is responsive to managing many seemingly simultaneous things at once to 1ms accuracy without missing anything- without MCU horsepower saturation.

Whilst I agree with everything you say, An RTOS will be time sliced in a bog standard MCU because they are primarily non multitasking... I have tried several RTOS environments (alas mainly freebees that were probably not powerful enough) That will not read an encoder... To the point I needed to write a kind of "driver" to do the task... Whilst it wasn't out of my remit, I thought.. Why bother... I'm too lazy to jump through the hoops... That's why I gave oop the heave ho...

RTOS has its home... Just not with me.. Incidentally... I love your avatar....