EMC2 running on Raspberry Pi?

mungkie wrote:

I got latency-test figures similar to:
servo thread(1.0ms) 1380000 380000
base thread(50.0us) 103000 53000

Ugh, those are sure not great numbers. 1 ms thread with 380 us jitter, that is
38%. And, base thread with a 50 us period having a 53 us jitter, that is
overrunning into the next period. So, software step generation is pretty
much out of the question, and a 1 ms servo loop is likely not going to
work, either. Rather disappointing, but not a surprise for the rather
underpowered Pi CPU plus the mediocre performance of
the preempt kernel when the RT periods get down in this range.

It might be interesting to try this on the Beagle Board XM or Beagle Bone,
which have a significantly faster CPU.

Jon

jmelson wrote:

It might be interesting to try this on the Beagle Board XM or Beagle Bone,
which have a significantly faster CPU.
Jon

Do you think the rpi will be totally unable to run linuxcnc reasonably?

Should I give up on this project, wait for someone to make a xenomai port, or look at the RT_PREEMPT patches to see if impovements can be made?

From the base clock speed I would have assumed that linuxcnc could run on the rpi, if clocks can be compared with x86 clock frequencys.

I think I setup base-thread at 1ms and servo thread at 4ms in my configs and hoped that I would get 1khz stepping but even at that speed the system seemed glitchy and I thought maybe the i2c driver was causing problems?.

I keep telling myself that maybe fixes in the usb and networking drivers and accelerated X and opengl could speed the system up and fix the problems?

I am sort of almost happy to put up with the crappy performance as I am only hacking this as a hobby for fun and constant velocity or acceleration control is not really necessary to me, I wish some experts could fix this, but I am starting to get the feeling the expert opinion is linuxcnc will not work reliably on the rpi.

How much do beagles cost?

Well 53 uSec of base thread jitter is not great but probably usable for up to 10 KHz or so step rates. Thats 360 RPM with 1/8 uSteps which may be perfectly usable for some things.

mungkie wrote:

jmelson wrote:

It might be interesting to try this on the Beagle Board XM or Beagle Bone,
which have a significantly faster CPU.
Jon

Do you think the rpi will be totally unable to run linuxcnc reasonably?

I don't know. Those results you posted looked pretty bad. I don't know why. It could be a combination
of things, or possibly one big thing that is making the performance so bad. One thing I don't know
about rt-preempt is whether each real time task in a thread runs in its own address space (needing a
cache scrub) or only the whole thread. If it needs a cache scrub for every task in the thread, it
will be spectacularly bad when running a real hal thread, as LinuxCNC often has 20 or more separate
tasks in the servo thread. So, this is the thing that has me worried that there could be some REALLY
bad news ahead. (What I'm saying here is that actual LinuxCNC performance could be MUCH worse
if the full address space switch needs to be done for each addf item in the thread, but I don't
know if that is true.) The latency test doesn't run a whole bunch of tasks in the thread.

I think I setup base-thread at 1ms and servo thread at 4ms in my configs and hoped that I would get 1khz stepping but even at that speed the system seemed glitchy and I thought maybe the i2c driver was causing problems?.

1 ms for base thread is REALLY slow, most people run about 20 times faster for software
stepping.

How much do beagles cost?

The old-version Beagle is now down to $125, the Beagle XM is $175, the Beagle Bone
in $89. The Bone leaves out some stuff, but has more I/O pins available.
It has an ~700 MHz CPU, 256 MB of main memory, uses an SD card as a "disk"
and is slightly bigger than a credit card. It has 10/100 Ethernet, but no video
output directly from the board. So, you need to add a "cape" board to hook
video directly to it. Or, you can export your video display on any system via
ssh -X.

The other Beagle Boards have XDVI output so you can connect a standard
computer LCD monitor directly.

Jon

mungkie wrote:

mhaberler wrote:

I try to figure out whether the Rpi is a viable platform for a HAL/RT (part of) LinuxCNC

that means exploring the IO path latency among many other probably more important aspects like timing precision and context switching latency

- Michael

...
Your tests show if there is any extra latency or load added to the system by handliing the IO??

No, I read the result as follows:
- the IO path latency looks ok in principle for stepgen tasks, modulo wait states
- the RT scheduling in my current kernel does not suggest this is a very bright idea
- the thing to be looked at is the high resolution timer support in the Raspbian kernel

it looks like clock_nanosleep() is pretty useless at least on my current kernel (stock; Linux raspberrypi 3.2.27+ #102 PREEMPT Sat Sep 1 01:00:50 BST 2012 armv6l GNU/Linux) - it gave a minimum delay of some 25usec

That would be needed to generate a precise, low jitter pulse train; so without the timer issue resolved I dont see how this can happen

example to make the point:
you run a 50kHz stepgen thread, means the thread function chain (addf ...) needs to be called every 20uS
assume the thread chain takes say, 12uS to execute, but that might vary
when the thread chain is done, the stepgen thread needs to compute the remaining time based on the actual chain running time until the next time slot (+/- 8uS) and start a high precision delay with that period

so if your 'hires' delay starts at 25uS no matter how short the delay parameter is, this dog will not hunt

-m

After some reading in github.com/bootc/linux/blob/rpi-3.2.23/a...ch-bcm2708/bcm2708.c I think there are currently only two relevant timing sources:

- a interrupt-based timer which runs at 10KHz, which could be the base of 'p recision sleeping
- a free-running 1MHz counter TCR which doesnt interrupt, so it cant be the source of 'precision sleeps'

if this is so, sleep time resolution is 100uS and no better, which explains my observation

-m

ps: take with a grain of salt, I dont understand that much of the linux kernel