Posts Tagged ‘embedded’

« Older Entries
Newer Entries »

Embedded Software Community Survey Findings

Monday, February 14th, 2011 Michael Barr

In addition to blogging here and tweeting (there), I also write a monthly e-mail newsletter about embedded software that is called Firmware Update. More than 15,000 embedded software developers are currently subscribed to this newsletter. Here’s what I learned in a recent survey of those newsletter readers, in which 452 individuals participated.

Geography

Embedded software engineers are spread all over the world. Of the survey respondents, only 40% are located in the United States; California houses about 1/4 of those. Two other well represented countries are India (9%) and Canada (7%). The remainder of respondents are spread across some 43 other countries, from Argentina to South Africa. Every continent but Antarctica is on the list. It’s amazing how quickly the world is shrinking because of the Internet, isn’t it?

Age

According to this survey, the average age of an embedded software engineer is approximately 37 years. Overall, approximately 55% are between 20 and 39 years of age and 45% are between 40 and 69. Just one respondent is 70 or over and none are under 20.

Education

Here I’ll admit to being a bit shocked: we are as a group far more educated than I thought going into the survey. Approximately 49% of respondents hold a graduate degree. These are mostly Master of Science degrees, of course. But almost 1 out of 20 of us holds a PhD. On the flipside, just 5% of respondents said they are practicing embedded software with only a high-school diploma or 2-year degree.

As I expected, we’ve mostly been educated as Electrical Engineers. Over 55% of all the undergraduate and graduate degrees held by respondents were EE degrees. Interestingly, Computer Engineering was slightly more popular than Computer Science among the rest. Though I offered a free-form “Other” textbox and quite a few folks entered something there, there were no large percentage of other degrees. Only Mechanical Engineering, Math, and Physics stood out as at least occasionally repeated answers. (Winner for most surprising answer: Psychology.)

Employment and Team Size

The number of unemployed respondents was about 3%. The vast majority of the rest are paid as full-time salaried employees. But approximately 15% of us are consultants (“on a per project basis; at times multiple clients simultaneously”) or contractors (“by contract to one large company for a set length of time”). And some of the consultants also have a full-time job or a contractor position.

The total number of embedded software engineers employed at the same company varies widely, from 1 to over 1,000. But the single most common choice was 2-4. In my mission to improve the quality of embedded software across industries, I’ve seen first hand that one of the reasons for poor quality is that a small team of firmware engineers working at a company that specializes in other types of engineering or product design tends not to be connected into the latest best practices.

The number of embedded software engineers on respondents’ current projects is smaller, of course, and ranged from 1 to over 200. Not surprisingly, project teams with more than 20 firmware engineers are quite rare (just 5%). On the flip side, teams with just a single firmware engineer are quite common (almost 25%). The average team size seems to be around 1.5-2.

Experience

As I planned the survey, I hoped to distinguish three types of experience: electronics design, embedded programming, and other programming. So I asked three distinct questions, each with the same answer choices.

Here’s my interpretation of the answers:

  • Over 60% of embedded software developers also design hardware–at least from time to time–or came to programming after first working as a hardware designer. That’s a big number. Shockingly, it’s an even bigger number than the percentage holding an EE degree cited above. The average number of years of hardware design experience is around 8.5
  • The average amount of embedded programming experience is approximately 12 years.
  • The average number of years of other programming experience is about 7.5.

In other words, embedded software developers are jacks of all trades. Many of us weave back and forth in our careers, and even sometimes within a single project, between electronics or chip design, writing low-level embedded software, and writing software for PCs, websites, and other platforms.

Tags: , ,
Posted in Uncategorized | No Comments »

Is a Smartphone an Embedded System?

Thursday, January 27th, 2011 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.

Tags: , ,
Posted in Uncategorized | 3 Comments »

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.

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.

Tags: , , , , , ,
Posted in Efficient C/C++, RTOS Multithreading | No Comments »

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

Tags: , , , , , , , ,
Posted in Firmware Bugs, RTOS Multithreading | 1 Comment »

Firmware-Specific Bug #9: Incorrect Priority Assignment

Tuesday, November 30th, 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’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

Tags: , , , , , , ,
Posted in Firmware Bugs, RTOS Multithreading | No Comments »

« Older Entries
Newer Entries »