"Time Analysis of Embedded Software" reading activities: 1 Chapter 1 Reading Notes - Basic Knowledge
[Copy link]
This post was last edited by hehung on 2024-6-25 08:49
Chapter 1 explains the basics, which every embedded software engineer should know. The sub-chapters are as follows:
1.1 Real-time systems
1.2 Phased software development model - V-Model
1.3 Compilation process: from model to executable file
- 1.3.1 Model-based software development and code generation
- 1.3.2 C precompiler
- 1.3.3 C compiler
- 1.3.4 Code optimization performed by the compiler
- 1.3.5 Assembler
- 1.3.6 Linker
- 1.3.7 Locator
- 1.3.8 Linker script
- 1.3.9 Debugger
1.4 Summary
1. Real-time systems
This is a very short chapter that explains the definition of a real-time system. In short, it is a system that can guarantee the time requirements and meet the time requirements under any circumstances.
2. V-Model
The V model is common in the automotive industry, and functional safety requirements must comply with V module development.
The V model is illustrated as follows. Projects generally have existing abstract requirements. According to the requirements, the design (architecture design, detailed design) is broken down, followed by code implementation and integration testing, followed by module testing (unit testing), and finally system-level testing.
3. Compilation process
This chapter is particularly important for embedded software developers, as they can learn some knowledge related to compilation principles.
The figure below shows the compilation and linking process. The C language code we usually write will eventually generate machine code and be executed by the machine. Programming machine code from C language code will go through the following processes: pre-compilation -> compilation -> assembly -> linking -> positioning. Each process has a separate tool to implement it, but the IDE we usually use helps us do these things and realizes one-click operation.
- Precompilation process: Precompilation will process all precompilation instructions, such as #define, #include, #if, #else, #endif... This process will replace all macros, read all files included in #include, and then delete unsatisfied code from the conditional variants;
- Compilation process: The precompiled output is transmitted to the compiler, which generates machine code (assembly code) for a specific processor. This process does not define storage addresses such as functions, defaults, and jump addresses, but only stores them in the form of symbols;
- Assembly process: The assembler converts the compiled program code into binary code, i.e. the target file. This process does not define functions, variables, or jump addresses;
- Linking process: The linker integrates the assembled target files into a program to be completed, but there is still no specific address. The linking process will also integrate some external reference library files, such as .a or .lib function library files. The linking process will also resolve all symbols used (such as functions), and search for symbols in all integrated objects. If the symbol is found, the reference to the symbol will be resolved. If it is not found in the integrated file, it will be searched in the included library file. If it is not found anywhere, it will be prompted "unresolved external <symbolname>"; if it is found in multiple target files, it will be prompted "redefinieiton of symbol <symbolname>";
- Positioning process: The locator is used to allocate the storage address for each symbol. The output file of the locator is an executable file (usually hex, s19, elf, etc.). In general development tools, the locator and linker are combined and collectively referred to as linkers. General tools can also create a map file, which contains a list of the storage locations of all symbols for programmers to view.
4. Linker Script
Chapter 1.3.8 explains the link script, but it is relatively basic. You cannot master the relevant knowledge of linking through this chapter. It can only be used as an introduction for beginners. The syntax of the link scripts of different compilers may not be the same, but the basic principles are similar.
The linker is usually used together with the locator to assign the compiled code to a specific execution location so that the code can run on the microcontroller. Interested friends can find the link documentation of GNU or other compilers to learn by themselves.
5. Debugger
The debugger is not part of the tool chain of the compilation system. Using the debugger helps developers quickly locate and solve problems.
Debuggers can generally read executable files (GNU generates elf, other compilers have different formats, but generally provide tools to convert to ELF format), load source code, and let the processor execute the code step by step, and display the location of each step in the program. In addition, developers can also see the contents of variables and registers.
The debugger usually accesses the debugging information in ELF, which is usually saved in DWARF format, which stores the source file and line number of each storage address.
To use the debugger well, you must also combine it with a specific compiler, and you need to learn more in the compiler's guide documentation. This chapter in this book is just an introductory explanation.
6. Conclusion
This chapter is basically an introductory explanation. All embedded developers should understand and be proficient in the debugger, because no programmer can guarantee that the code they develop is bug-free, so they need to use the debugger to locate and resolve these bugs.
|