libpruio (BB D/A - I/O fast and easy)

External libraries (GTK, GSL, SDL, Allegro, OpenGL, etc) questions.
tenko
Posts: 3
Joined: Apr 13, 2018 6:18

Re: libpruio (BB D/A - I/O fast and easy)

Postby tenko » Jul 07, 2019 19:09

Hello,
Libpruio is a great tool that speeds up the development of our small and big projects, thank you for creating it!
I would like to use libruio to read and store the state of 12 pins from GPIO2 at the constant time interval of 20 us (50k samples per second). The common way to read multiple GPIO2 pins seems to be the use of io->Gpio->Raw[2]->Mix, but this has to run within a CPU loop and thus cannot be executed at the constant time intervals. The ring buffer RB mode is a great solution to read and store the analog lines at the constant time interval, but is it possible to use the RB for sampling and storing (in the ring buffer) the state of GPIO2? If yes, how to do it? I could not find any examples on that…
Thank you for your advice.
TJF
Posts: 3570
Joined: Dec 06, 2009 22:27
Location: N47°, E15°
Contact:

Re: libpruio (BB D/A - I/O fast and easy)

Postby TJF » Jul 08, 2019 14:21

Hi tenko, welcome to the forum!

Sorry, there's no feature for mixed (GPIO/ADC) data in the ring buffer. This'd lead to complex code for data readings. (Some users are overhelmed by only reading the ADC values.)

Anyhow, as you mentioned the Mix member variable serves all GPIO states at one GPIO SS: 32 bit with some latency depending on the OCP port load and the enabled GPIO SS.

For me the main question is: do you just need to grab the data, or do you also need to evaluate them for a closed loop controller? Only grabbing may be possible by the ARM, when no further load comes from the kernel. In any other case, even for high reliability, I'd use the other PRU for that purpose. By direct access to the GPIO SS you can also reduce/suppress the libpruio latency on the GPIO-2 state (~160 us).

Ie. you could make the ring buffer smaller than the ERam and use its upper end for the GPIO data (high load on OCP). Or perhaps the SRam is big enough for your data (12 kB = 6000 values, or 9000 when packed). For your code this means configuring the pinmuxing as usual by libpruio, and then upload and start a small firmware on the other PRU just for fetching the data, synchronized with the PRU running libpruio.

Regards
tenko
Posts: 3
Joined: Apr 13, 2018 6:18

Re: libpruio (BB D/A - I/O fast and easy)

Postby tenko » Jul 08, 2019 21:33

Thank you TJF for the advise,
I just need to grab the data, I will think about the options you have mentioned.
Thanks a lot!
TJF
Posts: 3570
Joined: Dec 06, 2009 22:27
Location: N47°, E15°
Contact:

Re: libpruio (BB D/A - I/O fast and easy)

Postby TJF » Jul 09, 2019 5:00

You're welcome!

In RB mode you can synchronize the second PRU in the same way as synchronizing the ARM: observe DRam[0], which is address 0x2000 for the second PRU.

Note: that address is used for each (pinmuxing) operation, and reset to 0 (zero) afterwards:
  • First finish all configurations.
  • Then (upload and) start the second PRU firmware.
  • Last, call function PruIo.rb_start().
[Edit]Also, in the last step DRam[0] is used. First it contains high values (> 0xffff ff00), and ADC fetching starts when the value drops down to 0 (zero).[/Edit]

Good luck!

PS: Instead of GPIO-2 inputs you could also use fast PRU-GPIO inputs (reducing the OCP port load). For PRU-1 you can find 12 header pins on P8 (when HDMI is disabled). For PRU-0 there're only 11 header pins on P9, but 5 further pins on the SD-card slot. Find details at http://users.freebasic-portal.de/tjf/Pr ... SecPruGpio, and example code in http://users.freebasic-portal.de/tjf/Pr ... aPruToggle
tenko
Posts: 3
Joined: Apr 13, 2018 6:18

Re: libpruio (BB D/A - I/O fast and easy)

Postby tenko » Jul 09, 2019 5:33

Thank you so much TJF, this is all very useful information and I will be exploring it.
Dinosaur
Posts: 1342
Joined: Jul 24, 2005 1:13
Location: Hervey Bay
Contact:

Re: libpruio (BB D/A - I/O fast and easy)

Postby Dinosaur » Apr 18, 2020 5:34

Hi TJF

I am still involved with BBB projects and using your library.

Installing the development system on a new desktop hdd that has Debian 10.
When I try to update the sources list I get the first error.
root@debian:/home/dinosaur# wget -qO - http://beagle.tuks.nl/debian/public.key | sudo apt-key add -
gpg: no valid OpenPGP data found.
The next error:
oot@debian:/home/dinosaur# sudo apt-get install libpruio-dev # development in C programming language
E: Malformed entry 1 in list file /etc/apt/sources.list.d/tuks.nl.list (Component)
E: The list of sources could not be read.
E: Malformed entry 1 in list file /etc/apt/sources.list.d/tuks.nl.list (Component)
E: The list of sources could not be read.
After that I can't even use Synaptic, unless I delete the tuks.nl.list

Debian is without a doubt the most painful of Linux distro's, however I suspected that the 'debian jessie' was to blame.
Contents of tuks.nl.list
But deleting the jessie part did not solve the problem.

Have you come across this ?

EDIT: Note another file entry for comparison.
TJF
Posts: 3570
Joined: Dec 06, 2009 22:27
Location: N47°, E15°
Contact:

Re: libpruio (BB D/A - I/O fast and easy)

Postby TJF » Apr 18, 2020 8:22

Sorry, I didn't test Debian10 yet. I'm neither a pgp nor a PPA expert.

Why don't you compile from source?
TJF
Posts: 3570
Joined: Dec 06, 2009 22:27
Location: N47°, E15°
Contact:

Re: libpruio (BB D/A - I/O fast and easy)

Postby TJF » Apr 19, 2020 16:18

BTW, there's an other user who solved a similar problem. Find details at

https://groups.google.com/d/msg/beagleb ... pd4i-sAQAJ
Dinosaur
Posts: 1342
Joined: Jul 24, 2005 1:13
Location: Hervey Bay
Contact:

Re: libpruio (BB D/A - I/O fast and easy)

Postby Dinosaur » Jun 29, 2020 22:16

Hi All

TJF, I have given up on Debian 10, just to many complications for to little gain.

I am implementing a RTC using I2C , but want to use it together with Libpruio GPIO control.
Can you see any problems with using a library like iobb whilst controlling gpio with libpruio ?

I am waiting for the boards to arrive, but so far I am able to initialize , Configure the pins, open & read (without a board connected)
and still drive IO with libpruio.
If in your experience there are problems, then I will use I2C from the command line as I will only use it once per day to verify the time.
I can even do that before the libpruio is used.

Regards
TJF
Posts: 3570
Joined: Dec 06, 2009 22:27
Location: N47°, E15°
Contact:

Re: libpruio (BB D/A - I/O fast and easy)

Postby TJF » Jun 30, 2020 8:09

Dinosaur wrote:Hi All

TJF, I have given up on Debian 10, just to many complications for to little gain.

I am implementing a RTC using I2C , but want to use it together with Libpruio GPIO control.
Can you see any problems with using a library like iobb whilst controlling gpio with libpruio ?

I am waiting for the boards to arrive, but so far I am able to initialize , Configure the pins, open & read (without a board connected)
and still drive IO with libpruio.
If in your experience there are problems, then I will use I2C from the command line as I will only use it once per day to verify the time.
I can even do that before the libpruio is used.

Regards

For I2C it needs a kernel driver (AFAIK). So I'd try to configure (only) the I2C pins by a regular device tree blob. And claim all further pins for libpruio control.

I never tried iobb. But if it's a serious library, it shouldn't interfere with libpruio.

Regards

Return to “Libraries”

Who is online

Users browsing this forum: No registered users and 4 guests