[MUSIC] Welcome to this lesson about embedded system components. We first go through the processor families that are available and find out how these are presented. At the end of the lesson, you will know what the difference and similarities are and what criteria you can use selecting a solution. You will understand how the processor architecture influences the real-time behavior of a device. Embedded devices come in all sizes. On the one side, we notice very small mobile devices like an intelligent sensor running on batteries for as long as possible. It performs limited data handling and has limited communication possibilities. On the other side of the spectrum, there are line powered smart devices coming, where performance is needed for serious data handling, communication facilities, and sophisticated user interfaces. There is vast range of processors and combination of processors and I/O devices, answering different needs. You may already be familiar with terms like, embedded processor, microcontroller units or MCUs, digital signal processors or DSPs, field programmable gate arrays or FPGAs. Embedded processors will consume less than their business counterparts, and will also, of course, be less performant. Yet, they will be available for a longer period of time. Microcontroller units integrate a whole microprocessor system, including some I/O on a single chip. DSPs are specially designed for signal processing tasks. FPGAs allow for great flexibility and personalization of a hardware architecture. They are even hardware reconfigurable at all times. If it comes to large production devices, the bill of material or BoM, starts to be an important factor. Putting together all hardware components on the printed circuit boards may be too expensive. A special proprietary design of a system on a chip, or SoC, incorporating these elements may be indicated in case you do not find a ready-to-go microcontroller unit, or MCU, for the job. However, before getting there, you have to develop the architecture and the software and this should be performed on what we call a prototyping or development infrastructure. For this, development boards and/or an FPGA is very helpful. The characteristics to look at when choosing a processor are the processor's architecture, the operating temperature range, the cost per unit, and the performance related to the power consumption. Also, as we will see in next lessons, the availability of some peripherals, including software, can become an important selection factor. Processor families from vendors like Intel, ARM, Motorola, Atmel, Texas Instruments, and others, have different characteristics. The differences have an immediate impact on the compiler choice to produce the code. This becomes also an important selection factor. Interrupt handling may be different, influencing the software that has to be written. It also influences the setup of the operating system's device drivers. An important difference is in the way the processor is made available. Most vendors produce silicon. ARM is producing intellectual property, or IP, that other vendors or you yourself can use to produce a custom chip. It is possible, for example, to impact cost effectiveness by using an ARM processor inside an FPGA for prototyping reasons before deciding a custom built SoC. Licensing and as such, cost impact, is different in that case. The final performance will depend on the frequency used and the data which being 8 up to 64 bits. The frequency used to execute codes might be variable in order to reduce power consumption. Also, most processors have cache and pipelining to enhance average performance. Here we have some important issues regarding real-time behavior. The variable frequency and cache mechanisms introducing the notion of a variable performance engine. This is not advised for use if you have specific hard real-time requirements. In this case, accepting an automatic variation of frequency is not indicated. However, you can design an organized variation of frequency and so power consumption. Another issue pops up when one starts using multiple processors. An interesting point is that multiple processors use less power than a comparable solution with one processor. There are two solutions to use multiple processors. One is to go for a multicore architecture, which is a tightly coupled architecture that uses shared memory to communicate. The other is to have a loosely coupled architecture with multiple microprocessor systems, such as microcontrollers working together and communicating through one or another serial channel. Using a multicore architecture is very tempting, and provides an easy electronic solution. Yet, when it comes to real-time behavior, a hidden behavior problem may occur. Different cores that use a single parallel bus to access the central shared memory can create bus bottlenecks. This may occur on critical moments and cost you to miss deadlines. Silicon architects are trying to solve this problem by introducing Level 3 cache. But this introduces a previously discussed kind of unpredictability. A dual core architecture is acceptable and will not suffer too much from this behavior, because there is a sort of interleaving effect between the two cores. Using more cores should be done with care, especially when real-time requirements are essential. As you see, selecting a processor is not an easy task. A lot of considerations have to be taken into account, including the fact that after a couple of years, using a specific solution might necessitate bringing in another processor for cost reasons. The question is then, do I recover my software investment or not? Do I need to start the design from scratch again? These are questions we will answer as these lessons go along.
