ESP32 is based on the core of an Xtensa instruction set architecture. Although not many people know about this IP core, many people may not be unfamiliar with the famous HIFI series DSP in the audio field. In fact, the HIFI series and ESP32 are based on The LX6 core uses the same instruction set architecture (ISA).ISA architecture. The ISA definition of the xtensa architecture is rather obscure, and it uses the concept of a register window that is more difficult to understand, that is, an abstraction is made between the EABI register used for assembly instructions and the physical register implemented on the microarchitecture, in order to save caller/ The cost of stack save/restore between callees. In order to prevent the new register window from overwriting the old one, the windowoverflow exception mechanism is designed. The whole logic is very complicated to understand. According to the xtensa dsp ISA manual obtained by google, it is recommended that users do not compile by hand, but use the FreeRTOS ported version provided by cadence or their own xrtos system. Although esp-idf is based on the bare metal and rtos version, after careful analysis, we found it The arch porting layer implementation is completely based on the compilation layer implementation provided by cadence.
Xiongda’s rt-thread supports the ESP-IDF framework. Let’s take a look at how it does it. Isn’t it a manual assembly? Download the code with questions:
Download code:
Find the rtthread-esp-idf project on Xiongda ’s github personal homepage , and download the code according to the project readme:
analysis:
First look for a breakthrough in analysis, because each RTOS needs to provide a tick interrupt function, and I know very well that the tick function of rtt is called "rt_tick_increase", so the top-level directory executes "grep rt_tick_increase -nR" to see where it is called. You can find clues to the implementation of the xtensa architecture layer.
The first file found./esp-idf-port/stubs/libcpu.c 264 line is the place to call it, open it:
xTaskIncrementTick is the implementation of tick interrupt on FreeRTOS, so it looks like it puts a FreeRTOS vest on RTT.
After browsing the libcpu.c implementation, I found that it almost implements all the FreeRTOS first-level system interfaces. That is to say, it not only changed the FreeRTOS vest, but also changed its content to make itself look completely freeRTOS. So that’s it. Reuse the existing facilities of the ESP-IDF framework and start operation.
Package of scheduler:
The scheduler also needs to be repackaged to make RTT look like FreeRTOS, and its package is also in the ./esp-idf-port/stubs/libcpu.c file:
Looking at these packages, I am really wronged by RTT.
So the whole system looks like this:
The FreeRTOS skin is like a shell, which converts Xtensa's support for FreeRTOS into support for RT-Thread. In fact, there may be two directions of work, application-oriented and processor-oriented, the latter has been said before The former is to convert the kernel's support for RT-Thread system API into support for FreeRTOS, which seems to be symmetrical and opposite.
Through two layers of abstraction, the function of supporting rtt is realized without adding a new arch porting layer to rtt.
There is a fragment in the classic Jin Yong martial arts Heavenly Dragon Eight Parts. The King of the Great Wheel of Tufan National Normal University, the King of the Ming Dynasty, singled out the abbots of Shaolin Temple. On the surface, they used the 72 stunts of Shaolin Temple. The abbots and the elders were not opponents. Fortunately, they were emptied. See through and expose that the stunts he used were motivated by small Wuxiang Gong, using the internal force of Taoism, not the real 72 stunts of Shaolin Temple, which preserved Shaolin's reputation. It is very similar to the way of wearing a vest.
From a commercial point of view, the purpose of our research on the operating system is not the operating system itself, but its ability. This ability is the ability to load and execute user programs. However, when it comes to RTOS, the volume is small, the scale is small, and the program is small. Small, the scene is fixed, usually the scheme and the operating system itself are developed and compiled together, so that the constructed system is only used in a fixed scene.
The main difference between this method and ordinary home PCs, workstations, servers, etc. is that on these hardware, the operating system is independent. Although the main task of the operating system is still to load and execute programs, these executed programs can be Arbitrary definition and development, not limited to one or two scenarios in the RTOS scenario, as shown below:
I actually ran it and did a test of airkiss distribution network and found that it was quite stable. It is no wonder that RTT itself is a very good RTOS (I personally think that it is far superior to FreeRTOS in terms of supporting large-scale RTOS solutions).
Therefore, it seems that there are two types of virtualization. One type of hardware virtualization, such as qemu, can virtualize different ISA architectures and run programs of the corresponding architecture on it. The other type of software virtualization, through The software adds layers, so that a functional software is presented in a new look.
So the question at the beginning has an answer. The ESP32 support method of RTT still uses the arch porting layer provided by Cadence. This approach has a small workload and no problem with feasibility. This also corresponds to a motto in software development "in software All problems can be solved by adding layers"