The test application provides:
- RIOT's basic network utilities such as `ping6`
- A custom `cc110x` shell command that can be used print the low level device
and driver state. This is mostly useful for debugging.
- Removed cc110x driver
- Updated all makefiles
- Kept both board specific configurations and support for it in RIOT's
upper layers, so re-implementations don't need to start from zero
Python dictionaries are not guaranteed to be ordered until version
3.7. In 3.6 they are ordered too, but that is an implementation
detail. riotdocker seems to be using 3.5.
As it stands now, it would not be a problem if the test commands
are run in a random order, except that:
- It would result in non-reproduceable tests.
- It hinders testing other functionality, such as exiting the shell.
For test scripts, a terminal that does not modify the input and output
streams, configured without local echo, is preferred as it ensures the
test setup is introducing as little noise as possible.
Use test_utils_interactive_sync for synchronizing some case treat
the output before `reset` as the start of the test,
which fails for some boards/configurations.
Remove unconditionally setting 'BOARD' to an hardwritten value.
The definition must be moved before including 'Makefile.tests_common' as
it defines 'BOARD ?= native'.
Changes the test so that EVENT_QUEUE_INIT_DETACHED is used for the initialization of detached event queue. Without this change, a compilation problem was not recognized for ESP8266, MSP430 and MIPS.
Previously this was not tested and excepted KERNEL_PID_UNDEF == 0 as
legal value for received `gnrc_netif_hdr`s (which except for the
loopback interface is wrong)
The evtimer_msg test is expanded to also delete entries.
Furthermore the messages that are printed should now show
numbers that are very close (if not equal). Something like
this:
At 740 ms received msg 0: "#2 supposed to be 740"
At 1081 ms received msg 1: "#0 supposed to be 1081"
At 1581 ms received msg 2: "#1 supposed to be 1581"
At 4035 ms received msg 3: "#3 supposed to be 4035"
The function evtimer_print is also called to show the
intermediate status of evtimer entries.
The mips-malta board is a maintainance burden, has no working UART input
and is unobtainable and thus must be removed.
1. Unobtainable board
=====================
The mips-malta board is not an off-the-shelf part. A quick web
search only show the MIPS website where one is told to "contact sales".
I could find it on ebay, used, at €155 and from single seller.
Not having access to the board means:
a. We cannot maintain it. In fact it could be broken right now.
b. Potential RIOT uses have not access to the board either. In other
words, it is pointless to run on hardware nobody has.
2. No working UART input
========================
Not all applications need UART input, but that is no excuse for not supporting
it:
a. Makes development & debugging way harder.
b. It is impossible to run interactive tests.
b.1. Constrains the rest of the platforms by providing an incentive to not
make tests interactive.
c. The lack of UART is a witness to the poor quality of the port.
I want to stress point (c). If something as basic as a serial port cannot work,
how can we expect more complex fucntionality to work. The answer is impossible
to know, because of point (1).
3. Maintainance burden
======================
The RIOT project has limited time and human resources which can be better spent.
a. Compiling for mips-malta wastes CPU time.
b. Blacklisting the board in the test wastes contributor's time.
c. Adapting the board's makefile during build system rework takes time and makes
the reworks harder.
c.1. Add to that that the changes are most of the time not even tested on the board
because of (1). Look at the github issues/PRs and you will see it.
d. Developers usually stick to the lowest common denominator. Issue (2) sets this
denominator unacceptably low.
MIPS platform in general
========================
In commits I will address general issues in the MIPS platform and why it should all
be removed.
Adding saml1[01]-xpro, nucleo-f302r8|f334r8 to
BOARDS_INSUFFICIENT_MEMORY.
The riotboot build fails because it only offers half the flash size (per
slot), compared to before where the default build would not use riotboot
at all, thus have double the flash (but being useless).
... if the riotboot feature is used.
Previously, even an application that had "FEATURES_REQUIRED += riotboot"
set would still flash the non-riotboot binary on "make flash".
This is usualy not what the user wants.
This commit set's the FLASHFILE variable to the combined "riotboot
bootloader + slot0 + empty slot1" binary. This has the effect that make
all, flash and flash-only will compile and/or flash a working riotboot
setup.
tests/riotboot and tests/riotboot_flashwrite now default to flashing the
riotboot-extended binary. tests/riotboot was previously configured to
use the riotboot-combined binary. This has been changed in order to not
behave differently than how usual riotboot applications do.
When subscribing to IPv6 packets on a router for sniffing, the NETIF
header is released prematurely, because of a wrong
`gnrc_pktbuf_start_write()` call. This test aims to reproduce this
error case.
Summary for Users
=================
Deprecation is scheduled for 2020.01.
Users which depend on this module and cannot switch libraries may copy
the code into to their own application.
As expressed in PR #11724, the UBJSON module has issues which are not easy
or worth fixing.
Before removing the module, it should be marked as deprecated to give users
time to either migrate to another library, or copy the code to their own
private repo.
The deprecation warning has been supressed from the unit tests. This has the
ugly side-effect of supressing deprecation warning in other unit tests too,
but that should not last long, only until the module is finally deleted.
Blacklist native for the xtimer tests that have timing issues.
This also enables running the test on `nrf52dk` as I think it was
forgotten when adding the support.
New test function cmd_test_xtimer_mutex_lock_timeout_long_locked.
In this test the mutex is locked and the timeout is long.
When it works the thread continues running and stops waiting for the mutex and
the function will return that it did not get the mutex.
Adding a first normal test case where the mutex is unlocked and the timeout is long.
The timer will not trigger in this test and instead wil be removed after getting the mutex.
The test target is now defined in the common `Makefile.include`.
This removes the warning
Makefile: warning: overriding recipe for target 'test'
Makefile.include: warning: ignoring old recipe for target 'test'
The existing periph_uart test depends on having more than one UART.
This test allows for manual testing with the use of a probe
on-behalf-of: @sparkmeter <ben.postman@sparkmeter.io>
