EMC2 running on Raspberry Pi?

mhaberler wrote:

I've not relied on my feelings and made some measurements.

The gist: GPIO wiggling through the memory mapped interface is pretty fast - actually more than an order of magnitude faster than a parport on a PC driven with this: git.mah.priv.at/gitweb/emc2-dev.git/blob...simdrivers/ppioctl.c

busy-looping and wiggling GPIO 0 goes down to 220nS transition spacing; I never got less than 5uS on a PC parport.

code, results, LA screenshots are here: git.mah.priv.at/gitweb/raspberry-test.gi...44f95116ce764ae01f4a

- Michael

Excellent, thanks for the data! Well, a modern PC with motherboard parport can usually flip a bit in about 600 ns,
with a PCI parport card it can be down to 400 ns or so, from kernel mode, or with direct access to the
par port registers from user mode.

Similar testing with the OMAP3430 CPU in the Beagle Board shows 240 ns between updates. Some testing I
have done seems to indicate the CPU is in a wait state until the pin is updated. This is approximately a
100:1 slowdown of the CPU, however, which I find annoying.

Thanks for the data,

Jon

mhaberler wrote:

I've not relied on my feelings and made some measurements.

The gist: GPIO wiggling through the memory mapped interface is pretty fast - actually more than an order of magnitude faster than a parport on a PC driven with this: git.mah.priv.at/gitweb/emc2-dev.git/blob...simdrivers/ppioctl.c

busy-looping and wiggling GPIO 0 goes down to 220nS transition spacing; I never got less than 5uS on a PC parport.

code, results, LA screenshots are here: git.mah.priv.at/gitweb/raspberry-test.gi...44f95116ce764ae01f4a

- Michael

Good to see someone has equipment and expertise to see what is actually happening on the IO pins, I am afraid to say I am really just a hack and am learning this stuff as I go so all help is appreciated.

I think the gpio driver will be important for getting higher speed stuff working, but as I said it looked like too much hassle for me to try, I don't know if the gpio is latched or what logic type it uses, I have not checked any specs on it but I know the could be alot more circuitry required for interfacing as the logic levels run at 3.3volt. I imagine the broadcom datasheet should have all required specs (I put a copy in the tarball).

I used an i2c IO expander as it meant there was no need for any extra circuits for latching and level conversion, the mcp23017 'just works' (though I am not sure of this after my initial tests ).

The i2c expander should be able to flip 16 5volt IO pins at 60kHz, or 32 pins at 30kHz, etc...

If you check the linuxcnc driver for the mcp23017 in tree/src/hal/rpi/mcp23017.c there are some comments about my worrys on setting up the control registers and the bcm i2c clock speed (BSC_DIV ).

I am going to do a bit of coding tomorrow so may look at the mcp23017 driver again, though I got my atmega168 chip delivered so will probably be hacking that to see how it works with i2c first.

we're probably looking at different things here

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

Personally I dont care how pins are connected, as long its fast enough, which gpio it is - that isnt the core problem for me (the wait state Jon mentioned could be an issue)

that said, I think i2c will definitely not speed up the IO path

- Michael

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

I thought running the script 'scripts/latency-test' would give all required details about latency and jitter for setting up the base-thread and servo-thread ????

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

I am probably talking out my butt as I have not explored the linuxcnc source code much and really dont know how the underlying code works?

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

If I want to test additional latency added by my driver could I edit scripts/latency-test so that it loads my driver into hal when it make the latency tests??

How much extra latency could a driver normally add, I assumed it was just copying data into a register/buffer and the main processor then continued with other work while a hardware subsystem handled the transfer without effect on the main processor??

I have not really read the datasheet properly

I just sort of hacked things together to see if they worked, am I looking at things wrong?

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