3.6.1. Overview of PRU Subsystem¶
The Programmable Real-time Unit (PRU) is a 32-bit RISC processor core that is tightly integrated with an IO subsystem, offering low-latency control of IO pins. The TI Sitara family of devices offer three flavors of PRU Subsystem.
PRU-ICSS: The Programmable Real-time Unit and Industrial Communication Subsystem
The Programmable Real-time Unit and Industrial Communication Subsystem (PRU-ICSS) consists of dual 32- bit RISC cores (the PRUs), shared data, instruction memories, internal peripheral modules, and an interrupt controller (INTC). The programmable nature of the PRU, along with its access to pins (IOs), events and all System-on-Chip (SoC) resources, provides flexibility in implementing fast real-time responses, specialized data handling operations, custom peripheral interfaces, and in off-loading tasks from the other processor cores of the SoC.
Devices offering the PRU-ICSS capability include AM335x, AM437x, AM57x and K2G.
PRU_ICSSG: The Programmable Real-time Unit and Industrial Communication Subsystem - Gigabit
The Programmable Real-time Unit and Industrial Communication Subsystem - Gigabit (PRU_ICSSG) can be considered a superset of the PRU-ICSS. In addition to all PRU-ICSS features, the PRU_ICSSG adds two Auxiliary Programmable Real-Time Unit (RTU) cores, two Transmit PRU (TX_PRU) cores, broadside memories, improved event management with the task manager, data processing and data movement accelerators, and new peripherals such as PWM.
Devices offering the PRU_ICSSG capability include AM24x, AM64x, and AM65x.
PRU-SS: The Programmable Real-time Unit Subsystem
The Programmable Real-time Unit Subsystem (PRU-SS) consists of dual 32-bit RISC cores (the PRUs), shared data, instruction memories, internal peripheral modules, and an interrupt controller (INTC). The programmable nature of the PRU cores, along with their access to pins, events and all device resources, provides flexibility in implementing fast real-time responses, specialized data handling operations, custom peripheral interfaces, and in offloading tasks from the other processor cores of the device.
Industrial Communication Subsystem features including Ethernet (MII signals and MDIO signals are not pinned out) are not supported.
Devices offering the PRU-SS capability include AM62x.
The PRU subsystem hardware can be used for two categories of applications:
- General-purpose applications (using the PRU subsystem)
- Industrial applications (using the ICSS on applicable processors)
- See Evaluation Hardware for supported boards
This overview page serves as a hub for PRU subsystem collateral and related resources including software user guides, application notes, training modules, and FAQs.
Detailed information for getting started with PRU development can be found here:
188.8.131.52.1. Technical Documentation¶
Technical documentation is provided in device-specific Technical Reference Manuals (TRMs).
184.108.40.206.2. PRU Differences Between Devices¶
220.127.116.11.1. PRU C Compiler¶
PRU C compiler is available for download through the Code Composer Studio (CCS) App Center, or through the PRU-CGT page.
3.6.1. Linux Software information¶
RemoteProc driver information at RemoteProc
Information about general purpose Ethernet over PRU is at PRU_ICSSG Ethernet.
Other information about PRU development can be found throughout this “PRU Subsystem” documentation.
For RTOS software information, reference the RTOS Processor SDK documentation.
Generic PRU Examples
Industrial Software (Industrial Drives) Examples with Firmware Source
Reference “Industrial Drives” > “User Guide” > “Applications” for a list of example firmware.
The open source community has developed an incredible range of PRU projects:
- beagleboard.org has a wide range of hardware, tutorials, and open source projects
- Many individuals have posted projects and tutorials across the web on github.com, element14.com, and more. Interested in using PRU to control a printer, a stepper motor, or something else? Try typing “PRU beaglebone <search term>” into your web search engine and see what you can find!
TI cannot support community projects on the TI forums. For example, if a beagleboard.org tutorial is confusing, or a github project does not work as expected, please reach out to those communities directly for guidance. Some community projects use tools and software that TI does not support, like PASM or custom Linux drivers.
PRU evaluation hardware can be ordered from ti.com:
TI has created multiple TI Reference Designs around PRU applications. Perform a Quick Search to find PRU-based TI Designs like:
TI supports PRU through the e2e forums.
The Beagleboard community discusses PRU here
- PRU Applications & Support questions
- PRU Memory Access questions
- PRU GPI/O questions
- What is the maximum speed for toggling PRU GPO pins via PRU software?
- When does the PRU start capturing from the input pins?
- Can the module be modified so that the GPI start bit is a zero instead of a one?
- What happens after 28 bit GPI shifts?
- Can data be pre-loaded into shadow registers prior to configuring the PRU GPO mode to shift out mode?
- When does PRU<n>_CLOCKOUT start running?
- When does the PRU start shifting data in the shadow registers?
- The shadow registers are loaded by writing to PRU<n>_R30 [0:15]. Does this change the state of the corresponding device-level pins?
- When the PRU<n>_ENABLE_SHIFT bit is cleared, does the PRU immediately stop shifting PRU<n>_DATAOUT?
- Does the PRU shift data out LSB or MSB first?
- What happens to the content stored in R30 when the PRU changes to a different GPO mode?
- PRU INTC and System Event questions
- PRU Debugger questions
PRU subsystem and ICSS both refer to the same hardware (PRU-ICSS), but their distinction lies in the targeted applications. The term “PRU subsystem” is used for broad market (or non-industrial) applications, while the term “ICSS” is used for industrial applications. The ICSS is supported on applicable processors with ICE and IDK boards and Industrial Software Kit.
TI is not providing libraries for the PRU. Customers will need to develop their own PRU firmware. However, TI does provide the foundation for PRU development through example software and other resources available through the PRU-ICSS SDK Documentation.
One exception is the ICSS firmware supported with the ICE and IDK boards.
TI only supports the industrial protocols enabled in the IDK (Industrial Development Kit) available on ti.com. Independent development of industrial protocols using the MII_RT and IEP (Industrial Ethernet Peripheral) blocks in not supported or enabled.
No, the PRU cannot run a HLOS such as Linux or Android.
It depends. OMAP138 PRU is NOT supported in Processor SDKs, and there are no plans to add support for it. However, the latest Processor SDKs support general purpose PRU development for AM335x/AMIC110, AM437x/AMIC120, AM57x, AM243x, AM62x, AM64x, and AM65x. More processors will be added in future releases.
18.104.22.168.2.1. Why does my PRU firmware hang when reading or writing to an address external to the PRU Subsystem?¶
The OCP master port is in standby and needs to be enabled in the PRU-ICSS CFG register space, SYSCFG[STANDBY_INIT].
Make sure PRU-ICSS1’s OCP master port is enabled. PRU-ICSS0 accesses all external memories through the PRU-ICSS1 OCP master port.
The PRU does not have privileges to edit the pinmux or pad config settings in the device-level Control Module. However, the PRU can read these registers.
The max PRU IO speed depends on the PRU software executing on the PRU and is therefore not published.
For example, if the PRU software contained a tight loop that only toggled a PRU GPO pin, then the fastest 50% duty cycle square wave we could achieve would be 50 MHz. This is based on a 4 instruction loop (1. SET output, 2. NOP, 3. CLEAR output, 4. LOOP back to Set instruction) with the PRU running at 200 MHz. However, if the PRU needed to do any processing in addition to toggling the GPO, then that max speed starts decreasing with the number of PRU instructions that are executed between the GPO toggles.
The PRU continually captures and shifts the input once the GPI mode is set to 28-bit shift mode.
No, the GPI start bit flag only detects the first 1 captured.
The shift register overflows into a bit bucket.
22.214.171.124.3.5. Can data be pre-loaded into shadow registers prior to configuring the PRU GPO mode to shift out mode?¶
Yes, data can be loaded into the shadow registers even when the PRU is configured for a different GPO mode by setting PRU<n>_LOAD_GPO_SH0/1. Note for AM335x, PRU<n>_LOAD_GPO_SH0/1 corresponds to pru<n>_r30[29/30]. Please refer to the technical reference manuals for other devices to confirm how PRU<n>_LOAD_GPO_SH0/1 is mapped.
PRU<n>_CLOCKOUT is a free-running clock that begins when the PRU GPO mode is set to shift out mode. It is independent of PRU<n>_ENABLE_SHIFT.
The PRU starts shifting data as soon as the PRU<n>_ENABLE_SHIFT bit is set, regardless of the configured GPO mode. The output on PRU<n>_DATAOUT would only be seen if in shift out mode, but the shadow registers would still “drain” when in other GPO modes.
126.96.36.199.3.8. The shadow registers are loaded by writing to PRU<n>_R30 [0:15]. Does this change the state of the corresponding device-level pins?¶
If any device-level pins mapped to PRU<n>_R30 [2:15] are configured for the PRU<n>_R30 [2:15] pinmux setting, then yes, these pins will reflect the value written to PRU<n>_R30. Any pin configured for a different pinmux setting will not reflect the value written to PRU<n>_R30.
188.8.131.52.3.9. When the PRU<n>_ENABLE_SHIFT bit is cleared, does the PRU immediately stop shifting PRU<n>_DATAOUT?¶
No, when the shift operation is disabled by clearing the PRU<n>_ENABLE_SHIFT bit, the PRU will continue shifting all the data loaded in the shadow register used for GPO shifting (i.e. GPCFG0/1[PRU0/1_GPO_SH_SEL]).
The PRU shifts data out LSB first. PRU<n>_R30 = SH0/1 = LSB = first bit to be shifted out.
184.108.40.206.3.11. What happens to the content stored in R30 when the PRU changes to a different GPO mode?¶
R30 holds state when changing between GPO modes.
The PRU can interrupt the ARM by writing to R31 and generating a system event. The PRU INTC should be pre-configured to map this system event to a Host interrupt that is connected to the ARM (ie Host 2-9 on AM335x). The ARM can interrupt a PRU by writing to the PRU INTC SRSRx register and setting a pr<k>_pru_mst_intr<x>_intr_req system event. The PRU INTC should be pre-configured to map this system event to a Host interrupt that is connected to the PRU (ie Host 0-1 on AM335x). The PRU can poll R31 bit 30 or 31 to detect an interrupt on Host 0 or 1, respectively.
Check the PRU-ICSS System Event table in your device-specific reference manual on ti.com. There will be a System event tied to a PRU Host event from the other PRU-ICSS. By generating an interrupt of this Host, one PRU-ICSS can interrupt another PRU-ICSS. The other PRU-ICSS will detect this interrupt as the corresponding System event.
For example, on AM437x, the PRU can generate an interrupt on Host 7. The other PRU-ICSS will receive this as system event 56.
220.127.116.11.5.1. When using the XDS510 USB emulator, why does the PRU Program Counter not increment correctly when stepping through PRU Disassembly code?¶
There is a known bug associated with PRU debug in the XDS510 USB class driver, and a different emulator should be used to debug the PRU. Two good alternatives are the XDS200 or the XDS560v2 emulators. Comparative benchmarks for various classes of XDS emulators are available at XDS_Performance_comparison.
18.104.22.168.5.2. Why are no MMRs outside the PRU subsystem visible from the PRU perspective memory browser window in CCS?¶
The PRU core is capable of writing to the 32 bit memory map (i.e. MMRs outside of the PRU subsystem) but the PRU perspective of the CCS memory browser just cannot show those addresses. To view the full 32 bit memory map in a memory browser in CCS, the ARM core perspective or the DAP (debug access port) perspective should be used.
Note the PRU perspective memory browser includes a drop-down menu for viewing the following memories:
- Program_Memory - Instruction ram for the PRU
- Data_Memory - Data ram for the PRU
- PRU_Device_Memory - The memory map inside the PRU subsystem starting with the base address of the shared memory (0x00010000). Includes PRU shared memory and all submodules inside the PRU subsystem.