Preface
The 51 series single-chip microcomputer is a high-performance 8-bit single-chip microcomputer launched by Intel Corporation in the United States in 1980. It is widely used in China. At present, software engineers need to start from the bottom in software design, and a lot of repetitive work needs to be done in system software design. If an operating system based on the 51 series single-chip microcomputer is developed, then the user only needs to write programs for each task, and does not have to remember all the running conditions of all tasks at the same time, which not only greatly reduces the workload of program writing, but also reduces the possibility of errors.
1. Selection and demonstration of development platform
The choice of development platform is crucial because sometimes it not only affects general issues such as progress, product quality, maintainability, but also involves the feasibility of the solution.
In this system, the 51 series microcontroller is selected as the operating platform of the operating system for the following reasons.
First of all, the 51 series of single-chip microcomputers are widely used, and a large number of 51-compatible single-chip microcomputers with superior performance have been launched one after another. These include: Philips' series of products with low power consumption, high speed and enhanced type; Atmel's series of products that perfectly combine Flash (non-volatile flash memory technology) EEPROM with 80C51 core; Siemens' series of products and some other companies' products that are unique in anti-interference performance, electromagnetic compatibility and communication control bus functions and are often used in harsh working environments. Since the products are so rich and the performance is so superior, in the system design that handles multiple tasks and has strict real-time requirements, in order to fully tap the potential of single-chip microcomputers (especially in terms of real-time performance) and to simplify the development process, the demand for real-time operating systems based on 51 series single-chip microcomputers is very strong. Keil's RTX51 Full is a real-time operating system with practical value based on 51 series single-chip microcomputers, but this operating system is a paid software with undisclosed source code.
Secondly, with the help of Keil C51's integrated development environment, it is entirely possible to develop operating system code suitable for the 51 series microcontrollers.
Keil C51 software provides rich library functions and powerful Windows interface integrated development and debugging tools.
Another important point is that the target code generated by Keil C51 is very efficient. The assembly code generated by most statements is very compact and easy to understand. When developing large software, the advantages of high-level languages are more evident. The C compiler can generate reentrant code, and interrupts can be turned on and off in C language.
2 Issues that should be paid attention to when developing 51 single-chip microcomputer operating system
(1) The code of the operating system software cannot be too long
Because the system hardware resources of the 51 series microcontrollers are relatively scarce, if the code of the operating system is larger than the code of the application, the user's application may even have to consider giving up resources to the operating system. Such an operating system is not practical even if it has perfect functions. The popular embedded operating system cannot be applied to the 51 series microcontrollers because the code is too large. Developing a 5,000-line bare metal application only takes up 7~8KB of ROM space, and an operating system takes up dozens of KB. Not only does it take up space, but it also loses the real-time advantage (it takes time to execute so many instructions). Therefore, it is not surprising that the author of μCOS does not support porting his code to the 51 series microcontrollers.
(2) The operating system cannot take up too much on-chip RAM space
The 51 series MCU only has 128 or 256 bytes of on-chip RAM space, which will be used up if you don't pay attention. If the operating system uses up almost all of the on-chip RAM, what will the user's application use? If the user's program can define variables in the off-chip RAM, then where is the system's hardware stack placed? As we all know, the hardware stack of the 51 series MCU cannot be placed off-chip, so if you want to develop an operating system on the 51 series MCU, you have to use less of its on-chip RAM. But it is impossible to use the on-chip RAM, because the operating system also needs to pass parameters and use the stack. The C function of the C51 MCU passes parameters through registers and memory , not through the stack. But some measures can be taken to make the operating system code use less on-chip RAM.
(3) Solve the problem of function reentrancy
When developing a real-time preemptive operating system, reentrant functions are essential. Reentrant functions can be called by more than one task without worrying about data corruption. Reentrant functions can be interrupted at any time and can be run again after a period of time without losing application data. To make a function reentrant, the function must meet one of the following three conditions:
① Do not use shared resources;
② Turn off interrupts when using shared resources, and turn them on again after use;
③ Apply for semaphores when using shared resources, and release the semaphores after use.
These conditions are easy to implement in standard C programming, but it is more troublesome in Keil C51. Because standard C allocates local variables to the user stack (dynamic allocation), while Keil C51 allocates local variables to registers or fixed memory addresses (static allocation), and through the variable coverage analysis method, the local variables of multiple functions use the same memory address to reduce memory usage. In Keil C51, it is better if local variables are allocated in registers, but it is more troublesome if local variables are allocated in memory.
(4) Stack allocation problem
The main task of a preemptive operating system is to schedule tasks and complete the system's functions through real-time scheduling of tasks. In the process of task scheduling, it is inevitable that tasks will preempt system resources, because there is only one CPU in the system, and each task considers itself to be the absolute occupant of the CPU, and each task is an infinite loop. The basis for switching between tasks is their respective priorities. A high-priority task can terminate the running task through the task scheduling function or the interrupt exit function. The interrupted task can only continue to run from the interruption point when its priority is the highest in the current ready task list. This requires allocating a task stack for each task to save the task's environment variables. Since the number of environment variables that need to be saved when each task is interrupted at different times is different, the allocation of task stack space is also a science.
3 Some Problem Solving Techniques
(1) Solution to the on-chip RAM usage problem
It is best not to put the task stack on the chip. If the task stack is placed on the chip, the resources available to the user application will be very limited, and the functions of the application will also be restricted. This is why some real-time operating systems based on 51 series microcontrollers that put the task stack on the chip can only be used for demonstration experiments, but are not practical. A real-time operating system based on 51 series microcontrollers with practical value must run in a RAM environment of more than 512 bytes. With the development of integration technology, many 51 series microcontrollers with auxiliary RAM have appeared. This type of microcontroller integrates the off-chip RAM into the chip and uses MOVX instructions to access these RAMs. If the user does not want to expand the off-chip RAM through three buses, this type of microcontroller with auxiliary RAM can be selected. In addition, because the operating system needs to use some global variables, and in view of the processing speed problem, it is not desirable to put all of them off-chip, then it is possible to decide which ones to move off-chip and which ones to keep on-chip based on the frequency of application of these global variables. Don't underestimate the saving of these bytes, the effect will be very obvious on the 51 series microcontroller. The author believes that the highest level of operating system development on a MCU with relatively scarce resources should be to develop a green operating system, and the system resources that users can use when applying the operating system should be similar to those based on bare-metal programming.
(2) Solution to the reentrancy problem
The parameters of functions that require reentrancy should be passed through registers as much as possible, so that the function can be written in a general way to make it reentrant. If there are not enough registers, the hardware stack can be used to save these local variables.
(3) Solution to stack allocation problem
In view of the different requirements of each task for the task stack size, even if the same task is interrupted at different times, it has different requirements for the stack size. One more byte can be allocated to the task stack to count the number of valid data in the task stack. In the on-chip RAM of the microcontroller , a mark is also made at the bottom of the stack. When the task is switched, the environment variables placed in the stack by the current task are copied from the bottom to the top of the stack to the task stack, and then all the data in the task stack of the task to be run are restored to the beginning of the bottom mark of the stack. The data copying between the task stack and the hardware stack is shown in Figure 1.
Among them, Stack(i) and Stack(j) are elements in the pointer array Stack[max_tasks], NUM=SP-StkStart, and the operation steps to be performed in Figure 1 are: ① put the content in the system hardware stack into the stack of the current task; ② move the stack content of the task to be run to the system hardware stack, and pop the content in the hardware stack to each register. This process completes the task switching.
Conclusion
This article introduces several problems that may be encountered in the development of embedded operating systems based on the 51 series microcontrollers and their solutions. These ideas are obtained by the author through learning and practice, and I believe they can be of some inspiration to people doing the same work.
References
1 JEAN J.LABROSSE. Real-time embedded operating system with open source code. Translated by Shao Beibei. Beijing: China Electric Power Press, 2001
2 Chen Mingji, Zhou Ligong, et al. Principles and applications of embedded real-time operating system Small RTOS51. Beijing: Beijing University of Aeronautics and Astronautics Press, 2004
3 Tansi Studio. Embedded system development bible. Beijing: China Youth Publishing House, 2002
Previous article:Application of 51 MCU serial port working mode O in expanding parallel output port
Next article:Basic principles of 51 single chip microcomputer 16X16 dot matrix display learning board
- Popular Resources
- Popular amplifiers
- Research report on overall technical requirements of vehicle control operating system
- Research report on the standardization requirements of vehicle computing platforms
- ZxOS Zephyr-based Guest Operating System for Heterogeneous ISA Machines
- Beyond the Threaded Programming Model on Real-Time Operating Systems
Professor at Beihang University, dedicated to promoting microcontrollers and embedded systems for over 20 years.
- Innolux's intelligent steer-by-wire solution makes cars smarter and safer
- 8051 MCU - Parity Check
- How to efficiently balance the sensitivity of tactile sensing interfaces
- What should I do if the servo motor shakes? What causes the servo motor to shake quickly?
- 【Brushless Motor】Analysis of three-phase BLDC motor and sharing of two popular development boards
- Midea Industrial Technology's subsidiaries Clou Electronics and Hekang New Energy jointly appeared at the Munich Battery Energy Storage Exhibition and Solar Energy Exhibition
- Guoxin Sichen | Application of ferroelectric memory PB85RS2MC in power battery management, with a capacity of 2M
- Analysis of common faults of frequency converter
- In a head-on competition with Qualcomm, what kind of cockpit products has Intel come up with?
- Dalian Rongke's all-vanadium liquid flow battery energy storage equipment industrialization project has entered the sprint stage before production
- Allegro MicroSystems Introduces Advanced Magnetic and Inductive Position Sensing Solutions at Electronica 2024
- Car key in the left hand, liveness detection radar in the right hand, UWB is imperative for cars!
- After a decade of rapid development, domestic CIS has entered the market
- Aegis Dagger Battery + Thor EM-i Super Hybrid, Geely New Energy has thrown out two "king bombs"
- A brief discussion on functional safety - fault, error, and failure
- In the smart car 2.0 cycle, these core industry chains are facing major opportunities!
- The United States and Japan are developing new batteries. CATL faces challenges? How should China's new energy battery industry respond?
- Murata launches high-precision 6-axis inertial sensor for automobiles
- Ford patents pre-charge alarm to help save costs and respond to emergencies
- New real-time microcontroller system from Texas Instruments enables smarter processing in automotive and industrial applications
- RglComm is an open source USB control software for Rigol devices
- Share a charging automatic switching power supply circuit
- KEIL compile error No such file or directory
- Freescale's MC9S12XET256 chip, please help me with the problem of multiplexing function mapping
- Extreme point test
- Cost-effective testing method with TI-PMLK BUCK experiment board
- Urgently looking for VL6180X Chinese version manual
- Urgent help!!! About the calculation of the inductance of the switching power supply transformer
- R16-Startup Manual
- Header files in C language