[PATCH 0/2]GPIO Loopback Benchmark Tool
chensong at tj.kylinos.cn
Mon Jul 6 03:54:18 CEST 2020
On 2020年07月06日 09:35, chensong via Xenomai wrote:
> On 2020年07月03日 17:21, Jan Kiszka wrote:
>> On 03.07.20 08:37, chensong via Xenomai wrote:
>>> In general, we use cyclictest and latency to evaluate the determinism
>>> of our real
>>> time system. As we know, cyclictest and latency use hrtimer to set up
>>> a timer and
>>> calculate jitter by comparing expected wakeup time and real wakeup time.
>>> Besides that, we can also use GPIO to evaluate more modules in
>>> different scenarios.
>>> In this case, i apply 2 GPIO ports, one is set as output, the other is
>>> at the same time, connect them with a cable. Once an signal is sent
>>> from output pin,
>>> an interrupt will be raised in interrupt pin immediately.
>>> Timestamps are recorded before gpio_set_value and interrupt handler
>>> respectively, the
>>> diff between them is jitter.
>>> There is also an RT task running in the user space, which collects the
>>> information and
>>> output the summary at the end of the test. What's more, it also
>>> records the timestamps
>>> in user space, syscall overhead is included.
>>> Further, Making a little change will enable the tool working with
>>> latency box,once a
>>> signal from latency box is received in interrupt pin, the tool can
>>> send a signal at
>>> output pin as response. (I haven't got the latency box, so this
>>> function is not in
>>> place yet)
>>> chensong (2):
>>> demo/posix/cobalt: App of gpio loopback benchmark
>>> kernel/driver/testing: Driver of gpio loopback benchmark
>>> demo/posix/cobalt/Makefile.am | 6 +
>>> demo/posix/cobalt/gpioloop.c | 516
>>> kernel/drivers/testing/Kconfig | 7 +
>>> kernel/drivers/testing/Makefile | 3 +
>>> kernel/drivers/testing/gpiobench.c | 288 +++++++++++++++++++++
>>> 5 files changed, 820 insertions(+)
>>> create mode 100644 demo/posix/cobalt/gpioloop.c
>>> create mode 100644 kernel/drivers/testing/gpiobench.c
>> That is a valuable addition! We used to have such an interrupt benchmark
>> in Xenomai 2 times or so, using a null modem connection (UART signals).
>> GPIOs are more generic, though.
>> Two things I would recommend doing differently:
>> - use RTDM GPIO device (maybe adding missing RTDM GPIO driver for
>> your targets)
> gpiobench.c in patch2/2 is referring to gpio-core.c in
> kernel/driver/gpio, they use similar RTDM strcuts or APIs such as
> rtdm_driver, rtdm_dev_register.
> Could you please give me a sample of RTDM GPIO device? or what kind of
> RTDM GPIO driver did i miss?
> I've been very familiar with RTDM driver yet, so, a little more help is
> nedded, thanks.
correction: I've NOT been very familiar with RTDM driver yet,sorry
>> - build benchmark not via loopback but via cross-link
>> - device-under-test receives truly asynchronous event on GPIO input
> from a latency-box likely device ?
>> - reacts with flipping some GPIO output
>> - can run reaction either in interrupt handler or RT application
>> task, to cover more real scenarios
>> - latency box can also be a second device that triggers event and
>> measures reaction while having interrupts off (that's how things
>> worked in Xenomai 2)
> if i understand you correctly, via cross-link, you mean a latecy-box
> likely device is a must, it sends signal to device-under-test and
> device-under-test reacts with flipping GPIO output. is it asynchronous
> In the patch1/2, i think switching read and write can make it work, like:
> //once receiving event
> write_gpio() //as the reaction
>> The lookback scenario is too synchronous to catch realistic latencies.
>> It rather measures the performance of the event path.
More information about the Xenomai