Re: [riot-devel] 802.15.4 Radio HAL RDM

[Robert Hartung]

Good morning RIOT developers,

Before giving a review in the mentioned PR, I would like to give some
shorts comments on here, that wouldn't fit in the PR.

While I really like the new approach to access lower levels directly and
making the integration of new network stacks a lot easier, I feel like
we are adding more complexity, and another level of abstraction, which
makes it hard for a user to change things or even understand how things
work.
As mentioned in #13771, I feel like the term network stack needs some
thoughts and the implementations need some cleanup (which I am happy to
assist and commit some of my time to).

I would like to see a OSI layer model along with common implementations
within RIOT. There *should* be APIs on each level if possible to access
individual levels. I would really like to see a good method to exchange
layers.
At the same point I know that this will not happen over night. It will
take time and thoughts of multiple people. I think the existing code is
a very good starting point, in order to see what's there and how it
currently works and how it "should" work (what would be desireable).
I write this, because in the past I found in particular hard to
understand the network stack within RIOT and how to access other levels.

Additionally, one of my students tried to implement the BPBISv7 DTN
protocol for RIOT and was successful, but it was a painful ride, as it
was very hard to debug stuff in between.

So all I am asking for would be a little help, to complete such a
diagram for now, to know all apis and "entry" points and give some
examples on how to access layers. Ideally at one point, my wish would be
fulfilled to be able to easily exchange layers.

Best Regards and have a nice weekend,
Robert

#13771: https://github.com/RIOT-OS/RIOT/issues/13771

Am 24.04.2020 um 18:51 schrieb José Ignacio Alamos:
> Dear RIOT developers,
>
> I've opened a PR with a new RIOT Developer Memo [1] with a proposal for
> a 802.15.4 Radio Hardware Abstraction Layer.
>
> Abstract:
>> This memo describes a Hardware Abstraction Layer (HAL) for radios compliant
>> with the IEEE802.15.4 standard. The work follows a technology-specific 
>> approach
>> to provide well defined hardware access that allows to implement agnostic
>> IEEE802.15.4 PHY and MAC layers on top. Additionally, the new HAL enables
>> integration of network stacks that require direct access to the radio.
> Next to the RDM I published an implementation of the Radio HAL API, a test
> application and 2 HAL implementations (`at86rf23x` and `nrf52840` radios).
> I also appended the memory efficiency compared to the current `netdev`
> implementation.
>
> I would like to request feedback from people that have some experience
> with these kind of radios.
>
> In case of any questions or comments, don't hesitate to reply
> (or post directly in the PR)
>
> Thank you so much in advance!
> Have a nice weekend.
>
> Best,
> José
>
> [1]: https://github.com/RIOT-OS/RIOT/pull/13943
> ___
> 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] Release [2020.01] - dates and feature requests

[Robert Hartung]

Hi Alex,
at86rf215 [9] is heavily tested by me and three of my colleagues. I
would really like to see this one merged for the next release!
I am pretty confident that we can "fully" test the driver soon.

Best Regards,
Robert

On 12.12.19 09:19, Alexandre Abadie wrote:
> Hi there,
> 
> Sorry for the late reply.
> 
> I have some suggestions of new features that I'd like to see in the release:
> - add the arduino bootloader feature to samd21 based boards
> (arduino-mkr, sodaq and feather-m0). That would improve a lot the user
> experience with these boards. See [1] for details.
> - some PRs related to AI (TensorFlow) on microcontrollers: [2], [3] and [4].
> - a series of PRs to improve the hifive1 port [5], [6], [7], [7bis] and
> another one to come,
> - it would be good to finally merge [8] (kw41z radio)
> - still in radio drivers, maybe also [9] (at86rf215)
> - it would be great to merge the PR about external BOARDSDIR variable [10]
> 
> There are many more things that could go in the release but as usual,
> they need reviews.
> 
> Cheers!
> 
> Alex
> 
> [1] https://github.com/RIOT-OS/RIOT/pull/12304
> [2] https://github.com/RIOT-OS/RIOT/pull/12805
> [3] https://github.com/RIOT-OS/RIOT/pull/12846
> [4] https://github.com/RIOT-OS/RIOT/pull/12847
> [5] https://github.com/RIOT-OS/RIOT/pull/12663
> [6] https://github.com/RIOT-OS/RIOT/pull/12902
> [7] https://github.com/RIOT-OS/RIOT/pull/12917
> [7bis] https://github.com/RIOT-OS/RIOT/pull/10833
> [8] https://github.com/RIOT-OS/RIOT/pull/12277
> [9] https://github.com/RIOT-OS/RIOT/pull/12128
> [10] https://github.com/RIOT-OS/RIOT/pull/12183
> 
> - Le 28 Nov 19, à 9:59, Francois-Xavier Molina
>  a écrit :
> 
> |Dear RIOTers, The release dates for the upcoming release cycle are
> fixed as follows:
> - 08.01.2020 - soft feature freeze, for high impact features -
> 15.01.2020 - hard feature freeze, for all features - 05.02.2020 -
> Release date
> Could you please send your suggestions for features which you would
> like to see merged during this release cycle. Best regards, and
> happy hacking!
> Francisco Molina|
> 
> 
> ___
> 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
> 

-- 
Robert Hartung, M.Sc.

Technische Universität Braunschweig
Institut für Betriebssysteme und Rechnerverbund
Mühlenpfordtstr. 23, Raum 115
38106 Braunschweig

Fon: +49 (531) 391 - 3246
Fax: +49 (531) 391 - 5936
E-Mail: hart...@ibr.cs.tu-bs.de
WWW: https://www.ibr.cs.tu-bs.de/users/hartung/
___
devel mailing list
devel@riot-os.org
https://lists.riot-os.org/mailman/listinfo/devel

Re: [riot-devel] ztimer - a new high-level timer for RIOT

[Robert Hartung]

Hey again ;)
Do we need to put any thoughts in power management / low_power /
integration with pm_layered? Or are the possible issues addreses /
already talked about?
Regards
Robert

On 09.12.19 14:49, Kaspar Schleiser wrote:
> Hey everyone,
> 
> since the RIOT Summit in Helsinki, I've put quite some work into ztimer,
> a possible successor to xtimer.
> 
> If you're interested, please see an updated design document here: [1]
> 
> Cheers,
> Kaspar
> 
> [1]
> https://github.com/RIOT-OS/RIOT/wiki/ztimer-problem-statement-and-design-document
> ___
> devel mailing list
> devel@riot-os.org
> https://lists.riot-os.org/mailman/listinfo/devel
> 

-- 
Robert Hartung, M.Sc.

Technische Universität Braunschweig
Institut für Betriebssysteme und Rechnerverbund
Mühlenpfordtstr. 23, Raum 115
38106 Braunschweig

Fon: +49 (531) 391 - 3246
Fax: +49 (531) 391 - 5936
E-Mail: hart...@ibr.cs.tu-bs.de
WWW: https://www.ibr.cs.tu-bs.de/users/hartung/
___
devel mailing list
devel@riot-os.org
https://lists.riot-os.org/mailman/listinfo/devel

Re: [riot-devel] ztimer - a new high-level timer for RIOT

[Robert Hartung]

Hi Kaspar,
why are 8-bit timers not listed? Intentional or unintentional?
Regards,
Robert

On 09.12.19 14:49, Kaspar Schleiser wrote:
> Hey everyone,
> 
> since the RIOT Summit in Helsinki, I've put quite some work into ztimer,
> a possible successor to xtimer.
> 
> If you're interested, please see an updated design document here: [1]
> 
> Cheers,
> Kaspar
> 
> [1]
> https://github.com/RIOT-OS/RIOT/wiki/ztimer-problem-statement-and-design-document
> ___
> devel mailing list
> devel@riot-os.org
> https://lists.riot-os.org/mailman/listinfo/devel
> 

-- 
Robert Hartung, M.Sc.

Technische Universität Braunschweig
Institut für Betriebssysteme und Rechnerverbund
Mühlenpfordtstr. 23, Raum 115
38106 Braunschweig

Fon: +49 (531) 391 - 3246
Fax: +49 (531) 391 - 5936
E-Mail: hart...@ibr.cs.tu-bs.de
WWW: https://www.ibr.cs.tu-bs.de/users/hartung/
___
devel mailing list
devel@riot-os.org
https://lists.riot-os.org/mailman/listinfo/devel

Re: [riot-devel] Driver for the at86rf215

[Robert Hartung]

Hi José,
hrmpf. Should've looked again into the list of PRs, was a while ago ;)
Will contribute with reviewing and testing.
Regards
Robert

On 24.10.19 16:26, José Alamos wrote:
> Hi Robert,
> 
> Note there's already a PR for this radio [1].
> It's using 2 `netdev_ieee802154` for handling each radio.
> 
> Maybe you can sync there and contribute with feedback and testing.
> 
> Best,
> José
> 
> [1]: https://github.com/RIOT-OS/RIOT/pull/12128
> On Thu, 2019-10-24 at 16:20 +0200, Robert Hartung wrote:
>> Hello fellow developers,
>>
>> I am targeting this question to developers here first before opening
>> any
>> issues. We are looking to implement a driver for the at86rf215. The
>> challenge here is, that we cannot fit it into the existing at86rf2xx
>> driver for a simple reason: It has two interfaces for Sub-Ghz and
>> 2.4Ghz
>> communication, but shares a single interrupt pin. My idea was to have
>> a
>> single device, which has multiple communication interfaces. From what
>> I've seen and researched about netdev, this is not possible, as a
>> netdev
>> has a driver, which consists of the callbacks, including the isr
>> handler.
>>
>> The Idea would then be to have a meta device for the interrupt
>> handling
>> and then calling the actual isr for the radio that the interrupt was
>> ment for. Any one having a similar problem or any ideas how to solve
>> this issue?
>>
>> Best Regards
>> Robert
>>
> 
> ___
> devel mailing list
> devel@riot-os.org
> https://lists.riot-os.org/mailman/listinfo/devel
> 

-- 
Robert Hartung, M.Sc.

Technische Universität Braunschweig
Institut für Betriebssysteme und Rechnerverbund
Mühlenpfordtstr. 23, Raum 115
38106 Braunschweig

Fon: +49 (531) 391 - 3264
Fax: +49 (531) 391 - 5936
E-Mail: hart...@ibr.cs.tu-bs.de
___
devel mailing list
devel@riot-os.org
https://lists.riot-os.org/mailman/listinfo/devel

[riot-devel] Driver for the at86rf215

[Robert Hartung]

Hello fellow developers,

I am targeting this question to developers here first before opening any
issues. We are looking to implement a driver for the at86rf215. The
challenge here is, that we cannot fit it into the existing at86rf2xx
driver for a simple reason: It has two interfaces for Sub-Ghz and 2.4Ghz
communication, but shares a single interrupt pin. My idea was to have a
single device, which has multiple communication interfaces. From what
I've seen and researched about netdev, this is not possible, as a netdev
has a driver, which consists of the callbacks, including the isr handler.

The Idea would then be to have a meta device for the interrupt handling
and then calling the actual isr for the radio that the interrupt was
ment for. Any one having a similar problem or any ideas how to solve
this issue?

Best Regards
Robert

-- 
Robert Hartung, M.Sc.

Technische Universität Braunschweig
Institut für Betriebssysteme und Rechnerverbund
Mühlenpfordtstr. 23, Raum 115
38106 Braunschweig

Fon: +49 (531) 391 - 3264
Fax: +49 (531) 391 - 5936
E-Mail: hart...@ibr.cs.tu-bs.de

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

Re: [riot-devel] tests compiler policy

[Robert Hartung]

I agree with Marian here! Don't use anything provided by TI :)

On 10.09.19 09:48, Gero Müller wrote:
> Hi!
> 
> That's what I meant with philosophy ;-)
> 
> And +1 for vanilla from me as well.
> 
> Thanks
> Gero
> 
> Am 10.09.19 um 09:20 schrieb Marian Buschsieweke:
>> Hi,
>>
>> I'd personally go the vanilla version, but not for philosophical reasons. My
>> reasons would be:
>>
>> - More consistent to other toolchains (no TI specific stuff)
>> - Does not rely on TI for future updates (in case TI looses interest in
>>   maintaining their on version)
>>
>> So +1 for vanilla GCC.
>>
>> Kind regards,
>> Marian
>>
>> On Tue, 10 Sep 2019 09:12:01 +0200
>> Gero Müller  wrote:
>>
>>> Hi!
>>>
>>> I am about to update the Dockerfile for testing to include a new version
>>> of msp430-gcc.
>>> We have the choice between a binary version (gcc 8) provded by TI:
>>>
>>>  
>>> http://software-dl.ti.com/msp430/msp430_public_sw/mcu/msp430/MSPGCC/latest/index_FDS.html
>>>
>>> and the vanilla upstream gcc 9.2 release.
>>> I have no idea about the performance / feature differences, but I use
>>> the vanilla version and it works fine.
>>>
>>> Which one would better match the RIOT philosophy?
>>>
>>> Cheers
>>> Gero
>>>
>>
>> ___
>> 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
> 

-- 
Robert Hartung, M.Sc.

Technische Universität Braunschweig
Institut für Betriebssysteme und Rechnerverbund
Mühlenpfordtstr. 23, Raum 115
38106 Braunschweig

Fon: +49 (531) 391 - 3264
Fax: +49 (531) 391 - 5936
E-Mail: hart...@ibr.cs.tu-bs.de
___
devel mailing list
devel@riot-os.org
https://lists.riot-os.org/mailman/listinfo/devel

Re: [riot-devel] How to properly use cortexm_sleep

[Robert Hartung]

 devel@riot-os.org <mailto:devel@riot-os.org>
>> https://lists.riot-os.org/mailman/listinfo/devel
>>
>>  
>>
>> _______
>> devel mailing list
>> devel@riot-os.org <mailto:devel@riot-os.org>
>> https://lists.riot-os.org/mailman/listinfo/devel
>>
>> ,
>>
>> ___
>> devel mailing list
>> devel@riot-os.org <mailto: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
> 
> 
> ___
> devel mailing list
> devel@riot-os.org
> https://lists.riot-os.org/mailman/listinfo/devel
> 

-- 
Robert Hartung, M.Sc.

Technische Universität Braunschweig
Institut für Betriebssysteme und Rechnerverbund
Mühlenpfordtstr. 23, Raum 115
38106 Braunschweig

Fon: +49 (531) 391 - 3264
Fax: +49 (531) 391 - 5936
E-Mail: hart...@ibr.cs.tu-bs.de
___
devel mailing list
devel@riot-os.org
https://lists.riot-os.org/mailman/listinfo/devel

[riot-devel] Integration of the ATmega4809

[Robert Hartung]

Hello RIOT developers!

I am currently trying to integrate the ATmega4809 curiosity nano board
into RIOT. I tried to base it on the atmega_common CPU, but the
architecture is different. Is there anyone having played with this one
or any other of the megaAVR0 series? It looks like I might need to
create a new base cpu it.

Is there anyone interested in collaborating on the integration?

Best Regards
Robert

-- 
Robert Hartung, M.Sc.

Technische Universität Braunschweig
Institut für Betriebssysteme und Rechnerverbund
Mühlenpfordtstr. 23, Raum 115
38106 Braunschweig

Fon: +49 (531) 391 - 3264
Fax: +49 (531) 391 - 5936
E-Mail: hart...@ibr.cs.tu-bs.de
___
devel mailing list
devel@riot-os.org
https://lists.riot-os.org/mailman/listinfo/devel

Re: [riot-devel] just got my Vega

[Robert Hartung]

Sounds great - where did you order yours from?

On 12.02.19 12:53, Kaspar Schleiser wrote:
> Hey fellow RIOT'ers,
> 
> I've just received a VEGAboard (rv32m1-vega).
> 
> It's feature list is very promising. On-board BLE/802.15.4, plenty of
> RAM and flash, (apparently) specs & reference manuals for everything.
> I'm curious how it's power consumption will be.
> 
> I think it'll be a challenge integrating the thing properly. It has five
> cores with different instruction sets, four of them on the same bus, if
> I read the datasheet correctly. I'm also very looking forward to see
> messages floating between the cores! ;)
> 
> Who's interested in collaborating on bringing RIOT onto the thing?
> 
> Kaspar
> 
> ___
> devel mailing list
> devel@riot-os.org
> https://lists.riot-os.org/mailman/listinfo/devel
> 

-- 
Robert Hartung, M.Sc.

Technische Universität Braunschweig
Institut für Betriebssysteme und Rechnerverbund
Mühlenpfordtstr. 23, Raum 115
38106 Braunschweig

Fon: +49 (531) 391 - 3264
Fax: +49 (531) 391 - 5936
E-Mail: hart...@ibr.cs.tu-bs.de
___
devel mailing list
devel@riot-os.org
https://lists.riot-os.org/mailman/listinfo/devel

Re: [riot-devel] What definitions/configuration belong into to what file

[Robert Hartung]

Hi!

I have to disagree here. While the peripherals belong to the MCU
hardware-wise, the actual board might limit the available
configurations, as pins might be used as GPIOs, and the peripherals
might not be available. Therefore it would also belong to the board.h.
IMO it is *possible* to merge into board.h and omit periph_conf.h to
make it more clear. The only argument for keeping it seperate would be
the re-usaility of periph_conf.h, on the other hand a board_common.h
could be created and re-used as well.

More opinions?

Robert

On 8/27/18 2:18 PM, smlng wrote:
> Hi Gunar,
> 
> in `periph_conf.h` we configure all the MCU/CPU peripherals, i.e., SPI, I2C 
> bus and so on,
> these are typically not bound to a board. On the other hand, in `board.h` we 
> configure all
> board specific stuff, like for instance LEDs which are not part of the MCU. 
> While LEDs also
> need a certain GPIO pin to be configured, you can connect an LED to any 
> (free) GPIO while
> peripheral busses are bound to certain pins on most MCUs - except for, e.g. 
> TIs CC2538.
> 
> However, you're right it is (in parts) a bit confusing what to configure 
> where (and why).
> 
>> On 27. Aug 2018, at 14:02, Gunar Schorcht  wrote:
>>
>> Signed PGP part
>> Hi,
>>
>> I'm trying again to sort the definitions of board configurations. I feel
>> like doing this for the tenth time.
>>
>> I have taken a look at many board.h, periph_conf.h, board_common.h and
>> periph_conf_common.h files for different platforms, eg., Arduino*,
>> Nucleo*, IoTlab, ...
>>
>> The difference between *.h and their *_common.h counterparts is qute clear.
>>
>> However, I'm still unsure what the difference between board.h and
>> periph_conf.h is. For example, LED pins are mostly defined in board.h
>> while the definition of the of I2C or SPI pins are defined in
>> periph_conf.h. What exactly makes the difference, LED pins as well as
>> I2C or SPI pins are determined by the board.
>>
>> So the question is, what belongs in board.h and what in periph_conf.h?
>> Are there any rules or guidelines.
>>
>> Regards
>> Gunar
>>
>> --
>> Wenn du laufen willst, lauf eine Meile. Wenn du ein neues Leben
>> kennenlernen willst, dann lauf Marathon. (Emil Zatopek)
>>
>>
>>
> Cheers,
>   Sebastian
> 
> [mail]: s...@mlng.net
> [code]: https://github.com/smlng
> 
> 
> ___
> devel mailing list
> devel@riot-os.org
> https://lists.riot-os.org/mailman/listinfo/devel
> 

-- 
Robert Hartung, M.Sc.

Technische Universität Braunschweig
Institut für Betriebssysteme und Rechnerverbund
Mühlenpfordtstr. 23, Raum 115
38106 Braunschweig

Fon: +49 (531) 391 - 3264
Fax: +49 (531) 391 - 5936
E-Mail: hart...@ibr.cs.tu-bs.de



signature.asc
Description: OpenPGP digital signature
___
devel mailing list
devel@riot-os.org
https://lists.riot-os.org/mailman/listinfo/devel

Re: [riot-devel] General configuration Task Force

[Robert Hartung]

Sounds fun, would love to help with power management stuff here (if needed).

- Robert

On 09.07.2018 10:09, Jose wrote:
> Dear maintainers,
> 
> 
> Last Friday we had an offline discussion with some RIOT people about he
> lack of a mechanism to configure Kernel parameters as well as
> application specific configurations (private keys, timer values, etc).
> Although RIOT is configurable via CFLAGS, there's no way to (easily)
> expose all configurations and tweak RIOT in a centralized manner. As
> shown, other OS are using several strategies in order to accomplish this
> (KConfig, header files, etc).
> 
> 
> I want to propose a "Kernel and Application specific configuration" Task
> Force to address these issues. What are your feelings about this? Anyone
> (besides me) is interested to work in this topic?
> 
> 
> Cheers,
> 
> José
> 
> ___
> devel mailing list
> devel@riot-os.org
> https://lists.riot-os.org/mailman/listinfo/devel

-- 
Robert Hartung, M.Sc.

Technische Universität Braunschweig
Institut für Betriebssysteme und Rechnerverbund
Mühlenpfordtstr. 23, Raum 115
38106 Braunschweig

Fon: +49 (531) 391 - 3264
Fax: +49 (531) 391 - 5936
E-Mail: hart...@ibr.cs.tu-bs.de
___
devel mailing list
devel@riot-os.org
https://lists.riot-os.org/mailman/listinfo/devel

Re: [riot-devel] RIOT policy on hardware support without example board

[Robert Hartung]

Hi Matthew,
I already ported the atmega1284p to RIOT: 

https://github.com/RIOT-OS/RIOT/pull/7604 


Best Regards,
Robert

> Am 14.03.2018 um 18:49 schrieb Matthew Blue :
> 
> Hello all,
> 
> I am building mesh networking sensor arrays for agriculture, and I am
> working on RIOT as an operating system for them. I have a number of
> bits of hardware that I need to write support for and I would like to
> contribute that back to RIOT. However, since this is ag equipment
> designed to be deployed in large quantities, I expect that it will not
> really be available for developers other than myself to test on.
> 
> What is the RIOT community's policy on submitting support for things
> like CPUs and peripherals without a board implementing them? I intend to
> support what I contribute into the foreseeable future. I suspect that
> having hardware already supported will influence future board designs
> if they are intended to run a system like RIOT (it influenced some of
> my design choices).
> 
> Some of the specific bits I intend to add are the ATmega1284P MCU, the
> TCA9539 I2C GPI expander, and the ADS1015 ADC (and variants).
> 
> Sincerely,
> Matthew
> ___
> 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] GNRC with sleepy nodes

[Robert Hartung]

Hi,
I didn't say it is not working. But xtimer was designed to guarantee a
resolution of 1usec. Therefore if you use it with a different timer, you
are out of spec within RIOT ;)

On 21.11.2017 17:28, Michael Andersen wrote:
> This is not quite true. Xtimer works fine with the ultra low power 32khz
> oscillator on SAMR21, it just needs a little reconfiguration. We have
> duty cycling nodes working ok with gnrc.
> 
> On Nov 21, 2017 8:26 AM, "Robert Hartung" <hart...@ibr.cs.tu-bs.de
> <mailto:hart...@ibr.cs.tu-bs.de>> wrote:
> 
> That's the 'only' issue. Problem: xtimer is guaranteed to have 1usec of
> resolution. Most low-power timers will only have 8bit resolution ->
> xtimer cannot be used.
> 
> On 21.11.2017 15:07, Francisco Molina wrote:
> >
> >>Issues #7743 and #7332 both discuss the problem.
> >>
> >>Dan
> >
> > I saw those issues but they only refer to the fact that xtimer doesn't
> > run during sleep modes, is that the only issue? Cheers
> >
> > Francisco
> >
> >
> > ___
> > devel mailing list
> > devel@riot-os.org <mailto:devel@riot-os.org>
> > https://lists.riot-os.org/mailman/listinfo/devel
> <https://lists.riot-os.org/mailman/listinfo/devel>
> >
> 
> --
> Robert Hartung, M.Sc.
> 
> Technische Universität Braunschweig
> Institut für Betriebssysteme und Rechnerverbund
> Mühlenpfordtstr. 23, Raum 115
> 38106 Braunschweig
> 
> Fon: +49 (531) 391 - 3264 <tel:%2B49%20%28531%29%20391%20-%203264>
> Fax: +49 (531) 391 - 5936 <tel:%2B49%20%28531%29%20391%20-%205936>
> E-Mail: hart...@ibr.cs.tu-bs.de <mailto:hart...@ibr.cs.tu-bs.de>
> ___
> devel mailing list
> devel@riot-os.org <mailto:devel@riot-os.org>
> https://lists.riot-os.org/mailman/listinfo/devel
> <https://lists.riot-os.org/mailman/listinfo/devel>
> 
> 
> 
> ___
> devel mailing list
> devel@riot-os.org
> https://lists.riot-os.org/mailman/listinfo/devel
> 

-- 
Robert Hartung, M.Sc.

Technische Universität Braunschweig
Institut für Betriebssysteme und Rechnerverbund
Mühlenpfordtstr. 23, Raum 115
38106 Braunschweig

Fon: +49 (531) 391 - 3264
Fax: +49 (531) 391 - 5936
E-Mail: hart...@ibr.cs.tu-bs.de
___
devel mailing list
devel@riot-os.org
https://lists.riot-os.org/mailman/listinfo/devel

Re: [riot-devel] GNRC with sleepy nodes

[Robert Hartung]

That's the 'only' issue. Problem: xtimer is guaranteed to have 1usec of
resolution. Most low-power timers will only have 8bit resolution ->
xtimer cannot be used.

On 21.11.2017 15:07, Francisco Molina wrote:
> 
>>Issues #7743 and #7332 both discuss the problem.
>>
>>Dan
> 
> I saw those issues but they only refer to the fact that xtimer doesn't
> run during sleep modes, is that the only issue? Cheers
> 
> Francisco
> 
> 
> ___
> devel mailing list
> devel@riot-os.org
> https://lists.riot-os.org/mailman/listinfo/devel
> 

-- 
Robert Hartung, M.Sc.

Technische Universität Braunschweig
Institut für Betriebssysteme und Rechnerverbund
Mühlenpfordtstr. 23, Raum 115
38106 Braunschweig

Fon: +49 (531) 391 - 3264
Fax: +49 (531) 391 - 5936
E-Mail: hart...@ibr.cs.tu-bs.de
___
devel mailing list
devel@riot-os.org
https://lists.riot-os.org/mailman/listinfo/devel

Re: [riot-devel] GNRC with sleepy nodes

[Robert Hartung]

Xtimer is not guaranteed to be based on timers that keep running in low
power modes. Therefore sleeping is not supported on most devices.


Am 20.11.2017 um 21:05 schrieb Francisco Molina:
> >Hi,
> >
> >since the timers you mentioned are dependent on xtimer and since xtimer has
> >some known issues with power management (what those are directly I can't
> >say due to my own lack of knowledge there, some hardware person on this
> >list might give you more detailed information on that) in the default
> >configuration, sleeping is not currently possible with GNRC on
> >ATSAMR21G18A-based
> >platforms (at least, as I understand it in the default configuration).
>
> >Cheers,
> >Martine
>
> What are the xtimer know issues with power management? I did a quick
> search at opened issues and coudln't find any directly realted to
> power management and xtimer. Could anyone expand on this? Thank you.
> Cheers!
>
> Francisco
>
>
> ___
> 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] SAMD21 Configuration ( was Monthly meetings for organisation purposes)

[Robert Hartung]

os, but being
> told you can only put them together 4 ways. And each new recipe has
> to be expressed as a derivative of the original recipes.
> 
> It is my belief that this is just not a scalable approach to
> configuring the samd21 for RIOT. It will continue to limit the
> application programmer's ability to tune the chip's flexibility to
> their application. I believe that a model that allows the user to
> better follow the model presented in the data sheets is what is
> needed. I would expect to be able to configure all of oscillators in
> one place, preferably in a coding construct/format that approximated
> something tabular. I would expect to be able to do something with
> the array of clock generators, indicating which were enabled,
> sourced to what, and divided appropriately. And I would like to be
> able to configure each peripheral’s clock source.
> 
> Dan and I groused through the SAML data sheet earlier today. Like
> the SAMD, the SAML has a handful of oscillator sources and
> lock-loops, and it has 8 generic clocks, which can serve as sources.
> So maybe there’s an argument to do both together. Dan and I just
> have samd21 boards though, so to do this kind of work, we need
> someone with access to SAMLs to agree to iterate regularly with us.
> ___
> devel mailing list
> devel@riot-os.org <mailto:devel@riot-os.org>
> https://lists.riot-os.org/mailman/listinfo/devel
> <https://lists.riot-os.org/mailman/listinfo/devel>
> 
> 
> 
> <https://www.avast.com/sig-email?utm_medium=email_source=link_campaign=sig-email_content=webmail>
>   Garanti sans virus. www.avast.com
> <https://www.avast.com/sig-email?utm_medium=email_source=link_campaign=sig-email_content=webmail>
> 
> 
> <#DAB4FAD8-2DD7-40BB-A1B8-4E2AA1F9FDF2>
> 
> 
> ___
> devel mailing list
> devel@riot-os.org
> https://lists.riot-os.org/mailman/listinfo/devel
> 

-- 
Robert Hartung, M.Sc.

Technische Universität Braunschweig
Institut für Betriebssysteme und Rechnerverbund
Mühlenpfordtstr. 23, Raum 115
38106 Braunschweig

Fon: +49 (531) 391 - 3264
Fax: +49 (531) 391 - 5936
E-Mail: hart...@ibr.cs.tu-bs.de
___
devel mailing list
devel@riot-os.org
https://lists.riot-os.org/mailman/listinfo/devel

Re: [riot-devel] [riot-maintainer] Monthly meetings for organisation purposes

[Robert Hartung]

I'm at SenSys ;-) Can't attend unfortunately, next time!

On 06.11.2017 15:11, Vincent Dupont wrote:
> Hi,
> 
> I unfortunatelly won't be able to attend today, I'll try to join next
> time.
> 
> Cheers,
> Vincent
> 
> Le lundi 06 novembre 2017 à 15:06 +0100, Alexandre Abadie a écrit :
>> Hi,
>>
>> I'll also attend.
>>
>> Alex
>>
>>
>>> Hi Paco,
>>>
>>> I'm in as well.
>>>
>>> Cheers,
>>> Martine
>>>
>>> 2017-11-04 1:03 GMT+01:00 Thomas Eichinger <tho...@riot-os.org>:
>>>> Hi Paco,
>>>>
>>>> Thanks for the initiative!
>>>>
>>>> I will try to tune in. 
>>>>
>>>> Without wanting to start a tools discussion, I had very good
>>>> experiences with larger groups using zoom.us. 
>>>>
>>>> Best, Thomas 
>>>>
>>>> On Nov 3, 2017, at 4:29 PM, Francisco Javier Acosta Padilla >>> cisco.aco...@inria.fr> wrote:
>>>>
>>>>> Hi again!
>>>>>
>>>>> A kind reminder to let us now who’s willing to attend the
>>>>> meeting on Monday, November 6th at 17:00 CET (UTC +1).
>>>>>
>>>>> I don’t have an agenda yet but if we can establish it before it
>>>>> would speed up the meeting. So far I propose:
>>>>>
>>>>> 1. Sort the most urgent bugs-issues by priority
>>>>> 2. Assign (more/new) people to the bugs-issues
>>>>> 3. Mark the related issues/PRs to be solved as “in progress”
>>>>>
>>>>> The goal is to have the selected issues solved before the next
>>>>> meeting, if it happens before, be free to assign new ones and
>>>>> move them to the “in progress” column.
>>>>>
>>>>> Please don’t hesitate to propose your ideas for the topics of
>>>>> the meeting!
>>>>>
>>>>> Cheers!
>>>>>
>>>>> -- 
>>>>> Francisco Javier Acosta Padilla
>>>>> Research Engineer at INRIA Saclay
>>>>> INFINE Team
>>>>>
>>>>> On 1 November 2017 at 12:25:51, Martine Lenders (mail@martine-l
>>>>> enders.eu) wrote:
>>>>>> Hi Cenk,
>>>>>>
>>>>>> 2017-11-01 11:05 GMT+01:00 Cenk Gündoğan <list-riot@cgundogan
>>>>>> .de>:
>>>>>>>>> On 17-10-31 18:03:01, Francisco Javier Acosta Padilla
>>>>>>> wrote:
>>>>>>>>> […]
>>>>>>>>>> P.S: @Martine, can you set up the next Hack
>>>>>>> meeting? Thanks
>>>>>>>>>
>>>>>>>>
>>>>>>>> Anything different to do than the usual ad-hoc placecam
>>>>>>> set-up?
>>>>>>>>
>>>>>>>
>>>>>>> Jup, provide a working mic for the FU's PlaceCam laptop
>>>>>>> this time (:
>>>>>>
>>>>>> We had... the problem was that the machine we ran placecam on
>>>>>> was so slow and old that ALSA wasn't able to stream that
>>>>>> audio including video ^^ (that's definitely a problem we need
>>>>>> to solve until next week).
>>>>>>
>>>>>> Cheers,
>>>>>> Martine 
>>>>>> ___
>>>>>> Maintainer mailing list
>>>>>> maintai...@riot-os.org
>>>>>> https://lists.riot-os.org/mailman/listinfo/maintainer
>>>>> ___
>>>>> Maintainer mailing list
>>>>> maintai...@riot-os.org
>>>>> https://lists.riot-os.org/mailman/listinfo/maintainer
>>>>
>>>> ___
>>>> Maintainer mailing list
>>>> maintai...@riot-os.org
>>>> https://lists.riot-os.org/mailman/listinfo/maintainer
>>>>
>>>
>>>
>>> ___
>>> Maintainer mailing list
>>> maintai...@riot-os.org
>>> https://lists.riot-os.org/mailman/listinfo/maintainer
>>
>> ___
>> Maintainer mailing list
>> maintai...@riot-os.org
>> https://lists.riot-os.org/mailman/listinfo/maintainer

-- 
Robert Hartung, M.Sc.

Technische Universität Braunschweig
Institut für Betriebssysteme und Rechnerverbund
Mühlenpfordtstr. 23, Raum 115
38106 Braunschweig

Fon: +49 (531) 391 - 3264
Fax: +49 (531) 391 - 5936
E-Mail: hart...@ibr.cs.tu-bs.de
___
devel mailing list
devel@riot-os.org
https://lists.riot-os.org/mailman/listinfo/devel

Re: [riot-devel] pm_reboot

[Robert Hartung]

Hi Kaspar,

pm.h consists of pm_set_lowest, pm_off and pm_reboot.
pm_fallback therefore should define stubs for all of these [1]

cpu/cortexm_common defines some better implementation and also provides
cortexm_sleep, that's why I created pm_cortexm_common [2].

cpu/stm32_common provides pm_set, but only for some CPUs, but always
uses cortexm_sleep from cortexm_common - However I don't see a
dependency of stm32_common to periph_common? Does this mean, all boards
currenctly always use cortexm_common anyway, if they use stm32_common?

This made me create *pm_stm32_common_layered* [3], as this only provides
pm_set, so others can use pm_layered with this one.

Another cool thing is that cpu/saml21 / cpu/samd21 are just able to use
pm_layered and provide their own pm_set().

Q: Why is the pm_set guarded with ifdefs? Shouldn't all CPUs that use
stm32_common be able to use pm_layered with pm_set? The same applies for
all CPUs that are based on cortexm_common IMO.

I've finished my WIP branch and it can be viewed at [0]

[0] https://github.com/roberthartung/RIOT/tree/hartung/power-management
[1]
https://github.com/roberthartung/RIOT/blob/hartung/power-management/drivers/pm_fallback/pm_fallback.c
[2]
https://github.com/roberthartung/RIOT/blob/hartung/power-management/cpu/cortexm_common/pm/pm.c
[3]
https://github.com/roberthartung/RIOT/blob/hartung/power-management/cpu/stm32_common/pm/pm.c

On 13.09.2017 15:09, Kaspar Schleiser wrote:
> Hi,
>
> On 09/13/2017 03:06 PM, Robert Hartung wrote:
>> Make all pm_* implementations submodules, so the final CPU *always* has
>> to select the according pm implementation.
>
> You mean all functions, like pm_reboot()?
>
> Kaspar
>
-- 
Robert Hartung, M.Sc.

Technische Universität Braunschweig
Institut für Betriebssysteme und Rechnerverbund
Mühlenpfordtstr. 23, Raum 115
38106 Braunschweig

Fon: +49 (531) 391 - 3264
Fax: +49 (531) 391 - 5936
E-Mail: hart...@ibr.cs.tu-bs.de
___
devel mailing list
devel@riot-os.org
https://lists.riot-os.org/mailman/listinfo/devel

Re: [riot-devel] pm_reboot

[Robert Hartung]

Hi Kaspar,

I just looked in more detail on what you've done.
Using submodules is fine for me, but I would like to change a key aspect
here:

Make all pm_* implementations submodules, so the final CPU *always* has
to select the according pm implementation.
For cortexm_common this would allow us to get rid of all #ifdef stuff
which is really ugly!

Would that be fine? When do you plan to be finished with the submodules?
I would really like to finish the pm architecture and finally use it!

- Robert

On 11.09.2017 09:01, Kaspar Schleiser wrote:
> Hi,
> 
> On 09/08/2017 11:28 AM, Robert Hartung wrote:
>> Looks like it's not that easy. Many platforms define pm_reboot in the
>> board's file(s).
> 
> Only mips-malta has it's own "pm_reboot()" implementation. The other two
> define stubs.
> 
>> Additionally pm_layered does not define pm_reboot, the same applies for
>> pm_off (pm_off can be modeled as pm_set_lowest(); irq_disable();
>> while(1) in pm_layered I guess ?).
> 
> pm_layered does define pm_set_lowest() as weak exactly like that.
> 
>> Therefore I will work on removing pm_reboot() from pm_fallback
>> implementation and create additional modules if needed (at some points
>> pm_reboot is defined outside of pm anyway).
> 
> When designing periph/pm, we intentionally moved reboot from a core
> include into periph/pm, as it seemed to fit together with pm_off().
> 
> Do you have a WIP branch somewhere? While working on #7241, I had to
> implement a lot of what we've discussed, in order to make anything
> compile with sumbodulized periph. Maybe you can take a look? the
> requirements have changed a little.
> 
> Kaspar
> 

-- 
Robert Hartung, M.Sc.

Technische Universität Braunschweig
Institut für Betriebssysteme und Rechnerverbund
Mühlenpfordtstr. 23, Raum 115
38106 Braunschweig

Fon: +49 (531) 391 - 3264
Fax: +49 (531) 391 - 5936
E-Mail: hart...@ibr.cs.tu-bs.de
___
devel mailing list
devel@riot-os.org
https://lists.riot-os.org/mailman/listinfo/devel

Re: [riot-devel] pm_reboot

[Robert Hartung]

Hi Kaspar,

On 11.09.2017 09:01, Kaspar Schleiser wrote:

> Only mips-malta has it's own "pm_reboot()" implementation. The other two
> define stubs.

Might be, still, it has to be considered where to place it and how we
define fallbacks cleanly!

>> Additionally pm_layered does not define pm_reboot, the same applies for
>> pm_off (pm_off can be modeled as pm_set_lowest(); irq_disable();
>> while(1) in pm_layered I guess ?).
> 
> pm_layered does define pm_set_lowest() as weak exactly like that.

I am not using weak definitions. Because of the PR that claims that
definitions are not chosen correctly in RIOT!

> 
>> Therefore I will work on removing pm_reboot() from pm_fallback
>> implementation and create additional modules if needed (at some points
>> pm_reboot is defined outside of pm anyway).
> 
> When designing periph/pm, we intentionally moved reboot from a core
> include into periph/pm, as it seemed to fit together with pm_off().

Can't really see a reason why this belongs together IMO, but we can
leave it there for now.

> Do you have a WIP branch somewhere? While working on #7241, I had to
> implement a lot of what we've discussed, in order to make anything
> compile with sumbodulized periph. Maybe you can take a look? the
> requirements have changed a little.

I stopped working on this because of the pm_reboot problems. Therefore I
didnt create a WIP branch on my fork yet, as I wasn't able to setup a
working version.

Your PR does not compile for me, almost 50% of the boards in
examples/default/ are not compiling anymore.
At least the first few I checked are missing pm_reboot (undefined
reference).

- Robert
-- 
Robert Hartung, M.Sc.

Technische Universität Braunschweig
Institut für Betriebssysteme und Rechnerverbund
Mühlenpfordtstr. 23, Raum 115
38106 Braunschweig

Fon: +49 (531) 391 - 3264
Fax: +49 (531) 391 - 5936
E-Mail: hart...@ibr.cs.tu-bs.de
___
devel mailing list
devel@riot-os.org
https://lists.riot-os.org/mailman/listinfo/devel

Re: [riot-devel] pm_reboot

[Robert Hartung]

Looks like it's not that easy. Many platforms define pm_reboot in the
board's file(s).
Additionally pm_layered does not define pm_reboot, the same applies for
pm_off (pm_off can be modeled as pm_set_lowest(); irq_disable();
while(1) in pm_layered I guess ?).

Therefore I will work on removing pm_reboot() from pm_fallback
implementation and create additional modules if needed (at some points
pm_reboot is defined outside of pm anyway).

- Robert

On 08.09.2017 11:03, Robert Hartung wrote:
> After a short discussion offline we decided to keep it as it is. As the
> nucleo board for example, supports saving reigsters across the reset.
> Therefor when entering low power modes or making a reboot, it might be
> required to perform some more stuff.
> 
> The pm_* functions will now all be combined in a single module to make
> it easier to develop PM for other cpus.
> 
> - Robert
> 
> On 08.09.2017 10:20, Robert Hartung wrote:
>> Hi *,
>>
>> I am working on the pm (power management) module of RIOT. Can anyone
>> tell me why pm_reboot is (often) part of this module?
>>
>> If no one votes against it, I woud like to move *pm_reboot()* to a
>> dedicated module, in order to have a reboot_fallback module as we have
>> planned for pm_fallback and additionally common CPUs can implement
>> specific reboot functions if required.
>>
>> Is 'reboot' a good module name? Or should we name it pm_reboot_fallback
>> (prefix it with pm)?
>>
>> Background: atmega_common defines a pm_reboot, but no power management
>> by default. Therefore using pm_fallback is not possible and we would
>> have to duplicate existing code (bad idea!).
>>
>> Best,
>> Robert
>>
> 

-- 
Robert Hartung, M.Sc.

Technische Universität Braunschweig
Institut für Betriebssysteme und Rechnerverbund
Mühlenpfordtstr. 23, Raum 115
38106 Braunschweig

Fon: +49 (531) 391 - 3264
Fax: +49 (531) 391 - 5936
E-Mail: hart...@ibr.cs.tu-bs.de
___
devel mailing list
devel@riot-os.org
https://lists.riot-os.org/mailman/listinfo/devel

Re: [riot-devel] pm_reboot

[Robert Hartung]

After a short discussion offline we decided to keep it as it is. As the
nucleo board for example, supports saving reigsters across the reset.
Therefor when entering low power modes or making a reboot, it might be
required to perform some more stuff.

The pm_* functions will now all be combined in a single module to make
it easier to develop PM for other cpus.

- Robert

On 08.09.2017 10:20, Robert Hartung wrote:
> Hi *,
> 
> I am working on the pm (power management) module of RIOT. Can anyone
> tell me why pm_reboot is (often) part of this module?
> 
> If no one votes against it, I woud like to move *pm_reboot()* to a
> dedicated module, in order to have a reboot_fallback module as we have
> planned for pm_fallback and additionally common CPUs can implement
> specific reboot functions if required.
> 
> Is 'reboot' a good module name? Or should we name it pm_reboot_fallback
> (prefix it with pm)?
> 
> Background: atmega_common defines a pm_reboot, but no power management
> by default. Therefore using pm_fallback is not possible and we would
> have to duplicate existing code (bad idea!).
> 
> Best,
> Robert
> 

-- 
Robert Hartung, M.Sc.

Technische Universität Braunschweig
Institut für Betriebssysteme und Rechnerverbund
Mühlenpfordtstr. 23, Raum 115
38106 Braunschweig

Fon: +49 (531) 391 - 3264
Fax: +49 (531) 391 - 5936
E-Mail: hart...@ibr.cs.tu-bs.de
___
devel mailing list
devel@riot-os.org
https://lists.riot-os.org/mailman/listinfo/devel

[riot-devel] pm_reboot

[Robert Hartung]

Hi *,

I am working on the pm (power management) module of RIOT. Can anyone
tell me why pm_reboot is (often) part of this module?

If no one votes against it, I woud like to move *pm_reboot()* to a
dedicated module, in order to have a reboot_fallback module as we have
planned for pm_fallback and additionally common CPUs can implement
specific reboot functions if required.

Is 'reboot' a good module name? Or should we name it pm_reboot_fallback
(prefix it with pm)?

Background: atmega_common defines a pm_reboot, but no power management
by default. Therefore using pm_fallback is not possible and we would
have to duplicate existing code (bad idea!).

Best,
Robert

-- 
Robert Hartung, M.Sc.

Technische Universität Braunschweig
Institut für Betriebssysteme und Rechnerverbund
Mühlenpfordtstr. 23, Raum 115
38106 Braunschweig

Fon: +49 (531) 391 - 3264
Fax: +49 (531) 391 - 5936
E-Mail: hart...@ibr.cs.tu-bs.de
___
devel mailing list
devel@riot-os.org
https://lists.riot-os.org/mailman/listinfo/devel

Re: [riot-devel] Discussion of Power Management

[Robert Hartung]

Hi,

On 31.08.2017 17:42, Kaspar Schleiser wrote:

>
>>
>> In any case, if I added USE_MODULES += periph_common_pm_fallback, it
>> will not get compiled. Any idea why?
> 
> Did you use "USEMODULE" instead of "USE_MODULES"?
Yes, did not work :(

> Maybe the periph_common directory doesn't get selected. But we can't
> make periph_common_pm_fallback depend on periph_common, that might have
> side effects.
> 
> How about drivers/pm_fallback/... for now?

Then I'd vote for moving pm_layered to drivers as well? Or should be
make it sys/pm_fallback/?

- Robert

-- 
Robert Hartung, M.Sc.

Technische Universität Braunschweig
Institut für Betriebssysteme und Rechnerverbund
Mühlenpfordtstr. 23, Raum 115
38106 Braunschweig

Fon: +49 (531) 391 - 3264
Fax: +49 (531) 391 - 5936
E-Mail: hart...@ibr.cs.tu-bs.de
___
devel mailing list
devel@riot-os.org
https://lists.riot-os.org/mailman/listinfo/devel

Re: [riot-devel] Discussion of Power Management

[Robert Hartung]

Hi Kaspar,

On 31.08.2017 17:02, Kaspar Schleiser wrote:
> Hi Robert,
> 
> On 08/31/2017 04:37 PM, Robert Hartung wrote:
>>> - if not, possibly e.g., kinetis_common has pm_set(), then that should
>>> depend on pm_layered
>>
>> This means that kinetis_common should provide a module
>> **kinetis_common_pm** that provides pm_set. The CPU should then depend
>> on this module. Additionally, it should select pm_layered.
> 
> Yes!
> 
>>> - if not, it depends on periph_pm_fallback (which should wrap current
>>> drivers/periph_common/pm.c)
>>
>> In this case we use the existing pm_* functions from
>> drivers/periph_common/pm.c, but I would move them to the module I
>> created (pm_fallback?).
> 
> Perfect!
> 
>> I am working on a pm_fallback module (moved it from drivers/periph/pm.c
>> to sys/pm_fallback/pm.c) - is that the right location? Or where should
>> it be located?
> 
> I think as the periph common code is in drivers/, so should the fallback
> code.

Just asked because pm_layered is in sys/ ;-)

> 
> How about using submodules within drivers/periph_common/Makefile? E.g.,
> 
> - rename drivers/periph_common/pm.c to pm_fallback.c
> - add
> # exclude submodule sources from *.c wildcard source selection
> SRC := $(pm_fallback.c,$(wildcard *.c))
>   to drivers/periph_common/Makefile
> 
> - add "PSEUDOMODULES += periph_common_%" to makefiles/pseudomodules.mk
> 
> That would compile pm_fallback *only* if periph_common_pm_fallback is
> selected. (with #5757, all periph files will become submodules...)

This does not work for me, should it be
SRC := $(filter-out pm_fallback.c,$(wildcard *.c))
?

In any case, if I added USE_MODULES += periph_common_pm_fallback, it
will not get compiled. Any idea why?

> kinetis_common/periph/pm.c can just go (and be replaced with a
> dependency on the cortem_common code).
I will check that

- Robert

-- 
Robert Hartung, M.Sc.

Technische Universität Braunschweig
Institut für Betriebssysteme und Rechnerverbund
Mühlenpfordtstr. 23, Raum 115
38106 Braunschweig

Fon: +49 (531) 391 - 3264
Fax: +49 (531) 391 - 5936
E-Mail: hart...@ibr.cs.tu-bs.de
___
devel mailing list
devel@riot-os.org
https://lists.riot-os.org/mailman/listinfo/devel

Re: [riot-devel] Discussion of Power Management

[Robert Hartung]

Hi Kaspar,

thanks for the reply. See answers inline

On 31.08.2017 16:15, Kaspar Schleiser wrote:

> All of them who define pm_set() support pm_layered.

Makes sense. **CPUs should always define what they are going to use!**

> cortexm_common just provides a fallback for pm_set_lowest() which at
> least sets the ARM CPU into idle.

Oh, damn! It's not defining a pm_set. You are completely right, this is
how it should be! Got a little confused here.

I wonder why the kinetis_common cpu defines a pm_set, but cortexm_common
does not? Because the function is cortexm_sleep(0), which should be
available to all cortexm_common-based boards/cpus? So why not merge
these two?

> 
> This is how I envision it:
> 
> - if a CPU has a proper pm_set(), it depends on pm_layered

ACK. pm_layered does everything, except for pm_set. pm_layered will then
do all other stuff.

> - if not, possibly e.g., kinetis_common has pm_set(), then that should
> depend on pm_layered

This means that kinetis_common should provide a module
**kinetis_common_pm** that provides pm_set. The CPU should then depend
on this module. Additionally, it should select pm_layered.

> - if not, the cpu (or e.g., kinetis_common) might depend on
> cortexm_periph_pm_fallback (where the current cortexm weak defines
> should go)

Also sounds good.

> - if the cpu (or any common ancestor) has it's own way of power
> management, it implements pm_set_lowest()

Absolutely. Then we just don't use any of the existing pm_* modules.
This is the case that can always be done.

> - if not, it depends on periph_pm_fallback (which should wrap current
> drivers/periph_common/pm.c)

In this case we use the existing pm_* functions from
drivers/periph_common/pm.c, but I would move them to the module I
created (pm_fallback?).

I am working on a pm_fallback module (moved it from drivers/periph/pm.c
to sys/pm_fallback/pm.c) - is that the right location? Or where should
it be located?

> That should cover all cases, right?

I think so. Let's discuss the naming and location of the fallback
modules across CPUs and RIOT in general and I will take care of this.

- Robert

-- 
Robert Hartung, M.Sc.

Technische Universität Braunschweig
Institut für Betriebssysteme und Rechnerverbund
Mühlenpfordtstr. 23, Raum 115
38106 Braunschweig

Fon: +49 (531) 391 - 3264
Fax: +49 (531) 391 - 5936
E-Mail: hart...@ibr.cs.tu-bs.de
___
devel mailing list
devel@riot-os.org
https://lists.riot-os.org/mailman/listinfo/devel

[riot-devel] Discussion of Power Management

[Robert Hartung]

Dear everyone,

I've worked on the power management for the atmega platform at the RIOT
Hackathon.
While creating PRs for the different parts, I stopped at a critial point
I would like to discuss here:

Several functions are used for the power management and stubs are
provided in drivers/periph_common/pm.c. However as mentioned in one
issue, the weak implementation did *not* work correctly.
Therefore we agreed on removing weak definitions for the module and use
some #ifdefs instead:

#if !defined( MODULE_PM_LAYERED )
void pm_set_lowest(void) { }
#endif

Unfortunately, this does not work because some platforms and especially
the stm32_common/kinetis_common/cortexm_common platforms define these
functions all over the place!

My first question is there for, is there a good system to
implementations for a module such as the PM module at different levels?

E.g. the CPU should always have the possibility to implement specific
pm_* functions. A fallback could be provided in the common CPU.
Additionally, the pm_layered module uses some of these CPU functions.
And finally, the fallback functions in pm.c should be used, if none exist.
Is it ok to use #define / #ifdef constructs for these? Any opinions?
I think we need a very fine-granular system here. I started to add
special features to handle this case:

makefiles/features.inc.mk

DEFAULT_FEATURES += periph_pm periph_pm_off periph_pm_set_lowest
periph_pm_reboot

cpu/cortexm_common/Makefile.features
FEATURES_PROVIDED += periph_pm_set_lowest

I thought that maybe features can be used to describe which functions
are provided. Later on based on include/compile order, missing functions
can be added if needed. Any opinions on this?

Best Regards,
Robert

-- 
Robert Hartung, M.Sc.

Technische Universität Braunschweig
Institut für Betriebssysteme und Rechnerverbund
Mühlenpfordtstr. 23, Raum 115
38106 Braunschweig

Fon: +49 (531) 391 - 3264
Fax: +49 (531) 391 - 5936
E-Mail: hart...@ibr.cs.tu-bs.de
___
devel mailing list
devel@riot-os.org
https://lists.riot-os.org/mailman/listinfo/devel