EMC2 running on Raspberry Pi?

mungkie wrote: Which git branch should I grab?

Probably unified-build-candidate-3

What is happening with the universal RTOS thing?

That's what ubc3 is. It ought to be as simple as ./configure --with-platform=raspberry. I can't guarantee that it is.

How should I post my dma based stepgen driver?

What format is it in? Is it a standalone C-file that could live in src/hal/drivers? Some makefile-fu might be needed in order to have it only compile on RPi.

andypugh wrote:

How should I post my dma based stepgen driver?

What format is it in? Is it a standalone C-file that could live in src/hal/drivers? Some makefile-fu might be needed in order to have it only compile on RPi.

The driver I found on my old dev vm is almost identical to the code in this linuxcnc.org/index.php/english/forum/18-...y-pi?start=140#32939 post.

There were only very minor changes to the output code but I added a few functions to start experimenting with dma based gpio reads (not even tested or debugged just outline code).

I am sort of going back to getting a decent RT kernel compiled(which is not going well), as I think that needs to be fixed before I start looking at the driver code.

As said above I am trying to get a decent RT kernel compiled, I started again on the rpi linuxcnc as I has hoped the kernel infrastructure would be more mature work better and be simpler to patch with xenomai and RT_PREEMPT for the 3.6 or 3.8 kernels.

Unfortunatley this does not seem the case, I have done some tests with 3.8 patched with xenomai and RT_PREEMPT and they seem to have appaling RT performance. I then thought maybe I should checkout kinsas git repo of rpi xenomai patched kernel and that would not even boot to a login prompt.

The compiled kernel cyclictest results for 3.8 xen/RTPREMPT were and order of magnitude worse that the cyclictest results from the 3.2.27 RT_PREEMPT on the released image. I think the fiq code may have caused this?

I am not really a kernel hacker so I don't know enough to be productive in trying to fix anything.

So I am wondering where to head next, I will probably leave things for a while to see what happens, but maybe will go back to the 3.2.27 branch that is on the image I released and look at how to get the VC vchiq interface working.

The 3.2.27 kernel on the image I released before had quite a few problems such as inability to run VC code (problems with the firmware interface?) and the networking caused problems sometimes(that is why networking was disabled when linuxcnc is run). I Was hoping leaving things to mature would make it possible to come back and start with a newer more stable system, but I probably need to actually hack the kernel myself which is not something I am confident with (just understanding the codebase would take many more hours than I have available in free time).

I will keep looking at things, as something may and probably will improve soon.

mungkie wrote: As said above I am trying to get a decent RT kernel compiled,.

Have you seen: static.mah.priv.at/public/html/common/UnifiedBuild.html
and specifically section 7?

Hello to all,

  I'm new to the forum, I'm downloading the RPI-lcnc.img image and plan to mount a PICnc Jr Board to participate with you.

  I have a Raspberry controlling 4 stepper motors using ethernet (Delphi program and drivers direct on Raspberry), and has since I turned into an enthusiastic with CNCs.

  When I understand how this work works I would port it to Cubieboard (DDR3 1GB, 1GHz, 4GB).

This would motivate me to learn about Realtime Kernel and would be mode to exchange experiences with the group.

Best Regards

ADBensi wrote: I'm new to the forum, I'm downloading the RPI-lcnc.img image and plan to mount a PICnc Jr Board to participate with you.

Just by way of a warning, when I tried using the RPi step generator of real hardware I found that the pulse train wasn't very regular, and it didn't work very well.
I think that more development is needed.
LinuxCNC is known to work well on the Beagle Bone Black, and I am hoping to see if I can get it working on the Udoo board (which is an ARM PC, with an on-board Arduino.