libpruio (BB D/A - I/O fast and easy)
-
- Posts: 8586
- Joined: May 28, 2005 3:28
- Contact:
Re: libpruio (BB D/A - I/O fast and easy)
If you have installed libncurses make libtinfo.so.5 as a link to it thats all.
http://www.freebasic.net/forum/viewtopi ... es#p205452
Joshy
http://www.freebasic.net/forum/viewtopi ... es#p205452
Joshy
Re: libpruio (BB D/A - I/O fast and easy)
Hi TJF,
First, I want to thank you for taking the time to create this great library! It has helped us a great deal in our BBB robotic project.
I saw in a previous post that in order to fix the ADC sampling speed issue, I must first replace the lines in /src/pruio/puio_adc.bas
d *= (Conf->ADC_CLKDIV + 1) * 417 '417 ≈ 1000000 / 2400 (= 1 GHz / 2.4 MHz)
d += 30 ' PRU cycles for restart [GHz]
IF Tmr <= d THEN .Errr = @"sample rate too big" : RETURN .Errr
with
d = (d * (Conf->ADC_CLKDIV + 1) * 1000) \ 24
IF Tmr <= d ORELSE Tmr < 5000 THEN _
.Errr = @"sample rate too big" : RETURN .Errr
and play with the 5000. Then compile the updated source code.
I am a noob and don't know anything about freebasic (using the library in C). I have made the above changes, and tried recompiling the library but had no luck. Is there anyway you can recompile it and upload the fixed version? I need fast ADC sampling that the current version is unable to provide.
I really appreciate all of your hard work!
Cheers,
Ihab
First, I want to thank you for taking the time to create this great library! It has helped us a great deal in our BBB robotic project.
I saw in a previous post that in order to fix the ADC sampling speed issue, I must first replace the lines in /src/pruio/puio_adc.bas
d *= (Conf->ADC_CLKDIV + 1) * 417 '417 ≈ 1000000 / 2400 (= 1 GHz / 2.4 MHz)
d += 30 ' PRU cycles for restart [GHz]
IF Tmr <= d THEN .Errr = @"sample rate too big" : RETURN .Errr
with
d = (d * (Conf->ADC_CLKDIV + 1) * 1000) \ 24
IF Tmr <= d ORELSE Tmr < 5000 THEN _
.Errr = @"sample rate too big" : RETURN .Errr
and play with the 5000. Then compile the updated source code.
I am a noob and don't know anything about freebasic (using the library in C). I have made the above changes, and tried recompiling the library but had no luck. Is there anyway you can recompile it and upload the fixed version? I need fast ADC sampling that the current version is unable to provide.
I really appreciate all of your hard work!
Cheers,
Ihab
Re: libpruio (BB D/A - I/O fast and easy)
Thank you TJF for your help and patience.TJF wrote:Install the -dev version.
Unforunately, for Arch Linux there is no -dev version.
There is https://aur.archlinux.org/ncurses5-compat-libs.git - but this is not available for armv7h architecture.
Re: libpruio (BB D/A - I/O fast and easy)
Hi Ihab, sorry for the late answer (I again don't get notification on new posts in this thread).
@c136: :-(
Not really, ATM.isalameh wrote:Is there anyway you can recompile it and upload the fixed version?
How did you compile? Which messages did you get?isalameh wrote:I am a noob and don't know anything about freebasic (using the library in C). I have made the above changes, and tried recompiling the library but had no luck.
@c136: :-(
Re: libpruio (BB D/A - I/O fast and easy)
I posted a question on Beaglebone Black forum about issues with the PWM using SysFs and you replied that I could maybe use your technology. I have a few questions, and I have to admit I haven't spent to time on your site to see for myself.
I assume by the name of your library that use are using the pru built in the beaglebone black? And you have c binding to access your library.
If this is true then is it possible to add other io to the library, does this violate the license? I have wanted to write a pru version of the DS18B20 temperature sensor. A major problem with the SysFs version is that each temp reading takes a full second, ouch! I modified a c version of the library that enabled me to measure 4 devices per second by alternating the address write with the data read. I have a project I am building, one that requires 4 temperature sensors and another that requires 8 temperature sensors. Each require 4 separate pwm circuits so if all of this is correct, I could make use of this project :)
Thanks for suggesting it to me.
I assume by the name of your library that use are using the pru built in the beaglebone black? And you have c binding to access your library.
If this is true then is it possible to add other io to the library, does this violate the license? I have wanted to write a pru version of the DS18B20 temperature sensor. A major problem with the SysFs version is that each temp reading takes a full second, ouch! I modified a c version of the library that enabled me to measure 4 devices per second by alternating the address write with the data read. I have a project I am building, one that requires 4 temperature sensors and another that requires 8 temperature sensors. Each require 4 separate pwm circuits so if all of this is correct, I could make use of this project :)
Thanks for suggesting it to me.
Re: libpruio (BB D/A - I/O fast and easy)
Hello sting, welcome at this forum!
I had a similar problem with Dallas sensors and I used the second PRU for my W1 driver. In my usecase this driver reads 9 sensors in less than a second and I have less reading failures compared to the kernel driver. The driver also has a monitoring feature that can log the bus state (@1MHz). I used this to optimize the wiring.
Unfortunately it isn't published yet. Documentation isn't ready. But I can provide a version for beta testing, if you like. (The driver depends on libpruio for pinmuxing capability.)
BR
Correct!sting wrote:I assume by the name of your library that use are using the pru built in the beaglebone black? And you have c binding to access your library.
The library is OpenSource, you can adapt it as you like. But it isn't easy to add a W1 driver feature without breaking the functionality.sting wrote:If this is true then is it possible to add other io to the library, does this violate the license? I have wanted to write a pru version of the DS18B20 temperature sensor. A major problem with the SysFs version is that each temp reading takes a full second, ouch! I modified a c version of the library that enabled me to measure 4 devices per second by alternating the address write with the data read. I have a project I am building, one that requires 4 temperature sensors and another that requires 8 temperature sensors. Each require 4 separate pwm circuits so if all of this is correct, I could make use of this project :)
I had a similar problem with Dallas sensors and I used the second PRU for my W1 driver. In my usecase this driver reads 9 sensors in less than a second and I have less reading failures compared to the kernel driver. The driver also has a monitoring feature that can log the bus state (@1MHz). I used this to optimize the wiring.
Unfortunately it isn't published yet. Documentation isn't ready. But I can provide a version for beta testing, if you like. (The driver depends on libpruio for pinmuxing capability.)
BR
Re: libpruio (BB D/A - I/O fast and easy)
Yes, I would like to test your driver. I just moved to the latest kernel for the beaglebone and I have to remove all of the bloatware and understand how to build qt applications.
Thank you for your offer.
Thank you for your offer.
Re: libpruio (BB D/A - I/O fast and easy)
In my frustration with the pwm pins I move to a newer kernel to see if that was the problem. I decided to use your library :) but it doesn't seem to work on the 4.x kernel. The 4.x kernel has only the universal overlay loaded with no room for your overlay. Is this something you are going to change to or should I go to the 3.x kernel? It doesn't matter to me either way.
Re: libpruio (BB D/A - I/O fast and easy)
Hello!
BR
I uploaded the project at https://github.com/DTJF/libpruw1sting wrote:Yes, I would like to test your driver.
Not the best idea. In kernel version >4.x the path for ocp in /sys/devices changed. The current libpruio version 0.2 was published before that change. There're other problems with capemgr as well. So it's recommended to use kernel 3.8.x (Debian 7.9).sting wrote:I just moved to the latest kernel for the beaglebone ...
Qt? Really? Good luck!sting wrote:... and I have to remove all of the bloatware and understand how to build qt applications.
BR
Re: libpruio (BB D/A - I/O fast and easy)
You can disable the cape_universal in /boot/uEnv.txt. Just change cape_universal=enable to cape_universal=disable. Then edit the file /etc/default/capemgr and insert CAPE=libpruiosting wrote:IThe 4.x kernel has only the universal overlay loaded with no room for your overlay. Is this something you are going to change to or should I go to the 3.x kernel? It doesn't matter to me either way.
Re: libpruio (BB D/A - I/O fast and easy)
I have looked at several options that can remotely deploy to the beaglebone, some are more straight forward then others. I have build Qt applications for Linux machines so I figured this wouldn't be too bad. I can run it to the linux frame buffer and not need X11 so performance will not be terrible.TJF wrote: Qt? Really? Good luck!
I looked at uGFX at http://ugfx.org/ but they require a special make system and doesn't seem to work well with eclipse.
Do you know of any other alternatives for a simple GUI?
Re: libpruio (BB D/A - I/O fast and easy)
I tried to build the libpruw1 and had an error from cmake. I know you put the code out there when you didn't think it was ready so I understand if you are not ready to answer questions.
I believe I built all of the steps:
The FB compiler
cmakefbc
libpruio
when I try to build libpruw1 i get the error from cmake:
--Tool cmake_fb_deps not available -> no Fbc extensions!
CMake error at src/bas/CMakeList.txt:79 (Add_Fbc_SRC_DEPS):
unknown CMake command "ADD_FBC_SRC_DEPS".
I believe I built all of the steps:
The FB compiler
cmakefbc
libpruio
when I try to build libpruw1 i get the error from cmake:
--Tool cmake_fb_deps not available -> no Fbc extensions!
CMake error at src/bas/CMakeList.txt:79 (Add_Fbc_SRC_DEPS):
unknown CMake command "ADD_FBC_SRC_DEPS".
Re: libpruio (BB D/A - I/O fast and easy)
I am trying to sort out why I can't cmake on libpruw1 and I have run into a couple of issues.
In order of the preperations:
i have the freebasic compiler running, I type fbc and get the usage screen.
the directory /usr/local/include/freebasic/BBB has pruio.hp, prusdrv.bi, and pruss_intc_mapping.bi
pasm is installed in /usr/local/bin and is on the path. I type pasm and get the usage screen.
cmakefbc is installed: in the build directory I type sudo make install I get a list of items that are Up-to-date and the last is
- - Up-to-date: /usr/local/bin/cmake_fb_deps
libpruio is installed, I ran example 1 and got the expected array of hex values.
if I type ldconfig -p | grep libpru I get
libprussdrvd.so (...) => /usr/lib/libprussdrvd.so
libprussdrv.so (...) => /usr/lib/libprussdrv.so
libpruio.so => /usr/local/lib/libpruio.so
when I attempt to git fb_doc by typing
git clone https://github.com/DTJF/fb_doc I am asked for a username and password. This did not happen when I installed cmakefbc
I didn't think I need the doc so I continued
I cloned the libpruw1 repository, created the build directory and cd'd to that directory
when I type cmake .. I get the error posted in the above post.
I am clearly missing something.
In order of the preperations:
i have the freebasic compiler running, I type fbc and get the usage screen.
the directory /usr/local/include/freebasic/BBB has pruio.hp, prusdrv.bi, and pruss_intc_mapping.bi
pasm is installed in /usr/local/bin and is on the path. I type pasm and get the usage screen.
cmakefbc is installed: in the build directory I type sudo make install I get a list of items that are Up-to-date and the last is
- - Up-to-date: /usr/local/bin/cmake_fb_deps
libpruio is installed, I ran example 1 and got the expected array of hex values.
if I type ldconfig -p | grep libpru I get
libprussdrvd.so (...) => /usr/lib/libprussdrvd.so
libprussdrv.so (...) => /usr/lib/libprussdrv.so
libpruio.so => /usr/local/lib/libpruio.so
when I attempt to git fb_doc by typing
git clone https://github.com/DTJF/fb_doc I am asked for a username and password. This did not happen when I installed cmakefbc
I didn't think I need the doc so I continued
I cloned the libpruw1 repository, created the build directory and cd'd to that directory
when I type cmake .. I get the error posted in the above post.
I am clearly missing something.
Re: libpruio (BB D/A - I/O fast and easy)
Hello sting, sorry for my late answer. I don't check this forum often.
(minus instead of underscore)
(you should get an error message, like "cmake_fb_deps: Too less parameters").
I guess you're having a permissions issue. This tool is root only when you build it by sudo make install. Better follow the instructions (two separate commands)
I propose that you re-do the cmakefbc installation (execute in your cmakefbc/build folder):
BR
You're right, fb-doc is neccessary for documentation (and C header building) only. You shouldn't need it. Just for curiosity: What happens when you executesting wrote:when I attempt to git fb_doc by typing
git clone https://github.com/DTJF/fb_doc I am asked for a username and password. This did not happen when I installed cmakefbc
I didn't think I need the doc so I continued
Code: Select all
git clone https://github.com/DTJF/fb-doc
Something went wrong when you installed cmakefbc.sting wrote:when I try to build libpruw1 i get the error from cmake:
--Tool cmake_fb_deps not available -> no Fbc extensions!
This message is contrary to the above message, which says this tool is not available. Is /usr/local/bin in your path? What happans when you execute the tool in your libpruw1 build directory, likesting wrote:cmakefbc is installed: in the build directory I type sudo make install I get a list of items that are Up-to-date and the last is
- - Up-to-date: /usr/local/bin/cmake_fb_deps
Code: Select all
cmake_fb_deps
I guess you're having a permissions issue. This tool is root only when you build it by sudo make install. Better follow the instructions (two separate commands)
Code: Select all
make
sudo make install
CMake doesn't find/load the Fbc language scripts. That's the most confusing part. Those scripts should be in your CMake install path (after you installed cmakefbc correctly). But they're also in the libpruw1/cmake/Modules folder and should get loaded from there (as long as you didn't comment the line "SET(CMAKE_MODULE_PATH ...)" in the main CMakeLists.txt file).sting wrote:CMake error at src/bas/CMakeList.txt:79 (Add_Fbc_SRC_DEPS):
unknown CMake command "ADD_FBC_SRC_DEPS".
I propose that you re-do the cmakefbc installation (execute in your cmakefbc/build folder):
- remove installed files:
Code: Select all
sudo xargs rm < install_manifest.txt
- clean build directory
Code: Select all
rm -r *
- build again from scatch
Code: Select all
cmake .. make clean sudo make install
BR
Re: libpruio (BB D/A - I/O fast and easy)
Here is the console output you asked for. I rebuilt cmake_fb_deps, it is in my path for all users. For Some reason I can't seem to build the libpruw1.
Code: Select all
an@beaglebone:~/cmakefbc/build$ sudo xargs rm < install_manifest.txt
debian@beaglebone:~/cmakefbc/build$ rm -r *
rm: remove write-protected regular file `install_manifest.txt'? y
debian@beaglebone:~/cmakefbc/build$ ls
debian@beaglebone:~/cmakefbc/build$ cmake ..
-- Tool cmake_fb_deps not available -> no Fbc extensions!
-- Check for working Fbc compiler OK ==> /usr/bin/fbc (1.01.0)
-- fb-doc tool not executable! (tried command fb-doc)
-- fb-doc tool not found ==> doc targets not available!
-- Configuring done
-- Generating done
-- Build files have been written to: /home/debian/cmakefbc/build
debian@beaglebone:~/cmakefbc/build$ ls
CMakeCache.txt cmake_fb_deps CMakeFiles cmake_install.cmake doxy Makefile
debian@beaglebone:~/cmakefbc/build$ make clean
debian@beaglebone:~/cmakefbc/build$ sudo make install
Scanning dependencies of target cmake_fb_deps
[100%] Building Fbc object cmake_fb_deps/CMakeFiles/cmake_fb_deps.dir/cmake_fb_deps.bas.o
Linking Fbc executable cmake_fb_deps
[100%] Built target cmake_fb_deps
Install the project...
-- Install configuration: ""
-- Installing: /usr/share/cmake-2.8/Modules
-- Installing: /usr/share/cmake-2.8/Modules/FindFb-Doc.cmake
-- Installing: /usr/share/cmake-2.8/Modules/Platform
-- Installing: /usr/share/cmake-2.8/Modules/Platform/Windows-Fbc.cmake
-- Installing: /usr/share/cmake-2.8/Modules/Platform/Linux-Fbc.cmake
-- Installing: /usr/share/cmake-2.8/Modules/CMakeFbcInformation.cmake
-- Installing: /usr/share/cmake-2.8/Modules/CMakeFbcCompiler.cmake.in
-- Installing: /usr/share/cmake-2.8/Modules/CMakeDetermineFbcCompiler.cmake
-- Installing: /usr/share/cmake-2.8/Modules/UseFb-Doc.cmake
-- Installing: /usr/share/cmake-2.8/Modules/CMakeTestFbcCompiler.cmake
-- Installing: /usr/local/bin/cmake_fb_deps
debian@beaglebone:~/cmakefbc/build$ cd
debian@beaglebone:~$ cd /usr/local/libp*
debian@beaglebone:/usr/local/libpruw1$ ls
build cmake CMakeLists.txt doxy ReadMe.md src
debian@beaglebone:/usr/local/libpruw1$ cd build
debian@beaglebone:/usr/local/libpruw1/build$ cmake ..
-- Tool cmake_fb_deps not available -> no Fbc extensions!
CMake Error at src/bas/CMakeLists.txt:79 (ADD_Fbc_SRC_DEPS):
Unknown CMake command "ADD_Fbc_SRC_DEPS".
-- Configuring incomplete, errors occurred!
debian@beaglebone:/usr/local/libpruw1/build$ sudo cmake ..
-- Tool cmake_fb_deps not available -> no Fbc extensions!
CMake Error at src/bas/CMakeLists.txt:79 (ADD_Fbc_SRC_DEPS):
Unknown CMake command "ADD_Fbc_SRC_DEPS".
-- Configuring incomplete, errors occurred!
debian@beaglebone:/usr/local/libpruw1/build$ cmake_fb_deps
cmake_fb_deps: Too less parameters