Periodic delay reading analog inputs with C, will PRUs solve it and is it worth it?

Walter Cromer

unread,

Apr 7, 2021, 11:23:59 AM4/7/21

to BeagleBoard

I'm running a BBB Wireless. The OS version, version.sh output, etc. are below.

We're sensor outputs on AIN4 and AIN0 with C using the code below. The intervals between readings is fairly constant at about 350 uS but there is periodically, about every 25 readings, a reading interval of between 4000 and 4800 uS. Our application can't accept this.

1) Is there some process the OS is doing periodically to cause this delay and can we eliminate it?

2) Would the PRUs solve this problem and is it worth the effort to learn and apply them?

Thanks for your insights, advice, and help!

Code is in C...and we run it from the Cloud9 IDE.

void ReadDetectors(long TimeToRead, int CycleNo)

{

// initialize local variables

char Det1Volts_str[1024][6];

char Det2Volts_str[1024][6];

long elapsed_us;

int index;

index = 0;

struct timeval tv_start; //start time hack

struct timeval tv_now; // current time hack

long total_elapsed_time_us[1024];

long start_secs;

long last_secs;

long last_usecs;

int KeepReading = 1;

FILE* fDet1 = fopen("/sys/bus/iio/devices/iio:device0/in_voltage4_raw", "r"); // top sensor, blue wire

FILE* fDet2 = fopen("/sys/bus/iio/devices/iio:device0/in_voltage0_raw", "r"); // bottom sensor, purple wire

// get time at entry into the routine

gettimeofday(&tv_now,NULL);

start_secs = tv_now.tv_sec;

last_usecs = tv_now.tv_usec;

elapsed_us = 0;

total_elapsed_time_us[index] = 0;

while (KeepReading)

{

// update elapsed time

gettimeofday(&tv_now,NULL);

if (tv_now.tv_sec >= last_usecs)

{

elapsed_us = tv_now.tv_usec - last_usecs;

}

else

{

elapsed_us = (1000000 - last_usecs) + tv_now.tv_usec;

}

total_elapsed_time_us[index] = (tv_now.tv_sec - start_secs)*1000000 + elapsed_us;

if (total_elapsed_time_us[index] > TimeToRead) KeepReading = 0;// read detectors

fread(&Det1Volts_str[index], 5, 1, fDet1);

fread(&Det2Volts_str[index], 5, 1, fDet2);

rewind(fDet1);

rewind(fDet2);

index += 1;

if (index >1024) KeepReading = 0;

}

debian@beaglebone:/var/lib/cloud9$ uname --a

Linux beaglebone 4.19.94-ti-r42 #1buster SMP PREEMPT Tue Mar 31 19:38:29 UTC 2020 armv7l GNU/Linux

debian@beaglebone:/$ sudo opt/scripts/tools/version.sh

git:/opt/scripts/:[b39ec679648a6be8f25f48bd1c9784c1fc5a0c46]

eeprom:[A335BNLTBWA52027BBWG0227]

model:[TI_AM335x_BeagleBone_Black_Wireless]

dogtag:[BeagleBoard.org Debian Buster IoT Image 2020-04-06]

bootloader:[microSD-(push-button)]:[/dev/mmcblk0]:[U-Boot 2019.04-00002-g07d5700e21]:[location: dd MBR]

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

UBOOT: Booted Device-Tree:[am335x-boneblack-uboot-univ.dts]

UBOOT: Loaded Overlay:[AM335X-PRU-RPROC-4-19-TI-00A0]

UBOOT: Loaded Overlay:[BB-ADC-00A0]

UBOOT: Loaded Overlay:[BB-BBBW-WL1835-00A0]

UBOOT: Loaded Overlay:[BB-BONE-eMMC1-01-00A0]

UBOOT: Loaded Overlay:[BB-HDMI-TDA998x-00A0]

UBOOT: Loaded Overlay:[BB-I2C2-RTC-DS3231]

UBOOT: Loaded Overlay:[BB-W1-P9.12-00A2]

kernel:[4.19.94-ti-r42]

nodejs:[v10.15.2]

/boot/uEnv.txt Settings:

uboot_overlay_options:[enable_uboot_overlays=1]

uboot_overlay_options:[uboot_overlay_addr4=/lib/firmware/BB-W1-P9.12-00A0.dtbo]

uboot_overlay_options:[uboot_overlay_pru=/lib/firmware/AM335X-PRU-RPROC-4-19-TI-00A0.dtbo]

uboot_overlay_options:[enable_uboot_cape_universal=1]

uboot_overlay_options:[dtb_overlay=/lib/firmware/BB-I2C2-RTC-DS3231.dtbo]

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

pkg:[bb-cape-overlays]:[4.14.20200403.0-0rcnee0~buster+20200403]

pkg:[bb-wl18xx-firmware]:[1.20200322.0-0rcnee0~buster+20200322]

pkg:[kmod]:[26-1]

pkg:[librobotcontrol]:[1.0.4-git20190227.1-0rcnee0~buster+20190327]

pkg:[firmware-ti-connectivity]:[20190717-2rcnee1~buster+20200305]

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

cmdline:[console=ttyO0,115200n8 bone_capemgr.uboot_capemgr_enabled=1 root=/dev/mmcblk0p1 ro rootfstype=ext4 rootwait coherent_pool=1M net.ifnames=0 lpj=1990656 rng_core.default_quality=100 quiet]

dmesg | grep remote

[ 11.374832] remoteproc remoteproc0: 4a334000.pru is available

[ 11.397684] remoteproc remoteproc1: 4a338000.pru is available

[ 58.421621] remoteproc remoteproc2: wkup_m3 is available

[ 58.879676] remoteproc remoteproc2: powering up wkup_m3

[ 58.879705] remoteproc remoteproc2: Booting fw image am335x-pm-firmware.elf, size 217168

[ 58.879995] remoteproc remoteproc2: remote processor wkup_m3 is now up

dmesg | grep pru

[ 11.374832] remoteproc remoteproc0: 4a334000.pru is available

[ 11.375013] pru-rproc 4a334000.pru: PRU rproc node pru@4a334000 probed successfully

[ 11.397684] remoteproc remoteproc1: 4a338000.pru is available

[ 11.397867] pru-rproc 4a338000.pru: PRU rproc node pru@4a338000 probed successfully

dmesg | grep pinctrl-single

[ 0.929984] pinctrl-single 44e10800.pinmux: 142 pins, size 568

dmesg | grep gpio-of-helper

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

lsusb

Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub

END

TJF

unread,

Apr 8, 2021, 6:12:41 PM4/8/21

to BeagleBoard

Hi!

Check out libpruio for easy and reliable ADC measurements with accurate timing. I guess RB (ring buffer) mode is your way to go.

Regards

Walter Cromer

unread,

Apr 9, 2021, 8:41:00 AM4/9/21

to BeagleBoard

Thanks! I believe you are right and I've already started working with this. I will check out libpruio. I'm starting to believe it isn't quite as difficult as a I thought it might be.

Maybe you can answer a quick, related question.

I'm looking at some example code and there references to ADC_TSC. I realize this is a reference to the Touchscreen controller which provides the ADC functionality. And I suspect this refers to the base memory address of the chip but I cannot find where that is defined in any header files anywhere. It would help me to follow these examples if I knew where that reference was.

Unfortunately, too, the examples are Python and I'm not a Python programmer. I work in C. So I'm having to dig through this and learn some Python at the same time. Not a bad thing but time consuming!

Walter

TJF

unread,

Apr 9, 2021, 9:17:24 AM4/9/21

to BeagleBoard

wal...@edenconceptsllc.com schrieb am Freitag, 9. April 2021 um 14:41:00 UTC+2:

I'm looking at some example code and there references to ADC_TSC. I realize this is a reference to the Touchscreen controller which provides the ADC functionality. And I suspect this refers to the base memory address of the chip but I cannot find where that is defined in any header files anywhere. It would help me to follow these examples if I knew where that reference was.

Find high-level code (FreeBASIC) in files src/pruio/pruio_adc.[bas|bi] and low level code (assembler) in file src/pruio/pruio_adc.p.

Unfortunately, too, the examples are Python and I'm not a Python programmer. I work in C. So I'm having to dig through this and learn some Python at the same time. Not a bad thing but time consuming!

Python examples are in folder src/python. FreeBASIC examples are in folder src/examples. And C examples are in folder src/c_examples. Find an overview at

https://users.freebasic-portal.de/tjf/Projekte/libpruio/doc/html/ChaExamples.html

Regards

Mark Lazarewicz

unread,

Apr 9, 2021, 10:23:26 AM4/9/21

to beagl...@googlegroups.com

1)

Linux is not a real-time operating system (OS) in and of itself. ... “The idea is to run critical applications like the control loop on VxWorks and then run non-deterministic analytics on Linux.

Hard realtime apps like closed loop positioning used in pressing plants,automation,fighter planes etc etc don't use Linux. Determinism required by safety critical systems certified by FAA would require you found delay measured it to calculate worst case as well as validated software.

https://www.automationworld.com/products/control/blog/13318614/clarifying-the-linux-real-time-issue#:~:text=Linux%20is%20not%20a%20real,OS)%20in%20and%20of%20itself.&text=%E2%80%9CThe%20idea%20is%20to%20run,non%2Ddeterministic%20analytics%20on%20Linux.

What makes the Linux scheduler seem unpredictable?

The question refers to the output of a multi-threaded application, where each thread merely prints its ID (user assigned number) on the standard output. Here all threads have equal priority and com...

2) I say no depends on how much delay is acceptable there are buses between shared memory etc it will improve over using ARM.

Ideal situation is a barebone app designed with minimal interrupt latency followed by an RTOS that's guaranteed to meet latency specs especially one certified by FAA or FDA of course these are expensive

Sent from Yahoo Mail on Android

--
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/04caf3a3-cd8c-449e-9fd7-9ed6df33f99en%40googlegroups.com
.

Walter Cromer

unread,

Apr 9, 2021, 10:57:32 AM4/9/21

to BeagleBoard

Understood. Our application won't require FAA or FDA approval but it definitely needs the more deterministic performance of a bare bones app so I'm heading in the direction of the ADC being read by a PRU program and communicating back to the ARM for other processes (UI, reading other non-time-sensitive inputs, etc.).

pierric...@gadz.org

unread,

Apr 9, 2021, 11:19:47 AM4/9/21

to BeagleBoard

Hi,

I believe there are some simple ADC-read example directly in the image under /var/lib/cloud9/Techlab/.challenges, or here: https://github.com/beagleboard/cloud9-examples/blob/master/PocketBeagle/TechLab/.challenges/analogIn.pru0.c

They are labeled for PocketBeagle but it's the same ti-am335x chip so they should work easily on the BBB.

Hope it helps!

Pierrick

Mark Lazarewicz

unread,

Apr 9, 2021, 11:58:29 AM4/9/21

to beagl...@googlegroups.com

I'd share your timing requirement needs I've seen people get help in here before after doing this. search group. That way you don't spend time trying to meet a goal not attainable on PRU.

Sent from Yahoo Mail on Android

To view this discussion on the web visit https://groups.google.com/d/msgid/beagleboard/55b15f32-c44a-4977-8390-e91615c5e788n%40googlegroups.com.

Walter Cromer

unread,

Apr 9, 2021, 12:29:07 PM4/9/21

to BeagleBoard

Thanks, I'll check that out!

Walter Cromer

unread,

Apr 9, 2021, 12:30:53 PM4/9/21

to BeagleBoard

We are still experimenting but our preliminary calculations lead us to believe a reading every 50 microseconds will be sufficient. We can probably get by with 100 microseconds if we have to but I think the BBBw can easily sample at this rate, right?

WC

Pierrick Rauby

unread,

Apr 9, 2021, 12:32:00 PM4/9/21

to beagl...@googlegroups.com

Happy to help; I have worked some with these examples, so feel free to reach out if you have any questions!

Pierrick

**********************************************************************
Pierrick Rauby

Graduate Research Assistant

pierric...@gatech.edu
(+33) 640 237 194

Georgia Institute of Technology
George W. Woodruff School of Mechanical Engineering GeorgiaTech Institute of Technology
771 Ferst Drive, NW, Love Bldg. Room 108
Atlanta, GA 30332-0405
**********************************************************************

To view this discussion on the web visit https://groups.google.com/d/msgid/beagleboard/a50a177c-ba59-47d7-aaab-8352868a3199n%40googlegroups.com.

Mark Lazarewicz

unread,

Apr 9, 2021, 1:38:37 PM4/9/21

to beagl...@googlegroups.com

Hi

??but I think the BBBw can easily sample at this ????rate, right?

Asking about ARM/linux side ? or

PRU side

Polling or Interrupt?

Explain you delay details at least delay duration and what your app does with data would help.

The calculation I mentioned seeing people reply about were on the PRU.

Keep in mind there's overhead to get Data from PRU to ARM.

The timing becomes critical when you need to react from the data you read quickly. If that's not the case your just talking about how many sample's you use to control right? That's why I would expand a bit on your application.

I've worked on stuff that read and reacted in 10 microseconds closed loop plastic pressing for example that was easily achieved in 1988 microprocessor speeds

I've also worked on control loops that ran faster than 1 micro second on a similar processor OMAP L138 in that case the code ran on the DSP I forget the clock speed. In this case the motor control ran every 100 nanosecond I believe but it's used TI RTOS.

If the delay on Linux isn't acceptable add some details I mentioned hopefully the two guys who calculated PRU latencies will reply or I will find that post if possible.

Again it's probably highly likely even a polled PRU app can read Data quickly dependant on conversation rates time I'm assuming you need the ARM to get Data in 100 microseconds?

I'm not sure the transfer rate between PRU and ARM us determistic if linux is used .

Hopefully this makes sense if not ask but I'd follow up with more detail

Mark

To view this discussion on the web visit https://groups.google.com/d/msgid/beagleboard/DBBPR03MB6988AE54BE71B8EFDAD8A4BDA7739%40DBBPR03MB6988.eurprd03.prod.outlook.com.

Dennis Lee Bieber

unread,

Apr 9, 2021, 2:00:07 PM4/9/21

to Beagleboard

On Fri, 9 Apr 2021 09:30:53 -0700 (PDT), in
gmane.comp.hardware.beagleboard.user Walter Cromer

<walterc-2dFtBuzUeF/tpnMUCzy8b...@public.gmane.org> wrote:

>We are still experimenting but our preliminary calculations lead us to
>believe a reading every 50 microseconds will be sufficient. We can probably
>get by with 100 microseconds if we have to but I think the BBBw can easily
>sample at this rate, right?

Well, the SoC reference (SPRS717J) indicates that the ADC should be
capable of 200K samples per second. If I haven't flubbed the math, that
appears to come down to one sample every 5us.

As I recall, the PRU runs on a 200MHz clock, and PRU instructions, for
the most, run in one clock cycle. Should be enough cycles per sample to
handle processing <G>

Of course, it may matter how you have the ADC programmed.

--
Dennis L Bieber

Walter Cromer

unread,

Apr 9, 2021, 2:15:49 PM4/9/21

to BeagleBoard

We are controlling fluid flow by controlling two valves. (I am being a bit obscure because there are some proprietary processes involved.)

We start the flow and then read two sensors that are 'watching' the fluid for an event. There is an event 'start' in the fluid and then a following event 'end' that we determine by watching the values from the sensors. I believe this 'watch' part will be handled by the PRU firmware. When the event is over, the valves are turned off. We believe that the ARM will handle the valve control and UI. The C code running under Linux has completely missed events because of its non-deterministic operation.
The communication between ARM and PRU programs should consist of

1 - start / stop reading the sensors - considering just flipping a bit in a memory location both can access for this. ARM will have write access, PRU will just monitor it. (I don't really know how to do this yet. Still learning.)

2 - raw data collected about the event by the PRU doesn't really have to be accessed by the ARM in normal operation. (For R&D, we'd probably like to have it though.) Every sensor reading has to have its corresponding timestamp but all this data can be tossed once it is consumed. The PRU will need to be able to do some statistics on it like mean, mode, std. dev.

3 - if conditions are met, the PRU needs to tell the ARM. considering just flipping a bit in a memory location the PRU can write to and the ARM can only read from for this.

The valve on/off can handle delays of 50 ms with no issue at all.

(I'm an old dog learning new tricks. Years ago my hands-on experience was with Motorola 68xx and 68xxx series processors so I was comfortable writing directly to memory locations, registers, etc. It took me a while on returning to this to get comfortable with sysfs but I definitely see the limitations in projects like this one! Thanks for your patience and help!)

Walter Cromer

unread,

Apr 9, 2021, 2:16:32 PM4/9/21

to BeagleBoard

Thanks Dennis. That is in sync with my research.

Walter Cromer

unread,

Apr 9, 2021, 2:50:56 PM4/9/21

to BeagleBoard

When I try to run this in Cloud9, I'm getting this error. I'm not sure where type __far is defined but apparently I'm missing that definition. I have to copy pru_cfg.h over to /usr/include manually to get this far. Maybe there are other include files that are missing that it hasn't warned me about? Sorry be such as neophyte!

/usr/include/pru_cfg.h:242:10: error: unknown type name ‘__far’

volatile __far pruCfg CT_CFG __attribute__((cregister("PRU_CFG", near), peripheral));

^~~~~

/usr/include/pru_cfg.h:242:23: error: expected ‘=’, ‘,’, ‘;’, ‘asm’ or ‘__attribute__’ before ‘CT_CFG’

volatile __far pruCfg CT_CFG __attribute__((cregister("PRU_CFG", near), peripheral));

^~~~~~

PRU_AnalogReadfromGT.c:15:10: fatal error: pru_intc.h: No such file or directory

#include <pru_intc.h>

^~~~~~~~~~~~

compilation terminated.

make: *** [/var/lib/cloud9/common/Makefile:215: /tmp/cloud9-examples/PRU_AnalogReadfromGT.o] Error 1

On Friday, April 9, 2021 at 11:19:47 AM UTC-4 pierric...@gadz.org wrote:

Mark Lazarewicz

unread,

Apr 9, 2021, 2:54:55 PM4/9/21

to beagl...@googlegroups.com

Plenty of data Walter thanks.

You could write some linux code that reads Data from from PRU ram( I'm not sure if there's several ways to get Data beyond remote messaging and reading the shared ram directly) factor in delay for new sample's to be updated from ADC at least you could ensure that works in your time frame.

If that seems OK

Then use examples for PRU I'm skeptical about needing to use assembler it's not the PRU read time that's a bottleneck.

I'd be interested in seeing that PRU to ARM transfer rate it should not take alot of time but if Linux is still interfering beyond your needed specific time period you will only have one choice but to find what's exactly doing this delay and mitigation of that will be your only hope.

Typically a proof of concept fesigh verification like this is always wise.

If using this chip is your only option you'd have one option left but I don't think you would like it.

And I'm already well known for suggestioning that option on ARM so I'm not going to mention it.

I do understand the value of having a feature rich OS on ARM that's royalty free but I've been lucky on the 50 or so projects I've worked on this wasn't the issue.

Another project was a Diesel engine controller they did a DVT phase first. Design verification Test

I wish I could help on Linux side but I can't there's plenty of people in here using Linux so I think you can get more ideas and help.

Not Sure how many have used Linux in actual hard realtime systems.

Your application doesn't sound extremely hard realtime so be interested in seeing this have a happy ending.

Sent from Yahoo Mail on Android

--
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/44d5f47f-973d-4b08-bcdb-d93e0e6c3f70n%40googlegroups.com
.

Walter Cromer

unread,

Apr 9, 2021, 3:00:25 PM4/9/21

to BeagleBoard

It's a fairly simple application really and that's what makes it frustrating! We'll get there! I learn something every day and that's just fine with me.

Mark Lazarewicz

unread,

Apr 9, 2021, 3:33:21 PM4/9/21

to beagl...@googlegroups.com

I believe you will Walter

I just thought it prudent to mention doing some designs validation coding first. I do think the the through put coding could be done quickly on ARM . If you're doing the other code functions on PRU you mentioned your going to face the learning curve anyway you asked about. So you might then try some tests using ADC PRU.

Otherwise I'd do the ARM part first

Usually there's always away to shoe horn something.

Regards

Mark

Sent from Yahoo Mail on Android

On Fri, Apr 9, 2021 at 2:00 PM, Walter Cromer
<wal...@edenconceptsllc.com> wrote:

https://groups.google.com/d/msgid/beagleboard/1c1af0c5-207f-47fe-9c47-e97b563bbcecn%40googlegroups.com
.

Darren Freed

unread,

Apr 9, 2021, 3:49:59 PM4/9/21

to beagl...@googlegroups.com

For my project that used a PRU to sample the onboard ADC, I relied very heavily on the TI PRU_ADC_onChip example code, along with Mark Yoder's most excellent PRU cookbook. With those two resources, you should be able to do what you're hoping to do.

Good luck!

df

To view this discussion on the web visit https://groups.google.com/d/msgid/beagleboard/1c1af0c5-207f-47fe-9c47-e97b563bbcecn%40googlegroups.com.

Walter Cromer

unread,

Apr 9, 2021, 4:20:48 PM4/9/21

to BeagleBoard

I would not be nearly as far along if I did not have Mark Yoder's PRU Cookbook! I'll take a look at the TI documentation.

Right now, I'm working with some examples from GA Tech and the compiler running in Cloud9 IDE is balking at a __far definition in pru_cfg.h. I'm searching the GCC documentation and web for some fix for this. I suspect there must be a compiler switch to cause it to accept these but I don't know what it is or if that's even the solution. Any help would be appreciated!

Walter

TJF

unread,

Apr 10, 2021, 5:47:41 AM4/10/21

to BeagleBoard

Hi Walter!

A further "old dog" here. Sometimes I'm still working on my old Hades computer with 68060 CPU (loving that box).

In my house I'm using a BBB for a solar system running 24/7. It also controlls two valves (on/off, and four AC pumps in 16 power levels), connected to WLAN by an external USB-Stick. Most temperatures are comming from 1-wire sensors, but ADC is used to fetch samples from a high-temperature sensor on the roof/collector.

You should know that the onboard TSC_ADC_SS sometimes hangs, due to electromagnetical noice. In that case it allways measures/serves the same voltage, regardless of the changing input. There's a way to unblock the subsystem by software. But the better solution is to spend some effort in a decoupled input circruitry.

In a new project I start the controller development on ARM, doing measurements by libpruio. Once the prove of concept is done, I migrate the controller loop to the other PRU for hard real-time capability. libpruio is perfect for that concept, since the measurements are available from both sides, ARM and PRU. All setup is coded only once (on ARM), and only the inner controller loop needs adaption (from ARM to PRU). In that adaption the controller usually gets much better, since you won't repeat the bugs and pitfalls from the POC phase.

The most important initial decision is concerning the kernel driver to use. Drop rproc, and use uio_pruss driver instead. Then data exchange is pretty easy. Ie use DRam[0,1] for PRU-writing and SRam for ARM-writing. A simple and effective concept to avoid writing collisions (and pretty fast as well). uio_pruss driver provides pointers to that memory, while using rproc you've to find a solution by yourself.

Regards

Dennis Lee Bieber

unread,

Apr 10, 2021, 1:20:23 PM4/10/21

to Beagleboard

On Fri, 9 Apr 2021 11:50:56 -0700 (PDT), in

gmane.comp.hardware.beagleboard.user Walter Cromer
<walterc-2dFtBuzUeF/tpnMUCzy8b...@public.gmane.org> wrote:

>When I try to run this in Cloud9, I'm getting this error. I'm not sure
>where type __far is defined but apparently I'm missing that definition. I

>When I try to run this in Cloud9, I'm getting this error. I'm not sure
>where type __far is defined but apparently I'm missing that definition. I

That looks more like a compiler directive than a type in its own right
-- something forcing a pointer type to be a full address, and not a short
relative address. You may need to ask the source of the code what compiler
they were using?

--
Dennis L Bieber

Dennis Lee Bieber

unread,

Apr 10, 2021, 1:58:53 PM4/10/21

to Beagleboard

On Fri, 9 Apr 2021 11:15:49 -0700 (PDT), in

gmane.comp.hardware.beagleboard.user Walter Cromer
<walterc-2dFtBuzUeF/tpnMUCzy8b...@public.gmane.org> wrote:

>1 - start / stop reading the sensors - considering just flipping a bit in a
>memory location both can access for this. ARM will have write access, PRU
>will just monitor it. (I don't really know how to do this yet. Still
>learning.)

Well, since the PRU doesn't have asynchronous interrupts, using a
polling loop on the interrupt bits, that's probably reasonable -- though
I'd hope that RPMsg (since TI pushes it these days) should be usable
without a polling loop itself.

Especially if you can test for an incoming message between actually
reading an ADC sample.

>2 - raw data collected about the event by the PRU doesn't really have to be
>accessed by the ARM in normal operation. (For R&D, we'd probably like to
>have it though.) Every sensor reading has to have its corresponding
>timestamp but all this data can be tossed once it is consumed. The PRU
>will need to be able to do some statistics on it like mean, mode, std. dev.

Which probably need to be transferred to the Linux side -- another
RPMsg message block? <G> Using the same channel as #3 below, just different
message contents (or same message for both?)

>3 - if conditions are met, the PRU needs to tell the ARM. considering just
>flipping a bit in a memory location the PRU can write to and the ARM can
>only read from for this.
>

Ugh... Polling loop sucking up CPU cycles on an OS that already adds
potential process swapping when the loop eats all cycles of a quantum...

Just feels like attempting a (blocking) read on an RPMsg channel would
be cleaner. Linux side waits for PRU to send some message without eating
cycles. However ...

https://www.kernel.org/doc/html/latest/staging/rpmsg.html

... seems to rely upon a callback function for return data on the channel.
Example is too brief to really understand the API -- which does not seem to
have explicit RECV (to complement the SEND calls). Makes it a touch
confusing to me... Is the callback "active' from the moment the channel is
created, or only when a SEND operation was performed (since the channel is
considered bidrectional, I'd expect the callback to be active from the
start -- so either side can act upon a message sent by the other).

--
Dennis L Bieber

Mark Lazarewicz

unread,

Apr 10, 2021, 2:17:26 PM4/10/21

to beagl...@googlegroups.com

Hello TJF

Drop rproc, and use uio_pruss driver instead. Then data exchange is pretty easy. Ie use DRam[0,1] for PRU-writing and SRam for ARM-writing. A simple and effective concept to avoid writing collisions (and pretty fast as well). uio_pruss driver provides pointers to that memory, while using rproc you've to find a solution by yourself.

Sent from Yahoo Mail on Android

--
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/d715b191-d95b-4b86-8fae-eb618c74ddc5n%40googlegroups.com
.

Walter Cromer

unread,

Apr 12, 2021, 10:51:43 AM4/12/21

to BeagleBoard

Thanks, TJF! This sounds like good advice but tough tricks to learn! The more I think through the architecture of my solution, the more I realize the PRU code needs to do. In our lab evaluation setup, I need the voltages measured by the ADC for analysis to develop base algorithms for detecting the events from the sensors properly. But once we have that developed, in a production system, the PRU code will apply the logic to the data it is reading and probably should control the valves directly through with the GPIOs. Otherwise, if we pass the data to the ARM side, Linux could go off and service something else and leave the valves running when they shouldn't be or not running when they should be. But startup parameters will be selected by the user, so I'm thinking the UI is on ARM and once it has the start-up information, it just passes key info to the PRU code and lets it go do its thing.

So what is the long-term support for the different options? I thought remoteproc was the way of the future and uio_pruss drivers were phasing out. We are on the front end of a new product/solution design and need to pay attention to 'end of life' type issues. (Of course, the solution must work too!)

Good to know about the EM interference. Theoretically, we should be in a low external EM noise environment, however, we are using the BBB Wireless! I had painful experiences with RF wreaking havoc on a system in graduate school.

Walter Cromer

unread,

Apr 12, 2021, 10:53:22 AM4/12/21

to BeagleBoard

I'll look at that. I thought remoteproc was the way of the future so I was heading down that path. And if in production I don't need to do a lot of data transfer, does it make sense to use uio_pruss/libpruio ( I don't know much about these, it's probably evident that I don't know much about remoteproc either) ?

Walter Cromer

unread,

Apr 12, 2021, 4:08:48 PM4/12/21

to BeagleBoard

I'm working through this and learning a lot. But also realizing how much I have either forgotten or just never knew. So, can I get a quick primer on what this line of C code is doing?

HWREG(SOC_CM_WKUP_REGS + CM_WKUP_ADC_TSC_CLKCTRL) = 0x02;

Thanks!

Mark Lazarewicz

unread,

Apr 12, 2021, 4:51:52 PM4/12/21

to Walter Cromer, BeagleBoard

Look for a registrer similar name to ADC clk Ctrl in TRM under the ADC section.

That's looks like a C macro and it's writing 0x02 to that register. Macro Probably defined in a header file.

the registers will have different offsets depending on ARM or PRU access

Perhaps revisit init code on ARM you had working and document every bit that's important in ADC set-up and compare that to this PRU code.

Remember getting the Data out of PRU to ARM timings are important. I see you asked me about rproc that I don't use Linux that was TJ comments.

I'm afraid the PRU was marketed to you as the answer by people that don't understand your timing requirement. Lot's of script kiddies and cookbook reader's in this group few system engineer that actually read your intial post

Good luck

Sent from Yahoo Mail on Android

https://groups.google.com/d/msgid/beagleboard/90e0f287-b0b3-41af-9f1e-36fcd06f8dc2n%40googlegroups.com
.

Walter Cromer

unread,

Apr 12, 2021, 6:44:09 PM4/12/21

to BeagleBoard

What's really throwing me is the + between what looks like two macro values. Normally, we see the + on the right sign of the equals, right? Or am I forgetting something I used to know!?

TJF

unread,

Apr 13, 2021, 5:16:58 AM4/13/21

to BeagleBoard

I'm not a C guy (but prefering FreeBASIC for ligh-level and ASM for PRU code). Just guessing:

As lazarman mentioned HWREG is a preprocessor macro (perhaps using ARM in supervisor mode?)

SOC_CM_WKUP_REGS is the base adress of the wakeup registers in the control module

CM_WKUP_ADC_TSC_CLKCTRL is the offset for the TSC_ADC_SS clock control register

In oder to enable the TSC_ADC_SS the value 0x02 needs to be writen to that register. Afterwards you can read or write the subsystems registers. (libpruio additionally checks read acces to the ID register in order to validate that the subsystem is ready.)

Message has been deleted

pierric...@gadz.org

unread,

Apr 13, 2021, 9:40:59 AM4/13/21

to BeagleBoard

To complete on TJF answer, you can find the address defined by CM_WKUP_ADC_TSC_CLKCTRL in hw_cm_wkup.h line 101value (0xbc) and in soc_AM335x.h line 139.

Walter Cromer

unread,

Apr 13, 2021, 10:00:01 AM4/13/21

to BeagleBoard

After posting this, I realized this was a macro and that it was passing the sum of the two values. That seemed weird to me.

Thanks for the confirmations! It is coming back slowly!

Dennis Lee Bieber

unread,

Apr 13, 2021, 10:54:36 AM4/13/21

to Beagleboard

On Mon, 12 Apr 2021 13:08:48 -0700 (PDT), in

gmane.comp.hardware.beagleboard.user Walter Cromer
<walterc-2dFtBuzUeF/tpnMUCzy8b...@public.gmane.org> wrote:

>What's really throwing me is the + between what looks like two macro
>values. Normally, we see the + on the right sign of the equals, right?
>Or am I forgetting something I used to know!?
>

Why? Take into account the ()s.

From what I can tell, this is adding the ADC register offset to the
base address of the (?) wakeup register block, which is passed as parameter
to HWREG (no doubt some macro that sets up actual access to the SoC
registers and returns a pointer or some such), and then assigns 0x02 into
the register so indicated.

--
Dennis L Bieber

Mark Lazarewicz

unread,

Apr 13, 2021, 11:25:08 AM4/13/21

to beagl...@googlegroups.com

Walter

Your best bet.

Run your whole control loop on the PRU that's as realtime as you get. Use a foreground background loop. Use the ARM like a PC with Linux to access the system via ethernet.

You could also run control on ARM without linux but this way you have all the resources of Linux to access the system.

This assumes your output's from control loop are accessable from PRU.

The point is Linux can only run slow control loops and this way you don't have to debug the delay.

This wasn't obvious to me before as all the hard realtime systems I work on run an RTOS on ARM it has all the resources of Linux but cost $$$$$.

In our system we did that on the DSP the PID did the math on a fast DSP.

ARM is just a gateway to outside world.

Myself I'd debug the PRU with JTAG and CCS you can see exactly what's going on and dump these registers from CCS.

Some people like printf but with a PRU based system you are essentially doing barebones.

There's videos on PRU development doing this online.

Loading code via rproc and using printf is like burning and erasing an eeprom to test your changes. You wait 45 minutes for it to erase try your code and do it again.

Not for me.

Mark

Sent from Yahoo Mail on Android

--
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+unsub...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/beagleboard/44cb7gtf6pl4d4j3e6oqo57g5n0hobi29c%404ax.com.

Walter Cromer

unread,

Apr 13, 2021, 2:17:00 PM4/13/21

to BeagleBoard

Yeah, I woke up realizing what a dunce I was reading it the way I was. HWREG equates to (*((volatile unsigned int *) (x)))

Walter Cromer

unread,

Apr 13, 2021, 2:25:06 PM4/13/21

to BeagleBoard

We're designing it the way you suggested. The nice thing is that basically the control logic has already been written in C on the ARM side. Now, I just need to get it ported to the PRUs and create the communications between the PRUs and a new ARM app that supervises everything from the user's point of view. Meaning, taking inputs like start, stop and giving feedback by turning LEDs on and off. And it needs to take in some basic system configuration data from the cloud periodically that the PRU will consume to adjust it's operation.

I am making progress. Part of my problem was using Cloud9 for development. That's where all my ARM development has been so far. I have CCS installed on my Windows 10 machine and started working through TI's PRU Hands On Labs. Unfortunately, the very first one doesn't work because their document is written for CCS running on Linux. Step 6 says to delete the linker file and add it back with Project->Add Files but that's grayed out. I've asked TI about that. But I got it to compile by writing on the Beagle using nano and compiling it there. I've ready a lot of TI documentation today and learned a lot.

Here's one more thing I am struggling with though. It's a mental block I think. I'm used to controlling GPIOs on the ARM side using sysfs. It appears that on the PRU, we use __R30 instead but I don't understand how that works. I read through it this morning and it still isn't sinking in. If anyone can help make this clearer, I'd appreciate it.

TJF

unread,

Apr 14, 2021, 1:39:56 AM4/14/21

to BeagleBoard

Nano isn't best choice for polyglot applications. I'm using Geany (on PC exchanging source files via virtual file system), while I compile and test under LINUX on the BB.

wal...@edenconceptsllc.com schrieb am Dienstag, 13. April 2021 um 20:25:06 UTC+2:

Here's one more thing I am struggling with though. It's a mental block I think. I'm used to controlling GPIOs on the ARM side using sysfs. It appears that on the PRU, we use __R30 instead but I don't understand how that works. I read through it this morning and it still isn't sinking in. If anyone can help make this clearer, I'd appreciate it.

Check out example pruss_toggle.

Walter Cromer

unread,

Apr 14, 2021, 11:02:56 AM4/14/21

to BeagleBoard

My setup is a Windows 10 PC with a Black connected via USB or a Black wireless connected via wi-fi. So far I have done all the C development on the ARM side with Cloud9 and only occasionally use Nano. It's met my needs just fine so far but this is getting more complex. I installed TI's CCS but it (or TI) prefers to be on a Linux box apparently.

Walter Cromer

unread,

Apr 14, 2021, 11:03:30 AM4/14/21

to BeagleBoard

The TSC_ADC only has 8 channels. So why are there 16 STEP registers?

Walter Cromer

unread,

Apr 14, 2021, 11:58:31 AM4/14/21

to BeagleBoard

So I looked over the libpruio page and it looks great. My head's spinning a bit between remoteproc, uio, and libpruio options but I'd like to try libpruio.

I don't want to break remoteproc if I set up to use libpruio. Will that happen?

Also, I'm running Buster (version.sh) at the bottom of this post

The instructions refer to Jessie. Are the Debian packages referred to compatible with Buster? Here's what I am referring to.

The easy way to benefit from libpruio is to install the Debian packages. They're not in mainline, yet. So you have to add a PPA (Personal Package Archive) to your package management sources. On the default Debian operating system, edit the file sudo nano /etc/apt/sources.list and add the lines:

deb http://beagle.tuks.nl/debian jessie/ deb-src http://beagle.tuks.nl/debian jessie/

Then grep the keyring by (mind the '-' character at the end)

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

Once prepared, you can update your package manager database

sudo apt-get update

debian@beaglebone:/$ sudo opt/scripts/tools/version.sh

git:/opt/scripts/:[b39ec679648a6be8f25f48bd1c9784c1fc5a0c46]

eeprom:[A335BNLT00C04417BBBK1847]

model:[TI_AM335x_BeagleBone_Black]

dogtag:[BeagleBoard.org Debian Buster IoT Image 2020-04-06]

bootloader:[microSD-(push-button)]:[/dev/mmcblk0]:[U-Boot 2019.04-00002-g07d5700e21]:[location: dd MBR]

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

UBOOT: Booted Device-Tree:[am335x-boneblack-uboot-univ.dts]

UBOOT: Loaded Overlay:[AM335X-PRU-RPROC-4-19-TI-00A0]

UBOOT: Loaded Overlay:[BB-ADC-00A0]

UBOOT: Loaded Overlay:[BB-BONE-eMMC1-01-00A0]

UBOOT: Loaded Overlay:[BB-HDMI-TDA998x-00A0]

UBOOT: Loaded Overlay:[BB-I2C2-RTC-DS3231]

UBOOT: Loaded Overlay:[BB-W1-P9.12-00A2]

kernel:[4.19.94-ti-r61]

nodejs:[v10.15.2]

/boot/uEnv.txt Settings:

uboot_overlay_options:[enable_uboot_overlays=1]

uboot_overlay_options:[uboot_overlay_addr4=/lib/firmware/BB-W1-P9.12-00A0.dtbo]

uboot_overlay_options:[uboot_overlay_pru=/lib/firmware/AM335X-PRU-RPROC-4-19-TI-00A0.dtbo]

uboot_overlay_options:[enable_uboot_cape_universal=1]

uboot_overlay_options:[dtb_overlay=/lib/firmware/BB-I2C2-RTC-DS3231.dtbo]

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

pkg:[bb-cape-overlays]:[4.14.20210401.0-0~buster+20210401]

pkg:[bb-wl18xx-firmware]:[1.20200322.0-0rcnee0~buster+20200322]

pkg:[kmod]:[26-1]

pkg:[librobotcontrol]:[1.0.4-git20190227.1-0rcnee0~buster+20190327]

pkg:[firmware-ti-connectivity]:[20190717-2rcnee1~buster+20200305]

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

cmdline:[console=ttyO0,115200n8 bone_capemgr.uboot_capemgr_enabled=1 root=/dev/mmcblk0p1 ro rootfstype=ext4 rootwait coherent_pool=1M net.ifnames=0 lpj=1990656 rng_core.default_quality=100 quiet]

dmesg | grep remote

[ 66.835497] remoteproc remoteproc0: wkup_m3 is available

[ 67.240120] remoteproc remoteproc0: powering up wkup_m3

[ 67.240151] remoteproc remoteproc0: Booting fw image am335x-pm-firmware.elf, size 217148

[ 67.240404] remoteproc remoteproc0: remote processor wkup_m3 is now up

[ 69.894313] remoteproc remoteproc1: 4a334000.pru is available

[ 69.907897] remoteproc remoteproc2: 4a338000.pru is available

[15549.657580] remoteproc remoteproc1: powering up 4a334000.pru

[15549.665009] remoteproc remoteproc1: Booting fw image am335x-pru0-fw, size 30880

[15549.665035] remoteproc remoteproc1: header-less resource table

[15549.675909] remoteproc remoteproc1: Boot failed: -22

[15602.811891] remoteproc remoteproc1: powering up 4a334000.pru

[15602.812184] remoteproc remoteproc1: Booting fw image am335x-pru0-fw, size 30880

[15602.812202] remoteproc remoteproc1: header-less resource table

[15602.823804] remoteproc remoteproc1: Boot failed: -22

[15801.464252] remoteproc remoteproc1: powering up 4a334000.pru

[15801.464540] remoteproc remoteproc1: Booting fw image am335x-pru0-fw, size 30880

[15801.464559] remoteproc remoteproc1: header-less resource table

[15801.475947] remoteproc remoteproc1: Boot failed: -22

[15835.561165] remoteproc remoteproc1: powering up 4a334000.pru

[15835.561459] remoteproc remoteproc1: Booting fw image am335x-pru0-fw, size 30880

[15835.561478] remoteproc remoteproc1: header-less resource table

[15835.575362] remoteproc remoteproc1: Boot failed: -22

[15973.384568] remoteproc remoteproc1: powering up 4a334000.pru

[15973.384866] remoteproc remoteproc1: Booting fw image am335x-pru0-fw, size 30880

[15973.384884] remoteproc remoteproc1: header-less resource table

[15973.395805] remoteproc remoteproc1: Boot failed: -22

[15996.157221] remoteproc remoteproc1: powering up 4a334000.pru

[15996.157504] remoteproc remoteproc1: Booting fw image am335x-pru0-fw, size 30880

[15996.157523] remoteproc remoteproc1: header-less resource table

[15996.171335] remoteproc remoteproc1: Boot failed: -22

[16031.348941] remoteproc remoteproc1: powering up 4a334000.pru

[16031.349226] remoteproc remoteproc1: Booting fw image am335x-pru0-fw, size 30880

[16031.349244] remoteproc remoteproc1: header-less resource table

[16031.359886] remoteproc remoteproc1: Boot failed: -22

[26382.806806] remoteproc remoteproc1: powering up 4a334000.pru

[26382.807380] remoteproc remoteproc1: Booting fw image am335x-pru0-fw, size 94376

[26382.820350] remoteproc remoteproc1: registered virtio0 (type 7)

[26382.820370] remoteproc remoteproc1: remote processor 4a334000.pru is now up

dmesg | grep pru

[ 69.894313] remoteproc remoteproc1: 4a334000.pru is available

[ 69.894508] pru-rproc 4a334000.pru: PRU rproc node pru@4a334000 probed successfully

[ 69.907897] remoteproc remoteproc2: 4a338000.pru is available

[ 69.908098] pru-rproc 4a338000.pru: PRU rproc node pru@4a338000 probed successfully