Hi,
in order to push this forward I just opened a PR for an RDM at
https://github.com/RIOT-OS/RIOT/pull/12970. This PR is in an early state and
both feedback and help will be greatly appreciated.
> IMO, users should just not use these timer values as timestamps.
> That maybe needs to be stated
Hi Ralf,
On 12/13/19 6:41 PM, Ralf Schlatterbeck wrote:
> As far as I understand, the new timer implementation would not use 64
> bit for the timer and the user is responsible for not overrunning the
> timer? Note that I haven't looked a the implementation yet, so forgive
> my ignorance.
I think
As far as I understand, the new timer implementation would not use 64
bit for the timer and the user is responsible for not overrunning the
timer? Note that I haven't looked a the implementation yet, so forgive
my ignorance.
Over the years my experience is that it's no good idea to burden the
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,
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
>
Hi Kaspar,
thanks a lot for reading thru that and for the reply!
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
Hi Michel,
thanks for all that input. It is *a lot*. I guess it is a complex subject..
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?
On 12/10/19 6:23 PM, Michel Rottleuthner wrote:
>> RIOT needs
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 important things to do before
we move on.
I'm really sorry to write this wall of text, but there are so
Hey Kaspar,
On Mon, Dec 09, 2019 at 11:28:19PM +0100, Kaspar Schleiser wrote:
> > Hm, to be honest, I'm not so sure of what kind of efficiency we're speaking
> > here. CPU time or memory? Probably both, right? Regarding the CPU
> > efficiency,
> > I would assume that this also dictates the
Hi,
I was just literally about to send an email with pretty much the same arguments
Kaspar wrote right now. So I skip them and throw in a +1 instead.
> Below that, context switching takes the bulk of the time, so spinning (not
> using a callback) is probably preferable.
I think that the ws281x
Hey,
On 12/9/19 10:32 PM, Oleg Hahm wrote:
> Hm, to be honest, I'm not so sure of what kind of efficiency we're speaking
> here. CPU time or memory? Probably both, right? Regarding the CPU efficiency,
> I would assume that this also dictates the maximum precision, right?
I don't think so. The
Hey!
On Mon, Dec 09, 2019 at 10:07:16PM +0100, Kaspar Schleiser wrote:
> > Anyway, I think we need to define what "very efficient timers for use in
> > time-critical drivers" means in order to being able to check whether the
> > proposal fulfills the requirement or not.
>
> We can try. What
Hi Oleg et all,
On 12/9/19 9:25 PM, Oleg Hahm wrote:
> I think the problem statement and the requirements could indeed be more
> precise - while I must admit that a lack of precise requirements is a failure
> of the RIOT community.
Yes, that could be. I intentionally did not add requirements. I
Folks!
Can we get back to the actual problem at hand, please?
Let me recap:
Kaspar came up with a proposal for a new timer API, since xtimer has flaws (as
identified by multiple members of the RIOT community during the last ~4 years)
and is apparently not fixable (at least no one came up with a
Hi Marian,
On 09/12/2019 21:00, Marian Buschsieweke wrote:
I'd like to point out that the research community has largely dismissed Karl
Poppers contribution to the demarcation problem, as largely accepted fields of
research are not falsifiable. E.g. the evolution theory cannot be falsified.
Dear Thomas,
I'd like to point out that the research community has largely dismissed Karl
Poppers contribution to the demarcation problem, as largely accepted fields of
research are not falsifiable. E.g. the evolution theory cannot be falsified.
Maybe it is time for you to move on as well?
Kind
Hi Marian,
On 09/12/2019 20:06, Marian Buschsieweke wrote:
Also, a clear and falsifiable problem statement should be given.
could you elaborate on what you mean by a problem statement being falsifiable?
"falsifiable" is a standard principle in science: It is sometimes
difficult to verify
Hi Thomas,
> Also, a clear and falsifiable problem statement should be given.
could you elaborate on what you mean by a problem statement being falsifiable?
Do you want to be able to check that a given problem cannot be solved by
existing features?
> This should IMO address the question, why
Hi,
if this is a "problem statement and design document", then concise and
measurable requirements on power management should go into the
corresponding section.
Also, a clear and falsifiable problem statement should be given. This
should IMO address the question, why timer problems cannot
Hi,
On 12/9/19 4:52 PM, Kaspar Schleiser wrote:
> Hi Robert,
>
> On 12/9/19 4:25 PM, Robert Hartung wrote:
>> 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?
>
> Yes and yes. ;)
>
>
Hi Robert,
On 12/9/19 4:25 PM, Robert Hartung wrote:
> 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?
Yes and yes. ;)
I'll my thoughts so far.
Thanks!
Kaspar
Hi Robert,
On 12/9/19 4:19 PM, Robert Hartung wrote:
> why are 8-bit timers not listed? Intentional or unintentional?
Unintentional!
Kaspar
___
devel mailing list
devel@riot-os.org
https://lists.riot-os.org/mailman/listinfo/devel
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
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
24 matches
Mail list logo
