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

Headers, Bindings, Libraries for use with FreeBASIC, Please include example of use to help ensure they are tested and usable.
Post Reply
tenko
Posts: 3
Joined: Apr 13, 2018 6:18

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

Post by tenko »

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: 3809
Joined: Dec 06, 2009 22:27
Location: N47°, E15°
Contact:

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

Post by TJF »

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)

Post by tenko »

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: 3809
Joined: Dec 06, 2009 22:27
Location: N47°, E15°
Contact:

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

Post by TJF »

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)

Post by tenko »

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

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

Post by Dinosaur »

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: 3809
Joined: Dec 06, 2009 22:27
Location: N47°, E15°
Contact:

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

Post by TJF »

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: 3809
Joined: Dec 06, 2009 22:27
Location: N47°, E15°
Contact:

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

Post by TJF »

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: 1478
Joined: Jul 24, 2005 1:13
Location: Hervey Bay (.au)

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

Post by Dinosaur »

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: 3809
Joined: Dec 06, 2009 22:27
Location: N47°, E15°
Contact:

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

Post by TJF »

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
thegame
Posts: 4
Joined: May 25, 2021 9:27

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

Post by thegame »

Hello TJF,

I try to get started with your libpruio library on a BBB.
Looks like its perfect for what I want to do.
Her eis the problem I am running int:
I want to integrate the lib in a kernel module to read ADC values at high speed.
I can compile and run the rb_file.c sample just fine. However, when compiling the kernelmodule I get

WARNING: "pruio_rb_start" [/root/src/gpio-irq-udp-sender/gpio_irq_udp_sender.ko] undefined!
WARNING: "pruio_config" [/root/src/gpio-irq-udp-sender/gpio_irq_udp_sender.ko] undefined!
WARNING: "pruio_adc_setStep" [/root/src/gpio-irq-udp-sender/gpio_irq_udp_sender.ko] undefined!
WARNING: "pruio_new" [/root/src/gpio-irq-udp-sender/gpio_irq_udp_sender.ko] undefined!
WARNING: "my_udp_send" [/root/src/gpio-irq-udp-sender/gpio_irq_udp_sender.ko] undefined!

causing the module to me not loadable.

My understanding is, I would need the symbol export for the library such as a Module.symvers file.
Any idea how to solve this problem ?
Every bit of help is appreciated!

Thanks

Bernhard
thegame
Posts: 4
Joined: May 25, 2021 9:27

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

Post by thegame »

Oh, forget about the my_udp_send warning, different problem that I have solved.Problem with the libpruio symbols remains though.
TJF
Posts: 3809
Joined: Dec 06, 2009 22:27
Location: N47°, E15°
Contact:

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

Post by TJF »

thegame wrote:However, when compiling the kernelmodule I get

WARNING: "pruio_rb_start" [/root/src/gpio-irq-udp-sender/gpio_irq_udp_sender.ko] undefined! ...
Hi Bernhard!

It seems that the compiler doesn't find the function declarations (headers available?).

I don't understand why you want to build a kernel module. Why not running a standard app, ie. started by a boot script? Or an FCGI module providing data to a server like lighttpd, nginx or apache?

Regards
thegame
Posts: 4
Joined: May 25, 2021 9:27

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

Post by thegame »

Thanks for the fast response.
The code compiles with the warnings only. So it can resolve the header files I guess. But the compiled .ko module wont load
due to the missing symbols.
The reason I need the functionality in a kernel module is that the adc values should be synchronized with
other incoming data that creates an IRQ each time the values change. We are talking 20-50 kHz here.
Surprisingly, a kernel module on a BBB can handle that quite well, according to my measurements only about 0.5% of the IRQs get lost
at 20 kHz. And in addition, all the data is forwarded as UDP packets. never experienced a lost packet.
So my idea was to use your library to get two adc values every time the IRQ handle is invoked.
But in the meantime I think I know why it doesnt work. As far as I understand it, in a kernel module you can't simply
call user mode libraray code. All other functions I call have a representation in the kernel symbols table.
Am I right that the functions I try to use are from the C wrapper and implemented in free basic ?
I guess to do this in kernel modules I would need to use only the exportet symbols of the libpruio kernel module.
That would mean to recreate the required functions from your freebasic code in the kernel module.
Did you ever use the library in a kernel module ? If so, I would be very interesseted in the source code of the .ko module.
Thanks anyway!
TJF
Posts: 3809
Joined: Dec 06, 2009 22:27
Location: N47°, E15°
Contact:

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

Post by TJF »

thegame wrote:Am I right that the functions I try to use are from the C wrapper and implemented in free basic ?
I guess to do this in kernel modules I would need to use only the exportet symbols of the libpruio kernel module.
Yes, C wrapper functions.

In the build tree you can add option -R to the compiler flags. Then fbc will create a C source file from the FreeBASIC code. Just #include that file in to your LKM code. Once working, you can drop the bloat.
thegame wrote:The reason I need the functionality in a kernel module is that the adc values should be synchronized with
other incoming data that creates an IRQ each time the values change. We are talking 20-50 kHz here.
Surprisingly, a kernel module on a BBB can handle that quite well, according to my measurements only about 0.5% of the IRQs get lost
at 20 kHz.
Did you consider using the second PRUSS for IRQ handling? This should work up to ~1 MHz without losses.
Post Reply