The clock adjustment API only used a 16 bit integer for speed correction. This
is to course grained to allow compensating clock drifts at high accuracy.
Using a 32 bit integer instead would allow to fix for a drift of up to
about 1 nanosecond drift per each 5 seconds.
That ought to be enough for anyone! (*cough* *cough*)
This allows using the macro inside the periph_conf.h board files since the
periph/gpio.h header can't be included on the peripheral configuration.
Signed-off-by: Jean Pierre Dudey <me@jeandudey.tech>
Currently, when the prompt is read in `pyterm` the space after it is
ignored for the prompt and the output command just adds its own prompt.
This leads to the next output always having a leading space, see e.g.
this output from `tests/shell` using `RIOT_TERMINAL=pyterm`:
```
make: Entering directory '/home/mlenders/Repositories/RIOT-OS/RIOT2/tests/shell'
/home/mlenders/Repositories/RIOT-OS/RIOT2/dist/tools/pyterm/pyterm -p "/dev/ttyUSB1" -b "500000"
Twisted not available, please install it if you want to use pyterm's JSON capabilities
2021-02-09 14:47:15,071 # Connect to serial port /dev/ttyUSB1
Welcome to pyterm!
Type '/exit' to exit.
bufsize
2021-02-09 14:47:19,712 # bufsize
2021-02-09 14:47:19,712 # 128
> bufsize
2021-02-09 14:47:21,535 # bufsize
2021-02-09 14:47:21,536 # 128
>
```
While this isn't necessarily a problem in most cases, it becomes a
problem when the prompt is expected and the output of a command is
empty. In that case, the space is added to the empty output, making it
" ", so the prompt output command is never triggered and the prompt is
added to the next command in the log output. To demonstrate I added a
command `empty` to `tests/shell` that just does nothing and deactivated
the command echoing using `CFLAGS=-DCONFIG_SHELL_NO_ECHO=1`:
```
empty
> empty
empty
bufsize
2021-02-09 14:54:33,753 # > > 128
>
```
This fixes that problem by also reading the assumed space (we already
assume the prompt, so I don't see no harm in that) and if it is not a
space to skip the reading of the next char in the next iteration of the
reader loop.
The USB bootloader can take a while to be ready / Linux takes a while
to set up the interface.
1s is right at the edge, leading to races and often failed flashing.
Bump the delay to 2s for a wider safety margin, with this flashing is
a lot more reliable.
