embedded software boot camp

Social Networking for Engineers

February 4th, 2011 by Michael Barr

Would your best friend describe you as a particularly “social” person? Do you like to “network” and meet new people? If you’re an engineer, your answer is probably something like,

“Um, no and no. Now can I slink back to my cube, Mr. Nosy McSales Guy?”

The growth of “social networking” in its many forms is a remarkable phenomenon that’s proving powerful enough to reshape the economic landscape and trouble despotic regimes. For example, if (6 year old!) Facebook were a country it would already be the world’s 3rd most populous.

That we the engineers–who ultimately make stuff like this possible–are mostly a loose band of individuals self-selected for our lack of people skills (a key trait that allows us to sit in cubes all day focusing deep-deep-deep on new technology) may explain why so many of us are luddites when it comes to using this “social” technology.

Some of us rationalize that we don’t like connecting with people offline, so why would we do that online. Others that reading status updates from other people will take valuable time away from more important stuff. This fun video sums it all up,

“Until recently, wasting time on computers was the domain of engineers alone. Now even my Nana wants to keep me up to date on the status of her cats!”

But there’s a lot of value in social networking for engineers. Here’s how I use three social networking websites and why you should join them too.

LinkedInmy cloud-based self-updating address book

Every user on LinkedIn creates a “public profile page”, which is something like a resume. Your profile gives your current job title, the name of your employer, and the nearest big city. If you want, your public profile also has space for you to expand on what you do in your current job or in your career generally. You can also list where you went to University, what you majored in, and your past employment history–complete with praise quotes from former colleagues and managers.

When you “connect” to another LinkedIn user, they get to see your private information too. This includes (by default) your e-mail address and phone number, as well as the names of your other connections. The majority of LinkedIn users seem to have on the order of 100 connections once they get setup. Your “in” list consists mostly of current and past colleagues, perhaps some classmates or other chums, etc.

Although it is not specifically advertised this way and has many other valuable features, I think of LinkedIn as primarily my cloud-based self-updating address book. It’s an address book in that I can easily search for your phone number or e-mail address once we connect. If I can’t remember or spell your last name, I can search by first name and anything else I can remember about you, like the name of an employer. And, as long as you take the few minutes to update your profile page and contact info each time you change jobs, we’ll never lose touch with each other. Wow!

I’ve used LinkedIn to easily reconnect with old friends as well as to stay connected to colleagues, friends, and pretty much anyone who hands me their business card. Although I also have an offline address book, that’s now much smaller than it used to be–and just for tracking those phone numbers and e-mail addresses that I use on a weekly or monthly basis.

There are smartphone apps for LinkedIn and I have one on my iPhone, but I rarely use it. I don’t visit LinkedIn every day or even every week. Instead I visit the LinkedIn website in little bursts–such as just after a conference–or when I want to find someone’s phone number. I’ve also turned off most of their automatic e-mails at this point, though those can be useful prompts when you’re just getting started.

You can view my public profile at http://linkedin.com/in/netrinomike. If we’ve met somewhere (online or off), feel free to send me an invitation.

Twittermy own private specialized news service

Twitter is something completely different. In fact, it is hard to describe what twitter is. That’s partly because it is many different things to many different people. For example, I often hear people say they don’t use twitter because they don’t want to know what their friend Joe had for lunch. But I’ve been using Twitter almost two years and have never learned what anyone had for lunch there.

Thus rather than try to describe Twitter or its capabilities, I’ll just tell you how I use it as an engineer. I currently “follow” 276 twitter users. Just a handful of these are “friends”, though a larger set are “acquaintances”; most I’ve never met. When one of the users that I follow writes something (in the lingo, “tweets”), I see it in a timeline of recent posts. All of the posts are short text (maximum 140 characters). I usually check in on this timeline 1 or 2 times a day, at which point I scan them for interesting bits of information; except for sometimes following links to longer articles, this activity takes on the order of 15 minutes a day tops.

I DON’T follow users who tweet a lot–say more than ten times per day (a quick look suggests they collectively average less than one per day)–for long. And I DON’T follow users that tweet what they ate for lunch. In fact, I ONLY follow users that typically include a link in every tweet. That is, what they are doing is feeding me a headline of possible interest; if it is of interest and I have time, then I follow the link to read more.

The vast majority of the users I follow are in the embedded systems design community. Some are engineers. Some are marketers. Some sell tools that I use. Some are just in software or engineering more broadly. A few cover hobby interests of mine. The best tweeters always stay on topic, in their area of expertise–just as I try to do by posting from a narrower topic area than I read.

From reading these streams of short headlines I stay vastly more up to date on the technologies and products and subjects of most interest to me than was ever possible before. I’ve basically stopped reading newspaper websites and some blogs and read twitter instead. (But just like printed newspapers, when you don’t have time to keep up, the old stuff just drifts to the bottom of the stack where you may never get to it.)

By the way, I read and post Twitter messages almost exclusively from an app (Twitterific) on my iPhone. I hardly ever visit the Twitter website directly. I prefer the user experience of the app and can easily find spare minutes to read from my phone while away from my desk.

You can view a timeline of my tweets at http://twitter.com/embeddedbarr. If you find the kinds of links I post there interesting, feel free to “follow” me. Unlike most other social networking services, you can follow anyone on Twitter just for knowing their handle.

Deliciousmy Internet memory book

Delicious is an Internet bookmarking service that can be social if you want it to be. By bookmarking service I mean that it’s an alternative to the long list of bookmarks you’ve probably been keeping in your browser.

Rather, as I come across interesting web pages during Internet research, I save those I think I may want to come back to sometime later in delicious. There are a number of advantages of keeping bookmarks in this way:

  • you can add notes to each bookmark
  • you can categorize (“tag”) each bookmark in as many ways as you want (e.g., “embedded” + “bloggers”)
  • you can search for a previous bookmark by keyword or tag
  • your bookmarks are not tied to a specific browser on a specific computer

After using Delicious for more than five years, I now keep just 12 bookmarks in my web browser. These are links that I use daily or weekly. One of those is a shortcut to add the page I’m on to delicious; another to my delicious history.

Delicious can be social in that you can easily share links with friends and see what’s popular across all users and things like that. I never use any of those features. (For one thing, what’s popular on the whole site never includes the stuff about embedded software that I’m most passionate about.) But though I don’t connect to other delicious users much I do make the majority of my bookmarks public–so you can browse or search them too.

You can see my public bookmarks at http://www.delicious.com/frappucino.

Please share your experiences with social networking and suggestions for other useful services in the comments below. (I do use Facebook, by the way, but not for professional purposes.)

Is a Smartphone an Embedded System?

January 27th, 2011 by Michael Barr

When I wrote my first book about embedded programming, back in the late 1990’s, I carefully defined the term embedded system as follows:

An embedded system is a combination of computer hardware and software, and perhaps additional mechanical or other parts, designed to perform a dedicated function. In some cases, embedded systems are part of a larger system or product, as is the case of an anti-lock braking system in a car. Contrast with general-purpose computer.

I think this language still does a good job of capturing the difference between embedded and general-purpose computers. (In a sign of the times that is simultaneously uplifting and depressing to me, this exact language has been literally copied all over the Internet, mostly without any citation whatsoever.) But there have always been gray areas in the middle and the consumer electronics market is moving toward even greater blur.

Smartphones and tablet computers–like the Apple (Nasdaq:AAPL) iPhone and iPad, as well as the many Android-powered devices–clearly lie somewhere between embedded system and general purpose computer. Indeed, it has been helpful to me at times to think of Apple as a company that has profited by moving away from designing configurable and openable general purpose computers and toward designing more restricted and clearly physically closed embedded systems faster than its competitors.

So far this year, I’ve been finding time to play around with iPhone programming. (My first app has nothing to do with embedded systems, so won’t rate a mention in this blog even after it releases.) And I’m happy to report that in several ways the experience of writing iOS applications is similar to embedded programming. You program mostly in C (wrapped in a layer of Objective-C). And you must worry about writing code that uses the processor and memory efficiently. I feel right at home!

However, programming for iOS is also like programming for big general-purpose computers in that there are vast API libraries available to separate you from the hardware and low-level driver details. And there’s more memory and CPU available than in the vast majority of embedded systems.

Smartphones and tablet computers truly are at the crossroads between embedded systems and general purpose computers. If you are coming to them from the perspective of a firmware developer, you can think of them as merely very high end embedded systems. Or if you are coming from the world of general-purpose computing, you can think of them as resource-constrained computers reminiscent of an earlier era. Either way, you’re bound to find some things you like about these new programming platforms and others that you don’t.

P.S. I’ll have lots more to say about Objective-C in a later post.

Embedded Software Boot Camp in a Box

December 15th, 2010 by 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.

STR912-SK

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 http://www.netrino.com/Boot-Camp-Box.

Firmware-Specific Bug #10: Jitter

December 2nd, 2010 by 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

Firmware-Specific Bug #9: Incorrect Priority Assignment

November 30th, 2010 by 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’ve 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 original design team—unless a death and a lawsuit forces an investigation.

Best Practice: 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.

There’s insufficient space in this column for me to explain why and how RMA works. But I’ve written on these topics before and recommend you start with “Introduction to Rate-Monotonic Scheduling” and then read my column “3 Things Every Programmer Should Know About RMA.”

Please know that if you don’t use RMA to prioritize your tasks and ISRs (as a set), there’s only one entity with any guarantees: the one highest-priority task or ISR can take the CPU for itself at any busy time—barring priority inversions!—and thus has up to 100% of the CPU bandwidth available to it. Also note that there is no rule of thumb about what percentage of the CPU bandwidth you may safely use between a set of two or more runnables unless you do follow the RMA scheme.

Firmware-Specific Bug #8

Firmware-Specific Bug #10