Embedded is a LARGE field, and ranges from really little stuff to things that are really just a desktop machine in a funny box.

I’m going to go with 3 categories of embedded systems, to correspond with my experience, then I’ll make some recommendations.

Small embedded systems are things run by micro-controller type devices. They don’t have any OS, scheduler, etc, etc. You’re running code running directly on the CPU, and in general you’ll have main loop that gets started at power on and never exits. There are a lot of options for micro-controllers, ranging from things like the venerable 8051 to the really tiny PIC up and a lot of products based on the ARM cores. These are nice because you have complete and direct control over every facet of the system’s operation. Of course, that also means you need to be careful about things like timing and latency of operations, and how long you can spend on any one thing before you go back to your main loop.

Medium embedded systems are bigger things, and which will have an embedded OS such as Wind River’s pSOS (there are MANY choices for this, I happen to have used pSOS once upon a time). I’m calling it medium because at this point you’re NOT running a single main loop, and actually have a scheduler. The hardware may not be much different from the higher end of the previous group, but the presence of a scheduler and a more formalized driver architecture really improves your ability as a programmer to get stuff done. On the downside, it might be more trouble to meet really tight timing because you can easily introduce more unexpected delays from the scheduler. Also, you have to be careful that your hardware does things that make sense for the OS you are using – for instance, not all interrupt strategies work with all embedded OSs. At the larger end of this group I’ll put in Windows CE, the embedded offering from Microsoft. This segment is getting squeezed out to some degree as more and more processing power is becoming available for less and less money.

Big embedded systems are even bigger and run an OS that a desktop user might well recognize. Linux is common here, as is the embedded (or even the regular!) version of MS Windows. There’s a lot of this going around in the medical field (look at a lot of ultrasound machines). The advantage here is that you can run a full bore installation of Linux, with all the useful stuff that a real OS brings on very small and very cheap hardware anymore.

Now, being your first foray into embedded, and given that it’s medical (where I suspect you have margins to support reasonable hardware budgets), I recommend that you use some small computer like a rasberry pi, a beaglebone, or something else based on one of the multitude of ARM cores out there. Run Linux on it, and build your app on top of that. In fact, you probably want to simply leave your device as-is, package it into a box with the small computer and communicate via USB. Effectively, just port your existing app to Linux and go.

The term embedded system is extremely large and covers just about anything from the chip that controls your microwave to systems that give dynamic, road-side traffic information. Generally speaking, you have an embedded system if there is a computer chip in it that communicates with some purpose-built hardware.

There are roughly tow types of embedded systems, which I will term here as ‘small’ and ‘large’ systems.

In a ‘small’ embedded system, there is usually very little available in terms of resources (RAM/ROM/Flash) and it has no OS to speak of. Usually, all software running on such a device gets compiled into one big executable that also includes the OS kernel. These kernels only provide you with scheduling and task synchronization primitives.

In a ‘large’ embedded system, you are writing software to run under the control of a regular OS (often Linux, but not always). As a software developer, there is usually not much difference with writing software for a desktop environment, except in the tooling you use for compiling/deploying/debugging and that some of the heavier processes (like X windows) might not be available.

If this is the company’s first step in the embedded world, I would advise them to look as much as possible for stock hardware that fits their needs as best as possible and for which there already is an OS implementation available. Porting an OS to new hardware and writing device drivers are not the easiest of tasks, especially for people unfamiliar with embedded development.

The hardware designers need to pick the candidate hardware options that can do the job. Then the team should do a trade study to select the best option from those candidates for your specific product.

Some Software Specific Categories of that trade study are:

• OS Hardware Driver support
• Programmer Background
• Identification of “special” requirements that will impact OS/hardware selection. e.g. Do you need multithreading, scheduling, mutex’s, disk support etc.
• Do you already have code for a particular OS
• Any other factor that you can come up with that impacts your OS or language selection.

You don’t pick your OS first. You pick your hardware first, but that hardware selection has to consider software impacts. e.g. You don’t want to pick hardware that requires all custom driver code when an equivalent piece of hardware with a simple to use API is readily available.

As for what you should expect after that, it all depends on your selections from the trade study. If you are lucky enough to be able to use Windows Embedded compatible hardware with windows compatible drivers then your learning curve will be fairly small. It’ll be very similar to desktop development (at least until you begin integrating with the hardware devices, then some hardware knowledge may come into play).

If the intent is to build extremely low cost hardware then you may have to write code that tweaks individual bits in registers and be required to write all the interrupt handlers for the attached devices. If you don’t have a much of a hardware background then this would not be for your team. You can’t write reliable driver software if you don’t understand how the hardware needs to work.

I would say that if you have the full-blown windows embedded OS system then you may be able to do the job without hiring anyone. Linux would probably take someone with some experience, but if you have a little slack time you could try it on your own for a few weeks to determine if you think there’s a need. Any OS selection with less than either of the above will probably require someone with experience, even if it is to just get you going. If you pick a board package/OS that requires a custom Board Support Package then definitely find someone who has specific experience developing BSPs for that particular OS. That’s a very niche skill that can have huge impacts on the product when done wrong.