Embedded Systems: Part 1
Embedded Systems are everywhere. From your TV remote to the Cars that you drive, the lift that takes you up and down, the phones and other gadgets that are your part of life, the invisible router that provides connectivity to your homes and offices , Embedded Systems is deciding how we interact with our surroundings. In this article ( first part of a five series write-up ) I will attempt to explain how to go about designing an embedded system.
The design process can be concisely broken down into the following components:
Unlike many pure software projects , Embedded Systems does not typically follow an agile development method mostly because hardware, once manufactured , is expensive to change. If you make an error at any stage it costs 10x more than the previous phase of design so it is very important to follow a waterfall mode of development and freeze requirements at each stage before subsequent stages.
Each phase is important and it typically requires people with different skill-sets to produce a device worth using.
One of the major questions you have to answer while doing component selection is whether to use a micro-controller or micro-processor for your product. One easy way of deciding is asking the following questions:
If the answer to a majority of questions above is a "NO" then you use a micro-controller else a micro-processor.
Another major question to answer is the selection of an Operating System [ for micro-processor ] or Real Time Operating System [ for micro-controller ]. This is more involved than the above and requires expertise. This is also dependent on the teams skill and confidence on a particular flavour.
The following are the major choices:
Once you have made the call on the processor type and OS type next phase is to set up a development environment for firmware. More on that in the next article.
These are my personal views and any feedback is appreciated to my gmail ID.