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

[TJF]

A new library called libpruio is availble to support digital input and output as well as analog input on Beaglebone (black) hardware. It uses software running on a PRUSS to configure and control the devices

• Control Module (pinmuxing)
• GPIO 0 to 3 (digital IO)
  
• TSC_ADC_SS (analog input)
  

The API is designed for easy usage, but also for fast execution speed. No need for root privilegues or further device tree overlays (just a single overlay to start the PRUSS).

It's compiled by the FreeBASIC compiler, but also includes a wrapper to be used with C compilers. The package contains example code in both languages. Development and testing has been done on a BeagleboneBlack under Ubuntu 13.10.

Find more informations at

• en: libpruio (BB D/A - I/O fast and easy)
• de: libpruio (D/A - I/O schnell und einfach)

or check out the online documentation.

[Jason Kridner]

This looks pretty awesome  from the surface. You should register at http://beagleboard.org/project. Do you want this included the default image?

--
For more options, visit http://beagleboard.org/discuss
---
You received this message because you are subscribed to the Google Groups "BeagleBoard" group.
To unsubscribe from this group and stop receiving emails from it, send an email to beagleboard...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[TJF]

Thanks for the registration tip / link, done.

And thanks for your positive statement. I hope you find some time to look under the hood. Would be nice if you can run some of the pre-compiled examples and tell us your thoughts.

The licences are LGPLv2 / GPLv3, so it could get in to the default image. I'd like to get some feedback and fix the major bugs, first. Is there a deadline?

[Jason Kridner]

No particular deadline as we already shipped the Rev C image. We will push a bug fix version over the next 2-3 weeks as reports come in. If we don't squeeze in there, there's always another release coming. 

On Friday, May 9, 2014, TJF <jeli.f...@gmail.com> wrote:

[Jason Kridner]

No set deadline. We should be doing new releases multiple times this
summer as issue reports and feature requests start coming in on Rev C
as we get more users.

[TJF]

For the default image we need the binary libpruio.so (not sure about libpruio.a). And we need the headers. Currently there're 4 headers, but I think I should create an all-in-one version called pruio.h and drop the documentation comments to save some memory.

Where to send the fine-tuned files? (Please be patient, that's my first project here.)

Who cares about the dependencies (libprussdrv)?

[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

[sufialh...@gmail.com]

Hi TJF,

I just managed to compile and run the libpruio example apps on beaglebone white PRU.

I was experimenting with the button.c, trying to set the pin 8_07 as active high, using ->

if (pruio_gpio_set(io, PIN, PRUIO_IN_0, PRUIO_LOCK_CHECK)) { 
    printf("failed setting PIN (%s)\n", io->Errr); break;}

But, when I compile and run it, I still see its '1'.

./analyse reveals->

P8_07, GPIO 2/02: input, pullup

Am I missing something?

Forgive me if this sounds like a stupid question. Please help.

Thanks and regards,
Shoaib Ahmed.

[TJF]

Hi Shoaib Ahmed,

thanks for your interrests in libpruio.

Am Mittwoch, 3. September 2014 18:05:05 UTC+2 schrieb sufialh...@gmail.com:

Am I missing something?

Forgive me if this sounds like a stupid question. Please help.

No stupid question. A stupid author of libpruio, instead. Pinmuxing doesn't work in your version. See

http://www.freebasic.net/forum/viewtopic.php?f=14&t=22501&start=30#p198962

It'll be fixed in the next release (version 0.2). Meanwhile use external tools, please.

Sorry for your trouble.

[nils....@gmail.com]

Hey TJF,

I'm currently working on underwater ultrasonic sound and wonder if you think that with your library can produce constant and reliant ADC input at sample rates of 200Khz per pin. On top of that I'm interested to see version 0.2 and the ring buffer you're been talking about.

Since it seems that you've already been able to produce results with the ring buffer, I only need to read ADC input right now and I'm on a tight schedule right now I would like to ask you if you want to provide a test version of said feature. I can provide the results of the tests.

Greetings,

Nils Kohrs

[TJF]

Hello Nils!

Am Mittwoch, 17. September 2014 22:25:05 UTC+2 schrieb nils....@gmail.com:

Hey TJF,

I'm currently working on underwater ultrasonic sound and wonder if you think that with your library can produce constant and reliant ADC input at sample rates of 200Khz per pin

The PRUSS code is ready to work at that speed. Unfortunately the BBB hardware (TSC_ADC_SS) is limited to a maximum total sampling rate of 160 kHz (one channel, software triggered start). If you need more than one channel, you've to add some delay for switching (multiplexing) the input.
 

On top of that I'm interested to see version 0.2 and the ring buffer you're been talking about.

The code is ready (95 %). I'm working on the documentation (any help is welcome).
 

Since it seems that you've already been able to produce results with the ring buffer, I only need to read ADC input right now and I'm on a tight schedule right now I would like to ask you if you want to provide a test version of said feature. I can provide the results of the tests.

Beta testing is welcome. Please tell me if you're still interested (in the light of the hardware limitations).

BR

[TJF]

libpruio-0.2 is out now:


New:

• Ring buffer (RB) run mode (samples analog input continously).
• PWM output in IO and RB mode (variable frequency and duty cycles).
• CAP input in IO and RB mode (analyses frequency and duty cycles of a pulse train).
• New examples *pwm_adc*, *pwm_cap*, *rb_oszi*.
• Subsystem control (enable or disable single subsystems at run-time).
• Device tree overlay included (universal pinmuxing at run-time).
• Tools included to create, compile and install universal or customized device tree overlays.
• Advanced error messages from constructor.

Changes:

• Completely renewed source code (modular now, for easier expansions).
• Completely renewed documentation (interferences between C and FB source solved).
• API adapted to modular structure (see file migration.txt.
• Version 0.0 examples adapted (*1*, *analyse*, *button*, *io_input*, *sos*, *stepper*, *oszi*, *triggers*).
• Adaptions for new FreeBASIC compiler fbc-1.00.
• Access to all subsystem registers supported.

Bugfixes:

• Pinmuxing now available.
• GPIO output fixed (former gpio_set sometimes skipped a setting).

Download (as in first post)

http://www.freebasic-portal.de/downloads/fb-on-arm/libpruio-325.html

[William Hermans]

TJF, It would be nice if you're going to link to a site to a majority of English speakers, that the link you give to us links to a written English page.

At minimum you're posting in English so yeah, be nice to us.

[TJF]

William, sorry, my fault!

"us" can find the 'brand new' English project page at

http://beagleboard.org/project/libpruio/

Don't hesitate to ask if you need further assistance on downloading.

[niro...@gmail.com]

Hey TJF,

Nice to see the update, I really happy with the new features :)

What would be the highest consistent samplerate possible with the c wrapper with 1 channel. Using the RB would be the nicest but using MM is also an option if the samplerate is higher with that.

I think if I know that I could figure out the rest myself, however it would be nice to have sample code of config&start rb/mm(possibly on max samplerate) and data retrieving in c.

Greetings,

Nils Kohrs

[TJF]

Hello Nils,

thanks for feedback!

The maximum sample rate is limited by the ADC subsystem. It's 159 kS/s (15 cycles @ 2.4 MHz + safety buffer) for a single step (channel). It neither matters if you operate in RB or MM mode, nor if you use FB or C compilers.

For me, writing C examples is exhausting and time consuming. For an experianced C programmer it should be easy to translate the FB examples rb_oszi and triggers, where you can find the code you're loocking for. (I'd appreciate it if I can include such a translation in to the documentation.)

For maximum sample rate you've to configure a customized step with no delays and no avaraging. And you've to activate this step only, like

pruio_adc_setStep(Io, 9, 4, 0, 0, 0); // step 9 for AIN-4

pruio_config(Io, Samples, 1 << 9, 6285, 4); // '1 << 9' -> step 9, '6285' ns -> 159.1 kHz

pruio_rb_start(Io);

BR

[niro...@gmail.com]

Hey TJF,

with 6285 ns I was only able to set the amount of samples to 1 without getting an error. With 6290 works everything fine.

Here is some c samplecode for you, it keeps writing all the samples to a file in burst of 1000000/4 samples per writing burst.

#include "unistd.h"
#include "stdio.h"
#include "../c_wrapper/pruio.h"


//! The main function.
int main(int argc, char **argv)
{
  FILE* oFile;
  uint8 bDiv = 4, bStep;
  uint32 bSize = 1e6;
  uint32 bsSize = bSize/bDiv;
  oFile = fopen("output","wb");
  pruIo *io = pruio_new(PRUIO_DEF_ACTIVE, 0x98, 0, 1); //! create new driver structure
  pruio_adc_setStep(io, 9, 4, 0, 0, 0); // step 9 for AIN-4
  if (pruio_config(io, bSize, 1 << 9, 6290, 0)){ // '1 << 9' -> step 9, '6285' ns -> 159.1 kHz
        printf("config failed (%s)\n", io->Errr);}
  else{
    pruio_rb_start(io);
    sleep(1);
    while(1){
      while(io->DRam[0] < (bStep+1) * bsSize && io->DRam[0] > bStep * bsSize){
        sleep(1);
      }
      printf("start writing %u\n",bStep*bsSize);
      fwrite(io->Adc->Value, sizeof(uint16), 16000, oFile);
      printf("end writing %u\n",(bStep+1)*bsSize);
      bStep = bStep+1 < bDiv ? bStep+1 : 0;
    }
  }
  pruio_destroy(io);
  return 0;
}

Greetings,

Nils Kohrs

[TJF]

Hello Nils,

thanks for the code. I think about including it in the libpruio examples folder, but your main loop is endless and the user cannot abort the program. (Shouldn't the file get closed?) Perhaps I can adapt it a bit.

Regarding the ADC speed I made some further testing and it seems that I mis-interpreted the TRM. The ADC subsystem can sample at least at 200 kS/s. This speed also works for multiple channels. Find an example of four channels at 44.1 kHz in this post. An overall sampling rate of 200 kHz was also possible (four channels).

So the limiting in the current libpruio-0.2 is too much on the safe site. If you don't want to wait for the next version, you can adapt the code by yourself (FreeBASIC compiler required). Replace in file pruio_adc.bas in function PruIo.configure(...) the lines

      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

by the following code

      d = (d * (Conf->ADC_CLKDIV + 1) * 1000) \ 24
      IF Tmr <= d ORELSE Tmr < 5000 THEN _
                           .Errr = @"sample rate too big" : RETURN .Errr

You may play a bit with the absolute value 5000. On my BBB the timing is OK up to a frequency of 240 kHz (4165). But this may vary from board to board.

[niro...@gmail.com]

Hey TJF,

I've got it compiled and working. I can't yet test if the adc keeps up since I the function generator we've ordered got out of stock.... However I changed my code a bit so it would close the files and the whole program has a end statement. It's currently 1 channel at ~220 kS/s. I haven't pushed it further because I don't know what will happen. With my understanding of the PRU I guess the PRU can't break anything on the BBB while doing that, but I don't know so I don't want to push my luck.

#include "unistd.h"
#include "stdio.h"
#include "../c_wrapper/pruio.h"


//! The main function.
int main(int argc, char **argv)
{
  FILE* oFile;
  uint8 bDiv = 4, bStep;
  uint32 bSize = 1e6;
  uint32 bsSize = bSize/bDiv;

  uint8 cycles = 2;
  char fName[12];
  int i = 0;

  pruIo *io = pruio_new(PRUIO_DEF_ACTIVE, 0x98, 0, 1); //! create new driver structure
  pruio_adc_setStep(io, 9, 4, 0, 0, 0); // step 9 for AIN-4

  if (pruio_config(io, bSize, 1 << 9, 4545, 0)){ // '1 << 9' -> step 9, '6285' ns -> 159.1 kHz

        printf("config failed (%s)\n", io->Errr);}
  else{
    pruio_rb_start(io);
    sleep(1);

    for(i=0; i<cycles; i++){
      sprintf(fName, "output.%u",i);
      oFile = fopen(fName,"wb");
      while(bStep<bDiv){

        while(io->DRam[0] < (bStep+1) * bsSize && io->DRam[0] > bStep * bsSize){
          sleep(1);
        }

        printf("writing samples %u-%u\n",bStep*bsSize, (bStep+1)*bsSize);

        fwrite(io->Adc->Value, sizeof(uint16), 16000, oFile);

        bStep++;
      }
      bStep=0;
      fclose(oFile);
    }
  }
  pruio_destroy(io);
  return 0;
}

Greetings,

Nils Kohrs

[William Hermans]

Whew ! If you're looking for "fast", you're not going about it the right way.

1) Nested loops are bad.

2) A file open, and close every cycle on the outer loop ? Is that really necessary ?  Big time performance hit.

3) spintf() as I recall is a fairly slow function.

A few things you can do to fix these issues.

Remove the nested loops and replace with a, if/else control block. Make the conditions checks that are most likely to pass more often - first. Also, simplify your math. If the numbers are going to be consistent, and non changing. Hard code the values. Multiplication and division on fast moving code will slow you down. Especially if done on floating point numbers. So unless I missed an assignment somewhere . . .

while(io->DRam[0] < (bStep+1) * bsSize && io->DRam[0] > bStep * bsSize) {

 ...
}

if bsStep which seems to be left unassigned ( 0 ) + 1 = 1

1 * <any value> is going to be that <any value> . . . Some compilers may optimize this out, but why ? It also makes the code less readable.

Also . . .

fwrite(io->Adc->Value, sizeof(uint16), 16000, oFile);



Is a potential performance hit. Quite honestly I am not sure *if* sizeof(uint16) would be checked once at compile time, or if it would be checked every cycle at run time. But you can "fix" this simply by hard coding the value. Make it a constant if you feel it makes the code more readable.

Open the file once before the loop, and close it after the loop is done. That is, if at all possible. Also there is a "trap for new players", in that if the application exits abnormally, the file may still be left opened. So a check when the application first starts may be in order.

As an aside, you can simplify the whole application by just gathering  raw data, and shifting it out to the the general purpose processor ( ARM ). Which then the main processor can be made to do all the heavy math "lifting".

Anyway I hope this is useful information, and my posting is not meant to demean, or otherwise come across as "smart-ass".

--

[niro...@gmail.com]

Thanks for the feedback. I know that I'm far from a good c programmer, but I'm not that bad.

From reading the book "The C++ Programming Language" by Bjarne Stourstrup (the maker of c++) I know a thing or two about the compiler.

First of, all sizeof(...) are replace at compile time. Secondly, all operators that can be calculated at compile time will be calculated at compile time. This makes the last two optimizations you suggest just working with the code harder.

I don't know if you've runned this code your self already, but if you would have noticed that the limiting part is the PRU coprocessor and not actually the ARM processor itself.

With that in mind option 1 is just the flavor of code you choose.

About point 3: If you want to concatenate a integer to a string/char[] there are two options. First you can convert the into to a char[] with itoa() and then use strcat(), or you use the minimal slower spintf which is more readable

And lastly about point 2, if you want to write it to multiple files, you'll have to close the old one and open the new one every time you go on to the next file.

This programs was for me to test the performance, and as you see from the one seconds sleeps I've build into it, it runs fine and a lot faster than it needs to be. Also from any of the examples included to libpruio you can expect the reader not to just copy the code 1:1 and live happily ever after. Everyone will edit it to their liking and performance needs. For me this runs fine and error handling with the file io is something you can implement your self, if you need it. This is example code and not production code...

And on a last note, you've made me aware of a little error in my code though, the line:

fwrite(io->Adc->Value, sizeof(uint16), 16000, oFile);

should be

fwrite(io->Adc->Value, sizeof(uint16), bsSize, oFile);

If you want to provide better sample code you're free to go, but please don't be that smart-ass stating facts that are only half or not at all true.

Greetings,

Nils Kohrs

[William Hermans]

If you want to provide better sample code you're free to go, but please don't be that smart-ass stating facts that are only half or not at all true.

Ok, that is just plain rude.

So, since we're being rude now. I should mention the code you pasted is C and not C++. I figured you should know this since you think you know everything.

I will tell you what. You keep on trucking on, and nesting while loops 100 deep if you like, and I'll refrain from reading your posts any further to keep my eyes from bleeding.

[niro...@gmail.com]

Hey TJF, 

I wanted to give you a heads up on my samplecode. The performance test was right in that is was that exact performance, but I shouldn't write a program in c when I'm sleepy. 

The program had some functional problems which should be fixed now. However, I'll first test it with a function generator to make sure that the code is indeed working as expected. If everything is working fine I'll post it here and you should be able to use it as c samplecode.

Greetings,

Nils Kohrs

[TJF]

Hello Nils,

I just had a closer look at your first example. Sorry, I've new concerns. It seems that the code requires to customize the size of the external memory, which is a downside for beginners. And it doesn't show the ring buffer capabilities (, you could have used MM mode as well).

From my point of view the strange of RB mode is that you can fetch any number of samples with any size of the external memory. And the example should demonstrate that point.

So for the FreeBASIC folder I created a new example called rb_file.bas

/'* \file rb_file.bas
\brief Example: fetch ADC samples in a ring buffer and save to file.

This file contains an example on how to use the ring buffer mode of
libpruio. A fixed step mask of AIN-0, AIN-4 and AIN-7 get sampled and
saved as raw data to some files.

Licence: GPLv3

Copyright 2014 by Thomas{ dOt ]Freiherr[ At ]gmx[ DoT }net


Compile by: `fbc -w all rb_file.bas`

\since 0.2
'/

' include libpruio
#INCLUDE ONCE "../pruio/pruio.bi"

CONST tSamp = 123401 _  '*< The number of samples in the files (per step).
      , tmr = 5000 _    '*< The sampling rate in ns (5000 -> 200 kHz).
   , NoStep = 3 _       '*< The number of active steps (must match setStep calls and mask).
   , NoFile = 2 _       '*< The number of files to write.
   , NamFil = "output." '*< The output file names.

VAR io = NEW PruIo()   '*< Create a PruIo structure, wakeup subsystems.

WITH *io
  DO
    IF .Errr THEN                     ?"NEW failed: " & *.Errr : EXIT DO

    IF .Adc->setStep( 9, 0, 0, 0, 0) THEN _
                     ?"step 9 configuration failed: " & *.Errr : EXIT DO
    IF .Adc->setStep(10, 1, 0, 0, 0) THEN _
                    ?"step 10 configuration failed: " & *.Errr : EXIT DO
    IF .Adc->setStep(11, 2, 0, 0, 0) THEN _
                    ?"step 11 configuration failed: " & *.Errr : EXIT DO

    VAR mask = &b111 SHL 9 _         '*< The active steps (9 to 11).
      , tInd = tSamp * NoStep _      '*< The maximum total index.
      , half = ((.ESize SHR 2) \ NoStep) * NoStep '*< The maximum index of the half ring buffer.

    IF half > tInd THEN half = tInd  '        adapt size for small files
    VAR samp = (half SHL 1) \ NoStep '*< The number of samples (per step).

    IF .config(samp, mask, tmr, 0) THEN _ '                configure driver
                                   ?"config failed: " & *.Errr : EXIT DO

    IF .rb_start() THEN _ '                       start ring buffer mode
                                 ?"rb_start failed: " & *.Errr : EXIT DO

    VAR p0 = .Adc->Value _           '*< A pointer to the start of the ring buffer.
      , p1 = p0 + half               '*< A pointer to the middle of the ring buffer.
    FOR n AS INTEGER = 0 TO NoFile - 1
      VAR fnam = NamFil & n, fnr = FREEFILE
      IF OPEN(fnam FOR OUTPUT AS fnr) THEN
        ?"Cannot open " & fnam
      ELSE
        ?"Creating file " & fnam
        VAR i = 0                    '*< Start index.
        WHILE i < tInd
          i += half
          IF i > tInd THEN '          fetch the rest (no complete chunk)
            VAR rest = tInd + half - i _
              , iEnd = IIF(p1 >= p0, rest, rest + half)
            WHILE .DRam[0] < iEnd : SLEEP 1 : WEND
            ?"  writing samples " & (tInd - rest) & "-" & (tInd - 1)
            PUT #fnr, , *p0, rest
            SWAP p0, p1 :                                        EXIT DO
          END IF

          IF p1 > p0 THEN WHILE .DRam[0] < half : SLEEP 1 : WEND _
                     ELSE WHILE .DRam[0] > half : SLEEP 1 : WEND
          ?"  writing samples " & (i - half) & "-" & (i - 1)
          PUT #fnr, , *p0, half
          SWAP p0, p1
        WEND
        ?"Finished file " & fnam
        CLOSE #fnr
      END IF
    NEXT
  LOOP UNTIL 1
  IF .Errr THEN SLEEP
END WITH

DELETE(io)

'' help Doxygen to dokument the main code
'&/** The main function. */
'&int main() {PruIo::PruIo(); AdcUddt::setStep(); PruIo::config(); PruIo::~PruIo();}

Do you like to translate that code to C to include it in the libpruio package? If so, please add a file header with your copyright notes.

BR

[TJF]

Oups, found a buck right when I posted:

line 70

            SWAP p0, p1 :                                     EXIT DO

should be

            SWAP p0, p1 :                                     EXIT WHILE

Soory!

[William Hermans]

TJF,

I'd be willing at some point to help you port some code for your project, Do you have a quick setup guide for your library ? I did read some of your documents a couple months ago, but then i got busy with many other things . . . such is life.

Other problem is that I am not exactly a hardware person so much as a software developer, and I am semi new to embedded Linux. The new to embeded Linux part shouldnt be too much of a problem, just means I need to read up on the libc functions available to me. Not being an EE however slows me down greatly however, since I do not want to fry my boards . . .

As an aside, I must have really really become accustomed to C over the last several years, BASIC syntax hurts my eyes, lol but it was the very first language I picked up 17+ years ago . . .

--

[TJF]

Am Montag, 10. November 2014 21:52:26 UTC+1 schrieb William Hermans:

TJF,

I'd be willing at some point to help you port some code for your project,

Hello William, welcome at the libpruio project.

I know about many tasks to improve the libpruio package. Some of them might be fun for you.
 

Do you have a quick setup guide for your library ?

Find the installation guide in the documentation at page Preparation.

Could you check the documentation text? It seems that you're a native speaker with good language skills. You should be able to improve the text a lot. (I could mail a pdf version, where you could add your comments.)
 

Other problem is that I am not exactly a hardware person so much as a software developer, and I am semi new to embedded Linux. The new to embeded Linux part shouldnt be too much of a problem, just means I need to read up on the libc functions available to me. Not being an EE however slows me down greatly however, since I do not want to fry my boards . . .

I'm neither an electronics engineer, nor a programmer, nor an expert on embedded systems, nor a native speaker. I think I realy know what you're talking about.

I'm looking at the project from the user point of view, evaluating how things should work and then do my best to make this happen. And, knowing there's no perfect solution, I try to learn from my failures.
 

As an aside, I must have really really become accustomed to C over the last several years, BASIC syntax hurts my eyes, lol but it was the very first language I picked up 17+ years ago . . .

Basic isn't the first programming language I used, but for me it's the most productive. I'm not speaking about the m$ dialects, which I dislike as well, and which I don't use since the middle 80's. (AFAIR QB 4.5 was the last one I tested and droped.) But there're other dialects, which are in some points more powerful than C, and easier to read for my old eyes.

The libpruio package contains some examples, as you can see at this documentation page. I think all code in folder src/c_examples could have a review. But most important, there're some examples with grafics output

• pwm_adc.bas,
  
• osci.bas,
  
• rb_oszi.bas, and
  
• triggers.bas

which I didn't translate to C code jet. My idea was to use cairo grafics library, but there might be a more common way to create short and easy C code?

Note: libpruio examples should be easy to understand for beginners and should have less than 200 lines of code.

Feel free to send further colaboration ideas and discuss details (here or PM). Or just make your choice and start.

BR

[William Hermans]

Back in the early to mid 80's I was living in Kitzingen,Germany, and I was young. If you catch my meaning.

But anyway, I am still a bit busy, but perhaps in my spare time I can read your documentation a bit at a time to be used to it. It is something I've been wanting to do for a while now . . .

--

[TJF]

Am Dienstag, 11. November 2014 19:33:33 UTC+1 schrieb William Hermans:

Back in the early to mid 80's I was living in Kitzingen,Germany, and I was young. If you catch my meaning.

A "Franke", I see. Most of my mess mates were coming from the Würzburg and Aschaffenburg area.

Your surname sounds German. I'm not living in Germany any more. I moved to the "Schluchtenscheißers".

But anyway, I am still a bit busy, but perhaps in my spare time I can read your documentation a bit at a time to be used to it. It is something I've been wanting to do for a while now . . .

 May I send (private mail) a pdf version of the documentation? You could add notes to that document to improve the text.

[William Hermans]

Sure. However I am afraid my German reading skills ( translation ) are terrible now days. I will do what I can.

--

[elt...@gmail.com]

Hey,

I'm trying to match the below modification in my version of libpruio, but while compiling I run into the following

ld: pruio.o: relocation R_ARM_THM_MOVW_ABS_NC against `a local symbol' can not be used when making a shared object; recompile with -fPIC

and I'm not sure how to get past it. I -think- that I have the freebasic compiler running correctly. Any advice would be welcome.

Thanks,

Michael Todd

[TJF]

Hi Michael,

Am Freitag, 14. November 2014 01:08:42 UTC+1 schrieb elt...@gmail.com:

Hey,

I'm trying to match the below modification in my version of libpruio, but while compiling I run into the following

ld: pruio.o: relocation R_ARM_THM_MOVW_ABS_NC against `a local symbol' can not be used when making a shared object; recompile with -fPIC

and I'm not sure how to get past it. I -think- that I have the freebasic compiler running correctly. Any advice would be welcome.

Thanks,

Michael Todd

 
if you want to compile with the old (experimental) BBB-fbc-0.90 you'll have to use the old build scripts included in libpruio-0.0.x.

But I recommend to install the new BBB_fbc-1.00, which I also use on my board now. Just follow the instructions in (only point 1)

http://users.freebasic-portal.de/tjf/Projekte/libpruio/doc/html/_cha_preparation.html#SecInstallation

BR

[andreas....@gmx.de]

Am Freitag, 14. November 2014 15:19:01 UTC+1 schrieb TJF:

But I recommend to install the new BBB_fbc-1.00, which I also use on my board now. Just follow the instructions in (only point 1)

http://users.freebasic-portal.de/tjf/Projekte/libpruio/doc/html/_cha_preparation.html#SecInstallation

Hello TJF,

thanks for librpuio and the effort you spent for this.

I followed the instructions on the side above, but still can not compile the FB examples:

- I run a BBB with a very new Debian Linux image.

- I installed everything according the documentation on the above link.

- fbc is working:

 fbc -version

 FreeBASIC Compiler - Version 1.01.0 (10-14-2014), built for linux-arm (32bit) Copyright (C) 2004-2014 The FreeBASIC development team.

However, compiling an FB example yields:

libpruio-0.2/src/examples# fbc -w all analyse.bas

/usr/local/include/freebasic/BBB/prussdrv.bi(56) error 23: File not found, "crt/sys/types.bi" in '#INCLUDE ONCE "crt/sys/types.bi" '__HEADERS__: sys/types.h'

- I have searched my system manually for "types.bi", but there is none.

Do you have any suggestions what might be missing to compile the libpruio FB examples?

Btw. The C-examples can be compiled without errors.

Thanks.

 

[Jelena Freiherr]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Hallo Herr Vogelfrei,

ich hoffe, dass eine deutschsprachige Antwort in Ihrem Sinne ist und
bedanke mich für das Interesse an libpruio.

Am 05.03.2015 um 12:54 schrieb andreas....@gmx.de:
> However, compiling an FB example yields: libpruio-0.2/src/examples#
> fbc -w all analyse.bas
> /usr/local/include/freebasic/BBB/prussdrv.bi(56) error 23: File not
> found, "crt/sys/types.bi" in '#INCLUDE ONCE "crt/sys/types.bi"
> '__HEADERS__: sys/types.h'
>
> - I have searched my system manually for "types.bi", but there is
> none.
>
> Do you have any suggestions what might be missing to compile the
> libpruio FB examples?

Bitte beachten Sie folgenden Satz auf der deutschen Downlaodseite:

Diese fbc Version ist nicht vollständig. Fehlende Dateien, z. B.
Header oder Beispiele, können aus dem GIT Repository bezogen und
nachinstalliert werden.

Mittlerweile habe ich auch ein Debian Paket erstellt, welches die
Installation vereinfachen soll. Dieses ist hier zu finden:

http://www.freebasic-portal.de/downloads/fb-on-arm/debian-package-fbc-1-01-357.html

Da ich bisher keine Zeit hatte das Paket zu testen, würde ich mich
über Ihre Rückmeldung sehr freuen. (Bitte beachten: das Paket
installiert in /usr, nicht in /usr/local. Ggf. vorhandene Dateien und
Ordner in /usr/local vor der Installation löschen.)

MfG


-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1

iEYEARECAAYFAlT4sV4ACgkQiYQAalShlZ/z8QCgiHg31ijqnDngqyWimYSnX7Gm
wGoAnjgc9twRUAjqlDt0Np75dTwhzHM3
=GitI
-----END PGP SIGNATURE-----

[andreas....@gmx.de]

[SOLVED]

Hello TJF,

I will answer in English to give other users the possibility to use this information as well.

Thank you for your answer. With this information I was able to compile the supplied libpruio FreeBASIC examples.

Steps to take (on the BeagleBone, as root, otherwise use 'sudo'):

1.) wget http://www.freebasic-portal.de/dlfiles/625/freebasic_1.01.0debian7_armhf.deb 

2.) dpkg --install freebasic_1.01.0debian7_armhf.deb 

    (Note: On http://www.freebasic-portal.de/downloads/fb-on-arm/debian-package-fbc-1-01-357.html 

              you type: freebasic_1.01.0~debian7_armhf.deb which make copy and paste from the website resulting in an error)

3.) apt-get -f install

4.) rm /usr/local/bin/fbc

5.) reboot

6.) cp -R /usr/local/include/freebasic/BBB /usr/include/freebasic/

After this, compiling fbc -w all analyse.bas works.

Thank you.

[TJF]

Thanks for feedback!

BR

[akj...@gmail.com]

Hi TJF,

I am trying to use the example you provided here to sample an analog signal.
With the default setting of tmr=5000, I am getting configuration error:

config failed: sample rate too big

It works with tmr=20000 and dumps the data into 2 files. Though the data looks to be in binary format.

Could there be something in my setup that may need tweaking to run this at 200KHz?
I am using libpruio v0.2 and installed it following the steps mentioned here.

Thanks,
Akshay

[TJF]

Hi Akshay!

Am Montag, 19. Oktober 2015 02:48:44 UTC+2 schrieb akj...@gmail.com:

I am trying to use the example you provided here to sample an analog signal.

I guess you're refering to the example rb_file, which is sampling three analog signals?
 

With the default setting of tmr=5000, I am getting configuration error:

config failed: sample rate too big

It works with tmr=20000 and dumps the data into 2 files. Though the data looks to be in binary format.

Could there be something in my setup that may need tweaking to run this at 200KHz?
I am using libpruio v0.2 and installed it following the steps mentioned here.

This example is pre-published (from next version). In libpruio-0.2 the limit checking for the timer value is too rigid. See this post on how to fix this.

 
BR

[a.toma...@brainsomeness.com]

Hi TJF,
I'm trying to solve the bug as you described to niro some posts ahead.
After I've followed the instruction on the library site, I've:

cd pruio/
vim pruio_adc.bas (modify buggy lines)
./make.sh
./build.sh

After that a file named `libpruio.so` appear in the current directory
The problem is that I can't build anything with that lib. When I try to compile the c_example shipped with the library
I run into the annoying error

sos.c:(.text+0x128): undefined reference to `pruio_new' ecc

I'm doing something wrong? Why the libpruio library that I build doesn't export the pruio_* functions?

Thanks,
Andrea

[TJF]

Hi Andrea!

It compiles OK, but the linker doesn't find the symbols (= doesn't find the binary libpruio.so).

Where did you place the new binary? It should work when you override the original binary (ie. in /usr/local/lib). Otherwise you have to update the linker cache first:

sudo ldconfig

Or you can instruct the linker to search for libraries in a custom path, like (for the current directory)

LD_LIBRARY_PATH="." & ANY_COMPILE_COMMAND

See your linker manual for details (this issue is not related to libpruio).

BR

[a.toma...@brainsomeness.com]

Hi TJF,
thank you very much for your reply. You were too fast, I was deleting the post right now.
My mistake was to build only the FreeBasic library and not the one in the folder `c_wrapper`

Sorry for waste your time.

I have another question: I'm trying to read from the ADC the sound from a microphone. So I would like to acquire data at 44100Hz
In order to achive this result I follow your documentation so I've configured the ADC as follow

pruio_config(io, 2, 0x1FE, 0x22675, 4)

I put 22675 as a hexadecimal value because if I put it as a decimal number the library continue to give me the error

config failed (sample rate too big)

Can you, kindly, put me in the right direction to achieve my goal?

Thank you very much,
Andrea

[TJF]

Hi Andrea!

Am Mittwoch, 30. März 2016 23:07:55 UTC+2 schrieb a.toma...@brainsomeness.com:

My mistake was to build only the FreeBasic library and not the one in the folder `c_wrapper`

No mistake, a lucky find. Just use the matching compiler.
 

I have another question: I'm trying to read from the ADC the sound from a microphone. So I would like to acquire data at 44100Hz
In order to achive this result I follow your documentation so I've configured the ADC as follow

pruio_config(io, 2, 0x1FE, 0x22675, 4)

I put 22675 as a hexadecimal value because if I put it as a decimal number the library continue to give me the error

config failed (sample rate too big)

Can you, kindly, put me in the right direction to achieve my goal?

It's too less code to give detailed advices. What I can see:

• You specify only 2 samples (second parameter). That's too less. Your ARM code isn't fast enough to fetch the data value by value with appropriate timing.
• You set 0x1FE as step mask (third parameter). Why do you need steps 1 to 8 (defaults to AIN-0 to AIN-7)? The maximum sampling rate for 8 channels is 25 kHz (= 200 kHz / 8).
• Your sampling rate (fourth parameter) is 7096.3 Hz (= 1e9 / 0x22765, or in decimal 1e9 / 140917). It's not possible to sample at exactly 44100 Hz, but 44101,43 Hz is possible by using 22765 (= 0x5893) as fourth parameter.

So from my point of view you should

• Adapt the step mask to the necessary channels (= steps). The correct value depends on your wiring and step configuration (code is missing).
• Increase the number of samples (use all ERam: 131070 for one step or 65536 for two steps, when using default configuration of driver uio_pruss).
• Adapt the sampling rate (to 0x5893 = 22765).

Then use RB mode to fetch the samples (and output them to a file or evaluate them directly) or MM mode for a single shot (~ 3 s recording for 1 step, 1.5 s recording for 2 steps).

BR

[Arend Lammertink]

Hello all,

I am working on a test-setup, which requires at least two pretty fast ADC inputs, like 100 kS/s or more. I worked with an Arduino until now, which is way to slow. So, I bought a BeagleBoard Green and intend to use libpruio for my project. Of course, the first step is to install the library on my board, which required a few tweaks to get working. You find my notes on what I did attached. I did a few other steps, like installing the am33x-pro-package from source, but I re-installed the Debian package after I found out the standard one is OK. As far as I can tell, the steps I documented should work on a cleanly installed board, but I can't guarantee that for the full 100%.

I am running the shipped Debian image (Debian 7.10) with "Linux beaglebone 3.8.13-bone71.1 #1 SMP Wed May 20 20:13:27 PDT 2015 armv7l GNU/Linux" on which I applied all updates using apt-get update & apt-get upgrade. I connected to the board using ssh over ethernet and did everything native on the board.

As a final note, I would suggest renaming the patched pasm to fbpasm or something, so that one does not need to overwrite the standard pasm in /usr/bin.

Best regards and thanks for this nice library!

-- Arend --

[TJF]

Hi Arend,

thanks for the detailed installation guide/protokol. It's looking good. Full sure, it'll help BBG users to adapt the code. And all BBx users find information on how to fix the ADC sampling rate limitation.

Two notes:

1. You need not disable UART2 for BBG. Instead you can disable libpruio control for pin P9_22 in file dts_universal.bas by adding a line

   M(P9_22) = "" '' right below the PIN_DEL(...) lines.
   in order to release this pin from the libpruio overlay. Also, you can free the HDMI pins by removing the line  
   PIN_DEL(HDMI_Pins)
   Adapt before running the command fbc -w all dts_universal.bas.
   

2. You described a manual installation of the FreeBASIC compiler. Meanwhile I made a Debian package, which is less painful to install/uninstall, since it gets handled by the package manager. See description pages in (en) and (de) and this download link.

Thanks for sharing your experience!

[Arend Lammertink]

Hi Thomas,

Thanks for the tips. I have been working on making a build system and debian packages for fb_prussdrv and libpruiio, etc.

First of all, I patched the original pru assembler with your changes, whereby I exchanged your '-y' switch to a '-f' switch, because '-y' suggest something like 'assume yes' and -f was not used. I forked the beagleboard/am335x_pru_package for this:

https://github.com/l4m4re/am335x_pru_package

And I sent a pull request to the beagleboard package, which has been accepted and merged. According to Jason,  it will take a while before the patch will be included in the upstream beaglebone debian repository, but it should become available at some point. The new version number for pasm with the freebasic output patch is 0.87.

Secondly, I setup my own debian repository, which includes both freebasic as well as the pru packages:

http://beagle.tuks.nl/

Thirdly, I have been working on a generic build system for a/o C(++), pasm, overlay files and freebasic, LaMake, with which I can now build the fb_prussdrv package and build a debian package, although it is still a bit rough around the edges. I am now working on building the libpruio package, with the goal of also making a debian package for that.  At this moment, only the "config" directory builds. "make install DESTDIR=/tmp/test PREFIX=/usr"  works for that, which builds&installs the overlay binary.

LaMake, fb_prussdrv as well as libpruio can be found at my giithub repository:

https://github.com/l4m4re

If anyone wishes to play around with these, you will have to make a symlink from your git copy of LaMake to /usr/local/include for gmake to be able to find LaMake.

I will continue working on building&packaging libpruio and when I'm finished, I will release debian packages on my repository for all three.

Best regards,

Arend.

[TJF]

Hi Arend!

Am Samstag, 9. Juli 2016 20:13:59 UTC+2 schrieb Arend Lammertink:

I have been working on making a build system and debian packages for fb_prussdrv and libpruiio, etc.

First of all, I patched the original pru assembler with your changes, whereby I exchanged your '-y' switch to a '-f' switch, because '-y' suggest something like 'assume yes' and -f was not used. I forked the beagleboard/am335x_pru_package for this:

https://github.com/l4m4re/am335x_pru_package

And I sent a pull request to the beagleboard package, which has been accepted and merged. According to Jason,  it will take a while before the patch will be included in the upstream beaglebone debian repository, but it should become available at some point. The new version number for pasm with the freebasic output patch is 0.87.

Sounds very good! Thanks for your support.
 

Secondly, I setup my own debian repository, which includes both freebasic as well as the pru packages:

http://beagle.tuks.nl/

Also thanks for adding my packages to your repository. I hope, users will find it. I prefer your third idea:
 

Thirdly, I have been working on a generic build system for a/o C(++), pasm, overlay files and freebasic, LaMake, with which I can now build the fb_prussdrv package and build a debian package, although it is still a bit rough around the edges. I am now working on building the libpruio package, with the goal of also making a debian package for that.  At this moment, only the "config" directory builds. "make install DESTDIR=/tmp/test PREFIX=/usr"  works for that, which builds&installs the overlay binary.

I don't know LaMake. And I have already a build system for the next libpruio release based on CMake. It provides building/installing the libraries binary/headers, building documentations (html and/or pdf) and examples (fb and/or C). The config part is missing, yet. A Debian package can get build by CPack. Unfortunately I'm not keen on building packages and didn't have time for learning, yet.
 

I will continue working on building&packaging libpruio and when I'm finished, I will release debian packages on my repository for all three.

I'd like to get in private email contact, in order to cooperate on that issue. Ie. after some final testing, I could provide the current development source (libpruio-0.4: further pins for GPIO, CAP and PWM; QEP feature; timer feature; running also under kernel 4.x; bugfixes ...) for your package and we could find a solution for the config part together (no BBW nor BBG for testing here).

If you agree, just send your response to either the email adress here, or (prefered) the one in the documentation.

Have a nice weekend!

[mesquita....@gmail.com]

Hello Mr. TJF

First of All, thank you so much for providing support on real-time tasks using a low cost plataform.

I'm trying to apply the libary "libpruio" to make a system for energy meansurement using the beaglebone black. To do this,  I need to enable 2 ADC channels, set a sample time, fil a buffer with the samples and make some calculation that includes the FFT. I'm really newbie on microprocessors, but i wrote a simple C code. The idea of this code is just to make 128 samples os the two channels and print the values. Just it:

#include "unistd.h"
#include "../c_wrapper/pruio.h" // include header
#include "time.h"


//! The main function.
int main(/*int argc, char **argv*/)
{
 float n[256];
 int a[256];
 int i=0;


  pruIo *io = pruio_new(PRUIO_DEF_ACTIVE, 0x98, 0, 1); //! create new driver structure
  pruio_adc_setStep(io, 9, 1, 0, 0, 0);                                                                  // step 9, AIN-0
  pruio_adc_setStep(io, 10, 2, 0, 0, 0);


  if (pruio_config(io, 128, 9<<10 , 156250, 4)){ // upload (default) settings, start IO mode
                              printf("config failed (%s)\n", io->Errr);}
  else {


  if (pruio_rb_start(io)) printf("rb_start failed (%s)\n", io->Errr); // start measurement


  else{
        sleep(1);


        i=io->DRam[0];
        a[i] = i;
        n[i] = io->Adc->Value[i];
        do{
                if(i != io->DRam[0]){
                        i=io->DRam[0];
                        a[i] = i;
                        n[i] = io->Adc->Value[i];
                }
        }while(io->DRam[0] < 126);

        a[io->DRam[0]] = io->DRam[0];

        n[io->DRam[0]] = io->Adc->Value[io->DRam[0]];

        for(i = 0; i<=127; i++ ){

            printf("amostra %d            -----               %f \n", a[i],  (n[i]/65536)*1.8);

        }

}

/* we're done */

}

  pruio_destroy(io);        /* destroy driver structure */

        return 0;

}

 as result, I receive this:

amostra 1            -----               0.000000
amostra 0            -----               -0.000012
amostra 2            -----               1.799561
amostra 3            -----               1.799561
amostra -1092378024            -----               -0.000012
amostra 5            -----               1.799561
amostra 6            -----               1.799561
amostra 7            -----               1.799561
amostra -1092377860            -----               0.000000
amostra 9            -----               1.799561
amostra 10            -----               1.799561
amostra 11            -----               1.799561
amostra 12            -----               1.799561
amostra 466005475            -----               0.000000
amostra 14            -----               1.799561
amostra 15            -----               1.799561
amostra 1            -----               0.000000
amostra -1225151312            -----               -0.000012
amostra 18            -----               1.799561
amostra 19            -----               1.799561
amostra 3            -----               -0.000000
amostra 21            -----               1.799561
amostra 22            -----               1.799561
amostra 23            -----               1.799561
amostra -1225186212            -----               0.000000
amostra 25            -----               1.799561
amostra 26            -----               1.799561
amostra 27            -----               1.799561
amostra 1            -----               0.000000
amostra 29            -----               1.799561
amostra 30            -----               1.799561
amostra 31            -----               1.799561
amostra 0            -----               -0.000012
amostra 33            -----               1.799561
amostra 34            -----               1.799561
amostra 35            -----               1.799561
amostra -1092377728            -----               0.000000
amostra 37            -----               1.799561
amostra 38            -----               1.799561
amostra 39            -----               1.799561
amostra 0            -----               -0.000000
amostra 41            -----               1.799561
amostra 42            -----               1.799561
amostra 43            -----               1.799561
amostra 0            -----               0.000000
amostra 45            -----               1.799561
amostra 46            -----               1.799561
amostra 47            -----               1.799561
amostra 0            -----               0.000000
amostra 49            -----               1.799561
amostra 50            -----               1.799561
amostra 51            -----               1.799561
amostra 0            -----               0.000000
amostra 53            -----               1.799561
amostra 54            -----               1.799561
amostra 55            -----               1.799561
amostra -1225159968            -----               0.000000
amostra 57            -----               1.799561
amostra 58            -----               1.799561
amostra 59            -----               1.799561
amostra -1092376444            -----               0.000000
amostra 61            -----               1.799561
amostra 62            -----               1.799561
amostra 63            -----               1.799561
amostra 0            -----               0.000000
amostra 65            -----               1.799561
amostra 66            -----               1.799561
amostra 67            -----               1.799561
amostra 6            -----               0.000000
amostra 69            -----               1.799561
amostra 70            -----               1.799561
amostra 71            -----               1.799561
amostra 0            -----               0.000000
amostra 73            -----               1.799561
amostra 74            -----               1.799561
amostra 75            -----               1.799561
amostra 0            -----               0.000000
amostra 77            -----               1.799561
amostra 78            -----               1.799561
amostra 79            -----               1.799561
amostra 0            -----               0.000000
amostra 81            -----               1.799561
amostra 82            -----               1.799561
amostra 83            -----               1.799561
amostra 0            -----               -0.000000
amostra 85            -----               1.799561
amostra 86            -----               1.799561
amostra 87            -----               1.799561
amostra 0            -----               0.000000
amostra 89            -----               1.799561
amostra 90            -----               1.799561
amostra 91            -----               1.799561
amostra -1225160672            -----               -0.000000
amostra 93            -----               1.799561
amostra 94            -----               1.799561
amostra 95            -----               1.799561
amostra 96            -----               1.799561
amostra 0            -----               -0.000000
amostra 98            -----               1.799561
amostra 99            -----               1.799561
amostra 0            -----               0.000000
amostra 101            -----               1.799561
amostra 102            -----               1.799561
amostra 103            -----               1.799561
amostra -1225162752            -----               0.000000
amostra 105            -----               1.799561
amostra 106            -----               1.799561
amostra 107            -----               1.799561
amostra -1092377440            -----               0.000000
amostra 109            -----               1.799561
amostra 110            -----               1.799561
amostra 111            -----               1.799561
amostra 0            -----               -0.000000
amostra 113            -----               1.799561
amostra 114            -----               1.799561
amostra 115            -----               1.799561
amostra 0            -----               -0.000012
amostra 0            -----               0.000000
amostra 118            -----               1.799561
amostra 119            -----               1.799561
amostra 0            -----               -0.000012
amostra 121            -----               1.799561
amostra 122            -----               1.799561
amostra 123            -----               1.799561
amostra 0            -----               0.000000
amostra 125            -----               1.799561
amostra 126            -----               1.799561
amostra -1092376512            -----               0.000000

As you can see, the index does not obey the right sequency... do you have any idea why doe it happen??

[William Hermans]

  Right from the start I see several problems with your code.

125 zero based indexes. Or is it 128 ? Or do you really want 127 indexes ? It's impossible for us to know.

do{
. . .
}while(io->DRam[0] < 126);

This is inconsistent with:

for(i = 0; i<=127; i++ ){

. . .
}

So, I have no clue what io-DRam[] *is*, but I can assume, somehow, you're storing ADC values in DRAM *somehow* Based on your comments. However, first off,  your indexes to not match one another from buffer "packaging" to buffer "unpacking". Secondly, you're not clearing your buffers(arrays) before using them. This is what the "garbage" numbers are coming from. It's just random values in memory, which by the way is very bad from a couple perspectives. But this also leaves these arrays without a NULL termination at the end. Which is very unsafe, as a potential stack overflow. At least this applies for type char[], I'd have to double check the C standard that you're using for your particular case to make sure. Which you can do more easily than I.

Additionally, your code is hard to follow. With variable names such as a, n, and i, and zero helpful comments. The code is not exactly self documenting. But here is what seems to be happening. You're only storing one ADC channel value into the first half of your array. Or maybe the conditional if statement is testing for this somehow( unclear ), and taking care of that ?

Assuming what you really want is 128 samples of the two ADC channels you mention, your code needs to change. You need to check and make sure you're never going to overflow from your arrays. Which may mean your arrays need be of size 256 + 1 for each given type. Secondly, your loops need to be consistent at whichever number of values you wish to store. Thirdly, you need to clear your arrays before you use them, which can be done at array initialization, or by using memset(), after initialization.

A couple of things worth mentioning. In your printf() statement I'm not sure of libpruio's implementation, but from my experience with the beaglebone's ADC, this does not seem right ---> (n[i]/65536)*1.8) Values output from the ADC are in range 0-4095, I'd double check to make sure that is correct. It could be that libpruio's values are different in implementation through some sort of conversation. Secondly, for some reason, it may become readily apparent that your index value may contain a lot of zero's in the middle indexes. You're going to need to look into why that it happening after you clean your code up some. As I said above. I am not familiar with libpruio's implementation, and the rest of your code is not clear enough to make a determination at a glance.

 

[mesquita....@gmail.com]

thank you so much for the answer, Mr. William.

According do the documentation of the libpruio, the variable io->DRam[0] stores the index of the last data read. This data, is stored in the vector io->Adc->Value[].
I Just want 128 samples of each chanel.

In fact, I completely agree with you: there is garbage in the resoults, and this is why it look so strange..

[William Hermans]

On Mon, Feb 6, 2017 at 9:12 AM, Rodrigo Mesquita <mesquita....@gmail.com> wrote:

Mr, Willians, thanks for your answer.

According to the lipruio's documentation, the variable io->DRam[0] contains the index of the last ADC data read.

About the part:

do{
. . .
}while(io->DRam[0] < 126);

This is inconsistent with:

for(i = 0; i<=127; i++ ){
. . .
}

, 

the for is to print the values stored. The do-while is to read the sample 1 to 126. the samples 0 and 127 are read before and after this loop, respectively.

What are you sugestions to improve my code, Mr. Hermans?

Please, in the future do not email me personally. Please email to the group, so everyone can see the answer, as this may help others in the future. It also makes it much harder for me to follow the posts, and give a proper answer. Anyway . . .

Assuming what you say is correct. Your loops are still off by two between them. The do / while() loop being 1 based( starts from 1 ) where the for() loop being zero based( starts from 0 ). To correct this most simply, change your for loop to i<=125, or i<126 if that is clearer for you.

After that, starting from the top down.

 float n[256];
 int a[256];
 int i=0;



float n[256]; is not needed. For this particular application you only need one float value for printing a voltage value in your printf() statement. In fact, in the future if you plan on expanding on this application you may wish to do away with float values entirely, send the raw PRU values to an external source( if that's what happens ) and let the external source do the heavy math. This makes what your beaglebone is doing more efficient, and if performance is needed can make a huge difference. Also, you can look into using fixed point numbers, but this would use more processor cycles than just sending out raw values.

int a[256]; Assuming 128 samples, I might change this to: int channel_n[128]; ( n representing the actual channel you're reading from ), then do all the formatting in your printf() statement. If, and when you decide to print more than one channel worth of samples. This is however more a matter of semantics,  but it'll also make your code much more readable. Again, you need to read the C standard  for the compiler you're using. It does seem possible you're using a post C99 compiler as you're not initializing the variable i within the for() loop. Again, make sure your array has enough room for a NULL termination byte, if needed. Which wouldn't be of type byte, but instead of type int.

The libpruio stuff TJF will be able to give you a much better answer on. As it's his code, and I know nearly nothing of the specifics for this code.

if (pruio_rb_start(io)) printf("rb_start failed (%s)\n", io->Errr); // start measurement


This is also a bit unclear to me, mostly due to not knowing the implementation, but I'd probably move this if() statement into a while statement. That way you can loop, and sleep 1 second between fails. Assuming the check fails more than once. Still it'd be clearer to at least me, which may not matter to you, or anyone else. Semantics . . . However, as it stands, if the check fails, you code will probably just exit. Maybe this is what you want ?

As for your index values being "off" or just plain zero in some cases. The first thought that comes to mind is that you're trying to read from the ADC too fast. But again, I have no idea what TJF's code is doing, so this may not be possible. That would be the first place I'd look though, and in fact looking at your output, that seems very possible. As every value that has a garbage index value seems to be zero, or close to it. Ask TJF how you should throttle your loop. e.g. does he have something implemented in the library, or not.

The rest of your code looks like it should work, so I'd clean up your code a bit, throttle the ADC reading loop how TJF suggests, and check your application output.

[William Hermans]

Thinking about how to "throttle" reading from the ADC to get correct values. A little more. One way you could potentially deal with that situation  could be to change both loops to a while() loop, and only increment your loop index value if the ADC index value is greater than 0. Or maybe test if the actual ADC index value is your loop index value +1. With that said, actually you would only need to throttle the ADC read loop, so the printing to screen loop could be left alone.

However, this kind of loop would be very CPU intensive, but the problem with with using usleep() is that technically htis is a system call, and in addition to adding a hard coded delay, you're likely to also have some system( between user space and kernel space ) non deterministic delay penalty inured.

[William Hermans]

Or better yet, get rid of the second loop entirely, and just print the values as you receive them. However, printf() *is* a system all that would definitely slow down your ADC read speeds. Unless you pipe the output of the application to a file. Which would not be healthy for the emmc, or sdcard you're running from.

[mesquita....@gmail.com]

I got the solutio (i think.. hehe)

 /*file doiscs.c
 Compile by: `gcc -Wall -o doiscs doiscs.c -lpruio`
 
 */
 
 #include "stdio.h"
 #include "unistd.h"
 #include "../c_wrapper/pruio.h"
 #include "time.h"
 
 int main(int argc, char **argv)
 {
  float n[256];
  float v1[128];
  float v2[128];
  int i = 0;
 
   pruIo *io = pruio_new(PRUIO_DEF_ACTIVE, 0x98, 0, 0);                                                  //! create new driver structure
   pruio_adc_setStep(io, 9, 1, 0, 0, 0);                                                                 // step 9, AIN-0
   pruio_adc_setStep(io, 10, 2, 0, 0, 0);                                                                // step 10, AIN-1
 
   if (pruio_config(io, 128, 9<<10 , 156250, 4)){
         printf("config failed (%s)\n", io->Errr);}
   else {
 
   if (pruio_rb_start(io)) printf("rb_start failed (%s)\n", io->Errr);                                   // start measurement
 
   else{
         sleep(1);
         do{
                 if(io->DRam[0] == (i)){
                         n[i] = io->Adc->Value[i];
                         i=i+1;
                 }
         }while(i < 256);

 
         for(i = 0; i<=127; i++ ){

                  v1[i] = n[2*i];
                  v2[i] = n[2*i +1];
         }
 
         printf("adc1*************\n");
         for(i=0; i<=127; i++){
                 printf("%f \n", v1[i]*1.8/65536);
         }
 
         printf("\n adc2*************\n");
         for(i=0; i<=127; i++){
                 printf("%f \n ", v2[i]*1.8/65536);
         }
 
 }
 
 }
   pruio_destroy(io);
         return 0;
 }

The error is marked in yellow. The loop condition was considering the garbage :D

  if <span style="color:rgb(102,

[William Hermans]

On Mon, Feb 6, 2017 at 11:00 AM, <mesquita....@gmail.com> wrote:

I got the solutio (i think.. hehe)

If you're happy with the code you've got, who am I to argue about it ?

[TJF]

Am Freitag, 9. Mai 2014 16:23:18 UTC+2 schrieb TJF:

Version 0.6 is out now! Major highlights:

1. Debian packages, easy installation
2. Python bindings and examples available
3. Advanced Pinmuxing: faster and unlimited
   

Click this link for details or check the online documentation.

[TJF]

Major highlights:

• PRUSS functions exported now
• New examples pruss_add (interaction between ARM and PRU)
• New example pruss_toggle (up to 100 MHz pin toggling)

Find

• more info in the docs,
• the source tree on GitHub, and
• the install instructions (debian package or self-compiled from source tree.).

[Jason Kridner]

Few feature queries:

Does the current version support remote proc? 

Does it require superuser/root execution?

Is it in the main rcn-ee package feeds? 

Thought about getting into upstream Debian?

--
For more options, visit http://beagleboard.org/discuss
---
You received this message because you are subscribed to the Google Groups "BeagleBoard" group.
To unsubscribe from this group and stop receiving emails from it, send an email to beagleboard...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/beagleboard/40e7169e-cd77-4180-9f9f-057ad534e10f%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[TJF]

Hi Jason!

We already had such questions regarding upstream Debian four years ago

in 2014. I'm still waiting for your answers.

And you moved my project page

https://beagleboard.org/p/tjfr-wordpress-com/libpruio-0-2-fast-and-easy-d-a-i-o-b9f5c8

from wordpress.com to hackster.io, without asking for my agreement.
More than six month I tried to get back access to my own webside,
before I gave up. I'm still not able to update the informations on that
page.

So why should I answer your questions now? OK, other readers may be
interested in that topics as well and I wont operate at your level:

Am Donnerstag, 20. September 2018 18:14:53 UTC+2 schrieb Jason Kridner:

Few feature queries:

Does the current version support remote proc? 

Does rproc support libpruio requirements? rproc is designed for
entertainment: for playing music or for simple data logging tasks. In
contrast libpruio targets hard realtime requirements for closed loop
controllers. The rpmsg methods are simply too slow for libpruio.

Does it require superuser/root execution?

Please read the descriptions again. It depends on the need for
pinmuxing and the system configuration. No pinmuxing -> no root
execution. In case of pinmuxing several methods are supported:
config-pin, universal device trees or LKM. The device tree solutions
(including config-pin) need root privileges. In contrast the new LKM
solution provides single source pinmuxing access from user space for
all members of system user group 'pruio'.

Is it in the main rcn-ee package feeds? 

Thought about getting into upstream Debian?

libpruio is a hardware driver for AM335[89] CPUs, so we're talking
about Beaglebone Debian. Four years ago I asked for your help. Today I
found my own solution and do not care any longer about that issue. The
project is open source, so feel free to download the source tree and
build your packages for upstream Debian. Or just copy the already built
packages. The users would appreciate that, but they can handle Arend
Lammertinks PPA solution as well.

At least the LKM in upstream Debian would be a great help for the
users, since in case of PPA it needs dkms re-compilation for each
kernel update (and > 30 MB linux-headers in order to re-compile 4 kB
code to a binary that doesn't change).

[Jason Kridner]

On Thu, Sep 20, 2018 at 2:26 PM TJF <jeli.f...@gmail.com> wrote:

Hi Jason!

We already had such questions regarding upstream Debian four years ago

in 2014. I'm still waiting for your answers.

Guess I'll search for it. Found a bit of info on your site, but I'll try to go back and find the queries.

Going back as far as I can, I found https://groups.google.com/d/msg/beagleboard/lzJge-08T9s/HnPTZ82nLCYJ. Looking newer than that, I see a lot of queries, but it seems to me Robert has been pretty good at answering.

If you can provide any hints that will help my search and get you answers, I'd be appreciative.

 

And you moved my project page

https://beagleboard.org/p/tjfr-wordpress-com/libpruio-0-2-fast-and-easy-d-a-i-o-b9f5c8

from wordpress.com to hackster.io, without asking for my agreement.

There was a mass migration from the old project pages to hackster.io via a script. The main purpose is to give a place for people to discover the projects and point them to the real source for details, rather than actually take the attention away.

BTW, the projects were never on wordpress.com, they were on beagleboard.org, and wordpress.com was simply used as one of many OpenID provider options.

Maintaining the editable pages on beagleboard.org itself had become a logistical nightmare as quality support for OpenID has waned at all the key service providers even as the technology itself had changed. My older support libraries could no longer support the handful of providers that still exist.

I believe hackster.io has a method for offering a recourse, but, fundamentally, this is your information and you just need to be able to control it. Sorry for not keeping that access/control in your clear view. Seems you have found recourse here and now on this forum.

I'm committed to making this right. I'll take it down or replace it with whatever you see fit in regards to your project.

 

More than six month I tried to get back access to my own webside,
before I gave up. I'm still not able to update the informations on that
page.

Sorry it was so hard to get my attention. I try to make myself available via http://beagleboard.org/about and some people grab my attention at times via #beagle on IRC, but e-mails frequently escape my view are are closer to blind luck if I actually see them. I promise this isn't personal, but I do get several hundred e-mails a day and I try to scan the subject lines as best I can.

This project page can be put in your name if you create a hackster.io account... not sure if that is something you want to do. Again, I wanted it to all be OpenID so that you could maintain your own credentials/identity, but the support has become too hard for it. I will credit you and provide content however you see fit in regards to your project.

 

So why should I answer your questions now? OK, other readers may be
interested in that topics as well and I wont operate at your level:

That seems a bit harsh.

Helping the other readers is indeed the point, so glad we are at least of the same mind in that regard.

 

Am Donnerstag, 20. September 2018 18:14:53 UTC+2 schrieb Jason Kridner:

Few feature queries:

Does the current version support remote proc? 

Does rproc support libpruio requirements? rproc is designed for
entertainment: for playing music or for simple data logging tasks. In
contrast libpruio targets hard realtime requirements for closed loop
controllers. The rpmsg methods are simply too slow for libpruio.

rproc is really just about putting the kernel in charge of the PRUs, rather than leaving it up to userspace. It provides an ELF parser/loader and sysfs entries for starting/stopping the processor, among other processor abstractions. Memory (/dev/mem) mapping of PRU shared memories is still completely possible in an rproc environment. There is no explicit need to utilize rpmsg. Still, the permissions issues could be a bit different. With UIO, the memory mapping of the PRU is exposed explicitly for that peripheral and the permissions on access can be set for just that memory region. No one has yet created a UIO/memory driver that exposes the PRU shared memory while running the rproc driver, though nothing should prevent that.

The Linux upstream maintainers seem to have a preference for rproc which is why I tend to recommend it. "Just works" is great, but "leverages community" is also great.

 

Does it require superuser/root execution?

Please read the descriptions again. It depends on the need for
pinmuxing and the system configuration. No pinmuxing -> no root
execution. In case of pinmuxing several methods are supported:
config-pin, universal device trees or LKM. The device tree solutions
(including config-pin) need root privileges. In contrast the new LKM
solution provides single source pinmuxing access from user space for
all members of system user group 'pruio'.

Is it in the main rcn-ee package feeds? 

Thought about getting into upstream Debian?

libpruio is a hardware driver for AM335[89] CPUs, so we're talking
about Beaglebone Debian. Four years ago I asked for your help. Today I
found my own solution and do not care any longer about that issue. The
project is open source, so feel free to download the source tree and
build your packages for upstream Debian. Or just copy the already built
packages. The users would appreciate that, but they can handle Arend
Lammertinks PPA solution as well.

My neglect clearly touched a nerve. It was never intentional or personal. This announcement clued me into your continued development and support of this library. If existing users are happy, I'd love to see more Beagle users discover and make use of it.

I know the project entry changed hosts without your knowledge, but my sniff test of packaging your library into Robert's package feeds without contacting you smelled a bit funny.

If you don't mind and, as you seem to, agree it would be helpful to users, I can check if Robert will add it to https://github.com/beagleboard/repos. 

Seeing where we are at, we should probably get over that hurdle before trying to talk to upstream Debian maintainers.

 

At least the LKM in upstream Debian would be a great help for the
users, since in case of PPA it needs dkms re-compilation for each
kernel update (and > 30 MB linux-headers in order to re-compile 4 kB
code to a binary that doesn't change).

I'll interpret this to mean the BeagleBone kernel images used in the Debian reference images. 

Having https://github.com/DTJF/libpruio/tree/master/src/lkm pre-built into the distributed kernels does indeed seem helpful. The config-pin setup should be fairly well-deployed now. I'm curious if the pinmux helpers will interfere with this module. Guess we can try.

Thanks again for the cool project and hope the frustration subsides. 

 

On Sep 20, 2018, at 6:24 AM, TJF <jeli.f...@gmail.com> wrote:

Major highlights:

• PRUSS functions exported now
• New examples pruss_add (interaction between ARM and PRU)
• New example pruss_toggle (up to 100 MHz pin toggling)

Find

• more info in the docs,
• the source tree on GitHub, and
• the install instructions (debian package or self-compiled from source tree.).

--
For more options, visit http://beagleboard.org/discuss
---
You received this message because you are subscribed to the Google Groups "BeagleBoard" group.

To unsubscribe from this group and stop receiving emails from it, send an email to beagleboard...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/beagleboard/40e7169e-cd77-4180-9f9f-057ad534e10f%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

--
For more options, visit http://beagleboard.org/discuss
---
You received this message because you are subscribed to the Google Groups "BeagleBoard" group.
To unsubscribe from this group and stop receiving emails from it, send an email to beagleboard...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/beagleboard/76724c23-79da-45cf-8247-3b4c6f3026c6%40googlegroups.com.

For more options, visit https://groups.google.com/d/optout.

--

https://beagleboard.org/about

[TJF]

Hi Jason, thanks for your broad answer.

Now I've a reversed problem: too much text for a non-native speaker :-)

Am Freitag, 21. September 2018 09:51:47 UTC+2 schrieb Jason Kridner:

On Thu, Sep 20, 2018 at 2:26 PM TJF <jeli.f...@gmail.com> wrote:

Hi Jason!

We already had such questions regarding upstream Debian four years ago

in 2014. I'm still waiting for your answers.

Guess I'll search for it. Found a bit of info on your site, but I'll try to go back and find the queries.

Going back as far as I can, I found https://groups.google.com/d/msg/beagleboard/lzJge-08T9s/HnPTZ82nLCYJ. Looking newer than that, I see a lot of queries, but it seems to me Robert has been pretty good at answering.

If you can provide any hints that will help my search and get you answers, I'd be appreciative.

I'm not interested in old answers. Let us focus on current questions.
 

 

And you moved my project page

https://beagleboard.org/p/tjfr-wordpress-com/libpruio-0-2-fast-and-easy-d-a-i-o-b9f5c8

from wordpress.com to hackster.io, without asking for my agreement.

There was a mass migration from the old project pages to hackster.io via a script. The main purpose is to give a place for people to discover the projects and point them to the real source for details, rather than actually take the attention away.

BTW, the projects were never on wordpress.com, they were on beagleboard.org, and wordpress.com was simply used as one of many OpenID provider options.

Maintaining the editable pages on beagleboard.org itself had become a logistical nightmare as quality support for OpenID has waned at all the key service providers even as the technology itself had changed. My older support libraries could no longer support the handful of providers that still exist.

I believe hackster.io has a method for offering a recourse, but, fundamentally, this is your information and you just need to be able to control it. Sorry for not keeping that access/control in your clear view. Seems you have found recourse here and now on this forum.

I'm committed to making this right. I'll take it down or replace it with whatever you see fit in regards to your project.

 

More than six month I tried to get back access to my own webside,
before I gave up. I'm still not able to update the informations on that
page.

Sorry it was so hard to get my attention. I try to make myself available via http://beagleboard.org/about and some people grab my attention at times via #beagle on IRC, but e-mails frequently escape my view are are closer to blind luck if I actually see them. I promise this isn't personal, but I do get several hundred e-mails a day and I try to scan the subject lines as best I can.

This project page can be put in your name if you create a hackster.io account... not sure if that is something you want to do. Again, I wanted it to all be OpenID so that you could maintain your own credentials/identity, but the support has become too hard for it. I will credit you and provide content however you see fit in regards to your project.

 

So why should I answer your questions now? OK, other readers may be
interested in that topics as well and I wont operate at your level:

That seems a bit harsh.

After four years of neglect and blocking my project page, what level of harshness do you expect?

I didn't want to create a wordpress account, but I did it to make the project page.

I didn't want to create a hackster account, but I did it to gain access to the project page. Now I get unwanted commercials from hackster, find no way to switch it off (it's easy to add a channel, but no way to remove one) and still have no access.

Your concepts and communication behavior forces me to waste my time, create unwanted accounts and receive commercials. Instead I want to spend my time in finding new solutions for the BB.

All I need to know is what to do to update the project page. I created a hackster account. I want to login using my GitHub.com/DTJF account. I prefer a solution that neither needs cookies nor JavaScript enabled. Can you please transfer ownership of the project page to that hackster account?
 

Helping the other readers is indeed the point, so glad we are at least of the same mind in that regard.

 

Am Donnerstag, 20. September 2018 18:14:53 UTC+2 schrieb Jason Kridner:

Few feature queries:

Does the current version support remote proc? 

Does rproc support libpruio requirements? rproc is designed for
entertainment: for playing music or for simple data logging tasks. In
contrast libpruio targets hard realtime requirements for closed loop
controllers. The rpmsg methods are simply too slow for libpruio.

rproc is really just about putting the kernel in charge of the PRUs, rather than leaving it up to userspace. It provides an ELF parser/loader and sysfs entries for starting/stopping the processor, among other processor abstractions. Memory (/dev/mem) mapping of PRU shared memories is still completely possible in an rproc environment. There is no explicit need to utilize rpmsg. Still, the permissions issues could be a bit different. With UIO, the memory mapping of the PRU is exposed explicitly for that peripheral and the permissions on access can be set for just that memory region. No one has yet created a UIO/memory driver that exposes the PRU shared memory while running the rproc driver, though nothing should prevent that.

The Linux upstream maintainers seem to have a preference for rproc which is why I tend to recommend it. "Just works" is great, but "leverages community" is also great.

I have a preference for making development on the BB as easy and as much fun as on the Arduino, and as powerfull as on a modern linux system. Sorry when this doesn't match the upstream maintainers preferences.

I neither see sense in using an ELF parser/loader nor in using a C compiler/linker for a PRU-CPU with 2K instructions memory. Writing C source I loose control over the cycles used, what makes it hard to develop for hard real-time tasks. And installing the firmware at /lib/firmware requires root privileges and doesn't meet my single source preferences.

 

Does it require superuser/root execution?

Please read the descriptions again. It depends on the need for
pinmuxing and the system configuration. No pinmuxing -> no root
execution. In case of pinmuxing several methods are supported:
config-pin, universal device trees or LKM. The device tree solutions
(including config-pin) need root privileges. In contrast the new LKM
solution provides single source pinmuxing access from user space for
all members of system user group 'pruio'.

Is it in the main rcn-ee package feeds? 

Thought about getting into upstream Debian?

libpruio is a hardware driver for AM335[89] CPUs, so we're talking
about Beaglebone Debian. Four years ago I asked for your help. Today I
found my own solution and do not care any longer about that issue. The
project is open source, so feel free to download the source tree and
build your packages for upstream Debian. Or just copy the already built
packages. The users would appreciate that, but they can handle Arend
Lammertinks PPA solution as well.

My neglect clearly touched a nerve. It was never intentional or personal. This announcement clued me into your continued development and support of this library. If existing users are happy, I'd love to see more Beagle users discover and make use of it.

I know the project entry changed hosts without your knowledge, but my sniff test of packaging your library into Robert's package feeds without contacting you smelled a bit funny.

If you don't mind and, as you seem to, agree it would be helpful to users, I can check if Robert will add it to https://github.com/beagleboard/repos. 

Seeing where we are at, we should probably get over that hurdle before trying to talk to upstream Debian maintainers.

Upstream Debian doesn't make sense from my point of view. libpruio is a special solution for BB. (To be honest I don't know any other hardware with AM335[89] CPU.)

 

At least the LKM in upstream Debian would be a great help for the
users, since in case of PPA it needs dkms re-compilation for each
kernel update (and > 30 MB linux-headers in order to re-compile 4 kB
code to a binary that doesn't change).

I'll interpret this to mean the BeagleBone kernel images used in the Debian reference images. 

Having https://github.com/DTJF/libpruio/tree/master/src/lkm pre-built into the distributed kernels does indeed seem helpful. The config-pin setup should be fairly well-deployed now. I'm curious if the pinmux helpers will interfere with this module. Guess we can try.

The LKM concept works, regardless if the pinmux helpers are present or not. But they're unnecessary. A lot of kernel memory can get saved and the boot sequence is much faster when cape-universal is disabled.

Thanks again for the cool project and hope the frustration subsides. 

Frustration subsides immediately when I see some progress. Getting the LKM in to https://github.com/beagleboard/repos would be a great start. The folder you mentioned is related to the project tree and uses variables like PROJ_NAME to fill template files. From my point of view it's better to fetch the source from the libpruio-lkm package. But Robert should know the best solution. The libpruio.ko driver is necessary. The file libpruio-lkm.service can come from package libpruio-lkm, which also adds the 'pruio' system users group.

Best regards.

[Robert Nelson]

Frustration subsides immediately when I see some progress. Getting the LKM in to https://github.com/beagleboard/repos would be a great start. The folder you mentioned is related to the project tree and uses variables like PROJ_NAME to fill template files. From my point of view it's better to fetch the source from the libpruio-lkm package. But Robert should know the best solution. The libpruio.ko driver is necessary. The file libpruio-lkm.service can come from package libpruio-lkm, which also adds the 'pruio' system users group.

The libpruio.ko module is now wired up into the build process.

https://github.com/rcn-ee/libpruio

I've got 4.14.69-ti-r76 almost ready to be tagged, so this will be the first test shortly today..

If every works, It should shoot out a "libpruio-modules-4.14.69-ti-r76" deb package.

Regards,

--

Robert Nelson
https://rcn-ee.com/

[Robert Nelson]

and just to be clear, i'm wiring it up for all the am335x kernel "channels"...

v4.x.y-ti
v4.x.y-rt-ti
v4.x.y-bone
v4.x.y-bone-rt

[Robert Nelson]

The following NEW packages will be installed:
libpruio-modules-4.14.69-ti-r76 ti-sgx-ti335x-modules-4.14.69-ti-r76
0 upgraded, 2 newly installed, 0 to remove and 1 not upgraded.
Need to get 116 kB of archives.
After this operation, 465 kB of additional disk space will be used.
Get:1 http://repos.rcn-ee.com/debian stretch/main armhf
libpruio-modules-4.14.69-ti-r76 armhf 1stretch [6,000 B]
Get:2 http://repos.rcn-ee.com/debian stretch/main armhf
ti-sgx-ti335x-modules-4.14.69-ti-r76 armhf 1stretch [110 kB]
Fetched 116 kB in 0s (276 kB/s)
Selecting previously unselected package libpruio-modules-4.14.69-ti-r76.
(Reading database ... 40952 files and directories currently installed.)
Preparing to unpack .../libpruio-modules-4.14.69-ti-r76_1stretch_armhf.deb ...
Unpacking libpruio-modules-4.14.69-ti-r76 (1stretch) ...
Selecting previously unselected package ti-sgx-ti335x-modules-4.14.69-ti-r76.
Preparing to unpack
.../ti-sgx-ti335x-modules-4.14.69-ti-r76_1stretch_armhf.deb ...
Unpacking ti-sgx-ti335x-modules-4.14.69-ti-r76 (1stretch) ...
Setting up ti-sgx-ti335x-modules-4.14.69-ti-r76 (1stretch) ...
Setting up libpruio-modules-4.14.69-ti-r76 (1stretch) ...

debian@beaglebone:~$ sudo modprobe libpruio
[sudo] password for debian:
debian@beaglebone:~$ lsmod | grep uio
libpruio 16384 0
uio_pruss 16384 0
uio_pdrv_genirq 16384 0
uio 20480 2 uio_pruss,uio_pdrv_genirq

[TJF]

Thanks Robert!

Working here as well, but

$ sudo apt install libpruio-modules
Paketlisten werden gelesen... Fertig
Abhängigkeitsbaum wird aufgebaut.      
Statusinformationen werden eingelesen.... Fertig
E: Paket libpruio-modules kann nicht gefunden werden.

doesn't work (not found). I have to specify the complete name

$ sudo apt install libpruio-modules-4.14.69-ti-r76
Paketlisten werden gelesen... Fertig
Abhängigkeitsbaum wird aufgebaut.      
Statusinformationen werden eingelesen.... Fertig
Die folgenden NEUEN Pakete werden installiert:
  libpruio-modules-4.14.69-ti-r76
0 aktualisiert, 1 neu installiert, 0 zu entfernen und 0 nicht aktualisiert.
Es müssen 6.000 B an Archiven heruntergeladen werden.
Nach dieser Operation werden 26,6 kB Plattenplatz zusätzlich benutzt.
Holen:1 http://repos.rcn-ee.com/debian stretch/main armhf libpruio-modules-4.14.69-ti-r76 armhf 1stretch [6.000 B]
Es wurden 6.000 B in 0 s geholt (10,2 kB/s).        
Vormals nicht ausgewähltes Paket libpruio-modules-4.14.69-ti-r76 wird gewählt.
(Lese Datenbank ... 159470 Dateien und Verzeichnisse sind derzeit installiert.)
Vorbereitung zum Entpacken von .../libpruio-modules-4.14.69-ti-r76_1stretch_armhf.deb ...
Entpacken von libpruio-modules-4.14.69-ti-r76 (1stretch) ...
libpruio-modules-4.14.69-ti-r76 (1stretch) wird eingerichtet ...

And when I install libpruio-lkm afterwards, DKMS checks first for the linux headers and then for the kernel module. I've to install linux-heders-`uname -r` first, before I get the expected result

~$ sudo apt install libpruio-lkm
Paketlisten werden gelesen... Fertig
Abhängigkeitsbaum wird aufgebaut.      
Statusinformationen werden eingelesen.... Fertig
Die folgenden Pakete wurden automatisch installiert und werden nicht mehr benötigt:
  libllvm5.0 libncurses5-dev libtinfo-dev libxpm-dev
Verwenden Sie »sudo apt autoremove«, um sie zu entfernen.
Die folgenden NEUEN Pakete werden installiert:
  libpruio-lkm
0 aktualisiert, 1 neu installiert, 0 zu entfernen und 0 nicht aktualisiert.
Es müssen 8.142 B an Archiven heruntergeladen werden.
Nach dieser Operation werden 32,8 kB Plattenplatz zusätzlich benutzt.
Holen:1 http://beagle.tuks.nl/debian jessie/ libpruio-lkm 0.6.2a [8.142 B]
Es wurden 8.142 B in 0 s geholt (33,0 kB/s).
Vormals nicht ausgewähltes Paket libpruio-lkm wird gewählt.
(Lese Datenbank ... 159476 Dateien und Verzeichnisse sind derzeit installiert.)
Vorbereitung zum Entpacken von .../libpruio-lkm_0.6.2a_armhf.deb ...
Entpacken von libpruio-lkm (0.6.2a) ...
libpruio-lkm (0.6.2a) wird eingerichtet ...
addgroup: Die Gruppe »pruio« existiert bereits als Systemgruppe. Programmende.
Created symlink /etc/systemd/system/multi-user.target.wants/libpruio-lkm.service → /lib/systemd/system/libpruio-lkm.service.
Loading new libpruio-lkm-0.6.2a DKMS files...
Building for 4.14.69-ti-r76 4.17.6-armv7-x7
Building initial module for 4.14.69-ti-r76
Done.

libpruio:
Running module version sanity check.

Good news! Module version 0.0 for libpruio.ko
exactly matches what is already found in kernel 4.14.69-ti-r76.
DKMS will not replace this module.
You may override by specifying --force.

depmod......

Backing up initrd.img-4.14.69-ti-r76 to /boot/initrd.img-4.14.69-ti-r76.old-dkms
Making new initrd.img-4.14.69-ti-r76
(If next boot fails, revert to initrd.img-4.14.69-ti-r76.old-dkms image)
update-initramfs..............

DKMS: install completed.
Module build for kernel 4.17.6-armv7-x7 was skipped since the
kernel headers for this kernel does not seem to be installed.

More confusing than helpful for the users :-(

Regards

[Robert Nelson]

That is correct, the way my build farm is setup, the module
(libpruio.ko) is built against a specific kernel release and packaged
against that tag..

<pkg>-modules-<uname -r>...deb

> And when I install libpruio-lkm afterwards, DKMS checks first for the linux headers and then for the kernel module. I've to install linux-heders-`uname -r` first, before I get the expected result

This is where the fun begin's in a week or two, you really won't need
that dkms layer..

For debian and ubuntu this repo is going to fill up pretty fast with
kernel tag's..

https://rcn-ee.net/repos/debian/pool/main/libp/
https://rcn-ee.net/repos/ubuntu/pool/main/libp/

I've also updated our kernel update script "update_kernel.sh" to be
aware of the the module:

https://github.com/RobertCNelson/boot-scripts/commit/d837f2b02f44fabe16353fd1226bb1f64e847c93

This sunday's image will automatically have that module pre installed
after this commit:

https://github.com/beagleboard/image-builder/commit/37c1c4257edd3b70df0d9cefc5aa65d703e681b5

Currently, i'm having fun rebuilding freebasic..

Side question, any reason to just not use git master vs the 1.0.5 tag
from years ago????

[Robert Nelson]

I now have freebasic 1.0.5 available in stretch, it was bootstrap 3
times in a standard image and now once on my deb builder. I'll
probally build/bootstrap it two more times tonight (time to run home),
to make sure it's fully okay..

[TJF]

Good night!

Am Samstag, 22. September 2018 00:03:06 UTC+2 schrieb RobertCNelson:

I now have freebasic 1.0.5 available in stretch, it was bootstrap 3
times in a standard image and now once on my deb builder.  I'll
probally build/bootstrap it two more times tonight (time to run home),
to make sure it's fully okay..

Regards,

--
Robert Nelson
https://rcn-ee.com/

Wow, so much progress in such a short time, awesome!

Side question, any reason to just not use git master vs the 1.0.5 tag
from years ago????

Arend made that package. AFAIK he used that source.

This is where the fun begin's in a week or two, you really won't need
that dkms layer..

I really don't like that layer and want to get rid of it. But currently I see no way to make the LKM available on older kernel versions. Perhaps two packages: ...-lkm and ...-lkm-dkms?

Since you're building the FreeBASIC package it seems that you aim to build all libpruio packages at your farm. If correct, great news. There'll come a pitfall at the end. For the Python binding in package python-pruio a plugin from fbdoc is necessary (fbdoc/src/bas/libpy_ctypes.so). This needs the fbdoc source tree installed at the same level as libpruio tree and 'cmakefbc .. && make' executed, ! before ! building the libpruio package.

Regards

[Arend Lammertink]

Hi all,

Great to see the progress being made on getting these packages
included in the beaglebone repository. The PPA works and is great to
begin with packaging but inclusion in the beaglebone repository is of
course much better.

On Sat, Sep 22, 2018 at 8:31 AM TJF <jeli.f...@gmail.com> wrote:
>

>> Side question, any reason to just not use git master vs the 1.0.5 tag
>> from years ago????
>
>
> Arend made that package. AFAIK he used that source.
>

Yep. I think it was one of the first packages I made. It's quite a
steep learning curve and I only needed it to be able to compile
libpruio, so I didn't really care that much about keeping it up to
date with the latest&greatest.

Best regards,

Arend.

[TJF]

Hi Arend!

Am Samstag, 22. September 2018 09:43:13 UTC+2 schrieb Arend Lammertink:

Hi all,

Great to see the progress being made on getting these packages
included in the beaglebone repository. The PPA works and is great to
begin with packaging but inclusion in the beaglebone repository is of
course much better.

You did a great job with your PPA. And from my point of view it's still important for users with older kernel versions. I'd like to keep it running up to date, at least for further 6 month, if you don't mind.

 

Best regards.

[TJF]

Major highlights:

• PocketBeagle support (experimental)
• PRU examples also for Python
• Improved Documentation

Find

• more info in the docs,
• the source tree on GitHub, and

• the install instructions (for Debian packages or self-compiled from source tree).
  

[h2o...@gmail.com]

Hi TJF, 

I am a new user to both Linux and Beaglebone, and I am stucked installing the latest LIBPRUIO via Debian packages.

Below is what I have went through, by following steps in the guide: 

1. Added PPA - OK

2. Getting Keyring - OK

wget -qO - http://beagle.tuks.nl/debian/public.key | sudo apt-key add -

Response: gpg: no valid OpenPGP data found.

But this line from wiki of the same site works:

wget -qO - http://beagle.tuks.nl/debian/pubring.gpg | sudo apt-key add -

3. Update package manager database - OK

4. Installing packages - Had to bypass dependencies for libtinfo5

 

A) Doesn't work 

 

root@beaglebone:/var/lib/cloud9# sudo apt-get install libpruio

Reading package lists... Done

Building dependency tree       

Reading state information... Done

Some packages could not be installed. This may mean that you have

requested an impossible situation or if you are using the unstable

distribution that some required packages have not yet been created

or been moved out of Incoming.

The following information may help to resolve the situation:

The following packages have unmet dependencies:

 libpruio : Depends: libtinfo5 (>= 6) but 5.9+20140913-1+b1 is to be installed

B) Updated libncurses5-dev

root@beaglebone:/var/lib/cloud9# sudo apt-get install libncurses5-dev

Reading package lists... Done

Building dependency tree       

Reading state information... Done

The following extra packages will be installed:

  libncurses5 libncursesw5 libtinfo-dev libtinfo5 ncurses-bin

Suggested packages:

  ncurses-doc

The following packages will be upgraded:

  libncurses5 libncurses5-dev libncursesw5 libtinfo-dev libtinfo5 ncurses-bin

6 upgraded, 0 newly installed, 0 to remove and 161 not upgraded.

Need to get 1,019 kB of archives.

After this operation, 230 kB disk space will be freed.

Do you want to continue? [Y/n] Y

Get:1 http://httpredir.debian.org/debian/ jessie/main libncurses5-dev armhf 5.9+20140913-1+deb8u3 [156 kB]

Get:2 http://httpredir.debian.org/debian/ jessie/main libtinfo-dev armhf 5.9+20140913-1+deb8u3 [67.8 kB]

Get:3 http://httpredir.debian.org/debian/ jessie/main libncursesw5 armhf 5.9+20140913-1+deb8u3 [103 kB]

Get:4 http://httpredir.debian.org/debian/ jessie/main libtinfo5 armhf 5.9+20140913-1+deb8u3 [271 kB]

Get:5 http://httpredir.debian.org/debian/ jessie/main libncurses5 armhf 5.9+20140913-1+deb8u3 [78.4 kB]

Get:6 http://httpredir.debian.org/debian/ jessie/main ncurses-bin armhf 5.9+20140913-1+deb8u3 [343 kB]

Fetched 1,019 kB in 1s (680 kB/s)

(Reading database ... 44826 files and directories currently installed.)

Preparing to unpack .../libncurses5-dev_5.9+20140913-1+deb8u3_armhf.deb ...

Unpacking libncurses5-dev:armhf (5.9+20140913-1+deb8u3) over (5.9+20140913-1+b1) ...

Preparing to unpack .../libtinfo-dev_5.9+20140913-1+deb8u3_armhf.deb ...

Unpacking libtinfo-dev:armhf (5.9+20140913-1+deb8u3) over (5.9+20140913-1+b1) ...

Preparing to unpack .../libncursesw5_5.9+20140913-1+deb8u3_armhf.deb ...

Unpacking libncursesw5:armhf (5.9+20140913-1+deb8u3) over (5.9+20140913-1+b1) ...

Preparing to unpack .../libtinfo5_5.9+20140913-1+deb8u3_armhf.deb ...

Unpacking libtinfo5:armhf (5.9+20140913-1+deb8u3) over (5.9+20140913-1+b1) ...

Setting up libtinfo5:armhf (5.9+20140913-1+deb8u3) ...

Processing triggers for libc-bin (2.19-18+deb8u6) ...

(Reading database ... 44825 files and directories currently installed.)

Preparing to unpack .../libncurses5_5.9+20140913-1+deb8u3_armhf.deb ...

Unpacking libncurses5:armhf (5.9+20140913-1+deb8u3) over (5.9+20140913-1+b1) ...

Setting up libncurses5:armhf (5.9+20140913-1+deb8u3) ...

Processing triggers for libc-bin (2.19-18+deb8u6) ...

(Reading database ... 44825 files and directories currently installed.)

Preparing to unpack .../ncurses-bin_5.9+20140913-1+deb8u3_armhf.deb ...

Unpacking ncurses-bin (5.9+20140913-1+deb8u3) over (5.9+20140913-1+b1) ...

Processing triggers for man-db (2.7.0.2-5) ...

Setting up ncurses-bin (5.9+20140913-1+deb8u3) ...

Setting up libtinfo-dev:armhf (5.9+20140913-1+deb8u3) ...

Setting up libncurses5-dev:armhf (5.9+20140913-1+deb8u3) ...

Setting up libncursesw5:armhf (5.9+20140913-1+deb8u3) ...

Processing triggers for libc-bin (2.19-18+deb8u6) ...

C) Downloading the package and install by bypassing the dependency:

root@beaglebone:/var/lib/cloud9# sudo apt-get download  libpruio

           root@beaglebone:/var/lib/cloud9# dpkg -i --ignore-depends=libtinfo5 libpruio_0.6.4a_armhf.deb                                                 

Selecting previously unselected package libpruio.

(Reading database ... 44824 files and directories currently installed.)

Preparing to unpack libpruio_0.6.4a_armhf.deb ...

Unpacking libpruio (0.6.4a) ...

Setting up libpruio (0.6.4a) ...

Processing triggers for libc-bin (2.19-18+deb8u6) ... 

D) Done the same bypassing for libpruio-dev, libpruio-doc

E) Encountered more issues for libpruio-lkm, even though dkms installed by bypassing libtinfo5

root@beaglebone:/var/lib/cloud9# dpkg -i --ignore-depends=libtinfo5 libpruio-lkm_0.6.4a_armhf.deb

(Reading database ... 46270 files and directories currently installed.)

Preparing to unpack libpruio-lkm_0.6.4a_armhf.deb ...

Unpacking libpruio-lkm (0.6.4a) over (0.6.4a) ...

Setting up libpruio-lkm (0.6.4a) ...

Adding group `pruio' (GID 115) ...

Done.

Loading new libpruio-lkm-0.6.4a DKMS files...

First Installation: checking all kernels...

Building only for 4.4.30-ti-r64

Module build for the currently running kernel was skipped since the

kernel source for this kernel does not seem to be installed.

Job for libpruio-lkm.service failed because the control process exited with error code.

See "systemctl status libpruio-lkm.service" and "journalctl -xe" for details.

root@beaglebone:/var/lib/cloud9# systemctl status libpruio-lkm.service

● libpruio-lkm.service - Load libpruio loadable kernel module

   Loaded: loaded (/lib/systemd/system/libpruio-lkm.service; enabled; vendor preset: enabled)

   Active: failed (Result: exit-code) since Thu 2018-11-08 07:32:35 UTC; 1min 18s ago

  Process: 15039 ExecStart=/sbin/modprobe libpruio (code=exited, status=1/FAILURE)

 Main PID: 15039 (code=exited, status=1/FAILURE)

Nov 08 07:32:35 beaglebone systemd[1]: Starting Load libpruio loadable kernel module...

Nov 08 07:32:35 beaglebone systemd[1]: libpruio-lkm.service: Main process exited, code=exited, status=1/FAILURE

Nov 08 07:32:35 beaglebone systemd[1]: Failed to start Load libpruio loadable kernel module.

Nov 08 07:32:35 beaglebone systemd[1]: libpruio-lkm.service: Unit entered failed state.

Nov 08 07:32:35 beaglebone systemd[1]: libpruio-lkm.service: Failed with result 'exit-code'.

And I am currently stucked here. I couldn't run any examples as the following errors would return:

1.c:(.text+0x14): undefined reference to `pruio_new'

1.c:(.text+0x28): undefined reference to `pruio_config'

1.c:(.text+0x8e): undefined reference to `pruio_destroy'

Here is my current debian details:

root@beaglebone:/var/lib/cloud9# cat /etc/os-release

PRETTY_NAME="Debian GNU/Linux 8 (jessie)"

NAME="Debian GNU/Linux"

VERSION_ID="8"

VERSION="8 (jessie)" 

I have few doubts that are lingering:

- The version of package libtinfo5 for debian Jessie should be 5.9+, why does my dependencies asked for 6? Is it because I haven't downgraded my BBB properly? The BBB was previously updated to latest debian image. 

- Why is kernel source for my kernel does not seem to be installed?

I am stucked for hours trying to sourcing for answers online, any help would be greatly appreciated. Thanks. 

[TJF]

Hi, sorry for your trouble and thanks for feedback!

Am Donnerstag, 8. November 2018 13:43:03 UTC+1 schrieb h2o...@gmail.com:

- The version of package libtinfo5 for debian Jessie should be 5.9+, why does my dependencies asked for 6? Is it because I haven't downgraded my BBB properly? The BBB was previously updated to latest debian image. 

I compiled on 4.14 kernel, libtinfo-6 seems to be the default on that kernel. May I ask why you downgraded? The latest debian image should solve the dependency issue.

 

- Why is kernel source for my kernel does not seem to be installed?

The libpruio-lkm package needs the kernel headers to compile the module. First install the kernel version you want to use, then execute

sudo apt install build-essential linux-headers-`uname -r`

and then re-install the libpruio-lkm package

sudo apt install libpruio-lkm

And I am currently stucked here. I couldn't run any examples as the following errors would return:

1.c:(.text+0x14): undefined reference to `pruio_new'

1.c:(.text+0x28): undefined reference to `pruio_config'

1.c:(.text+0x8e): undefined reference to `pruio_destroy'

 What command did you execute? Did you link against libpruio?

Regards

[h2o...@gmail.com]

Hi TJF,

I compiled on 4.14 kernel, libtinfo-6 seems to be the default on that kernel. May I ask why you downgraded? The latest debian image should solve the dependency issue.

May I ask which debian image that you used? Because the latest debian image is debian 9 (stretch), while the PPA hosted is using debian 8 (jessie). 

Do you mean I should use latest image for debian 8, which is Debian 8.10?

Thank you & Best Regards

[TJF]

Am Freitag, 9. November 2018 04:46:51 UTC+1 schrieb h2o...@gmail.com:

Hi TJF,

I compiled on 4.14 kernel, libtinfo-6 seems to be the default on that kernel. May I ask why you downgraded? The latest debian image should solve the dependency issue.

May I ask which debian image that you used? Because the latest debian image is debian 9 (stretch), while the PPA hosted is using debian 8 (jessie). 

The latest packages (0.6.4a) I built on 4.14 kernel (AFAIK it's Debian 9.5, stretch). You're correct, I should have built on 4.4 kernel instead. The packages built on the old kernel installs and runs on the newer, but obviously not vice versa.

 

Do you mean I should use latest image for debian 8, which is Debian 8.10?

For now, the latest image (Debian 9.5, stretch) and installing the linux-headers will solve your problems. I've to find a solution for better handling the versions in future.   

Thank you & Best Regards

Best regards

[h2o...@gmail.com]

For now, the latest image (Debian 9.5, stretch) and installing the linux-headers will solve your problems. I've to find a solution for better handling the versions in future.    

Yes thank you very much. With the latest image, and installing linux header (4.14.71-ti-r80) before installing libpruio-lkm works perfectly fine now. 

One final dump question,  how could I link the header?

/tmp/ccS0jPtl.o: In function `main':

1.c:(.text+0x14): undefined reference to `pruio_new'
1.c:(.text+0x28): undefined reference to `pruio_config'

1.c:(.text+0x8a): undefined reference to `pruio_destroy'

[h2o...@gmail.com]

For now, the latest image (Debian 9.5, stretch) and installing the linux-headers will solve your problems. I've to find a solution for better handling the versions in future.   

That works great. But I encountered issue running the example 1.c. When I try to read it (./1), it says segmentation fault. The error still existed after I take out every lines except for these two:

pruIo *io = pruio_new(PRUIO_DEF_ACTIVE, 4, 0x98, 0); 

pruio_destroy(io); 

Is it because my ADC pins are not properly linked? I have checked my ADC are running fine, by running the line: cat /sys/bus/iio/devices/iio\:device0/in_voltage0_raw

 

[TJF]

Am Freitag, 9. November 2018 11:17:57 UTC+1 schrieb h2o...@gmail.com:

Is it because my ADC pins are not properly linked? I have checked my ADC are running fine, by running the line: cat /sys/bus/iio/devices/iio\:device0/in_voltage0_raw

No, libpruio doesn't use iio. It has it's own hardware driving code (much more flexible than iio).

Post the output from

lsmod

[h2o...@gmail.com]

On Friday, 9 November 2018 18:35:46 UTC+8, TJF wrote:

Post the output from lsmod

 

debian@beaglebone:/var/lib/cloud9$ lsmod

Module                  Size  Used by

pruss_soc_bus          16384  0

evdev                  24576  1

uio_pdrv_genirq        16384  0

usb_f_mass_storage     53248  2

usb_f_acm              16384  2

u_serial               20480  3 usb_f_acm

usb_f_ecm              20480  2

usb_f_rndis            32768  4

u_ether                20480  2 usb_f_ecm,usb_f_rndis

libcomposite           65536  18 usb_f_ecm,usb_f_acm,usb_f_mass_storage,usb_f_rndis

iptable_nat            16384  0

nf_conntrack_ipv4      20480  1

nf_defrag_ipv4         16384  1 nf_conntrack_ipv4

nf_nat_ipv4            16384  1 iptable_nat

nf_nat                 32768  1 nf_nat_ipv4

nf_conntrack          143360  3 nf_conntrack_ipv4,nf_nat_ipv4,nf_nat

iptable_mangle         16384  0

iptable_filter         16384  0

libpruio               16384  0

uio_pruss              16384  0

uio                    20480  2 uio_pruss,uio_pdrv_genirq

spidev                 20480  0

pru_rproc              28672  0

pruss                  16384  1 pru_rproc

pruss_intc             16384  1 pru_rproc

ip_tables              24576  3 iptable_mangle,iptable_filter,iptable_nat

x_tables               36864  3 iptable_mangle,ip_tables,iptable_filter

[TJF]

Am Freitag, 9. November 2018 14:25:18 UTC+1 schrieb h2o...@gmail.com:

On Friday, 9 November 2018 18:35:46 UTC+8, TJF wrote:

Post the output from lsmod

 

libpruio               16384  0

debian@beaglebone:/var/lib/cloud9$ lsmod

Module                  Size  Used by

...

pru_rproc              28672  0

uio_pruss              16384  0

uio                    20480  2 uio_pruss,uio_pdrv_genirq

...

pruss                  16384  1 pru_rproc

pruss_intc             16384  1 pru_rproc

...

You're loading uio_pruss and rproc drivers at the same time. Edit your /boot/uEnv.txt file and comment out the rproc trigger

###PRUSS OPTIONS
###pru_rproc (4.4.x-ti kernel)
#uboot_overlay_pru=/lib/firmware/AM335X-PRU-RPROC-4-4-TI-00A0.dtbo
###pru_rproc (4.14.x-ti kernel)
#uboot_overlay_pru=/lib/firmware/AM335X-PRU-RPROC-4-14-TI-00A0.dtbo
###pru_uio (4.4.x-ti, 4.14.x-ti & mainline/bone kernel)
uboot_overlay_pru=/lib/firmware/AM335X-PRU-UIO-00A0.dtbo

I also recomment to rename the trigger file to pinmux device tree blob, in order get faster boot and save some memory (you won't need confog-pin any more)

cd /boot/dtbs/`uname -r` && mv am335x-boneblack-uboot-univ.dtb am335x-boneblack-uboot-univ.dtb.org

Regards

[h2o...@gmail.com]

You're loading uio_pruss and rproc drivers at the same time. Edit your /boot/uEnv.txt file and comment out the rproc trigger

###PRUSS OPTIONS
###pru_rproc (4.4.x-ti kernel)
#uboot_overlay_pru=/lib/firmware/AM335X-PRU-RPROC-4-4-TI-00A0.dtbo
###pru_rproc (4.14.x-ti kernel)
#uboot_overlay_pru=/lib/firmware/AM335X-PRU-RPROC-4-14-TI-00A0.dtbo
###pru_uio (4.4.x-ti, 4.14.x-ti & mainline/bone kernel)
uboot_overlay_pru=/lib/firmware/AM335X-PRU-UIO-00A0.dtbo

Thank you so much. I finally can see the values.  

I might post again if I stuck somewhere. I hope you don't mind :) Have a great day even though I don't know what timezone you are at. 

[Hans Leeuw]

Hi TJF,

I had exactly the same problem. I commented out the line according to your example. I don't know I was supposed to uncomment the bottom line. I tried both uncommented and commented... Anyway after reboot I am stuck with the same problem. lsmod gives the same output while the /boot/uEnv.txt file is modified and the debug information (running 1.c) is the same as well. This is the output of the c compiler:

/tmp/ccNSrhGX.o: In function `main':

1.c:(.text+0x14): undefined reference to `pruio_new'

1.c:(.text+0x28): undefined reference to `pruio_config'

1.c:(.text+0x8a): undefined reference to `pruio_destroy'

collect2: error: ld returned 1 exit status

<builtin>: recipe for target '1' failed

make: *** [1] Error 1

Best, Hans.

Op zaterdag 10 november 2018 14:06:12 UTC+1 schreef h2o...@gmail.com:

[TJF]

Hi Hans!

Am Montag, 25. Februar 2019 16:42:07 UTC+1 schrieb Hans Leeuw:

I had exactly the same problem. I commented out the line according to your example. I don't know I was supposed to uncomment the bottom line. I tried both uncommented and commented... Anyway after reboot I am stuck with the same problem. lsmod gives the same output while the /boot/uEnv.txt file is modified and the debug information (running 1.c) is the same as well.

 I need to know if you're booting from eMMC or uSD and which kernel you use (uname -r).

This is the output of the c compiler:

/tmp/ccNSrhGX.o: In function `main':

1.c:(.text+0x14): undefined reference to `pruio_new'

1.c:(.text+0x28): undefined reference to `pruio_config'

1.c:(.text+0x8a): undefined reference to `pruio_destroy'

collect2: error: ld returned 1 exit status

<builtin>: recipe for target '1' failed

make: *** [1] Error 1

That's a diferent issue. It's not related to the boot process loading drivers. Instead it's a linker problem. Assuming you installed the libpruio-dev package, then executing once the command sudo ldconfig should solve the problem.

Regards

[Hans Leeuw]

Op maandag 25 februari 2019 18:59:48 UTC+1 schreef TJF:

Hi Hans!

Hi TJF, thanks for the very quick response. 

Am Montag, 25. Februar 2019 16:42:07 UTC+1 schrieb Hans Leeuw:

I had exactly the same problem. I commented out the line according to your example. I don't know I was supposed to uncomment the bottom line. I tried both uncommented and commented... Anyway after reboot I am stuck with the same problem. lsmod gives the same output while the /boot/uEnv.txt file is modified and the debug information (running 1.c) is the same as well.

 I need to know if you're booting from eMMC or uSD and which kernel you use (uname -r).

Kernel 4.14 .71-ti-r80

Debian 9.8

I have a pocket beagle so I guess that I boot from uSD

and I use the cloud9 IDE

This is the output of the c compiler:

/tmp/ccNSrhGX.o: In function `main':

1.c:(.text+0x14): undefined reference to `pruio_new'

1.c:(.text+0x28): undefined reference to `pruio_config'

1.c:(.text+0x8a): undefined reference to `pruio_destroy'

collect2: error: ld returned 1 exit status

<builtin>: recipe for target '1' failed

make: *** [1] Error 1

That's a diferent issue. It's not related to the boot process loading drivers. Instead it's a linker problem. Assuming you installed the libpruio-dev package, then executing once the command sudo ldconfig should solve the problem.

I did that but it did not solve anything. 

Regards

[TJF]

Hi!

Am Montag, 25. Februar 2019 19:34:06 UTC+1 schrieb Hans Leeuw:

Op maandag 25 februari 2019 18:59:48 UTC+1 schreef TJF:

Hi Hans!

Hi TJF, thanks for the very quick response. 

Am Montag, 25. Februar 2019 16:42:07 UTC+1 schrieb Hans Leeuw:

I had exactly the same problem. I commented out the line according to your example. I don't know I was supposed to uncomment the bottom line. I tried both uncommented and commented... Anyway after reboot I am stuck with the same problem. lsmod gives the same output while the /boot/uEnv.txt file is modified and the debug information (running 1.c) is the same as well.

 I need to know if you're booting from eMMC or uSD and which kernel you use (uname -r).

Kernel 4.14 .71-ti-r80

Debian 9.8

I have a pocket beagle so I guess that I boot from uSD

and I use the cloud9 IDE

Please post the output from

lsmod | grep uio
ls -l /dev/uio*
ls -l /sys/devices/

This is the output of the c compiler:

/tmp/ccNSrhGX.o: In function `main':

1.c:(.text+0x14): undefined reference to `pruio_new'

1.c:(.text+0x28): undefined reference to `pruio_config'

1.c:(.text+0x8a): undefined reference to `pruio_destroy'

collect2: error: ld returned 1 exit status

<builtin>: recipe for target '1' failed

make: *** [1] Error 1

That's a diferent issue. It's not related to the boot process loading drivers. Instead it's a linker problem. Assuming you installed the libpruio-dev package, then executing once the command sudo ldconfig should solve the problem.

I did that but it did not solve anything.

What happens when you compile from command line

gcc -Wall -o 1 1.c -lpruio

Regards

[TJF]

Upps!

Am Dienstag, 26. Februar 2019 06:41:36 UTC+1 schrieb TJF:

Please post the output from

lsmod | grep uio
ls -l /dev/uio*
ls -l /sys/devices/

Should be

lsmod | grep uio
ls -l /dev/uio*

ls -l /sys/devices/platform/libpruio

[Hans Leeuw]

debian@beaglebone:/var/lib/cloud9$ lsmod | grep uio

uio_pdrv_genirq        16384  0

libpruio               16384  0

uio_pruss              16384  0

uio                    20480  2 uio_pruss,uio_pdrv_genirq

debian@beaglebone:/var/lib/cloud9$ ls -l /dev/uio*

crw-rw---- 1 root users 243, 0 Feb 25 19:11 /dev/uio0

crw-rw---- 1 root users 243, 1 Feb 25 19:11 /dev/uio1

crw-rw---- 1 root users 243, 2 Feb 25 19:11 /dev/uio2

crw-rw---- 1 root users 243, 3 Feb 25 19:11 /dev/uio3

crw-rw---- 1 root users 243, 4 Feb 25 19:11 /dev/uio4

crw-rw---- 1 root users 243, 5 Feb 25 19:11 /dev/uio5

crw-rw---- 1 root users 243, 6 Feb 25 19:11 /dev/uio6

crw-rw---- 1 root users 243, 7 Feb 25 19:11 /dev/uio7

debian@beaglebone:/var/lib/cloud9$ ls -l /sys/devices/

total 0

drwxr-xr-x  5 root root 0 Jan  1  2000 armv7_cortex_a8

drwxr-xr-x  3 root root 0 Jan  1  2000 breakpoint

drwxr-xr-x 20 root root 0 Jan  1  2000 platform

drwxr-xr-x  3 root root 0 Jan  1  2000 soc0

drwxr-xr-x  3 root root 0 Jan  1  2000 software

drwxr-xr-x  6 root root 0 Jan  1  2000 system

drwxr-xr-x  3 root root 0 Jan  1  2000 tracepoint

drwxr-xr-x 14 root root 0 Jan  1  2000 virtual

debian@beaglebone:/var/lib/cloud9$ ls -l /sys/devices/platform/libpruio

total 0

-rw-r--r-- 1 root root  4096 Feb 26 19:56 driver_override

-r--r--r-- 1 root root  4096 Feb 26 19:56 modalias

drwxr-xr-x 2 root root     0 Feb 26 19:56 power

-rw-rw-r-- 1 root pruio 4096 Feb 25 19:11 state

lrwxrwxrwx 1 root root     0 Feb 26 19:56 subsystem -> ../../../bus/platform

-rw-r--r-- 1 root root  4096 Feb 25 19:11 uevent

debian@beaglebone:/var/lib/cloud9$

And compiling from command line seems to work!!! So I have to link something in Cloud9?

Hmmm, at least it is not your package!!!

Thanks a lot.

Op dinsdag 26 februari 2019 06:56:30 UTC+1 schreef TJF:

[TJF]

Am Dienstag, 26. Februar 2019 21:05:47 UTC+1 schrieb Hans Leeuw:

And compiling from command line seems to work!!! So I have to link something in Cloud9?

Hmmm, at least it is not your package!!!

Thanks a lot.

You're welcome!

I hope that the example not only compiles, but also runs as expected.

From my point of view Cloud9 is unusable slow. I use Geany IDE here.

Good luck for your project!

[donp...@gmail.com]

First time post. Thank you for all your work on libpruio.

I am trying the pwm_cap example but am getting the following error:

sudo ./pwm_cap

failed setting input @P_IN (pin P9_42 claimed by: ocp:P9_42_pinmux)

I am running 4.14 and have installed from the Debian packages, including libpruio, libpruio-dev and libpruio-lkm. I have made the following changes to uEnv.txt...

• enable_uboot_cape_universal=0
  
• uboot_overlay_pru=/lib/firmware/AM335X-PRU-UIO-00A0.dtbo
  

What else might I be missing? Thank you for the help.

Don

[Robert Nelson]

On Sun, Mar 3, 2019 at 6:49 AM <donp...@gmail.com> wrote:

First time post. Thank you for all your work on libpruio.

I am trying the pwm_cap example but am getting the following error:

sudo ./pwm_cap

failed setting input @P_IN (pin P9_42 claimed by: ocp:P9_42_pinmux)

I am running 4.14 and have installed from the Debian packages, including libpruio, libpruio-dev and libpruio-lkm. I have made the following changes to uEnv.txt...

• enable_uboot_cape_universal=0
  
• uboot_overlay_pru=/lib/firmware/AM335X-PRU-UIO-00A0.dtbo
  

What else might I be missing? Thank you for the help.

P9_42 is odd, let's what you have configured.

sudo /opt/scripts/tools/version.sh

Regards,

[donp...@gmail.com]

Thank you for looking at this. Output of the command you requested...

debian@beaglebone:/usr/share/doc/libpruio-dev/examples$ sudo /opt/scripts/tools/version.sh

git:/opt/scripts/:[1aa73453b2c980b75e31e83dab7dd8b6696f10c7]

eeprom:[A335BNLTEIA00917BBBK4F44]

model:[TI_AM335x_BeagleBone_Black]

dogtag:[BeagleBoard.org Debian Image 2018-10-07]

bootloader:[eMMC-(default)]:[/dev/mmcblk1]:[U-Boot 2018.09-00002-g0b54a51eee]:[location: dd MBR]

kernel:[4.14.71-ti-r80]

nodejs:[v6.17.0]

uboot_overlay_options:[enable_uboot_overlays=1]

uboot_overlay_options:[uboot_overlay_pru=/lib/firmware/AM335X-PRU-UIO-00A0.dtbo]

uboot_overlay_options:[enable_uboot_cape_universal=0]

pkg check: to individually upgrade run: [sudo apt install --only-upgrade <pkg>]

pkg:[bb-cape-overlays]:[4.4.20190227.0-0rcnee0~stretch+20190227]

pkg:[bb-wl18xx-firmware]:[1.20190227.1-0rcnee0~stretch+20190227]

pkg:[kmod]:[23-2rcnee1~stretch+20171005]

pkg:[librobotcontrol]:[1.0.4-git20190107.0-0rcnee0~stretch+20190108]

pkg:[firmware-ti-connectivity]:[20180825+dfsg-1rcnee1~stretch+20181217]

groups:[debian : debian adm kmem dialout cdrom floppy audio dip video plugdev users systemd-journal i2c bluetooth netdev cloud9ide gpio pwm eqep admin spi tisdk weston-launch xenomai pruio]

cmdline:[console=ttyO0,115200n8 bone_capemgr.uboot_capemgr_enabled=1 root=/dev/mmcblk1p1 ro rootfstype=ext4 rootwait coherent_pool=1M net.ifnames=0 quiet]

dmesg | grep pinctrl-single

[    1.122289] pinctrl-single 44e10800.pinmux: 142 pins at pa f9e10800 size 568

dmesg | grep gpio-of-helper

[    1.134289] gpio-of-helper ocp:cape-universal: ready

END

debian@beaglebone:/usr/share/doc/libpruio-dev/examples$

I also tried P9_28 since I believe that is the other pru eCAP pin. I got the following error...

debian@beaglebone:/usr/share/doc/libpruio-dev/examples$ sudo ./pwm_cap

failed setting input @P_IN (pin P9_28 claimed by: 48038000.mcasp)

Don

[Robert Nelson]

Okay, P9_28 makes more sense, disable the 'audio' part of hdmi..

disable_uboot_overlay_audio=1

[TJF]

Hi Don!

Am Sonntag, 3. März 2019 13:49:12 UTC+1 schrieb Don Pancoe:

I am trying the pwm_cap example but am getting the following error:

sudo ./pwm_cap

failed setting input @P_IN (pin P9_42 claimed by: ocp:P9_42_pinmux)

I am running 4.14 and have installed from the Debian packages, including libpruio, libpruio-dev and libpruio-lkm. I have made the following changes to uEnv.txt...

• enable_uboot_cape_universal=0
  
• uboot_overlay_pru=/lib/firmware/AM335X-PRU-UIO-00A0.dtbo
  

What else might I be missing? Thank you for the help.

That's a uBoot issue. Although you configured in file /boot/uEnv.txt the variable enable_uboot_cape_universal=0, the cape universal stuff gets loaded and claims all free pins. By default libpruio respects these claims. You can either

1. call the constructor with bit PRUIO_ACT_FREMUX set, in order to activate free pinmuxing (note: in this case libpruio can override the pinmux modes of all CPU balls, so it's a quick and dirty, and also dangerous solution), or
   
2. help uBoot to do its work by renaming (or removing) the device tree blob that triggers the cape universal stuff (/boot/dtbs/`uname -r`/am335x-boneblack-uboot-univ.dtb).

I recommend the second solution, since it makes (nearly) all pins free for libpruio, and also saves a lot of kernel memory (the blob is > 150 kB), as well as speeds up the boot process. (Note: pins P9_19 and P9_20 will still be claimed.)

Regards

PS: When you copy the example sources to your home directory and add yourself to the user gruop pruio, you can work from user space (no admin privileges necessar = omit sudo).

[donp...@gmail.com]

Thank you again. While I was disabling HDMI (both audio and video, just for good measure) in /boot/uEnv.txt, I noticed that I had incorrectly disabled the universal cape earlier. What I did was to change the value from one to zero as follows...

###Cape Universal Enable

enable_uboot_cape_universal=0

...but I should have commented the line out like this...

###Cape Universal Enable

#enable_uboot_cape_universal=1

So now the pwm_cap example is working on both P9_28 and P9_42.

Don

[TJF]

Thanks for feetback! So it seems to be partially fixed now.

Am Montag, 4. März 2019 12:54:23 UTC+1 schrieb Don Pancoe:

Thank you again. While I was disabling HDMI (both audio and video, just for good measure) in /boot/uEnv.txt, I noticed that I had incorrectly disabled the universal cape earlier. What I did was to change the value from one to zero as follows...

###Cape Universal Enable

enable_uboot_cape_universal=0

...but I should have commented the line out like this...

###Cape Universal Enable

#enable_uboot_cape_universal=1

So now the pwm_cap example is working on both P9_28 and P9_42.

In earlier kernel versions this didn't work.

Good luch for your project!

[78b...@gmail.com]

Hi TJF,

I was previously using iio but due to ADC sampling rate issues, I've been trying to use libpruio on my BBB wireless with the latest image from beaglebone (i.e Debian 9.5, 4.14.71-ti-r80) on an SD card. 

I've installed libpruio through sudo apt-get install libpruio libruio-dev libpruio-lkm libpruio-doc 

I've read some of the troublshooting on this thread and followed quite a few steps but I'm encountering a similar problem to the others mentionned here, once compiled the 1.c program goes to segmentation fault.

lsmod outputs this:

root@beaglebone:/var/lib/cloud9# lsmod

Module                  Size  Used by

xt_conntrack           16384  1

ipt_MASQUERADE         16384  1

nf_nat_masquerade_ipv4    16384  1 ipt_MASQUERADE

aes_arm_bs             20480  0

crypto_simd            16384  1 aes_arm_bs

cryptd                 24576  1 crypto_simd

wl18xx                110592  0

wlcore                237568  1 wl18xx

mac80211              696320  2 wl18xx,wlcore

cfg80211              622592  3 wl18xx,wlcore,mac80211

bnep                   28672  2

hci_uart               69632  0

btqca                  16384  1 hci_uart

bluetooth             552960  24 hci_uart,btqca,bnep

ecdh_generic           28672  1 bluetooth

wlcore_sdio            16384  0

evdev                  24576  1

uio_pdrv_genirq        16384  0

usb_f_mass_storage     53248  2

usb_f_acm              16384  2

u_serial               20480  3 usb_f_acm

usb_f_ecm              20480  2

usb_f_rndis            32768  4

u_ether                20480  2 usb_f_ecm,usb_f_rndis

libcomposite           65536  18 usb_f_ecm,usb_f_acm,usb_f_mass_storage,usb_f_rndis

iptable_nat            16384  1

nf_conntrack_ipv4      20480  3

nf_defrag_ipv4         16384  1 nf_conntrack_ipv4

nf_nat_ipv4            16384  1 iptable_nat

nf_nat                 32768  2 nf_nat_masquerade_ipv4,nf_nat_ipv4

nf_conntrack          143360  6 nf_conntrack_ipv4,ipt_MASQUERADE,nf_nat_masquerade_ipv4,xt_conntrack,nf_nat_ipv4,nf_nat

iptable_mangle         16384  0

iptable_filter         16384  1

libpruio               16384  0

uio_pruss              16384  0

uio                    20480  2 uio_pruss,uio_pdrv_genirq

spidev                 20480  0

pruss_soc_bus          16384  0

pru_rproc              28672  0

pruss                  16384  1 pru_rproc

pruss_intc             16384  1 pru_rproc

ip_tables              24576  3 iptable_mangle,iptable_filter,iptable_nat

x_tables               36864  5 iptable_mangle,ip_tables,iptable_filter,ipt_MASQUERADE,xt_conntrack

I've modified /boot/uEvent.txt to stoppru_rproc from loading as suggested and rebooted but the output of lsmod stays the same (and the program still goes to segfault).

modification in uEvent.txt:

###PRUSS OPTIONS

###pru_rproc (4.4.x-ti kernel)

##uboot_overlay_pru=/lib/firmware/AM335X-PRU-RPROC-4-4-TI-00A0.dtbo

###pru_rproc (4.14.x-ti kernel)

##uboot_overlay_pru=/lib/firmware/AM335X-PRU-RPROC-4-14-TI-00A0.dtbo

###pru_uio (4.4.x-ti, 4.14.x-ti & mainline/bone kernel)

uboot_overlay_pru=/lib/firmware/AM335X-PRU-UIO-00A0.dtbo

###

I went so far as to remove AM335X-PRU-RPROC-4-14-TI-00A0.dtbo and AM335X-PRU-RPROC-4-4-TI-00A0.dtbo from /lib/firmware, to no avail.

Additionally the output of ls -l /dev/uio* is "no such file or directory", I don't know why.

root@beaglebone:/var/lib/cloud9# ls -l /dev/uio*

ls: cannot access '/dev/uio*': No such file or directory

And in case this helps:

root@beaglebone:/var/lib/cloud9# ls -l /sys/devices/platform/libpruio

total 0

-rw-r--r-- 1 root root  4096 Mar 21 14:00 driver_override

-r--r--r-- 1 root root  4096 Mar 21 14:00 modalias

drwxr-xr-x 2 root root     0 Mar 21 14:00 power

-rw-rw-r-- 1 root pruio 4096 Mar 21 13:36 state

lrwxrwxrwx 1 root root     0 Mar 21 14:00 subsystem -> ../../../bus/platform

-rw-r--r-- 1 root root  4096 Mar 21 13:36 uevent

Do you have a lead on what the problem might be?

In advance, thank you,

Baptiste

[Robert Nelson]

Let's see more details..

sudo /opt/scripts/tools/version.sh