I think it is 0.6.4 and to be honest I don’t know how I installed… There is no worked out install instruction is there? I installed it when the beagle board was stil very new to me. And although I wrote out quite a lot of my experiments I did not write out how I installed.
It is an idea though to upgrade. I see that 0.6.6 is the new version.
Installation using Cmake I guess. (I honestly don’t know if I used that the first time).
What makes you think that the problem could be there, since the other examples work…?
It is an idea though to upgrade. I see that 0.6.6 is the new version.
Installation using Cmake I guess. (I honestly don’t know if I used that the first time).
Sure, there’re multiple guides for the different methods at
It sounds that you self compiled the source tree. You should have a git repo folder including the file libpruio/build/install_manifest.txt. In order to update and with internet connection, you can perform
cd libpruio/build
git pull
make
make lkm
sudo make install
sudo make lkm-install
But when you have internet connection for the Pocket, it may be more convenient to use the packet manager (apt), after connecting to Arends PPA. In that case, first you have to remove the files installed from source tree by executing
cd libpruio/build make lkm-uninstall
xargs rm < install_manifest.txt
Then follow the above mentioned guide.
What makes you think that the problem could be there, since the other examples work…?
AFAIR there has been an issue with RB mode in a very first version, 0.2 I guess.
Despite the fact that I think that I have found the culprit I will update anyway and thanks for the help. I used the method from preparation. I could not find the folder you mention in your post (libpruio/build). What is the path toward it?
It seems that the USB WiFi dongle adapter (micro male to USB A female) that I use influenced the measurement. Just when I started to test my theory it broke down completely, so I am not completely sure… I became suspicious of it when I was thinking again about the ADC not reaching its conclusion and your remark about impedance. The adapter became pretty hot. Much hotter then the one I currently use. So I hope that’s it.
Thanks for testing. That convinced me not to look for a solution in the software…
I could not find the folder you mention in your post (libpruio/build). What is the path toward it?
It’s recommended that the user creates that folder inside his clone of the GIT repo, and builds the binaries in that subfolder = out-of-source-build → no polution of the original source tree.
When you build in-source instead, you should find the file at libpruio/install_manifest.txt
It seems that the USB WiFi dongle adapter (micro male to USB A female) that I use influenced the measurement. Just when I started to test my theory it broke down completely, so I am not completely sure… I became suspicious of it when I was thinking again about the ADC not reaching its conclusion and your remark about impedance. The adapter became pretty hot. Much hotter then the one I currently use. So I hope that’s it.
Seems to be OK, when you get 12 bit resolution now.
But increasing the ERam size doesn’t make sence. That’s only sufficient in MM mode, where all data must get stored in a single block.
Just quick on the question of the large ringbuffer.
One of the things I want to measure is phrases on what I call digital valves (I am busy with a musical instrument). These digital valves are potmeters with a spring. I want to measure from the time that one of the valves gets depressed till all the valves are up again (0). I do that by collecting the write address at the beginning of the phrase (moment of first depression) and the end of the phrase (all valves up). I then analyse the phrase: which valves were depressed when and what was the rhythm of depression. I estimate the very maximum length of a phrase to be about 10 seconds. One measurement per ms is probably a good enough resolution for that. On another analog input I measure the pitch and other sound ‘descriptors’ from sound picked up by a microphone, hence the 22050 Hz sampling frequency. This only needs a buffer of 512 samples for FFT analysis.
I also had a question. In my embedded application I use libpruio, 2 I2C ports and 2 USB busses (a HID sensor device and USB Wifi dongle). Currently there is a cape with a USB-hub, but that is probably going to vanish because with just one device it is not really needed anymore.
I saw in the boot time discusion, that you had a very quick startup of your board so I wondered what you have done to accomplish that specifically in relation to libpruio. I have also moved to a bone kernel. I probably can’t get to your time since I use a PocketBeagle. Currently I am at: Startup finished in 12.952s (kernel) + 25.336s (userspace) = 38.288s (4.19.94-bone44). Shaving of another 10 - 20 seconds would be nice…
Just an observation: I'm not sure of how "clean" that upgrade is, since
your apt repository list is full of Jessie (Debian v8) repositories, and
skips over Stretch (Debian v9) (which is the current "stock" OS release).
Hoping to get there, but you have a bbb. The files are interesting though. Uenv looks the same although you have the universal cape disabled. But the status shows me you have quite a few less services. Thanks.
My first custom app starts as a systemd service after ~7s (solar-regler). A second one wait for the network to be ready (solar-fcgi).
I don’t know why the pgp file is broken:-( Thanks for reporting. I re-signed both. Download from the PPA should be OK now.
Unfortunately the same error. Can it be buster related?
Yes, it can. Perhaps Buster uses a version of PGP that’s binary incompatible (not backward compatible). I’m no expert in such topics. And ATM no time to test Buster, sorry.
Workaround: Download the packages under Jessie/Stretch, copy them to Buster, and install by sudo dpkg --install *.deb``sudo apt-get -f install``
Find attached some files from the fast-boot system, hope that helps.
Hoping to get there, but you have a bbb. The files are interesting though. Uenv looks the same although you have the universal cape disabled. But the status shows me you have quite a few less services. Thanks.
Disabling all universal capes is a major step, saving ~10s kernel time (and a lot of kernel memory). You don’t need them. Pinmux by libpruio, and load necessary kernel modules manualy by modprobe.
Sure. Standard maintenence I do by WLAN. If I need a wired connection, ie. to configure WLAN, I use a temporary LAN connection. In your case just disable LAN and use USB-Serial instead.
I managed, but I had to override authentication (from stretch, 4.14.108-ti-r127) to be able to download. There was a bunch of errors and messages on the way:
Filesize:3256 [weak]
Release file created at: Thu, 09 May 2019 12:13:37 +0000
Reading package lists… Done
W: GPG error: http://beagle.tuks.nl/debian jessie/ Release: The following signatures were invalid: A76E9815117798B563EC51A7FBA956CCF84E5437
W: The repository ‘http://beagle.tuks.nl/debian jessie/ Release’ is not signed.
N: Data from such a repository can’t be authenticated and is therefore potentially dangerous to use.
N: See apt-secure(8) manpage for repository creation and user configuration details.
E: Method gave invalid 201 URI Done message
debian@beaglebone:/var/lib/cloud9$ sudo apt-get download libpruio-dev libpruio-lkm libpruio-doc
WARNING: The following packages cannot be authenticated!
libpruio-dev libpruio-doc libpruio-lkm
E: Some packages could not be authenticated
debian@beaglebone:/var/lib/cloud9$ sudo apt-get download libpruio-dev libpruio-lkm libpruio-doc --allow-unauthenticated.
E: Command line option --allow-unauthenticated. is not understood in combination with the other options
debian@beaglebone:/var/lib/cloud9$ sudo apt-get download libpruio-dev libpruio-lkm libpruio-doc --allow-unauthenticated
WARNING: The following packages cannot be authenticated!
libpruio-dev libpruio-doc libpruio-lkm
Authentication warning overridden.
Get:1 http://beagle.tuks.nl/debian jessie/ libpruio-dev 0.6.6 [24.9 kB]
Get:2 http://beagle.tuks.nl/debian jessie/ libpruio-doc 0.6.6 [4,444 kB]
Get:3 http://beagle.tuks.nl/debian jessie/ libpruio-lkm 0.6.6 [9,186 B]
Fetched 4,478 kB in 10s (432 kB/s)
W: Download is performed unsandboxed as root as file ‘/var/lib/cloud9/libpruio-dev_0.6.6_armhf.deb’ couldn’t be accessed by user ‘_apt’. - pkgAcquire::Run (13: Permission denied)
debian@beaglebone:/var/lib/cloud9$ apt-get download libpruio-dev libpruio-lkm libpruio-doc --allow-unauthenticated
WARNING: The following packages cannot be authenticated!
libpruio-dev libpruio-doc libpruio-lkm
Authentication warning overridden.
Never a dull moment. The package needs dkms and updating that package gives problems. installing recursively also asks for libpruio itself. I can probably ignore that by using --ignore-depends=libpruio?
I have upgraded and I get this warning while compiling my program (using rb):
I avoid updates, if possible. It takes too much time to optimize the boot time again and again.
/usr/bin/ld: warning: libtinfo.so.5, needed by /usr/lib/gcc/arm-linux-gnueabihf/8/…/…/…/libpruio.so, may conflict with libtinfo.so.6
(4.19.94-bone44), buster.
This library isn’t much important. It gets linked due to a single PRINT statement at the end of the destructor, sending a message to the error channel, if any. (Since the PruIo instance is destroyed after the DTOR, the variable Errr cannot get used in that case.)
It’s much likely that you can ignore the linker warning.
It’d be best to include libpruio in RCNs build farm, in order to get a fresh binary for each new update. He startet that project, but never finished jet. I don’t know why.
Perhaps libpruio users should motivate him to continue. (I’m ready for supporting, if necessary.)
I have upgraded and I get this warning while compiling my program (using rb):
I avoid updates, if possible. It takes too much time to optimize the boot time again and again.
I will too once I have found my optimum configuration ;-). Still looking for it though. I am now trying to be careful in documenting each step, so it won’t be such a hassle the next time.
/usr/bin/ld: warning: libtinfo.so.5, needed by /usr/lib/gcc/arm-linux-gnueabihf/8/…/…/…/libpruio.so, may conflict with libtinfo.so.6
(4.19.94-bone44), buster.
This library isn’t much important. It gets linked due to a single PRINT statement at the end of the destructor, sending a message to the error channel, if any. (Since the PruIo instance is destroyed after the DTOR, the variable Errr cannot get used in that case.)
