Posts Tagged ‘firmware’

What is Arduino?

Friday, February 18th, 2011 Michael Barr

Believe it or not, artists, hobbyists, and other “makers” have discovered embedded computing. Increasingly, they’re turning to an open source hardware platform called Arduino to put firmware inside their creations. Over 100,000 of these inexpensive embedded systems have apparently been sold for use in prototyping and in a range of low-volume “products.”

What is Arduino?

Arduino is the name of a family of related circuit boards, which includes the Arduino One shown in the photo below. The official website of the Arduino project is http://www.arduino.cc.

Arduino Uno Circuit Board

Like many open source projects, there appears to be a lot of branching from the original design. So what follows is a generalization. Arduino is based on the Atmel AVR microcontrollers, such as the ATmega328. The ATmega328 is an 8-bit MCU with on-chip memory in the form of 32K flash, 2K SRAM, and 1K EEPROM. In the Arduino designs, the processor is generally clocked at 16MHz.

There are also a whole host of pin-compatible extension boards, containing displays, buttons, sensors, actuators, network interfaces and/or wire-wrap prototyping areas.

The Arduino IDE is an open source cross-platform tool (i.e., written in Java) that is based on the avr-gcc compiler (a variant of the GNU compiler for 8-bit AVRs). Though you can program in the “Arduino language,” this is really just a set of function calls that gets translated into C–so you can also program in C or C++ if you prefer.

An open source bootloader (0.5K) makes downloading your programs to the Arduino board easy.

Should you care about Arduino?

As a professional embedded software developer, I don’t have much use for a prototyping board like the Arduino. I’m generally handed a custom board by a hardware designer on my team. And many of you design both the hardware and the software for your projects. So why should we care about Arduino?

I don’t think I know the answer to this question yet. But it is very interesting to find embedded software being used by such a diverse group of artists, hobbyists, and entrepreneurs. What do you think?

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.

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.

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

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