Re: Beaglebone: Bidirectional bus with PRU-ICSS

[Lyren Brown]

Brandon,

Thanks for the response. I should have updated this thread when I learned from Alexander Haim that muxing requires privilege. [1]

Unfortunately interrupt latency would have been too large for my use case, so I used external muxes instead. I posted a write up the beagleboard group. [2]

I was also pleased to learn other people found my work useful.

Matt Porter referenced my abx project in his presentation at the Embedded Linux Conference. [3] [4]

boxysean wrote a post about PRU usage that referenced this very thread. [5]

I think I even see vestiges of the code from this thread in Elias Bakken's replicape PRU code. [6] [7]

I love the power of the PRU and I love to see new applications. Sounds like you have something in the works.

Cheers,

Lyren

[1] http://www.alexanderhiam.com/tutorials/beaglebone-io-using-python-mmap/#comment-53

[2] https://groups.google.com/forum/?fromgroups=#!topic/beagleboard/NF8zKl29HYk

[3] http://forum.6502.org/viewtopic.php?f=4&t=2331

[4] http://blogs.mentor.com/chrishallinan/blog/2012/11/21/beaglebone-and-6502-the-ultimate-geek-toys/

[5] http://blog.boxysean.com/2012/08/12/first-steps-with-the-beaglebone-pru/

[6] http://hipstercircuits.com/?p=351

[7] https://bitbucket.org/intelligentagent/replicape/src/4f8d3f0001364a0a6b6f5a0ed0d4a03ae06a4bbe/firmware/firmware_pru_0.p

On Thursday, March 7, 2013 5:37:27 PM UTC-6, brando...@gmail.com wrote:

Even though the PRU can access system memory, writes to the MUX settings require "privileged" (meaning kernel) access. So, no, it's not possible to change the mux from the PRU. But, you can use the PRU to trigger an interrupt, which can be handled by something in userspace (using UIO and the uio_pruss driver) or kernel space (with your own kernel driver) to change the pin mux, and then signal the PRU that the change has been made. Easiest way to signal the PRU would be a memory write to the pru data block that the pru would sit and poll.

On Monday, June 25, 2012 1:49:37 AM UTC-7, Lyren Brown wrote:

Is it possible to alternate reads and writes from the PRU-ICSS to an external bidirectional bus?

[Juanjo]

I've using the PRU with success to read a PCM audio stream from a 3G modem using uio_pru. That way I can leave McASP0 for the audio cape or other codec (since McASP1 isn't exposed on BB)

My PRU code reads the serial stream and signal with an interrupt when the buffer is half or full (circular buffer) then a thread in userspace code reads the buffer.

The only weird thing I've noted that I get exactly two (2) UIO events (the library just block reads /dev/uio) per PRU interrupt. It seems this only happens using UIO.

I use two UIO interrupts one for buffer signaling and the usual end of execution interrupt.

[Juanjo]

Yes thanks to them. And someone even posted the patch on the official git repo but maintainer hasn't applied it.

On Sunday, April 28, 2013 12:55:13 PM UTC-4, Brandon I wrote:

The only weird thing I've noted that I get exactly two (2) UIO events (the library just block reads /dev/uio) per PRU interrupt. It seems this only happens using UIO.

The awesome guy at Hipstercircuits covered the double PRU interrupt bug recently: http://hipstercircuits.com/prussdrv-bug/

[a.hi...@gmail.com]

Hi Juanjo, what performance in terms of resolution, latency and sample rate did you push through it? And do you think one could sample one signal with higher precision by somehow sampling the lower part with 12bit and sequentially the upper part with 12bit?