Home

RTOS Programming

A huge amount of attention is focused on multi-threading architectures and RTOS programming because virtually all modern embedded software applications are built this way. The common “thread” - no pun intended, is POSIX.
 
With the maturing of the POSIX standards and the broad adoption of the standards by all vendors in the industry as well as a move towards POSIX by the Linux team, RTOS programming has been vastly simplified. Applications are now much more portable and users simply need to know how to:

  • understand the fundemntal principles of RTOS programming
  • use the tools for a given POSIX environment,
  • have the necessary device support, and
  • have the necessary hardware architectural support.

 
Is this enough for all applications? No, in fact, users need much more than this to meet the demanding goals of customers. There is many other factors which influence the choice of application and the underlying tools and runtime environment and ensure that your RTOS programming efforts are minimal while still exceeding customer expectations.

  • The memory footprint available on each processor is very important. If the processor is tiny and the application is demanding then the memory resources that the RTOS consumes is critical.
  • Minimum sizes for micro CLinux are in the range of 4MBytes
  • Minimum sizes for most popular kernels are in the range of 200K to 500K bytes to actually run an application.
  • How much memory does your DSP, Digital Signal Controller, or microcontroller have? How small does the kernel have to be?

 
Applications need additional capabilities like real-time response, reliability features and other security features. What does your application need? You should clearly define the requirements before you decide on a solution.

  • What are your real-time response requirements?
  • What are your security requirements?
  • What are your reliability requirements?

 
Almost all embedded applications require real world I/O. Support for this I/O, off the shelf, is the single biggest factor in rapid development of a product because processor support, chip support and board support software (DSO) is expensive and time consuming.

  • Does the solution you are choosing have off the shelf support?
  • Is the support package complete or is their holes in critical areas?
  • If the processor support is good, is your chip fully supported? Your board?
  • Consider all types of I/O when you think about your application and make sure you get what you need.
  • Typical I/O services should include: file systems, serial I/O, SPI, nfs, usb, A/D-D/A, timers, and more.

 
Applications often need specialized application libraries, and on many microcontrollers, DSPs, DSCs and FPGAs these might not be available. The lack of library support can add months or years to application development time and substantial amounts of risk. Off the shelf libraries and applications are as important as off the shelf device support

  • Are you doing DSP and do you need these libraries?
  • Are you doing communications processing which requires special libraries?
  • Are you doing image processing, compression or decompression which require special libraries?
  • Are you doing user I/O in well known formats or have a requirement to run canned format programs which restrict your design choices?
  • Off the shelf libraries can save thousands of hours of development during RTOS programming at the application level.

 
Tools that are required often are driven by the needs of the application developers. You need to consider if your environment has all the tools that you need and if it will mature with your project.

  • Are you doing algorithm development – are their links to your tools?
  • If you are filtering, do you have a DSP filter design package?
  • Can you capture the data that you need?
  • Can you simulate before the hardware is ready?
  • Is your environment completely integrated with editor, debugger, compiler and target tools in one package?

 
RTOS programming is about training and design services too. These are also important components.

  • Can you get training easily?
  • Is the training useful across more than one project?
  • Are you learning something that can be used on all future projects - big and small?
  • Is it easy to get people who understand your system?
  • Can you easily hire designers that understand your run time environment?

    • All these factors are important to make sure your RTOS programming project is fast, low cost and high quality.