Forum Menu




 


Log in Problems?
New User? Sign Up!
AVR Freaks Forum Index

Post new topic   Reply to topic
View previous topic Printable version Log in to check your private messages View next topic
Author Message
karthiprime
PostPosted: Aug 08, 2012 - 07:37 AM
Newbie


Joined: Jul 23, 2012
Posts: 18


So far i have understood the datasheet of the Atmega644 (have worked with its timers, USART etc) and basics of the RTOS (like it has scheduler, threads etc).

Now i want a RTOS to be run on this microcontroller.

Do i have to use FreeRTOS kinda tool to achieve this?
if so i have lots of questions ahead.

Thanks
 
 View user's profile Send private message  
Reply with quote Back to top
meslomp
PostPosted: Aug 08, 2012 - 07:50 AM
Raving lunatic


Joined: May 02, 2007
Posts: 3022
Location: Nieuwegein, Netherlands

never used one, but there are a lot of Free RTOSs around that can be used.

_________________
1)Datasheet and application notes checked?
2)tutorial forum
3)Newbie start here
 
 View user's profile Send private message  
Reply with quote Back to top
jayjay1974
PostPosted: Aug 08, 2012 - 08:03 AM
Raving lunatic


Joined: Oct 30, 2002
Posts: 5721
Location: The Netherlands

There is a FreeRTOS port for AVRs that you can use.

FreeRTOS has the advantage it is widely used; other RTOSes for AVRs are less well tested, or used or are mostly experimental.
 
 View user's profile Send private message  
Reply with quote Back to top
karthiprime
PostPosted: Aug 08, 2012 - 08:10 AM
Newbie


Joined: Jul 23, 2012
Posts: 18


jayjay1974 wrote:
There is a FreeRTOS port for AVRs that you can use.



What is that FreeRTOS port mean?
 
 View user's profile Send private message  
Reply with quote Back to top
Kartman
PostPosted: Aug 08, 2012 - 08:56 AM
Raving lunatic


Joined: Dec 30, 2004
Posts: 8789
Location: Melbourne,Australia

It means FreeRTOS for an AVR, there's FreeRTOS for other micros as well.
 
 View user's profile Send private message  
Reply with quote Back to top
karthiprime
PostPosted: Aug 08, 2012 - 09:19 AM
Newbie


Joined: Jul 23, 2012
Posts: 18


Can i do(load RTOS on the microcontroller) without using such tools??
 
 View user's profile Send private message  
Reply with quote Back to top
Kartman
PostPosted: Aug 08, 2012 - 10:08 AM
Raving lunatic


Joined: Dec 30, 2004
Posts: 8789
Location: Melbourne,Australia

I think something is being lost in translation. What tools do you speak of?

At a minimum you need some means of loading code into the AVR.

Exactly why do you want a RTOS? Have you read my tutorial on multitasking?
 
 View user's profile Send private message  
Reply with quote Back to top
clawson
PostPosted: Aug 08, 2012 - 10:24 AM
10k+ Postman


Joined: Jul 18, 2005
Posts: 62369
Location: (using avr-gcc in) Finchingfield, Essex, England

Here is a list of RTOS for the AVR:

http://www.avrfreaks.net/index.php?name ... mp;t=66371

There are loads to choose from. FreeRTOS (http://www.freertos.org/) is just one but it's true that it's widely used as it's a good implementation and the website goes out of its way to explain how it works.

But maybe take a step back first and say why you think an RTOS is required in your application anyway? Many (most?) AVR apps consists simply of a main() and a handful of interacting ISR()s and that is generally the "best" solution for the problem in hand. It's only when things get so complicated that you really want to be doing 5-10 things in the foreground and there's tens of ISRs involved that the complexity/overhead of using an RTOS is justified. I'd say as a rough rule of thumb there's a limit somewhere around the 48K of code mark where a program may have grown so complex that an RTOS may help. It's true you mentioned a 64K chip so maybe you mean to write close to 64K of code? But if a lot of that 64K is really going to be data then take a step back and look at the complexity of the proposed application and weigh up whether the added overhead of an RTOS is really required.
Quote:

Can i do(load RTOS on the microcontroller) without using such tools??

What do you mean by "such tools" in this sentence. An RTOS is just a piece of AVR software (typically 5K..20K) that you build alongside your own program code and it effectively gives you the chance to have 5 or 10 main() programs all running alongside one another. It does this at the cost of RAM (for each "program" it has to hold the state of everything including a stack for each) and CPU cycles - every 10ms (or similar) it has to stop one main(), store away it's current state then recover the state of some other main() and setup the CPU to run it and then enter it. This task switching is non-trivial and can easily be absorbing hundreds of CPU cycles every 10 milliseconds.

The other "downside" of RTOS use is inter-process synchronization. Any one main() cannot easily know what any other main() is doing at any particular moment. So if the process that is happening in one must deliver a result to another they need to interact. This can be done with mutex's, semaphores, message queues and so on but this adds a complexity to those processes that may not have existed previously. If not done correctly it can also introduce the potential for some extremely subtle bugs that can prove very hard to find as the situation that shows some inter-process interaction failing may require on 10 different things to be at just the right point for it to occur.

Another issue with RTOS (just as you see in "big ones" like Linux and Windows) is the question of memory protection. You may now have 5 or 10 different programs all running together in the AVR but at the end of the day they all share the same SRAM space. If one of those tasks makes an inadvertent write to memory (often with a pointer that's holding the wrong value or as the result of an buffer overflow) then it may actually be corrupting one or more of the variables of another program in a very subtle and difficult to find way. When program 3 suddenly starts misbehaving it can be very tricky to diagnose that it was actually a write done by program 6 that caused the problem. In Windows/Linux this is mitigated by clever CPUs that isolate the memory of any one running program so that it cannot write to memory it does not "own" but AVR processors are not that clever and do not offer such memory protection mechanisms so inter-process memory corruption is a real possibility.

Bottom line: think hard as to whether an RTOS is really justified before over-complicating a design that does not really need one.

_________________
 
 View user's profile Send private message  
Reply with quote Back to top
danni
PostPosted: Aug 08, 2012 - 10:29 AM
Raving lunatic


Joined: Sep 05, 2001
Posts: 2499


I would suggest the ATmega1284P instead, since it has 16kB SRAM.
An RTOS should have as much RAM as possible, since it need many more, than the classical main loop approach.

Task switching need lot of RAM.
Every task need its own RAM (stack, variables), which can be not shared with other tasks.
Semaphores, mutexes, queues and so on need further RAM.
And at least the whole application may need RAM for conventional variables.


Peter
 
 View user's profile Send private message  
Reply with quote Back to top
hanemagne
PostPosted: Aug 08, 2012 - 10:41 AM
Hangaround


Joined: Feb 10, 2011
Posts: 164
Location: Trondheim, Norway

If you don't absolutely need to use PDIPs, and really really want to use ATmegas, try the ATmega2560 instead. It's got an external bus interface to which you can attach more static ram practically hassle-free. Then you can have 256kB Flash and a LOT of RAM (compared to other ATmegas).
If size is the issue, there are 44-pin xmegas available, which are even better (less ill) suited for RTOS's.

Here you'll find a bunch of RTOS's, some better than others. But really, go with jayjay and clawsons suggestion!

_________________
"Maybe happiness is just fragments of existence with better packaging."
 
 View user's profile Send private message  
Reply with quote Back to top
DO1THL
PostPosted: Aug 08, 2012 - 11:55 AM
Resident


Joined: Aug 29, 2002
Posts: 786
Location: Muenster, Germany

Maybe the OP views an AVR like a traditional PC. In order to use both, he expects to be in need of an operating system and has already read about RTOS for AVRs. If my assumption is true, then i might suggest that the OP forgets everything about RTOSes for micros, start with reading some tutorials in the beginners sections or elsewhere on the net, and defers working with an RTOS on an AVR until he positively knows that he needs one.

_________________
Einstein was right: "Two things are unlimited: the universe and the human stupidity. But i'm not quite sure about the former..."
 
 View user's profile Send private message  
Reply with quote Back to top
karthiprime
PostPosted: Aug 13, 2012 - 07:10 AM
Newbie


Joined: Jul 23, 2012
Posts: 18


Thanks for the reply..

Sorry for the late reply guys.

Kartman : Ya i read ur tutorial on Multitasking. That was excellent.

Clawson : Ya fine. Am in my training program, where RTOS is a part of it. I never really selected the particular application for RTOS.

I understood that i need to think before complicating things with the RTOS.

Between i like to know the specific scenario where RTOS is used, which might give me some instinct.

Thanks
 
 View user's profile Send private message  
Reply with quote Back to top
clawson
PostPosted: Aug 14, 2012 - 01:16 PM
10k+ Postman


Joined: Jul 18, 2005
Posts: 62369
Location: (using avr-gcc in) Finchingfield, Essex, England

Quote:

Between i like to know the specific scenario where RTOS is used, which might give me some instinct.

Well my opinion as noted above is that there's some level of MCU software complexity perhaps around the 48K mark where code maybe has got so complex that an RTOS could be justified. But don't just throw one in because "it seems like a good idea".

_________________
 
 View user's profile Send private message  
Reply with quote Back to top
Display posts from previous:     
Jump to:  
All times are GMT + 1 Hour
Post new topic   Reply to topic
View previous topic Printable version Log in to check your private messages View next topic
Powered by PNphpBB2 © 2003-2006 The PNphpBB Group
Credits