are any PRU progammers around, here ?

Hi Gus,

I read your white paper on using the PRU to implement various serial protocols such as SPI, I2C and CAN.

http://focus.ti.com/lit/wp/spry136/spry136.pdf

I have downloaded the PRU development system, but I do not see any serial protocol examples. In your white paper, you refer to the performance of a CAN implementation. Can you share the code for the CAN implementation?  I need to implement 4 SPI interfaces and 4 I2C interfaces but only 4 interfaces will be configured to run at any one time. Does TI have any examples of how to implement SPI and I2C with the PRU? If you don't have SPI or I2C, the perhaps I can adapt your CAN example.

Sorry for the delayed response, I was out of office last week. 

We don't have SPI or I2C examples, but these protocols are simple enough to bit bang and hence capable of being implemented using the PRU.  The SPI implementation should not be very complex.  You should be able to bit bang the SPI ports using the PRU & its output/input pins. Not sure what are your throughput requirements though.  The I2C implementation may be a little more difficult to implement given the arbitration requirements, but given its speed, should be doable.

We are working with a 3rd party to implement a CAN and UART example using the PRU.  Unfortunately that work has been delayed.  It should be available before the end of this month, if not before.  Most of the code will be very specific to those two peripherals, so not sure how much you will be able to reuse.  The CAN example uses bit banging, but there is a lot of code to meet all the requirements of this protocol (error detection, arbitration, CRC calculation, etc.).  The UART example is simpler, but leverages a serial port for the actual data transmission (the PRU prepares the code for transmission and receives the data).

Hi Gus,

Thank you for your response. I find this somewhat strange given that TI have promoted the PRU as a way to implement serial protocols and specifically naming SPI so I don't understand why TI would not implement a SPI example. Anyway, given this current situation, can you explain a little more about the environment in which these examples are run? Are these examples run on top of a Linux OS? If so, are there any specific drivers or modules that need to be installed? Will these examples work with CCSV4 or ARM's DS-5?

Given that the PRU does not have any I/O ports, do we implement the I2C SDA with both a input pin and and output pin tied together and just tristate the output when we are receiving? 

Finally, has TI characterized the performance of the PRU. For example, I'm trying to determine how many SPI channels I can support at 10mbps. 

Re: Linux: I can't speak for TI, but it's obvious that the PRU software is independent of the OS running on on the ARM. The firmware done on the PRU is considered as a hardware device by the ARM software. This (when doing it in the correct "Linux" way), an appropriate device driver would be done in Linux to have the user land software access the functions done using the PRU. This could be a driver compatible to other COM, accessed directly by the user land software,  to  support an UART done in the PRU or drivers compatible to the appropriate Linux internal bus abstractions "sub-systems" to support I²C or SPI functions done the the PRU.

With serial ports such as UART, SPI or I²C I suppose the PRU software would define some buffers somewhere in RAM that would hold the information to be transmitted/received and some Status/Command registers in REAM or in the PRU itself to create the interface to the ARM processor.

Of course the PRU does have bit banged I/O ports. The bits of R30 can be routed directly to Pins of the chip.

I suppose you need to do a test implementation of the critical loops in your PRU software to check if the PRU can do the work. Regarding SPI this obviously depends on the count of SPI interfaces you want to implement and on the count of PRUs you want to dedicate to that job.

With my task (a very propriety serial interface doing some 10 MBit/sec on a single line - a very little bit similar to Ethernet) I found that the limiting factor was not the PRU itself, but the dummy cycles the PRU suffers when accessing the chip's RAM resources (e.g. "L3").

-Michael

john3909 said:

can you explain a little more about the environment in which these examples are run? Are these examples run on top of a Linux OS? If so, are there any specific drivers or modules that need to be installed? Will these examples work with CCSV4 or ARM's DS-5?

john3909 said:

Given that the PRU does not have any I/O ports, do we implement the I2C SDA with both a input pin and and output pin tied together and just tristate the output when we are receiving?

john3909 said:

Finally, has TI characterized the performance of the PRU. For example, I'm trying to determine how many SPI channels I can support at 10mbps.

I need to spend some more time on this question.  Right now I am a bit tied up.  Here are some things that come to mind though:

- Definitely bit banging a 10MHz i/f is not going to be possible with the PRU.  For the clock alone, you would have 150MHz/10Mhz/2 = ~7 instruction cycles to toggle/sample a clock pin.  Pulling data from shared RAM or DDR RAM would definitely take longer than this.

- Another option is to use the audio serial port for the actual data transfer and the PRU for internal data formatting and movement. You could create a data stream that mimics a SPI clk & data output.  The audio pins could continuously stream data in and the PRU could extract the actual data from the stream.  This is what we are doing for the UART case. 

- The audio port is capable of reaching 10MHz rates, the question is whether or not the PRU can move data to/from it fast enough.  Data can be moved to the serial port 32 bits at a time, so the actual interrupt rate to the PRU is 20MHz/32 = 625kHz or 240 PRU instruction cycles (20MHz because data stream is 2x actual data rate to be able to generate a clock using a data stream).  Whether that is enough depends on the number of reads/writes to/from L3/L2/DDR memory and serial port registers.  I'm thinking one channel is doable, but more than that is a bit questionable.

Sorry, I know this is a non-answer, but hopefully it provides a better picture of how things are implemented on the PRU.  I'll try to get some more concrete latency numbers soon.

Michael Schnell said:

With serial ports such as UART, SPI or I²C I suppose the PRU software would define some buffers somewhere in RAM that would hold the information to be transmitted/received and some Status/Command registers in REAM or in the PRU itself to create the interface to the ARM processor.

This is correct.  The PRU can generate/receive interrupts to/from the ARM/DSP.  It also has internal memory which the DSP and ARM can access.  Of course the PRU can access all internal and external memory on the device.  The communication between the ARM/DSP and the PRU is totally up to the programmer.

Gus Martinez said:

The PRU on the AM1808/OMAPL138 does have I/O ports, please see the device data sheet.  On the AM1707/OMAPL137 the PRU does not have I/O ports.  However, both these devices the PRU can directly access the GPIO pins of the device.

I've looked at the AM1808 datasheet Section 3.7.8 and from the way I understand ti, PRUx_R30 are defined as Outputs (Table 3-10) and PRUx_R31 are defined as Inputs (Table 3.11). Am I missing something here? 

No, you are not.  The AM1808 PRU has dedicated input only and output only pins. 

Dears;

I got confused about this post.

The confusion is that when am1808 has 2 spi ports of higher speed; then why fooling around with PRU?

Can you please tell me if I am missing someting?

thanks for taking the time.

Ma

I needed more than two SPI ports. Also, one of the SPI ports is not available when Ethernet is used. I also needed more I2C interfaces. 

john3909 said:

I needed more than two SPI ports. Also, one of the SPI ports is not available when Ethernet is used. I also needed more I2C interfaces. 

Implementing a "bit-banged" SPI port in the PRU would be good enough for our needs.

We will also need to read the RTC in the main processor and implement a thread running in the PRU.

I have done "bit-banged" SPI before so I'm not worried about that, but are there any examples of creating a thread to run in one of the PRU's and any examples of the PRU accessing the RTC (or is the same access method as for the ARM)?