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.
cpu/stm32_common: cleanup periph eth
boards/nucleo-f767zi: cleanup dependencies
boards/nucleo-f767zi: fix dma configuration attribute for eth
examples/default: add nucleo-767zi in boards with netif
drivers/stm_32_eth: Add header guard for eth_config
Co-authored-By: Robin <robin@chilio.net>
This commit rewrites the example so that the registration loop is
run inside the main() function instead of running the standalone
submodule of epsim. It also adapts the example application to
parse the RD UDP endpoint locally and provide this to epsim's
register() function.
The build system contains several instances of
INCLUDES += -I$(RIOTBASE)/sys/posix/include
This is bypassing the module management system, by directly accesing
headers without depending on a module. The module is the posix module.
That line is also added when one of the posix_* modules is requested.
According to the docs, the posix module provides headers only, but in
reality there is also inet.c.
This patch:
- Moves `inet.c` into `posix_inet`, leaving `posix` as a headers-only
module.
- Rename `posix` as `posix_headers` to make it clear the module only
includes headers.
- Makes `posix_*` modules depend on `posix_headers`, thus removing the
explicit `INCLUDES+=...` in `sys/Makefile.include`.
- Ocurrences of `INCLUDES+=...` are replaced by an explicit dependency
on `posix_headers`.
Added arduino-nano to BOARD_INSUFFICIENT_MEMORY/BOARD_BLACKLIST following suit
of how arduino-uno is marked, as arduino-nano is mostly an Uno in a different
form factor.
This static function was a leftover from very early stages of this
example and at the current state there is not sense in keeping it.
Having these few lines directly where the advertising is triggered
makes the code more clean and readible.
Extend this application with 2 custom BLE characteristics. One is
read-only and returns a string including a random number and the
second one is writable. In addition, two characteristics for device
information were added (model and manufacturer). Access to the
characteristics produces output on the terminal.
