EMC2 running on Raspberry Pi?

Hi,
i played around with beagle bone Black like blog.machinekit.io/p/machinekit_16.html and github.com/modmaker/BeBoPr/wiki/BeBoPr-Bridge

So i think raspberry is not fast enough for my use cases. Question did someone get the UDOO in his hands ?
Because to have an Reprap board avail (pinout) would be great )
Then i would spend also some time to test it on my lathe and 3d mill and 3d printer

But i have to Finnish one project first so i can earliest start in 4 -6 weeks
thomas

ODROID-U3 do not have many GPIO / SPI, but, have I2C, however, it is possible make over USB SPI similary the Udoo (working over USB and Serial to the GPIO/SPI/I2C).

I do not like SPI over USB, but They have github.com/hardkernel/Odroid-USBIO

They have the RT Kernel ODROID:
github.com/hardkernel/linux/tree/odroid-3.8.y-rt

I liked the idea of ​​ODROID, it is less expensive and power-full.

To discuss it I thought it best to leave the topic dedicated to Raspberry and go for this.

Challenge ODROID-U3 - LinuxCNC
linuxcnc.org/index.php/english/forum/18-...e-odroid-u3-linuxcnc

What do you think? I am waiting for my ODROID-U3

I ordered a ODROID-U3, let's see what is quadrcore ... this have 3 GPIO interrupt (may be bitbang to SPI 2.4MHz) and I2C to drive one uC.

Unfortunately I am not going to start developing for another board, only for the reason that it take too much time to start learning everything from scratch again.

There are so many ARM boards becoming available I think the should be a new forum section for ARM boards with subsections for all the flavours, I don't understand why the beagle already has this but not the other boards?

I think almost all of the current ARM boards should run linuxcnc reasonably though it will depend on some optimizations and some limitations.

I think that the rpi can get almost perfect 20us step rate (no jitter whatsoever as its all done with pwm dma and precomputed steps at servo loop rate) using the DMA driver I have seen no realtime overruns, the only problem is with the UI latencys

Anyways I have been having a look at the new 3.14 kernel and while patching code and checking against my 3.12 code I notice that I have made a large pebkac as in the sdhci.c code in my last compile of 3.12 I have somehow got this code
somehow added the letter 'c' to the end if the compiler conditional?

Which means it was not properly patched in the last kernel I showed in the test video above, I may recompile 3.12 and test or I may test 3.14 first, either way probably be a couple of days before I know if there is any improvement.

I am guessing 3.14.159 will be the time when the kernel should all work together with linuxcnc in perfect harmony?

Hello Mung,
I have RPi on Class10 SD Card with Xenomai RT and PICncJr (with DMA) and none problem with SDHCI driver or buttons (I used F1 - stop many times rss) up,down, left, right. It runs smoothly but slow for some conversions tasks or opening files (low processing power, CPU high running Perl script to convert files, waiting many time).

But I had trouble with direct GPIO driver.

If the raspberry had sufficient performance to run the application would not think to re-invent the wheel. Use it requires patience and I'm getting old..

I have Cubieboard A10 on Nand with 3.4.12-xenomai #2 PREEMPT, in there the performance of LinuxCNC is acceptable, but I did not adjusted the SPI to work with PICncJr yet.

Both running Debian. I will install PREEMPT_RT in version 3.14 on Odroid-U3 Quadrcore on eMMC and report if the performance of LinuxCNC will be nice.

I understand what you say.
Best Regards.

The answer why BBB got may be because the ARM architecture between A8-BBB and A11(v6)-RPi.

For sample, the hardware timer in A9 (ODROID) is provided by the processor core, and not specific to the SOC.

Other read: lwn.net/images/conf/rtlws11/papers/proc/p11.pdf (see: 2 ARM designs and 5.2 Decision guide).

I have had a quick mess around with the 3.14 kernel this morning and tried some tuning and config of motors and hal and thought I would post another quick video, not sure what is shows, I hoped it may give some idea of what top/cyclictest and the lxde system histogram showed and show how linuxcnc runs with better tuned motor drivers and hal settings.



I changed out the motors on a couple of the A4988 driver boards to try and test max step speed, video should give some idea of voltages used and hardware that is running driven direct from the rpi GPIO.

I used a stop watch to get some idea of time that system locks up and the average over 4 lockups was 48seconds okay then 8 seconds unable to move mouse of keyboard input. Very strange timings being so long in duration, I am sure it was rather different on previous compilations of kernels, and am wondering if it is some sort of processor throttling due to thermal overheat?

I actually burnt out my model B which I assume is because I was running it force_turbo with dram@600 cpu@1100 and core@400(those maynot be the exact params cannot remember with certainty now). I am running on a model A now with cpu@1000 dram@500 and other params default and no force_turbo, maybe running the pi at defaults would not cause overheat and throttling, this is of course just a crazy guess, no real evidence to support it.

Also I found problems running DMA stepgen driver with shorter pulse time than 25us, so the test is running 25us step (base thread equivalent) and servo thread of 2000us. I found that for some reason I could not drive motors at more than 1500rpm (according to my rpm meter) this would be a pulse frequency of 5000 pps, 25us should allow 20000pps?

Don't know if hal inserts some default holdtime dir_setup delays if those params are not defined?

Anyways the whole thing seems weird and strange due to the long lockup of mouse yet cpu still seems to have cycles unused.

I am waiting for 3.14 kernel to compile with debugfs and some other RT profiling options enabled so cyclictest can give some profiling information from /sys/ (30 minutes compile time) I may get time to continue profiling and investigating but its not something I have done before so hope the learning curve is not too slow. I have other stuff to do today so may not do much more.

If anyone has any advice on realtime profiling or how linuxcnc prioritys can be changed or what they think may be the reason for the lockups please feel free to comment. I am no expert in this and am just muddling through without a full understanding to the huge mount of code that under lies the linuxcnc system. As said before it seems to me as though the step generation is very good, the problem is with the UI lockup, motor running seems very smooth and constant.