EMC2 running on Raspberry Pi?

Pete,

yes, hardware drivers are open issues for such boards. there's hal_gpio and kinsamanka's rpi SPI driver for a start, plus Charle's PRU stepper.

Generally, any linux driver for candidate peripherals are useless, since those cannot be used from a realtime thread - the system call for say open/read/write/ioctl/ etc would kill realtime behavior.

So writing a HAL driver means excerpting the interesting stuff out of existing kernel drivers, disabling those, and replicating that in a HAL module. Whether it's offloaded with SPI or done through GPIO is really a question of performance (eg Stepper) and pin availablity. On the Beaglebone there are lots of pins which are also available for the PRU coprocessors, so there isnt much point in doing the stunt kinsamanka did with the picnc - the PRU performs better than any 8bit uC and there are negligible communication delays too.

As for boards - that is a matter of taste to some extent; I think the BeagleBone boards are an excellent base - lots of pins, good stepper performance, no outboard needed.

The stability of the rtos-integration-preview3 branch is reasonably good - there have only been retouche patches over the last two months. It should hit the main repo within weeks, not months.

- Michael

otto_pjm wrote: Michael

Great thanks for the pointer on the Olinuxino stuff. It looks like the A13 would be the board to get to pursue this route. (which looks like the same components as the pcDuino, to my untrained eyes) I'm not terribly savvy about all of this but it appears they are working towards using the native GPIO as opposed to off-loading to another processor as with the SPI to PIC mentioned above?

I'll poke around the Olinuxino forums some more and try and work out a few more details. This is getting quite exciting it looks like LinuxCNC on ARM in a supported fashion is getting closer.

Thanks

Pete

Michael,

Thanks that a great overview of the current and possible options for ARM.

Pete

re highspeed stepgen on Raspberry:

I just stumbled over this and it looks like the method described there could be subverted for a high-speed, precise, low-overhead stepgen directly on the Pi:

pythonhosted.org/RPIO/pwm_py.html#subcycles

(I did not try; I will not try and it looks non-trivial to start with)

- Michael

mhaberler wrote: I just stumbled over this and it looks like the method described there could be subverted for a high-speed, precise, low-overhead stepgen directly on the Pi:

It seems to say that the max frequency is 500Hz (2mS minimum time). I might be miss-reading it.

thats not what I read, but I'll meet the author in a week or two and have him explain

unfortunately the method is useful only on the output side; it wont help e.g. with encoders

-m

I think the author is using this for R/C servos at 50 Hz (1-2 ms range so 1 uSec timing gives ~10 bits of resolution = fine for R/C servos)

1 uSec is a bit crude for PWM (<6 bit resolution at 20 KHz), but low CPU overhead and output channels only limited bit GPIO bits.

Strangely enough we did the exact thing about 20 some years ago for a ~0 hardware LCD interface using DMA (the LCD contrast was done with a PDM "track" in the DMA'ed LCD data stream)

A stepgen would be a bit tricker as it would have to be able to generate the memory patterns for the DMA faster than the DMA consumed them.

Also you can read encoders this way (DMA in the Port data to a circular RAM buffer and process the say 1024 samples every servo tic)