Archive for October, 2010

Upcoming Embedded Software Boot Camps

Thursday, October 21st, 2010 Michael Barr

Earlier this week, Netrino announced the dates and locations for a pair of upcoming public sessions of the popular hands-on Embedded Software Boot Camp workshops.  The dates and locations will be as follows:

These will be the 9th and 10th times, respectively, that the Embedded Software Boot Camp has been offered to the public since the first was held in 2008.  The workshop is a one-week skills strengthening program consisting of a series of lectures and hands-on exercises. This intense educational (yet fun!) program is guaranteed to quickly and dramatically raise the embedded programming skills of individuals and teams.

Everyone who attends learns a ton, including:

  • How to write portable device drivers and interrupt handlers in C
  • How to decide if an RTOS will benefit your application
  • How to architect real-time software to ensure all deadlines are met
  • More than fifty practical tips for reducing firmware bugs
  • How to find, fix, and prevent each of the top 10 firmware bugs

I will be the instructor for both of these sessions and hope you will make the commitment to become a Master Firmware Engineer in 2011 by taking this course!  You can find out more about pricing and other details here: http://www.netrino.com/Training-Calendar.

Get Your (RTOS Task and ISR) Priorities Straight!

Thursday, October 14th, 2010 Michael Barr

Get your priorities straight!  Or suffer the consequence of missed deadlines.  Of course, I’m talking here about the relative priorities of your real-time tasks and interrupt service routines.  In my travels around the embedded design community, I have learned that most real-time systems are designed with ad hoc priorities.

Unfortunately, mis-prioritized systems often “appear” to work fine without discernibly missing critical deadlines in testing.  The worst-case workload may have never yet happened in the field or there is sufficient CPU to accidentally succeed despite the lack of proper planning.  This has lead to a generation of embedded software developers being unaware of the proper technique.  There is simply too little feedback from non-reproducible deadline misses in the field to the team that designed it—unless a death and a lawsuit forces an investigation.

Truth be told: There is a science to the process of assigning relative priorities.  That science is associated with the “rate monotonic algorithm,” which provides a formulaic way to assign task priorities based on facts.  It is also associated with the “rate monotonic analysis,” which helps you prove that your correctly-prioritized tasks and ISRs will find sufficient available CPU bandwidth between them during extreme busy workloads called “transient overload.”   It’s too bad most engineers don’t know how to use these tools.

I’ve written on the why and how of RMA before and recommend you start with my article Introduction to Rate-Monotonic Scheduling and then read my blog post 3 Things Every Programmer Should Know About RMA.