EMC2 running on Raspberry Pi?

actually it looks like this is a common problem with kernels ported to new hardware. Just because the kernel has the RT_PREEMPT patch applied, high resolution timers do not suddenly spring into existence..

this link has quite informative references on the theme: www.spinics.net/lists/linux-rt-users/msg06424.html

-m

this page might be interesting wrt the timer question, and for those interested in xenomai on the Rpi:

www.raspberrypi.org/phpBB3/viewtopic.php?t=12368&p=154691

-Michael

Hi

www.raspberrypi.org/phpBB3/viewtopic.php?t=12368&p=154691

I have built this kernel despite these instructions! They appear in different guises in several places.

The link to a 3.2.1 branch in fact gets you a 3.4.x branch, the prepare-kernel.sh script is not present in 2.6.1 xenomai and I had to get it elsewhere.
Neither of the patches work with this.

If you download 3.2.1 from www.kernel.org, the ipipe patch works but the rpi-xenomai patch still does not.
That is because one of the file patched does not exist in the default kernel arm source tree and is the very one which deals with the timer changes
The resulting kernel built but would not run.

I am waiting for another SD card to run a pre-built xenomai image to decide if it is worth persisting with.

The rpi-linux-xenomai patch is all to do with the timer and includes this hunk

regards

Well, I cannot help thinking that no one here really has the expertise or knowledge to say much about the realtime on ARM as linuxcnc has never been run realtime on arm before???

I see some errors in what has been written, but I think I have probably less idea than others, I was going to say something about the xenomai patch as its very simple and easy to read what it does(according to the comments), but I have no idea if it works.

The xenomai patch was in my tarball but I have not actually got it working as I only tried cross compiling and the kernel did not boot. I would suggest checking your build environment or compiling it on the rpi to be sure its building with correct options, also I would suggest doing 'cat /proc/config.gz' and then editing the config produced with 'make menuconfig'.

I had another total SD card crash and lost all data, which meant I used the tarball I posted here to try recompiling, I found that the compile.sh script has numerous errors and will not create a working system, no one has used it and pointed this out to me????

With regards to clocks on the RPI I think most use the 1Mhz clock for realtime interupt but I treat everything I have used as a 'blackbox' that should just work and I used the RT_PREEMPT patch as it is part of the mainline kernel so should work 'out of the box'. I don't generally try to fully read and understand the patches.

I have no realtime experience and even getting up to speed on the current jargon would take me too long, so I just patch and compile. I am still wondering if problems are with the USB and networking and I have no idea what priority they would run at on the RT_PREEMPT kernel, or if xenomai would relieve USB and networking problems?

If you are interested in actually hacking the clocks used for realtime probably best to start here : www.raspberrypi.org/phpBB3/viewtopic.php?f=29&t=9882
then read the broadcom datasheets, I think getting the understanding required would probably take a long time if you currently know nothing about arm arch.

I started posting here on the linuxcnc forum as I was sort of working on the drivers for rpi hal i2c, I get the feeling if major work needs doing to the rpi realtime kernel then the best place to post would be on the rpi forum. I always seem to end up making many slightly offtopic posts, though its all generally about getting rpi linuxcnc running I maybe should have started a new thread here titled i2c drivers for rpi???

I am still sort of hoping that some minor config changes may improve RT_PREEMPT performance, and I was checking some things before my SD card crashed and realised the quotes of latency-test I posted were wrong, there was an extra zero added to the servo thread figure ( should have been 3% latency not 30%), would be nice if could copy and paste stats from the latency-test window.....

linuxcnc is definitly runable with RT_PREEMPT but I think there are occasional glitches where the latency is vastly higher e.g. if you reset the stats in latency test the figures will seem very good for maybe 10-20 seconds then shoot up higher. There maybe some weird no maskable interupts happening from the GPU or somewhere in hardware that cannot be switched off (most of what i say is stupid speculation without knowledge)??????

I will hopefully post another tarball with the compile script a little more fully tested so people can actually try running the RT_PREEMPT kernel and linuxcnc on the rpi and give some feedback, probably after next weekend.

I added some timings for xenomai and summarized it here: linuxcnc.mah.priv.at/rpi/rpi-rtperf.html

- Michael

mhaberler wrote:

I added some timings for xenomai and summarized it here: linuxcnc.mah.priv.at/rpi/rpi-rtperf.html

- Michael

I just looked at your link page and by the looks of things you are not using an RT_PREEMPT patched kernel, PREEMPT is not the same as RT_PREEMPT, did you actually compile the kernel yourself with the rt patch did you enable full RT preemption in the .config file???

If you patch the kernel correctly it should boot and identify showing something like ' Linux raspberrypi 3.2.27-rt40 #102 RT_PREEMPT Sat Sep 1 01:00:50 BST 2012 armv6l GNU/Linux.'

I noticed quite a lot of difference between the PREEMPT and RT_PREEMPT kernels running on the rpi.

Next thing I should say is that I recently saw figures that suggested RT_PREEMPT could have lower latency than xenomai (internet is great in that if you look long enough you can find totally opposite opinions).

I like that you are actually making some real measurements, though I am not certain that I can interpret them that well, it looks like the pulses will be +- 17us @ 20us or +-12us@ 30us.
This seems strange to me as I would have assumed a pulse should never be early unless scheduling looks ahead for timing (of course this is probably just due to my knowing nothing about scheduling and RTOS).

Anyways is anyone actually working on porting the linuxcnc rtapi wrapper to xenomai, I have really done very little actual coding to change linuxcnc, most of what I have done is minor hacks to get things to compile, getting xenomai in the rtapi could be quite a long job.

I have as previously said looked at my tarball scripts and seen that virtually nothing compiles correctly if downloaded from the original sources, I think the next tarball release will have to distribute all source as I really cannot remember what changes I made to get things to compile. I also found that there were also more changes that needed to be made to the linuxcnc source that I forgot to add. I probably should make a diff patch but I think this also could lead to confusion, so I will probably release everything needed in the next version so that it will definitely compile, unfortunately this will mean maybe 200Mb to download.

mungkie wrote:

mhaberler wrote:

I added some timings for xenomai and summarized it here: linuxcnc.mah.priv.at/rpi/rpi-rtperf.html

- Michael

I just looked at your link page and by the looks of things you are not using an RT_PREEMPT patched kernel, PREEMPT is not the same as RT_PREEMPT, did you actually compile the kernel yourself with the rt patch did you enable full RT preemption in the .config file???
...

This is why I have added the kernel config file here: git.mah.priv.at/gitweb/raspberry-test.gi...:/proc_config_gz.txt

mungkie wrote:

Anyways is anyone actually working on porting the linuxcnc rtapi wrapper to xenomai, I have really done very little actual coding to change linuxcnc, most of what I have done is minor hacks to get things to compile, getting xenomai in the rtapi could be quite a long job.
...

It is unlikely to get a lot of response on that question in this forum. Subscribe to the emc-developers mailing list, and the linuxcnc-devel IRC channel.

See for instance: comments.gmane.org/gmane.linux.distributions.emc.devel/7664


- Michael

Well seems like a long long time since I posted, and last time I did I said I would post a new guaranteed working tarball.

Unfortunately I have had major internet problems as the phone company has spent two weeks telling me my phone will be reconnected, then another week waiting for broadband to work again (which it still does not).

All the net problems made it impossible to do any work on linuxcnc for rpi as I could not access information needed, and the whole mess made me feel its not worthwhile bothering anyways as there are other things on the rpi that need fixing first.

Before the net problems I started work on atmega code for interfacing pwm/adc/digital IOwith linuxcnc via hal, and also was going to rewrite the stepgen code so that is directly sent output to rpi hardware (to reduce the number of addf calls in linuxcnc to cut RT load). Also wrote a direct linuxcnc driver for rpi digital gpio. Unfortunately all of it stalled for want of information from the web, and I have moved on to other projects now due to internet disconnection.

I am now accessing the net via dialup speed so there is no way I am going to try uploading the 250Mb tarball of kernel/linuxcnc source code.

I normally try to upload stuff as quick as possible so others can fix my buggy crappy hacks, but I decided I am not going to bother until I have finished other things I am doing as I feel the infrastructure on rpi is not upto requirements yet, and I would like to try and get the new drivers debuggered.

I think maybe christmas could see wayland/weston compositing accelerated X and possibly even hardware accelerated python openGL which should cut load on the rpi ARM core?

I am not going to bother trying to release the tarball until I have polished some of the new drivers I started and I am not going to do that until I finish the other projects I moved onto.

Hi mungkie,

I'd be very interested your rpi_cnc archive
however, rpi_cnc/tree is missing vital parts, like Submakefile mods, flags etc

could you post a more complete archive, maybe with a build README?

thanks in advance,

- Michael

mungkie wrote:

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

it just occurred to me that I mixed up PREEMPT and RT_PREEMPT.

You're right, those are PREEMPT (stock kernel) figures

- Michael