FreeRTOS updated

This is not a critical comment, but does this really make a difference.

In my last job we had a few timing problems and everyone was blaming the context switch, so I crafted a test to time it. Turned out the total switching time was a fraction of one percent of the total run time of the ap. Saving 10% of nothing isn't going to help much

Tim

Well that all depends on your quantum time.....

Ralph

Working for the last 4 years writing/designing RTOSes, I can only copy this, __but__ that's what we first hear as question: How fast is the context switch ? More interessting IMHO is the IPC. Or the interrupts turn around times. (And this maybe compared to the task-switch times). E.g. using a classical *nix mailbox (AFAIK FreeRTOS uses this technique as well) sending a 100 bytes means to copy 200 bytes (into and out of the mailbox). On a x86 the context (aka register set) to be saved are about 14 registers, means 56bytes + restore 56bytes are 112 bytes => the IPC takes more time than the context switch. (Neglecting that of course the IPC is not only copying !)

So, when optimizing the whole IPC path must be quick => See L4.

Sure, and I could create tasks that could actually show a degradati Saving 10% of nothing isn't going to help ME much.

How many context switches do you do? Other system designs might get a full 10% improvement (or more) due to the changes, if the tasks execution times are very short (for example, state machine evaluations).

If optimal polling time was at say, 95% of the old context switch and task execution time, this change could yield near 100% improvement.

I just think you can't generalize the value of an improvement based on one personal observation.

Rufus

-----= Posted via Newsfeeds.Com, Uncensored Usenet News =-----

-----== Over 100,000 Newsgroups - 19 Different Servers! =-----

Can anyone suggest resources (links, books) to better understand the theory, design and issues behind RTOS's?

Thanks,

To some it will. Or, to maybe coin a phrase:

There is no such thing as "fast enough for everyone".

The net effect that 10% speed-up can be both invisibly small, or make the difference between a working product and failure, depending on the particular project.

I have written a reference document to our real-time operating system.

It explains what an operating system is (for embedded systems, not in the general case) and the inner working of a kernel.

You can download this document at our web site:

In fact, you can also download our configurable real-time operating system (also under 'download' - you will have to install our graphical configuration tool first). Our RTOS is free for non-commercial use, and it is portable to virtually any processor.

By studying the source code, you will typically learn the inner working of a real-time operating system.

I have also compiled a list of recommended books, and there is a section covering real-time operating systems. This list can also be found under the 'Knowledge' menu at our web site.

Best of luck!

Anders Rosvall

Embedded Artists

theory,

This

difference.

task

You seem to have extrapolated from what I said to the reason being that we didn't switch task very often. The point is the switching time is small overall (or should be) so making it smaller doesn't save very much IMHO.

You going to have a huge OS overhead if you save this much. A better design might be a more appropriate way of saving time.

Actually it was, but the guts of the work was handled in interrupts and didn't go through the OS context change.

How is this going to work? Oh, currently the OS uses 95% of the time and now it uses 90%. Sorry, you've got a crap OS if this is your profile.

I think I can. If your OS is so busy that a small change in the function that saves context when task switching is significant, where is all the time coming from to perform all the other functionality?

Tim

I'll look that over, thank you.

-Martin

the

of

of

evaluations).