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.
Changes include:
- Implementation of two power modes for the driver: low and high
- Redesign and API change to the description in tsl4531x.h
- Full documentation
- Changing file structure and implementation to fit best practices as
described in
https://github.com/RIOT-OS/RIOT/wiki/Guide%3A-Writing-a-device-driver-in-RIOT
- Including I2C addresses for the rest of the range
While reviewing #9942 I noticed that the documentation on the netdev
driver API is unclear and in some cases outright contradicting itself:
> ```
> @return number of bytes used from @p value
> @return `< 0` on error, 0 on success
> ```
IMHO this is unacceptable for such a central API where communication
This fixes a few things and also clarifies preconditions:
- Specifies negative `errno`s clearly so all drivers return the same
when required
- Re-iterates parameter preconditions and special cases within the
parameter documentation itself (might also help towards #9805?)
- Fixes contradictions within return value documentation
- Adds missing parameter documentation on `init()`.
- Add minimal usage instructions
- Ensure that the `bme_280_read_humidity` function (only available on
the BME280) is included in the documentation.
- Fix a typo
The flags from the ieee802154 struct are only used in the radio code.
there is no advantage of having them in the netdev_ieee802154_t struct
if the flags are defined differently per radio driver.
- Use RIOT's GPIO interface to access the sensor to increase portability
- Changed API to allow more than one sensor per board
- Added `sht1x_params.h` that specifies how the sensors is connected - each
board can overwrite default settings by #defining SHT1X_PARAM_CLK and
SHT1X_PARAM_DATA
- Changed arithmetic to use integer calculations only instead of floating point
arithmetic
- Added support for checking the CRC sum
- Allow optional skipping of the CRC check to speed up measuring
- Added support for advanced features like reducing the resolution and skipping
calibration to speed up measuring
- Allow specifying the supply voltage of sensor which heavily influences the
temperature result (and use that information to calculate the correct
temperature)
- Reset sensor on initialization to bring it in a well known state
- Support for the obscure heater feature. (Can be useful to check the
temperature sensor?)
- Updated old SHT11 shell commands to the new driver interface, thus allowing
more than one SHT10/11/15 sensor to be used
- Added new shell command to allow full configuration of all attached SHT1x
sensors
- Removed old command for setting the SHT11 temperature offset, as this feature
is implemented in the new configuration command
The sensor family SHT10, SHT11 and SHT15 only differ in their accuracy (as in
calibration, not as in resolution). Thus, the same driver can be used for all.
The new driver name better reflects this fact.
