The Early Days

In the early 1990s, as now, the specialized knowledge needed to write reliable embedded software was mostly not taught in universities. The only class I’d had in programming was in FORTRAN; I’d taught myself to program in assembly and C through a pair of hands-on labs that were, in hindsight, my only formal education in writing embedded software. It was on the job and from the pages of the magazine, then, that I first learned the practical skills of writing device drivers, porting and using operating systems, meeting real-time deadlines, implementing finite state machines, the pros and cons of languages other than C and assembly, remote debugging and JTAG, and so much more.

In that era, my work as a firmware developer involved daily interactions with Intel hex files, device programmers, tubes of EPROMs with mangled pins, UV erasers, mere kilobytes of memory, 8- and 16-bit processors, in-circuit emulators, and ROM monitors. Databooks were actual books; collectively, they took up whole bookshelves. I wrote and compiled my firmware programs on an HP-UX workstation on my desk, but then had to go downstairs to a lab to burn the chips, insert them into the prototype board, and test and debug via an attached ICE. I remember that on one especially daunting project eight miles separated my compiler and device programmer from the only instance of the target hardware; a single red LED and a dusty oscilloscope were the extent of my debugging toolbox.

Like you I had the Internet at my desk in the mid-90s, but it did not yet provide much useful or relevant information to my work other than via certain FTP sites (does anyone else remember FTPing into sunsite.unc.edu? or Gopher?). The rest was mostly blinking headlines and dancing hamster; and Amazon was merely the world’s biggest river. There was not yet an Embedded.com or EETimes.com. To learn about software and hardware best practices, I pursued an MSEE and CS classes at night and traveled to the Embedded Systems Conferences.

At the time, I wasn’t aware of any books about embedded programming. And every book that I had found on C started with “Hello, World”, only went up in abstraction from there, and ended without ever once addressing peripheral control, interrupt service routines, interfacing to assembly language routines, and operating systems (real-time or other). For reasons I couldn’t explain years later when Jack Ganssle asked me, I had the gumption to think I could write that missing book for embedded C programmers, got a contract from O’Reilly, and did–ending, rather than starting, mine with “Hello, World” (via an RS-232 port).

In 1998, a series of at least three twists of fate spanning four years found me taking a seat next to an empty chair at the speaker’s lunch at an Embedded Systems Conference. The chair’s occupant turned out to be Lindsey Vereen, who was then well into his term as the second editor-in-chief of the magazine. In addition to the book, I’d written an article or two for ESP by that time and Lindsey had been impressed with my ability to explain technical nuances. When he told me that he was looking for someone to serve as a technical editor, I didn’t realize it was the first step towards my role in that position.

Future Trends

Becoming and then staying involved with the magazine, first as technical editor and later as editor-in-chief and contributing editor, has been a highlight of my professional life. I had been a huge fan of ESP and of its many great columnists and other contributors in its first decade. And now, looking back, I believe my work helped make it an even more valuable forum for the exchange of key design ideas, best practices, and industry learning in its second decade. And, though I understand the move away from print towards online publishing and advertising, I am nonetheless saddened to see the magazine come to an end.

Reflecting back on these days long past reminds me that a lot truly has changed about embedded software design. Assembly language is used far less frequently today; C and C++ much more. EPROMs with their device programmers and UV erasers have been supplanted by flash memory and bootloaders. Bus widths and memory sizes have increased dramatically. Expensive in-circuit emulators and ROM monitors have morphed into inexpensive JTAG debug ports. ROM-DOS has been replaced with whatever Microsoft is branding embedded Windows this year. And open-source Linux has done so well that it has limited the growth of the RTOS industry as a whole–and become a piece of technology we all want to master if only for our resumes.

So what does the future hold? What will the everyday experiences of embedded programmers be like in 2020, 2030, or 2040? I see three big trends that will affect us all over those timeframes, each of which has already begun to unfold.

Trend 1: Volumes Finally Shift to 32-bit CPUs

My first prediction is that inexpensive, low-power, highly-integrated microcontrollers–as best exemplified by today’s ARM Cortex-M family–will bring 32-bit CPUs into even the highest volume application domains. The volumes of 8- and 16-bit CPUs will finally decline as these parts become truly obsolete.

Though you may be programming for a 32-bit processor already, it’s still true that 8- and 16-bit processors still drive CPU chip sales volumes. I’m referring, of course, to microcontrollers such as those based on 8051, PIC, and other instruction set architectures dating back 30-40 years. These older architectures remain popular today only because certain low-margin, high-volume applications of embedded processing demand squeezing every penny out of BOM cost.

The limitations of 8- and 16-bit architectures impact the embedded programmers in a number of ways. First, there are the awkward memory limitations resulting from limited address bus widths–and the memory banks, segmenting techniques, and other workarounds to going beyond those limitations. Second, these CPUs are much better at decision making than mathematics–they lack the ability to manipulate large integers efficiently and have no floating-point capability. Finally, these older processors frequently lack modern development tools, are unable to run larger Internet-enabled operating systems, such as Linux, and don’t feature the security and reliabiltiy protections afforded by an MMU.

There will, of course, always be many applications that are extremely cost-conscious, so my prediction is not that they will disappear completely, but that the overall price (including BOM cost as well as power consumption) of 32-bit micro controllers, with their improved instruction set architectures and transistor geometries, will win on price. That will put the necessary amount of computing power into the hands of some designers and make our work easier for all of us. It also helps programmers accomplish more in less time.

Trend 2: Complexity Forces Programmers Beyond C

My second prediction is that the days of the C programming language’s dominance in embedded systems are numbered.

Don’t get me wrong, C is a language I know and love. But, as you may know firsthand, C is simply not up to the task of building systems requiring over a million lines of code. Nonetheless, the demanded complexity of embedded software has been driving our systems towards more than a million lines of code. At this level of complexity, something has to give.

Additionally, our industry is facing a crisis: the average age of an embedded developer is rapidly increasing and C is generally not taught in universities anymore. Thus, even as the demand for embedded intelligence in every industry continues to increase, the population of skilled and experienced C programmers is on the decline. Something has to give on this front too.

But what alternative language can be used to build real-time software, manipulate hardware directly, and be quickly ported to numerous instruction set architectures? It’s not going to be C++ or Ada or Java, for sure–as those have already been tried and found lacking. A new programming language is probably not the answer either, across so many CPU families and with so many other languages already tried.

Thus I predict that tools that are able to reliably generate those millions of lines of C code automatically for us, based on system specifications, will ultimately take over. As an example of a current tool of this sort that could be part of the trend, I direct your attention to Miro Samek’s dandy open source Quantum Platform (QP) framework for event-driven programs and his (optional) free Quantum Modeler (QM) graphical modeling tool. You may not like the idea of auto-generated code today, but I guarantee that once you push a button to generate consistent and correct code from an already expressive statechart diagram, you will see the benefits of the overall structure and be ready to move up a level in programming efficiency.

I view C as a reasonable common output language for such tools (given that C can manipulate hardware registers directly and that every processor ever invented has a C compiler). Note that I do expect there to be continued demand for those of us with the skills and interest to fine tune the performance of the generated code or write device drivers to integrate it more closely to the hardware.

Trend 3: Connectivity Drives Importance of Security

We’re increasingly connecting embedded systems–to each other and to the Internet. You’ve heard the hype (e.g., “Internet of things” and “ubiquitous computing”) and you’ve probably already also put TCP/IP into one or more of your designs. But connectivity has a lot of implications that we are only starting to come to terms with. The most obvious of these is security.

A connected device cannot hide for long behind “security through obscurity” and, so, we must design security into our connected devices from the start. In my travels around our industry I’ve observed that the majority of embedded designers are largely unfamiliar with security. Sure some of you have read about encryption algorithms and know the names of a few. But mostly the embedded community is shooting in the dark as security designers, within organizations that aren’t of much help. And security is only as strong as the weakest link in the chain.

This situation must change. Just as Flash memory has supplanted UV-erasable EPROM, so too will over-the-net patches and upgrades take center stage as a download mechanism in coming years and decades. We must architect our systems first to be secure and then to accepted trusted downloads so that our products can keep up in the inevitable arms race against hackers and attackers.

And That’s a Wrap

Whatever the future holds, I am certain that embedded software development will remain an engaging and challenging career. And you’ll still find me writing about the field at http://embeddedgurus.com/barr-code and http://twitter.com/embeddedbarr.

As the designers of embedded systems, the first thing we must accomplish on any project is to make the hardware and software work. That is to say we need to make the system behave as it was designed to. The first iteration of this is often flaky; certain uses or perturbations of the system by testers can easily dislodge the system into a non-working state. In common parlance, “expect bugs.”

Given time, tightening cycles of debug and test can get us past the bugs and through to a shippable product. But is a debugged system good enough? Neither reliability nor security can be tested into a product. Each must be designed in from the start. So let’s take a closer look at these two important design aspects for modern embedded systems and then I’ll bring them back together at the end.

Reliable Embedded Systems

A product can be stable yet lack reliability. Consider, for example, an anti-lock braking computer installed in a car. The software in the anti-lock brakes may be bug-free, but how does it function if a critical input sensor fails?

Reliable systems are robust in the face of adverse run-time environments. Reliable systems are able to work around errors encountered as they occur to the system in the field–so that the number and impact of failures are minimized. One key strategy for building reliable systems is to eliminate single-points-of-failure. For example, redundancy could be added around that critical input sensor–perhaps by adding a second sensor in parallel with the first.

Another aspect of reliability that is under the complete control of designers (at least when they consider it from the start) are the “fail-safe” mechanisms. Perhaps a suitable but lower-cost alternative to a redundant sensor is detection of the failed sensor with a fall back to mechanical braking.

Failure Mode and Effect Analysis (FMEA) is one of the most effective and important design processes used by engineers serious about designing reliability into their systems. Following this process, each possible failure point is traced from the root failure outward to its effects. In an FMEA, numerical weights can be applied to the likelihoods of each failure as well as the seriousness of consequences. An FMEA can thus help guide you to a cost effective but higher reliability design by highlighting the most valuable places to insert the redundancy, fail-safes, or other elements that reinforce the system’s overall reliability.

In certain industries, reliability is a key driver of product safety. And that is why you see these techniques and FMEA and other design for reliability processes being applied by the designers of safety-critical automotive, medical, avionics, nuclear, and industrial systems. The same techniques can, of course, be used to make any type of embedded system more reliable.

Regardless of your industry, it is typically difficult or impossible to make your product as reliable via patches. There’s no way to add hardware like that redundant sensor, so your options may reduce to a fail-safe that is helpful but less reliable overall. Reliability cannot be patched or tested or debugged into your system. Rather, reliability must be designed in from the start.

Secure Embedded Systems

A product can also be stable yet lack security. For example, an office printer is the kind of product most of us purchase and use without giving a minute of thought to security. The software in the printer may be bug-free, but is it able to prevent a would-be eavesdropper from capturing a remote electronic copy of everything you print, including your sensitive financial documents?

Secure systems are robust in the face of persistent attack. Secure systems are able to keep hackers out by design. One key strategy for building secure systems is to validate all inputs, especially those arriving over an open network connection. For example, security could be added to a printer by ensuring against buffer overflows and encrypting and digitally signing firmware updates.

One of the unfortunate facts of designing secure embedded systems is that the hackers who want to get in only need to find and exploit a single weakness. Adding layers of security is good, but if even any one of those layers remains fundamentally weak, a sufficiently motivated attacker will eventually find and breach that defense. But that’s not an excuse for not trying.

For years, the largest printer maker in the world apparently gave little thought to the security of the firmware in its home/office printers, even as it was putting tens of millions of tempting targets out into the world. Now the security of those printers has been breached by security researchers with a reasonable awareness of embedded systems design. Said one of the lead researchers, “We can actually modify the firmware of the printer as part of a legitimate document. It renders correctly, and at the end of the job there’s a firmware update. … In a super-secure environment where there’s a firewall and no access — the government, Wall Street — you could send a résumé to print out.”

Security is a brave new world for many embedded systems designers. For decades we have relied on the fact that the microcontrollers and Flash memory and real-time operating systems and other less mainstream technologies we use will protect our products from attack. Or that we can gain enough “security by obscurity” by keeping our communications protocols and firmware upgrade processes secret. But we no longer live in that world. You must adapt.

Consider the implications of an insecure design of an automotive safety system that is connected to another Internet-connected computer in the car via CAN; or the insecure design of an implanted medical device; or the insecure design of your product.

Too often, the ability to upgrade a product’s firmware in the field is the very vector that’s used to attack. This can happen even when a primary purpose for including remote firmware updates is motivated by security. For example, as I’ve learned in my work as an expert witness in numerous cases involving reverse engineering of the techniques and technology of satellite television piracy, much of that piracy has been empowered by the same software patching mechanism that allowed the broadcasters to perform security upgrades and electronic countermeasures. Ironically, had the security smart cards in those set-top boxes had only masked ROM images the overall system security may have been higher. This was certainly not what the designers of the system had in mind. But security is also an arms race.

Like reliability, security must be designed in from the start. Security can’t be patched or tested or debugged in. You simply can’t add security as effectively once the product ships. For example, an attacker who wished to exploit a current weakness in your office printer or smart card might download his hack software into your device and write-protect his sectors of the flash today so that his code could remain resident even as you applied security patches.

Reliable and Secure Embedded Systems

It is important to note at this point that reliable systems are inherently more secure. And that, vice versa, secure systems are inherently more reliable. So, although, design for reliability and design for security will often individually yield different results–there is also an overlap between them.

An investment in reliability, for example, generally pays off in security. Why? Well, because a more reliable system is more robust in its handling of all errors, whether they are accidental or intentional. An anti-lock braking system with a fall back to mechanical braking for increased reliability is also more secure against an attack against that critical hardware input sensor. Similarly, those printers wouldn’t be at risk of fuser-induced fire in the case of a security breach if they were never at risk of fire in the case of any misbehavior of the software.

Consider, importantly, that one of the first things a hacker intent on breaching the security of your embedded device might do is to perform a (mental, at least) fault tree analysis of your system. This attacker would then target her time, talents, and other resources at one or more single points of failure she considers most likely to fail in a useful way.

Because a fault tree analysis starts from the general goal and works inward deductively toward the identification of one or more choke points that might produce the desired erroneous outcome, attention paid to increasing reliability such as via FMEA usually reduces choke points and makes the attacker’s job considerably more difficult. Where security can break down even in a reliable system is where the possibility of an attacker’s intentionally induced failure is ignored in the FMEA weighting and thus possible layers of protection are omitted.

Similarly, an investment in security may pay off in greater reliability–even without a directed focus on reliability. For example, if you secure your firmware upgrade process to accept only encrypted and digitally signed binary images you’ll be adding a layer of protection against an inadvertently corrupted binary causing an accidental error and product failure. Anything you do to improve the security of communications (i.e., checksums, prevention of buffer overflows, etc.) can have a similar effect on reliability.

The Only Way Forward

Each year it becomes increasingly important for all of us in the embedded systems design community to learn to design reliable and secure products. If you don’t, it might be your product making the wrong kind of headlines and your source code and design documents being poured over by lawyers. It is no longer acceptable to stick your head in the sand on these issues.

Beer and Boards sounds really fun. Here’s how it works: Every “All Access” attendee will get to choose one of three free development kits to take home:

• TI CC2540DK-MINI Bluetooth Low Energy Kit
• XL_STAR MMA8451 Accelerometer Kit
• Xilinx Spartan-6 FPGA LX9 MicroBoard Kit

Once you select your preferred kit you will receive information on the time and place for the relevant Beer and Boards party, at which you will get to drink free beer at a special meet-and-greet with one of your kit’s designers to talk about your new kit and its capabilities. Three boards spread out over three days.

Nerds drinking beer! I love it. What will they think of next?

Before you register for this year’s ESC, be sure to check out my earlier post Save Big on Embedded Systems Conference Registration. Also, remember to use the promo code BARR20 to save an additional 20% off registration and be entered to win a free seat at a future Embedded Software Boot Camp or one of 20 free copies of the Embedded C Coding Standard.

Judging from the speaker and course lineups, it looks like it’s going to be a really great ESC conference again this year. I strongly encourage you to go if you can. Here are five great reasons to register ASAP:

#1: IT’S CHEAPER THIS WEEK! – The current early registration pricing expires this Friday, March 25. Registering now will save you $400 off the onsite price of the All Access, 4-Day, and 3-Day Conference Passes or $200 off a 1-Day Pass. (Note there are also group discounts available.)

#2: USE PROMO CODE “BARR20″ TO SAVE AN ADDITIONAL 20%! – During the registration process there is a place to enter a “Promo Code”. No matter what conference package you select, you will receive an additional 20% off the price if you use my special code “BARR20″. For the All Access Conference Pass that’s an additional $479 discount on top of the $400 above. Wow!

#3: GRAND PRIZE: FREE SEAT AT EMBEDDED SOFTWARE BOOT CAMP – Many people have told me that their company only has a set amount of budget for training and conferences per year and that the Embedded Systems Conference and Embedded Software Boot Camp have to compete for those funds. Well, now you can have your cake and eat it to. One lucky ESC conference attendee will be selected at random to also attend the Embedded Software Boot Camp for free (minimum $2,995 value). (To be entered to win, you must use the “BARR20″ promo code when you register.)

#4: 20 RUNNER-UP PRIZES: EMBEDDED C CODING STANDARD BOOK – Twenty lucky ESC conference attendees will be selected at random to receive a print copy of the Embedded C Coding Standard book. (To be entered to win, you must use the “BARR20″ promo code when you register.)

#5: THE CONFERENCE CONTENT – Use the ESC Schedule Builder to choose from hundreds of training sessions by dozens of expert speakers spread across 25 technical tracks. To this depth and breadth of topics this year are added the 6th Annual Multicore Expo and Texas Instrument’s Technology Day 2011 programs. Wow!

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.

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?

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.

Baltimore

I was born and raised in Charm City and have lived and worked within about 35 miles of downtown Baltimore in all of the years since; I’m writing this from about 10 miles out. I’m thus a proud Baltimoron (er, Baltimorean?). Though the whole Old Bay seasoning/Maryland crab cakes thing never caught on with me (I’m a vegetarian, hon) I maintain many ties to The City That Reads and, as a result, struggle to this day with the proper pronunciation of words like museum, wash, and sink.

Now, Baltimore is not particularly known for its embedded software jobs. Yet Jack Ganssle and Nigel Jones as well as many top-notch embedded system designers are located right here. Unfortunately, most of the local embedded developers would have to kill you if they told you what kinds of systems they design. (Suffice it to say that the folks over at nearby NSA and their many subcontractors make a heck of a lot more receivers than they do transmitters.)

You’ll be hearing more from me about what’s going on locally here in Baltimore, because that’s my community. Local is the new global, after all.

Technology

As much as I truly love working in the field of embedded systems, I recognize that what we do is typically everything but state of the art. At a very high level, our specialty is putting decades old processor technology and trusted reliable software languages and libraries into previously unthinkable applications–in a diverse set of domains, from medical devices to automobiles. That’s why we mostly still use the C programming language.

However, like most good technologists, I maintain an active interest in what’s going on in the state of the art in my field. On the software side, what seems to be hottest right now is cloud computing, smartphone apps, and big data.

I read and think a lot about all of this. And from now on I’ll be passing along bits and pieces that I hope you’ll find interesting too.

Startups

Finally, though I am principally an engineer, I also have an MBA. And for over 12 years I have run a successful small business (i.e., Netrino). I’ve also been involved in a few technology startups that didn’t go so far. And I really enjoy interacting with other entrepreneurs, helping them refine their ideas, and sharing what I’ve learned as a businessman. (Over the years, Netrino has also helped a number of startups develop prototype embedded systems.)

This year all of this stuff seems to be coming together in my world. That’s partly because Baltimore has a rapidly expanding technology startup community. The heart of this community is at the Emerging Technology Center in downtown Baltimore, where I’ll be increasingly making time to get involved. There’s also the wonderful Baltimore Node Hackerspace, where Baltimore, technology, and startups actually intersect with embedded systems design.

I think these additions to the topics covered here and in my twitter feed will make for an even more interesting read. I hope you agree and would love to hear your thoughts in the comments below.

“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.

LinkedIn — my 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.

Twitter — my 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/netrinomike. 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.

Delicious — my 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.)

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.