EMC2 running on Raspberry Pi?

ArcEye wrote:

Hi

The download works fine thanks, I have had a quick look at it but will not be able to do any proper playing with it until a couple of extra SD cards I have ordered for development appear.

Am currently running a debian based image to prove it and it works better than it deserves to really, for such a limited processor and memory.

I may try building the xenomia rt kernel first, as that is perhaps best documented and see where that leads me.

regards

Would be very interested to see work on xenomai as some docs I read seem to suggest it has lower latency than RT_PREEMPT, I actually was considering trying it myself and copied the RT_PREEMPT wrapper files from src/rtapi into a directory and renamed them to start using as template files for porting to xenomai.

I think it will be a lot of work, so I doubt I will be hacking it myself to quite some time.

I have pretty much stalled on any work as I am waiting for an accellerated X server and RPI GPU naitive mesa libs and a GPU implementation of python OGL to speed all the graphics up.

I still like to believe that once the GPU is used for all the graphic intensive processing there will be plenty of speed for running linuxcnc possibly even with servos like in the etch servo configs?

I am also still a little unsure of the i2c stuff and weather there could be some problems in the driver config I used slowing the system down?

mungkie wrote:

..
I get the feeling that running direct from the gpio pins as a parallel interface is more hassle than its worth, I have done everything via the i2c bus with an expander chip, the rpi has hardware that makes handing i2c very simple with everything automatically buffered and checked and should be possible to send 16bits at 50Khz. I think SPI is handled similarly but much faster, though only a single device per bus.

Also I believe there has been a board revision so some of the gpio pins are changed on new boards, I dont yet know if it effect my drvers??
...

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

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 :blush:

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