Embedded Engineering

I had been an embedded engineer for the past ten years. For the first half, I was mainly involved in simple hardware  development, and as for software, I delved with Simple programming (Simple Control Loop) specific to particular sets of electronic chips (mainly on ATMEL microcontrollers and  PIC microchips using ANSI-C and Assembly language). And then the latter 5 years, was mostly spent on embedded software with customized operating systems (RTOS – Real Time Operating Systems) using mainly the programming languages  C, and C++.

Since my hardware development faculties are rusty, and because I had been in the most part of my short career, an embedded software developer, I would like to share some ideas I have , though little as they may be, on embedded engineering. And hope to contribute in the growth of some who may not have had the opportunity of training as I have had, but wish to learn in this profession. (Bear in mind though that I too am a work in progress. And this blog is written with the intention of continuous improvement.)

What is embedded engineering?  Embedded engineering is an applied science that is geared toward the creation of “embedded devices”.  Samples of embedded devices are mp3 players, mobile phones, a computer’s video card, ipod, iphones and well anything that basically acts like a personal computer but is not really one. With so many people creating a lot of sophisticated devices, and the laptop or notebook PC becoming smaller and smaller, sometimes an embedded device is misconstrued as a personal computer. But in this case, size really has no bearing. In my humble opinion (and in no way a universal truth), there are some important items that differentiate embedded equipment from that of its personal computer counterpart. And these are :

[1] An embedded device is an electronic device which possesses very limited resource compared to the PC.
- it usually has lesser “brain” or computing power.
- it has a smaller “football field” for memory.

[2] An embedded device is an electronic device which is usage-specific, it cannot compute or process generic PC functions.
- your watch can’t open nor write document files
- your cant do spread sheet computations on a scanner

[3] An embedded device may or may not stand on its own.
- the graphics card of your pc has no use if it is not “plugged in”.
- Well you know how it is with the PC.

Aside from these three, there are more finer points that differentiate embedded devices from the personal computer. These finer differences including the ones listed above play critical roles in the development process.

And like the other applied sciences, Embedded engineering too has so many sub-disciplines. However, in my humble opinion, its two fundamental sub-disciplines are HARDWARE  ENGINEERING (HW) and SOFTWARE ENGINEERING (SW).

HARDWARE EMBEDDED DEVELOPMENT

I may not do justice enough for hardware engineers for I lack the deep “gaussian-function-iiiish” level hardware expertise. But to give some balance on this article,  from a hardware standpoint, [2] stands out because HW engineers have to select the fittest electronic component in light of what needs to be achieved. Think of it as having to select a wall mounted TV, but you don’t really need a gigantic one because your living room wall space for the TV allows only a 40 inch mounting.  Is it wise then for you to buy a $2000 60-Inch flat panel high definition TV?  In the same light, hardware engineers select, re-select and re-select components to fit their designs. Choosing components with the lowest cost without curtailing safety, quality and functionality is top priority. Sometimes, due to our cost driven environment, HW engineers re-design according to cheaper and available components. Key point [2] indirectly governs the overall cost of the device. Which in turn has an effect on final market price or corporate profit.

In the plotting of schematics and creation of a prototype, a hardware guy has to ultimately decide whether his implementation is better than an already available sub-system pre-built by somebody else. In a simplistic analogy, hardware people have to ask “Do I create a finger print scanner or is it better to buy from somebody else?”. Of course, the thought process is not as simple as that.  But point [3] stands.  Some embedded devices like finger print scanners can not stand on their own, but they are created because somebody else will need them. (In hardware, there are times when one has to re-invent the wheel so as not to succumb to pricey components. The risk here is that development might take too much time and resource that the cost of Research and Development (R&D) will be bigger than originally planned.)

Unlike [2] and [3], point [1] is an effect of the general desire to make the product affordable or to increase corporate profit. Whichever the case, to achieve cost reduction,  hardware engineers are obligated to build a system with very limited resource but can, and will get the job done. (In my personal experience, sometimes a brilliant management team has to step in to stop R&D engineers from over-designing resulting to too much cost and too much loss in time-to-market.)

SOFTWARE and FIRMWARE

As I have said, I have for the most part of my short career become an embedded software developer. (More specifically in the development of customized applications, networking protocol implementations and partially in the realm of the operating systems.) In the technical world slang, most if not all embedded software developers are dubbed as firmware engineers(Ascher Opler-1967). Simply put, firmware or “microcode” is a kind of software which once installed, needs some form of special mechanism for it to be updated or modified. Some even are designed “NEVER” to be updated. Firmware codes or programs usually make up the barest essential of the system. Examples of devices that have microcode in them are your digital wrist watches, Engine Control Unit (ECU) and USB memory sticks.

However, with the advent of new technology which makes core-function upgrade relatively easy (FLASH Technology and UVPROMs ),  Ascher Opler’s “softness” based definition of firmware now needs some reconsideration. And since I am in no position to redefine it yet, I stumbled upon Mark Smotherman’s A Brief History of Microprogramming” which provides some clarity to what I think holds ground as to what firmware has evolved as of this time period.

And as for this blog-series however, I would like to refer to firmware as basically a piece of software that is intended for embedded devices.

Next …  (Embedded Software Paradigm )

Advertisement