beaglebone, PREEMPT-RT and low latency ADC/DAC

GoogleGroups
1

This might be completely random (i’m not familiar with RT linux at all, and only beginning with beaglebone), but wouldn’t the PRUSS be useful here? The way I understand it, it’s just a real time core in the Sitara processor that you can program independently, and maybe control from the linux user space. A quick google turned up these threads that might be worth a read:

https://groups.google.com/forum/#!topic/beagleboard/SYkkZaWWUeg thread talking about official support (or lack there of) and community support for the PRUSS.

https://github.com/beagleboard/am335x_pru_package Github link to go along with that talk.

https://gforge.ti.com/gf/project/pru_sw/ Description says there are code examples here, but I don’t know enough to say if useful or not.

Sorry if this isn’t useful. I just remember reading about the PRUSS and was thinking it might help.

2

I did have a bit of a look at this. One problem is that I need to do floating point calculations. The problem could probably be recast to fixed point but it would be complex calculation in PRUSS assembler. Perhaps it would possible for the PRUSS to perform the DAQ io and hand the calculation to a kernel thread…

3

I did have a bit of a look at this. One problem is that I need to do floating point calculations. The problem could probably be recast to fixed point but it would be complex calculation in PRUSS assembler. Perhaps it would possible for the PRUSS to perform the DAQ io and hand the calculation to a kernel thread…

Hi Evan,

Same problem as before. Linux response is not deterministic and hence it cannot process the calculation and return the result in 10uS. Using the PRUSS for DAQ is no better than using DMA. Can you explain why you need the calculated output to occur in 10uS?

Regards,

John

4

Update:

  • As predicted by others jitter in a standard 3.2.28 kernel is terrible, milliseconds in some cases.
  • I’ve tried nanosleep but it seems to have a minimum resolution of around 75us even when called with a sleep of 0 (min 32us, max 1200us, mean 77us). The CPU is at about 27% indicating that is it doing some sort of wait. Can someone suggest a finer grained sleep function? The PRU might be an option here?

Even though I think starterware will be the long term solution I want to play with llinux while I get my embedded skills up.

Thanks again for great help so far.
Evan.

5

I managed to compile 3.2.28 with PREEMPT_RT. The first thing I noticed is that the CPU frequency is now 600MHz instead of 720MHz!!! Has anyone else noticed this behaviour?

Old kernel ====>>>>

root@beaglebone:~# uname -a
Linux beaglebone 3.2.28 #1 Thu Aug 30 10:18:55 CEST 2012 armv7l GNU/Linux
root@beaglebone:~# cpufreq-info
cpufrequtils 008: cpufreq-info © Dominik Brodowski 2004-2009
Report errors and bugs to cpufreq@vger.kernel.org, please.
analyzing CPU 0:
driver: omap
CPUs which run at the same hardware frequency: 0
CPUs which need to have their frequency coordinated by software: 0
maximum transition latency: 300 us.
hardware limits: 275 MHz - 720 MHz
available frequency steps: 275 MHz, 500 MHz, 600 MHz, 720 MHz
available cpufreq governors: conservative, ondemand, userspace, powersave, performance
current policy: frequency should be within 275 MHz and 720 MHz.
The governor “performance” may decide which speed to use
within this range.
current CPU frequency is 720 MHz (asserted by call to hardware).
cpufreq stats: 275 MHz:0.00%, 500 MHz:0.00%, 600 MHz:0.00%, 720 MHz:100.00%

New kernel ====>>>>

root@beaglebone:~# uname -a
Linux beaglebone 3.2.29-rt42-psp22 #1 PREEMPT RT Mon Sep 17 14:54:25 EST 2012 armv7l GNU/Linux
root@beaglebone:~# cpufreq-info
cpufrequtils 008: cpufreq-info © Dominik Brodowski 2004-2009
Report errors and bugs to cpufreq@vger.kernel.org, please.
analyzing CPU 0:
driver: omap
CPUs which run at the same hardware frequency: 0
CPUs which need to have their frequency coordinated by software: 0
maximum transition latency: 300 us.
hardware limits: 275 MHz - 600 MHz
available frequency steps: 275 MHz, 500 MHz, 600 MHz
available cpufreq governors: conservative, ondemand, powersave, userspace, performance
current policy: frequency should be within 275 MHz and 600 MHz.
The governor “userspace” may decide which speed to use
within this range.
current CPU frequency is 600 MHz (asserted by call to hardware).
cpufreq stats: 275 MHz:nan%, 500 MHz:nan%, 600 MHz:nan%

6

Well, take out the 720Mhz disable patch on your next build. :wink:

https://github.com/RobertCNelson/linux-dev/blob/am33x-v3.2/patch.sh#L183

Although, it's probably safe to renable by default now.. We were
having stability problems in the past and it turned out it was the
tied to the very-low frequency opp point..

Regards,

7

That’s pretty funny.

My testing shows that PREEMPT_RT is still pretty bad at controlling latency and jitter on the time scale I need (~20us). I’ve used RTAI on x86 in the past and it was pretty good. Sadly it doesn’t seem to tracking current kernel development.

Evan.

8

That's pretty funny.

My testing shows that PREEMPT_RT is still pretty bad at controlling latency
and jitter on the time scale I need (~20us). I've used RTAI on x86 in the
past and it was pretty good. Sadly it doesn't seem to tracking current
kernel development.

You can also take a look and Xenomai [1] which uses similar approach
as RTAI but is currently under active development. We were able to get
some good results with it on BeagleBoard (not the Bone) as described
here [2,3]

[1] http://www.xenomai.org
[2] Precise PWMs with GPIO using Xenomai kernel module
[3] Comfortable kernel workflow on Beagleboard XM with nfsroot
- these instructions are for 2.6 kernel, but we are currently moving
to 3.2.21.

Regards,
Andrey.

9

Thanks. I'll have a close look at this.