How long is a piece of string?

Answering questions is something that I am often expected to do. Maybe I am presenting at a conference, doing an online seminar, hanging out on a trade show booth, writing blogs or articles – these all elicit questions. Sometimes I am asked by a salesperson to respond to a customer’s question.

I would always do my best to give a complete and accurate answer and certainly aim to be truthful. I was recently posed some questions about Nucleus, which made me think …

A customer was considering the deployment of Nucleus RTOS in a new project. I had no background information, but they asked three questions. Here they are, along with my answers and rationale:

Q – Is the presence of an MMU (Memory Management Unit) a mandatory requirement of the OS?

A – Nucleus implements a multi-threading environment with a flat memory space, like most classic real time operating systems. It does not carry the overhead of implementing process model. However, depending on the choice of CPU, if an MMU is available, there is the option to deploy it to implement “thread protected mode”, where each task’s memory, along with that of the OS, is protected from the other tasks. This is a very lightweight use of the MMU.

[In this case, I did not know whether they were expecting to have an MMU or not. If they knew that there would not be one, they would be pleased to hear that Nucleus did not demand an MMU. On the other hand, if they were going to have an MMU, they might be pleased to hear that it could be utilized.]

Q – In how much space can we derive the basic functionality of the OS?

A – This depends on the target CPU and the amount of functionality required. All the functionality outside of the kernel [file system, networking etc.] is optional and is only included if explicitly required by the application. The Nucleus kernel and all the additional components are highly scalable, so only the required functionality is included in the target memory footprint. Here is an example:

  • ARM Cortex A8 in ARM mode
  • Built with Mentor Sourcery CodeBench toolchain
  • Full optimization for size

ROM = 12-30 Kbytes

RAM = 500 bytes

Min has essential kernel services [dynamic memory, threads, semaphores, events, queues] – Runtime library excluded.

Max includes all kernel services.

Compiling for Thumb-2 mode reduces ROM by 35% – So Nucleus kernel can use 7.8 Kbytes on a Cortex-M based controller

[Again, I had no background on their memory size plans. So, I used the opportunity to emphasize the flexibility of Nucleus configuration options and gave a real example to maintain credibility.]

Q – How much of the processor’s computational bandwidth shall be used by the OS?

A – This question is virtually impossible to answer accurately for any OS. Apart from the choice of CPU and its configuration, the architecture of the application and the way that it uses the OS is critical. Nucleus is designed and very widely used to efficiently utilize the CPU for hard real time applications; OS overhead is not raised as an issue. Measurement of this overhead is quite straightforward using a tool like Sourcery Analyzer, but that can only be done on a complete [albeit maybe prototype] system.

[This really is an almost impossible question to answer usefully, but I saw it as an ideal opportunity to talk about System Analyzer, which really is an excellent tool for this kind of application.]

Post Author

Posted July 1st, 2013, by

Post Tags

, , ,

Post Comments

2 Comments

About The Colin Walls Blog

This blog is a discussion of embedded software matters - news, comment, technical issues and ideas, along with other passing thoughts about anything that happens to be on my mind. The Colin Walls Blog

Comments

2 comments on this post | ↓ Add Your Own

Commented on 1 July 2013 at 19:02
By Dan S

These questions seem to be either very lazy or very naive (or ignorant). Actually, I’m going to guess ignorant now that I think about it. To even ask such questions shows a very shallow understanding of RTOSes, if any at all.

Regarding the MMU question, I’ve seen many companies use the MMU more like an MPU (which I believe is along the lines of what you were discussing) – hence the prevalence of MPUs on architectures like the ARM CM3/4.

Commented on 2 July 2013 at 13:44
By Colin Walls

Dan: I think naivety. Good point about MPUs.

Add Your Comment

You must be logged in to post a comment.

Archives