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.
Converting phydat_t* to lsm6dsl_3d_data_t* is not correct, but it happened
to just work because the first struct member of phydat_t will be used.
Furthermore, casting &res[0] to int16_t* is wrong. Again, it just happened
to work.
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.
This commit returns accurate error codes and prevents improper i2c states.
If since i2c_read_reg and i2c_write_reg are full frames the I2C_NOSTOP/START commands should not be supported
With ace5db70e858b8c114580e8b4f65a3994ee3c4e7 the IID may be gotten from
the device again. However, following the current refactoring efforts
regarding the `netdev_ieee802154` layer, the devices don't necessarily
store the address in the `netdev_ieee802154_t` struct anymore. So we
need to access the address using the driver's `get` function here
instead.
This write access is only required when a modification to the PAN ID
happened directly via this function and not via a netdev::set operation.
The only direct call was done in the reset function of the driver
This write access is only required when a modification to the PAN ID
happened directly via this function and not via a netdev::set operation.
The only direct call was done in the reset function of the driver
This write access is only required when a modification to the PAN ID
happened directly via this function and not via a netdev::set operation.
The only direct call was done in the reset function of the driver
This write access is only required when a modification to the PAN ID
happened directly via this function and not via a netdev::set operation.
The only direct call was done in the reset function of the driver
