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

[TJF]

[edit190406]

The original text below is deprecated. Meanwhile the code works on all Beaglebones (white, black, green, blue and Pocket).

Find the current source at https://github.com/dtjf/libpruio
the on-line documentation at http://users.freebasic-portal.de/tjf/Pr ... /doc/html/
an the binaries in Arend Lammertinks PPA.

[/edit190406]

Developing I/O tasks on Beaglebone (white or black) hardware isn't really fun. For digital I/O you've to deal with issues like

• multiple source (device tree overlays and your program)
• several device tree compiler versions (option -@)
• pure documentation (spread all over the kernel source)

And also for analog input the situation isn't better

• faulty ADC kernel driver
• no control over the ADC device setting
• slow sampling rates

Most operations either need root privilegues or a lot of configurations to get access for a normal user. Anyway, all I/O isn't fast due to the slow file operations.

All these pitfalls don't realy help when you want to focus on your core problem and create new software.


Here's my solution

libpruio is a driver for the AM33xx processor family. It controls the subsystems

• Control Module (pinmuxing)
• GPIO 0 to 3 (General Purpose Input and Output)
• TSC_ADC_SS (Touch Screen Controler and Analog to Digital Convertor SubSystem)
• PWMSS (Pulse Width Modulation SubSystem)

in real time by software running on the PRUSS (Programable Realtime Unit SubSystem). The API is designed for easy and safe usage, but also for high speed operations. For the daily work you need not care about mystic tables with CPU ball numbers or GPIO codes. Instead specify what you see (ie. P8_11 = header P8, pin 11).

libpruio handles

• waking up subsystems
• reading original subsystems configurations on start up
• enable or disable subsystems at run-time
• configure subsystems at run-time
• setting GPIO configurations
• performing GPIO operations (read / write in IO mode)
• output of pulse trains (PWM)
• analysing of pulse trains (CAP)
• setting ADC configurations
• reading single ADC samples (IO mode, controlled by host)
• reading multiple ADC samples with accurate timing (MM mode, controlled by PRUSS)
• using triggers to start ADC sampling in MM mode (GPIO or ADC input)
• restoring the original configurations on close down

The library can be used under the terms of the Lesser GNU Public Licence version 2 (LGPLv2). The package also contains a C wrapper for the library and examples (under GPLv3) in FreeBASIC syntax (most of them are also included in C syntax):

• 1.bas: minimal example
• analyse.bas: output initial devices configurations
• button.bas: output the state fo an pullup GPIO input in IO mode (since 0.0.2)
• io_input.bas: output the digital and analog lines in IO mode
• pwm_cap.bas: output a measured pulse train of a PWM output
• sos.bas: blink a user led in SOS code
• stepper.bas: drive a stepper motor
• pwm_adc.bas: show a graph of analog inputs of three PWM outputs
• oszi.bas: show a graph of analog inputs
• rb_oszi.bas: show a graph of two analog inputs from ring buffer
• triggers.bas: start measurements by trigger events in MM mode

Check the on-line documentation or download it here for off-line usage.

Download the package at

• libpruio (D/A - I/O schnell und einfach)

[ike]

Do I need to use that library for this board?

http://xylotex.netfirms.com/OSCommerce/ ... ucts_id=53

or I can just turn pins on using file output?

[TJF]

Hello ike!

I'm not sure if I understand your aim and your question. Some thoughts in general:

The cape (board) you mentioned gets shiped with a pre-installed LinuxCnc package on a uSD-card. You don't need any additional software to run the cape for a 3D application with cartesian coordinates (3D printer, 3D milling, ...).

If you want to use the cape in a different application (ie. a roboter arm with polar coordinates) you need to customize the software

• either by adapting the (Python and PRU based) LinuxCnc project
• or by developing from scratch in your prefered programming language.

The later can be done

• either by using file input / output methods (multiple source, slow)
• or by using libpruio (single source, fast access).

libpruio also makes it easy to use additional ADC input (ie. to control the temperature of a printing head for different filament materials).

[ike]

The later can be done
either by using file input / output methods (multiple source, slow)
or by using libpruio (single source, fast access).

SO I CAN USE FILE INPUT - it is slow
or LIBPRUIO - FAST

That is answer! Thank you TJF!
-----
What BBB you recomend for larning, I have no experience with LINUX.
What Linux is good for BBB?

[TJF]

I use a Beaglebone Black, it's fine for me. If you buy one in near future, take care that you get the new board design. It's called Rev C and has some more EMC memory and other improvements over the first design. A downside of BBB is the missing driver for 3D acceleration. A sgx530 GPU is on board, but the driver is still under development.

Regarding Linux I first tried the Angström distribution that was shiped on the board. But I ran into trouble when compiling / installing the fbc. That's why I switched to Ubuntu. I succesfuly used version 12.10 and now 13.10. You can prepare bootable uSD-cards with different OSs and test one after the other. The bigger the card, the better. But 8 Gb is fine for OS and some applications to test.

[TJF]

Version 0.0.2 is out now:

• added: new example button.bas (.c)
• bugfix: gpio_get returns correct value now
• cosmetic: pruio_c_wrapper.h contains headers pruio.h and pruio.hp (all-in-one)
• cosmetic: minor changes in documentation

(For download links see first post.)

[rvega]

Hello, I'll post this here in case it's useful for others:

1. Install FreeBasic compiler in BBB

1.1. Download package from http://www.freebasic-portal.de/download ... k-283.html

Code: Select all

wget http://www.freebasic-portal.de/dlfiles/452/bbb_fbc-0.0.2.tar.xz

1.2. Uncompress and copy files

Code: Select all

 cd bbb_fbc-0.0.2
   cp usr/local/bin/fbc /usr/local/bin/
   cp -R usr/local/lib/freebasic /usr/local/lib/

2. Install pruss driver kit for freebasic and BBB.

2.1. Download and uncompress package from http://www.freebasic-portal.de/dlfiles/ ... .0.tar.bz2

2.2. Copy files

Code: Select all

   cd FB_prussdrv-0.0
   cp bin/libprussdrv.* /usr/local/lib
   ldconfig
   mkdir /usr/local/include/freebasic/BBB
   cp include/* /usr/local/include/freebasic/BBB
   cp bin/pasm/usr/local/bin
   cp bin/PRUSSDRV-00A0.dtbo /lib/firmware
   

2.3. Install am335x-pru-package

Code: Select all

apt-get install am335x-pru-package

2.4. Activate the PRUSS by enabling the tree overlay. This must be done everytime, after each boot or before running your programs.

Code: Select all

echo PRUSSDRV> /sys/devices/bone_capemgr.9/slots

3. Install libpruio

3.1. Download and uncompress package from http://www.freebasic-portal.de/dlfiles/ ... .2.tar.bz2

3.2. Copy files

Code: Select all

   cd libpruio-0.0.2
   cd src/c_wrapper/
   cp libpruio.so /usr/local/lib
   cp libpruio.a /usr/local/lib
   ldconfig
   cd ../pruio/
   cp pruio.bi /usr/local/include/freebasic/BBB
   cp pruio.hp /usr/local/include/freebasic/BBB
   cp pruio_pins.bi /usr/local/include/freebasic/BBB
   

4. Here's a simple example C program that uses the library

Code: Select all

   #include <stdio.h>
   #include <unistd.h>
   #include "pruio_c_wrapper.h"
   #include "pruio_pins.h"

   int main(int argc, const char *argv[]) { 
      PruIo *io = pruio_new(0, 0x98, 0, 1);
      if (io->Errr) {
         printf("Initialisation failed (%s)\n", io->Errr);
         return 1;
      }

      if(pruio_config(io, 0, 0x1FE, 0, 4, 0)){
         printf("Config failed (%s)\n", io->Errr); 
         return 1;
      }

      int a = 0;
      int i;
      while(1){
         printf"\r%12o  %12o  %12o  %12o  %4X %4X %4X %4X %4X %4X %4X %4X\n", io->Gpio[0].Stat, io->Gpio[1].Stat, io->Gpio[2].Stat, io->Gpio[3].Stat, io->Value[1], io->Value[2], io->Value[3], io->Value[4], io->Value[5], io->Value[6], io->Value[7], io->Value[8]);
         fflush(STDIN_FILENO);
         usleep(1000);
       }


      pruio_destroy(io);

           return 0;
   }
   

5. To compile it, here's a makefile:

Code: Select all

   all: bbb-io.c Makefile
        gcc -Wall -o bbb-io bbb-io.c /usr/local/lib/freebasic/fbrt0.o -lpruio -L"/usr/local/lib/freebasic/" -lfb -lpthread -lprussdrv -ltermcap -lsupc++ -Wno-unused-variable

[rvega]

Hi TJF. I have a request.

I want to publish a PureData http://puredata.info/ external (an add-on object) that allows for reading the GPIO and Analog pins on the BBB through libpruio. Externals in PD are built in the C language and compiled as linux dynamic libraries.

When I try to compile my external, the linker complains that the libfb.a library has to be built with the -fPIC compiler flag. I then tried to compile libfb: I downloaded the full src for version 0.90.0 from sourceforge, rewrote some files in the 0.90.0 package from your package at http://www.freebasic-portal.de/download ... k-283.html (src/compiler*, makefile and config.mk) but I get errors when running `make rtlib`:

Code: Select all

gcc -Wall -Werror-implicit-function-declaration -Wfatal-errors -O2 -DDISABLE_X11 -DDISABLE_GPM -DDISABLE_OPENGL  -c src/rtlib/linux/sys_portio.c -o src/rtlib/obj/sys_portio.o
src/rtlib/linux/sys_portio.c: In function ‘fb_hIn’:
src/rtlib/linux/sys_portio.c:11:2: error: impossible constraint in ‘asm’

Also, if I do `make` I get:

Code: Select all

gcc -Wall -Werror-implicit-function-declaration -Wfatal-errors -O2 -DDISABLE_X11 -DDISABLE_GPM -DDISABLE_OPENGL  -c src/rtlib/linux/sys_portio.c -o src/rtlib/obj/sys_portio.o
src/rtlib/linux/sys_portio.c: In function ‘fb_hIn’:
src/rtlib/linux/sys_portio.c:11:2: error: impossible constraint in ‘asm’

Can you please advise?

Thank you!

[D.J.Peters]

http://www.freebasic.net/forum/viewtopi ... =5&t=21433

[added by d.j.peters]
- ARM v6/v7 support gcc backend used -march armv6 or armv7-a. Compiler #define __FB_ARM__
Internal fbCpuTypeIsARM() is new and /rtlib/arm/cpudetect.s (CPU type is curently hard coded will be changed in next version)
added in makefile DISABLE_FBDEV and DISABLE_PORTIO(all source code changes marked with !!!ARM!!!)

You have to disable x86 assembler instructions.

Joshy

[TJF]

Hello rvega, welcome at this forum!

I want to publish a PureData http://puredata.info/ external (an add-on object) that allows for reading the GPIO and Analog pins on the BBB through libpruio.

Glad to read that! I'll do my best to support your project.

Obviously, I missed this change in my fbc-package. Here's the code I used (src/rtlib/linux/sys_portio.c):

Code: Select all

/* ports I/O functions */

#include "../fb.h"
#include "../unix/fb_private_console.h"

int fb_hIn( unsigned short port )
{
	//unsigned char value;
	//if (!__fb_con.has_perm)
		return -fb_ErrorSetNum( FB_RTERROR_NOPRIVILEDGES );
	//__asm__ volatile ("inb %1, %0" : "=a" (value) : "d" (port));
	//return (int)value;
}

int fb_hOut( unsigned short port, unsigned char value )
{
	//if (!__fb_con.has_perm)
		return fb_ErrorSetNum( FB_RTERROR_NOPRIVILEDGES );
	//__asm__ volatile ("outb %0, %1" : : "a" (value), "d" (port));
	//return FB_RTERROR_OK;
}

I documented the process to build the ARM version of the compiler in this thread. Unfortunatelly the complete thread is lost. (I asked the admins to fix this several times, but no response.)

A little after my project, D.J.Peters made a second ARM version of the FreeBASIC compiler (see the link in his above post). I didn't test this version yet. His advice (DISABLE_PORTIO) is related to his compiler version. This switch is not included in the official fbc nor in my ARM version. Also his version number 0.91.0 is a bit irritating, because it will interfere with the next official FreeBASIC version. So take care that you don't mix different versions.

Good luck!

[rvega]

Thanks TJF, that worked! I'm now able to read the GPIOs from within a PD external. It still needs some work, though, so It'll be a few days untill I publish it.

I have a couple of questions, just out of curiosity.

1. On your src/compiler directory, there are a few .c files but the makefile only compiles .bas files in that folder, what are those .c files for/how do they get compiled?

2. Since compiling of the freebasic compiler is done with freebasic itself, how did you compile this the first time!?

3. Is any of the two arm branches of the FB compiler going to be merged into the official FB compiler codebase? If so, is there any interest to make "standard" linux packages for this?

[TJF]

Thanks TJF, that worked! I'm now able to read the GPIOs from within a PD external. It still needs some work, though, so It'll be a few days untill I publish it.

Great! Take your time, quality is more important than speed.

1. On your src/compiler directory, there are a few .c files but the makefile only compiles .bas files in that folder, what are those .c files for/how do they get compiled?

2. Since compiling of the freebasic compiler is done with freebasic itself, how did you compile this the first time!?

3. Is any of the two arm branches of the FB compiler going to be merged into the official FB compiler codebase? If so, is there any interest to make "standard" linux packages for this?

As you said -- and since FB compiler is self-hosted -- it's a kind of Chicken & Egg question.

• 3: We cannot provide a "standard" linux package, because the fbc is needed to compile its own source. (It's not allowed for standard packages.)
  
  2: For the ARM version I auto-created the C version of the compiler source files on a PC (using fbc).
  
  1: Then I adapted some files (containing __asm__ instructions). Only these adapted files are included in my BBB-fbc package. Finally I copied all files to the BBB and compiled with ARM-gcc. (This process is described in the lost thread.)

I see my project as a kind of pilot-study. Its purpose is to demonstrate the technical doability. I think (hope), that the FB developers will adapt the official source soon (in a more professional way than I can do). For the time being, my version works for me.

[dkl]

I think all needed changes are already in fbc.git - I'd recommend using the latest version from Git, instead of the (by now outdated) FB 0.90.* sources.

It'd be good for this to get some testing too, since I've only tested it with Ubuntu's ARM cross compilers, to see whether it will compile and can produce executables in the first place, but not on a ARM system.

[TJF]

I think all needed changes are already in fbc.git.

Good to know, thanks.

I'd recommend using the latest version from Git, instead of the (by now outdated) FB 0.90.* sources.

It'd be good for this to get some testing too, since I've only tested it with Ubuntu's ARM cross compilers, to see whether it will compile and can produce executables in the first place, but not on a ARM system.

Is version 0.91 released now (and 0.90 is outdated)?

Anyway, I'll prepare a testing environment on my BBB under Debian and do some testing with the current Git code. But I want to finish my current project first.

[dkl]

Well, good point. It's about time for a new release.