xtimer_usleep wrong delay time

[leandrolanzieri]

Description

While doing some tests on #10011, which uses a 1-wire interface I found out that the xtimer_usleep is introducing an extra delay.

I did some measurements by toggling a GPIO. Here is the value passed to the function vs. the actual delay measured.

Board	1us	5us	10us	50us	100us
nucleo-f410rb	4us	8us	18us	58us	108us
nucleo-l152re	12us	16us	21us	73us	124us

I also confirmed that this is not a delay introduced by the toggle of the pin by adding multiple calls of the xtimer_usleep function and each of them would add this extra time.

Steps to reproduce the issue

Try toggling a GPIO pin and using the xtimer_usleep function to wait:

   while (1) {
        gpio_toggle((GPIO_PIN(PORT_A, 5)));
        xtimer_usleep(10);
    }

Expected results

Should see the pin toggled each 10us.

Actual results

Pin toggles each 21us (on nucleo-152re).

Versions

Installed compiler toolchains
native gcc: gcc (Ubuntu 7.3.0-27ubuntu1~18.04) 7.3.0
arm-none-eabi-gcc: arm-none-eabi-gcc (GNU Tools for Arm Embedded Processors 7-2017-q4-major) 7.2.1 20170904 (release) [ARM/embedded-7-branch revision 255204]
avr-gcc: missing
mips-mti-elf-gcc: missing
msp430-gcc: missing
riscv-none-embed-gcc: missing
clang: clang version 6.0.0-1ubuntu2 (tags/RELEASE_600/final)

Installed compiler libs
arm-none-eabi-newlib: "2.5.0"
mips-mti-elf-newlib: missing
riscv-none-embed-newlib: missing
avr-libc: missing (missing)

Installed development tools
cmake: cmake version 3.10.2
cppcheck: missing
doxygen: 1.8.13
flake8: missing
git: git version 2.17.1
coccinelle: missing

[Josar]

@leandrolanzieri
The problem is that as it is implemented right now there will always be an offset. As the timer has to match the target before it will be shot. So depending on the Platform there is an constant overhead.
Also for short times when XTIMER_BACKOFF criteria is met the offset varies.

This and other issues can be solve with #8990 (WIP, waiting for other PRs)
which also offers a calibration routine to get best parameters on each platform.

[stale]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. If you want me to ignore this issue, please mark it with the "State: don't stale" label. Thank you for your contributions.

[miri64]

Is this still an issue with #9530? Is this related to #8251 maybe?