EMC2 running on Raspberry Pi?

More
05 Sep 2012 07:05 - 05 Sep 2012 11:38 #23904 by ArcEye
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
Last edit: 05 Sep 2012 11:38 by ArcEye.

Please Log in or Create an account to join the conversation.

More
05 Sep 2012 18:39 #23942 by mungkie
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.

Please Log in or Create an account to join the conversation.

More
05 Sep 2012 19:30 #23943 by mhaberler
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

Please Log in or Create an account to join the conversation.

More
06 Sep 2012 15:45 #23984 by mungkie
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

Please Log in or Create an account to join the conversation.

More
07 Sep 2012 11:02 #24009 by ArcEye
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

Please Log in or Create an account to join the conversation.

More
07 Sep 2012 13:59 #24021 by wizard69
Replied by wizard69 on topic Another ARM board coming.
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.

Please Log in or Create an account to join the conversation.

More
07 Sep 2012 23:35 #24053 by mungkie
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?

Please Log in or Create an account to join the conversation.

More
08 Sep 2012 10:34 #24062 by mhaberler
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

Please Log in or Create an account to join the conversation.

More
08 Sep 2012 17:39 - 08 Sep 2012 17:40 #24072 by jmelson
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
Last edit: 08 Sep 2012 17:40 by jmelson. Reason: cleanup

Please Log in or Create an account to join the conversation.

More
08 Sep 2012 19:28 #24073 by mungkie
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 :D ).

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.

Please Log in or Create an account to join the conversation.

Time to create page: 0.200 seconds
Powered by Kunena Forum