- Changed declaration of SAUL classes (while keeping the format)
- Termed "class of SAUL classes" category of SAUL classes in the doc to
avoid confusion. (E.g. a SAUL class will now be in category sensor or
actuator.)
- Separate enums for SAUL category and intra-category ID. Numbers will now
but auto-assigned by the compiler
- Use constant look-up tables for stringification (one table per SAUL category).
==> This saves 512B in .data section of AVR
The binary shift operators in C are defined via the change of their values, not
the change of the memory representation of them. When reading a value from
little endian out of buffer `buf`, `((uint16_t)buf[1] << 8) | buf[0]` will
thus work regardless of the byte order of the host system.
- Use standard RIOT style `ina2xx_params_t` on initialization as explained in
[1] instead of a custom API
- Provided a default configuration via `ina2xx_params_t` as required by [1] that
works fine for the INA219 breakout board and with an optimal resolution that
still covers the whole range of USB high-power devices (500 mA @ 5V) with a
comfortable safe margin.
- Changed initialization procedure to include a device reset and connectivity
test, as required by [1]
- The calibration value is now calculated by the driver
- This simplifies using the driver a lot
- The user can still choose a trade-off between range and resolution that
matches the application requirements, but now among predefined values
- This allows the driver to easily convert the raw data into meaningful
physical data, as the resolution of the raw data is known
- All measurements are provided as meaningful physical data as required by [1]
[1]: https://github.com/RIOT-OS/RIOT/wiki/Guide:-Writing-a-device-driver-in-RIOT
The INA219 has the exact same interface as the INA220 (including values and
semantics of the configuration register). Thus, this driver can be used for
both. The ina220 has been renamed to ina2xx to reflect this and pseudo modules
for the ina220 and ina219 have been added.
Added driver for the WS2812/SK6812 RGB LEDs often sold as NeoPixels, which due
to their integrated RGB controller can be chained to arbitrary length and
controlled with a single GPIO.
This reverts commit cf01c743a8.
Adding an unexplained delay seemed wrong in the first place, but it fixed
the display on the MCB2388.
Turns out the display was erroneously operating in 8-bit mode due to the
uninitialized flag register.
Why the delay helped here I don't know.
But with #12634 fixing this, this hack is not needed anymore.
The driver can only be used with either 4 or 8 bit modes. Checking if the 5th pin is set in the configuration is enough the determine if 8bit mode should be used or not
The ATmega128RFA1 and ATmega256RFR2 contain a version of this IP
on the MCU.
The radio core behaves mostly like a at86rf231, but all registers
are mapped to memory and radio states can directly generate interrupts
on the CPU.
The ATmega256RFR2 adds support for automatic retransmissions.
This has not been implemented yet.
Co-authored-by: Josua Arndt <jarndt@ias.rwth-aachen.de>
During production it is often desirable for devices to perform
some kind of basic self-test to isolate defects.
For this it is necessary for the initialization not to hang if a
component is faulty / not connected.
This moves an already exising self-test that was previously enabled
as a debug option to an independent compile-time configurable.
It is necessary to call this in _init() before mrf24j40_hardware_reset()
as the reset function uses xtimer_usleep() which will cause another
thread to get scheduled.
If this thread (e.g. rpl or ipv6) then tries to access the netdev, RIOT
will crash.
When hooking up the mrf24j40 to a bluepill board, the driver would
always get stuck on init.
Debugging revealed that it would get stuck in the mrf24j40_reset_state_machine()
function because it expects the RFSTATE to have a special value after reset.
However, the data sheet does not mention this in section 3.1 Reset.
Waiting 192µs should be enough - the value of the RFSTATE is not specified.
The Linux driver also does not wait for the RFSTATE register.
And even without the loop, the driver is functioning fine.
Microchip offers ready-to-use modules with the mrf24j40 chip.
All but the MRF24J40MA integrate an external PA/LNA, they also come
with an RF shield.
If the PA/LNA is not enabled, the signal off these modules is really
poor.
This adds pseudomodules so that the PA/LNA is automatically enabled
when the appropriate module is used.
Change documentation on return codes in periph/timer API to
return 0 on success and (-1) on error by default.
For timer_init this was already the case, but for timer_set,
timer_set_absolute, and timer_clear this is now changed
from 1 to 0 for success, while error remains (-1).
This (re-)introduces the `CC110X_DEFAULT_CHANNEL` preprocessor macro to set the
default channel of the `cc110x` at compile time. The same macro has been used
in the previous version of the driver, so some users might still expect it to
work.
The Atlas Scientific pH OEM sensor is a small circuit to be embedded in
end products to measure the pH value with any commercially available pH
electrode
Rename TMP006 to TMP00x
Add TMP007 sensor support to TMP00X
Change uint8_t reg to uint16_t
Add to doxygen documentation group
Expose compile time configurations
Move defines from .c to .h
Change double to float, because double is not needed
Add TMP007 register information
i2c_release() should not have a return value, as:
- There is no reasonable error handling possible by the caller, so there is no
value in indicating success/failure via the return value to the caller
- There is no legitimate reason to fail *unless* an invalid I2C bus was released
or an I2C bus that was not previously acquired was released
--> This would indicate a bug in the code and should be tackled by an
assert()
- Added required logic to provide correct L2 netstats when the module
netstats_l2 is used.
- Refactored code to use gnrc_netif_hdr_set_netif() over manually setting the
pid to ease future refactoring.
The cc110x driver has been re-written from scratch to overcome the limitations
of the old driver. The main motivation of the rewrite was to achieve better
maintainability by a detailed documentation, reduce the complexity and the
overhead of the SPI communication with the device, and to allow to
simultaneously use transceivers with different configuration regarding the used
base band, the channel bandwidth, the modulation rate, and the channel map.
Features of this driver include:
- Support for the CC1100, CC1101, and the CC1100e sub-gigahertz transceivers.
- Detailed documentation of every aspect of this driver.
- An easy to use configuration API that allows setting the transceiver
configuration (modulation rate, channel bandwidth, base frequency) and the
channel map.
- Fast channel hopping by pre-calibration of the channels during device
configuration (so that no calibration is needed during hopping).
- Simplified SPI communication: Only during start-up the MCU has to wait
for the transceiver to be ready (for the power regulators and the crystal
to stabilize). The old driver did this for every SPI transfer, which
resulted in complex communication code. This driver will wait on start up
for the transceiver to power up and then use RIOT's SPI API like every other
driver. (Not only the data sheet states that this is fine, it also proved to
be reliable in practise.)
- Greatly reduced latency: The RTT on the old driver (@150 kbps data rate) was
about 16ms, the new driver (@250 kbps data rate) has as RTT of ~3ms
(depending on SPI clock and on CPU performance) (measured with ping6).
- Increased reliability: The preamble size and the sync word size have been
doubled compared to the old driver (preamble: 8 bytes instead of 4,
sync word: 4 byte instead of 2). The new values are the once recommended by
the data sheet for reliable communication.
- Basic diagnostic during driver initialization to detect common issues as
SPI communication issues and GDO pin configuration/wiring issues.
- TX power configuration with netdev_driver_t::set() API-integration
- Calls to netdev_driver_t::send() block until the transmission has completed
to ease the use of the API (implemented without busy waiting, so that the
MCU can enter lower power states or other threads can be executed).
- 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
