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

one day later
=============
Are the limitations from the rasPI, from the PC of from the linux-RTs?

I made further tests:
The first image shows a RT-thread of the raspberry. It toggles one GPIO-pin permanently.
The averag cycle time is 10usec. But more than 20usec are also possible.
Output frequency is about 45 kHz.

The second image is the same c-loop. But as an endless loop inside the thread.
The output frequency is 3.7 MHz(!). But the output is not really a square wave any more...


erste.de/rasPiCat.html

Next question:
What will the output of a local HAL-thread with a toggle-loop look like?
On the PC and on a rasPI.

to be continued.....

loopback-HAL-script

halcmd:
loadrt threads name1=fast period1=5000 name2=slow period2=10000000
loadrt hal_parport cfg="0x378 out"
loadrt siggen
addf parport.0.write fast
addf siggen.0.update fast
addf parport.0.read fast
net a parport.0.pin-11-in-not => parport.0.pin-02-out
start

results on PC with
loadrt threads name1=fast period1=5000 name2=slow period2=10000000
(left image)

and
loadrt threads name1=fast period1=50000 name2=slow period2=10000000
(right image)

erste.de/loopback.HAL.PC.jpg

next test with the rasIP

lopback-HAL-script

about 5.7 kHz
loadrt threads name1=fast period1=40000 name2=slow period2=10000000
loadrt hal_gpio dir=4288672767 exclude=4088
loadrt not
addf not.0.funct fast
addf hal_gpio.read fast
addf hal_gpio.write fast

net dummy17 => hal_gpio.pin-03-out
net dummy17 <= not.0.out
net inv <= hal_gpio.pin-16-in
net inv => not.0.in
start

at period1 >40000 the system hangs.....

so, is a latency of a little bit below 100usec. enough?
I don't think so.
but I will check it again...


erste.de/loopback.HAL.rasPI.jpg

wicki wrote: so, is a latency of a little bit below 100usec. enough?

That would depend on the application. 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.

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?