The dependency conditional for RPL was at the very end of
`Makefile.dep`, giving depending modules no chance to pull in their
dependencies.
Also it pulled in the deprecated module `net_help`, though it did not
use any of it's functions (it just included `inet_pton.h` for `AF_INET6`).
Honeywell HumidIcon Digital Humidity/Temperature Sensors: HIH-6130/6131 Series
Only basic humidity and temperature measurement support is implemented.
Missing:
- Alarm interrupts
- Command mode (reconfigure i2c address, alarm levels, alarm polarity, custom ID)
These headers do not provide full stl functionality,
but a small subset:
* thread and this_thread
* condition_variable (some timed functions are missing)
* mutex, lock_guard and unique_lock
This PR proposes an approach to reduce the thread count of RPL.
The current RPL/Trickle stack needs about 5 threads to handle tasks
like updating the trickle timer, routing entries and the transmission of
DAOs.
This PR modifies RPL to use only one thread with a looped `msg_recv()` call.
The message is then multiplexed to the right task.
This PR depends on #1766.
It contains a minimal implementation of the AODVv2 routing protocol.
*Not* implemented are:
- AckReqs
- alternate metrics
- multiple interfaces
- clients and Client Networks
- buffering
- all addresses, TLVs, and features that are marked as optional
An example application can be found at https://github.com/Lotterleben/RIOT-AODVv2/tree/master/aodvv2_demo.
The implementation relies heavily on a functioning Neighbor Discovery Protocol.
It might be necessary to fill the neighbor cache manually with the current state
of RIOTs NDP implementation.
The value of AODVV2_MAX_UNREACHABLE_NODES has been chosen arbitrarily and will be subject to
future improvement.
Please note that based on my experience, with the default transceiver
buffer size (3) of the native port, about 2/3 of the route discoveries
will fail. This has been addressed in issue #1747. It is advised to increase
the transceiver buffer size when using AODVv2 as a routing protocol.
Please see #1715.
Closes#1715.
This PR implements the new Makefile variables "FEATURES_PROVIDED" and
"FEATURES_REQUIRED". A board *can* have a new file `Makefile.features`
which looks like:
```make
FEATURES_PROVIDED = transceiver
```
An application can have a corresponding line
```make
FEATURES_REQUIRED = transceiver
```
If the selected BOARD does not fulfil the requirements of the
application, then a *warning* is issued at compile time.
This change only includes the feature "transceiver", further features
are expected to be listed in further PRs. The requirement "transceiver"
is automatically added if the application uses the module
"defaulttransceiver".
`make buildtest` understands the new feature listing, so the user won't
need to add boards to `BOARD_BLACKLIST` manually.
Part of the change are the added Make targets
* `info-features-missing`, which prints the required features
`\setminus` the provided features. The output is empty if there are no
features missing.
* `info-boards-features-missing`, the same as `info-features-missing`
but as a table for all boards, but heeded `BOARD_WHITELIST` and
`BOARD_BLACKLIST`.
Applications don't have to use this new feature. This change does not
break existing Makefile.
Currently, the tcp and udp implementations are bound to each other in a
module called *destiny*. Thus, when using only one of them then the
other one gets also compiled into the binary and initialized,
which results in unnecessary RAM usage and workload for the CPU.
The approach in this PR defines a common module named *socket_base*,
which contains functions used by the posix layer. Compiled by it's own,
those functions return negative error codes, to symbolize upper layers
that they are not supported. When also including the modules *udp* or
*tcp* respectively, functions from *socket_base* get overwritten with the
correct functionality.
Defining *udp* or *tcp* in a Makefile also includes *socket_base*.
Defining *pnet* in a Makefile also includes *socket_base*.
This is a malloc-free implementation of the Concise Binary Object
Representation (CBOR) data format for the RIOT-OS.
This implementation mostly stand-alone, and it should be pretty easy to
port to other platforms. We're only using the C STL and some custom
network-related functionaliy which could be easily replaced by depending
on arpa/inet.h.
The CBOR API is straight-forward to use and provides encoding/decoding
functionality for all major C types, such as:
- int
- uint64_t
- int64_t
- float
- double
- char*
- struct tm
- time_t
It is possible to conditionally compile this module via CFLAGS:
- CBOR_NO_SEMANTIC_TAGGING: All semantic-tagging features removed
- CBOR_NO_CTIME: All ctime related features removed
- CBOR_NO_FLOAT: All floating-point related features removed
- CBOR_NO_PRINT: All features depending on printf removed
Martine Lenders