Final Thoughts On The Embedded Community

This is part 3 of 4 in a series about ESC Chicago and the Sensors Expo and Conference. See previous posts about Day 1 and Day 2.

I imagine if a doctor was diagnosing the medical condition of the embedded community, he would walk into the tiny exam room, take one look at the embedded community sitting there in its socks and underwear on the crinkly disposable exam table cover and say:

“Yup, still fragmented.”

What do I mean by this? It means that even with my posturing about the need for community AND my lack of expertise in the topic, there are some undeniable rifts in the embedded community. And they will always be there. Why?

1. Too many vendors with their own pieces of silicon
   • Guess what? Companies like making money! Amazing, right? I can name at least 5 monstrous companies that produce independent silicon chips, almost always with similar cores that rhyme with “schlARM”. They have their niche areas and peripherals that are used in that segment; examples areas that a vendor might try to target are motor control, display processing, low cost, low power or RF. But in the end, the very things that distinguish them from their competitors and therefore allow them make money, also drives the community apart.
2. Too many closed doors
   • Another problem on the vendor side can be the amount of information provided to the people working on their chips. Without open access to the information, users are forced into the “camps” of the vendors in order to access features buried within the silicon. Less mobility between chips means more fragmentation.
3. Too much software
   • Well what about abstraction? For those out there that are more on the analog side of things, abstraction is writing code that isn’t controlling something directly. Think about it like you’re a teacher. You care a lot about turning the lights off in your classroom and want to teach your kids about why it’s important in order to save energy. In a non-abstracted case, you would tell each of the kids to turn the lights off when it’s their turn. Perhaps Wednesday it’s Johnny and Thursday it’s Susie. So you tell them directly. Abstraction in the simplest sense would be assigning Bobby to remember whose turn it is each day of the week. That way, you only have to tell Bobby to have someone turn off the lights; it’s the same every time. Bringing it back to processors and the embedded community, if things were abstracted, you could always tell “Bobby” to do the same thing and he would have close to the same response each time. Well there is such a thing that even the layman such as me is familiar with: operating systems. But this isn’t like the PC world where the choices have been culled down to a select two or three. There are embedded versions of larger OSes (think Win CE or Embedded Linux) and RTOS (Real Time Operating Systems) which are an even lighter version of their half cousins named previously. Beyond that there are superloops and other small implementations. The point is, there are a lo00000t of choices for software for a looooot  of different processors. It’s fragmented. But why all the trouble? Why do we need so many choices?
4. Too many market segments
   • It’s true. That’s why embedded has been growing steadily for the past 20 years and will likely continue to keep growing. There are a lot of  different needs! I guarantee you that engineers working on high-reliability industrial controls don’t care that much about Android. Sure, it could work, but it’s a new OS with lots of potential bugs and doesn’t really fit the needs. Similarly, handset makers don’t want to use reliable code from 10 years ago because all the reliability in the world doesn’t make a flashy new interface for mobile, web-enabled handsets. Chip vendors pick and choose to play to specific segments, as do the software vendors, creating hundreds of potential combinations; it’s much more likely that whatever current developers are working on though is a much smaller combinatorial subset. And so the fragmentation continues.

I know that analog is my niche and that there are some very compelling cases for using it in different areas of electronics. But I’m not stupid; there was a reason I took interest in the embedded space and why you should do the same. Everyone will continue to expect more from their devices, whether scientific, consumer or somewhere in between; if you’re on the internet reading this post, you’re likely used to the benefits of Moore’s Law and will continue to be.

What I’m trying to say is that there is value in learning about embedded systems; learning about some component of embedded computing is better than ignoring it. As software continues ascending into further levels of abstraction (think Python instead of C), there will be fewer people around that know how to reach down into silicon and flip a bit. Knowing how to do so not only will help you in your day to day tasks, but could make you a very employable engineer/programmer.

And who knows, perhaps embedded design will be the next black magic, much like analog is considered today!