To be honest, I knew a long time ago that the heterogeneous processor chip composed of cortex-A and cortex-M is a good thing. For example, NXP and TI have had such SOCs for a long time, but they are always scared, and think they are troublesome to develop. The introduction on the Internet is also confusing. Only recently did I use STM32MP157C to find that at least STM32MP157 is not as difficult to use as imagined. After doing some basic experiments, I also designed an application layer protocol IO-RPC (IO Remote Procedure Call). Prepare for the design of embedded devices for Linux. This will accelerate the pace of our migration to Linux-based applications. Relevant content and ideas are currently immature, share them with you for discussion.
remoteprc，rpmsgAPI和open AMP
STM32MP157C is a heterogeneous multi-processor structure, which consists of two cortex-A7 cores and one cortex-M4 core. This is an asymmetric processor architecture (AMP Asymmetric Multi-processing). In order to realize RTOS or bare metal program can communicate with the program on Linux. Need a standardized multi-core architecture. . In the Linux internalization, remoteproc and rpmsgAPI components are included. This infrastructure was first developed by Texas Instrument. On this basis, mentor company developed the OpenAMP framework. Under this framework, the main Linux kernel uses the remoteproc API to control and manage the life cycle of the remote kernel (you can start and stop other kernels), allocate system resources for the remote processor and create virtual IO virIO devices. The program in the remote kernel registers virIO through the openAMP library and communicates with the application on the main Linux through virIO.
The simple virtual IO is the serial port (UART). In the figure below, two virtual UARTs are registered between the main Linux and the remote processor. Convert complex multi-processor communication into two UARTs. Isn’t it amazing? Of course, the transmission speed of such a UART should be much higher than that of a physical UART. Because they are implemented through shared memory. In the specific implementation, we use virtual virUART0 as the communication channel of IO-RPC, and use virUART1 as the debugging serial port.
IO-RPC protocol
In the heterogeneous processor architecture of STM32MP157C, cortex-A7 and cortex-M communicate with each other in the above manner, which provides a virtual serial port to transparently transmit data. This is not enough, we designed the IO-RPC protocol on this basis. Make Linux applications more convenient to access cortex-M4 IO resources and programs.
. Usually cortex-A completes network and data processing transactions (based on Linux OS), cortex-M completes real-time IO interface control (based on RTOS), so data design is required, a relatively common dual-computer communication protocol to implement data processing programs The data exchange with the IO control program is conducive to standardizing program design, improving program flexibility and scalability.
IO-RPC uses the mechanism of remote procedure call to achieve access and control to the interface resources and programs on cortex-M by calling the procedures on M4. In order to improve efficiency, IO-RPC binary coded RPC form.
Figure-1 RPC protocol between heterogeneous processors
The difference from traditional RPC is that when the signal or state of the hardware interface occurs randomly, a notification mechanism similar to an interrupt is required. A notification frame is set in the protocol to notify the hardware of events.
IO-RPC details
Object programming concept
The IO-RPC protocol introduces the concept of object-oriented programming, and defines various IO peripheral types as objects, and the specific IO peripherals are regarded as the entity of the object.
Frame structure
RPC call (A7 ->M4)
Object type, object entity, method, parameter length, parameter
RPC result (M4 ->A7)
Object type, object entity, result, parameter length, parameter
Notification M4 -> A7)
Object type, object entity, notification, parameter length, parameter
- Object type (Object Type, 1 byte)
- Object entity (object instance, 1 byte)
- Method, result, notification (1 byte)
- Parameter length (2 bytes)
- Parameters (n bytes)
Object type
Theoretically, the object can be of any type. Here we are limited to a programmable controller PAC based on STM32MP157C as an example.
The PAC controller provides the following object types
- Digital input (8 digital inputs)
- Digital output (8 digital outputs)
- Analog input (two analog inputs)
- Analog output (two analog outputs)
- RS485 (two-way UART)
- FD-CAN (One way FD CAN)
Object entity
The entity of the object uses binary encoding.
- Digital input (0~7)
- Digital output (0~7)
- Analog input (0~1)
- Analog output (0~1)
method
Each interface object contains several methods. They use binary sequential coding as an ID. such as:
- Read
- Write
- PWMOut
Realization (omitted)
Release it later.