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.
As decided in https://github.com/RIOT-OS/RIOT/issues/10413 when
netdev_driver_t::recv() is called with a too small buffer the incoming frame
should be dropped and `-ENOBUFS` returned. This commit makes cc2420 compliant.
First, every read function converts the void pointer into a const bmx055_t
Second, it is cleaner (more obvious) to pass phydat_t.val[3] instead of
type casting to int16_t* and relying that .val[3] is the first struct
member of phydat_t.
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.
A memset was used to clear two of the SAUL values in phydat_t::val
The change is to replace that by the following
res->val[1] = 0;
res->val[2] = 0;
which makes the code more obvious.
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.)
