- \n
- Scrolling is very inconvenient<\/li>\n\n\n\n
- It\u2019s hard to find things we\u2019re interested in if we didn\u2019t strictly follow some order<\/li>\n\n\n\n
- \u2026and with order as well<\/li>\n<\/ul>\n\n\n\n
Think that, for example, Windows has around a million<\/strong> lines. I heard that a few years ago, so the newest ones probably already have a few million.<\/p>\n\n\n\n
How to live?!<\/strong><\/p>\n\n\n\n
Finally, you need to start splitting the program into smaller modules.<\/strong> These modules will be sets of files that we later include in the main program, or we connect them with each other.<\/p>\n\n\n\n
We may already know such modules from the standard library! All external libraries like, for example, string.h are exactly such separate sets of files. We call them libraries<\/strong>.<\/p>\n\n\n\n
When writing your own programs for microcontrollers, you\u2019ll also be writing such libraries for various purposes. Handling a sensor, handling a menu, some graphics. These will be individual modules.<\/strong><\/p>\n\n\n\n
Files in the C language<\/h2>\n\n\n\n
What files do we have in C? The most important ones and the ones that interest us are files with the extensions *.c and *.h.<\/strong><\/p>\n\n\n\n
H files<\/strong><\/p>\n\n\n\n
This is a header<\/strong>. This is where there will be only prototypes and declarations.<\/strong><\/p>\n\n\n\n
Such a file has no executable code. Or in other words\u2026 we don\u2019t want it to have any \ud83d\ude42<\/p>\n\n\n\n
In it we will write the so-called interface.<\/strong> This will be only what we can use when using this file, or more precisely, the library.<\/p>\n\n\n\n
Speaking plainly\u2026 Here you\u2019ll find things such as declarations of:<\/p>\n\n\n\n
- \n
- types<\/li>\n\n\n\n
- enums<\/li>\n\n\n\n
- structures<\/li>\n\n\n\n
- functions, i.e., only prototypes<\/li>\n\n\n\n
- global variables (if we want them ;))<\/li>\n<\/ul>\n\n\n\n
There will be no executable code here, i.e., function bodies.<\/strong><\/p>\n\n\n\n
A set of such declarations we will include into the second type of file<\/strong> (with the extension *.c). For example, into main.c.<\/p>\n\n\n\n
We need to use the preprocessor for this purpose.<\/p>\n\n\n\n
#include \u201cfile.h\u201d<\/strong><\/p>\n\n\n\n
#include <file.h><\/strong><\/p>\n\n\n\n
With angle brackets <file.h> you indicate a file from the compiler\u2019s default path.<\/p>\n\n\n\n
With quotation marks you specify a file from the project path.<\/p>\n\n\n\n
C files<\/strong><\/p>\n\n\n\n
Files with the extension *.c are source files<\/strong>. In short, sources<\/strong>.<\/p>\n\n\n\n
This is the place for the actual code<\/strong>. Here we write function bodies.<\/p>\n\n\n\n
Into this file we also include other headers like, for example, the main header main.h or stdio.h.<\/p>\n\n\n\n
This file must know the definitions <\/strong>of the types it works on, as well as other headers that will be required to compile this file.<\/p>\n\n\n\n
Apart from functions, we can place global variables here. They will be able to be visible globally, i.e., throughout the entire project. Only\u2026 this will be rare and truly a last resort <\/strong>. In good practice we rather avoid global variables. I\u2019ll talk more about that someday.<\/p>\n\n\n\n
If not global, then what? Globals with a limited scope<\/strong> to this specific file. This is a much better and more common practice.<\/p>\n\n\n\n
I guess I\u2019ll have to talk about those globals earlier. Let me know if I should do that in the next emails.<\/p>\n\n\n\n
Minimum for the compiler<\/h2>\n\n\n\n
This may seem surprising, but you need to know that the compiler <\/strong>to compile a file needs only definitions.<\/strong><\/p>\n\n\n\n
It doesn\u2019t need to have a specific variable allocated in memory.<\/p>\n\n\n\n
It also doesn\u2019t need a function body! It\u2019s enough for it to have just the prototype.<\/strong><\/p>\n\n\n\n
You might ask how is that possible?! Keyword: at the compilation stage.<\/strong><\/p>\n\n\n\n
This is quite funny, but compilation <\/strong>as a whole process from A to Z is divided into several stages.<\/strong> The most important ones are:<\/p>\n\n\n\n
- \n
- Preprocessor<\/li>\n\n\n\n
- Compilation<\/li>\n\n\n\n
- Linking<\/li>\n<\/ol>\n\n\n\n
Yes! Compilation is part of compilation! Great, right? \ud83d\ude42<\/p>\n\n\n\n
And it is exactly for step no. 2 that only knowledge of prototypes is needed. Why?<\/p>\n\n\n\n
Because this stage compiles ONLY one <\/strong>C file at a time. From one file it creates one so-called object file. Such modules<\/strong> are created. This is a single compilation unit<\/strong>.<\/p>\n\n\n\n
In it (in that object file) there is (speaking in a huge simplification) information that we want to use variable X in some place or function Y with arguments Z and W in such a place in the program.<\/p>\n\n\n\n
Compilation creates <\/strong>therefore (again in a huge simplification) a map of relationships<\/strong> of what, when, how, and with what operations to do. Bare assembly without ties to addresses<\/strong> in memory.<\/p>\n\n\n\n
It doesn\u2019t have to know the function, but it knows that it has to be called. Now who ties<\/strong> this information together? The LINKER <\/strong>at the linking stage.<\/strong><\/p>\n\n\n\n
The linker at input collects all object files<\/strong> after compilation and creates a whole from them.<\/strong> It resolves these relationships of variables and functions between modules and assigns them specific locations in memory, e.g., of the microcontroller.<\/p>\n\n\n\n
It sees, for example, that Module1 wanted to call a function located in Module2. So it links the call with the function located in ANOTHER compilation unit.<\/strong><\/p>\n\n\n\n
This will be important to understand the essence of how it works. Because what does such a prototype tell the compiler?<\/p>\n\n\n\n
\u201cI have such a function and I want to use it. I don\u2019t have the body \u2013 the linker will resolve it.\u201d<\/em><\/p>\n\n\n\n
The compiler will set up the instructions, arguments on the <\/em>stack, the return from the function, and that\u2019s it. Now the linker has to connect these operations with the appropriate function in another compilation unit.<\/p>\n\n\n\n
And here we arrive at the fact that both the compiler and the linker will report different problems.<\/strong><\/p>\n\n\n\n
The compiler <\/strong>will most often tell you that it doesn\u2019t know the name of a variable or a function when they are used.<\/strong> This means that it has never seen<\/strong> the function prototype or the variable definition before. You need to inform it only about the existence (name and types).<\/strong> The function body or memory reservation for a variable may be in another compilation unit. That doesn\u2019t interest it.<\/p>\n\n\n\n
What does the linker<\/strong> most often report? That it can\u2019t resolve a reference.<\/strong> Such a situation will occur if in one compilation unit we inform with a prototype about the existence of a function whose\u2026 body won\u2019t exist anywhere else<\/strong> (in other compilation units). The linker didn\u2019t resolve the reference and returned an error.<\/p>\n\n\n\n
These are two completely different<\/strong> messages and you have to approach them differently.<\/p>\n\n\n\n
Summary<\/h2>\n\n\n\n
I got a bit carried away, and I still feel I haven\u2019t said everything\u2026 Let me know if you\u2019d like something in a longer and more expanded form.<\/p>\n\n\n\n
We didn\u2019t do, for example, a practice session\u2014i.e., how it should actually look, e.g., in an online compiler. In text form it may be hard to carry out. Maybe you\u2019d prefer learning in video form? In that case, I have a certain proposal \ud83d\ude42<\/p>\n\n\n\n
Do you want to learn the C language with microcontrollers in mind?<\/h2>\n\n\n\n
I created a course dedicated to microcontrollers (the course is conducted in Polish). I teach C from the basics there. Everything I discussed in this post (and much, much more) is included in the course curriculum.<\/strong><\/p>\n\n\n\n
![\"\"](\"https:\/\/msalamon.pl\/wp-content\/uploads\/2021\/10\/Kurs-C-dla-embedded-logo-500px.jpg\")
<\/a><\/figure>\n\n\n\nI\u2019ve gathered my experience from several years of embedded programming<\/strong> and I want to pass on the best knowledge possible. I participated in various projects: on my own, a start-up, a medium-sized company, and a huge corporation.<\/p>\n\n\n\n
Apart from the basics and syntax, I share a ton of good practices.<\/strong> I weave this in between explaining subsequent aspects of the C language.<\/p>\n\n\n\n
An additional advantage is also that I show how to manage a project well.<\/strong> I\u2019ll show you how to deal with building abstraction layers. We\u2019ll use structures, pointers, and callbacks.<\/strong> And of course splitting into files. It helps a lot.<\/p>\n\n\n\n
Such separated layers are much easier to \u043f\u0435\u0440\u0435\u043d\u043e\u0441 between projects, and even between different families of microcontrollers.<\/p>\n\n\n\n
Join the waiting list for the course and start learning together with the materials I\u2019ve prepared. After signing up, you will receive weekly emails about the C language (the newsletter is conducted in Polish): https:\/\/cdlamikrokontrolerow.pl<\/a><\/strong> <\/strong><\/p>\n\n\n