Can we port latmon from zephyr to xenomai 3.2 for measuring gpio latency.

Can we port latmon from zephyr to xenomai 3.2 for measuring gpio latency.

[Chen, Hongzhan]

Hi Philippe

I have tried different ways and different X86 boards to co-work with FRDM K64F to get correct GPIO latency
for latmus test but failed because of voltage mismatch( 1.8V <-> 3.3V) or bad signal  of gpio connection between X86 boards 
and FRDM K64F triggering lots of invalid gpio interrupts after run.

Can we port latmon from zephyr to xenomai so that we can set up latmus and latmon on same type of board
which both run xenomai to measure gpio latency to avoid voltage mismatch or bad signal caused by platform 
difference?  It would also provide more options for user to setup latmon to measure gpio latency.  How do you think?

Regards

Hongzhan Chen

Re: Can we port latmon from zephyr to xenomai 3.2 for measuring gpio latency.

[Philippe Gerum]

Hi Hongzhan,

Chen, Hongzhan <hongzhan.chen@intel.com> writes:

> Hi Philippe
>
> I have tried different ways and different X86 boards to co-work with FRDM K64F to get correct GPIO latency
> for latmus test but failed because of voltage mismatch( 1.8V <-> 3.3V) or bad signal  of gpio connection between X86 boards 
> and FRDM K64F triggering lots of invalid gpio interrupts after run.
>

Yeah, too bad the PI-X designers did not stick with the pretty common
3.3 voltage. Any ARM-based PI can give us 3.3V on the GPIO pins
AFAICS. But I guess this might not be on the table, right?

> Can we port latmon from zephyr to xenomai so that we can set up latmus and latmon on same type of board
> which both run xenomai to measure gpio latency to avoid voltage mismatch or bad signal caused by platform 
> difference?  It would also provide more options for user to setup latmon to measure gpio latency.  How do you think?
>

Benchmarking Xenomai with Xenomai might raise some validity concerns in
theory, hence the reason for going for a distinct and fairly basic
Zephyr-based solution for monitoring latency.

Practically speaking, this could be done and should work for sure. In
this case, I would have the basic measurement code running in a RTDM
driver (e.g. extending the latmus driver?) so that no extra cost is
involved due to memory contexts switches, pushing the data to userland,
which would in turn collect it and deal with the TCP stream.

-- 
Philippe.