[TUT][SOFT] RTOS for AVR

Go To Last Post
65 posts / 0 new

Pages

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

clawson wrote:

There's quite a range of AVRs from 1K (even a couple of 0.5K) up to 384K. The majority in use are probably 2K..16K. In those "controller apps" the design is often a main loop and perhaps 2..10 interrupt handlers and that's all that's really required to achieve the design. In such chips/designs the use of RTOS (well certainly a preemptive one) is just huge over-kill. Sure if you are programming 64K+ (perhaps even 32K) then the interaction of the processes may get to such a position of complexity that an RTOS will help to coordinate things but for "normal" apps typically found in small 8 bit controllers it saps both available RAM resource and available CPU resource for very little (if any) gain. 

clawson, in my opinion, your point of view is centered on the correct usage of an 8bit microcontroller for doing something. 
Has sense to me, that the normal apps doesn't really needs an real RTOS, but i'm referring on the design of such apps. 
Think about IoT, in this case there are some class of applications that need different level of hardware complexity.
It's difficult to do this kind of project using an approach that doesn't use a RTOS or similar system that offer an abstraction layer between the hardware and the logic of the specific app.
In this case i think that an RTOS simplifies a lot the design phase, although if it consume a lot of resources. The important thing is that the hardware meets the app requirements.

Obviously, nothing is necessary, and one reaches the same thing without using an RTOS, but i think that this way isn't simple for the app designer, if the objective of the app designer is centered on the modelling the software of such app.

 

Kartman wrote:

Consider what you might use an AVR for. My commercial applications involved MODBUS communications using RS485, usually driving relays and/or indicators, sensing switch and analog inputs and doing some basic calculations like average and alarm set points. In some cases there was a simple user interface with a 16x2 lcd and three pushbuttons. The main real-time requirement was MODBUS in that I had to service the usart in time, everything else was not time critical. Relays and indicators don't work much faster than 100ms and likewise with the user interface. All this ran a one thread of execution with a timer and a usart interrupt. In this instance, a RTOS would offer no benefit in either execution time or code 'cleanliness'. Frequently in this low end embedded systems, computer science doctrines go out the window - tricks are used to minimise the code size, improve execution time and to minimise the stack profile. You've also asked about C++ and STL - it is unlikely you'd use the more advanced data structures in an AVR - there's usually not enough ram to use and/or justify them. Consider the overhead of a red/black tree - from memory, there at least 4 pointers per node, so that is 8 bytes on top of the data you search on. In 4K of ram, you're not going to have a very big structure. If you need to search, the size constraint would mean a brute-force search is viable. Also consider that the app is designed to do a specific job - it's configuration is pretty well fixed at compile time. You wouldn't be creating/deleting objects on the fly, notwithstanding the problems with memory allocation. 

So, given a mega328 with 32k flash and 4k ram,what application would justify the use of a RTOS?

Kartman, conceptually you are near at my project!
I'm aware on the limit that offer the 8bit microcontrollers, but I think it's fair to use all the functionalities that offer such kinds of microcontrollers.
If i have 4k of ram, why i can't use full ram for an given application? 
I have implemented a priority queue using the heap algorithm. I know that this data structure it's ram consuming, but the priority queue give me some functionalities, so is normal that i have to pay a price to obtain this kind of service, i'm aware about this.
Maybe there aren't application that really justify the use of a RTOS on an 8bit microcontroller, i haven't a right experience to answer to this question.
My doubts are about the design of such applications, that in my opinion became easier if one use an RTOS or another similar system.

 

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Think about IoT,

Yeah but this 8bit AVR8 we are talking about. You wouldn't pick one of those for an IoT application. Atmel recently announced and launched Cortex M7 devices as being a targeted IoT processor. When you have a few hundred MHz, a few hundred K of flash and 16/32/64K or more RAM then,  yes,  of course you will be using an RTOS. In fact if you move a bit further up the IoT scale you hit the Cortex A devices and there's probably about a 99 out of 100 chance you'll actually be using Linux (though it leaves something to be desired over the "R" in RTOS!). But for a small 8 bit MCU reading a few sensors and operating a few actuators it's still over-kill. 

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Does an RTOS mean pre-emptible tasks?  That is, where one task can be suspended in favor of a higher priority task. 

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

luca80 wrote:

If i have 4k of ram, why i can't use full ram for an given application? 

 

Because when your customer asks you to add 'one small feature' you will find that you have run out of RAM.

'This forum helps those who help themselves.'

 

pragmatic  adjective dealing with things sensibly and realistically in a way that is based on practical rather than theoretical consideration.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

steve17 wrote:
Does an RTOS mean pre-emptible tasks?

Depends on who you ask.

My definition would include cooperative as well as preemptive.

David (aka frog_jr)

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

"One's value is inherent; money is not inherent"

 

Chuck, you are in my heart!

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Just a reminder that this is a tutorial thread, it's not really for a general discussion of the merits of using an RTOS, just for posting feedback to the first post (like additions/corrections) so if this is to continue it should probably be somewhere else. 

 

Moderator. 

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

clawson wrote:

Think about IoT,

Yeah but this 8bit AVR8 we are talking about. You wouldn't pick one of those for an IoT application. Atmel recently announced and launched Cortex M7 devices as being a targeted IoT processor. When you have a few hundred MHz, a few hundred K of flash and 16/32/64K or more RAM then,  yes,  of course you will be using an RTOS. In fact if you move a bit further up the IoT scale you hit the Cortex A devices and there's probably about a 99 out of 100 chance you'll actually be using Linux (though it leaves something to be desired over the "R" in RTOS!). But for a small 8 bit MCU reading a few sensors and operating a few actuators it's still over-kill. 

 

I think that the serious problem that arise on the usage of a RTOS are the MHz. Some weeks ago i have tested my actor framework on the Arduino board. My dummy test it was to send continuosly a message to an actor (proactivity). Every time that the actor is run (the message is arrived) i toggled a pin, so using a poor man oscilloscope (an usb soundcard) i have measured a frequency in the order of 10e0 Khz.

After this test i tryed to print some string in Arduino framework. I repeated the test and i have measured a frequency in the order of 10e0 Hz @ 9600 buad, 10e1 Hz @ 115000 baud. From this, trivially I realized that the frequency play an important role in the use this kind of framework. I think that the ram is an secondary problem, and it depend strongly on how good is the design of the framework.

I'm in part disagree with you when you say 

for a small 8 bit MCU reading a few sensors and operating a few actuators it's still over-kill.

I agree on the fact that for small 8bit MCU, i think you refer at the attiny series, an RTOS is over-kill, but on an atmega128/2560 that run near the their max frequency an RTOS isn't over-kill if you accept that i say before, that with an good design, the consume of the ram isn't a really problem. Obviously, one should be aware about the hardware, I doesn't believe that a RTOS is a magic component that resolve any thing.

However at this moment i not care about the hardware. I'm trying to apply the MBD methodology for develop a project, so i don't know and i don't care about what kind of hardware i need to satisfy my requirements. At this moment my role is like an architect, i need to design a good framework infrastructure, after that i can choose my hardware.

 

Brian Fairchild wrote:

Because when your customer asks you to add 'one small feature' you will find that you have run out of RAM.

 

This is a good tip, thank a lot! 

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I said the switch point is probably somewhere between 32K and 64K of code so we're in total agreement aren't we? But in this day and age if folks are looking at 64K+ flash then surely they are going to pick Cortex M or even Cortex A? I doubt many choose 64K+ AVR in volume production do they? This is 2016, not 1996!

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Yes, we are in total agreement but only on the switching point! :) 

It's true that this is 2016 and a fortiori think that the use of an RTOS is not prohibitive for a 8-bit microcontroller like an atmega2560 for do some task like acquiring a sensor signal or control an actuator.

Here we are speaks about RTOS on the 8bit microcontroller so for curiosity i have ask a question about the RTOS.

I'm well aware that we are in 2016. It is not the case I'm trying to use the MBD approach for my project. Following the MBD, the hardware is just an implementation detail! ;)

 

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

However, the your range is very similar with range cited in this article: http://www.ti.com/lit/wp/spry238/spry238.pdf and obviosly, the author of this article think like you.

What I meant it is mainly reported in paragraph 3 of Article. In this sense, the choice on the use of an RTOS for an 8-bit microcontroller is motivated by the fact that a good software architecture inevitably requires the use of an abstraction layer between the hardware and the software. For me it makes sense to accept a decrease in performance (an RTOS on a microcontroller 8bit) if it takes me a serious advantage for my software architecture.
Simple processes that require the use of time and a certain formalism (eg PID or other control systems), can be executed on a microcontroller 8bit (eg ATmega128 / 256), in these cases the use of an RTOS is not essential but much easier life is at the project level and is at the implementation level. This is what I would say based on my limited experience in embedded systems.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Luca, we would like to think that all embedded projects are like pink fluffy unicorns dancing on rainbows, but the reality isn't quite as cosy. When you need the performance, then niceties like abstraction go out the window. Many times, poor decisions (on reflection) have been made and you're committed, so you just have to make it work. Or there's an existing product you need to add features to. The list goes on. I had to give a motivational speech to a programmer than was seconded to the team recently to remind him that what they teach at school doesn't necessarily reflect the commercial world. Do we want pretty code that doesn't work, or code that works?

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Kartman, I understand your motivations and those of clawson only that I agree in part with you. Let me give an example:

I have a Esc, and I have to design an application to make it work. At the moment, I do not know the hardware on which this application should run. 

It can be an ATtiny, an atmega or.. Well, how I can design this application?
Using oop, I can create two classes that help me to abstract the logic of the ESC and the logic of the hardware. Using the uml
 formalism, I should do something like this:

please ignore the number and the operator + in the association link, also ignore the Eint type, i'm new to papyrus and at this moment i don't know how hide this symbol and use the standard type.

 

This diagram show an important features that is the abstraction. In this case it is rappresented with the PwmIF interface. In this contex the PwmIF interface work like an HAL, an Hardware Abstraction Layers.

I use it to separate the logic of the ESC from the hardware. If my final hardware is an attiny, i need an another class (es AttinyPwm) that extend the PwmIF, same thing if my hardware is a corterx arm or an atmega microcontroller.

So, in this case if you adopt this design, for this simple application, you need 3 class (the Esc class, the PwmIf and the AttinyPwm for ex) and the main obviosly.

Question, are all this class necessary for make this simple application? Maybe not, but this design meets all requirements of this application and, more important, in this way the software is very portable because you have designed it without know nothing about the hardware. But how about the performance? There is a overhead due this design. This is true, but i'm aware of this overhead and i accept it because it is a price that i pay to meets the requirements.

This is that i mean when i express my opinion on the use of a RTOS on an 8bit microcontroller. I prefer to pay something in term of performance at the expense of a good design.

I don't know if this is a good o bad, maybe someone have some cripticism about it, but it work and the code is pretty to read and mantain.

Obviosly there are some application in which this kind of design doesn't work due the overhead, so you can analyse the application before to suggest any desgin, due to my little experience this is my forma mentis.

In the real wold, there are some other factors (like time to develop, the whims of the customer etc) that actually may negatively affect the choice of a type of design, and should be taken into account.

I'm not have considered this aspect, but maybe i should! :)

 

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

clawson wrote:

Just a reminder that this is a tutorial thread, it's not really for a general discussion of the merits of using an RTOS, just for posting feedback to the first post (like additions/corrections) so if this is to continue it should probably be somewhere else. 

 

Moderator. 

So locked. If anyone has suggestions / corrections for the list in the first post contact a Moderator who will unlock this for you. 

Pages