Trackback Error running rb_file.py on BBB, fresh installation

I am currently trying to run the example rb_file .py however whenever I do I get a traceback error:

bbb_error.JPG

I am not quite sure how to fix this error, however I went into the file (pruio.py) and located the lines that it stems from:

bbb_error2.JPG

I’m pretty new to this library in general and as such don’t know much about how to fix this kind of stuff, so any help would be greatly appreciated!

Upps. This is an auto-generated bug in version 0.6.4c. Thanks for reproting.

Just delete the 3 lines around PruReady. You wont need them. Then save the file.

Sorry for your trouble.

Thanks for the reply that solved my problem, however, I have a new one. Running the rb_file.py now throws the error:

BBBnewError.JPG

Any idea what could be causing this? I have not made any modifications to this file. And I have the three suggested libraries installed on the latest 0.6.4c version. (python-pruio libpruio-lkm libpruio-doc).

Your system is not prepared for libpruio. Either the kernel driver uio_pruss doesn’t load at all, or the driver cannot create the files /dev/uio[0-7] due to miss-configuration. For further help I’d need the output from

`

`

`

lsmod | grep uio
ls -l /dev/uio*
ls -l /sys/devices/platform/libpruio
sudo /opt/scripts/tools/version.sh
`

`

`

Regards

Here are my outputs from each command you gave (in order):

BBB1.JPG

bbb2.JPG

bbb3.JPG

bbb4.JPG

Let me know if you need any other information from me!

Sir,

I am not contributing much to this conversation but wish to offer a suggestion. For the sake of searchability in the future, and readability now, it is usually better to copy and paste the text directly into your email rather than using screen shots.

On some questions you might get more help that way.

Best regards,

Jim

bbb3.JPG

bbb2.JPG

BBB1.JPG

bbb4.JPG

@Jim F: Thank’s for the helpfull hint!

@derkin@gmail.com

Comment the RPROC line in file /boot/uEnv.txt. It should look like

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

After saving and rebooting, the command ls -l /dev/uio* should output

crw-rw---- 1 root users 243, 0 Apr 29 06:42 /dev/uio0
crw-rw---- 1 root users 243, 1 Apr 29 06:42 /dev/uio1
crw-rw---- 1 root users 243, 2 Apr 29 06:42 /dev/uio2
crw-rw---- 1 root users 243, 3 Apr 29 06:42 /dev/uio3
crw-rw---- 1 root users 243, 4 Apr 29 06:42 /dev/uio4
crw-rw---- 1 root users 243, 5 Apr 29 06:42 /dev/uio5
crw-rw---- 1 root users 243, 6 Apr 29 06:42 /dev/uio6
crw-rw---- 1 root users 243, 7 Apr 29 06:42 /dev/uio7

Regards

Thanks for the tip on text vs pictures, I will definitely take that in mind before I make new posts. That fixed my issue and I am now able to run the file, thank you so much for your help. One last question I have is how do I read the data that is written in the output.x file that is written by rb_file.py. Since its raw data I cant sudo nano the files and I am not quite sure how to convert it to something like a .txt or csv file that I can then parse through. Any suggestions on how I would do this?

Hi Sean!

Hi Jim,

“Never use sudo during development. Instead add yourself (your user ID) to the group pruio, and work from user space.”

May I ask why?and how?

Charles

TJF於 2019年4月30日星期二 UTC+8上午3時18分27秒寫道:

Okay, do you understand how the data is written in C, and how in C I could convert the data to readable data? I think I understand how to transport that from C to python but I don’t understand the initial translation from the written form to a human-readable form.

Hi Charles!

May I ask why?

During development bugs may lead in mal-functions. The risc of damaging the system is mutch smaller in user space. And when you write some data, you have to spend much of work in managing the file access, in order to read the data from user space. It’s safer, more easy and faster to develop in user space.

and how?

11 hours ago, TJF wrote:

Instead add yourself (your user ID) to the group pruio, and work from user space.

Regards

This link helps.

On Mon, 29 Apr 2019 10:23:25 -0700 (PDT), Sean Landerkin
<derkinmail.me@gmail.com> declaimed the
following:

Thanks for the tip on text vs pictures, I will definitely take that in mind
before I make new posts. That fixed my issue and I am now able to run the
file, thank you so much for your help. One last question I have is how do I
read the data that is written in the output.x file that is written by
rb_file.py. Since its raw data I cant sudo nano the files and I am not
quite sure how to convert it to something like a .txt or csv file that I
can then parse through. Any suggestions on how I would do this?

  Have you ever shown the contents of your rb_file.py ? (or, at least,
the section the does the file output, along with a sample of what the data
looks like /in the language -- not what you'd like to see later/

  The best place to convert the data format for later use would be in
that file (change whatever write statements you are using).

  The alternative would be to use another Python script to /read/ the
file and then convert the data to something usable. After all, if you wrote
it with Python, the equivalent type of read operation should handle it.

Hi Dennis!

Have you ever shown the contents of your rb_file.py ?

http://users.freebasic-portal.de/tjf/Projekte/libpruio/doc/html/rb__file_8py_source.html

The best place to convert the data format for later use would be in
that file (change whatever write statements you are using).

Not a good idea. The example is about sampling a big number of ADC values at high speed, more than the RAM memory can hold. The ARM CPU is simply not fast enough for fetching, converting and writing the data at the same time.

The alternative would be to use another Python script to /read/ the
file and then convert the data to something usable. After all, if you wrote
it with Python, the equivalent type of read operation should handle it.

That has been said already.

Regards

On Tue, 30 Apr 2019 10:20:51 -0700 (PDT), TJF
<jeli.freiherr@gmail.com> declaimed the
following:

Not a good idea. The example is about sampling a big number of ADC values
at high speed, more than the RAM memory can hold. The ARM CPU is simply not
fast enough for fetching, converting and writing the data at the same time.

  You're already using Python -- a byte-code interpreted language. If
that's fast enough to write the data as is, it can probably handle
conversion at the same time. (especially as you have a 1millisecond
polling loop!)

  However...

  If I interpret that code, the output is just a sequence of 16bit
integers. Rudimentary post processing (Python 3.4+ to get the iterator)
{UNTESTED}

You’re talking about up to 200,000 samples per second. Neither FreeBASIC, nor C, nor assembler code can write human readable numbers that fast. Yes, probably Python can.

Regards

@Sean Landerkin

I found a bug: the p1 pointer computation is wrong. Only the first and all odd chunks contain valid data. The even chunks contain garbage.

In order to get valid data you’ll have to replace the line

p1 = cast(byref(p0, half), POINTER(c_ushort))

by

p1 = cast(byref(p0.contents, (half << 1)), POINTER(c_ushort))

(Computing simple pointers is pretty complicated in Python.)

Thank you @TJF and @Dennis for your help, I figured out everything I needed to and probably wouldn’t have without your help! I modified the code suggested by Dennis to be able to loop over the multiple output.x files generated, and had it write the values to a .csv to be easily readable! Here is the code for anyone who wants to use it:

`

import struct
import csv
import array

#Note this file assumes you are using 7 outputs in rb_file.py and assumes that you have
#not changed the file naming convention. You must use command Python3 to run this file!

CHNK_SAMPLES = 64

rdr = struct.Struct(“H”)

write = open(“data.csv” , “w”) #Opens a csv file called data.csv in write mode
csvwriter = csv.writer(write, delimiter = ‘,’, quotechar = ‘"’, quoting = csv.QUOTE_MINIMAL) #sets up the csv writer where a , seperates data entries and ‘’ is used for quotation
counter = 0 #sets up a counter used to iterate over the various data output files
fileName = “output.%u” #follows the same naming format as used in rb_file.py
datarr = array.array(‘f’,[0,0,0,0,0,0,0]) #sets up an array of length 7 that will contain floats
i = 0 #sets up the index for looping over our array
while True:
try:
fin = open(fileName % counter,“rb”) #opens the output file corresponding to the counter value in read binary mode
print("Now Reading: " + fileName % counter) #updates the user on the current file being read
while True:
chnk = fin.read(2*CHNK_SAMPLES) #gathers data from the output file in chunks
if not chnk: break
for smpl in rdr.iter_unpack(chnk): #iterates over the values found in the chunk
datarr[i] = smpl[0]*1.8/4095 #converts the raw data into voltge form and stores it in the ith entry
if(i == 6): #if we have filled the array
csvwriter.writerow([datarr[0],datarr[1],datarr[2],datarr[3],datarr[4],datarr[5],datarr[6]]) #writes the data values to the csv
i = 0 #resets the index and the array values to 0
datarr[0]=0
datarr[1]=0
datarr[2]=0
datarr[3]=0
datarr[4]=0
datarr[5]=0
datarr[6]=0
else:
i= i+1
counter = counter + 1 #raises the counter so we can move onto the next file
fin.close() #closes the previous file
except IOError: #this will trigger when you run out of data files to loop over
print(“No file called: " + fileName % counter + " found. This may be because you ran out of data.”)
write.close() #closes the csv file
break

`
Any suggestions on modifications are welcome

On Wed, 15 May 2019 08:17:50 -0700 (PDT), Sean Landerkin
<derkinmail.me@gmail.com> declaimed the
following:

  NOTE: if you KNOW the data will be in "records" of 7 values (and you
never have an "odd" record) you could...

CHNK_SAMPLES = 64

  Change that to 7 (it will mean more reads in the main loop, but...)

rdr = struct.Struct("H")

  Change to "HHHHHHH" -- will interpret all 7 values in one call to the
unpack and...

i = 0 #sets up the index for looping over our array

  Probably don't need this phase

               while True:
                       chnk = fin.read(2*CHNK_SAMPLES) #gathers data from
the output file in chunks
                       if not chnk: break

  With above changes, "chnk" should contain exactly 7 samples (14 bytes),
and
    smpls = rdr.unpack(chnk)
should be a tuple or list (I haven't opened the help file to check) of all
seven.

                               datarr[i] = smpl[0]*1.8/4095 #converts the
raw data into voltge form and stores it in the ith entry

    datarr = [smpl * 1.8 / 4095 for smpl in smpls]

should do the conversion (you probably don't need the array initializer
either since this flat out creates a regular list of values).

                               if(i == 6): #if we have filled the array

  And since we know it is 7 values at a time, no need to test...
                                        

csvwriter.writerow([datarr[0],datarr[1],datarr[2],datarr[3],datarr[4],datarr[5],datarr[6]])

  I think just

csvwrite.writerow(datarr)

would then suffice -- why index each element of the list, only to wrap them
back into a list.

#writes the data values to the csv
                                       i = 0 #resets the index and the
array values to 0
                                       datarr[0]=0
                                       datarr[1]=0
                                       datarr[2]=0
                                       datarr[3]=0
                                       datarr[4]=0
                                       datarr[5]=0
                                       datarr[6]=0
                               else:
                                       i= i+1

... and not needed since the read/chunk and unpack is now working 7 values
at a time.