• State Resolved
  • Locked Locked
  • Replies 3 replies
  • Subscribers 100 subscribers
  • Views 722 views
  • Users 0 members are here
Support feedback
Options
Options
Similar topics

This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

[FAQ] Can the PRU implement my interface protocol?

Nick Saulnier
Guru* 87655 points
Part Number: AM625

I am using a TI processor with a PRU subsystem. I want to add an additional interface to my processor (e.g., UARTs, SPIs, I2S, etc), or a custom protocol (e.g., parallel SPIs, proprietary bus protocol, etc). Can I use the PRU cores to implement my interface or custom protocol?

.

For additional FAQs around PRU development, reference the Sitara multicore development and documentation FAQ.

  • +1
    TI__Guru* 87655 points

    Is bitbanging a protocol with PRU the right solution?

    The PRU was designed specifically so that it could be used to bitbang (i.e., directly toggle a GPO signal) protocols - that is why we made the core deterministic and placed the cores physically close to the pins they control within the processor package (giving low and guaranteed read/write signal latency). However, protocol development does take time and effort.

    Before deciding to develop a PRU protocol, I would ask:
    * Can one of the on-chip peripheral instances be used? (e.g., if just doing SPI communication, can the on-chip SPI be used?)
    * Can the core that will be using the information control that peripheral instance? (e.g. on AM62x, Linux A53, FreeRTOS R5 or FreeRTOS/bare metal M4?)
    * If not, could the PRU control the peripheral instance and then pass information to the core that will be using it?

    If the answer to all of those questions is "no", then I would start evaluating the PRU for protocol development.

    For example, if all that is needed is a SPI interface, then bitbanging with the PRU is probably not needed. But what if we needed to get ADC readings over SPI from multiple ADCs from exactly the same point in time? Then the PRU could be a good fit for controlling all ADCs and triggering simultaneous reads.

    Another usecase where bitbanging the PRU might make sense is if a read needs to be triggered immediately after receiving an external asynchronous signal. The PRU's very low latency reads and writes allow it to read in the external signal and respond much quicker than any other core on the chip.

  • +1 in reply to Nick Saulnier
    TI__Guru* 87655 points

    Ok, we want to evaluate whether the PRU is able to bitbang our protocol. Where do we start?

    There are several considerations the customer needs to keep in mind:

    1) Details of the protocol itself:
    * What is the protocol clock speed?
    * What steps will the PRU need to take to implement the protocol successfully? Since each step needs to be programmed, a more complex protocol may be unable to run at higher interface clock frequencies.

    (example: a while back I was doing proof-of-concept analysis for parallel I2S instances on a 200MHz PRU core. If all I2S instances shared the same frame sync signal, then the core could support about 8 I2S instances. However, if the PRU had to watch for a different frame sync signal for each instance, then additional assembly instructions were needed. Those extra assembly instructions reduced the max number of I2S instances from 8 to 2)

    2) PRU firmware:
    * Customers typically write bitbanging code in assembly so they can have direct control over all the timing
    * Different PRU cores run at different frequencies. e.g., AM335x PRU cores run at 5ns per instruction (200MHz), while AM62x PRU cores can run at 3ns, 4,ns, or 5ns per instruction (i.e., 200MHz, 250MHz, 333MHz). For more information on the max PRU frequency for each processor, reference the PRU Feature Comparison app note
    * Customers are responsible for writing and testing their firmware. TI can help with basic debug and development questions, but we cannot write or debug customer firmware.

    3) IPC requirements between PRU core & Linux?
    * Are there throughput / latency requirements here?
    * TI offers RPMsg as an out-of-the-box IPC solution. It is pretty easy to get working, and it is good enough for usecases where low latency and high throughput don't really matter (e.g., updating a human readable display). If RPMsg is not a good fit, then IPC may require some additional development on the customer side.

  • +1 in reply to Nick Saulnier
    TI__Guru* 87655 points

    Other useful examples & resources

    Most of our resources for bitbanging protocols are based on AM335x. For information on the hardware differences between the PRU subsystems in each processor, please reference the PRU Feature Comparison app note.

    General system design, & bitbanging SPI:
    https://www.ti.com/tool/TIDA-01555     has a pretty helpful design guide. Source code at https://git.ti.com/cgit/apps/tida01555

    Bitbanging UART:
    The source code for the soft UART is at https://e2e.ti.com/support/processors-group/processors/f/processors-forum/1039445/processor-sdk-am335x-iso7816-on-pru-of-am335x/3859860#3859860 
    The Linux driver information is at https://software-dl.ti.com/processor-sdk-linux/esd/docs/07_03_00_005/linux/Foundational_Components/PRU-ICSS/Linux_Drivers/pru-sw-uart.html 

    AM335x bitbanging with TI-RTOS drivers: I2C, IOLINK, eSPI
    Documentation & source code location here: https://software-dl.ti.com/processor-sdk-rtos/esd/docs/06_03_00_106/AM335X/rtos/index_pru_icss_fw.html#pru-icss-i2c 
    Note that AM335x TI-RTOS is no longer supported as per https://e2e.ti.com/support/processors-group/processors/f/processors-forum/1071334/notice-regarding-processor-sdk-ti-rtos-for-am335x-am437x-omap-l13x-c674x-k2g-devices . We will not be able to answer any questions about these resources.