1. Article purpose[edit source]
This article gives an example of high rate exchange of data chunks from the Cortex-M to the Cortex-A.
2. Introduction[edit source]
Relying on a logic analyser sample, this article describes the mechanism and software implemented to perform high rate transfer. In this example, Cortex-M is used to perform continuously :
- real time operations,
- offload of a heavy data algorithm,
- transfer of the resulting data flow, via DMA, in DDR buffers.
Such kind of implementation requires :
- contiguous memory allocation in DDR,
- Cortex-M to be aware of physical address and size of memory buffers,
- to mmap buffers to let Linux user land application have access to them.
A specific Linux driver has been developed to take care of such constraints: RPMsg sdb (shared data buffer).
3. Example context description[edit source]
Let's implement a logic analyzer running on the STM32MP1 discovery kit.
The user interface allows to start the logic analyzer sampling thanks to a START button.
On START press, the logic analyzer samples GPIO PORT E bits 8 to12 which are present on Arduino connector; this represent 5 bits. It remains 3 bits in each byte of data, which are used to implement a packing algorithm.
After packing, the logic analyzer saves data in the file system, in a binary file called "date-time".dat; where date-time is the date and time of the system at the START press.
4. Static architecture of big data example[edit source]
Big data example includes :
- Cortex-M firmware
- Linux user land application
- Linux RPMSG sdb (shared data buffer) driver
- Linux RPMSG tty driver
In the figure, the numbers indicate the chronological order of data flows.
5. Cortex-M firmware[edit source]
Cortex-M firmware is responsible to:
- Receive messages, from Linux RPMsg sdb driver, containing physical address and size of DDR buffer(s)
- Receive a command Start/Stop sampling (including sampling frequency) through the TTY RPMsg channel, from Linux application
- On start request:
- Sample the data at requested sampling frequency
- Filter and pack data
- Transfer the packed data in DDR buffer by packet of 1024 bytes thanks to DMA
- Inform Cortex-A user interface (through the TTY RPMSG channel) when a DDR buffer of 1 megabyte is filled, and roll to next DDR buffer
6. Linux user land application[edit source]
A user interface is available in a web page, running in the Cortex-A Linux application.
The user interface allows to control:
- The sampling frequency
- The start / stop of the sampling
The user interface displays statistics, including:
- Number of packed data received by user interface
- Number of unpacked data decompressed by user interface
- Number of packed data written by user interface in file system
The user interface saves packed data in a binary file.
7. Linux RPMsg_sdb driver[edit source]
Cortex-A Linux RPMsg_sdb driver is responsible to:
- Allocate / free buffers in contiguous memory (DDR)
- Send physical address and size of DDR buffer to Cotex-M firmware over RPMSG
- Mmap DDR buffers in order to let user land application access to them
8. RPMsg_tty driver[edit source]
RPMsg_tty driver is used for the communication (transport commands and status/events) between Cortex-M firmware and Cortex-A user land application.
9. Dynamic view[edit source]
At startup, the Linux application :
- Loads rpmsg_sdb.ko module
- Loads Cortex-M firmware, then start it
- Opens RPMsg_tty driver for Cortex-M firmware control
- Opens RPMsg_sdb driver, then uses RPMsg_sdb IOCTL interface to allocate and mmap 3 buffers of 1MB in DDR memory.
On press on START button, the application sends the sampling command to Cortex-M firmware (including sampling frequency), and creates a "date-time.dat" binary file which is used for sample storing in mass storage.
On press on STOP button, or overrun data error, or file system full error, the application sends the stop command to Cortex-M firmware and finalize the "date-time.dat" binary file.
On event "buffer full" coming from Cortex-M firmware via RPMsg tty driver, the application unpacks data, writes packed data in "date-time.dat" file, and updates statistics information.
10. Results[edit source]
Depending on the type of data available on GPIOE, the transfer rate between Cortex-M and Cortex-A will vary from 1 megabyte per second (repetition factor of 7) to 8 megabytes per second (repetition factor of 0).
In this use case Cortex-M CPU is able to compress data at a rate up to 64 megabits per second (8 megabytes per second), and this is the maximum we can hit.
11. Limitation[edit source]
The limitation is due to data packing, as shown in this figure:
On this oscilloscope snapshot figure, a GPIO is set at the beginning of the packing algorithm, and reset at the end of the algorithm. So, 109.5µs are spent to pack 1024 bytes of data at a sampling frequency of 8 MHz. Increasing the frequency to 9 MHz would cross the limit : 9MHz => 111µs.
12. Source code[edit source]
The source code of this use case is available as a Yocto layer here:
The firmware is included in the Yocto layer as a .elf file.
The source code of the Cortex-M firmware is available here:
For firmware compilation, please have a look into: Developer Package for STM32CubeMP1
13. Usage[edit source]
Please follow README.md of Yocto layer to perform installation.
The logicanalyser application is launched by pressing User2 button of the STM32MP1 Discovery board.
Use a PC or a Tablet or a MobilePhone as a host, and scan for a Wifi hotspot named STDemoNetwork.
Select it and use "stm32mp1" as password.
Launch the internet navigator on the host, and enter the following URL: 192.168.72.1:8888/index.html
Select the sampling frequency and click on Start to start the use case.
Snapshot view of user interface :
