RTOS Discussion?

Go To Last Post
52 posts / 0 new

Pages

Author
Message
#1
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I'm using Salvo Pro for a product that has multiple AVR's communicating over an I2C bus. The documentation for Salvo is excellent and the tutorials very helpful.

This is the first Cooperative RTOS that I've used and it has taken me awhile to readjust my thinking on how to structure a solution without the use of preemption.

It has also taken me awhile to get my head wrapped around the fact that I can not invoke an OS service that would block in a function that was called from a task. Any OS service that returns control to the scheduler must be called only from within a task itself. However, I do understand the reason for this.

Here'a an example. I've written several functions to control the character LCD. One of these functions clear the display. Since the clear operation takes up to 1.6mS, my first thought was to call to OS_Delay() with a 1 tick delay in the LCD_Clear function itself. But this is not permitted. So, I have to have the OS_Delay() call in the task after the call to LCD_Clear(). This makes it a bit more of a challenge to isolate the low-level code from the application code.

My solution was to wrap up all of the LCD control functions into a single task that waits on a message queue. My application code creates a message with the appropriate arguments and (after obtaining a lock on the LCD) passes this message (a pointer to a struct of type lcd-control) to the lcd control task. All low-level LCD operations are handled in this lcd control task. I do have higher level operations such as LCD_Printf() that I call from a task in the application. These higher-level functions handle the work of creating and sending the message to the lcd control task.

Overall, I find Salvo to be a solid RTOS for use with the AVR. I also like the fact that it is avalable for other processor platforms.

What RTOS are you using on the AVR?

Does anyone else have experience with Salvo?

-Tom
[/i]

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

I am on my way to start a new project using RTOS...
I am planning to use ucOS II (not sure yet).
As I saw recently, Salvo is extremely expensive, right?

BTW: I am still in the research stage on RTOS, but I will definitely go for a preemptive RTOS, not for a cooperative OS.

Real men don't use backups, they post their stuff on a public ftp server and let the rest of the world make copies.

Last Edited: Mon. Dec 19, 2005 - 10:39 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Well, I am a single developer working for myself (no paycheck until done) on a product that I plan to release sometime in March of next year. I have customers waiting to buy this product and have received much input from them during the design process. I look at an RTOS as a development tool as much as I look at an oscilloscope, logic analyzer, I2C/SPI analyzer, DVM, etc. as development tools. I wouldn't think of developing this product without an RTOS. I did look at other RTOS options for the AVR but selected Salvo based on documentation, maturity, and availability on other processing platforms that I use.

The price for the Salvo PRO version for the AVR - $1250, the value of the time I save in design, debugging, and maintenance - priceless. Salvo may not be the best choice for everyone and you may not need the PRO version. Take a look at the other options out there.

-Tom

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

I also looked at ucOS II, but the memory footprint of some of the devices in my system are too small for this but are supported by Salvo. I see a huge benefit in having a single RTOS across the entire product line. I have also used ARM, MPS430, and PIC and Salvo also supports these processors. Code re-use across platforms should save me much time (money) on future product development.

-Tom

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

Well... many of us here at AvrFreaks are single developers...
Now, speaking only for myself, I can not afford to pay that much for an OS. Needless to say, I can do the project without a RTOS, but... anyway... I wouldn't compare the AVR-OS with a scope, for instance.
OTOH, there are also free RTOS out there, open-source, etc.
But, ok... I may be subjective here :-)

Real men don't use backups, they post their stuff on a public ftp server and let the rest of the world make copies.

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

zoomcityzoom wrote:
I also looked at ucOS II, but the memory footprint of some of the devices in my system are too small for this but are supported by Salvo. I see a huge benefit in having a single RTOS across the entire product line. I have also used ARM, MPS430, and PIC and Salvo also supports these processors. Code re-use across platforms should save me much time (money) on future product development.

Yes, you're right!
I can see the point and I must agree with you! 100% !

BTW: PRO version entitles you to have also the full source code, right?

Real men don't use backups, they post their stuff on a public ftp server and let the rest of the world make copies.

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

Yes, the Pro version includes the full source. This may result in a smaller memory requirement than when using the library only version. The full manual is available for downaload as is restriced versions of the RTOS.

-Tom

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

Yuck… unfortunately, there’s no lib for CodeVision :-(

Real men don't use backups, they post their stuff on a public ftp server and let the rest of the world make copies.

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

There is some limitation in CodeVision that prevents Pumpkin from supporting it. Something to do with pointers to functions. I read about it somewhere, but I cannot find the info now. I was using CodeVIsion before I started this project but had to switch to a Salvo supported compiler.

-Tom

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

Quote:
Something to do with pointers to functions.

Pointers to functions are ok in CodeVision... Trust me, I am using CodeVision :-)
Quote:
but had to switch to a Salvo supported compiler

IAR maybe? :wink:

Real men don't use backups, they post their stuff on a public ftp server and let the rest of the world make copies.

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

No, I switched to ICCAVR. Like I said, I don't remember exactly why Salvo could not be compiled with CodeVision. Send a message to support at Pumpkin and ask them?

-Tom

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

Stanley,

IIRC, uCos is nice, but to use it in a commercial product has fairly steep licensing fees! $1250 one time might look good!

Randy

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

Only a single developer. So too pricely but seem nice!
groenhen look at nut/os www.ethernut.de Maybe it suite your needs.

Power too the NUT :)

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

An other nice RTOS is FreeRTOS:

http://www.FreeRTOS.org

Curently there are AVR-ports for GCC and IAR avaiable. For me it was easy to port the included example to an AtMega128.

But so far, I don't have any further experiences with FreeRTOS. Does anybody else have...?

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

rstahlhu wrote:
Stanley, IIRC, uCos is nice, but to use it in a commercial product has fairly steep licensing fees! $1250 one time might look good!

Well... the cost of a RTOS varies between $0 and $10,000.
But, for me the difficulty is to select the right RTOS for my project.

Real men don't use backups, they post their stuff on a public ftp server and let the rest of the world make copies.

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

Quote:
Send a message to support at Pumpkin and ask them?

You can't just compile it, you need a task switcher to be written in assembly for your compiler. This changes based on how the compiler stores the stack - so it will be specific to the compiler.

-Colin

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

If i was to look into an RTOS i would definately give FreeRtos a glance

FreeTros is free.
But ported to a lot of platforms

uCos seems nice but is $$$
Advantage : Tested and approved for some "Critical" apps.

/Bingo

/Bingo

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

zoomcityzoom wrote:

Here'a an example. I've written several functions to control the character LCD. One of these functions clear the display. Since the clear operation takes up to 1.6mS, my first thought was to...

That sounds like your real problem. Take a look at the spec for your LCD: it should come with a "clear screen" function anyway that would not take up to 1.6ms to clear.

Eric

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

Actually, this is not my real problem. It was just one example of many where I am trying to keep the hardware related code seperate from the application code. The clear display operation may take anywhere from 82uS to 1.64mS according to the display datasheet.

My solution to create a device driver task seems to be the recommended approach according to posts on the Salvo user forum. The advantages keeping a small memory (SRAM) footprint (as well as very little stack usage) with Salvo more than outweigh any disadvantages to using a cooperative RTOS.

Eric, do you use an RTOS for any of your AVR projects?

-Tom

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

Hi Zoom. Wondering where on the planet you are. Just curious. Also wondering if you have a 'test' for the combination of requirements that calls for moving from 'loop of subroutine calls with interrupt handlers' to 'two or more separate tasks that might or might not communicate'. Usually the loop model works at simulating multitasking if all the little tasks complete within the loop time. If there is one big time hog subroutine that needs to be preempted, or if one of the tasks is 'asynchronous' to the loop time, like terminal input, these are easier with tasks.. they are like little mini standalone programs. Agree so far? You have other 'rules of thumb' you use when partitioning a problem into tasks?

Imagecraft compiler user

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

EW wrote:
zoomcityzoom wrote:

Here'a an example. I've written several functions to control the character LCD. One of these functions clear the display. Since the clear operation takes up to 1.6mS, my first thought was to...

That sounds like your real problem. Take a look at the spec for your LCD: it should come with a "clear screen" function anyway that would not take up to 1.6ms to clear.

Eric

Actually Eric, a quick look at the HD44780 datasheet I have quotes 1.64mS for the clear display function, assuming a clock of 250kHz.

Writing code is like having sex.... make one little mistake, and you're supporting it for life.

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

bobgardner wrote:
Also wondering if you have a 'test' for the combination of requirements that calls for moving from 'loop of subroutine calls with interrupt handlers' to 'two or more separate tasks that might or might not communicate'.

I use to put much thought into this, but not anymore. Now, I will almost always pick the processor based on the fact that I can find an RTOS that supports it. I have found that solving a problem with the aide of an RTOS will almost always result in shorter development time as well as a simpler, more elegant solution that is easier to maintain with a greater possibility to reuse code on another project. The fact that Salvo supports a great deal of processor families and, in particular, almost all of the Atmel AVR processors is icing on the fruitcake.

Notice that I did use the word "almost" two times. There are always exceptions...

-Tom

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

Here is the response I received back from Andrew regarding my query about why Salvo has not supported CodeVision:

Quote:
Hi Tom.

The reason is that CodeVision does not use a linker -- its "libraries" are
really just source code, encrypted. So for us to offer support for
CodeVision, we'd either have to

1) Say "Yes, we support it, but you can't try it until you buy it (i.e. no
Salvo Lite), or

2) Make "libraries" for CodeVision and have them hacked within a week, with
full Salvo source code out there.

I would like to support CodeVision, so I'm open to suggestions ...

--Andrew

-Tom

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

So is your 'simple project template' that you start with one task and the rtos, and you build on that? Any advantage or disadvantage to shipping a project with one task that runs every n ticks?

Imagecraft compiler user

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

bobgardner wrote:
So is your 'simple project template' that you start with one task and the rtos, and you build on that? Any advantage or disadvantage to shipping a project with one task that runs every n ticks?

It could be, but I've never had a single task project. I started to provide an example but then erased it. Take a look at chapter 2 (page 11) of the Salvo User Manual for a nice discussion of RTOS fundamentals and the real-world example on page 39. I'd be happy to discuss their example.

-Tom

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

BTW, here is a link to the manual:

http://www.pumpkininc.com/conten...

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

Hi Bob!

Quote:
Any advantage or disadvantage to shipping a project with one task that runs every n ticks?

A friend of mine from Slovenia already did that... He hates RTOSs, but his boss insisted on using an OS for a device (not AVR inside, but that's not important). He adopted a (somehow) strange solution: he implemented an application with only one task!!!... based on some older source code he had in the drawer... Well, his program is... fine, it works ok, but I consider it a weird implementation as it doesn't take real advantage from multi-tasking (his programming outlook was far behind the RTOS's potential).

Real men don't use backups, they post their stuff on a public ftp server and let the rest of the world make copies.

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

Y'all with this pre-emptive RTOS stuff obviously haven't packed any "real" microcontroller apps into Mega48-class resources, IMO.

Signed, an old bit jockey.

Chapter 2: "Well, then I'll use non-preemptive." OK, fine, minimizes or eliminates most of my objections. But that really isn't any different than my hand-crafted app with needed ISRs setting flags for the mainline loop to say: "That flag is set so that 'task' is ready to be run."

Chapter 3: I can bow to the arguments for an RTOS on all projects when there are multiple programmers involved, either on the same project or you want the various team members to be able to interchange easily. But I won't agree that the final app will be "as good" and definitely not "better" than one in which an experienced AVR programmer has license to make changes to the RTOS rules of engagement to end up with a faster/tighter end application, using the subsystems as best fit the app not the politically-correct rules of program formation.

Chapter 3a: I could agree that a working functional high-level program can be created as fast with an RTOS (pre-emptive or no) versus "hand crafted". But not faster.

Appendix: I've had a lot of apps recently where my tried-and-true USART stuff needed modification for the characterstics of attached devices -- weird framing, sync bits or bytes, etc. The RTOS ain't gonna help get that done any faster. In fact I would argue the opposite--I >>know<< where I need to make the tweaks and what might be affected.

Lee

You can put lipstick on a pig, but it is still a pig.

I've never met a pig I didn't like, as long as you have some salt and pepper.

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

Lee, OK then, but there is no denying the fact that code can be developed much faster using the emacs editor than with any other editor.

Kidding... Tom

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

I am not a RTOS-fan, but I would really like to try a minimal (free if any) RTOS on my AVR.
I am thinking of a RTOS with maximum 2kbytes that should not eat more than 2-3% of my CPU time.
The reason I am thinking of using a RTOS... well, I hope to get a better task management/control, as I already counted 10 tasks and I got scared when I saw the draft flowcharts... so many delays, timeouts, flags, etc. and somehow all task need to respond/react fast!
Ok, finally I need to concentrate on simple (small?) tasks as quasi-independent entities and leave the complexity of their management (control and inter-task communication) to RTOS and maybe I could save some precious time...

Real men don't use backups, they post their stuff on a public ftp server and let the rest of the world make copies.

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

Stanley,
Check out csRTOS abstract and csRTOS files

I have used it with winAVR. It is free, easy to modify, leightweight, and easier for me to understand than a state machine.

Greg

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

glitch wrote:

Actually Eric, a quick look at the HD44780 datasheet I have quotes 1.64mS for the clear display function, assuming a clock of 250kHz.

Hmpf. Thanks for checking that. I wasn't aware that it took that long.

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

I've also used PR_RTX from PRLLC with good success on a previous product.
http://www.prllc.com/productcart...

I have to agree with Lee that for a resource limited embedded system, a solution with an RTOS may not be smaller or faster to develop than a handcrafted application. However, when it comes to modifying the code or adapting it for another system a year later, the structure of the solution imposed by designing with an RTOS usually pays for itself. Especially if you are handing off the job to a different engineer.

I wonder, where is the threshold for using/not using an RTOS for most engineers? I have worked on SoC designs with ARM9 core that I would never consider approaching without the use of an RTOS. The complexity was just too great. In this case, we used ThreadX from Express Logic. On the other hand, I designed a product ( http://www.powerseed.com ) with an 8-pin micro using a state machine and would not have dreamed of using an RTOS. But then, I didn't know about Salvo back then either.

So, where is your threshold for using an RTOS? Is it when using an 8-bit, 16-bit, 32-bit processor? The number of developers? The complexity of the system?

In the end, an RTOS is just another tool in our toolbox that we may choose to use for a variety of reasons. I think there is some advantage in knowing how to properly use as many tools as we can in our profession.

Another tool I've been using for the past year is a program called MindManager. In its simplest form, you use it to develop mind maps. Mind maps don't tickle everyone's fancy, but if your interested, take a look at http://www.mindmanager.com. When I start a new design, I'll often create a map with the processor in the middle as the main topic and then place all of the IO and periperhals as bubbles around it with links and text to document the system. Gyronix, in the UK, has a useful add-on package to organise and manage projects within MindManager.

Here is a link to a free mind mapping tool: http://freemind.sourceforge.net/...

What I miss the most, since starting my own business, are the discussions with other engineers. I work out of my house in my lab and it's just so quiet. Participating in this forum helps in this regard and also helps to sharpen one's skills.

-Zoom

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

EW wrote:
glitch wrote:

Actually Eric, a quick look at the HD44780 datasheet I have quotes 1.64mS for the clear display function, assuming a clock of 250kHz.

Hmpf. Thanks for checking that. I wasn't aware that it took that long.

I posted a LCD_Initialization.pdf (created from DigiView) showing the initialization of the LCD I am using in an earlier thread on LCD initialization. The controller, a Novatek NT7605 seems to be an enhanced version of the HD44780. The interesting thing is that the busy status may not be checked before initialization is complete on the HD44780 but this is not so on the NT7605 as is shown in the timing diagram. In the end, rather than holding in a loop checking the busy status after a display clear operation, I block for 1 tick so that other tasks have the chance to execute.

-Zoom

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

Quote:
csRTOS files

Thx, but...somehow I don't feel very comfortable with cooperative OS, 'cause if a task gets stuck, nothing is gonna pull it out from there and the whole proggy goes up into Nirvana...

Real men don't use backups, they post their stuff on a public ftp server and let the rest of the world make copies.

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

zoomcityzoom wrote:

My solution to create a device driver task seems to be the recommended approach according to posts on the Salvo user forum. The advantages keeping a small memory (SRAM) footprint (as well as very little stack usage) with Salvo more than outweigh any disadvantages to using a cooperative RTOS.

Eric, do you use an RTOS for any of your AVR projects?

Ok, this is where there is no simple answer....

I haven't used any other third party code that was labeled as an OS or RTOS on an embedded system. I've just used what is commonly called "main()+ISR".

However I have written systems that have evolved from a strict "main+ISR()" into an RTOS-like system. What this means is that I had a need to have tasks fired periodically, which then required:
- a system timer
- a way to define tasks
- a way to execute tasks
- and a way to execute tasks at a specfic time period

And then I needed to have timers as well. Timers that could have long periods and fire simple (callback) functions when the timers expired. The timers were based on the system timer for the tasks.

So when you start building all of this, then you have a lot of the infrastructure of a cooperative multi-tasking system anyway. But, is it an RTOS? Well, it contains elements of an operating system. But then we get into the religious discussion of what does Real Time mean? Did it meet the timing requirements of the system that it was built for? Yes, it did. Will it meet the timing requirements for other systems? It all depends on the system.

Eric

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

Quote:
In the end, rather than holding in a loop checking the busy status after a display clear operation, I block for 1 tick so that other tasks have the chance to execute.

Yes, basically this is THE point! This is where an OS is very helpful!
This is the kind of feature I would like to achieve in my new project...
I need only few services from the RTOS: StartTask; EndTask; WaitSleep; WaitSemaphore; SendSemaphore.

Real men don't use backups, they post their stuff on a public ftp server and let the rest of the world make copies.

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

I'd be happy with a nice one page c source for a function called switchtask that would just flip back and forth between two tasks. two reg save areas, all global vars. I've fiddled with it a little but cant quite crack it. I guess the idea while polling on a timer flag, you call switchtask and the other thing runs.

Imagecraft compiler user

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

groenhen wrote:
Quote:
csRTOS files

Thx, but...somehow I don't feel very comfortable with cooperative OS, 'cause if a task gets stuck, nothing is gonna pull it out from there and the whole proggy goes up into Nirvana...

I think the same precautions must be taken if you are using a pre-emptive RTOS or no RTOS at all. The precautions depend on the end system application. With Salvo, an ISR could call OS_DestroyTask() under a detected lockup condition. But I think I would handle a task lockup situation by carefully employing the WDT. Again, I think all of this is very system dependent.

Like I said eariler, having experience with only preemptive RTOSs and then moving to a cooperative RTOS like Salvo was a bit mind bending for me. It still is in fact. This is why I started this thread, to get some feedback and to discuss other's experiences with a cooperative RTOS.

However, having purchased Salvo, I plan to amortise its cost (purchase price + learning time) by using it on as many products as possible. I do wish that the folks who use Salvo would post more examples of code or even create a library for a collection of devices. The Salvo user forum is not very active. I do understand the reluctance a company may have to posting in public the work they paid for. This is where open source really shines.

-Zoom

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

Stanley, AvrX may do what you want:
http://www.barello.net/avrx/
There is also a group on Yahoo providing support.
I've used it, it works well for what I need.

Arthur

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

Stanley and Bob, It looks like csRTOS is just what your are looking for. On the other hand, PR_RTX could also be used. A nice solution if you use CodeVision. Attached is a user-interface task I wrote for a product that used PR_RTX.

-Zoom

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

Quote:

Thx, but...somehow I don't feel very comfortable with cooperative OS, 'cause if a task gets stuck, nothing is gonna pull it out from there and the whole proggy goes up into Nirvana...

I cannot really agree. You/We are in the same boat without an RTOS. If you have a loop or a subroutine call in your code right now, >>you<< need to assure that it terminates properly. There is nothing magical about these RTOS thingies. The designers have access to no more AVR instructions than you or I do. When you look under the hood, it is a status bit or byte for each chunk of code that marks it ready to run or not, with maybe a few more conditions. You/We can do that with banks of bits or bytes too. You/We can have a dispatcher that looks at the banks and decides what to do next. And on and on with critical sections dealing with I/O devices, etc.

You/We can enable the watchdog timer or the watchdog interrupt. You/We can decide in that interrupt or a periodic tick ISR if something has taken too long to complete. You/We can do exactly the same actions as the pre-emptive RTOS.

In very general terms, a pre-emptive RTOS needs to save the contents of all GP registers and have separate data & return stacks for each task. Let's say you like passing parameters and calling subroutines 3 deep; give you 64 bytes of data stack (still quite conservative). Let's add another 16 or 32 for call stack. With 32 for the registers, that is 100+ bytes/task for the pre-emptive. Then you might have 8-16 per task for the RTOS housekeeping.

Summing up at 128 bytes/task & 8 tasks gives 1k. Cool. Gee, I like to declare some global variables in my apps, too. Running down the list of AVRs, a Mega32 has a couple k of SRAM; we are all set. Whoops, that costs 3x a Mega48 which can do the app quite nicely, thank you. "But Boss, it is so cool that I'm using a pre-emptive RTOS! The extra $2/unit and board space and power consumption be damned!"

So you try to weasel on all the stack space and "combine tasks"--with flags that tell which pieces to run. Hmmm--looks suspiciously like the non-RTOS version.

There are nice products out there, and some have small footprints especially for co-operative. But I'll continue to argue that there is no place for pre-emptive RTOS in a true microcontroller, near-single-chip, Mega48/88-class application.

Lee

You can put lipstick on a pig, but it is still a pig.

I've never met a pig I didn't like, as long as you have some salt and pepper.

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

Quote:
I think the same precautions must be taken if you are using a pre-emptive RTOS or no RTOS at all. The precautions depend on the end system application. With Salvo, an ISR could call OS_DestroyTask() under a detected lockup condition. But I think I would handle a task lockup situation by carefully employing the WDT. Again, I think all of this is very system dependent.

Yes, basically you're right: one must always take some precautions...
But, the advantage of the pre-emptive RTOS is that if something goes wrong, you will lose only one task (locked, stuck, etc.), but the rest of the tasks will definitely have a good chance to run. Yet, I am not saying that the other tasks will compensate the dead task.

Real men don't use backups, they post their stuff on a public ftp server and let the rest of the world make copies.

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

Quote:
There are nice products out there, and some have small footprints especially for co-operative. But I'll continue to argue that there is no place for pre-emptive RTOS in a true microcontroller, near-single-chip, Mega48/88-class application.

I agree completely!

BTW I had some errant comments in the code for the system menu task I posted earlier. Attached is the updated file.

-Zoom

Attachment(s): 

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

bobgardner wrote:
I'd be happy with a nice one page c source for a function called switchtask ...

Hey Bob!... Still fighting with that bloody task-switcher? :-)

Real men don't use backups, they post their stuff on a public ftp server and let the rest of the world make copies.

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

Being against all that OS stuff on AVRs I'm working on a preemptive OS myself.
It's quite simple but it seems to run. I'm able to sleep, suspend and resume tasks but haven't fixed the DeleteTask function yet.
No semaphores but I've made a simple lock/unlock so a task can lock an LCD or seriel port for as long as it needs it. Other tasks will then wait for the resource to be freed.
Task overhead is 35 bytes RAM/task minimum.

Simple yes but it shows how much an OS wastes.

I have yet to see an 8 bit system that couldn't be done using the mainloop/ISR style but then again I've only worked on sub 64kb systems.

/claus

/claus

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

bobgardner wrote:
I'd be happy with a nice one page c source for a function called switchtask that would just flip back and forth between two tasks. two reg save areas, all global vars. I've fiddled with it a little but cant quite crack it. I guess the idea while polling on a timer flag, you call switchtask and the other thing runs.

@Bob

Could it be this one ???

Even in your favorite flavour :-)

Edit: The below is hosted on freaks (and this might be a newer version)
https://www.avrfreaks.net/index.p...

/Bingo

Attachment(s): 

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

groenhen wrote:

Thx, but...somehow I don't feel very comfortable with cooperative OS, 'cause if a task gets stuck, nothing is gonna pull it out from there and the whole proggy goes up into Nirvana..

Yes, but the idea of csRTOS is to run with limited RAM. A preemptive rtos requires a stack for each task that can be preempted, while csRTOS uses only one stack and it needs only enough space for the task that needs the most.

Besides, you will solve the 'proggy' problem with a preemptive rtos, but your code still won't work if the bad task is required to work.

Many people have found that a cooperative rtos works fine in their apps. One reason that folks might want preemption is if there is a compute-bound task and it is not convenient to do a yield() frequently, or if there is a task that needs to run real soon after it is set RTR by an interrupt, but it is too big or slow to just be an ISR.

btw, there are 4 versions of my rtos, but only csRTOS has been published. One is completely preemptive, another is a combination of cooperative and preemptive. I use one of those on micros that have lots of RAM.

glen@worstell.com

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

I agree with those that say an "OS" per se is not usually needed on small 8 bitters. But...

1) AVRX is rock-solid. Preemptive with queues and sempaphores. Simple. Free. I've used it.

and

2) On small-RAM micros, often one uses a cooperative "task" scheduler so that just one stack is needed, and it's shared among tasks. A preemptive RTOS needs a stack per task. More RAM and tasks that stay suspended a lot waiting on something waste RAM.

3) Freebie OPEX (projects section here) is a cooperative OS that schedules based on I/O events, flags, semaphores or calendar time or delta time, e.g., "run this task ( C function) at some date/time. And has a way to suspend waiting on serial port or a flag set by an ISR. Each "task" keeps its state in a hunk of RAM that is persistent; the scheduler calls the task's root function with a pointer to this RAM, in which there is usually a C structure. With this, the "Tasks" are reentrant. I recently adapted OPEX for an ARM7 and the Standard C library time routines. OPEX uses a C lib "setjmp" to ensure that all tasks will yield to the scheduler, unless a task just do an infinite loop (in which case it should execute the Halt And Fire Firmware Guy instruction).

A common scheme in such cooperative schedulers is that each "task" is a state machine. Each time it's called, it decides what code to run this time based on a state variable (switch statement).

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

I wrote a small Salvo-like OS for the AVR a few years ago. Googling on CS-RTOS or something like that might turn up info. If there is a lot of interest I could resurrect the article (and code) and post it somewhere.

This OS is, like Salvo, particularly good for micros with small RAM. I've used it with MSP430 micros with 128B. If you have enuf RAM a preemptive OS might be a better choice.

g.

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

Quote:

I wrote a small Salvo-like OS for the AVR ...

sorry, I did not realize that my name and email would not appear.

Glen@Worstell.com

Pages