Archive for December, 2010

Embedded Software Boot Camp in a Box

Wednesday, December 15th, 2010 Michael Barr

Whether you are new to embedded software development in C or looking for ways to improve your skills, the Embedded Software Boot Camp in a Box will provide you the hands-on education you need. Exercises are based around an ARM processor board (shown below), the MicroC/OS-II real-time operating system, and the IAR Embedded Workbench compiler/debugger, all of which are included in the box.


Learn Embedded Programming on an ARM Processor

Netrino’s popular Embedded Software Boot Camp (see upcoming dates), on which this kit is based, is an intense in-person training experience that requires attendees to be able to check out of normal work and life routines for a week—sometimes also travelling a great distance. The Embedded Software Boot Camp in a Box is a way to learn the same skills at your own pace. You’ll do the same exercises and have access to the same materials, just won’t have a “drill instructor” or the clock to prod you.

Here’s how you’ll use the Embedded Software Boot Camp in a Box to learn embedded programming:

  • Read the 350 page “Field Manual” book, which contains the slides from the in-person Boot Camps, in order.
  • If you want to dig deeper, watch the video of Michael Barr‘s acclaimed “How to Prioritize RTOS Tasks and Why it Matters” lecture on DVD, or read the three books and numerous articles provided as PDFs on the USB drive.
  • As you read, you will come to slides titled “Exercise: …”. These slides mark the best points to attempt each exercise.
  • In all there are ten programming exercises: one to test your compiler/debugger/board setup; two concerning hardware interfacing in C; six concerning multithreaded programming with uC/OS-II; and one capstone project to build a scuba dive computer. These involve hardware interactions such as blinking LEDs, debouncing pushbuttons, reading A/D converters, working with programmable timer/counters, and generating audio tones via PWM signals.
  • Detailed instructions for each exercise can be found in the printed “Exercise Manual”.
  • Solutions for each of the exercises are provided on the USB drive.
  • After you finish with the included exercises, you’ll know your way around most of your ARM processor board and be ready to explore the rest of its hardware (RS-232, CAN, Ethernet, USB, etc.) on your own.

For more details or to order your kit now, browse on over to

Firmware-Specific Bug #10: Jitter

Thursday, December 2nd, 2010 Michael Barr

Some real-time systems demand not only that a set of deadlines be always met but also that additional timing constraints be observed in the process. Such as managing jitter.

An example of jitter is shown in Figure 1. Here a variable amount of work (blue boxes) must be completed before every 10 ms deadline. As illustrated in the figure, the deadlines are all met. However, there is considerable timing variation from one run of this job to the next. This jitter is unacceptable in some systems, which should either start or end their 10 ms runs more precisely.

Jitter Figure 1

If the work to be performed involves sampling a physical input signal, such as reading an analog-to-digital converter, it will often be the case that a precise sampling period will lead to higher accuracy in derived values. For example, variations in the inter-sample time of an optical encoder’s pulse count will lower the precision of the velocity of an attached rotation shaft.

Best Practice: The most important single factor in the amount of jitter is the relative priority of the task or ISR that implements the recurrent behavior. The higher the priority the lower the jitter. The periodic reads of those encoder pulse counts should thus typically be in a timer tick ISR rather than in an RTOS task.

Figure 2 shows how the interval of three different 10 ms recurring samples might be impacted by their relative priorities. At the highest priority is a timer tick ISR, which executes precisely on the 10 ms interval. (Unless there are higher priority interrupts, of course.) Below that is a high-priority task (TH), which may still be able to meet a recurring 10-ms start time precisely. At the bottom, though, is a low priority task (TL) that has its timing greatly affected by what goes on at higher priority levels. As shown, the interval for the low priority task is 10 ms +/- approximately 5 ms.

Jitter Figure 2

Firmware-Specific Bug #9