[PATCH 0/2]GPIO Loopback Benchmark Tool

chensong 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
>>> interrupt,
>>> 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
> event?
>
> In the patch1/2, i think switching read and write can make it work, like:
>
> while(){
>       read_gpio()
>       //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.
>>
>> Jan
>>
>
>
>
>





More information about the Xenomai mailing list