3.4.1. Overview of PRU-ICSS and PRU_ICSSG

The Programmable Real-Time Unit Subsystem and Industrial Communication SubSystem (PRU-ICSS) consists of dual 32-bit RISC cores (Programmable Real-Time Units, or PRUs), data and instruction memories, internal peripheral modules, and an interrupt controller (INTC). The programmable nature of the PRU-ICSS, along with their access to pins, events and all SoC 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 system-on-chip (SoC).

The PRU-ICSS hardware can be used for two categories of applications:

  • General-purpose applications (using the PRU subsystem)
  • Industrial applications (using the ICSS)

This overview page serves as a hub for PRU subsystem collateral and related resources including software user guides, application notes, training modules, and FAQs.


3.4.1.2. Hardware Information

3.4.1.2.1. Technical Documentation

Technical documentation is provided in device-specific Technical Reference Manuals (TRMs).

3.4.1.2.3. Miscellaneous

PRU Read Latencies


3.4.1.4. Development Tools

3.4.1.4.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.

PRU Optimizing C/C++ Compiler User’s Guide

PRU Assembly Language Tools User’s Guide

3.4.1.4.2. PRU Assembly Instructions

PRU Assembly Instruction Guide


3.4.1.5. Software Information

3.4.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-ICSS / PRU_ICSSG” documentation.

For RTOS software information, reference the RTOS Processor SDK documentation.

3.4.1.5.1. Firmware Software Information

PRU-ICSS / PRU_ICSSG Migration Guide


3.4.1.6. Examples

Generic PRU Examples

PRU Software Support Package

Industrial Software (Industrial Drives) Examples with Firmware Source

PRU-ICSS Industrial Software for Sitara Processors

Reference “Industrial Drives” > “User Guide” > “Applications” for a list of example firmware.

Community Projects

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!

Note

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.


3.4.1.7. Evaluation Hardware

PRU evaluation hardware can be ordered from ti.com:


3.4.1.8. TI Designs

TI has created multiple TI Reference Designs around PRU applications. Perform a Quick Search to find PRU-based TI Designs like:


3.4.1.9. Support

TI supports PRU through the e2e forums.

The Beagleboard community discusses PRU here

PRU FAQ

FAQ for PRU-ICSS Industrial Software


3.4.1.10. PRU FAQ

3.4.1.10.1. PRU Applications & Support questions

3.4.1.10.1.1. What is the difference between the PRU subsystem and ICSS?

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 with ICE and IDK boards and Industrial Software Kit.

3.4.1.10.1.2. Is TI providing libraries for the PRU?

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.

3.4.1.10.1.3. Can I develop my own industrial protocols on the PRU-ICSS?

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.

3.4.1.10.1.4. Can the PRU run a High Level Operating System?

No, the PRU cannot run a HLOS such as Linux or Android.

3.4.1.10.1.5. My processor has a PRU. Is the PRU supported in the Linux Processor SDK?

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, AM64x, AM65x, and 66AK2G02 (K2G). More processors will be added in future releases.


3.4.1.10.2. PRU Memory Access questions

3.4.1.10.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].

3.4.1.10.2.2. In AM437x, why can PRU-ICSS0 not access memories outside of the ARM?

Make sure PRU-ICSS1’s OCP master port is enabled. PRU-ICSS0 accesses all external memories through the PRU-ICSS1 OCP master port.

3.4.1.10.2.3. Why can the PRU not edit pinmux settings?

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.


3.4.1.10.3. PRU GPI/O questions

3.4.1.10.3.1. What is the maximum speed for toggling PRU GPO pins via PRU software?

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.

3.4.1.10.3.2. When does the PRU start capturing from the input pins?

The PRU continually captures and shifts the input once the GPI mode is set to 28-bit shift mode.

3.4.1.10.3.3. Can the module be modified so that the GPI start bit is a zero instead of a one?

No, the GPI start bit flag only detects the first 1 captured.

3.4.1.10.3.4. What happens after 28 bit GPI shifts?

The shift register overflows into a bit bucket.

3.4.1.10.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.

3.4.1.10.3.6. When does PRU<n>_CLOCKOUT start running?

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.

3.4.1.10.3.7. When does the PRU start shifting data in the shadow registers?

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.

3.4.1.10.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.

3.4.1.10.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]).

3.4.1.10.3.10. Does the PRU shift data out LSB or MSB first?

The PRU shifts data out LSB first. PRU<n>_R30[0] = SH0/1[0] = LSB = first bit to be shifted out.

3.4.1.10.4. PRU INTC and System Event questions

3.4.1.10.4.1. How can a PRU core interrupt the ARM? How can the ARM interrupt a PRU core?

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.

3.4.1.10.4.2. On devices with multiple PRU-ICSSs, how can one PRU-ICSS interrupt the other?

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.


3.4.1.10.5. PRU Debugger questions

3.4.1.10.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.

3.4.1.10.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.