[riot-devel] periph_clk_en on STM32L with -Os optimization may result in Hard Fault

[Oleg Artamonov]

Hi everyone

 

While working with low-power modes on STM32L1, we found a bug (?) in gcc
with -Os optimization - somehow it "optimizes" rather simple
periph_clk_en(bus_t bus, uint32_t mask) function in
cpu/stm32_common/cpu_common.c, so using it right after waking up from STOP
mode results in Hard Fault (for some reasons, in our firmware it is called
from clk_init(), and clk_init() is called right after __WFI() in LPM code,
as we need to switch MCU from 2 MHz MSI clock back to our default clock
settings).

 

Didn't dig it any deeper yet, but just for everyone to know:

 

-void periph_clk_en(bus_t bus, uint32_t mask)

+void __attribute__((optimize("O3"))) periph_clk_en(bus_t bus, uint32_t
mask)

 

fixes it.

 

--

Oleg Artamonov

+7 (916) 631-34-90

www.unwds.com

 

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

[riot-devel] planning for release 2017.04

[Kaspar Schleiser]

Dear RIOTers,

for the next release, we've decided to shorten the merge window for
"high impact"-changes.

Previously, we've tried hard to finish up even complex changes (like the
just released SPI rework) in time for a release. That lead to code
touching many configurations but getting only two weeks of testing.
We've been lucky so far regarding unexpected regressions, but would like
to be more certain that a release meets our quality expectaions.

So for the upcoming 2017.04 release, the schedule is as follows:

- the merge window for "high impact" changes ends on March 10th.
- regular feature freeze is on April 14th.
- planned release date is on April 28th.

The exact definition of "high impact" is up to the maintainers.

Keep on hacking!
Kaspar

___
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] Removed Driver

[Ilias Seitanidis]

Ok, the code removed is totaly useless or are there any parts that I can
use?(Just a question before I go over the datasheet of the ltc4150). I will
try to fix it as soon as possible, I dont know if there should also be a
PR, because with the ltc4150 device we can estimate the battery level of a
RIOT device, which seems important on IoT.

Best,
Ilias

2017-02-20 14:23 GMT+01:00 Kaspar Schleiser :

> Hi Ilias,
>
> On 02/20/2017 02:07 PM, Ilias Seitanidis wrote:
> >  I want to ask why the ltc4150 driver was removed( I will need to use it
> > and I would like to know if I should do any modifications on the
> > existing code for the ltc4150). Or is there any other new driver
> > supported by RIOT for coulomb counting or voltage meter?
>
> We've removed the driver (you've seen the PR: [1] ?) because it was not
> using our periph-based hardware abstraction, didn't even have an
> implementation for the needed board-specific code and had several other
> code quality issues, and noone found the time to fix it.
>
> We'd be happy to see an updated version!
>
> Cheers,
> Kaspar
>
> [1] https://github.com/RIOT-OS/RIOT/pull/6591
> ___
> 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] Removed Driver

[Kaspar Schleiser]

Hi Ilias,

On 02/20/2017 02:07 PM, Ilias Seitanidis wrote:
>  I want to ask why the ltc4150 driver was removed( I will need to use it
> and I would like to know if I should do any modifications on the
> existing code for the ltc4150). Or is there any other new driver
> supported by RIOT for coulomb counting or voltage meter?

We've removed the driver (you've seen the PR: [1] ?) because it was not
using our periph-based hardware abstraction, didn't even have an
implementation for the needed board-specific code and had several other
code quality issues, and noone found the time to fix it.

We'd be happy to see an updated version!

Cheers,
Kaspar

[1] https://github.com/RIOT-OS/RIOT/pull/6591
___
devel mailing list
devel@riot-os.org
https://lists.riot-os.org/mailman/listinfo/devel

[riot-devel] Removed Driver

[Ilias Seitanidis]

Hi all,
 I want to ask why the ltc4150 driver was removed( I will need to use it
and I would like to know if I should do any modifications on the existing
code for the ltc4150). Or is there any other new driver supported by RIOT
for coulomb counting or voltage meter?
Thank you in advance!

Best regards,
Ilias Seitanidis
___
devel mailing list
devel@riot-os.org
https://lists.riot-os.org/mailman/listinfo/devel