search

scapri / first-githubtest

Just a quick repo to learn the basics of GitHub
0 stars 0 forks source link

Beaglebone black SBC #2

Open scapri opened 7 years ago

scapri commented 7 years ago

beaglebone black - 2 RT processors - but the main Linux processor is a single core A8. So even though the 2 RTs give plenty of help for bit banging, the app processor isn't very powerful. But is it enough for this project?

scapri commented 7 years ago

Still trying to see if I can write to the gpios with one of the 2 RT processors - only certain ones have access to certain gpios with high speed.

Wed Jan 4 - was able to use PRU0 to write the GPIO P8_12 (with the R30 register). I found out that delay_cycles is using the cycle speed of the PRU processor (5ns). Therefore 1usec = __delay_cycles(200).

scapri commented 7 years ago

Need to investigate how interrupts work in PRU - I believe we would poll a GPIO. Should I use a different PRU for this, and communicate to the other PRU? (if not, I can't use delay_cycles for the pulse width if we are having to poll).

Thursday Jan 5 - Yes it appears that the PRU just needs to read the GPIO in the loop. This means that a single __delay_cycles() call isn't sufficient - I have made the delay a 1usec delay for now, and when that is complete, read the input gpio to see if the "interrupt" has come in. Note that having a smaller delay means that the rest of the instructions in the loop will have a bigger impact on the delay time, but looking at the generated assembly code should tell how many cycles to subtract from the delay. 1usec didn't seem to have much problem, but 1/2usec or 100ns definitely showed the difference.

scapri commented 7 years ago

Need to investigate communication to Linux driver space - the driver will be the one telling the PRU to do a pulse, and what the width should be.

There is discussion http://www.righto.com/2016/09/how-to-run-c-programs-on-beaglebones.html about using interrupts (to bit 31 of __R31 for both PRUs to allow the Linux side to talk to the PRUs, and the PRUs can generate interrupts as well - but hopefully that's not the only way.

A good recent thread is here at: https://groups.google.com/forum/#!category-topic/beagleboard/HogqgKnxcg0 discussion about using rpmsg and remote proc to communicate back and forth - although the discussion is about transferring lots of data (we need just small amounts of data), there's lots of good stuff there.