Raspberry Pi 4

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?