Slow down, take a deep breath! I try to understand your system.
The first question is why is uio5 different than the others. By default since kernel 4.14 all devices are owned by root users. Why do you get root root for uio5? Why are all dates 2016 Nov., while uio5 is from today?
Please reload the driver and post the output from
sudo rmmod uio_prusssudo modprobe uio_pruss ls -l /dev/uio* dmesg | grep uio`
`
Regards
Yes, I think I should probably take a deep breath, thanks!
So my system image was initially written in November, I guess, which is why that date is shown. It updates after being on a bit (via GPS).
Now it shows all /dev/uio* as Nov 3, until removing/reinstalling uio_pruss. Please see the output below:
debian@beaglebone:~$ ls -l /dev/uio*
crw-rw---- 1 root users 240, 0 Nov 3 2016 /dev/uio0
crw-rw---- 1 root users 240, 1 Nov 3 2016 /dev/uio1
crw-rw---- 1 root users 240, 2 Nov 3 2016 /dev/uio2
crw-rw---- 1 root users 240, 3 Nov 3 2016 /dev/uio3
crw-rw---- 1 root users 240, 4 Nov 3 2016 /dev/uio4
-rw-r–r-- 1 root root 0 Nov 3 2016 /dev/uio5
crw-rw---- 1 root users 240, 6 Nov 3 2016 /dev/uio6
crw-rw---- 1 root users 240, 7 Nov 3 2016 /dev/uio7
debian@beaglebone:~$ sudo rmmod uio_pruss
debian@beaglebone:~$ sudo modprobe uio_pruss
debian@beaglebone:~$ ls -l /dev/uio*
crw-rw---- 1 root users 240, 0 Mar 29 12:46 /dev/uio0
crw-rw---- 1 root users 240, 1 Mar 29 12:46 /dev/uio1
crw-rw---- 1 root users 240, 2 Mar 29 12:46 /dev/uio2
crw-rw---- 1 root users 240, 3 Mar 29 12:46 /dev/uio3
crw-rw---- 1 root users 240, 4 Mar 29 12:46 /dev/uio4
-rw-r–r-- 1 root root 0 Nov 3 2016 /dev/uio5
crw-rw---- 1 root users 240, 6 Mar 29 12:46 /dev/uio6
crw-rw---- 1 root users 240, 7 Mar 29 12:46 /dev/uio7
debian@beaglebone:~$ dmesg | grep uio
debian@beaglebone:~$
I don’t understand why uio5 doesn’t change. The main issue is it’s lenght of 0 bytes (others are 240). The device seems to be disconnected from the driver, and the driver loader cannot change the file.
Sorry, you don’t have a libpruio issue. You have a problem with LINUX driver loading. And I have no Blue to test here, so I cannot really help.
I’d try to erase the file before reloading the driver
lsmod | grep uio* sudo rmmod uio_pruss lsmod | grep uio*ls -l /dev/uio* sudo rm -f /dev/uio5ls -l /dev/uio* sudo modprobe uio_pruss ``lsmod | grep uio* ls -l /dev/uio*``
Regards
PS: Check your systemd services if anyone is changing the file /dev/uio5.
Hello,
Your suggested steps did work to connect uio5, thanks! It reverts to the disconnected state on reboot, however.
I do have several services running, including for the IMU and the analog in (using libpruio). So my service isn’t explicitly changing uio5, but maybe it invokes it too early in the boot process.
When I disable the service that uses libpruio, I am able to manually run my code, and the example code (e.g 1, io_input).
Thank you for your help. I just have to figure out what about my service is causing this issue.
Your suggested steps did work to connect uio5, thanks! It reverts to the disconnected state on reboot, however.
Good!
I do have several services running, including for the IMU and the analog in (using libpruio). So my service isn’t explicitly changing uio5, but maybe it invokes it too early in the boot process.
Sure, your service must not start before the driver is loaded. Here is an example how I start one of my projects
File /etc/systemd/system/solar.service
`
[Unit]
Description=Start controller (/etc/default/solar-regler.sh)
[Service]
Type=oneshot
ExecStart=/etc/default/solar-regler.sh
StandardOutput=tty
RemainAfterExit=yes
[Install]
WantedBy=multi-user.target
`
File /etc/default/solar-regler.sh (the program to start is called solar-regler)
`
#!/bin/sh -e
uio=/dev/uio5
until test -e ${uio}; do sleep 1; done
/usr/local/bin/solar-regler &
`
Regards
TJF,
Thank you for your help, especially because it turned out to be more of a systemd issue than libpruio! I have now changed my service so that it doesn’t start until later in the boot process, and everything seems to be functioning correctly.
My initial mistake was making multiple changes at the same time: the number of samples in my libpruio program and editing my systemd services. Because of that, I was looking at the wrong potential cause of the problem.
Thanks, again.
Hi CM!
Hi TJF,
I am getting the hang of the pocket beagle, C++ and libpruio and I am testing some features. Thanks again for your efforts because it has been really helpful. One of the things that struck me as odd is that the claim of the beaglebone is 12-bit ADC’s. What I see when I measure the analoge pins is values that differ by 64. This suggests that the pocket beagle is not 12 bit but 10 bit… (full range is 65536 and differences between values are 64 is 1024 steps or 10 bits). I must say that the difference is not 64 consequently but sometimes the differences are 32 bit (other measurement). So it seems the board shifts between bit depths. I tried with sample frequencies 22.1kHz and 1kHz. 1 khz seems inclined to 11 bit.
My question is whether you know if this is because of libpruio or a general issue with the pocket beagle and whether there is a way to fixate the bit depth at 12 also for high frequencies?
I measure 8 channels and the number of samples is 220500 (10 seconds of audio at 22.1 kHz).
Thanks in advance.
Best, Hans.
Hi Hans!
First let me say that I have no Pocket and cannot speak about experience, but only about knowledge that I’ve read anywhere.
As far as I know the PocketBeagle has a CPU with inbuild memory, but fully compatible to the AM3358 (which I use). My guess is that the ADC measurent is equal at both systems (untested), which gets done by the TSC_ADC_SS (= Touch Screen Controller_Analoge Digital Converter_Sub System). That subsystem is designed to measure touch screen input, and the measurent isn’t very accurate.
Anyway, you should see 12 bit resolution. But note, libpruio may left shift the raw data in order to make them comparable with 16 bit measurements. This depends on the last parameter Mds in the call to function PruIo::config(). When this parameter is 0 (zero) you’ll get unchanged data directly from the TSC_ADC_SS. This should be in the range of 0-4095 with one bit resolution. Find further details in the libpruio docs and in the CPU TRM chapter 12.
Regards
Hi TJF!
Again, since I forgot a line of code and I think this post is more clear:
I read your suggestion and spend some time reading but I cannot really figure out what I could do to remedy the issue. The bit shifting does not change anything either but it gave insight.
I do have an inkling about what happens now. My strong suspicion is that the ADC conversion process does not finish.
With 12 bits we would start the ADC sample process with 011111111111 and look if the corresponding voltage is lower or higher then our input. If our input voltage is higher the next probe would be 1011111111111, if that is lower we probe 100111111111. When I measure 0V I often get values like 15 with some 23 mixed within. There are also some values of 19 but much less then we see the value 23 which is odd since we would expect something like a normal distribution. This suggests that the process mostly stops before the last three bits are processed by the ADC.
My configuration of the pruio is below:
`
pruIo *io = pruio_new(PRUIO_DEF_ACTIVE, 1, 0x98, 0); //Create a new driver structure
void ADC::initPruio() {
pruio_adc_setStep(io, 7, 0, 1, 0, 0); //Step 1, AIN-0
pruio_adc_setStep(io, 8, 1, 1, 0, 0); //Step 2, AIN-1
pruio_adc_setStep(io, 9, 2, 1, 0, 0); //Step 3, AIN-2
pruio_adc_setStep(io, 10, 3, 1, 0, 0); //Step 4, AIN-3
pruio_adc_setStep(io, 11, 4, 1, 0, 0); //Step 5, AIN-4
pruio_adc_setStep(io, 12, 5, 1, 0, 0); //Step 6, AIN-5
pruio_adc_setStep(io, 13, 6, 1, 0, 0); //Step 7, AIN-6
pruio_adc_setStep(io, 14, 7, 1, 0, 0); //Step 8, AIN-7
if (pruio_config(io, SAMPLE_RATE, 255<<7 , 45352, 0)){ // upload settings: 220500 (* 8) samples (, 255 is bin 11111111, 22.05 kHz, 16 bits,
printf(“config failed (%s)\n”, io->Errr);}
if (pruio_rb_start(io)) printf(“rb_start failed (%s)\n”, io->Errr); // start measurement //Starts in rb_mode
printf(“initialized\n”);
}
`
I hope you can help me to point me in the right direction.
Best, Hans.
Hi Hans!
Your configuration code seems to be OK.
Regarding your guess:
libpruio picks up the samples from a FiFo buffer. It’s unlikely that the TSC_ADC_SS sends a value to the FiFo before the sampling process is finished (unless you butchered your hardware). It’s more likely that you have high impedance signals, which break down when sampling comes to the lower bits (and current increases).
Anyway, you can perform an easy resolution test: connect one input to a strong signal, ie. from a simple 1V5 battery cell. Then run the example 1.c and check the resolution of the battery channel. It should flicker at the last one or two bits.
Regards
Hi TJF,
It is not the impedance I think, but it was interesting to go back to the normal io example 1.c. The behaviour is different. Output when using that example (but without leftshift):
0 0 0 0 0 0 0 0
C37 13 9B7 5 199 E34 0 1A4
C3B 13 9B7 5 199 E36 0 1A5
C37 12 9BD 5 197 E36 0 1A4
C37 11 9B8 5 199 E34 0 1A5
C38 13 9B7 5 199 E36 0 1A5
C37 13 9BA 4 197 E35 0 1A5
C37 12 9BA 4 197 E35 0 1A5
C37 12 9B7 4 197 E35 0 1A5
C37 12 9B7 5 197 E35 0 1A5
C37 12 9B7 5 197 E35 0 1A5
C37 12 9B7 5 197 E35 0 1A5
C37 12 9B7 5 197 E35 0 1A5
So that is ok!!!
But now, when adapting the syntax and using ringbuffer mode (and I hope I did the syntax ok):
`
#include “stdio.h”
#include “libpruio/pruio.h” // include header
#include <unistd.h>
int main(int argc, char **argv)
{
int i, n;
pruIo *io = pruio_new(PRUIO_DEF_ACTIVE, 4, 0x98, 0);
pruio_adc_setStep(io, 7, 0, 1, 0, 0); //Step 1, AIN-0
pruio_adc_setStep(io, 8, 1, 1, 0, 0); //Step 2, AIN-1
pruio_adc_setStep(io, 9, 2, 1, 0, 0); //Step 3, AIN-2
pruio_adc_setStep(io, 10, 3, 1, 0, 0); //Step 4, AIN-3
pruio_adc_setStep(io, 11, 4, 1, 0, 0); //Step 5, AIN-4
pruio_adc_setStep(io, 12, 5, 1, 0, 0); //Step 6, AIN-5
pruio_adc_setStep(io, 13, 6, 1, 0, 0); //Step 7, AIN-6
pruio_adc_setStep(io, 14, 7, 1, 0, 0); //Step 8, AIN-7
if (pruio_config(io, 220500, 255<<7 , 45352, 0)){ // upload (default) settings, start IO mode
printf(“config failed (%s)\n”, io->Errr);}
if (pruio_rb_start(io)) printf(“rb_start failed (%s)\n”, io->Errr); // start measurement //Starts in rb_mode
printf(“initialized\n”);
usleep(10000);
/* now current ADC samples are available for AIN-0 to AIN-7 in array io->Adc->Value /
for(n = 1; n <= 13; n++) { // print some lines
for(i = 0; i < 8; i++) // all steps
printf(" %4X", io->Adc->Value[i + (8 * n)]); // output one channel in hex
printf(“\n”); // next line
}
/ we’re done /
pruio_destroy(io); / destroy driver structure */
return 0;
}
`
output:
8EF B7 477 F 10F E3F 47 19F
72F A7 357 F 117 E3F 4F 1A3
60F 97 2DF 13 11B E3F 4F 1A3
557 8F 2B7 17 11F E3F 4F 1A7
4DF 8F 2A7 17 11F E3F 4F 1A7
49F 7F 29F 17 127 E3F 4F 1A7
477 7F 29F 17 127 E3F 4F 1A7
45F 7F 29F 17 127 E4F 53 1A7
44F 7F 29F 17 127 E3F 4F 1A7
447 7F 29F 17 127 E3F 4F 1A7
43F 7F 29F 17 127 E3F 53 1A7
43F 7F 29F 1B 127 E3F 53 1A7
43F 7F 29F 17 127 E3F 53 1A7
There are definitely some interesting differences in the output. Loose from the difference in resolution some of the inputs (Ain-0, Ain-1, Ain-2, Ain-6) cause very different output from the values that come from the minimal code ADC example while Ain-3, Ain-4, Ain-5, Ain-7 are more or less the same except for the resolution thing. (Pull-down activated in the minimal example?). The battery is connected to Ain-5 in both situations using a 10kΩ potmeter on that channel, the other channels are floating so maybe we should not pay too much attention to the absolute differences but we do see that the resolution thing seems connected to rb-mode unless my syntax is false.
Looking for a clue…
Best, Hans.
Hi Hans!
What did you do in order to increase the external RAM size for the uio_pruss driver?
With standard configuration (io->ESize = 262144) your code generates an error message
config failed (out of memory)
at line
if (pruio_config(io, 220500, 255<<7 , 45352, 0))
, but it doesn’t stop in that case. It tries to continue, and fails.
Either increase the extram_pool_sz parameter for the uio_pruss driver, or reduce the number of samples (<= 16384 == 262144 / 2 / 8) for standard setting.
Tipps:
A```lways end the code in case of an error message.```
Regards
Hi TJF,
I increase the external RAM at startup:
https://groups.google.com/forum/#!msg/beagleboard/_8Ld1deXhSY/gAoPN2FaDwAJ (Brian B’s post)
I set it at the maximum size for the moment although it can be a little smaller indeed… I forgot to make it smaller in my example. I think it is not important for the resolution issue though.
Starting the outer loop at 0 wil only lead to printing the step cycle one compleet cycle earlier (from the start) but does not change the resolution either.
Where do I fail to catch an error message?
So any clue on the resolution issue except for impedance? Why does it only play up in rb-mode and not in single shot? Did you try the rb-mode example? I tried to use delays in setstep but at high speed you cannot use too much. It seems that delays help the issue a little but it is not useable in practice. It is also unclear what unit is used for sample delay. Are those ADC clock pulses? Then I would expect 4 clock pulses to be enough to do 4 extra ADC steps…
The documentation also mentions a status bit that is used to indicate that the ADC is busy converting (page 1828). Is the status bit information used in the rb-mode?
I did not try yet whether the freebasic example yields the same result. Would you recommend checking it?
Best, Hans.
Hi Hans!
I set it at the maximum size for the moment although it can be a little smaller indeed… I forgot to make it smaller in my example. I think it is not important for the resolution issue though.
When the size of the ERam is too small the main loop doesn’t start → no ADC sampling at all. You’ll get garbage.
Starting the outer loop at 0 wil only lead to printing the step cycle one compleet cycle earlier (from the start) but does not change the resolution either.
Correct!
Where do I fail to catch an error message?
A lot of errors are uncatched. This version catches them all
`
#include “stdio.h”
#include “libpruio/pruio.h” // include header
#include <unistd.h>
int main(int argc, char **argv)
{
int i = 1, n;
char *emsg = “CTOR”;
pruIo *io = pruio_new(PRUIO_DEF_ACTIVE, 4, 0x98, 0);
while (!io->Errr) {
if (pruio_adc_setStep(io, 7, 0, 1, 0, 0)) {emsg = “step 7”; i = 2; break;} //Step 7, AIN-0
if (pruio_adc_setStep(io, 8, 1, 1, 0, 0)) {emsg = “step 8”; i = 2; break;} //Step 8, AIN-1
if (pruio_adc_setStep(io, 9, 2, 1, 0, 0)) {emsg = “step 9”; i = 2; break;} //Step 9, AIN-2
if (pruio_adc_setStep(io, 10, 3, 1, 0, 0)) {emsg = “step 10”; i = 2; break;} //Step 10, AIN-3
if (pruio_adc_setStep(io, 11, 4, 1, 0, 0)) {emsg = “step 11”; i = 2; break;} //Step 11, AIN-4
if (pruio_adc_setStep(io, 12, 5, 1, 0, 0)) {emsg = “step 12”; i = 2; break;} //Step 12, AIN-5
if (pruio_adc_setStep(io, 13, 6, 1, 0, 0)) {emsg = “step 13”; i = 2; break;} //Step 13, AIN-6
if (pruio_adc_setStep(io, 14, 7, 1, 0, 0)) {emsg = “step 14”; i = 2; break;} //Step 14, AIN-7
// upload settings, prepare MM mode
if (pruio_config(io, 220500, 255<<7, 45352, 0)) {emsg = “config”; i = 3; break;}
// start measurement //Starts in rb_mode
if (pruio_rb_start(io)) {emsg = “rb_start”; i = 4; break;}
printf(“initialized\n”);
usleep(10000);
/* now current ADC samples are available for AIN-0 to AIN-7 in array io->Adc->Value /
for(n = 0; n <= 13; n++) { // print some lines
for(i = 0; i < 8; i++) // all steps
printf(" %4X", io->Adc->Value[i + (8 * n)]); // output one channel in hex
printf(“\n”); // next line
}
i = 0;
}
/ we’re done */
if (io->Errr) printf(“%s failed (%s)\n”, emsg, io->Errr);
pruio_destroy(io); /* destroy driver structure */
return i;
}
`
Try it. You also can check the available ERam size by printing out io->ESize.
The documentation also mentions a status bit that is used to indicate that the ADC is busy converting (page 1828). Is the status bit information used in the rb-mode?
Yes, the status bit gets checked for restart as well as the FiFo counter before fetching a sample.
Regards
Hi TJF,
No errors. Warnings when compiling with g++ all similar to each other: testRB.c:28:61: warning: ISO C++ forbids converting a string constant to ‘char*’ [-Wwrite-strings]
if (pruio_rb_start(io)) {emsg = “rb_start”; i = 4; break;
no warnings, nor errors when compiling with gcc.
io Esize = 8388608
But the output still has the same problem. About 9 bits get converted but the least significant last three bits stay at 111(7).
Oh, and the loop goes on. The problem is not there.
Sampling 100 times slower, delay to the maximum and short buffer:
`
pruIo *io = pruio_new(PRUIO_DEF_ACTIVE, 4, 0x98, 0);
while (!io->Errr) {
if (pruio_adc_setStep(io, 7, 0, 1, 255, 0)) {emsg = “step 7”; i = 2; break;} //Step 7, AIN-0
if (pruio_adc_setStep(io, 8, 1, 1, 255, 0)) {emsg = “step 8”; i = 2; break;} //Step 8, AIN-1
if (pruio_adc_setStep(io, 9, 2, 1, 255, 0)) {emsg = “step 9”; i = 2; break;} //Step 9, AIN-2
if (pruio_adc_setStep(io, 10, 3, 1, 255, 0)) {emsg = “step 10”; i = 2; break;} //Step 10, AIN-3
if (pruio_adc_setStep(io, 11, 4, 1, 255, 0)) {emsg = “step 11”; i = 2; break;} //Step 11, AIN-4
if (pruio_adc_setStep(io, 12, 5, 1, 255, 0)) {emsg = “step 12”; i = 2; break;} //Step 12, AIN-5
if (pruio_adc_setStep(io, 13, 6, 1, 255, 0)) {emsg = “step 13”; i = 2; break;} //Step 13, AIN-6
if (pruio_adc_setStep(io, 14, 7, 1, 255, 0)) {emsg = “step 14”; i = 2; break;} //Step 14, AIN-7
// upload settings, prepare MM mode
if (pruio_config(io, 2205, 255<<7, 4535200, 0)) {emsg = “config”; i = 3; break;}
`
No difference either.
initialized, io size = 8388608
F88 F3 8CF 7 F3 23 1 67
ABF CF 5AB F 7F 27 3 6F
7FF AF 3FF 17 63 2F 7 77
64F 9F 35F 17 5F 2F B 77
537 8F 317 17 5F 2F F 7F
48F 7F 2FF 1F 67 37 F 7F
427 7F 2F7 1F 67 37 F 7F
3EF 7F 2EF 1F 67 37 17 7F
3CF 7F 2EF 1F 67 37 F 7F
3BF 7F 2EF 1F 67 37 17 7F
3BF 7F 2F7 1F 67 37 17 7F
3B7 7F 2EF 1F 67 37 17 7F
3AF 7F 2EF 1F 67 37 17 7F
3AF 7F 2EF 1F 67 37 17 7F
Best, Hans.
For what it is worth, I also tried to do it in freebasic. I don’t know anything about freebasic but tried to hack something together and I see exactly the same behaviour:
`
’ include libpruio
#INCLUDE ONCE “BBB/pruio.bi”
CONST tSamp = 20000 _ '< The number of samples in the files (per step).
, tmr = 45352 _ '< The sampling rate in ns (20000 → 50 kHz).
, NoStep = 8 _ '*< The number of active steps (must match setStep calls and mask).
VAR io = NEW PruIo() '*< Create a PruIo structure, wakeup subsystems.
WITH *io
DO
IF .Errr THEN ?"NEW failed: " & *.Errr : EXIT DO
IF .Adc->setStep( 7, 0, 0, 0, 0) THEN _
?"step 9 configuration failed: " & *.Errr : EXIT DO
IF .Adc->setStep( 8, 1, 0, 0, 0) THEN _
?"step 10 configuration failed: " & *.Errr : EXIT DO
IF .Adc->setStep( 9, 2, 0, 0, 0) THEN _
?"step 11 configuration failed: " & *.Errr : EXIT DO
IF .Adc->setStep(10, 3, 0, 0, 0) THEN _
?"step 9 configuration failed: " & *.Errr : EXIT DO
IF .Adc->setStep(11, 4, 0, 0, 0) THEN _
?"step 10 configuration failed: " & *.Errr : EXIT DO
IF .Adc->setStep(12, 5, 0, 0, 0) THEN _
?"step 11 configuration failed: " & *.Errr : EXIT DO
IF .Adc->setStep(13, 6, 0, 0, 0) THEN _
?"step 9 configuration failed: " & *.Errr : EXIT DO
IF .Adc->setStep(14, 7, 0, 0, 0) THEN _
?"step 10 configuration failed: " & *.Errr : EXIT DO
VAR mask = &b11111111 SHL 7 _ '*< The active steps (7 to 14).
IF .config(tSamp, 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
sleep 10
’ here current ADC samples are available in array Adc->Value[]
FOR n AS LONG = 0 TO 13 ’ print some lines
FOR i AS LONG = 0 TO 7 ’ all steps
PRINT " " & HEX(io->Adc->Value[i + 8 * n], 0); ’ output one channel in hex
NEXT
PRINT ’ next line
NEXT
LOOP UNTIL 1
IF .Errr THEN SLEEP
END WITH
DELETE(io)
`
Output:
C2D D7 747 F 117 F9F 4F 197
927 BF 4BB F 117 F9F 4F 197
757 A7 377 13 11F F9F 53 197
62F 9B 2EF 17 123 F9F 57 19F
56F 8F 2BF 17 127 F9F 57 19F
4EF 8F 2AF 17 127 F9F 57 19F
4AF 87 29F 17 12F F9F 57 19F
47F 7F 29F 17 12F F9F 57 19F
45F 7F 29F 17 12F FAF 57 19F
457 7F 29F 17 12F FAF 57 19F
44F 7F 29F 1B 12F FAF 57 19F
44F 7F 29F 1F 12F F9F 57 19F
43F 7F 29F 1F 12F FAF 5F 19F
Should I ask if this is pocket beagle related in a general forum or support or does exactly the same happen on the BBB with ringbuffer mode? And is this related to the processor or could there be a bug in libpruio?
Thanks for thinking with me.
Best, Hans.
Hi Hans!
Oh, and the loop goes on. The problem is not there.
Yes, there’s a break; statement missing at the end of the while loop.
Sorry, I cannot reproduce the problem. Using this code
`
// gcc -Wall -o hansOK hansOK.c -lpruio
#include “stdio.h”
#include “libpruio/pruio.h” // include header
#include <unistd.h>
int main(int argc, char **argv)
{
int i = 1, n;
char *emsg = “CTOR”;
pruIo *io = pruio_new(PRUIO_DEF_ACTIVE, 4, 0x98, 0);
while (!io->Errr) {
if (pruio_adc_setStep(io, 7, 0, 1, 0, 0)) {emsg = “AIN-0”; i = 2; break;} //Step 7, AIN-0
if (pruio_adc_setStep(io, 8, 1, 1, 0, 0)) {emsg = “AIN-1”; i = 2; break;} //Step 8, AIN-1
if (pruio_adc_setStep(io, 9, 2, 1, 0, 0)) {emsg = “AIN-2”; i = 2; break;} //Step 9, AIN-2
if (pruio_adc_setStep(io, 10, 3, 1, 0, 0)) {emsg = “AIN-3”; i = 2; break;} //Step 10, AIN-3
if (pruio_adc_setStep(io, 11, 4, 1, 0, 0)) {emsg = “AIN-4”; i = 2; break;} //Step 11, AIN-4
if (pruio_adc_setStep(io, 12, 5, 1, 0, 0)) {emsg = “AIN-5”; i = 2; break;} //Step 12, AIN-5
if (pruio_adc_setStep(io, 13, 6, 1, 0, 0)) {emsg = “AIN-6”; i = 2; break;} //Step 13, AIN-6
if (pruio_adc_setStep(io, 14, 7, 1, 0, 0)) {emsg = “AIN-7”; i = 2; break;} //Step 14, AIN-7
// upload settings, prepare MM mode
if (pruio_config(io, 220500, 255<<7, 45352, 0)) {emsg = “config”; i = 3; break;}
//if (pruio_config(io, 16384, 255<<7, 45352, 0)) {emsg = “config”; i = 3; break;}
// start measurement //Starts in rb_mode
if (pruio_rb_start(io)) {emsg = “rb_start”; i = 4; break;}
printf(“initialized, ESize = %X\n”, io->ESize);
usleep(10000);
/* now current ADC samples are available for AIN-0 to AIN-7 in array io->Adc->Value /
for(n = 0; n <= 12; n++) { // print some lines
for(i = 0; i < 8; i++) // all steps
printf(" %4X", io->Adc->Value[i + (8 * n)]); // output one channel in hex
printf(“\n”); // next line
}
i = 0; break;
}
/ we’re done */
if (io->Errr) printf(“%s failed (%s)\n”, emsg, io->Errr);
pruio_destroy(io); /* destroy driver structure */
return i;
}
`
on Beaglebone Black, AIN-[0-6] open, but AIN-7 connected on board to 1V65, I get
$ ./hansOK
initialized, ESize = 40000
F50 ED5 EC6 B6A 83F 845 8EA F24
F4E F13 ECD D08 A58 941 948 F2F
F5D F23 EE5 DF1 BEA A8C A09 F28
F56 F33 F0F E72 CE9 BB1 AFF F2F
F63 F34 F1A EB8 D9D CA7 BEA F25
F52 F2F F2D EE0 E06 D50 CB3 F2F
F5E F2D F2C EF1 E57 DCF D4F F25
F4B F2C F35 EFB E75 E11 DBF F2E
F55 F2D F2A EFA E95 E4B E0E F25
F4D F2A F2F F05 EA0 E68 E3D F33
F57 F25 F26 EFC EAD E8A E6A F28
F47 F22 F2A EFF EB0 E8B E75 F2F
F54 F27 F24 EF8 EB3 E9D E8B F2A
$ sudo rmmod uio_pruss
$ sudo modprobe uio_pruss extram_pool_sz=0x800000
$ ./hansOK
initialized, ESize = 800000
F43 ED3 EC0 B64 842 839 8D3 F2F
F50 F03 EC9 D11 A62 941 930 F2A
F57 F2B EE6 DEC BDE A8B A07 F32
F58 F22 F01 E71 CEF BB5 AF6 F28
F5A F31 F1B EB2 D95 CA7 BEF F31
F58 F28 F23 EDF E11 D52 CAE F25
F51 F2F F32 EED E47 DC6 D51 F32
F54 F2A F30 EFB E7B E15 DB6 F2B
F4F F2D F30 EFC E89 E4A E10 F35
F56 F21 F26 EFF EA9 E71 E3E F24
F4B F28 F2B F00 EAC E82 E67 F37
F52 F20 F25 EFD EBA E94 E74 F2A
F49 F2A F2A EF7 EAE E98 E89 F33
So here it works with standard (16384 samples) or maximum ERam (220500 samples) configuration on kernel
4.14.69-ti-r76
Regards
It seems that this stupid board butchered my response. Here’s the rest:
Hi Hans!
Just for curiosity, which version of libpruio are you using? Where did you download and how did you install?
Regards