PRU and LCD display on one BBB

GoogleGroups
1

Hi,
I am starting to play with PRU on BBB, and I noticed, that when I want to use PRU on BBB and on the same time use LCD display through GPIO, i cant (they use the same pins). Is there any workarounds?
Thanks a lot

2

Hi,
I am starting to play with PRU on BBB, and I noticed, that when I want to use PRU on BBB and on the same time use LCD display through GPIO, i cant (they use the same pins). Is there any workarounds?

Thanks a lot

I suppose that depends on how far you’re willing to go, and changes you’re willing to make. You can buy a different LCD screen, and perhaps even type of screen that uses different peripherals.

But you can start by telling us which LCD screen you’re using, and being more verbose as to how this LCD is connected. exactly which pins are required, etc.

3

I have this LCD screen and it user most of the second PRU pins and one of the first PRU unit. I am not sure, if this is problem or not.

Dne pátek 6. května 2016 17:59:11 UTC+2 William Hermans napsal(a):

4

Ok, so, I do not have time to read through all the literature for that screen. Which pins does it use, what is the specific function of each pin, and what “protocol” does the screen use ?

Is it one of those modified 9pin SPI + GPIO screens ?

5

Sorry, i send the wrong link. On this link, there is a picture, where you can see precisely which pin it is using

Dne pátek 6. května 2016 18:12:17 UTC+2 William Hermans napsal(a):

6

Better yet, I’ll tell you what’s better to do. Contact the manufacturer of that screen, and ask what you’re options are.

If you’re lucky, it could be possible to rewrite the device tree overlay file for that screen to work using alternate pins.

If you’re unlucky, you’ll have to buy a different kind of screen.

7

Ok. Great. Thanks for your time.

Dne pátek 6. května 2016 18:21:47 UTC+2 William Hermans napsal(a):

8

I have another Question on PRUs. It has 9 pins for first PRU and 15 pins for the second PRU (according to this schematic). Is there any option to expand number of pins, which I cand use by the PRUs?

Dne pátek 6. května 2016 18:25:14 UTC+2 Robert Jonathan Šimon napsal(a):

9

Decide what features you do not need, like LCD, Ethernet, etc, and redesign the board by removing those features, freeing up the pins to use them as PRU pins.

Gerald

10

Robert,

What do you need or want to use the PRUs for ? These pins you’re talking about are probably shared with the HDMI pins, but are not the only pins the PRU have access to. These pins are probably the pins the single cycle(5ms) access to

, where the PRU’s can access any pin on the board, just not with single cycle access. More like 3+ cycles if memory serves correctly.

My answers this morning did not include this earlier because I was not quite awake yet. . .

11

Robert,

What do you need or want to use the PRUs for ? These pins you’re talking about are probably shared with the HDMI pins, but are not the only pins the PRU have access to. These pins are probably the pins the single cycle(5ms) access to

, where the PRU’s can access any pin on the board, just not with single cycle access. More like 3+ cycles if memory serves correctly.

My answers this morning did not include this earlier because I was not quite awake yet. . .

Put more acurately.

  • The pins you’re asking about are shared with the header pins for the HDMI framer.
  • Your LCD uses HDMI, so in order to use those pins, you would have to disable HDMI.
  • The PRUs can access any GPIO pin on the board, but the ones shared with HDMI( and a few others ) can be accessed by the PRU in a single PRU cycle - 5ms.
  • The rest of the pins can still be accesses by the PRU’s, just with a higher access latency. 3-5 cycles if I remember right.

So to solve this problem of yours, you have some options. Disable the HDMI pins, and re-enable for PRU GPIO access, for full speed GPIO, or use different pins and access the pin slower . . .Or perhaps the remaining single cycle access pins raming for PRU0 / PRU1 are enough for what you need ?

So again, I ask. WHat ddo you need the PRU’s for ? :wink:

12

“raming” = remaing

I honestly think my keyboard is failing . . .

13

Thanks for your extensive answers, that was precisely what i needed, and could not find. Just to be sure - 1 PRU cycle is 5ns right? Not 5ms.
I will be building a simple car robot, just to get familiar with PRUs on BBB, than to go to heavier tasks. So I am very thankful for your answer :slight_smile: it help me a lot, to know what PRU are capable off.

Dne pátek 6. května 2016 22:13:56 UTC+2 William Hermans napsal(a):

14

Thanks for your extensive answers, that was precisely what i needed, and could not find. Just to be sure - 1 PRU cycle is 5ns right? Not 5ms.I will be building a simple car robot, just to get familiar with PRUs on BBB, than to go to heavier tasks. So I am very thankful for your answer :slight_smile: it help me a lot, to know what PRU are capable off.

Yes, nice catch. 5ns. I’m multi tasking. Reading, responding to posts, writing code, and researching stuff I plan on implementing into my code too . . . so no wonder I make mistakes :wink:

Also the PRU can access all onchip hardware modules, like the ADC, SPI, and pretty sure I2C as well. Among other modules . . .

15

SO here, maybe you’ve seen this, maybe not. https://groups.google.com/forum/#!category-topic/beagleboard/newbies/u28ytaoNenU

One thing that might help you understand how the PRU’s can access the other peripherals, and even DDR3 memory, is if you understand how /dev/mem/ and mmap() work to do the same task. All, you need to do it “poke” certain addresses in memory, to manipulate the various peripherals. Except, the PRU’s can do this independent of the main ARM processor. Which is a huge benefit, and often can be though of as a hardware offload mechanism.