[Music] [Music] Okay, so far we have talked about the internal aspects of microcontrollers, and you know what kind of functionality they are capable of giving you. And to some extent, touched upon the choice of maybe how would I choose between different families, and also sort of to the decision that yes, ARM SE seems reasonable enough that we can learn how to program embedded systems using ARM. And hopefully, those learnings should apply to other processors as well, right? And that is an important thing I want to stress upon. This is not meant to say that ARM is the only family that we are, that is worth using, or that we are going to use. It is more meant as a vehicle for teaching some concepts of embedded programming, which hopefully will, you know, hold you in good stead for any other family as well. Now, one other aspect that needs to be chosen over here is how do I program these systems, right? What kind of programming language should I use in order to program an embedded system? Now, there are multiple different approaches to programming Assembly.

Language affords the most direct control of the system. It allows you to directly get to the uh as close to the hardware as possible and control every aspect of what the microcontroller can do. There are various high-level languages, C and C++ being the most common. There is also a language called Rust that I will briefly touch upon later. Apart from that, there are what are called visual programming languages. Some of you may have already seen things like LabVIEW from National Instruments, or there is something called Blockly that can be used in order to basically create a block-based programming environment. And there are other beginner-friendly languages like the Processing IDE, which is more or less what Arduino is built on, which sort of abstracts a lot or looks similar to C or Java or C/C++/Java but is sufficiently abstract, you know, abstracts away most of the uh details and makes it easier for a beginner to get useful work done. Now let's look at each of these in a little bit more detail to understand why we are finally looking at embedded C.

programming for this course right. Assembly Language is pretty much direct manipulation of the instruction code. You are literally going in there and writing the Assembly Language instructions. The problem is it requires detailed knowledge of your ISA. Now why is that a problem? Because it's fragile. It is very strongly dependent on the specific microcontroller that you choose. If you have programmed at the Assembly Language level and let's say at some point you need to even consider a choice between moving from ARM to ESP32, it's flat out not possible, right? Because you'll have to rewrite your code from scratch. It would be like designing a completely new system and it's just not going to be worth the effort unless there is a very specific reason why you had to do things only in Assembly Language. The effort involved will be very, very significant. Assembly Language also makes certain, you know what we call structured programming, difficult to do. Structured programming, as you may recall, basically looks at how I can introduce structure into the programs that I write. What that means is can I use functions in

order to encapsulate commonly called routines of operations. Can I sort of bring all my branching conditions into either a specific kind of an if, which is a branching in a flowchart, or into loops, right? For loops, while loops, and so on, which have a very specific kind of repetitive nature, right? So, the ability to sort of break programs down into terms of blocks that can then be composed into larger programs is essentially one of the key aspects of what we call structured programming. It is possible to do some kind of structured-like programming in Assembly Language, but it doesn't make it easy, right? So, it's definitely not sort of meant for something like that, which is why people usually look at higher-level languages, right? Which give us access to functions, iterator iterations, and various kinds of data types and data structures that we can use to make our programming life easier. Now, high-level languages, right? C and C++ are the ones that are sort of most popular. They are close to the hardware, as we will be seeing throughout.

this course. What I mean by close to the hardware is that it's actually possible to write code which directly allows us to manipulate individual registers, bits, memory locations, and so on. Right? There are other languages. Rust, that I mentioned earlier, is possible. There is a variant of another language called Go (GoLang), which is a Google-based language, but which has variants that can be used for embedded systems. There is also something called MicroPython, right, where it's a variant of Python that allows, that actually runs with fairly limited memory requirements and could be used in the context of programming certain kinds of systems, right? These are relatively new languages in the embedded space and solve many of the memory safety problems. Memory-related problems are one of the biggest sort of, you know, trouble points as far as C programming is concerned, right? Already from the C programming course, you have probably seen the whole notion of the segmentation fault and, you know, how you can easily end up accessing data outside of the memory of your process and how that can cause your entire process to crash.

right. These languages try and solve many of those things at the language level itself and prevent you from, you know, running into some issues at runtime. Okay, so there are obviously trade-offs, right? In order to do that, you either have to make the programming and debugging a bit more complicated, right? Although arguably it's a good thing if it avoids bugs at runtime, right? Or they provide certain other kinds of runtime memory management, which can be overhead, which actually slows down your system in other ways. Okay, so those are some aspects of high-level language. Now, what exactly do we mean by embedded programming, right? There are a number of patterns that are used in embedded programming. And by pattern, what I mean is a common repeated way of writing certain kinds of code, which you will encounter in embedded programming, which are very rare or unlikely to happen in regular code, right? These include things that require direct access to registers or memory, things like volatile variable declaration, which you will almost never see in a regular program, right? A lot of interrupt-related code, right? So what I

have on this screen are a couple of different snippets of what a portion of embedded code could look like, right? And as you can see, there are a whole bunch of hash defines out here. And if you look at the hash defines, there are many things out here that don't look very appealing, right? There is this keyword volatile, which you would probably never have come across in a regular C program. The U in 32t is probably the easiest thing to work with, right? All that it's saying is, Okay, this is an unsigned 32-bit integer. Good so far, so good. But then we are directly actually giving it a hexadecimal 32-bit value, which presumably is the address of some location somewhere, either of memory or of a peripheral that's attached to this system, right? And not only that, what we are going to do is the way that we configure an IO port, an input-output port on the microcontroller, would actually be things like this. We would take this port F data, the direction register, and we would or a certain value.

into it right or 04, which basically means we are setting a particular bit somewhere in the middle of that register, right? It's a 32-bit register, but I want to set one of the bits to one to indicate that it is being enabled as an output signal, right? Then I have to enable it explicitly by writing that same, uh, by writing a similar value into another register or another address. And then finally, I can actually change the data on it or, you know, toggle the pin so that it goes high, right? So all of this, this is a pattern that is very common in embedded programming. It is something where you are directly trying to access an external memory location and make some changes to it, which is very rare in a regular C program or, in fact, unlikely that you would ever come across it, right? In some sense, what we are doing over here is literally taking things that would be written in Assembly Language but then modifying them so that they are working at the C programming level, right? Another piece of code would be where you

would have something like an interrupt handler. It's either a timer or an interrupt handler. Every time that this function gets called, you need to go in there, you need to reset some values, you need to change the value of an output port, perhaps maybe turn a LED on or off depending on the timer, right? All of these would be done directly by accessing certain memory locations and changing their values. So, these are patterns of code that you would find commonly in embedded programming that you would not normally see in a higher-level language, right? So, C for embedded systems, really the power comes from the fact that it has this proximity to the hardware. It allows you to go very close to the hardware. It allows you to directly access memory locations, right? It also allows you to very easily write code for handling interrupts, timers, interacting with peripherals, and so on, okay? The most important thing is it allows a certain degree of portability, right? As you can see from this code over here, as long as I, if I, let's say, want to switch from an ARM to

an ESP processor. As long as I can now change things around and say, okay, the GPIOs on the ESP correspond to a different set of memory locations. I just need to have one place where I change my hash defines, and the actual logic remains exactly the same as before, right? So, this portability is the key aspect of why we go to a higher-level language instead of directly writing things in assembly. Of course, there is also another reason for using C, which is just legacy, right? I mean, there is a large amount of old code that has been written in C, which is surviving to this day, and people still use it and update it, which means that you probably need to understand embedded C in order to make changes to any of that code, right? Now, C++, as I said, we will only be treating it as a kind of way of abstracting and generalizing the ideas of C, right? What we will do, what C++ allows you to do, is to encapsulate common functions into a notion of a class. This is very similar to the idea

of a struct in C, right? But a struct in C is used in order to encapsulate or collect data that are related to each other into a single structure. If I can also have functions associated with those data, then at a very primitive level, this has now become a class, right? C++ of course does more than that. It's not just a question of associating functions with inside a struct. It allows you to do things like declaring what are private versus public functions, encapsulating them, preventing unnecessary access, and thereby eliminating certain classes of bugs if possible, right? It also allows you to do what's called generic programming by having templates that allow you to handle, you know, 16-bit numbers, 32-bit numbers, floating-point numbers, all of those using a single sort of code base, right? For our purposes, we'll be using a very limited form of object-oriented programming, mostly in the case where we will be calling library functions that already exist or looking at existing functions and seeing how to add basic functionality to them rather than coming

up with completely new classes on our own. That is, of course, you know, coming up with the classes of how to use embedded systems is important by itself but is not going to be the main focus of what we'll be looking at in this course. So, for those of you who are not comfortable with C++, the amount of C++ that we will be using in the course will be fairly limited, and we'll be looking at those aspects as and when we get to them. Now, at a very high level, right, um, there are other languages that can be used. Like I said, processing and Arduino are very popular, especially among the hobby type of applications. Python has a very interesting, uh, you know, background over here because it's useful in many other contexts. It's used for system-level scripting, for data science these days, and if we can also use it for embedded programming, that sounds like a great idea. But there are limitations, one of the biggest being that you need some kind of an interpreter, and the overhead of having that interpreter can be a

problem, especially for resource-constrained systems. What about visual programming, LabVIEW from National Instruments is a very good example of this. Once again, we will not be getting into any details on this. They are useful for non-programmers, well, or at least semi-programmers, but people who don't want to get into the details of how to write C code, probably. They do impose certain kinds of limitations in the amount of control that you get over the code, but having said that, you can build fairly powerful structures using these visual programming environments as well, right? They are primarily useful when you already have blocks of code that have been developed and optimized and need to be sort of chained together into a sequence of activities, one after the other. There are the more traditional languages. Java has its place in embedded systems programming. One of the issues with it, of course, is that it typically requires the JVM, the Java Virtual Machine, and the corresponding bytecode, which has overhead associated with it. But it has a large installed user base.

meaning that there are a large number of people who know how to write Java, and it's a well-known language, so it has found its applications in the context of embedded systems as well. Go, like I said, Go from Google is another language that has its biggest selling point: it's very easy to pick up, it's a very simple language in some ways, right. It also provides a good degree of control because it has a notion of pointers and so on and can be used in order to directly access memory locations if needed. But memory management is a bit more tightly controlled. They use something called garbage collection, which means that there is actually some process running in the background managing your memory for you, which could potentially interfere with real-time applications, especially Rust. Rust sort of deserves a special mention over here primarily because it looks very promising for the future. One of the biggest things it does is it addresses many of the memory safety features associated with C and C++, right. And there are things about the Rust language which mean that almost by

construction. If you have written a piece of code in Rust, then you can be fairly sure that certain classes of memory-related bugs cannot even exist in that code. Having said that, and you can also get extremely high performance. You can get to the same level of performance as C code. Having said that, it is more complicated to write code in Rust, and there are certain sort of drawbacks potentially that come, and there are scenarios, especially in embedded coding, where you have to give up on some of the embedded safety features or rather language safety features and use effectively unsafe aspects of the code, which sort of negates its main selling point, right? But it is sort of emerging as a very strong challenger to C and C++ in some contexts, at least, right? So, it's something to keep an eye on, but definitely not something that we'll be looking at further in this course. So, to summarize why the C programming language, it's a good trade-off between practicality and ease of use, right? It has a large installed code base, very well tested. It also gives

you have very good control over how to access memory registers, and you can pretty much look at the C code and see how it translates into Assembly Language directly, right? It's practical, as I said, and part of the reason for this is there are good industry standards that have been developed over the years that give, you know, good foundations on how to write code that is well-structured, safe, and is going to give you very good performance as well, right? And part of the reason there is just inertia, right? People are, especially people dealing with safety-critical systems, are very reluctant to try new languages. So, even if a language sort of picks up popularity in one domain, it'll be many years before it really takes off in another domain. And the final reason why, you know, going with C is that the sheer volume of training material that's available in C is much larger than in pretty much any other language at this point, which means that Community Support, getting access to other resources online especially, will probably be much easier in C than in most other languages at this stage. So,

these are the reasons why we have chosen C. But as I said, one of the things that you need to keep in mind as we go through this course is the focus of this course is not to try and train you in one particular processor or an architecture. What it is doing is to try and keep the abstraction level at the point where you understand the concepts that are involved in embedded programming, and hopefully, you should be able to translate them into any other embedded system or any other processor or ISA that you encounter as required.

Language Choices

Language Choices

Scripts