06.Aug.2019 Update - Timing-Tests Raspberry PI4 - Realtime Kernel

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.

05.Aug.2019 Update - Timing-Tests Raspberry PI4 - Realtime Kernel

10kHz stepper signal - not as bad as expected. But some deviations in timing....
The above spikes are the durations of the "low" and "high" parts oth the squarewave.
not even so bad.... but if zoom it:

27.07.2019 Update - Timing-Tests Raspberry PI4 - Realtime Kernel

Response time in nanoseconds: read GPIO input and set GPIO output.
System without load. Number auf measurements: ~25.000

Response time - number auf measurements: 330000

System without load - max. respond time: 544 nS

AVG respond time: ~100nS

Response time - number auf measurements: 330000

System with heavy load (make j8) - max. respond time: 574 nS

AVG respond time: ~100nS

26.07.2019 Update - Timing-Tests Raspberry PI4 - Realtime Kernel

While a local eth-raw is faster than expected (see last screenshot),
the connection with a real cable between 2 RPI4s slows down the
respond time down to 100-120usec.

Each sending and reading thread is running on a single RPI4 whith reealtime kernel (4.19.50-rt22-v7l+ #2 SMP PREEMPT RT)

26.07.2019 2nd Update - Response time less than one uSec.

A 5kHz square output on the first PI4 (channel I) is connected to
GPIO input of a second PI4.
One thread of the scond PI4 sets the output of its GPIO (channel II)
to the incomming signal.
(Both PI4s are running without further load at testtime)

21.07.2019 Timing-Tests Raspberry PI4 - Realtime Kernel

Toggle GPIO-pin every 50 microseconds. "getMicrotime();" is used:
(system is idle)

Same 50-usec. interval - Task ist bound to one single CPU with "taskset"
(while compiling kernel with "make -j3")

Endless toggle of a GPIO-port without any delay
(while compiling kernel with "make -j3")

24.07.2019 ethraw latency on a rapsberry PI4


Just a test run on the local eth device of the PI4.

Channel one is the output the GPIO output.
The falling edge of channel two is used to indicate, that an raweth-packet 
will be send now.
The 10usec duration of the channel two signal is necessary for the logic analyzer
to identify the trigegr-signal.
So from sending the raw-eth packet here it took only 20 usec. to set the corresponding
signal of the GPIO. The ususal respond time is longer - but alway less than 100usec. 
Further tests will follow.