µC/OS-III

[SuperMiguel]

So what exactly is µC/OS-III, and the renesas rx62n, what exactly can you do with it? How is it different from an AVR or an PIC

[EEVblog]

µC/OS-III is what's called a "real time operating system"
That lets you process many things at once without having to worry about the finer details of interrupts and juggling things yourself, as you would if you had to write the C program from scratch. It provides lots of high level functions you can use to perform various tasks.

With many products, once the complexity gets to a certain level it usually requires an operating system of some sort. e.g. mobile phones, tablets, ebook readers etc all run on operating systems. So you can play MP3's and surf the web at the same time or whatever.

The rx62n is a powerful 32bit microcontroller, no different to PIC or AVR's, just a different architecture, just as PIC's and AVR are different. Both PIC and AVR have 32bit versions too.

Dave.

[scrat]

µC/OS-III is what's called a "real time operating system"
That lets you process many things at once without having to worry about the finer details of interrupts and juggling things yourself, as you would if you had to write the C program from scratch. It provides lots of high level functions you can use to perform various tasks.

With many products, once the complexity gets to a certain level it usually requires an operating system of some sort. e.g. mobile phones, tablets, ebook readers etc all run on operating systems. So you can play MP3's and surf the web at the same time or whatever.

The rx62n is a powerful 32bit microcontroller, no different to PIC or AVR's, just a different architecture, just as PIC's and AVR are different. Both PIC and AVR have 32bit versions too.

Dave.

I'm used to write code almost only for control, so I'm not familiar with multiple concurrent tasks.
Are RT OSes used also in applications with lower complexity than the ones you mentioned, in your experience?
I mean things that have a mix of interrupt and non-interrupt driven tasks, such as something with a user interfaces and real-time control, for example.
Personally, I won't use something other than transparent code for things like acquiring samples and applying control actions, if I need precise timing...

[EEVblog]

I'm used to write code almost only for control, so I'm not familiar with multiple concurrent tasks.
Are RT OSes used also in applications with lower complexity than the ones you mentioned, in your experience?
I mean things that have a mix of interrupt and non-interrupt driven tasks, such as something with a user interfaces and real-time control, for example.
Personally, I won't use something other than transparent code for things like acquiring samples and applying control actions, if I need precise timing...

RTOS's can guarantee you timing whilst doing other tasks, that's one of their jobs.
Yes, pretty much anything with an advanced UI you can be fairly sure uses some form of OS.
Yes, RTOS's can be used in relatively simple projects, because their high level approach allows you to do a lot of stuff with minimal effort.

Dave.

[SuperMiguel]

I'm used to write code almost only for control, so I'm not familiar with multiple concurrent tasks.
Are RT OSes used also in applications with lower complexity than the ones you mentioned, in your experience?
I mean things that have a mix of interrupt and non-interrupt driven tasks, such as something with a user interfaces and real-time control, for example.
Personally, I won't use something other than transparent code for things like acquiring samples and applying control actions, if I need precise timing...

RTOS's can guarantee you timing whilst doing other tasks, that's one of their jobs.
Yes, pretty much anything with an advanced UI you can be fairly sure uses some form of OS.
Yes, RTOS's can be used in relatively simple projects, because their high level approach allows you to do a lot of stuff with minimal effort.

Dave.

so its easier program this, than it is to program an avr?

[joelby]

so its easier program this, than it is to program an avr?

It depends entirely on what your program is doing. Bear in mind that there are RTOSes that run on AVRs too, such as FreeRTOS and Contiki.

Once your software gets to a certain level of complexity and concurrency, you may end up essentially writing your own third-rate operating system to schedule tasks. If this happens, you may be better off using an existing, proven operating system. There's an additional learning curve involved in mastering the operating system, but the idea is that in the long run it'll save you time by not having to re-invent the wheel.

[SuperMiguel]

so its easier program this, than it is to program an avr?

It depends entirely on what your program is doing. Bear in mind that there are RTOSes that run on AVRs too, such as FreeRTOS and Contiki.

Once your software gets to a certain level of complexity and concurrency, you may end up essentially writing your own third-rate operating system to schedule tasks. If this happens, you may be better off using an existing, proven operating system. There's an additional learning curve involved in mastering the operating system, but the idea is that in the long run it'll save you time by not having to re-invent the wheel.

Ummm so the programming part it self, becomes easier when using an operating system compared with an 8bit programming

[joelby]

Ummm so the programming part it self, becomes easier when using an operating system compared with an 8bit programming

Not necessarily. Programming is still programming. The operating system might provide services like process or thread management and libraries (such as IP and radio communications and file systems). It could be easier to use an existing operating system than reinventing all of this your own, unless your requirements are simple and you know what you're doing, and unless the operating system is so complicated that it would be quicker to reinvent it anyway.

It really depends on what you're trying to achieve.

[tyblu]

Program complexity increases like this:
[1] linear tasks
[2] interrupt-driven tasks
[3] state machine
[4] RTOS, no timing requirements
[5] RTOS, with timing requirements (cell phone, etc.)
[5.1] RTOS, with hard timing requirements (switchgear, etc.)

Application complexity in context of a RTOS is dependent on a whack-load of things including, but not limited to: portability, documentation, available API, compile-time options, timing requirements, RAM type, peripheral and IO configurations, etc.. It doesn't get any simpler than programming a bare-bones 8-bit micro with a proprietary IDE (that takes care of the makefile, linking, target options, etc.). Some RTOS's come with language libraries like Java, but still require that you (port) configure and compile the kernel for your specific chip, requirements, and peripheral configuration.

<edit> Some dev boards come with chips preprogramed with a bootloader or interface that allows you to write code in a preconfigured environment.

[Hypernova]

Personally I have only used uC/OS-II. It was a school assignment and we had to do a froggers game on a NIOS cpu in ucos and Esterel, I opted to do the ucos part alone and let the other two guys in the team do the Esterel version which looked crazy.

You don't really need a RTOS if you don't have many threads, just a micro with several levels of interrupt priority will do, the Atmel xmega for example has 3 levels. Every thread runs on it own level and all of them can be said to be running concurrently. You can run 4 threads if you also have your least timing constrained task at the bottom while(1){} loop. the CM3 core in the mbed can do even better at 32 int levels. Using RTOS consumes a lot of overhead in terms of flash and ram if you are just doing simple stuff.

[scrat]

Are RT OSes used also in applications with lower complexity than the ones you mentioned, in your experience?
I mean things that have a mix of interrupt and non-interrupt driven tasks, such as something with a user interfaces and real-time control, for example.

RTOS's can guarantee you timing whilst doing other tasks, that's one of their jobs.
Yes, pretty much anything with an advanced UI you can be fairly sure uses some form of OS.
Yes, RTOS's can be used in relatively simple projects, because their high level approach allows you to do a lot of stuff with minimal effort.

Dave.

Thanks Dave. It seems that start tinkering with an RTOS would be a good thing for learning...

[rstofer]

You might find that using an RTOS, even when not strictly required, helps modularize the code and results in something much easier to follow.  Some interrupt process sets a semaphore.  Fine, a couple of lines of code and that process is done.  Some other process is waiting for the semaphore.  It sees it, does what is required and that process is done.  But it takes its turn based on priority.  Same story for a lot of other processes.  Individually, each process can be short and tight, communicating through the features of the RTOS.

Managing complexity...

The way it really works:  An interrupt is generated in hardware and a branch is taken to the interrupt handler (based on interrupt priority).  The interrupt handler tells the RTOS to set a semaphore and exits the handler to the RTOS scheduler.  The RTOS sees the semaphore and looks around to see if there is a routine waiting on the flag and, if so, and the priority it right, calls the semaphore handler.  That handler runs, generally to completion, and surrenders control back to the scheduler.  It is likely that the interrupted routine will be resumed but there are other possibilities depending on priorities.

https://www.freertos.org/Documentation/RTOS_book.html

FreeRTOS is now supported by Amazon for AWS.

https://aws.amazon.com/freertos/