• State Answer Suggested
  • Locked Locked
  • Replies 5 replies
  • Answers 1 answer
  • Subscribers 102 subscribers
  • Views 813 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.

PRU Driver

bwilcutt
Intellectual 310 points

I would like to write a special driver that extends A-to-D functions of an external chip.  This chip will be connected to the Am335x PRU units.  Ultimately, I want to be able to get-set-and-check programs to the PRU and read-write data to the A-to-D chip.   I've been able to write a driver but getting it to connect to the PRU has not been a pleasant experience [yes, I'm using device tree].  

I'd like to get the uio_pruss.c driver to to be the go-between the processor and the PRU and my device driver would be the go-between the PRU and the external A-to-D processor.

Anyone have any tips on how I should approach this?

  • 0
    TI__Guru**** 393215 points
    Hi Bryan,

    I will ask the PRU experts to comment.
  • 0 in reply to Biser Gatchev-XID
    Intellectual 310 points

    Thanks, Biser.

    What we're trying to do is make a device tree driver that talks to an MCP3202 a/d converter which is jury rigged onto a beaglebone board.  I'd like to be able to tell the mpc3202 driver to load the PRUs and to instruct the PRUs to start/stop as well as send frequency information.  The PRUs would then read values from the mcp3202 and I can retrieve those values through a sys/class variable.  Pretty simple stuff on paper but in implementation it presents a number of challenges.

    Thanks again...

  • 0 in reply to bwilcutt
    TI__Genius 10415 points

    Bryan,

    The TI supported method for loading/running the PRU cores is the pruss_remoteproc (drivers/remoteproc/pruss_remoteproc.c) kernel driver. This driver takes user-provided PRU firmwares and loads them into the PRUs and runs them.

    We also provide IPC between the ARM running Linux and the PRUs using another mechanism called RPMsg. From the ARM Linux perspective, a character device is created (e.g. /dev/rpmsg_pru30) that can be written to in order to send messages to the PRU and read from in order to receive messages from the PRU.

    Check out the Hands-on Labs on our PRU-ICSS wiki. Pay close attention to labs 4, 5 and 6 for the pruss_remoteproc and rpmsg examples. You should be able to begin with one of the RPMsg examples as a starting point for your project. You'll just need to add code to the PRU firmware that will control the ADC and then pass the sample data up to the Linux character device using RPMsg.

    Jason Reeder

  • 0 in reply to Jason Reeder
    Intellectual 310 points

    Jason,

    Thank you for responding so quickly.  One last follow up question.

    I have a uio_pruss and a pruss-rproc.   Dump the uio and keep the rproc?   The UIO has been a bane in my backside for 3 weeks!   I inherited this Linux build so I don't know why both are there or if they should be.

    Thanks,

    Bryan

  • 0 in reply to bwilcutt
    TI__Genius 10415 points

    Bryan,

    The uio_pruss and pruss-rproc drivers both attempt to achieve largely the same goals of loading the PRU cores with firmware and then running them. There may be some use cases where it would make sense to use both (one for firmware loading/running and the other for IPC) but I don't think that this is one of them. 

    My recommendation would be to spend a few hours going through the Hands-on Labs that I mentioned above. Labs 5 and 6 should give you a very good starting point for your project and with a bit of testing from there you should be able to see if the RPMsg IPC performance will be enough to support your ADC use case.

    Jason Reeder