Previously, the test vectors were encoded into the python test scripts,
converted to base64, and send over to the device under test via stdio.
The application sent back the output after converting it to base64
first, which was read back in by the test script and decoded. Finally,
the test script compared the result with the expected result.
This made the test complex, slow and, flanky, as stdio on interfaces
such as UART has a high bit error rate and some quirks (e.g. the EDBG
UART bridge e.g. in the samr21-xpro dropping bytes when bursts of more
than 64 bytes at a time are send).
This basically rewrites the test to embed the test vectors in the
firmware and do the comparison on the devices. This fixes test failures
on the samr21-xpro, the nRF52840-DK and likely many others. Also, it
is now fast.
It turns out that the fix for the missing terminating newline is not
robust. This hopefully fixes the issue and resolves the following
error message:
In file included from /home/maribu/Repos/software/RIOT/tests/pkg_emlearn/main.c:25:
/home/maribu/Repos/software/RIOT/tests/pkg_emlearn/model.h:7221:36: error: stray '\' in program
7221 | /* fix for no newline at eof */\n
| ^
/home/maribu/Repos/software/RIOT/tests/pkg_emlearn/model.h:7221:38: error: expected ';' before '_Alignas'
7221 | /* fix for no newline at eof */\n
| ^
| ;
The test (at least locally) fails on the long shell line detection in
`master`, as the EDBG UART adapter drops chars when more than 64 bytes
are send at a time. This works around the issue:
- The line buffer in the test is reduced to 60 bytes, so that
overflowing it becomes possible with sending less than 64 bytes.
- The test script is adapted to exceed the shell buffer size by one
byte only (due to linefeed char), rather than significantly.
- Sending more than 64 bytes would result in the linefeed being
dropped by the EDBG adapter and the test failing
Finally, the shell buffer is no longer allocated on the stack and,
hence, the main stack size could be reduced a bit. The test still
passes on the Nucleo-F767ZI which is notorious in failing on tight
stacks due to the MPU stack guard - so the stack size reduction is
expected to work for all boards.
Move some variables from stack to `.bss` / `.data` to avoid stack
overflows, which are detected by the MPU stack guard (e.g. on the
Nucleo-F767ZI that I used) and results in the test failing.
The `mpu_stack_guard` test intentionally overflows the stack with a
stupid infinite recursion. Newer versions of GCC started to dislike
this, so this disables the corresponding diagnostics to get the
intentional stack overflow still compiled.
`coap_build_reply()` may return negative values on error or
0 in the no-response case.
Don't use it to calculate a payload offset without checking first.
This allows including C headers from C++. It sadly reduced the
diagnostics on C++ code as well, were there warning may make sense as
unintended side effect. We may be able to drop that later on, when more
C APIs are properly wrapped in native C++ APIs, so that C headers do no
longer need to be compatible with C++ compilers.
