Raspberry Pi 4

When we get around to building a proper preempt_rt kernel for the pi4 the services you mask will be turned off as well as the cpu core freq be maxed out (as spma posted above).

All this should be done when properly building the preempt_rt kernel. Working on optimizing GPIO pulse generation before you have a good preempt_rt kernel is going to waste lots of effort.

What do you mean by proper preempt rt kernel?
Is that something else than the rpi-4.19.y-rt from github.com/raspberrypi/linux?

PCW wrote:

Thanks for posting that
Its nice that the RPI4s SPI hardware is compatible with the
RPI3's and only needs a different base address.

Have you tried mesaflash on the RPI4? I does work on the RPI3 though the
syntax is not obvious...

github.com/jethornton/mesaflash has some added SPI help text and
support for about 6 new boards including the RPI3/4 compatible 7C80/7C81

...slightly strange and light on error messages indeed... Yes it seems to work if I reboot with spi enabled. I did not try anything more advanced than a readhmid yet. Is this the latest official version?


/svante

They didn't do the best job of configuring the preempt_rt kernel posted there.

NTULINUX did the majority of the RTAI that works the past few years. He will likely post a better config for LinuxCNC use github.com/NTULINUX/RTAI

We just got our pi4 yesterday.

Hakan,

The link should be github.com/raspberrypi/linux/ rather than github.org.

Alan

Yes for now... it still needs some rototilling to get better pin descriptions
for cards with embedded interface hardware and better error reporting

Bari wrote:

They didn't do the best job of configuring the preempt_rt kernel posted there.
.

What is missing there really? It is the standard raspberry pi kernel with the RT PREEMPT patches applied, and the FULL PREEMPT tick box ticked. This is what we all have been using in these tests.

Is RTAI really the way forward for linuxcnc and Pi? At least with the code in the link you gave you wil have quite an uphill battle. It is only for amd64 architecture. Of course, if there are significant technical advantages (timing, latency) then things tend to be used. But this is way over my head really. Now when you got you RPi4 you can give it a spin and let us know how it works.

(Edited the github link in my previous post. Thanks acondit)

No, the link was just to tell you where he will be posting his preempt_rt code.

No we won't be porting RTAI to ARM anytime soon.

A properly configured preempt_rt kernel would include locking the governor to full speed and not including features in the kernel that will impact latency such as power management.

Some of this would also be locked into u-boot so that users can't mess with features that impact latency.

double-post deleted..

wicki wrote:

> wicki wrote: >
> now a period of 80.000 is possible.

> What is a possible, usable step-rate?

oh no.
a BASE_PERIOD down to 80000 is possible without getting a
"unexpeted rt-delay"-warning in linCNC is possible with my PI4.



> I'm not sure what you are measuring yet. Are you measuring all the duration of all the > intervals between pulse edges falling and rising, just rising or just falling or?

this are the durations of the high and the low periods of the square signal.
the high-periods is near exactly 80usec.
the low-periods are a mutliple of 80: 160, 240, 320.

that also sounds logical....

with a BASE_PERIOD of 80000 a square of 12500Hz is possible. (as a quad-signal)
but the next frequency below is 6250.
aus you see here:
getp stepgen.3.frequency
4000
and the output square is 4.1kHz

or 3.1kHz

I am still considering whether I can use an arduino for step/dir production.

as far as I now, the mesa-cards are generating their own stepper-signal?
does anyone know how the cards get their information?
do they receive data from stepgen or do they generate them themselves
from the position information?