Re: [riot-devel] Radio Driver Recommendations

[Kaspar Schleiser]

Hi Anthony,

On 02/22/2017 05:17 PM, Anthony Merlino wrote:
> I'm trying to understand a few things.  In the _setup command,
> how should I copy the default value struct into the overall params if
> the radio_params pointer member is const.  Should I use memcpy? Or
> should I create a new struct on the stack and initialize it with the
> correct pointer before copying it to the dev->params?

Usually the setup() function gets a state struct and the params as
parameters, e.g.,

device_setup(device_t *state_struct, const device_params_t *params);

Usually we double all fields that are needed after setup into the state
struct, or put a pointer in the state struct pointing to params.

(On some MCU's there's a small speed penalty for reading values from
flash. Depending on the device and how often a value is read, that's
tolarable.)

> Also, I'm trying to understand how to achieve your comment: "In the
> default case, all parameters end up in flash."

I meant that if the params struct and the "default advanced settings"
struct are const, they'd end up in flash, although it is still possible
to use runtime-generated versions (in RAM) and use them for initializing
the device.

Kaspar
___
devel mailing list
devel@riot-os.org
https://lists.riot-os.org/mailman/listinfo/devel

Re: [riot-devel] Radio Driver Recommendations

[Anthony Merlino]

Kaspar,

Thanks for this! Very clever to put a pointer to a second struct to keep the 
flexibility without forcing the user to know it.

I'm trying to understand a few things.  In the _setup command, how 
should I copy the default value struct into the overall params if the 
radio_params pointer member is const.  Should I use memcpy? Or should I create 
a new struct on the stack and initialize it with the correct pointer before 
copying it to the dev->params?

Also, I'm trying to understand how to achieve your comment: "In the default 
case, all parameters end up in flash."

Thanks Again!
-Anthony
[photo]
Anthony Merlino
CTO & Co-founder, Verge Aero
(609)-319-1399 [tel:(609)-319-1399]
On 2/20/2017 3:18:20 PM, Kaspar Schleiser  wrote:
Hi Anthony,

On 02/14/2017 03:56 PM, Anthony Merlino wrote:
> I am in the process of writing a radio driver for a device I'm working
> with. The device is highly configurable and I am trying to identify the
> best strategy for exposing some of the configuration to the user. For
> example, the data rate, channel, preamble length, etc. can be changed to
> configure the radio.
> 1. Put all configurable parameters in _params_t held in the
> device descriptor. I don't like this option since the user basically
> needs to worry about all of them even if they want to just use them as
> default. Plus it's more stored data that doesn't necessarily need to be
> stored.

Some parameters might make sense to have them runtime user configurable,
e.g., the channel used. Probably for most of them there's a netapi
option. If not, it might make sense to just add it.

IMHO, for everything that doesn't need to be changed much, e.g. general
radio parameters like preable length, should end up in _params_t.
The usual way here is to have the initialization function read that
struct as const parameter, so it can be put to flash (but doesn't have
to be).

If you'd like to seperate the device specific parameters (e.g., SPI,
gpi-pins) from the radio configuration, you can nest the parameter structs:

typedef struct {
spi_t spi;
...
const _radio_params_t *radio_params;
};

Then define a default set of radio_params_t with the most sensible
default values.

Make your initialization function use that default if the radio_params
field equals NULL.

That way, e.g. in the board config, it is possible to just do

const _params_t whatever = {
.spi = SPI;
};

Leaving out radio_params implicitly zeroes it.

This way you'll get sensible defaults, but a way to override them, even
at runtime. In the default case, all parameters end up in flash.

Kaspar
___
devel mailing list
devel@riot-os.org
https://lists.riot-os.org/mailman/listinfo/devel
___
devel mailing list
devel@riot-os.org
https://lists.riot-os.org/mailman/listinfo/devel

Re: [riot-devel] Radio Driver Recommendations

[Kaspar Schleiser]

Hi Anthony,

On 02/14/2017 03:56 PM, Anthony Merlino wrote:
> I am in the process of writing a radio driver for a device I'm working
> with.  The device is highly configurable and I am trying to identify the
> best strategy for exposing some of the configuration to the user.  For
> example, the data rate, channel, preamble length, etc. can be changed to
> configure the radio.
> 1. Put all configurable parameters in _params_t held in the
> device descriptor.  I don't like this option since the user basically
> needs to worry about all of them even if they want to just use them as
> default. Plus it's more stored data that doesn't necessarily need to be
> stored.

Some parameters might make sense to have them runtime user configurable,
e.g., the channel used. Probably for most of them there's a netapi
option. If not, it might make sense to just add it.

IMHO, for everything that doesn't need to be changed much, e.g. general
radio parameters like preable length, should end up in _params_t.
The usual way here is to have the initialization function read that
struct as const parameter, so it can be put to flash (but doesn't have
to be).

If you'd like to seperate the device specific parameters (e.g., SPI,
gpi-pins) from the radio configuration, you can nest the parameter structs:

typedef struct {
spi_t spi;
...
const _radio_params_t *radio_params;
};

Then define a default set of radio_params_t with the most sensible
default values.

Make your initialization function use that default if the radio_params
field equals NULL.

That way, e.g. in the board config, it is possible to just do

const _params_t whatever = {
.spi = SPI;
};

Leaving out radio_params implicitly zeroes it.

This way you'll get sensible defaults, but a way to override them, even
at runtime. In the default case, all parameters end up in flash.

Kaspar
___
devel mailing list
devel@riot-os.org
https://lists.riot-os.org/mailman/listinfo/devel

Re: [riot-devel] Radio Driver Recommendations

[Anthony Merlino]

Just another idea here:

4. At the end of the netdev init method inside the radio driver, have a single 
_user_config function that has a weak default implementation internally 
(which does nothing).  This way, the user can override that function and 
configure any additional settings after the device is in a known state.

Best,
Anthony

[photo]
Anthony Merlino
CTO & Co-founder, Verge Aero
(609)-319-1399 [tel:(609)-319-1399]
On 2/14/2017 9:56:34 AM, Anthony Merlino  wrote:
Hello,

I am in the process of writing a radio driver for a device I'm working with.  
The device is highly configurable and I am trying to identify the best strategy 
for exposing some of the configuration to the user.  For example, the data 
rate, channel, preamble length, etc. can be changed to configure the radio.  I 
understand that the netapi has some parameters that can be set through the 
interface, but I have quite a few parameters that don't fit into the netapi 
framework that I'll need to change.  Here are the 3 proposed methods that I 
believe will expose the configuration to the user, I am wondering which you 
guys think is best.

1. Put all configurable parameters in _params_t held in the device 
descriptor.  I don't like this option since the user basically needs to worry 
about all of them even if they want to just use them as default. Plus it's more 
stored data that doesn't necessarily need to be stored.
2. Internally, have a bunch of default __attribute__((weak)) functions that can 
be overriden by different areas of the code.  This way if someone wants a 
particular data rate tied to a board, the board can have the override. Or if 
the application wants to override it, it can.
3. Simply setup the radio in what I believe to be the most useful default 
configuration.  Then the application is responsible for configuring the radio 
further AFTER the radio is configured.  The radio module would be responsible 
for providing hooks to configure different aspects.  One thing I'm not sure of 
here is to know when the network stack has finished initializing the radio so 
it can begin it's configuration.

Any suggestions or guidance on this matter is appreciated!

Sincerely,
Anthony
___ devel mailing list 
devel@riot-os.org https://lists.riot-os.org/mailman/listinfo/devel___
devel mailing list
devel@riot-os.org
https://lists.riot-os.org/mailman/listinfo/devel

[riot-devel] Radio Driver Recommendations

[Anthony Merlino]

Hello,

I am in the process of writing a radio driver for a device I'm working with.  
The device is highly configurable and I am trying to identify the best strategy 
for exposing some of the configuration to the user.  For example, the data 
rate, channel, preamble length, etc. can be changed to configure the radio.  I 
understand that the netapi has some parameters that can be set through the 
interface, but I have quite a few parameters that don't fit into the netapi 
framework that I'll need to change.  Here are the 3 proposed methods that I 
believe will expose the configuration to the user, I am wondering which you 
guys think is best.

1. Put all configurable parameters in _params_t held in the device 
descriptor.  I don't like this option since the user basically needs to worry 
about all of them even if they want to just use them as default. Plus it's more 
stored data that doesn't necessarily need to be stored.
2. Internally, have a bunch of default __attribute__((weak)) functions that can 
be overriden by different areas of the code.  This way if someone wants a 
particular data rate tied to a board, the board can have the override. Or if 
the application wants to override it, it can.
3. Simply setup the radio in what I believe to be the most useful default 
configuration.  Then the application is responsible for configuring the radio 
further AFTER the radio is configured.  The radio module would be responsible 
for providing hooks to configure different aspects.  One thing I'm not sure of 
here is to know when the network stack has finished initializing the radio so 
it can begin it's configuration.

Any suggestions or guidance on this matter is appreciated!

Sincerely,
Anthony___
devel mailing list
devel@riot-os.org
https://lists.riot-os.org/mailman/listinfo/devel