Does the OS have separate stack area for itself(operating system) and
separate stack area for the application ?
Or
Does the stack area of the application will be part of the
stack(bigger stack) of the Operating System ?
I do not find Clear information w.r.t this on the internet. Any
ideas ?
Can somone tell me w.r.t a specific OS & application ?
Thx in advans,
Karthik Balaguru
What an OS does with stacks depends on the OS. It's pretty much necessary
to maintain a stack for each thread of execution, so you can count on that
happening. Some of the really small microkernels (Micro-C/OS for example)
don't really maintain an independent thread other than the idle thread;
other OS's (like Linux or Windows) may have many applications and drivers,
each with their own tasks, running in the background.
--
Tim Wescott
Control systems and communications consulting
http://www.wescottdesign.com
Need to learn how to apply control theory in your embedded system?
"Applied Control Theory for Embedded Systems" by Tim Wescott
Elsevier/Newnes, http://www.wescottdesign.com/actfes/actfes.html
Either, both or neither, depending. I have seen all of those.
|> I do not find Clear information w.r.t this on the internet. Any
|> ideas ?
|> Can somone tell me w.r.t a specific OS & application ?
Look, you are likely to get confused if you proceed like this, and
will certainly annoy people.
I recommend finding a book that gives an introduction to operating
system design, and reading it. Ask on comp.theory for book
recommendations.
And don't post basic questions to so many groups.
Regards,
Nick Maclaren.
Tim Wescott wrote:
>>Does the OS have separate stack area for itself(operating system) and
>>separate stack area for the application ?
>>Or
>>Does the stack area of the application will be part of the
>>stack(bigger stack) of the Operating System ?
>>
>
> What an OS does with stacks depends on the OS. It's pretty much necessary
> to maintain a stack for each thread of execution, so you can count on that
> happening. Some of the really small microkernels (Micro-C/OS for example)
> don't really maintain an independent thread other than the idle thread;
In our proprietary RTOS HALOS, I also maintain a separate stack for all
of the interrupt system. Thus the nested interrupts do not waste the
stack space of the tasks; also the interrupt stack is located in the
fast memory area, so the response time is better.
>> other OS's (like Linux or Windows) may have many applications and drivers,
>> each with their own tasks, running in the background.
If you have a full blown MMU and non-RTOS desktop OS, this is a
different story.
Vladimir Vassilevsky
DSP and Mixed Signal Design Consultant
http://www.abvolt.com
Any particular OS you are thinking of?
See www.freertos.org/implementation for some general info.
--
Regards,
Richard.
+ http://www.FreeRTOS.org
13 official architecture ports, 1000 downloads per week.
+ http://www.SafeRTOS.com
Certified by TÜV as meeting the requirements for safety related systems.
Even with an MMU a separate thread needs its own stack space. Its
existence may be buried underneath a pile of other code, but it'll still
be there.
--
Tim Wescott
Wescott Design Services
http://www.wescottdesign.com
Do you need to implement control loops in software?
"Applied Control Theory for Embedded Systems" gives you just what it says.
See details at http://www.wescottdesign.com/actfes/actfes.html
Depending on how you define a thread, I would add "*in a pre-emptive
system* - a separate thread needs its own stack space". Cooperative threads
can share a stack. FreeRTOS.org has both.
Commonly called coroutines. And they can all share space if they use
the heap to get each frame, preemptively or not. And you can have
threads that have no associated storage. And ....
Regards,
Nick Maclaren.
Just another illustration that mucos is a toy and its architecture is
miserable.
> It's a good thing if you have a lot of tasks in a
> memory-constrained system: instead of having to add space for the
> interrupts everywhere, you only need it in one spot.
Another advantage is that the interrupt stack is located in the fast memory
on chip, so the interrupt latency is low and independent of the state of the
cache and the timing of the bus.
> >>> other OS's (like Linux or Windows) may have many applications and
> >>> drivers,
> >>> each with their own tasks, running in the background.
> >
> > If you have a full blown MMU and non-RTOS desktop OS, this is a
> > different story.
>
> Even with an MMU a separate thread needs its own stack space. Its
> existence may be buried underneath a pile of other code, but it'll still
> be there.
The MMU is the good thing to have. It solves so many problems. Even a
286-like MMU is a great aid to the multitasking system.
Vladimir Vassilevsky
DSP and Mixed Signal Consultant
www.abvolt.com