The use of Real-time Operating Systems can simplify application development of embedded systems, effectively ensure stability and reliability, and facilitate maintenance and secondary development. , Can be solidified, can be tailored, with high stability and reliability, in addition, the distinctive characteristics of μC/OS-II is open source code, easy to transplant and maintenance. On the official page of μC/OS-II, you can find a comprehensive list of porting examples. However, in actual development projects, there is still no suitable version for the chips or development tools used in the project. You may wish to port the SDK as needed. In this paper, the transplantation process on the DSP is taken as an example to analyze the general methods and techniques of the transplantation of μC/OS-II on the embedded development platform. Basic steps of μC/OS-II Transplantation After selecting the system platform and development tools, the transplantation of μC/OS-II usually needs to follow the following steps: ● Gain an in-depth understanding of the system core ● Analyze the features of the C language development tools used ● Write the porting code ● Conduct a porting Test ● Encapsulate service functions for the Project Development Platform (Similar to the 80x86 versions of PC. C and PC. h) System Core Regardless of the project is the core of the system MCU, DSP, MPU, μC/OS-II transplantation, the attention to the details are similar. First, it is the chip Interrupt Processing Mechanism, how to enable and shield the interruption, and whether to save the previous interruption status. Also, whether the chip has soft interruptions or trap commands is triggered. In addition, you also need to pay attention to the system's memory usage mechanisms, such as the memory address space, the growth direction of the stack, and whether there are commands for bulk stack pressure. In this example, the TMS320C6711 DSP is used. This is a floating-point model in TI's 6000 series. Due to its extremely high clock frequency, it adopts technologies such as super-normal command character (VLIW) structure, class-of-the-shelf instruction set, and multi-level flow, therefore, the computation performance is quite powerful and has been widely used in communication equipment, image processing, medical instruments, and other fields. In C6711, there are three types of interruptions: reset, unshielded interrupt (NMI), and shielded interrupt (INT4-INT15 ). The CSR registers control the global enable and enable the IER registers separately. There is no soft interrupt mechanism in C6711, so the task switching of μC/OS-II needs to write a special function implementation. In addition, C6711 has no special interrupt return instructions or batch pressure stack commands, so the corresponding task switching code must be programmed. Because of the use of the class of the core, C6711 kernel structure, only A0-A15 and B0-B15 these two sets of 32 bit General registers. C language development tools C language development tools are essential for μC/OS-II, no matter what the system core is. The simplest information can be found in the development tool manual, for example, how many bytes are compiled for various data types in C language, whether embedded assembly is supported, and what are the format requirements; whether the "interrupt" non-standard keyword declaration interrupt function is supported, whether the list function is supported, and so on. These features bring a lot of convenience to embedded development. TI's C language development tool CCS for C6000 contains all of the above functions. On this basis, some technical details of the development tool can be further clarified, so as to carry out the real porting work. First, enable the "list of assembly code" function of the C compiler, so that the compiler will generate the corresponding assembly code file for each C source file. In the CCS development environment, select "Interlisting: Opt/C and ASM (-s)" in the "Feedback" column of "/Project/Build options". Or, you can also directly add the "-s" parameter to the C compilation command line of CCS. Then, compile several simple functions to compare the C source code and compiled compilation code. For example: Void FUNC_TEMP (void) { Func_tmp2 (); // call any function } The ASM code generated after compilation in CCS is: . Asg B15, SP // macro definition _ FUNC_TEMP: STW B3, * SP -- (8) // inbound Stack NOP 2 CALL _ Func_tmp2 //----------- Mvkl back, B3 // function call Mvkh back, B3 //----------- NOP 3 BACK: LDW * ++ SP (8), B3 // output Stack NOP 4 RET B3 // function return NOP 5 It can be seen that in the Rules of the CCS compiler, the B15 register is used as a stack pointer, and the general access command is used for Stack operations, and the stack pointer must be changed in 8 bytes. In addition, the B3 register is used to save the return address of the function call. Before the function is executed, stack protection is required until the function returns the stack. Of course, the C compiler of CCS has an agreed purpose for each General Register, but for the porting of μC/OS-II, understanding of the above information is enough. Finally, write a function declared with the keyword "interrupt: Interrupt void isr_temp (void) { Int; A = 0; } The generated ASM code is: _ Isr_temp: STW B4, * sp -- (8) // inbound Stack NOP 2 Zero B4 //--------- STW B4, * + SP (4) // a = 0 NOP 2 //---------- B IRP // returns an interrupted message. LDW * ++ Sp (8), B4 // output Stack NOP 4 Compared with the previous Code, there are two differences in the compilation of interrupt functions: ● The return address of the function no longer uses the B3 register. Correspondingly, you do not need to import B3 into the stack. (The IRP register can automatically save the program address when the interrupt occurs) ● The compiler will automatically count the registers used by the interrupt function, so that all of them are protected in the stack at the beginning of the interrupt-for example, only the B4 register is used in the above program segment. Write porting code Based on an in-depth understanding of the system's core and development tools, writing and porting code is relatively simple. The vast majority of μC/OS-II code is written in ansi c, and the code hierarchy is very clean, the porting Code related to the platform only exists in three files: OS _CPU_A.ASM, OS _CPU_C.C, and OS _CPU.H. When porting, combine the information that has been obtained in the previous two steps, basically, follow the instructions in the relevant chapter of "embedded real-time operating system μC/OS-II. However, due to the wide variety of system cores and development tools, there are usually some different processing methods in actual projects, so pay special attention to them. Take C6711 as an example: ● The enable and block macros of an interrupt are defined: # Define OS _ENTER_CRITICAL () Disable_int () # Define OS _EXIT_CRITICAL () Enable_int () Disable_int and Enable_int are two functions written in assembly language. A feature of the control status register (CSR) is used here. In addition to the GIE bit that controls global interruptions, the CSR also has a PGIE bit that can be used to save the previous GIE status. Therefore, in Disable_int, first write the value of GIE to PGIE, and then write the value of GIE to 0 to block the interruption. In Enable_int, the value is read from PGIE and written to GIE to return to the previous interrupt settings. In this way, we can avoid using these two macros to accidentally change the interrupt state of the system-in addition, we do not use stacks or local variables, which is better than the method recommended by the original author. ● Task Switching: As mentioned above, there is no soft interrupt mechanism in c6711. Therefore, to switch tasks, you need to compile a function _ osctxsw in the assembly language. # Define OS _task_sw () osctxsw () Registers that require inbound stack protection in c6711 include A0-A15, B0-B15, CSR, IER, IRP, and Amr, which, together with the current program address, constitute a Storage Frame and need to be saved on the stack. _ In the osctxsw function, you need to import the above storage frame into the stack as if an interruption occurred, then obtain the TCB pointer of the activated task, and pop up the content of the stored frame, this completes task switching. Note that OS _task_sw is called as a function, so as described above, the current program address during the call is saved in the B3 register, this is the return address when the task is re-activated. ● Interrupted Compilation: As mentioned above, if the "interrupt" keyword is used to declare a function, CCS automatically puts the registers used in the function into the stack and protects them out of the stack during compilation. However, this will lead to various interruptions, and the content in and out of the stack is different. This can cause serious errors for μC/OS-II. Because the μC/OS-II requires that the inbound stack operations when the interrupt occurs use the same Storage Frame Structure as when Task Switching occurs. Therefore, when porting, based on μC/OS-II for development, should not use the "interrupt" keyword, and the application of the following structure to write the interrupt function: Void ostickisr (void) { Dsp_c6x_save (); // service function, in the stack Osintenter (); If (osintnesting = 1) // added in v2.51 { Ostcbcur-> ostcbstkptr = (OS _stk *) dsp_c6x_getcurrentsp (); // service function } // Obtain the current sp value // Enable interrupt nesting, where the interrupt is enabled Ostimetick (); Osintexit (); Dsp_c6x_resume (); // service function, output Stack } Dsp_c6x_save and dsp_c6x_resume are two service functions that are used to complete the out-and in-stack interrupted Operations respectively. They differ from OS _task_sw functions in that the current program address is automatically stored in the IRP register when the interrupt occurs and should be used as the return address of the task instead of B3. In addition, dsp_c6x_resume is a function that never returns. After all the content is pushed out of the stack, it directly jumps back to the program address before the interruption and continues execution. Perform a porting Test After writing all the transplanted code, you can write several simple task programs for testing. Generally, you can do this in three steps. The relevant information is detailed, I will not go into detail here. Encapsulate service functions The last step is often overlooked, but it is of great significance to keep the project code concise and easy to maintain. The source author of The μC/OS-II strongly recommends storing source code in different paths. For example, all source code in this example should be stored in the following path structure: /UCOS-II Platform-source // platform-independent code │ OS _core.c │ ...... 2017── ti_c6711 // System Core ├ ── CCS // Development Tool │ OS _cpu.h │ OS _cpu_a.asm │ OS _cpu_c.c │ ─ ── Dsp_c6x_service // service function │ Dsp_c6x _ service. h │ Dsp_c6x _ service. ASM │ Development-test // specific development project code OS _cfg.h Includes. h Test. C ...... As shown above, the service functions in dsp_c6x_service are similar to the PC. C and PC. H files in the 80x86 version provided by the original author. In this example, the service functions include the interrupt-related functions mentioned above, as well as the system initialization function dsp_c6x_systeminit () and the clock initialization function dsp_c6x_timerinit. For specific development project code, you can create your own directory under the "/ti_c6711" path, just like porting the "test" project for testing, without having to focus on the source code and service functions of the μC/OS-II. In this way, you can avoid unnecessary compilation errors and facilitate the maintenance of development projects. ------------- Description of copyright to μC/OS-II series software Micrium products include μC/OS-II, μC/GUI, uC/FS, μC/TCP-IP, μC/USB and so on. Micrium provides embedded system applications and has intellectual property rights to its software. Micrium takes a lot of time and money to provide high-quality software products for the embedded field. All of the above products are provided to customers in the form of source code, with great applicability. Products are not free software, is not open source software, therefore, can not be used for free, need to clearly clarify the μC/OS-II and series of software is not open source free software, this is completely different from Linux. Developers and researchers can get the μC/OS-II source code by buying books from Mr Jean of Micrium, but can only be used as individuals and schools to learn, all business purpose activities that are directly and indirectly related to μC/OS-II must be purchased with commercial licenses for the use of μC/OS-II and series products, any reference design, teaching equipment, and final products from Chip/board/system manufacturers are illegal if they are not legally authorized by Mr. Jean of Micrium, this book in μC/OS-II is Micrium Corporation (Www.micrium.comAnd China agents-Beijing mctai software company website (Www.bmrtech.com. Micrium Company other software such as μC/GUI, μC/FS, μC/TCP-IP, μC/USB and other sales models and μC/OS-II is different, if you do not have the purchase authorization, you cannot have the source code or use the source code for product design, training, teaching and production. μC/OS-II, μC/GUI, μC/FS, μC/TCP-IP, μC/USB and other authorization methods are: single product, product line (series) according to the CPU product three forms, μC/OS-KA, μC/OS-VIEW and other tools are charged according to the number of users, compared with the traditional RTOS, the development cost and the usage fee of each slice are usually 2-3 US dollars (from several hundred to several US dollars ), μ C/OS-II and series products are a one-time charging method, should be only equivalent to the traditional RTOS 10-20% of the total cost. If you are using the μC/OS-II series software for your product, you need to purchase and get formal use authorization. |