GitLab

Stress load running in parallel to this test might be high enough to
have udelay() actually skipped by the EVL core since the sleep_until
(absolute) form is used internally, preventing evl_schedule() from
ever being called, which in turn skip the PP boost for the caller.
This has been observed on qemu-aarch64 under extreme load.

Increase the delay to 5ms.

Make it obvious that the call accepts an absolute timeout spec.

Follows new libevl behavior.

This is a simple way to figure out the protocol of a mutex without
crippling the API with trivial accessors people might need twice a
century.

Events timed on the monotonic clock is the most common form used by
applications. Allow people to write more compact code by providing
creation calls and static initializers aimed at building these
directly:

- evl_new_event(), EVL_EVENT_INITIALIZER() for events timed on the
  monotonic clock.

- evl_new_event_any() and EVL_EVENT_ANY_INITIALIZER() usable for
  specifying the clock.

In the wake of adding recursive mutexes and compact creation calls for
synchronization objects.

Zero-initialized semaphores timed on the monotonic clock is the
most common form used by applications. Allow people to write more
compact code by providing creation calls and static initializers aimed
at building these directly:

- evl_new_sem(), EVL_SEM_INITIALIZER() for zero-init semaphores
  timed on the monotonic clock.

- evl_new_sem_any() and EVL_SEM_ANY_INITIALIZER() usable for any
  initialization form, specifying the clock and init value.

Zero-initialized event groups timed on the monotonic clock is the
most common form used by applications. Allow people to write more
compact code by providing creation calls and static initializers aimed
at building these directly:

- evl_new_flags(), EVL_FLAGS_INITIALIZER() for zero-init event groups
  timed on the monotonic clock.

- evl_new_flags_any() and EVL_FLAGS_ANY_INITIALIZER() usable for any
  initialization form, specifying the clock and init value.

Normal (i.e. non-recursive) mutexes timed on the monotonic clock are
the most common form of locks used by applications. Allow people to
write more compact code by providing creation calls and static
initializers aimed at building these directly:

- evl_new_mutex(), EVL_MUTEX_INITIALIZER() for PI locks timed on the
  monotonic clock.

- evl_new_mutex_any() and EVL_MUTEX_ANY_INITIALIZER() for building any
  supported type of lock (normal/recursive), specifying the protocol
  (PI/PP) and the base clock.

The EVL shim library mimics the behavior of the original EVL API based
on plain POSIX calls from the native *libc, which does not require the
EVL core to be enabled in the host kernel. It is useful when the
real-time guarantees delivered by the EVL core are not required for
quick prototyping or debugging application code.

RWA (Remote-WAkeups) reports the number of times a thread was readied
and rescheduled from a remote CPU. Available with the -s display
format.

Jorge Ramirez-Ortiz authored Jun 02, 2019 and Philippe Gerum committed Jul 23, 2019

This Linux-side tool is designed to echo the GPIO signals issued from
a remote board, which in turn measures the response time. The code has
been validated using a Linux-based rpi3b running gpio-echo, and a
Zephyr-based FRDMk64f board measuring the response time.

The current version of the Zephyr code is available in the zephyr/
subdirectory in patch format. This code is maintained at:
https://github.com/ldts/zephyr.git

, branch evl-latency

For instance, GPIO23 can be used to receive test signals on rpi3b and
GPIO24 to respond to them.

gpio-echo is realtime capable (via EVL) or non-realtime capable
(standard Linux behaviour) - it depends on how you run it.

$ gpio-echo -n gpiochip0 -o 23 -t 24 -O -T -f

Once that process is started (and the necessary cabling is done) start
this Zephyr program, get the console and follow the instructions.

Connections:
-------------
 Zephyr - FRDMk64F:                Linux - rpi3b
  PIN 20 (PTE-24) ----------------  PIN 16 (GPIO 23)
  PIN 18 (PTE-25) ----------------  PIN 18 (GPIO 24)
Signed-off-by: Jorge Ramirez-Ortiz <jro@xenomai.org>