Re: [riot-devel] ztimer - a new high-level timer for RIOT
Hi, here are my thoughts on the discussion. # Not Getting Lost in Requirement Analysis and Problem Specifications A good requirement analysis is a valuable tool for both development and evaluation of a software component. But once a solid understanding of the problem to solve is reached, additional effort put into a requirement analysis doesn't yield enough additional benefit to justify the work. And every requirement analysis is flawed: Assembling a complete list of all current requirements in RIOT's code base is hard. Predicting how future developments influence the requirements we have is impossible. There has to be a point when we just stop on collecting more requirements and consider the current list as good enough; a perfect, complete and definite result cannot be reached. High level timer API are no new concept and the basic goals and requirements are well understood. On top of these basic requirements, benchmarks could be a good tool to quantify how well specific timer implementations perform. To me, writing a set of benchmarks would be more useful than additional requirements collection. Not only would it allow to see how good ztimer/xtimer are performing. They will also be useful for development and reviews of future PRs targeting RIOTs timer framework. In the end, RIOT will be judged upon the features it provides. Not on the features on RIOT's to do lists. Not on how tough and rigorous the requirements are we have formulated on some yet-to-be-implemented feature. And not on how much documents and emails have been written about an yet-to-be-implemented feature. # Complete Rewrites can be the Best Option @Michel: You seem to dismiss the development approach of a complete rewrite fundamentally, apparently for ideological reasons. While most of the time a complete rewrite is not the best option, there are good reasons for doing so in some cases: When fundamental architectural changes are needed, the effort of an rewrite can be less compared to iterative transform the architecture. In such cases, a rewrite is the better option. I don't think that there is a reason to see a complete rewrite as some kind of failure that we should try very hard to prevent for the future. And ultimately, any attempt to prevent rewrites can fail. Any design decision is based on the current experience, the available tools, and the current requirements. But with time, more experience is gained, better tools become available, and completely new use cases with potentially fully distinct requirements pop up. Perfectly solid design decisions can be rendered obsolete by this. And sometimes, fundamental architecture changes are needed in response. In that cases, a rewrite can be the best option. And this could happen very well without any mistakes being made in the original implementation. # Suggestion of a Path Forward There seems to be an agreement, that an additional parameter is needed in the API. How about we specify an implementation independent high level timer API based on xtimer with an additional parameter. The type of the first argument could just by some `foo_t` that is provided by the implementation of that API. The implementation could be freely chosen as module, and xtimer could be the default backend when the user has not specified a backend. I bet it is trivial to extend xtimer in a way to comply with that API by just adding an ignored parameter. Everyone with the motivation, knowledge and dedication to fix the discussed issue in xtimer has still the opportunity to do so. And providing ztimer as alternative implementation of the same API would not hurt anyone. Not defining the semantics and contents of the first parameter sounds a bit crazy. But I bet that 90% of all use cases will only use two different values there: One low power low resolution setting for long sleeps and one high power high precision setting e.g. in drivers. Just providing these two settings as global variables (or preprocessor macros) under defined names would be enough to cater 90% of the use cases in an implementation agnostic way. (And the other use cases could provide their own global variables for the additional settings, so that only the assignment of those variable depend on the used implementation.) And if there is indeed enough interest in fixing xtimer, this would allow them to freely decide if they want this parameter to be a pointer to a clock struct as in ztimer, or maybe a bitmask holding a set of flags, or something completely different. It might be very well possible that the future will bring use cases will mutually exclusive requirements. A implementation independent API would allow to just let the users choose what they need. Kind regards, Marian On Tue, 10 Dec 2019 18:23:53 +0100 Michel Rottleuthner wrote: > Hi, > > Thanks for starting this! It's very much appreciated. > Discussing these things, reaching common ground and documenting > decisions and findings > during this process is IMO one of the most
Re: [riot-devel] ztimer - a new high-level timer for RIOT
Hi Michel,
On 12/11/19 4:50 PM, Michel Rottleuthner wrote:
> Hi Kaspa
>> Would it make sense to make a micro conference? Get everyone interested
>> in improving timers in a room and lock it until solutions are presented?
> Not convinced about the "lock in a room" ;) - but otherwise: absolutely
> yes!
>
> What do you think about an RDM PR?
> We could just use your design document as a starting point.
Let me propose the following: we make merging ztimer *as a distinct and
optional module* independent of changing RIOT's default timer
implementation. The latter can be done within the RDM.
IMO, ztimer is quite usable already, and even if only used as
multiplexer for the RTT, it provides a lot of benefit. I don't see a
reason not to merge it (when it's been reviewed properly), as an
optional module.
We can, in parallel, work on the RDM. If it turns out there's some
better option than ztimer, no harm was done, I'll of course happily
accept that.
I already have a basic xtimer benchmark application (for timing
set()/remove()/now() in pathetic cases), which can provide at least some
numbers. I'll PR that today.
Regarding "fixing" xtimer vs a rewrite from scratch, I'd like to point
out that #9503 alone changes (well, removes) ~450 lines of *logic code*.
That is three quarters of xtimer's total code, including definitions and
prototypes. IMO, we need to acknowledge that changing that amount of
code does not result in the same code base. We should call it "ytimer".
The amount of reviewing, validation and testing should be the same as
for a rewrite. Or maybe just be measured in "amount of lines changed".
Regarding whether a "clock" parameter makes sense, this is something we
should explore within the RDM. I think you need to prototype a function
that chooses a suitable frequency from multiple options (without relying
on an explicit parameter for that). (I'd actually suggest you use ztimer
as basis, as there you have multiple, multiplexed backends using the
same API. :) ). You might even be successful. At that point, an RDM can
decide if that functionality should move down the layers.
More details following:
>> periph_timer IMO should be the slimmest layer of hardware abstraction
>> that makes sense, so users that don't want to do direct non-portable
>> register based applications get the next "closest to the metal".
> Agree, but there are some things that we should add to the periph_timer.
> E.g. adding support for dedicated overflow interrupts together with an
> API to read
> the corresponding IRQ status bit.
> The high level timer would benefit from that on many platforms.
> E.g. Ztimer wouldn't require the code for the time partitioning
> mechanism then.
> But thats yet another part of the story...
Yes. Also, do all platforms support that overflow interrupt?
I don't think so, in which case this cannot be relied upon to be available.
> Also the term "frequency conversion" is a bit misleading I think.
> With a discrete clock you won't be able to just precisely convert a
> frequency to any other frequency in software.
> Especially if you want to increase the frequency - it will just be a
> calculation.
Yup. Frequency conversion makes sense if an application wants to sleep
12345ms, but the timer is clocked at e.g., 1024Hz.
>> That is one of the main issues with an API that doesn't have the clock
>> parameter, but a fixed (probably high frequency) frequency, as xtimer
>> has.
>
> Of course there is a difference.
> Here I just wanted to point out that the quality defect of xtimer
> not mapping to multiple peripherals is not directly tied to its API.
>
> Further, adding a convention to the xtimer API would allow to for
> automatic selection of an appropriate low-level timer.
> E.g. think of something like "will always use the lowest-power timer
> that still ensures x.xx% precision".
That's what ztimer does.
> Again, this is just a simple example to explain what I think we should
> also consider as part of the solution.
> Forcing the application / developer to select a specific instance also
> has it's downsides.
With convention ("ZTIMER_MSEC provides ~1ms accuracy"), the application
developer chooses the intended precision. Without that, and with a fixed
API time base, 1s (100us) cannot be distinguished from 1000ms or
100us.
Maybe it can, this is where you can maybe come up with a prototype.
> I mostly agree. But as I tried to clarify before:
> ztimer is mixing "relevant and valid fixes" and "introducing new design
> concepts".
> We should strive for being able to tell what is done because it fixes
> something
> and what is done because the concept is "considered better".
> Next to that the "considered better" should then be put to the test.
Ok. That might be necessary to choose one implementation over xtimer. -> RDM
>>> For timeouts that are calculated at runtime do we really want to always
>>> add some code to decide which instance to use?
>> If there are multiple instances, there is code that
Re: [riot-devel] Release [2020.01] - dates and feature requests
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] Release [2020.01] - dates and feature requests
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
