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.
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()
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
The DHT11/DHT21/DHT22 cannot be sampled more than once a second. Previously,
a global cache was added to the SAUL adaption of the dht driver to answer with
stored values for one second after the last read. This however had two
disadvantages:
- The global cache was shared for all DHTXX devices connected. As a result
incorrect values were delivered when reading out multiple sensors over SAUL
with less than 1 second delay in between
- A user of the low level API will had to implement the same caching strategy,
resulting in code duplication
By moving the hold logic to the driver, both limitations can be overcome.
Previously the DHT11/DHT21/DHT22 driver ended up in an infinite loop locking up
RIOT when a communication error occurred. This commit adds a simple timeout to
the communication in order to prevent these lock ups.
stm32eth: Move to stm32_common periph
cpu/stm32_periph_eth: Rebase to current master branch
- Update DMA to use new vendor headers
- Update send to use iolist. It looks like the packet headers are now transfered as seperate iolist entries which results in the eth periph sending each header as own packet. To fix this a rather ugly workaround is used where the whole iolist content is first copied to a static buffer. This will be fixed soon in another commit
- If MAC is set to zero use luid to generate one
- Small code style fixes
cpu/stm312f7: Add periph config for on-board ethernet
boards/nucleo-f767zi: Add config for on board ethernet
tests/stm32_eth_lwip: Remove board restriction
boards/common/nucleo: Add luid module if stm32 ethernet is used
tests/stm32_eth_gnrc: Add Testcase for gnrc using the stm32 eth periph
stm32_eth: Rework netdev driver layour
tests/stm32_eth_*: Use netdev driver header file for prototypes
stm32_eth: Add auto init for stm32 eth netdev driver
boards/stm32: Enable ethernet conf for nucleo boards
stm32_eth_auto_init: Add dont be pendantic flag
stm32_eth: Remove dma specific stuff from periph_cpu.h
Looks like this was implemented in PR #9171 and 021697ae94 with the same interface.
stm32_eth: Remove eth feature from stm32f4discovery boards
stm32_eth: Migrate to stm32 DMA API
stm32_eth: Add iolist to module deps
stm32_eth: Rework send function to use iolist
stm32_eth: Fix ci build warnings
stm32_eth: Fix bug introduced with iolist usage
stm32_eth: Remove redundant static buffer
stm32_eth: Fix feature dependencies
stm32_eth: Fix wrong header guard name
stm32_eth: Implement correct l2 netstats interface
stm32_eth: Rename public functions to stm32_eth_*
stm32_eth: Fix doccheck
stm32_eth: Move register DEFINE to appropriate header file
stm32_eth: remove untested configuration for f446ze boards
stm32_eth: Move periph configuration struct to stm32_common
stm32_eth: Fix naming of eth_phy_read and eth_phy_write
stm32_eth: Remove obsolete test applications
drivers/eth-phy: add generic Ethernet PHY iface
cpu/stm32f4: implement eth driver peripheral
This implements the ethernet (MAC) peripheral of the stm32f4 as a
netdev driver.
boards/stm32f4discovery: add eth configuration
boards/stm32f4discovery: add feature stm32_eth
tests/stm32_eth_lwip: add test application
in case of CME or CMS errors, the error codes or human readable strings
are in the response buffer. We want to indicate to the AT driver user
that when tihs case occurrs so he can extract the error codes.
`tsrb` changed to that type, so there is no reason for us, to keep the
internally used buffer as a `char` (especially since the rest of the
driver already uses `uint8_t`)
The MRF24J40MC/MD/ME modules contain an external power amplifier &
low noise amplifier that has to be enabled manually by setting three bits
in the TESTMODE register.
On MRF24J40MC the power amplifier is powered by a separate voltage regualtor
that has to be enabled by setting GPIO3 to HIGH.
During Sleep and CCA the PA should be disabled.
Co-authored-by: Carton <joel.carron@eeproperty.ch>
Co-authored-by: Benjamin Valentin <benjamin.valentin@ml-pa.com>
This driver is compliant with the candev interface. It has been tested
with STM32F0 and STM32F2 and STM32F413 ONLY at this time but should be
compliant with other STM32Fx devices
This commit adds usbdev, a common API to interface USB peripheral
devices. The API is split into two parts, one for the USB device itself
and one for the USB endpoint.
This driver API aims to control DC motors.
It handles :
* motor controller associated to a PWM device
* several motors by controller
* motor rotation direction
* brake capability
* enable/disable motor individually
Signed-off-by: Gilles DOFFE <g.doffe@gmail.com>
Change description to reflect the configurability of the serial
interface.
Also, fix the uart_mode parameter description as the UART will be
configured and not initialized.
Signed-off-by: Yegor Yefremov <yegorslists@googlemail.com>
As suggested in PR#5899 add a routine uart_mode() that will
setup data bits, stop bits and parity at runtime.
uart.h provides a set of enums defining these settings and each
platform will override them to specify values corresponding to
its configuration registers.
The idea behind the enums is to specify default settings i.e. 8N1
through the 0 value item. Invoking uart_mode(uart, 0, 0, 0) will
setup 8N1 mode.
Signed-off-by: Yegor Yefremov <yegorslists@googlemail.com>
The LTC4150 is a coulomb counter (a.k.a. battery sensor or bidirectional
current sensor) that is used in the MSBA2 board and available for little money
as easy to use break out board.
in case there's an error uart_init() returns an error value,
this value indicates the reason for the error thus we should
return it from at_dev_init() so the user will be able to identify
whether the init succeded or failed.
This change makes it more clear that the dev is modified in some of the
read functions. Only pulse_counter_read_without_reset gets a const
pointer argument.
Also, use pulse_counter_t pointers instead of void pointers where
possible.
All DS18 functions have a dev argument. All except the init function use
it as an IN parameter, so we can prototype it as const ds18_t*.
As a consequence we can drop the cast in read_temperature() in ds18_saul.c
which was the primary trigger for the changes.
The commit also follows the preferred convention that "params" is a field
in the device struct. Only the init function needs to write it.
This follows the usual convention of having the whole params in the device
struct instead of a pointer-to. This also eliminates the need to cast a
const to a non-const pointer in the init function.
Some drivers return on netdev_driver_t::recv() not the actual frame size, but
an upper bound estimation of it. The upper layer code is already prepared to
handle that. This brings the doc in sync with the code.
Clarified in the documentation how netdev_driver_t::recv() should behave in case
the size of the buffer in parameter buf (indicated by parameter len) is to small
to fit the received frame.
netdev_driver_t::recv does on of three things:
- Receive the frame
- Drop it
- Get (an estimation of) the size of the frame
The brief section of the documentation was changed to reflect this. (And it
starts with the least obvious thing in the hope readers of the API stumble upon
it...)
Removed the invalid precondition in netdev_driver_t::recv that the buffer never
NULL and the length positive. (In the "get message size" case both is wrong, in
the drop message case the first part is wrong.)
The write_reg/s states a repeated start write is used but that is not how the i2c is implemeneted.
Most devices also only use a continuous write so the API should be changed to match implementation and the majority of sensors.
