임베디드 프로그래밍: 마이크로컨트롤러 애플리케이션을 위한 C 선택

### 임베디드 프로그래밍의 이해: 적합한 언어 및 기법 선택하기
* 💻 마이크로컨트롤러에 대한 논의에서는 마이크로컨트롤러의 내부 기능과 임베디드 시스템 프로그래밍을 위한 학습 플랫폼으로 **ARM SE**를 선택한 근거에 대해 살펴봤습니다.
* 🔧 ARM은 교육에 적합한 수단이지만, 학습한 개념은 **임베디드 프로그래밍 기술의 보편성**을 강조하면서 다양한 프로세서 제품군에 적용된다는 점에 유의해야 합니다.
* 📜 임베디드 시스템용 프로그래밍 언어의 경우 **하드웨어를 직접 제어할 수 있는 어셈블리 언어부터 C, C++, Rust와 같은 고급 언어까지 다양한 옵션**이 있으며, 각 언어마다 장단점이 있습니다.
* 📝 어셈블리 언어는 **명령어 집합 아키텍처(ISA)에 대한 심층적인 지식**이 필요하며 다른 마이크로 컨트롤러 간에 쉽게 이식할 수 없는 취약한 코드를 만들 수 있어 구조화된 프로그래밍에 적합하지 않습니다.
* 🔍 C와 C++와 같은 상위 수준 언어는 추상화가 잘 되어 있어 **메모리와 하드웨어를 더 쉽게 조작**할 수 있고, 구조화된 프로그래밍이 가능하므로 **코드 유지 관리와 가독성**이 향상됩니다.
* ⚙ 임베디드 C는 하드웨어에 근접하여 메모리에 직접 액세스하고 인터럽트 및 주변 장치를 효율적으로 처리할 수 있으며 **다양한 시스템에서 어느 정도의 이식성**을 제공하기 때문에 특히 선호되는 언어입니다.
* 📚 또한 **Rust 및 Go와 같은 언어는 메모리 안전 기능**을 갖춘 최신 대안을 제시하지만, 실시간 애플리케이션 요구 사항과 맞지 않을 수 있는 복잡성과 잠재적인 성능 절충점을 초래합니다.
* 🔄 궁극적으로 이 과정에 C를 선택한 이유는 **사용 편의성, 광범위한 커뮤니티 지원, 업계에서 여전히 관련성이 높은 방대한 코드베이스**가 실용적인 균형을 이루고 있어 학습자가 다양한 임베디드 시스템에서 기술을 효과적으로 적용할 수 있기 때문입니다.

임베디드 C 프로그래밍은 효율적인 마이크로 컨트롤러 애플리케이션 개발을 위한 제어, 이식성 및 커뮤니티 지원의 실질적인 균형을 제공합니다.

[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

IIT Madras - BS in Electronic Systems

임베디드 시스템 프로그래밍: 언어 선택

임베디드 시스템 프로그래밍은 직접 제어를 위한 어셈블리 언어, C 및 C++와 같은 고급 언어, LabVIEW 및 Blockly와 같은 시각적 프로그래밍 언어 등 다양한 접근 방식을 사용하여 수행할 수 있습니다.

어셈블리 언어는 명령어 코드를 직접 조작할 수 있지만 취약하고 특정 마이크로컨트롤러에 크게 의존하기 때문에 다른 프로세서로 전환하기가 어렵습니다.

이 과정은 제어와 추상화 사이의 균형을 잘 유지하여 다른 마이크로컨트롤러 제품군에 개념을 쉽게 적용할 수 있는 임베디드 C 프로그래밍에 초점을 맞출 것입니다.

구조화된 프로그래밍 및 고급 언어

구조화된 프로그래밍은 특정 분기 및 반복 조건이 있는 블록으로 코드를 구성하는 것을 포함합니다.

C, C++, Rust, Go와 같은 고수준 언어는 하드웨어 액세스와 메모리 관리를 위한 도구를 제공하여 일반적인 프로그래밍 문제를 해결합니다.

임베디드 프로그래밍은 임베디드 시스템의 특정 요구 사항을 해결하기 위해 직접 메모리 액세스 및 휘발성 변수 선언과 같은 고유한 패턴을 사용합니다.

C를 사용한 임베디드 프로그래밍

임베디드 코드에는 종종 직접 메모리 액세스 및 하드웨어 상호 작용을 나타내는 해시 정의와 휘발성 키워드가 사용됩니다.

메모리 주소와 레지스터의 비트 조작에 16진수 값을 사용하는 것은 입출력 포트를 구성하는 데 흔히 사용됩니다.

임베디드 시스템용 C 프로그래밍은 하드웨어에 근접하여 직접 메모리 액세스, 인터럽트 처리 및 주변 장치 상호 작용을 가능하게 하는 동시에 어느 정도의 이식성을 제공합니다.

임베디드 프로그래밍에서 C와 C++의 역할

C는 이식성과 레거시 코드 덕분에 메모리 위치를 쉽게 수정할 수 있어 임베디드 프로그래밍에 사용됩니다.

C++는 클래스를 도입하고 함수와 데이터를 캡슐화하며 비공개/공개 액세스 및 일반 프로그래밍과 같은 기능을 제공함으로써 C를 기반으로 구축됩니다.

Python이나 Arduino 같은 다른 언어도 임베디드 프로그래밍에 널리 사용되지만, 인터프리터가 필요하다는 등의 한계가 있습니다.

임베디드 시스템용 프로그래밍 언어

LabVIEW와 같은 시각적 프로그래밍은 프로그래머가 아닌 사람에게 유용하며 최적화된 코드 블록을 연결할 수 있지만 제어 기능이 제한적입니다.

Java는 JVM 오버헤드에도 불구하고 임베디드 시스템에서 널리 사용되고 있으며, Go는 가비지 컬렉션을 통해 단순성과 메모리 제어 기능을 제공합니다.

Rust는 메모리 안전 문제를 해결하고 고성능을 제공하는 미래 유망한 언어이지만 사용하기가 복잡하고 임베디드 코딩에서 일부 안전 기능을 희생해야 할 수 있습니다.

임베디드 프로그래밍에서 C의 중요성

C는 메모리 레지스터를 제어하고 어셈블리 언어로 직접 변환할 수 있어 프로그래밍을 위한 실용적인 선택입니다.

업계 표준과 새로운 언어 채택에 대한 거부감 덕분에 특히 안전이 중요한 시스템에서 C가 지속적인 인기를 누리고 있습니다.

C에 대한 풍부한 교육 자료와 커뮤니티 지원은 이 분야에서 C의 지배력을 더욱 공고히 합니다.