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

hi all,

as I told some days ago, I'm trying to develop a rasPI-interface. details here:

forum.linuxcnc.org/27-driver-boards/3577...iver-hardware#123630

my further plan, to change the hal_partport.c in the following way:

if no physical parport exists, change the inb/outb-parts of the driver in that way, that the
in- and out-bytes are stored in an share-memory-region.
if so, it will be possible to access this bytes by another RT-thread, which does a
raw-ehter-communication with a rasPI and exchange there values with the rasIP GPIO.

latency-times less then 30usec. should be possible.

what are you thinking about this idea?
is this the right way? or is it i stupid idea because of...[insert reason here] ?

or it there a way to do this job in a simpler manner?

regards

wicki

andypugh wrote:

I think that it makes no sense to modify parport.c

This should be an entirely separate driver. The whole point of HAL is
that any signal can be connected to any hardware driver.

Of course, you are right.

But I've done so, because I was unable to create the whole
configure/makefile-overhead for an newly created driver.
Maybe, any reader in here is able to help me in that way?

The last documented state is here:

erste.de/rasPiCat.html

An update will follow later this day.

Yesterday I made the first tests on a 4-axis-mill (only 3 stepper actually connected).
It runs an a newly installed linuxmit 19.1 on an intel i5 with a vanilla kernel without
any realtime-patches.

"Linux Mint 19.1 Tessa"
4.15.0-43-generic #46-Ubuntu SMP Thu Dec 6 14:45:28 UTC 2018 x86_64 x86_64 x86_64 GNU/Linux

The rasPI runs with:
"Raspbian GNU/Linux 8 (jessie)"
Linux cerec 4.4.4-rt9-v7+ #7 SMP PREEMPT RT Mon Mar 7 14:53:11 UTC 2016 armv7l GNU/Linux

to be continued....

andypugh wrote:

You might be able to do it all in a .comp file.

This may be possible and may be a way to do it, if I got it completely working first....

But I have not found a way, to create working Makefile/Submake-file or even to compile
the files in the /example-direcotry.
So I modified the hal_parport a little bit and wrote 4 tasks/threads for reading/writing
an the PC- and on the rasPI-side.

The new version will consist of only one thread on each side.

not really amazing results....

PC-side
Linux debian 3.4-9-rtai-686-pae #1 SMP PREEMPT Debian 3.4.55-4linuxcnc i686 GNU/Linux
4 cores
model name : Intel(R) Atom(TM) CPU D525 @ 1.80GHz
bogomips : 3600.09

total used free shared buffers cached
Mem: 3350624 366124 2984500 0 63544 196052
-/+ buffers/cache: 106528 3244096
Swap: 0 0 0


Jobs:
pcIOethRaw send and receive-thread which send output of the virtual-parport
to, and receives input from the rasberry GPIO

pcTestloop sends bytes received from the raspberr GPIO-input Immediately
inverted to the raspberry GPIO-output





rasPI-side
Linux cerec 4.4.4-rt9-v7+ #7 SMP PREEMPT RT Mon Mar 7 14:53:11 UTC 2016 armv7l GNU/Linux
model name : ARMv7 Processor rev 4 (v7l)
BogoMIPS : 76.80


total used free shared buffers cached
Mem: 945164 325524 619640 14792 30788 158516
-/+ buffers/cache: 136220 808944
Swap: 102396 0 102396

Jobs:
rasPIioEthRaw send and receive-thread, which reads local GPIO-input ans sends it
Immediately to the receiving PC. packets _from_ the PC are directed
to the raspberry GPIO-out.





the result of the configuration describes above is a 2 kHz signal on the IO-Pin.
so it took about 125 usec. thats to slow....

the PC is able to send about 100k packets/second. the raspbbery is able to send
20k packets/second.

I think, it is not the best way, to do the linuxCNC/ethernet-task by polling
shared memory. Anyway: a RT-task is needed on both sides.

to be continued.....

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