2 Implementation

System introduction

The Texas Instruments AM243x microcontroller device contains two instances of the PRU-ICSS (ICSSG0) peripheral, alongside 2 to 4 ARM R5F cores depending on the part name version.

Figure 2-1 offers insight into the system block diagram. One instance of PRU-ICSS interfaces with the 4-channel IEPE ADC board, serving as the analog front-end for IEPE sensors. The upcoming sections delve into the particulars of this 4-channel SPI interface, showing the implementation towards the ADC boards. The second PRU-ICSS instance functions as an Ethernet MAC, establishing connectivity with the single-pair Ethernet PHY. This connection facilitates the transmission of ADC samples and FFT data to the SPE gateway board.

To effectively distribute the workload, two ARM R5F cores come into play. R5F core 00 undertakes tasks such as ADC interface initialization (including configuration), reception of the four ADC sample buffers, and the execution of FFT calculations on these buffers. Results from the FFT computations and the unprocessed ADC data are made accessible to the second R5F core, labeled as R5F core 01. The latter core is responsible for tasks like JSON formatting and MQTT networking, ultimately transmitting the Ethernet frame through the MAC network interface hosted on the second PRU-ICSS instance (ICSSG1).

This application note focuses primarily on the PRU-ICSSG0 ADC interface in conjunction with the 4-channel ADC board.

PRU-ICSS Multi-Channel SPI to ADC Interface

Figure 2-2 provides a simplified representation of the hardware signal connections between the four ADCs and PRU-ICSS over the custom 4-channel SPI interface.

The implementation of the multi-channel SPI function is facilitated by PRU-ICSS firmware utilizing dedicated General Purpose Input (GPI) and General Purpose Output (GPO) signals. These GPI and GPO signals are mapped to PRU registers and offer minimal latency, enabling real-time control of external peripherals through firmware. In this context, the GPI and GPO signals are leveraged to emulate an SPI interface.

The system employs a unified Serial Data Out (SDO) line from PRU-ICSS to all ADCs. This design choice permits simultaneous configuration of all ADCs with identical settings, essential for synchronized sampling. The PRU accesses the SDO line through the R30 register.

SPI lines 1 to 4 from each ADC are channeled into dedicated GPI lines on the PRU-ICSS, and these lines are read by the PRU firmware via the R31 register. The subsequent sections delve into the intricate process of converting the serial data stream from each SDI line into parallel 24-bit ADC data.

The Serial Clock (SCLK) signal is generated by the PRU-ICSS. Two options exist for generating SCLK:

• The PRU can manipulate the GPO via firmware to set and clear the line. This entails an active involvement of the PRU to manage the line's state.
• The Integrated Event Processor (IEP) timer independently generates the clock, decoupling the clock from PRU firmware activity.

This system implementation employs the IEP timer for generating SCLK.

The Return_SCLK signal serves as the clock signal for data sampling in the PRU firmware. Return_SCLK is derived from SCLK and transmitted over the high-speed connector. This choice proves advantageous when utilizing high-speed clocks above 10 MHz. Isolation devices introduce signal delays for all signals traversing the isolation barrier. Employing Return_SCLK for sampling permits the PRU-ICSS to capture the exact clock edge used by the ADC to output sampling data on the SDI lines, thereby achieving accurate data capture.

Figure 2-3 visually depicts the transfer of SCLK, Return_SCLK, and ADC data samples over the SDO lines. SDO1 to SDO4 and Return SCLK are input to the PRU-ICSS via GPIs. SCLK clock signal is generated via GPO in PRU-ICSS. Return SCLK is utilized by PRU firmware to capture SDO data bits.

Each ADC furnishes 24-bit data samples, comprising Least Significant Bit (LSB), Middle Bits (MID), and Most Significant Bit (MSB). These data samples are placed on the SDO lines using the SCLK clock signal. Thus, a continuous 24-clock cycle SCLK signal is necessary, prompting the ADCs to present all data samples on the SDO line.

The PRU firmware undertakes the subsequent tasks:

• Initiates SCLK clock output by enabling IEP SYNC output.
• Utilizes Return_SCLK to sample data bits across SDO1 to SDO4.
• Reorganizes the bit stream from each SDO line to construct a 24-bit ADC sample for each channel.
• Stores these 24-bit samples in a shared RAM data buffer.
• Upon filling the designated buffer, dispatches an event via the INTC to the ARM processor, triggering subsequent actions within the ARM application (such as FFT calculations).

Accessing the SDO lines directly involves utilizing bits b0 to b3 of register R31. PRU firmware samples data by copying and left-shifting the lower 8 data bits to register R2 (byte 0), as demonstrated in Figure 2-4. After sampling, the initial 1-bit of data for each channel is located in R2 from bit 4 to bit 7.

The PRU firmware executes the following task seen in Figure 2-5:

1. Waits for RET_SCLK to transition to 'high' before sampling MSB-1 in the subsequent step.
2. Awaits the RET_SCLK to go 'low' to perform data sampling.
3. Samples four SDO data bits by left-shifting 4 bytes and copying the outcome into register R2, byte 0. The color-coded cells depict the bit location of each ADC sample bit.
4. Awaits RET_SCLK to transition to 'high' again.
5. Waits for RET_SCLK to go 'low' before proceeding to sample MSB-2.
6. Samples the next four data bits by performing a logic OR operation between R31 byte 0 and R2 byte 0. The result of the OR operation is stored in R2 byte 0.
7. Prepares for lookup table access by left-shifting R2 by 2 bits.
8. Utilizes the 2-bit samples of each channel with the lookup table to rearrange them into consecutive 2 bits, using the sample bits as offsets for the lookup table. The memory access loads into register R3, showcasing the two consecutive bits for each channel.
9. Awaits RET_SCLK to transition to 'high'.
10. Left-shifts register R3 by two bits and stores the outcome in register R4.
11. Resets all values in register R2 to 0.
12. Repeats steps 3 to 9.
13. After repeating step 9, performs a logical OR operation between register R3 and R4, storing the result in R4. This step populates R4 with sorted MSB-1 to MSB-4 sample bits for each ADC channel.
14. Left-shifts register R4 by two bits and stores the result in R4.

1. Clears register R2.
2. Repeats steps 3 to 9, then repeats steps 13 to 15.
3. Repeats steps 3 to 9, then performs step 13. At this stage, R4 contains 8 bytes of data samples, sorted for each ADC channel.
4. Repeats steps 1 to 17 two more times. Clears R3 before next use. At this point, PRU has accumulated and sorted 24 bits of samples. A complete ADC sample for every ADC resides in PRU registers R4 to R6.
5. Transfers data bytes into individual registers, enabling the PRU to store each 24-bit sample, converted to 32-bit registers, in the ICSS shared memory. Please refer to Figure 2-6 for a visual representation of this process.

Following step 19, the PRU firmware executes four sbco instructions to store each 32-bit sample into the data buffer located in shared RAM. The PRU repeats this process, writing 32-bit data into the buffer multiple times until a complete sample buffer is filled. Please refer to Figure 2-7 for a visual representation of this process.

Figure 2-8 illustrates the comprehensive software flow of the entire system. Following the completion of the sample buffer, the PRU triggers an Interrupt Controller (INTC) event towards the ARM. The ARM core R5F-00 receives this event as an interrupt, subsequently performing Fast Fourier Transform (FFT) calculations on the ADC sample buffer. Once the FFT calculation concludes, the samples are passed to the second R5F-01 core. This core manages the creation of JSON formatting and the transmission of data via the MQTT protocol over the Single Pair Ethernet (SPE) connection. The ICSSG1 manages Ethernet transmission through the SPE port.

This iterative process is continually repeated for each ADC buffer. FFT calculations and raw ADC samples are efficiently conveyed over the Single Pair Ethernet to the gateway board.

ARM application

The application on the ARM processor is split across two ARM Cortex R5F cores for efficient processing and communication.

R5F Core 00:

• R5F Core 00 is responsible for initializing the MPU (Microprocessing Unit), which includes subsystem configuration settings. These configuration details are specified in the SYSCONFIG file.
• RF5 Core 00 handles tasks like pinmux configuration, device setup, PRU ADC firmware loading and initiation, and the provisioning of configuration data to the ADC board.
• RF5 Core 00 receives events from PRU-ICSSG0 and performs Fast Fourier Transformation (FFT).

R5F Core 01:

• R5F Core 01 receives events from Core 00.
• This core handles the conversion of processed data (raw ADC and FFT results) into a format for transmission. Specifically, the core performs JSON (JavaScript Object Notation) formatting of the data.
• JSON formatting is followed by data transmission over the Single Pair Ethernet (SPE) using the MQTT (Message Queuing Telemetry Transport) protocol.
• Core 01 makes sure that the data is packaged and transmitted effectively over the network, making the data accessible for visualization and analysis.
• The MAC (Media Access Control) layer operates on ICSSG1, facilitating the Ethernet communication.

In summary, the ARM application is structured to leverage the capabilities of two Cortex R5F cores efficiently. Core 00 handles initialization, configuration, and interaction with the ADC subsystem, while Core 01 is dedicated to data processing and communication. This leads to the efficient transmission of processed data over the network.