- 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.
