AVR MCU RTOS-AVRX Application

introduction

      With the development of technology, the design and application of embedded systems have a great impact on people's lives and will gradually change people's future lifestyles. Developing applications on a specific operating system allows developers to ignore many underlying hardware details, making application debugging more convenient, easier to maintain, shortening the development cycle and reducing development costs. Therefore, embedded operating systems are deeply favored by developers.

      AVR microprocessor is an 8-bit embedded RISC processor developed by Atmel. It has the advantages of high performance, high confidentiality, low power consumption, non-volatility, etc., and the program memory and data memory can be independently addressed and have independently accessed Harvard structure. The AVR microcontroller core has a rich instruction set, which is directly connected to the logic operation unit through 32 general registers, allowing a single instruction to access two independent registers in one cycle. This structure makes the code execution efficiency nearly 10 times faster than that of traditional complex instruction set microprocessors.

      AVRX is an open-source embedded operating system written by lbarello. It is a RTOS specifically for AVR series microcontrollers and is free and modifiable. Its disadvantage is that it is difficult to port to other platforms as a dedicated operating system.

1 Features of the AVRX system

      AVRX, as a dedicated RTOS for AVR, has the following features:

      ◆Fully support preemptive and priority-driven task scheduling algorithms;

      ◆16 priority levels, tasks of the same priority are executed in turns using the Round-robin scheduling algorithm;

      ◆Semaphores can be used for signal transmission, synchronization and mutual exclusion, supporting blocking and non-blocking syntax;

      ◆Tasks can use message queues to pass information to each other, and blocking and non-blocking calls can be used to receive and confirm messages;

      ◆In the interrupt subroutine, most non-blocking interrupt service routines can be used;

      ◆Supports time queue management of a single timer. Any process can set a timer, and any task can wait for the timer to expire.

      ◆Support single-step debugging of the running process;

      ◆The program space is small, and the version with all functions occupies 1000 bytes;

      ◆Some transactions related to timers/counters can be written as task-level code using AVRX.

1.1 Task

      AVRX2.6 saves all 32 registers to support C language. The minimum context is 32 registers, SREG and PC, a total of 35 bytes. The AvrxInitTask() function initializes all registers to 0X00. Only the process context is saved in the task stack, and all other uses (including kernel and interrupts) are saved in the kernel stack. This reduces the context switch of the first interrupt and the SRAM consumption of entering the kernel API. Subsequent interrupts (if interrupt nesting is allowed) are embedded in the kernel stack, and the API does not perform context switching.

1.2 Semaphore

      Semaphores are SRAM pointers, and they have three states: PEND, WAITING, and DONE. When a process is blocked by a semaphore, it is in the WAITING state, and multiple tasks can queue up to wait for a semaphore. In the latter case, the semaphore can be regarded as a mutually exclusive semaphore. The provided API functions are as follows: AvrXSetSemaphore, AvrXIntsetSemaphore, AvrXWaitSemaplaore, AvrXTestSemapIlorc, AvrX-IntTestSemaphore, and AvrxResetSemaphore.

1.3 Timer

      The Timer Control Block (TCB) is 4 (or 6) bytes long. They manage a 16-bit count value. The Timer Queue Manager manages a classified timer queue, each of which is adjusted to the sum of all counters to the value required for its delay. The provided API functions are as follows: AvrXStartTimer, AvrXTim-erHandler, AvrXCancel Timer, AvrXWaitTimer, AvrX-TestTimer and AvrXDelay.

1.4 Message Queues

      The message queue uses the message control block (MCB) as the queue head address. Any process, interrupt handler and multiple processes can wait for messages. The length of MCB is 2 or 4 bytes, and the message can be considered as a semaphore with greater flexibility. The provided API functions are as follows: AvrXSendMessage, AvrXIntSendMessage, AvrXRecvMessage, AvrXWaitMessage, AvrXAckMessage, AvrXTestMessage and AvrXWait-MessageAck.

1.5 Single-step operation support

      By reassembling the kernel AVRX, single-step support can be enabled or disabled. Single-stepping can be enabled by defining the following variable when compiling the kernel library: #define SIGNALSTEPSUPPORT. Before single-stepping can be performed, the process must be suspended. There are two ways to achieve this: one is to just initialize the process but not enable it; the other is to call AvrXSuspend with the ID of the target process. Once the target process is suspended, the debug SPI can be used. The provided API functions are: AvrxStepNext and AvrXSingleStepNext.

1.6 System Objects

      AVRX is built around the concept of system objects. A system object consists of a link followed by a semaphore of zero or more bytes of data. Process objects can be queued on run queues and semaphores. Counter control blocks can only be queued on counter queues. Message control blocks can only be queued on message queues. Processes wait on these objects based on semaphores embedded in them. The available SRAM in the process stack is the main factor limiting the size of the system. Each process requires at least 10 to 35 bytes of space to store the process context. The following API functions are provided: AvrXSetObjectSamaphore, AvrXIntObjectSamaphore, AvrXResetObiectSamaphore, AvrXWaitObjectSamaphore, AvrXTestObjectSamaphore, and AvrXInfTestObjectSamaphore.

1.7 System Stack

      AVRX needs a large enough stack to handle all possible interrupt nesting. Each time the kernel is entered, 10 to 35 bytes will be pushed into the stack (standard context and return address), and interrupt processing may push more. The AVRX API will temporarily push more than 2 bytes. GCC or assembly code is defined at the top of SRAM, and it is the designer's job to ensure that the AVRX stack is within the valid SRAM space. [page]

2 Application of AVRX system

2.1 AVRX transplantation on different types of AVR microcontrollers

      The following uses ATmegM6 as an example to introduce the transplantation work.

      (1) Compiler selection

      Since the compiler of AVRX is written under the AVR-GCC compiler launched by GNU, the use of AVR-GCC compiler can greatly improve the transplantation characteristics of AVRX on different AVR microcontrollers.

      (2) Recompile the AVRX kernel

      In order to successfully compile the application, you need to recompile the AVRX kernel. The recompilation includes the following steps.

      ①Re-modify the Makefile file of the AVRX source code. The following parts need to be modified:

      ②Re-modify the serialio.S file of the AVRX source code, that is, modify the register definition of the serial port part according to different microcontrollers. The following code needs to be added:

      ③ Recompile the kernel. The specific method is to copy a "command prompt" to the AVRX directory, run the "command prompt", type the "makegcc" command and run it to complete the recompile of the AVRX kernel, which will generate many .o files and avrx.a files. These files will be used in future applications.

      At this point, the kernel porting of AVRX on the ATmegal6 microcontroller has been completed, and then you can write the application.

2.2 Writing applications on AVRX

      At this time, you need to use a new makefile. Your own program can be in a different directory from the AVRX kernel, but you need to specify the clear path of the dependent files. The makefile framework can use the makefile framework in the sam-ple folder of Winavr. The difficulty here is actually the syntax of the makefile. The following introduces the code that needs to be modified or added in the application's makefile in the example:

3 System Testing

3.1 System real-time test

      In real-time systems, the real-time performance of real-time systems is reflected in the system's ability to respond to external events. The system responds to external events through interrupts, and the user interrupt program should do as little as possible, leaving most of the work to the task, and only notifying the task to run through semaphores or message mechanisms. Mega16's timer 2 is set to compare match output mode, and a certain period of pulse output is generated after the match time is reached, and an interrupt is generated. Set timer 1 to count mode to count the generated pulse output. Use the compare match interrupt service subroutine of timer 2 to send a semaphore to notify the task to run, and do not open the interrupt in the interrupt subroutine, but open the interrupt after the task receives the signal, so as to achieve synchronization between interrupt processing and task running. Count a global variable in the task to record the number of times the task is executed. After running for a period of time, the number of times the task runs is the same as the count of timer 1 during the set match time, then the system can fully respond to external events during this period. When the compare match time of timer 2 is set to be greater than 23 μs, the two counts are equal; when it is less than 23 μs, the count value of timer 1 is greater than the count value of the task, indicating that the task has not been fully responded to. This means that the interrupt entry and return, that is, the system's response and processing time to external events, is 23 μs, which is much longer than the response time of other operating systems after being ported to the AVR microcontroller.

3.2 Application Routine Test

      Here we simply compile several routines in the source file, remove unnecessary codes, add some codes that we want to test, and test the timer control module, semaphore and message queue with their simple combinations, and achieve the expected results on ATmega16.

4 Experience

      ①AVRX source code is written in assembly language, which is relatively efficient. However, since there is no detailed API introduction document, the best way to get started is to first read the RTOS source code and routines, then modify them, and then gradually become proficient in using them with your own code.

      ②AVRX needs to allocate 35 bytes of stack plus the additional stack required by the task code. The specific size depends on the number of local variables used by each process. A better way to determine the size of the stack allocated to a task is to allocate a large stack (such as 70 bytes), run a section of the application and see how deep the stack is (because GCC clears all memory to 0 when it starts, this is easy to see). However, to be safe, use the compiler or emulator to write a few bytes of 0xFFFFF at the top of the estimated stack to verify how many bytes are reached, and then allocate more than two bytes to the task than the test result.

      ③The last instruction of startup must jump to Epilog().

5 Conclusion

      AVRX is a good RTOS. Its most notable features are its small kernel and high speed. After compilation, it only takes about 500 to 700 bytes, and it has all the basic scheduling functions. Since its code is open, combined with the characteristics of different types of AVR microcontrollers, the system can be tailored and expanded on this basis to achieve better results. This article provides a reference for the application of AVR embedded systems.