1. Article purpose[edit source]
This article gives an example of high data rate exchange of data chunks from the Cortex-M4 to the Cortex-A7.
2. Introduction[edit source]
In this example, Cortex-M4 will be 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-M4 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 to be 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 will allow to start the logic analyzer sampling thanks to a START button. On START press, the logic analyzer will sample GPIO PORT E bits 8 to12 which are present on Arduino connector; this represent 5 bits. It will remain 3 bits in each byte of data, which will be used to implement a packing algorithm:
- 000: means data present once
- ...
- 111: means data present 8 times
After packing, the logic analyzer will save data in the file system, in a binary file called "date-time".dat; where date-time will be the date and time of the system at the START press.
4. Static architecture of big data solution example[edit source]
Big data solution example will include :
- Cortex-M4 firmware
- Linux user land application
- Linux RPMSG sdb (shared data buffer) driver
- Linux RPMSG tty driver
5. Cortex-M4[edit source]
Cortex-M4 firmware will be 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) via RPMsg tty driver, from Linux application
- On start request:
- Sample the data at a sampling frequency
- Filter input data to keep only bit 8..12
- Compress data on bit 13..15
- Transfer the packed data in DDR buffer by packet of 1024 bytes thanks to DMA
- Inform Cortex-A7 user interface (via RPMsg tty driver) 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 will be available in a web page, running in the Cortex-A7 Linux application.
The user interface will allow to control:
- The sampling frequency
- The start / stop of the sampling
The user interface will display 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 will save packed data in a binary file.
6.1. Behavior details[edit source]
At startup, the Linux application will :
- Load rpmsg_sdb.ko module
- Load Cortex-M4 firmware
- Open RPMsg_sdb driver
- Use RPMsg_sdb IOCTL interface to allocate and mmap 3 buffers of 1MB in DDR memory.
- Open RPMsg_tty driver for Cortex-M4 firmware control
On press on START button, the application will send the sampling command to Cortex-M4 firmware (including sampling frequency), and open a "date-time.dat" binary file which will be used for sample storing in mass storage.
On press on STOP button, or overrun data error, or file system full error, the application will send the stop command to Cortex-M4 firmware and close the "date-time.dat" binary file.
On event "buffer full" coming from Cortex-M4 firmware via RPMsg tty driver, the application will unpack data, write packed data in "date-time.dat" file, and update statistics information.
7. Linux RPMsg_sdb driver[edit source]
Cortex-A7 Linux RPMsg_sdb driver will be responsible to:
- Allocate / free buffers in contiguous memory (DDR)
- Send physical address and size of DDR buffer to Cotex-M4 firmware over RPMSG
- Mmap DDR buffers in order to let user land application have access to them
8. RPMsg_tty driver[edit source]
RPMsg_tty driver will be used to communicate (transport commands and status/events) between Cortex-M4 firmware and Cortex-A7 user land application.
9. Dynamic view[edit source]
10. Snapshot view of user interface[edit source]
See Usage chapter to discover how to launch and use the interface below.
11. Results[edit source]
In this use case Cortex-M4 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. The limitation is due to data packing, as shown in this figure:
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.
Depending on the type of data available on GPIOE, the transfer rate between Cortex-M4 and Cortex-A7 will vary from 1 megabyte per second (repetition factor of 7) to 8 megabytes per second (repetition factor of 0).
As already explained, data packing is the limitation of this use case; without data packing, experiments allowed to sample GPIOE at a rate of 65 megabytes per second, with samples transferred by DMA in DDR buffers (witout any data treatment in Cortex-A7 application).
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-M4 firmware is available here:
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.