[Music] [Music] Okay, now that we have seen what an embedded system roughly can be defined as, one of the most important aspects that most embedded systems that we are going to be dealing with at least are concerned is a microcontroller, right? It is possible to have an embedded system that does not really have a computing unit within it, right? It might be a completely analog system that senses data and responds to it using some kind of hardware control, and yes, technically, that is also an embedded system. However, that's not the definition we are primarily using here. We are looking at embedded computing systems where there is some kind of a microprocessor or a microcontroller that is involved in actually controlling it. So, what are these two, and what's the difference between them? Let's look into that. So, this is a picture of a general-purpose computer, the architecture of a general-purpose computer, right? Now, we have already looked at the context in the context of how a C program runs. We know that we can sort of think of a

processor as having, you know, certain core functionality, which we usually call the central processing unit, within which there are some amount of control, an arithmetic and logic unit, and a set of registers. These elements put together allow us to have what's called a programmable system, and by combining that with outside memory, right, we can actually expand the behavior of this programmable system and have it do many things that just a basic ALU by itself could not, right? So, in other words, we can store a state of the system inside the registers. Based on that, we can perform certain computations. We can also interact with the outside memory, and combining all of these with, and by using a suitable control unit, we can get behavior which is, in some sense, any such processing unit, in principle at least, can replicate the behavior of any other such processing unit. All right, now you might also notice that there are a couple of other elements in this picture. Of course, the main memory is probably the most important thing that is required to expand the functionality of the CPU code.

the CPU, being the central processing unit, we might also have some kind of secondary memory, which is usually storage, right? Uh, the main difference between main memory and secondary memory usually relates to just the speed, right? I can store things in main memory fast enough that I can actually retrieve them for my regular computations, but secondary memory is considered something that is much larger in capacity but maybe slower in terms of how fast I can retrieve data from it. Now, that's as far as the memory aspect of the entire system is concerned, but you also have these two things on the sides: the input devices and the output devices. And if you look carefully at it, and as we discussed during the C programming course, in some sense, all of these, even the input and output devices, as far as the CPU are concerned, just look like things that you want to talk to, right? You ask for something by giving out an address, and you get back a response saying, Okay, this is what this address responded with. Now, if that address responded with whatever data was stored over there, then it's a memory.

block if that address responded with, let's say, what key was pressed or where the mouse cursor is. It's an input device. If that address accepts data from you and maybe displays it on a screen or prints it out onto a piece of paper, it's an output device, right? So, all of these things, this abstraction out here, allows us to sort of treat the core of the processor, the central processing unit, and the rest of the outside world in a very clean sort of abstraction. Now, having said that, clearly, there are two terms that we are interested in. One of them is the microprocessor, and the other is the microcontroller. And what we are trying to do here is to understand the differences between the two, in general, at least in the context of this course. A microprocessor is taken to be the core processing unit that provides the computational power to the system, right? And usually, what we assume is that a microprocessor will require additional supporting circuitry to handle things like input, output, or to talk to peripherals, or even to talk to

memory in general, right? On the other hand, a microcontroller very often integrates a lot of these things into a single device. There will usually be a central processing unit, some amount of memory, possibly even IO peripherals, all on the same chip, right? And very often what we'll also find is that these are usually designed for specific applications. So, if you think about this definition, one thing that you might notice over here is it looks as though a microcontroller actually contains a microprocessor in some sense, right? So, after all, there is the core processing unit for the microprocessor. A microcontroller also has the central processing unit, but it also has more to it. So, is it that a microcontroller is better than a microprocessor? Not exactly, right? The whole point over here is that in the process of sort of integrating multiple things onto a single chip, you also have to, in some sense, compromise on what the CPU can do, which means that the amount of computational power that you might have associated with a given chip over there might come down. Now, this integration, right, the fact

that you can integrate multiple different things onto a single chip is a key aspect of what has made microcontrollers possible and useful, right? In particular, the kind of things that people try to integrate are various kinds of on-chip memory, right? So, we have the RAM, which is the usual working memory of the system. We basically use it in order to store our variables, create temporary arrays, do all our computation, and so on. But there is also the ROM, the read-on memory, where things like the configuration data, so what happens when you actually start the system, switch it on from scratch, right? There's nothing in the RAM. What do I do with it? Well, the ROM is something that is read-only, so it has already been pre-programmed with some information. So, RAM and ROM by themselves are usually sufficient to build up a system, but of course, there are variants. In particular, ROM has many different kinds of variants, especially these days. They used to something called the EOM, the electrically erasable programmable read-on memory. Uh, when I say there used to be

there still is. It's not as popular these days because Flash has mostly sort of replaced the requirement for eom, right? Uh, you can, it is essentially what is called non-volatile memory. It allows you to store information over there, and even after you switch off the power to the system, that information remains stored over there. That's very powerful. It basically allows you to even change the functionality of the device and have it programmed into the system at some point. Now, that's as far as the memory is concerned. There are also a whole bunch of different kinds of peripherals that are useful for various kinds of especially small tasks, right? There are various kinds of digital and analog input-output devices. Uh, there are timers that allow you to perform operations at a specific interval. There is the U, which is the universal asynchronous receiver transmitter, which we will be also looking at a lot more, uh, in terms of the examples that we see later, and other communication protocols like SPI, I2C, CAN, Modbus, and so on, right? Uh, more

complicated networking protocols like Wi-Fi or Bluetooth, right, or ethernet if you're actually talking about wired connectivity, or even higher bandwidth interfaces such as camera interfaces, right, MPP, and various other kinds of things are also there. All of these could potentially be integrated into the chip by itself. Effectively, what we are creating is something called a system on chip. The entire system that would normally have taken a complete motherboard with all of these different chips performing different functionality these days can be integrated down onto a single chip, right? And that system on chip, the fact that such a thing exists and can be used, enables a lot of features that would otherwise not have been possible. Now, why do we do this, right? Why do we go about doing this integration and trying to create systems on chip? Of course, it sounds like a good idea. I mean, it's not clear why I should even have to answer that, right? But there are actually very specific reasons why people want to go with that, right? It turns out that when you are actually building a large

system the number of different discrete components that you have adds to what's called the bill of materials, right? And it basically means that these are different components that you need to keep in stock in inventory. If you can replace 10 different parts or 10 different chips with a single chip that has the functionality of all of those, you are minimizing the number of extra components, which makes your inventory control a lot easier. But that's one part of it, which actually has a very serious impact on the economics of design of such systems, right? It's not to be underplayed; it actually does matter when you are building large and complicated systems. But on top of that, it turns out that as you integrate, what is happening is these different components are actually coming physically closer together, and they don't have to sort of send electrical signals over large distances or over large wires. When I say large distances, I'm talking about in the context of semiconductors and microchips, right? Where literally anything over a few microns is a large distance.

right, and it turns out that instead of having centimeters of wires on a board, if I can convert that into micrometers of wires inside a chip, the amount of power that I need in order to switch those signals or capacitances is significantly reduced, which has a direct impact on battery life. If you're working on, if you're trying to design something that needs to run off a battery. On top of this, the fact you know these aspects of MCU design also allows us to have direct control of various kinds of physical systems. We can use general-purpose I/O and also various kinds of bus interfaces to attach sensors and actuators. Nowadays, there are many microcontrollers that also come with communication primitives built into them: USB, Bluetooth, all of Wi-Fi, all of those are actually baked into a number of different microcontrollers. The bottom line why they really become useful is cost-effectiveness, right? The fact that you are able to integrate all of these brings down the number of components it

brings down the number of things that you need to choose. A single chip can now be mass-produced, which again works in the economic favor of this kind of approach and brings down the cost of individual units. Overall, all of these things are contributing to bringing down the cost required to design, build, maintain, and upgrade such systems. Okay, now like I said, there are microprocessors and there are microcontrollers. If microcontrollers have all of these good features, what's the drawback and why do we even want a microprocessor in the first place? Remember what I said about a trade-off, right? I mean, the moment you are trying to integrate more peripherals or more work onto a single chip, it means you have to sacrifice some of the area on that chip for those peripherals, and you cannot use them purely for computation, right? The net result is that especially in areas where computing and data processing are the key requirement, you still want microprocessors. You can't really get away without them, even in the context of smartphones, right? Whenever you need to perform complex computations

let's say that you're trying to do some kind of video processing or that you want to do some kind of data analysis, right, which may not even have code that has been previously written. All of those have to be processed by something that is capable of just performing computations extremely fast, and such a system benefits from outsourcing things like memory management and peripheral management. You don't want that on the same chip because, at this point, your primary requirement is how fast can my system run, right? And if that is the case, then you are actually better off focusing your processor just on computation alone. So, what happens with such a system is typically you can then expand that microprocessor to be able to access larger memory storage, right, and also make it more flexible and expandable. Different kinds of memory connectivity are possible because all of that has sort of been outsourced to a different chip, which handles the memory interface. Similarly, by having another chip handle the entire communication protocol and just having a sort of standardized bus that this processor

uses to communicate with the outside world. You can make the system expandable with other kinds of USB, PCI, and so on peripherals, right? And in general, what you're aiming for is how do I increase the amount of processing power that I have in my system right now. Keep in mind that what is effectively happening over there is the reason why we had to do this was we did not want to sacrifice any of the Silicon area on the chip to the various other kinds of things that make microcontrollers useful. So what do microcontrollers do? They are usually used in places like appliances, consumer electronics, and so on, where you have limited functionality, you know, the same kinds of things that you have been discussing earlier, but primarily, right, the main driving Factor over there is cost Effectiveness, right? So if it turns out that it actually makes sense to design a microcontroller for a specific kind of functionality, that's what you would do. And if on top of that, it turns out that you really don't need to have USB expandability, let's say that you are

designing a microwave oven, and you never expect to plug in a USB mass storage device into it. Why even bother to have USB functionality, right? You can strip all of that out and have something which, at its very core, is just a very efficient microcontroller that draws a minimal amount of standby power and just does the task that is expected of it. So, the bottom line over here is each of these microprocessors and microcontrollers have their respective domains where it makes sense to use one or the other. We are going to be looking more and more at applications where microcontrollers make sense and then looking at, you know, how do you program them to do the right kind of thing. So, the bottom line once again is, you know, these are all the dividing lines over here are blurred, right? Embedded systems on the one hand typically started out as having very limited functionality, but increasingly you find that there is a requirement for increasing the flexibility of such things, right? Even though I said that you probably don't have a USB interface on a microwave oven, I think it's just a

matter of time before somebody decides that it's actually a good idea to maybe attach a camera to a microwave oven. Why? I don't know, but there are things that you can already see with regard to, for example, washing machines that have Wi-Fi built into them, refrigerators that have touch screens built on them, and will show you whether you have run out of a particular item, run out of milk, for example, right? So, at that point, you have to really ask the question: is this still an embedded system, or is it a general-purpose platform? Because I could potentially even run an operating system or download an app onto that refrigerator and run it on the touch screen that I have there. On the other hand, microprocessors are going in the opposite direction. People are increasingly saying, Okay, I know that I want a significant amount of compute, but there is silicon area. Why not also integrate the peripheral interfaces onto the same thing? This is pretty much what made the Apple M series of processors extremely powerful or a significant

Game changer in some sense, right? Although people had already been doing this in the context of smartphones for a while, this was the first time that something like this was taken into the domain of a laptop and became a general-purpose processor. But it is actually an SoC, a system on chip. It has a large amount of compute and peripheral interactivity all combined onto the same chip. Smartphones actually are a perfect blend in some sense, right? They are sort of exactly on the borderline between both of these, and that they are the ones responsible primarily for blurring these differences. And what we have is the expandability of downloadable apps, potentially even high-performance computation at the same time, fixed functionality like phones, emergency services, communication, and so on, right? So, the distinction between the embedded and general-purpose devices is blurred at best, and it's probably not really worth spending too much time trying to very clearly define and say, Okay, is this an embedded system or is it a general-purpose system? What matters is what are you trying to achieve with it.

If the functionality requires specific kinds of fixed functionality or resource optimization, what are the kinds of tricks that you can use in order to improve upon that? That's the more important part rather than what it's called.

Microcontollers vs Mircoprocessor

Scripts