Development environment configuration
Compilation environment system
ubuntu-20.04.2.0-desktop
hardware:
Main control: Hi3536C;
FLASH: 16MB SPI Nor FLASH;
DDR: 512MB
The corresponding hardware is a 16-channel NVR board from a solution company that I bought before. I can’t easily program its uboot and kernel. I’m afraid I won’t be able to do it!!! There is no corresponding hardware information!
BSP version:
Hi3536C V100R001C02SPC040
Diary management
The log directory in the project directory.
First add the diary printing function to facilitate debugging. The glog library has been used in many projects before. It seems to be very easy to use and the functions used are relatively simple. Let’s use this library here.
Generally, the storage in embedded systems is very limited. We will not write files here first. We will then write a glog sink and add some diary file management strategies.
Add a separate directory to manage the operation log, and use a singleton instance class to manage this log function.
There is a relatively easy-to-use function in glog, which is to set the InstallFailureWriter. That is, when an error occurs or the program crashes, some simple stacks will be printed out. However, it cannot be printed out in many cases. Sometimes the program still has a core dump. Give some information to find program problems.
Assertions in code
In my previous development habits, I would add more assertions in places where the program logic and business are unlikely to appear, or where the occurrence would be an error. At the same time, I thought about typing the assertions into the diary, so I added an ASSERT. The macro definition just adds an assertion to the diary when a problem occurs.
See assertdef.h
Compilation and management of third-party library tools
The third-party library tools are all placed in the third_party directory of the project. I originally wanted to use buildroot to build the file system and third-party tool libraries, so I used my previous habit and simply placed them in a third_party and created a tarball directory in it. The source codes of all third-party libraries used in the project are placed here. At the same time, a directory is created for different chip solutions and corresponding compilation scripts are written. In the past, this was mainly done to compile all third-party libraries with one click. , the corresponding modified patches of the third-party libraries are also placed in it, so that when subsequent people come to maintain it, they will not understand how it was compiled and what patches they have applied.
Use of object singleton
For many types of objects and modules, they basically exist as singletons in applications, such as diary management, storage management, etc. If you use C++, it is basically abstracted into a class and a corresponding instance is created like this. , I would be more accustomed to building these objects into a singleton, so that when used in tasks, I only need to quote the header file of this class, declare the constructor and destructor of the class as private, and call the corresponding singleton get function of the class. That’s it! Such as the getInstance method in TLog.
This method of operation may be used in more places in the future. In the past, it was customary in the C language environment to create a Context upper and lower structure for the entire business and put all the object pointers in this context structure. This is also convenient. Centralized management, whether in C or C++, is very good. However, I feel that in embedded applications, many singletons are actually obtained directly using a getInstance method of the class, which is quite cool (provided that in the application, this class only creates this one instance, and the constructor and destructor are not allowed to be called by the user). ), it’s easier to write code this way!