EMC2 running on Raspberry Pi?

mungkie,

there seems to be something wrong with the link you posted - could you check?

- Michael

I hope this goes through, I'm getting many 502 errors for one reason.

In any event what do you mean runs like crap? Is that general slowness or something specific to LinuxCNC? I've been following this thread for awhile now, you have made significant progress.

Hi

Farnells tell me my R Pi is en route, so I am interested in your download too.

EDIT: In fact it has just arrived!

Unfortunately left clicking on the link gets a site about sound proofing and right clicking and saving gets something that is very small and isn't a valid tar ball.

regards

OOPs, I just found there is a problem with hosting, as I got free hosting from a friend and they set a maximum file size for downloads as they dont want their server getting thrashed or any extra bills.

I will try and sort out hosting on sourceforge or berlios as I have accounts there if I can work out what the login details are.

I hopefully will sort this out tonight although last time I logged into berlios was a few years ago and I remember having terrible problems with getting my password right.

Also please note the install package should work but I have added things that could void your RPI warranty like overvolting the soc so that it can run at 1Ghz, also I have not properly tested all the scripts so it may be best to read through and check things first (though if any system corruption occurs reflashing the SD card is very simple).

I hope I should get time to arrange uploading in about 4-5 hours as I have other stuff to do first, on the off chance I have problems, if anyone else has suggestion for hosting let me know.

I played with my Raspberry a bit and it seems straightforward to build a hal_gpio component

all the missing pieces are in the C-code in this package pypi.python.org/pypi/RPi.GPIO/0.3.1a#downloads

I/O is memory mapped - so it's just read/write of memory locations


- Michael

mhaberler wrote:

I played with my Raspberry a bit and it seems straightforward to build a hal_gpio component

all the missing pieces are in the C-code in this package pypi.python.org/pypi/RPi.GPIO/0.3.1a#downloads

I/O is memory mapped - so it's just read/write of memory locations


- Michael

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??

If you check the html doc in the tarball it should give some info about how to start implementing other io options I will eventually get round to interfacing an avr via i2c as it looks like there is plenty of avr code for i2c.

PLEASE LET ME KNOW IF THE TARBALL WORKS, I HAVE NOT TESTED IT!
ftp://ftp.berlios.de/pub/natld/rpi_cnc.tgz
ftp://ftp.berlios.de/pub/natld/rpi_cnc.tgz

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

I just came across these guys: cubieboard.org/ whom are trying to deliver another open ARM based board. Maybe something to keep an eye on. The board is expected to be more expensive that Raspbeery PI but it sounds like it will be more powerful. Documentation isn't out yet so I really don't know the comple port situation, I'm hoping it is suitable equipped to handle LinuxCNC.

In any even they are expected to ship soon.

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