connect raspberry via ehternet as IO-port - some developer help needed

andypugh wrote: Most LinuxCNC IO happens in a 1mS thread.
The exception is step-generation, and I would imagine that if your setup was generating steps on the Pi then you would be sending step-rate information rather than individual steps.

My plan is/was, to use the microstepping-generator of linuxcnc - without doing much
more on the rasPI, than the IO-pin handling.
If I need 3 motor-turns/cm in 16 micorsteps, I have to send 48 signals/cm.
With a latency of 1ms, a jog-speed of 20cm/second an with a latency of
100usec, 200cm/second should be possible.
appears as a lapse of thought.... but it seems to be right.

If so, it explains the reason why my machine is working yet

I will test it the next days.
But I still need some help in writing a configure/makefile to integrate the
driver into linuxCNC.

The rasPI-side is a standalone-thread - on the linuxCNC-side, I patched the hal_parport.c
and wrote also a standalone-thread for sharemem-exchange and raw-eth-communication.

It would be fine, to have single a hal-driver for both (simulate parport and raw-eth to rasPI)

wicki wrote: But I still need some help in writing a configure/makefile to integrate the
driver into linuxCNC.

Put it in the same folder as another driver, then copy the makefile entries for that other driver.

That is all I have ever done.

Have you tried compiling and installing it with halcompile?

andypugh wrote: Put it in the same folder as another driver, then copy the makefile entries for that other driver.
That is all I have ever done.
Have you tried compiling and installing it with halcompile?

I've tried so.... in several ways. But it does not work.

Do you mean the Makefile or the Submakefile?

I never used autogen, autoconf or configure in development.

But I think, if it should be re-distributable, it is necessary, to include it in
these scripts.

Halcompile I used serveral years ago - but I think it is not the right tool
for writing a driver. (maybe I'm wrong...)

wicki wrote: Halcompile I used serveral years ago - but I think it is not the right tool
for writing a driver. (maybe I'm wrong...)

oh, of course I'm wrong....
It seems to work with halcompile!

halcompile --compile hal_rasPI.c
Compiling realtime hal_rasPI.c
Linking hal_rasPI.so

then copy it to ../rtlib

I'll test it again.....

OK, modified parport-driver is working with halcompile.

But the next problem:
For the integration of the raw-sockets into the driver I need
raw-socket-access. But I can't find any rtai-functions for it.

And access by the standard-API results in "Operation not permitted"

any hints ?

Which realtime kernel are you using?
The Mesa card Ethernet drivers need to run with preempt-rt not rtai.

wicki wrote: If I need 3 motor-turns/cm in 16 micorsteps, I have to send 48 signals/cm.
With a latency of 1ms, a jog-speed of 20cm/second an with a latency of
100usec, 200cm/second should be possible.
appears as a lapse of thought.... but it seems to be right.

yes... it was a stupid lapse of thought.... a stupid one....
not 16 steps for 360 degree turn, 16 steps for 1.8 degrees!
so 3200 steps /turn --> 9600 steps/cm.

with 1ms latency it is incredible slow....
with 100usec its also slow....


at which speed are youre machines running?
(microstepping by parport?)

andypugh wrote: Which realtime kernel are you using?
The Mesa card Ethernet drivers need to run with preempt-rt not rtai.

I made tests with vanilla, preempt and rtai 3.5 and 5.1i.
last try with kernel 4.9.80-rtai does not start (crash at kernel-boot)

preempt or preempt-rt?

andypugh wrote: preempt or preempt-rt?

now this one:

Linux desktop 4.19.15-rt12 #1 SMP PREEMPT RT Tue Jan 22 23:20:37 CET 2019 x86_64 x86_64 x86_64 GNU/Linux