Re: [riot-devel] Which tests are expected to succeed for my board

[Kaspar Schleiser]

Hi,

On 5/30/20 10:14 PM, Alexandre Abadie wrote:
> You can just put all of them in the same issue. It will be easier to track. 
> That is what is done in [1].

I think we should add this information to compile_and_test.py. Some way
to expect failure for specific tests or board/test combinations, and
report accordingly.

"... FAILED (due to $reason)", and maybe not change return code to
something that's an error.

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

Re: [riot-devel] Release 2020.04

[Kaspar Schleiser]

Hey,

On 4/30/20 1:25 PM, Leandro Lanzieri wrote:
> --- * RIOT 2020.04 * ---

Gratulations everyone! And special thanks to Leandro! ;)

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

Re: [riot-devel] RIOT sprint day

[Kaspar Schleiser]

Hey Martine,

On 3/19/20 11:39 AM, Martine Sophie Lenders wrote:
> So you judge this as a hen and egg then? There is no interest, since not
> many people know about it, so there is no advertisement for it since not
> enough interest was generated.  

Well, I had pitched the idea on maintainers@, and noone but Francisco
replied. We then started the thing, and announced that again at the VMA
[1], with zero feedback. I thought at this point at least every
maintainer is aware of it happening and who to contact if there's
further interest.

> However, IMHO with more advertisement and
> more transparency this could be easily resolved.

Totally, let's just do that. It was the plan anyways. From now on, we'll
send invitations on maintain...@riot-os.org, either a day early or on
Tuesdays in the morning. We'll also start writing up how the workflow
looks like, probably on some wiki page.
There's also the Github Project [2] for anyone interested in watching
the progress.

We've discussed a bit, and came to the conclusion that the format is not
really suitable for non-maintainers. The idea is that people both review
and get reviewed (their PRs that is). So for now, the Sprint Day will be
maintainers only. Everyone else, please come join the monthly Hack'n'Acks!

Happy hacking,
Kaspar
[2] https://github.com/RIOT-OS/RIOT/projects/26
___
devel mailing list
devel@riot-os.org
https://lists.riot-os.org/mailman/listinfo/devel

Re: [riot-devel] RIOT sprint day

[Kaspar Schleiser]

Hi,

On 3/19/20 10:29 AM, Martine Sophie Lenders wrote:
> then why not advertise it more? E.g. by posting the relevant links a day
> ahead to devel?

The interest when first announced was quite limited (basically zero
interest). After the announcement that this is really happening and
feels productive and everyone is welcome (at the VMA), we got zero
feedback. Your mail is the first.

This month's lead is @aabadie, it is his call, but we can surely
announce this again.

We'll need to figure out if / how useful non-maintainers are in this
format, though.

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

Re: [riot-devel] RIOT sprint day

[Kaspar Schleiser]

Hi Martine,

On 3/18/20 3:43 PM, Martine Sophie Lenders wrote:
> apparently the RIOT sprint days proposed a while back are already
> happening. I'd like to have some transparency: when are they happening
> and how are they organized (incl. how can one join / can anybody join)?

They are currently happening every Tuesday.
We're usually adding PR's to the project beforehand.
On Sprint Days, we have a short Visio at usually 10:30, then start
hacking using a somewhat defined workflow including moving PR's around
in the project and chatting in a Mastodon instance. We finish up with a
short debrief Visio around 5pm.

Everyone can join! Everyone is welcome.

So far they have been quite effective, as in, the current Sprinters are
running out of interesting PRs of themselves, and we've started
reviewing "external" PRs.

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

[riot-devel] anyone using the eZ430 chronos?

[Kaspar Schleiser]

Hey fellow RIOTers,

is anyone using TI's chronos with RIOT?

We're in the process of updating the msp430 toolchain. The chronos has
quite some special cases, and I'd like to avoid having to deal with them.

I suspect that noone is actually using the chronos port anyways...
If you do, please shout out now!

Kaspar

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

Re: [riot-devel] Release 2020.01

[Kaspar Schleiser]

Hi,

On 2/3/20 10:02 PM, Francois-Xavier Molina wrote:
> We are happy to announce the 22nd official release of RIOT:

Congrats everyone!

Awesome job managing the release, Francisco!

Kaspar
___
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

[Kaspar Schleiser]

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 you got it right. In ztimer, the clocks' now() value will
overflow after 32bits.

E.g., `t1 = now(); t2 = now(); assert(t1 < t2)` might fail.

Setting timer values is always relative (target = now() + X), and X can
be any 32bit value, the user does not need to handle any overflow there.

> Over the years my experience is that it's no good idea to burden the
> user with the knowledge of timer overflow. The latest example was a
> bunch of HPE SSDs that stop working after 32.768 hours (a little less
> than 4 years). Bad when you have several of them in a RAID for
> redundancy :-)

Failing after 32768h strongly points to using a signed 16bit variable
for the hours count. That's an odd choice to begin with.

> https://www.techradar.com/news/hpe-ssd-drives-could-fail-at-this-critical-moment
> So I'd vote for the (small) additional overhead, even on 8-bit µCs due
> to safety reasons. Unless the implementation can produce the correct
> timer representation with, say, C-preprocessor magic at compile-time.

You mean, you'd vote for all timer values to be always 64bit? I don't
think the overhead is small enough to justify that, but that needs to be
evaluated.
The increased CPU usage needs benchmarks, in RAM we can estimate easily.

IMO, users should just not use these timer values as timestamps.
That maybe needs to be stated at a prominent place (or multiple) in the
documentation.
For that, we can (should?) re-introduce a 64bit API in ztimer.

It might make sense to add a (very large or possibly randomized)
constant offset to all 32bit timers, maybe limited to development
builds, that causes the timer value to overflow early(er), so
applications would break early in tests.

Kaspar

___
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

[Kaspar Schleiser]

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 

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

[Kaspar Schleiser]

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 an easy to use, efficient and flexible timer system that
>> allows precise high-frequency (microsecond scale) timings *alongside*
>> low-power timers.
>>
>> For example, an application might include a driver requiring
>> high-frequency (microsecond scale) timings, but at the same time needs
>> to run on batteries and thus needs to make use of low-power timers
>> that can wake up the device from deep sleep.
>>
> 
> I fully agree that this currently is a problem and it needs to be resolved.
> But what this statement essentially points out, is that the xtimer API
> either misses
> an instance parameter to be used on different low level timers or that it
> misses the functionality to internally handle multiple low level timers
> to multiplex
> timeouts to the (different) available hardware instances to fulfill
> low-power and high precision sleep requirements.

Agreed.

Adding the instance parameter is not trivial. The implementation needs
to provide the underlying functionality. xtimer currently doesn't allow
that. Much of it needs to be rewritten.

Handling this internally is IMO not feasible for reasons I will point
out later.

> The problem statement implies nothing related to the rest of the high
> level timer API and design at all.
> Thus, it is not a problem statement that shows ztimer is our only option.
> 
> *efficient*
> -in which dimensions? Do we favor small RAM, ROM, CPU overhead?
> -how do we prefer this to scale if more or less timers are used?
> -does it make sense to decide for only one of these things at all? (one
> implementation may not suit everyone)
> -just thinking: would it hurt to have one memory efficient
> implementation and one that is "bigger, but faster"?
> 
> *flexible*
> -in level of manual control it provides?
> -in level of automatic functionality and abstraction it provides?
> 
> *precision (& accuracy)*
> -the bounds are defined by the hardware.
> -the question is how do we come as close as possible to the capabilities
> the HW provides.
> -where do we need trade-offs?
> 
> *low-power*
> -dependencies are mostly defined by the hardware
> -How do we model these dependencies?
> -for our power management we try to do things implicit.
>     -how does this work together with a timer that needs to be called
> with explicit instances?
>     -why should the timer API differ from that principle?
> 
> 
> The following general questions pop up:
> -What does the hardware provide that is abstracted by this high level
> timer?
> -How much abstraction do we need?
> -Where do we need trade-offs?
> -How do we balance them?
> -Based on what information?
> 
> Please don't get me wrong, I'm not in principle for or against xtimer,
> ztimer (or even wtimer, the whatever timer;)
> Yes, 64 bit time intuitively doesn't sound like a perfect fit for the
> IoT, but how does this translate to numbers (also different scenarios)?
> Yes, xtimer is broken. Yes, it needs fixing or replacement.
> *But: the functional problems related to xtimer are not related to it's
> API, it is the implementation!*
> 
> 
>> General requirements:
>> - very efficient timers for use in time-critical drivers
> 
> This statement touches memory, runtime overhead and precision, but isn't
> precise on how to balance between them.

These are all very valid questions.

IMO, coming up with definite answers is quite difficult, unless we move
towards defining bounds.

(Assuming xtimer would be stable / reliable), performance wise, it is
*in the acceptable range* on RAM, ROM, cycle use. We have not yet seen
an application that was in any way limited by it, apart from someone
trying to use it for bit banging with the sub-10-us timings, which as I
described in another mail is (probably) just not doable with a callback
based high level timer.

With "acceptable range" I mean that any implementation that is in the
same ballpark (+- maybe 20%) would be acceptable (if it provides the
necessary functionality). The difference would just don't matter in
practice. Smaller and faster aabsolutely becomes a *nice to have*
compared to the *musts* of reliability, accuracy, low-power friendlyness
and the general possibility to be usable for a high percentage of our
applications.

For (RAM, ROM, CPU) performance, I'd not ditch xtimer. It performs
alright (if it works).

Maybe we can agree that xtimer's performance tradeoffs so far have not
shown to be wrong.

>> easy-to-use interface (unified interface)
> 
> Very much a matter of taste, but also what is the importance of "unified"?
> If there are two completely distinct use-cases (requirements) why
> enforce unified API for that?

With "unified" I actually mean something that xtimer already does: no
matter the 

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

[Kaspar Schleiser]

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 hardware dictates the maximum precision.

I wrote a test (its in tests/ztimer_overhead in the ztimer PR), that
sets a timer, which in its callback gets the current time, and then
calculates the differenve.

Uncorrected (with XTIMER_OVERHEAD=0 or the ztimer equivalent), both add
a pretty constant ~7us, on an nrf52dk using a periph timer clocked at
1MHz. There's not much happening in this simplest case. I don't think we
can carve off much in any high level timer implementation, compared to
using periph_timer or even skipping that and using plain register writes.

Callback based (high-level) timers are only suitable for timeouts down
to a certain level (somewhere below 10us on our hardware scope). Below
that, context switching takes the bulk of the time, so spinning (not
using a callback) is probably preferable.
I mean, if a device can do 100k context switches per second, each takes
10us. Setting a timer to anything below that might work, but doesn't
make much sense.

Even ztimer using only 32bit arithmetic vs. xtimer sometimes needing
64bit comparisons might show measurable differences when there are many
timers active, but I honestly don't know if this difference can become a
deal breaker, or even just relevant.

Cycle wise, xtimer is not terrible to begin with.

That said, if we get an alternative that matches or improves on most
metrics and is still more flexible, and allows proper sleeping, then I
take any percent improvement with a happy face.

> Regarding
> memory we have probably different requirements: ROM for the whole thing, RAM
> per instance and for the module itself.
> 

Here, the requirement should be "needs to fulfill all other
requirements", and from that point on, less is better.
xtimer and ztimer are comparable in ROM and RAM usage. Again, I don't
think that any high level timer implementation can bring disruptive
reduction here.

I'm not looking forward to coming up with requirements for accuracy.
Simple tests (like the overhead test from above) are easy to optimize so
a timer hits bang on the target time, by subtracting a measured overhead
from any interval. Figuring out the impact of having N timers in the
list is difficult, and more difficult to correct.

Here we could come up with a test setting as many timers as fit in RAM
to random values, then measuring each timer's punctuality. All making
sure that the target times don't overlap.

But all the requirements don't help over the fact that xtimer currently
just doesn't work for many identified use cases. Fixing that would
require substantial code changes, probably including API changes.
Knowning the complexity of xtimer, I decided to give a rewrite from
scratch a try, and IMO, the result is quite nice.

I'd maybe roll up the discussion from a different side: If noone can
identify a conceptual flaw, something where a different implementation
or design might yield benefits compared to ztimer, and if ztimer does
not show regressions compared to xtimer, but improves on some relevant
aspects, why don't we consider going with better in the short term and
pursue provably best as a longer term goal?

>>> Besides I'm missing a requirement regarding the maximum granularity and the
>>> maximum duration of a timer.
>>
>> You mean minimum granularity?
> 
> In my understanding of the term maximum granularity translates to the finest
> granularity.

Yup, got it.

Kaspar
___
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

[Kaspar Schleiser]

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 just
added a clarification on "adaptable to varying configurations of timers,
RTTs, RTCs (use RTC if available for super-long-time timers)", trying to
convey later on that xtimer just doesn't fulfill this requirement, and
"fixing" that involves changing most of it.

> 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 would that look like?
Something like "must not incur more than x us overhead on hardware of
class y"?

> Besides I'm missing a requirement regarding the maximum granularity and the
> maximum duration of a timer.

You mean minimum granularity?

Anyway, good point. xtimer has 64bit range with 1us precision. ztimer
makes the trade-off of only offering 32bit range, but with flexible
precision. I'm not sure we can get away with that, if just for the fact
that we have code using the 64bit functions, which means automatic code
conversion using coccinelle is not (easily) possible.

I think I'll just implement a 64bit version (as an extra module) so a
possible transition gets easier. And to checkbox "any precision possible
(if hardware keeps up), 64bit range supported".

Kaspar
___
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

[Kaspar Schleiser]

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. ;)
> 
> I'll my thoughts so far.

I've added this to the wiki page:

# Power management considerations
- currently, ztimer is pm_layered agnostic. If a timer is set on a
periph_timer, this would probably not prevent sleep (timer would not
trigger), whereas if a ztimer is set on a rtt, it would behave as
expected (timer hardware keeps running in sleep, timer isr wakes up MCU).

- (TODO) if a timeout has been set (e.g., `ztimer_set(clock, timeout)`),
the backend device blocks sleeping if necessary. IMO this is the minimum
requirement, but still needs to be implemented.

- Idea: we specify that by convention, ZTIMER_MSEC (and ZTIMER_SEC)
*keep running in sleep mode*, whereas ZTIMER_USEC stops when the MCU
enters sleep (unless a timeout is scheduled). This is current behaviour
*if* ZTIMER_USEC is using periph_timer as backend and ZTIMER_MSEC is
using RTT/RTC.

  This would mean that `before = ztimer_now(clock); do something; diff =
ztimer_now(clock) - before;` only works if either `do_something` does
not schedule away the thread causing sleep *or* a clock is used that
runs in sleep mode.

- the behaviour could be accessible either through defines
(ZTIMER_USEC_LPM_MODE or ZTIMER_USEC_DEEPSLEEP ...), *or* be made part
of the ztimer API

- in addition, we could add functions to explicitly tell the clocks to
stay available until released, e.g., `ztimer_acquire(clock); before =
ztimer_now(clock); do something; diff = ztimer_now(clock) - before;
ztimer_release(clock);`.
  Once the "if timer is scheduled, don't sleep" is implemented, this
could also be worked around by:
`ztimer_set(clock, dummy, 0x); ...; ztimer_cancel(clock,
dummy);`


Feedback appreciated!

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

Re: [riot-devel] How to deal with lost interrupts?

[Kaspar Schleiser]

Hi,

On 12/9/19 5:02 PM, José Ignacio Alamos wrote:
> No, I wouldn't consider those lost interrupts (because messages are
> lost, not IRQs).

Ok, thanks for clarifying!

Kaspar
___
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

[Kaspar Schleiser]

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
___
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

[Kaspar Schleiser]

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

Re: [riot-devel] How to deal with lost interrupts?

[Kaspar Schleiser]

Hey Jose,

On 12/9/19 3:46 PM, José Ignacio Alamos wrote:
> The main question here is, how should we handle lost interrupts in
> general? Let's say:

What do you mean by "lost interrupt"?

GNRC uses messages to pass an ISR from the interrupt handler to
"userspace". Those can be lost. Are you referring to that?

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

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

[Kaspar Schleiser]

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

[riot-devel] Question about expected timer semantics

[Kaspar Schleiser]

Hi everyone,

I think everyone agrees that if a relative timer is set, it is expected
to run *at least* the amount of time that is specified as interval to
timer_set().

That means if now() is e.g., 0 ticks and the timer is set to wait 1
tick, the timer must trigger at 2 ticks, as even if now()==0, the actual
("real") time is anywhere between ticks 0 and 1.
If ticks where 1ms each and now_us() is actually 999 (one us before
now()==1), triggering at now(1) would trigger only 1us later and not
1ms. Thus it needs to trigger at 2 ticks (2ms), in order to have the
timer wait "at least 1ms". Correct so far?

Now for the case where a 1ms timer is using a 1us timer as backend.
If a 1ms timer is set at now_ms()==0 and now_us()=500 to trigger after
1ms, it would be possible to trigger the timer at now_ms()==1 and
now_us()==1500, thus at a "half_tick" of now_ms(). Should that be done,
or should the conversion be implemented in a way that the 1ms timer
behaves the same regardless of the lower timer having 1ms or 1us precision?

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

Re: [riot-devel] [riot-users] Release 2019.10

[Kaspar Schleiser]

Congrats everyone!!

And special thanks to Ken!

Kaspar

On 10/31/19 2:38 PM, Martine Lenders wrote:
> Woohoo! Congratulations to everyone and thanks Ken for the great work!
> 
> Best regards,
> Martine
> 
> Am Do., 31. Okt. 2019 um 14:29 Uhr schrieb Emmanuel Baccelli
> mailto:emmanuel.bacce...@inria.fr>>:
> 
> Yay! Congrats to all involved, and thanks a bunch Ken for managing
> this release!
> Cheers
> Emmanuel
> 
> On Thu, Oct 31, 2019 at 2:17 PM Ken Bannister  > wrote:
> 
> Dear RIOTers,
> 
> We are happy to announce the 21st official release of RIOT:
> 
> --- * RIOT 2019.10 * ---
> 
> The 2019.10 release includes:
> 
>   - initial support for SUIT firmware updates
>   - USB CDC-ACM serial communication
>   - complete rewrite of TI CC110x radio driver
>   - initial support for IPv6 fragmentation
>   - DTLS support in the sock networking stack
>   - complete blockwise messaging for gcoap and nanocoap
>   - as always, bug fixes and documentation updates
> 
> About 460 pull requests, composed of 950 commits, have been
> merged since the
> last release, and about 60 issues have been solved. 57 people
> contributed with
> code in 105 days. Approximately 2000 files have been touched
> with 129000
> insertions and 25000 deletions.
> 
> You can download the RIOT release from Github by cloning the
> repository
> and checkout the release tag [1] or by downloading the tarball
> [2], and
> look up the release notes for further details [3].
> 
> A big thank you to everybody who contributed! Special thanks to
> previous
> release managers @miri64, @MrKevinWeiss, and @PeterKietzmann for
> offline
> advice. Many thanks also to release testers @aabadie, @cladmi,
> @fjmolinas,
> @jia200x, @leandrolanzieri, and @smlng.
> 
> Your friendly neighborhood release manager,
> Ken Bannister
> 
> 
> [1] https://github.com/RIOT-OS/RIOT/tree/2019.10
> 
> [2] https://github.com/RIOT-OS/RIOT/archive/2019.10.tar.gz
> 
> [3] https://github.com/RIOT-OS/RIOT/releases/tag/2019.10
> 
> ___
> devel mailing list
> devel@riot-os.org 
> https://lists.riot-os.org/mailman/listinfo/devel
> 
> ___
> users mailing list
> us...@riot-os.org 
> https://lists.riot-os.org/mailman/listinfo/users
> 
> 
> ___
> 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] Notification: Hack'n'ACK @ Tue Oct 29, 2019 5pm - 10pm (CET) (RIOT Events)

[Kaspar Schleiser]

Hi,

we're all set in Berlin. Join us at https://meet.jit.si/riot-hacknack!

Kaspar

On 10/28/19 5:00 PM, Google Calendar wrote:
> more details »
> 
> 
> 
>   Hack'n'ACK
> 
> /When/
>   Tue Oct 29, 2019 5pm – 10pm Central European Time - Berlin
> /Where/
>   FU Berlin; HAW Hamburg(map
> )
> /Calendar/
>   RIOT Events
> /Who/
>   
> • 
> Martine Lenders- creator
> 
> https://meet.jit.si/riot-hacknack
> 
> 
> Invitation from Google Calendar 
> 
> You are receiving this email at the account peterschme...@gmail.com
> because you are subscribed for notifications on calendar RIOT Events.
> 
> To stop receiving these emails, please log in to
> https://www.google.com/calendar/ and change your notification settings
> for this calendar.
> 
> Forwarding this invitation could allow any recipient to send a response
> to the organizer and be added to the guest list, or invite others
> regardless of their own invitation status, or to modify your RSVP. Learn
> More .
> 
> 
> ___
> 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] Notification: Hack'n'ACK @ Tue Oct 29, 2019 5pm - 10pm (CET) (RIOT Events)

[Kaspar Schleiser]

Hey,

On 10/28/19 5:00 PM, Google Calendar wrote:
>   Hack'n'ACK
> 
> /When/
>   Tue Oct 29, 2019 5pm – 10pm Central European Time - Berlin

Don't they start at 3pm now?

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

Re: [riot-devel] RIOT OS and Raspberry Pi 3

[Kaspar Schleiser]

Hi Milica,

On 10/21/19 11:14 AM, Milica Lekic wrote:
> Does RIOT OS support installation on Raspberry Pi3? In a way like I
> installed RIOT OS on Linux PC. As I found out it does not but I am not
> sure. 

Running RIOT directly on the Pi3 SoC is currently not possible.
You can, however, run the RIOT native port within Linux in the Pi3.

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

Re: [riot-devel] SmartFusion2 Port: Timer

[Kaspar Schleiser]

Hi Gideon,

On 6/5/19 12:46 PM,  wrote:
> Dear List,
> 
> In an effort to port RIOT to SmartFusion2 (goto BACKGROUND at the bottom
> for interest), we've hit a small stumbling block. The dedicated hardware
> timer is extremely basic and does not have any CCP (capture/compare)
> channels. It's is a simple down counter with an overflow interrupt.

Can the start or reload value be set, and the current counter value be read?

If yes, this sounds much like the Cortex-M systick timer.
It should be possible to emulate a one-CCP counting timer.

When no callback is set, now() is "MAX_VALUE - current_value", and the
overflow interrupt is ignored.

If a callback is set, the timer gets (re-)set with the timeout as start
value, and the callback is executed on overflow, where the start value
then gets reset to MAX_VALUE.
Also, the time when the callback gets configured is stored somewhere and
then incorporated into now().

This will be difficult to implement without losing a tick here and
there, but might be acceptable.

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

Re: [riot-devel] Lightweight Syslog Implementation

[Kaspar Schleiser]

Hi,

On 5/29/19 11:57 AM, Juan Ignacio Carrano wrote:
> IPC/message queue backend.

RIOT's message queues are a poor choice for this, as they can only send
pointers around. That means the calling thread needs to allocate memory
for the log message and keep that valid until the message has been
processed, which means that it has to block. Or, the calling thread
allocates and the logd thread frees, which again requires allocations.

Better use a synchronised ringbuffer or pipe or tsrb.

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

Re: [riot-devel] Lightweight Syslog Implementation

[Kaspar Schleiser]

Hi Robin,

On 5/23/19 2:09 PM, Robin wrote:
> First and most important is the
> question if this feature is still of interest for the RIOT community? It
> was originally mentioned in a feature request back in 2015[2] and may be
> obsolete by this time. 

IMO the syslog API itself should not be used for new or RIOT-targeting
applications. Having it available makes porting existing code easier,
thus I still think it is valid to have it available.

Having the syslog-over-udp functionality available is pretty awesome,
especially if it could be hooked up to the existing LOG_* framework.
Have you tried that?

> - Should the syslog implementation be included into an existing logging
> API?

See above. There's an example log backend in sys/log/log_printfnoformat
showing how to create a logging backend module. It should be straigh
forward to use syslog there.

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

Re: [riot-devel] Ethos global wired address

[Kaspar Schleiser]

Hi Ashim,

On 5/21/19 12:44 PM, Ashim Asharaph wrote:
> I am using ethos for a project I have. The computer needs to communicate
> with a samr21-xpro. The board needs to have a global address so that I
> can reach it. I have tried to adapt the gnrc_border_router example but I
> see only the wireless interface has a global address. 

That shouldn't matter for global reachablility via the wireless'
address. If you cannot reach the samr21 from outside, something is
wrong. Packets arriving at the ethos interface with the wireless'
address as destination should arrive correctly, so should outgoing packets.

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

Re: [riot-devel] Release 2019.04

[Kaspar Schleiser]

Hey everyone,

On 4/29/19 4:01 PM, Daniel Petry wrote:
> we are happy to announce the 19th official release of RIOT:

congratulations and big thanks to everyone involved!

Special thanks to Dan. Good job managing the release and I'm sorry to
see you leave!

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

Re: [riot-devel] RIOT Support for STM32WB with Nucleo Board

[Kaspar Schleiser]

Hi Warren,

On 3/26/19 10:22 AM, Warren Bilgeri wrote:
> Are there any plans to support the STM32WB with RIOT?
> I have used RIOT on other STM32 devices and would like to use RIOT on
> the STM32WB - the STM32WB is targeted at IOT applications.

I started adding STM32WB support in [1].

The cpu part of the port is based on STM32F4. When I got to the clock
configuration, I realized that the WB55 is probably more alike to the L4
line. Anyhow, I stopped at that point. So don't expect anything to
compile or even make sense conceptionally.

Feel free to take over. ;)

Kaspar
[1] https://github.com/kaspar030/RIOT/tree/add_stm32wb55xx
___
devel mailing list
devel@riot-os.org
https://lists.riot-os.org/mailman/listinfo/devel

Re: [riot-devel] just got my Vega

[Kaspar Schleiser]

Hi,

On 2/12/19 2:01 PM, Joakim Nohlgård wrote:
> There is a tracking issue for porting
> at https://github.com/RIOT-OS/RIOT/issues/10575

I feel two months late. Thanks!

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

[riot-devel] just got my Vega

[Kaspar Schleiser]

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

Re: [riot-devel] Location for module specific compile configurations

[Kaspar Schleiser]

Hi,

On 1/31/19 3:31 PM, Gaëtan Harter wrote:
> One solution, which does not match the current way of doing in RIOT.
> Is to use Make declarative syntax and  define your configurations using
> deferred evaluation
> 
> CFLAGS += $(if $(filter something,$(USEMODULE)), -DIF_NUM=3)
> 
> This would make CFLAGS have the correct value when `USEMODULE` is
> resolved. There may be cases where it does not work directly though.

How about adding this somewhere:

CFLAGS += $(foreach module,$(USEMODULE), $(CFLAGS.$(module)))

Then add

CFLAGS.something += -DIF_NUM=3

to the CPU's Makefile.include.

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

Re: [riot-devel] PhyNode connecting to Raspberry Pi

[Kaspar Schleiser]

Hi Anna,

it is quite cumbersome at the moment, especially considering that the
current Raspbian kernel is broken.

May I suggest @smlng's Wiki pages [1]? AFAIK They contain up-to-date
information on how to set up the RasPi side.

Once that is set up, compiling and flashing e.g.,
"examples/gnrc_networking" onto the phynode should be a starting point.
When typing "ifconfig" in RIOT's shell, it should show an IP address
picked up from the RasPi, and pinging between them should work.

Kaspar

[1]
https://github.com/RIOT-Makers/wpan-raspbian/wiki/Create-a-generic-Raspbian-image-with-6LoWPAN-support

On 1/21/19 12:22 PM, Aïcha Diack wrote:
> Hi Emmanuel,
> 
> Thank you so much for your quick answer. The Module [2] is the one I
> already have on my Pi. But how to get to communicate with this module
> from the PhyNode Board?
> Regards 
> Anna
> 
>> Am 21.01.2019 um 09:39 schrieb Emmanuel Baccelli
>> mailto:emmanuel.bacce...@inria.fr>>:
>>
>> Hi Anna,
>>
>> if I am not mistaken,  your PhyNode is communicating via a IEEE
>> 802.15.4 radio transceiver.
>> So for your raspberryPi to be able to communicate with it, you need to
>> add a IEEE 802.15.4 transceiver to your  Pi as described in [1], for
>> instance with an Openlab module  [2].
>>
>> Emmanuel
>>
>>
>> [1] 
>> https://github.com/RIOT-OS/RIOT/wiki/How-to-install-6LoWPAN-Linux-Kernel-on-Raspberry-Pi#raspberrypi-with-openlabs-raspberry-pi-802154-radio
>> [2] https://openlabs.co/OSHW/Raspberry-Pi-802.15.4-radio
>>
>>
>> On Mon, Jan 21, 2019 at 9:14 AM Aïcha Diack
>> > > wrote:
>>
>> Dear Developers,
>>
>> My question is about the connecting possibilities with the PhyNode
>> Board Kw 2x. I found it on your list and I was able to flash the
>> board with Riot os. Now my problem is to connect it to my
>> raspberryPi3 which has an raspberry pi radio modul. I need the
>> Accelerometer values on my raspberry to work with them.
>> I would be really happy if someone could give me a hint of which
>> code I need or how I can realize my project.
>>
>> Sincerely
>> Anna
>> ___
>> 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
> 
> 
> ___
> 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] sched_active_thread is a volatile pointer, but volatile is ignored

[Kaspar Schleiser]

Hi Kees,

On 1/7/19 9:19 PM, Kees Bakker wrote:
> My main concern is: who made it volatile in the first place?

I did, almost a decade ago.

> And what was the reasoning behind it? Volatile is one of the least
> understood properties of the C language (my personal opinion). I'm
> hoping that the volatile was not just thrown in because it feels good
> when doing threads. And in other places the volatile is ignored,
> hopefully for a good reason (optimisation is _not_ a good reason).
IIRC the intention was so the IPC code would create read / write
accesses whenever accessing fields of thread_t.

E.g.:

void msg_recv(...)
{
   if (!sched_active_thread->waiters) {
// platform specific macro to suspend thread
   }

   thread_t *waiter = sched_active_thread->waiters;

   // ...
}

(or similar)

My understanding of volatile back then was that the compiler could,
without volatile, assume that sched_active_thread->waiters equals NULL.

This was certainly a case of only (at most) half-understanding volatile,
which then turned into "if it is not broken, don't fix it".

Nowadays such code is always guarded with disabled IRQs.

I seem to remember that we tried making sched_active_thread non-volatile
at some point, breaking things, but that has also been a long time ago.

I'm all for removing the qualifier. But we do have to make sure to
thoroughly test core/ on all platforms.

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

Re: [riot-devel] Eliminating casts

[Kaspar Schleiser]

Hi,

On 12/26/18 11:16 PM, Kees Bakker wrote:
> Suppose I make a Pull Request to eliminate casts, would that be picked up?

Always welcome! +1 on Joakim's hint to keep the PR's small.

> void at86rf2xx_tx_exec(const at86rf2xx_t *dev)
> {
>     netdev_t *netdev = (netdev_t *)dev;

What would be the way to go here? 'netdev_t netdev = >netdev;'?

In this case, it won't work. Would need to recurse into
netdev_ieee802154_t, like 'netdev_t *netdev = >netdev.netdev;'.

That might be less error.prone, but more confusing. Unfortunately C is
not much help here.

> Casts
> * Try to avoid casts (a bit vague, but it should get people's attention)
> * Introduce helper variables to avoid multiple casts within a function
> * Don't cast a const pointer into a non-const pointer without an
> explanation in a comment.
> * Don't cast a pointer to a volatile object dropping the volatile
> without an
> explanation in a comment.
> * ...

* use dereferenced superclass field instead of "blind" cast

(the netdev case above).

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

Re: [riot-devel] Compute the time elapsed when switching between two threads

[Kaspar Schleiser]

Hi Julien,

On 11/21/18 11:31 AM, Julien Gomez wrote:
> Indeed, using external equipment like an oscillograph was the first
> thing I did. 
> 
> But I am looking to compute the context switching time only with software. 
> 
> 
> I am pretty sure I will have to tweak the kernel to get such
> measurements  And even doing so, I will not have the closest value to
> the real elapsed time.

How exact do you expect the value to be?

As you've already realized, the benchmarks in tests/bench_* measure the
number of context switches within one second, for threads of the same
priority. (Actually, it counts double context switches.)

For the IPC tests, the priority of the threads doesn't matter, you
should be able to change them. But that should also not really change
the results.

You can easily calculate the time taken by one context switch.

On real MCUs, these numbers are fairly constant, and the overhead of the
actual test is minimal, so the results should be within a very low
single digit percentage of the actual time.

A less portable improvement would be to set up a periph timer with
maximum (e.g,, MCU) frequency. Then take the current timer value,
trigger a context switch (e.g., through "time_sleep()"), and in the
other thread, again as first thing take the timer value. That way you'd
get almost cycle-perfect context switch time measurements.

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

[riot-devel] 20000 commits!

[Kaspar Schleiser]

Hey fellow RIOTers,

master has just grown past 2 commits!

And in other news, RIOT is about to cross the 200 contributors mark.

Keep up the good work everyone,
Kaspar
___
devel mailing list
devel@riot-os.org
https://lists.riot-os.org/mailman/listinfo/devel

Re: [riot-devel] Unit test code coverage using gcov

[Kaspar Schleiser]

Hey Toon,

On 10/9/18 4:16 PM, STEGEN Toon wrote:
> Has anybody succeeded in getting gcov to work to check code coverage of
> the unit tests?

I managed to get gprof working at some point. AFAIR they're using the
same infrastructure (PC sampling, saving it somewhere, then dumping the
file) as gcov.

gcc's "-pg" needs library support. For that I have a branch [1].
It is quite old, but maybe it helps.

Kaspar
[1] https://github.com/kaspar030/RIOT/tree/add_gcov_support
___
devel mailing list
devel@riot-os.org
https://lists.riot-os.org/mailman/listinfo/devel

Re: [riot-devel] Benchmarking of Real-Time Operating Systems for Internet of Things Devices

[Kaspar Schleiser]

Hi Julien,

On 9/25/18 6:13 PM, Julien Gomez wrote:
> We'd love to hear your recommandations or any help you can provide us with.

For RIOT, compile with "LTO=1" and "DEVELHELP=0" set in the Makefile. ;)

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

[riot-devel] CI news

[Kaspar Schleiser]

Hey everyone,

thanks to Martine we now have a nice new view for our nightly builds:

https://ci.riot-os.org/nightlies.html

There are many more improvements to Murdock and the accompanying
scripts, but they're under the hood and thus more or less invisible. But
they'll allow for more nice features and visual improvements in the future.

Thanks Martine!

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

Re: [riot-devel] Proposal for sys folder

[Kaspar Schleiser]

Hi,

On 8/29/18 11:13 AM, Jose wrote:
> 1. Move the `net` folder to the RIOTBASE folder (`sys/net` -> `sys`):
>    This is consistent with our documentation, generates less folder
>    depth, makes refactoring easier. The Linux kernel does exactly the
>    same [2].
> 2. Add a `lib` folder in the RIOTBASE:
>     1. Move cryptos, serializers, parsers, math, etc. to this `lib` folder.
>     2. Keep RIOT sys related stuff in the `sys` folder. This could be,
>    for instance, stuff in direct communication with the RIOT kernel
>    and layers interacting with periphs (auto_init, xtimer, power
>    management, maybe file systems).

+1!

Would it make sense to then move core, drivers, sys, net, lib, boards,
cpu into src/?
Is there something sensible like "hw" where we could put cpu, boards,
drivers?
Should periph and netdev move to sys?

For network I find it a little difficult. IMO some parts are more
sys/net, others are more lib/net. Eg., everything that sits on top of
sock (and is stack independent) could be considered "library code".

Kaspar
___
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

[Kaspar Schleiser]

Hi Robert,

On 8/27/18 3:37 PM, Robert Hartung wrote:
> 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.

There's another layer: the application.

board.h should define hard-wired stuff (LEDs, stuff that is actually
hard-defined by the board). periph_conf.h contains a (default)
"peripheral configuration" that an application might want to (and almost
always does) override.

One problem is that much here is not entirely clear. E.g., some Nucleos
have an LED on an also exposed IO pin, or boards can be run with both
internal and external OSC, or SAMR21-XPRO have an integrated at86rf233
hard-wired to an SPI, so all "boards" using that CPU should configure
that SPI if but only if that RF chip is used by the application.

Also, some stuff is actually difficult to express nicely with C.

Usually for every piece of configuration, you'll find arguments to move
it somewhere else. But usually, the next place is just a different
trade-off.

Currently, we're trying for uniformity and consistency, so as soon as a
location is determined, it is at least the same for all boards.

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

Re: [riot-devel] Where to put board pictures?

[Kaspar Schleiser]

He,

On 8/21/18 11:28 AM, Jose wrote:
> I personally think 2. (put them in the RIOT wiki) is the fastest way to
> go and doesn't bloat the RIOT repository. But I would like to hear some
> comments about this topic.

+1. Don't forget, the Wiki is a git repo, too.

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

Re: [riot-devel] Driver AT, what is the concept of process_urc

[Kaspar Schleiser]

He Kees,

On 08/05/2018 01:20 PM, Kees Bakker wrote:
> First of all, who is the maintainer of driver_at? In other words,
> who should I be asking questions about this driver?

As I'm the original author, I'd consider myself the author, but Vincent
has contributed a lot. Asking on this mailing list was probably the best.
Sorry for the delayed answer.

> Is somebody using the AT driver? Is somebody using the URC facility?
I'm using the driver in a production device, but without URC.

I'm sure URC can be improved. I was thinking whether we can write a UART
RX handler that can be switched to line-mode when needed (compared to
bytewise handling), and then hook URC handling in there.

I think we're all not entirely clear on how URC's are supposed to work
in general, and if modems actually behave as expected. Most
documentation states that URC cannot occur while a command is handled.
When does that "handling" start? after sending the newline
(AT), or maybe after receiving AT?

Could someone with a modem on the desk try, e.g, does "RING" arrive
after typing "AT"?

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

Re: [riot-devel] size_t vs int usage

[Kaspar Schleiser]

Hi Neil,

On 06/27/2018 03:03 PM, Neil Jones wrote:
> IIRC size_t is unsigned so the error is correct, how did this code get
> upstream, and how come no one else is getting this error ?

I suppose the toolchain is compiled with different default warning flags.

> I presume the fact that this PR add SPI support for MIPS(PIC32) these
> drivers are now getting built for MIPS, but how is this not a failure
> on other architectures ?
> 
> Should I fix these in this PR or create another one ?

Usually another PR (or even multiples) are preferable. Trivial one-line
PR's are usually merged *very* quickly. :)

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

Re: [riot-devel] Scheduler: Supporting Cooperative Threading

[Kaspar Schleiser]

Hi Juan,

On 06/13/2018 10:27 AM, Juan Ignacio Carrano wrote:
>>> Coroutines make it possible to program asynchronous code in a
>>> blocking style - see "await". This is more natural and easier that
>>> using callbacks.
>> How does it compare to sending / receiving messages?
>>
> 
> Using messages is OK, but not everything is built that way. Even code
> which uses a separate thread that processes messages must use locks.
> 
> Messages require some decoding logic if one is expecting messages from
> many senders. I'm thinking of a loop in which one waits for messages and
> acts according to the type: what would conceptually be multiple threads
> gets squashed into a single chunk of code.

How about we discuss this on actual code? Can you come up with a (maybe
hypothetical) piece of code, and we see what would be the best way to
express it in RIOT, or if more API would help?

Kaspar

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

[riot-devel] PIC programmer with Linux support?

[Kaspar Schleiser]

Hey fellow RIOTers,

I'm looking for a readily available PIC programmer with Linux support.

Main requirements are:


- can flash the boards that RIOT supports
- has a CLI application that runs on Linux (both x86 and ARM/RasPi)
(- not too expensive)

Any suggestions?

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

[riot-devel] Release 2018.04

[Kaspar Schleiser]

Dear RIOTers,

we are happy to announce the 15th official release of RIOT:

--- * RIOT 2018.0 * ---
The 2018.04 release includes major progress in support for current
crypto libraries. A lot of work has gone into updating drivers to RIOT's
unified configuration scheme. Support for ten new boards has been added.
In our quest to improve and automate testing, many test scripts have
been fixed and improved, and RIOT's CI now runs many tests on real
hardware during its nightly build testing. And as usual, many tiny fixes
and improvements have been merged.

About 390 pull requests with about 1073 commits have been merged since
the last release and about 54 issues have been solved. 44 people
contributed with code in 98 days. Approximately 1491 files have been
touched with 208426 insertions.

You can download the RIOT release from Github by cloning the repository
and checkout the release tag [1] or by downloading the tarball [2], and
look up the release notes for further details [3].

Many thanks to all of you contributing in so many different ways to make
RIOT worthwhile!

Kaspar

[0]: https://github.com/RIOT-OS/RIOT/blob/master/CODE_OF_CONDUCT.md
[1]: https://github.com/RIOT-OS/RIOT/tree/2018.04
[2]: https://github.com/RIOT-OS/RIOT/archive/2018.04.tar.gz
[3]: https://github.com/RIOT-OS/RIOT/releases/tag/2018.04
___
devel mailing list
devel@riot-os.org
https://lists.riot-os.org/mailman/listinfo/devel

[riot-devel] Release 2018.04 feature freeze

[Kaspar Schleiser]

Dear fellow RIOTers,

I've branched off the 2018.04 release branch, and we're now officially
in feature freeze. That means from now on only bug fixes will be merged
into 2018.04-branch.

There are 12 open issues tagged for the release [1]. I hope we'll be
able to resolve most of them in the next couple of days.
@maintainers, your help on those issues is greatly appreciated!

Happy hacking,
Kaspar

[1] https://github.com/RIOT-OS/RIOT/milestone/22




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

Re: [riot-devel] License check for vendor specific MIT license

[Kaspar Schleiser]

Hi Gunar,

On 04/12/2018 01:09 PM, Gunar Schorcht wrote:
> What is the right way to add a new license test pattern in
> dist/tools/licenses/patterns? As usual PR or is there any other
> procedure for that?

Yes, a PR is the prefered procedure.

Regards,
Kaspar


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

Re: [riot-devel] Porting RIOT to ESP8266

[Kaspar Schleiser]

Hi,

On 04/16/2018 01:56 PM, Emmanuel Baccelli wrote:
> FYI at FOSDEM this year, one of the most frequent question we got was
> "when will RIOT be ported to ESP32"?

It actually was the second most asked question, only bested by "does
RIOT work on ESP8266?".

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

Re: [riot-devel] Release 2018.04 planning

[Kaspar Schleiser]

Hey all,

On 03/06/2018 11:35 AM, Kaspar Schleiser wrote:
> - final feature freeze will be two weeks later, on the 16.04.2018

just a quick reminder: the last week before feature freeze just started!

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

Re: [riot-devel] ESP8266 Port and Networking

[Kaspar Schleiser]

Hi,

On 03/24/2018 07:33 PM, Gunar Schorcht wrote:
> Therefore, my question is, what is the best way to realize networking on
> a new platform that doesn't have 802.15.4 radio but full TCP/IP stack
> and WiFi on board?

I suggest implementing netdev on top of the WiFi layer 2 of the ESP,
treating it as ethernet.

In the beginning you could use the esp API to configure the WiFi (SSID,
pwd, ...), down the line there should be netdev get/set options for that.

Going this route, you can use the esp's wifi, ignore its integrated IP
stack and make all RIOT networking features work. It would allow other
RIOT applications to be easily ported.

Cheers,
Kaspar







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

[riot-devel] Release 2018.04 planning

[Kaspar Schleiser]

Hey fellow RIOTers,

here are the dates for release 2018.04:

- feature freeze for high impact features will be on the 02.04.2018
- final feature freeze will be two weeks later, on the 16.04.2018
- final release date will be once all tests run through successfully

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

[riot-devel] Timers

[Kaspar Schleiser]

Hi all,

I guess it is time to coordinate improving RIOT's timers - again.

IMO xtimer is a dead end. It was designed with good intentions, but
unfortunately with not much real-world experience. It has also
(d)evolved into a complex and inflexible #ifdef-mess...

Here's what I think is bad about it:

- it allows only one type of base timer. On most platforms it tries to
use one 1MHz periph/timer. there are PR's and hacks to make it use e.g.,
32KHz RTTs or low power timers, but they didn't make it to master. The
API basically enforces 1us ticks, and mapping unchanged code bases to
very different timers is just too error prone. Also, the API would
require choosing at compile time, which is just too inflexible.

- xtimer still doesn't support pm

- by forcing 1us time, xtimer also requires 64bit time functions in
order to support > 2**32us (~71min) timeouts

- xtimer is not ISR safe (xtimer_now() with <16bit base timers can break)

- xtimer_t is quite large (20b on 32bit platforms)

- xtimer's code has become very complex due to us/tick conversion and
the many #ifdefs that grew into it

Here's what I propose:

- re-write from scratch

- in the API, allow "instances", e.g.:

timer_now(instance);
timer_set(instance, timer_object);

where an "instance" provides state and function pointers.

- implement backends for periph/timer, rtt, rtc, lptim, systick, whatever

- provide global instance aliases that every board provides, e.g.,
"TIMER_USEC", "TIMER_MSEC", "TIMER_SEC". Map those to available timer
backends. Make it possible to enable / disable them as needed.

- allow application specific timers to use the same API (e.g., allow
setting up a very high speed timer, which can be used alongside
"default" timers)

- provide stackable "converters"
  e.g., if there's no MSEC resolution low power timer that can be mapped
to "TIMER_MSEC", use "TIMER_USEC", but transparently convert all values
  or if periph/timer doesn't support 32bit, create a "timer instance"
that transparently handles the extension.
  Maybe stack those (e.g., if the rtt backend only supports 1024hz and
16bit, stack a 1024 to 1000 converter on that, stack a 16bit to 32bit on
that and map the result to "TIMER_MSEC".
 this would lead to re-usable components that can also be individually
tested (think unittests using a software-controlled fake timer).

- provide either clear convention (e.g., TIMER_USEC stops when sleeping,
unless a timer using it is set, TIMER_MSEC keeps running in low power
mode) or controlling API (e.g., "timer_block_sleep(TIMER_USEC)" for
behaviour in sleep modes

- try to slim down the timer struct (if possible)

- drop the 64bit API (usec resolution over 64bit range is unrealistic on
real hardware. if, for larger ranges, TIMER_MSEC or TIMER_SEC can be
used, the range that 64bit provides is not needed anymore. thus all the
expensive 64bit arithmetic can be dropped)

- consider new insights like the clock domain issue fixed by [1]

- obviously, avoid long-standing xtimer bugs like the ISR unsafeness

The main point I would like to push is the introduction of "timer
instances", which would basically make the timer interface object
oriented. This would allow having multiple implementations with
different tradeoffs without changing actual application code.

What do you think?

Kaspar

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

Re: [riot-devel] Pull request for RISCV

[Kaspar Schleiser]

Hi JP,

On 01/13/2018 01:12 AM, JP wrote:
> So I've asked some questions in the PR but receive few answers and it 
> usually takes weeks for an answer.  Should I be asking in the PR or 
> here?  In any case here's some questions.

I'll answer in the PR.

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

Re: [riot-devel] Updates to the build system - modules definition

[Kaspar Schleiser]

Hi,

On 11/30/2017 04:32 PM, Gaëtan Harter wrote:
>   1. Configuration is not documented
>   2. Information is not readable
>   3. Modules definition is scattered but in RIOT global files

> With these issues in mind, I propose to add parseable module meta-data
> definitions in a file in each module directory to first replace the
> existing information and then extend it to add more precise ones.
> How to do in practice it is still to be defined and discussed.

When are you gonna take a look at my ninja-based build system? It solves
1-3 quite nicely, and more. You could save a lot of time.

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

Re: [riot-devel] 6lowpan Host with SLAAC, minimum ram footprint

[Kaspar Schleiser]

Hi Josua,

On 11/30/2017 04:17 PM, Arndt, Josua wrote:
> I have ported Riot OS to the atmega256rfr2 and the gnrc_network example
> works as expected.
> 
> Now I want to reduce the RAM  footprint to a minimum would need some
> advice how to proceed.

I have a branch in [1] that tries to disable as much as possible in
order to make tests/minimal smaller. Most of it won't be of much use as
you're using gnrc, but maybe you find some inspiration.

Some ideas:

- reduce the number of allowed threads and priority levels to exactly
what you need
- disable all stdio (see also [2])
- compile with LTO=1

Kaspar

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

Re: [riot-devel] Updates to the build system - modules definition

[Kaspar Schleiser]

Hi Dan,

On 11/29/2017 02:33 PM, Daniel Petry wrote:
> 1. The current build system isn't suitable to support the front end for
> RAPstore that Hendrik developed for his bachelor thesis, which requires
> that certain information can be displayed to the users.

I hear about this for the first time. Are there any pointers?

> 2. The current build system doesn't allow developers to easily include
> modules in their applications

USEMODULE += module_name?

> built can be affected by files/code outside the module directory
>   2.1 API changes as a result of including other modules aren't
> immediately visible in that module
>   2.2 API changes on other modules as a result of including that module
> isn't immediately visible
>   2.3 The complete build information for a module isn't localised only in
> the module directory

If modules are interdependent, they will affect each other. How can a
different module definition help here?

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

Re: [riot-devel] Release 2017.10

[Kaspar Schleiser]

Hey all,

On 10/27/2017 12:37 PM, Hauke Petersen wrote:
> we are happy to announce the 13th official release of RIOT:

Congratulations and many thanks to everyone involved!

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

Re: [riot-devel] rtc alarm running with threads

[Kaspar Schleiser]

Hi Paula,

on which platform are you running your application?

Kaspar

On 10/20/2017 09:45 PM, Paula Ortega Cancino wrote:
> Hi Oleg,
> 
> Thanks for your help. I should mention that i'm working on the 2017.07
> release. This is the main functions of the code, the behavor i'm
> expecting is to trigger the alarm every TIME_WAITING seconds, run
> sale_test() and the go back to the control thread. However i get a
> kernel panic or run only the control_thread, without considering the
> rtc_alarm after a while.
> 
> char stack[THREAD_STACKSIZE_DEFAULT];
> kernel_pid_t control_pid;
> 
> int sale_test(void){
>     DEBUG("Send sale\n");
>     return 1;
> }
> 
> /* set interrupt event every TIME_WAITING  = 10 seconds*/
> static void onInterruptEvent(void *arg)
> {
>     (void)arg;
>     struct tm time;
>     rtc_get_alarm();
> 
>     /* schedule next message */
>     time.tm_sec  += TIME_WAITING;
>     /* Make an interrupt */
>     sale_test();
> 
>     rtc_clear_alarm();
>     rtc_set_alarm(, onInterruptEvent, 0);
> }
> 
> void *control_thread(void *arg)
> {
>     (void) arg;
>     while (1) {
>   DEBUG("Running thread right now\n");
>   xtimer_usleep(10);
>     }
>     return NULL;
> }
> 
> int main(void)
> {
>     printf("This test will display 'Alarm every %i seconds'\n",
> TIME_WAITING);
> 
>     /* initialize rtc functions */
>     application_init();
> 
>     onInterruptEvent(NULL);
> 
>     control_pid = thread_create(stack, sizeof(stack),
>     THREAD_PRIORITY_MAIN - 1, THREAD_CREATE_STACKTEST,
>     control_thread, NULL, "control");
>     (void) control_pid;
> 
>     return 0;
> }
> 
> Cheers,
> Paula
> 
> 2017-10-19 14:41 GMT-03:00 Oleg Hahm  >:
> 
> Dear Paula,
> 
> can you share the code of your application somewhere? That might
> help to find
> the issues. I would suppose that the interrupt handler is faulty or
> consumes
> too much memory or something like this.
> 
> I think start debugging with a basic application that just prints
> some text
> whenever a message from the RTC interrupt is received is a smart
> idea. Now, we
> need to figure out what exactly triggers the kernel panic. Are you
> compiling
> your application with the DEVELHELP macro enabled? And which port
> are you
> using? Maybe you can use `make debug` to get more information.
> 
> Cheers,
> Oleg
> --
> /* Fuck, we are miserable poor guys... */
>         linux-2.6.6/net/xfrm/xfrm_algo.c
> 
> ___
> 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
> 
___
devel mailing list
devel@riot-os.org
https://lists.riot-os.org/mailman/listinfo/devel

Re: [riot-devel] Ethernet communication initialization.

[Kaspar Schleiser]

Hi Subhasis,

On 10/16/2017 01:04 PM, SUBHASIS MAITY cs16m055 wrote:
> By the way how the flag is used. I mean to ask where the flag will be used? 
> I can't find the use of the value of DGNRC_NETIF_NUMOF in any file.

Look for GNRC_NETIF_NUMOF (without D).

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

Re: [riot-devel] Ethernet communication initialization.

[Kaspar Schleiser]

Hi Subhasis,

On 10/16/2017 11:32 AM, SUBHASIS MAITY cs16m055 wrote:
> When I try to run with module enc28j60 driever and cc2538_rf drivers,
> only wired interface is detected on ifconfig. Can you specify why is
> that happening.

Might be that gnrc is configured to only use one network interface.

Try adding

CFLAGS += -DGNRC_NETIF_NUMOF=2

to your application's Makefile.

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

Re: [riot-devel] Graphing build sizes

[Kaspar Schleiser]

Hi,

On 10/13/2017 09:53 AM, Hauke Petersen wrote:
> Thinking out loud: would it make sense to do some data aggregation for
> more generic views? On first thought I would imagine something like
> average ROM/RAM size over all application/examples over all platforms.

Yes! The data should already be there (in the parsed sizes.json). Maybe
an "all" selector for both application and board would do it?

> I also have an idea for code size diff visualization, that I have in my
> mind for quite a while: how about we draw a (huge) table, using all
> available platforms as columns and all available applications as rows.
> Each cell would then be colored: [...]
> 
> What do you think about this idea, and how would you assess the doability?

Well, that table would be *huge* (~100 * 150 cells). We could make a
bitmap with mouse-over.

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

Re: [riot-devel] Graphing build sizes

[Kaspar Schleiser]

Hi Koen,

(your mail's quoting arrived a little garbled, I'll try my best to fix)

On 10/12/2017 03:02 PM, Koen wrote:
> At that point it might be easier to integrate
> this work into the CI to trigger it after such a build.

Probably! There's already infrastructure to run arbitrary scripts after
each build, which is also used to actually parse out sizes.json.

See [1].

Probably a simple http(s) request using wget would do it?

> [1] http://docs.grafana.org/reference/annotations/

[2] pretty much shows our use-case. ;)

Kaspar

[1] https://github.com/grafana/grafana/issues/1588



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

Re: [riot-devel] Graphing build sizes

[Kaspar Schleiser]

Hey Koen,

On 10/11/2017 04:59 PM, Koen Zandberg wrote:
> For now I want to keep it up to date by running my script as a cron
> every night approximately after the nightly build.

If we'd build the in-between HEAD commits, would your script pick them up?

> The dashboard is now a simple Grafana templated dashboard where a test
> and a board can be selected. I'd like to expand this by creating a
> dashboard for every test or for every board. The most difficult thing
> for now is to present the huge amount of data in a clear and concise
> way. Input on this and the overview in general is most welcome.

Is it possible to put the commit hash into each step? If I move my mouse
over a graph, each point shows a pop-up with the timestamp. It would be
very useful to see which commit that belongs too. Maybe even with a link
to the PR page on github?

Kaspar



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

Re: [riot-devel] Commercial products based of RIOT

[Kaspar Schleiser]

Hi Samir,

one product that's in development is the Sleeping Beauty [1], a GPS
tracking device with an integrated GSM modem.

Kaspar

[1] https://sleeping-beauty.kontrollfeld.com

On 10/11/2017 10:05 AM, SKS wrote:
> Dear All
> 
> 
> I am doing a literature survey on the commercial applicability of RIOT rtos.
> Can you please help me with some relevant pointers on Commercial
> products which are based of RIOT rtos ?
> 
> Thanks and regards 
> Samir 
> 
> 
> 
> ___
> 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] On the State of RIOT's IEEE 802.15.4 Support

[Kaspar Schleiser]

Hi Joakim,

On 09/20/2017 10:11 AM, Joakim Nohlgård wrote:
> I have recently been digging around the gnrc_netdev code as well. I
> think that adding support for other frame types and logic for sending
> these frames will definitely become a mess if the 802.15.4 code is not
> decoupled from the netdev code.

Could you elaborate why? We should aim to get as much as possible
gnrc-independent code.

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

Re: [riot-devel] On the State of RIOT's IEEE 802.15.4 Support

[Kaspar Schleiser]

Hi Thomas,

On 09/17/2017 11:37 PM, Thomas Eichinger wrote:
> tl;dr: Do we see the need to be IEEE 802.15.4 compliant?

Thanks for bringing this up.

The answer is pretty simple: Yes, of course!

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

Re: [riot-devel] pm_reboot

[Kaspar Schleiser]

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

Re: [riot-devel] pm_reboot

[Kaspar Schleiser]

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

Re: [riot-devel] Discussion of Power Management

[Kaspar Schleiser]

Hi,

On 08/31/2017 05:13 PM, Robert Hartung wrote:
>> 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))
> ?

Ah, yes.

> 
> 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"?
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?

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

Re: [riot-devel] Discussion of Power Management

[Kaspar Schleiser]

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.

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...)

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

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

Re: [riot-devel] Discussion of Power Management

[Kaspar Schleiser]

Hi Robert,

(I'll CC the list, this may be interesting to others)

On 08/31/2017 03:52 PM, Robert Hartung wrote:
> The main problem is that it is NOT sufficient to provide pm_layered and
> periph_pm. As the various CPUs provide different implementations.

Actually, that is sufficient.

> The various defines look something like this:
> 
> cpu/saml21: cpu/cortexm_common, cpu/sam0_common
>   defines pm_set()
> 
> cpu/samd21: cpu/cortexm_common, cpu/sam0_common
>   defines pm_set()
> 
> boards/mulle: cpu/k60
> 
> cpu/k60: cpu/cortexm_common, cpu/kinetis_common
> 
> cpu/cortexm_common:
>   defines pm_set(), pm_set_lowest(), pm_reboot()
> 
> cpu/kinetis_common:
>   defines pm_set()

All of them who define pm_set() support pm_layered.
cortexm_common just provides a fallback for pm_set_lowest() which at
least sets the ARM CPU into idle.

> These are only two examples of conflicts. The question here would be why
> do we have multiple "common" CPUs and where should the sleep modes be
> implemented?

The common cpus are nested, e.g., k60 -> kinetis_common -> cortexm_common.

This is how I envision it:

- if a CPU has a proper pm_set(), it depends on pm_layered
- if not, possibly e.g., kinetis_common has pm_set(), then that should
depend on 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)
- if the cpu (or any common ancestor) has it's own way of power
management, it implements pm_set_lowest()
- if not, it depends on periph_pm_fallback (which should wrap current
drivers/periph_common/pm.c)

That should cover all cases, right?

> I guess I could just remove the periph/pm.c from kinetis_common?

Yes! kinetis_common should use the cortexm_fallback, they're equivalent.

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

Re: [riot-devel] Mailserver issues

[Kaspar Schleiser]

Hi Michael,

On 08/14/2017 06:36 PM, Michael Andersen wrote:
> Lambda is actually pretty flexible. 
> [...]
> So yeah, totally agree that you need caching, but actually it does that,
> they just don't advertise it much.

Ok, that makes it a lot more attractive. How would we deal with the
needed software? RIOT's CI container currently contains ~1.5g of
toolchains. That can be split by architecture, though. Would that have
to be part of the 500mb context as well?

Kaspar

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

Re: [riot-devel] Mailserver issues

[Kaspar Schleiser]

Hi Michael,

On 08/11/2017 08:26 PM, Michael Andersen wrote:
> Having just done something similar for something else, you should really
> look at doing CI in AWS lambda. It is remarkably cheap and (more
> importantly for my case) requires nearly zero devops once set up. If you
> suddenly have 10x the CI runs, they can all run in parallel for the same
> cost. No queues.

I'm not sure the current RIOT build system requirements match AWS lambda
in order to properly make use of it.

For every build, the current CI sends "build application X for board Y"
as job to a CI queue. With git workdir caching and most of the build
already in ccache, such a job takes between .5 and 2 seconds. Without
those caches, more like 10 to 20 seconds, depending on the time needed
to check out RIOT and to a cold-ccache build. If I understand AWS lambda
correctly, it is not really suitable if that much context information is
needed.

I was looking into using AWS and the google container engine, but
without the caches (e.g., on freshly booted containers/VMs/instances),
they're not very attractive performance wise. Long-running (keeping the
caches in memory, or even using the persistent storage options), they're
not attractive price-wise.

I'd love to be proven wrong! ;)

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

Re: [riot-devel] Mailserver issues

[Kaspar Schleiser]

Hi Adam,

On 08/11/2017 07:14 PM, Adam Hunt wrote:
> What sort of hardware would RIOT need for CI? Would a machine with,
> for example, a pair of E5-2670 (eight cores @ 2.60 GHz), Xeons between
> 64 and 128 GB of DDR3 ECC RAM, an SSD or two, and maybe some spinning
> storage suffice or are we talking about something like a highly
> available cluster consisting of half-dozen or more HP ProLiant DL380
> Gen10 machines each with a pair Xeon 8100s (28 cores @ 3.60 GHz), a
> terabyte of DDR4 RAM, and a pile of blazing fast NVMe drives?

The CI can take advantage of anything with 4g of RAM for the ccache and
another .5g of RAM per core. Long-running is preferable, as the ccache
takes a couple of builds (or a manually triggered full-build) to warm up.

We currently have 2 16-core (Dual Xeon E5-2660/2670), 2 20-core (don't
know which Xeons) and a couple of Quad-Cores. There are also about 20
dual-core VM's on the Inria CI cluster, but they're down at the moment.
See e.g., the bottom of [1] for the relative performance of these boxes.

We decided (inofficially) on a build target time of <5min to be
acceptable, which we're below if the Inria boxes are up. But with every
test or every new supported board, the build matrix grows...

I doubt that setting up quad core boxes are worth the administrative
overhead (which is basically setting up a systemd service keeping a
docker container running), but if you could spare dual 8-core Xeon
boxes, that would be nice. :)

The boxes mostly idle, and as everything runs in RAM, even if a build
starts, e.g. on my quad core workstation, I barely notice the builds.

Kaspar

[1]
https://ci.riot-os.org/RIOT-OS/RIOT/7438/d24e072af26134996ab488d8bf072142fe4618de/output.html
___
devel mailing list
devel@riot-os.org
https://lists.riot-os.org/mailman/listinfo/devel

Re: [riot-devel] edbg build failure in Vagrant VM due to missing libudev-devpackage + problems flashing Atmel samr21-xpro board

[Kaspar Schleiser]

Hey all,

On 05/29/2017 10:21 AM, Adrian Herrmann wrote:
> Attempting to flash with the edbg driver instead of OpenOCD results in
> an error when using the Vagrant VM as building edbg requires the
> libudev-dev package, which is not included in the image and cannot be
> found in the configured package repositories either.

I've never used our Vagrant stuff. How do I change the VM template?
Can maybe someone who knows add the missing package? Maybe @cenk? :)

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

[riot-devel] heads up: new header guard rules

[Kaspar Schleiser]

Hey fellow RIOTers,

we've just merged [1], which will enforce certain rules about the C
header guards. See [2] for more details.

In order to adapt your git tree,

$ dist/tools/headerguards/check.sh

... will show which files might need a header guard fix.
The checker outputs unified diff, which can be piped directly into
"patch -p0".

Cheers,
Kaspar

[1] https://github.com/RIOT-OS/RIOT/pull/7095
[2] https://github.com/RIOT-OS/RIOT/wiki/Coding-conventions#header-guards
___
devel mailing list
devel@riot-os.org
https://lists.riot-os.org/mailman/listinfo/devel

Re: [riot-devel] Support for cc3200

[Kaspar Schleiser]

Hi,

On 05/19/2017 09:10 AM, Martine Lenders wrote:
> __-  __Is it correct that it is only necessary to wirte the
> cc3200_netdev.c-File.
> 
> The CC3200 delivers a full embedded network stack right? If so, I would
> rather suggest to either implement against GNRC's NETAPI [1] or the sock
> API [2], rather than netdev. Though it is the CC3200 network device,
> porting it to the netdev API might lead to problems that API rather
> thought to be used for link-layer networking.

Another possibility would be to stay at the netdev level and only use
the device's L2 capabilities.

For that we probably need some netdev extensions for handling the setup
of a WiFi network (e.g., search for networks, join & set credentials,
...). Apart from that, WiFi behaves very similar to ethernet.

No need to limit this to GNRC, and moreso, no need to go with the vendor
IP stack.

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

[riot-devel] Release 2017.04

[Kaspar Schleiser]

Dear RIOTers,

we are happy to announce the 11th official release of RIOT:

--- * RIOT 2017.04 * ---

This release provides a lot of new features, fixes and enhancements.
Among these has been a huge cleanup regarding cppcheck and
documentation, and we're pleased to announce that all remaining doxygen
and cppcheck warnings have been fixed.
We're also proud to present a Virtual File System layer and integration
of the SPIFFS file system.
A lot of work has gone into support for STMicroelectronics's Nucleo
family, with RIOT now supporting 28 (up from 13) Nucleo boards. And as
always, there was a lot of under-the-hood cleanup, bug fixing and
documentation work.

About 200 pull requests with about 562 commits have been merged since
the last release and about 23 issues have been solved. 32 people
contributed with code in 91 days. 2697 files have been touched with
716950 insertions and 492623 deletions.

You can download the RIOT release from Github by cloning the repository
[1] or by downloading the tarball [2], and look up the release notes for
further details [3].

Thanks everyone for your contributions, discussions, testing efforts,
and keep RIOTing!

Happy hacking,
Kaspar

[1] https://github.com/RIOT-OS/RIOT/releases/tag/2017.04
[2] https://github.com/RIOT-OS/RIOT/archive/2017.04.tar.gz
[3] https://github.com/RIOT-OS/RIOT/blob/2017.04-branch/release-notes.txt
___
devel mailing list
devel@riot-os.org
https://lists.riot-os.org/mailman/listinfo/devel

Re: [riot-devel] coccinelle

[Kaspar Schleiser]

Hi Julia,

On 05/05/2017 08:41 AM, Julia Lawall wrote:
> The following rule finds local variables that are static, but where the
> static property is not used, because the variable is initialized before
> any use.

Thanks! I've added the patch to my coccinelle branch [1].

>  There are only two instances of this problem in RIOT at the
> moment, in code that doesn't look very important, but perhaps the rule
> could be useful in the future, just in case.

Actually half of the static uses actually don't make sense, e.g., using
a static variable within main().

Kaspar
[1] https://github.com/kaspar030/RIOT/tree/add_coccinelle_testing
___
devel mailing list
devel@riot-os.org
https://lists.riot-os.org/mailman/listinfo/devel

Re: [riot-devel] Reorganization of Cortex-M build test MCU groups

[Kaspar Schleiser]

Hey,

On 04/24/2017 10:00 AM, smlng wrote:
>>> It might be that this is equivalent to what we now call "features". ;)
>>
>> A good idea, we could introduce just introduce more features and wire
>> the features_required checks to be available from the command line.
>> `make buildtest TAGS=kinetis`
>> would be very useful while working on periph drivers.
> 
> +1, for the general idea, but lets stick with FEATURE then. 

Makes sense, +1 for using only one variable.

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

Re: [riot-devel] Reorganization of Cortex-M build test MCU groups

[Kaspar Schleiser]

Hey Joakim,

On 04/21/2017 06:46 PM, Joakim Nohlgård wrote:
> I would like to change this split to create groups of boards which are
> likely to fail together to be in the same group. For example, the Nucleo
> boards could be in one or more groups cortexm_nucleo, the SAM boards,
> nrf, and kinetis boards would be suitable candidates for other groups.
> Practically grouping by each xxx_common source directory makes sense in
> my opinion. 

IMO a good idea. And as Sebastian pointed out, the build groups
themselves will be obsolete, soon.

How about introducing tags? The difference being that a board can have
more than one "tag", with some of them possibly defined by the MCU used.

e.g., every nucleo gets "nucleo", "arm" and "cortex-m", but some also
get "cortex-m0" and maybe "lowmem", others get "cortex-m4" and
"hardfloat". You get the idea.

That way we could use our buildtests like:

$ make buildtest TAGS=msp430

or even

$ make buildtest TAGEXPR="cortex-m0 and nucleo"

It might be that this is equivalent to what we now call "features". ;)

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

[riot-devel] 2017.04 feature freeze

[Kaspar Schleiser]

Dear fellow RIOT'ers,

I've just created the 2017.04 branch and tagged the first release
candidate [1], which means we're now in feature freeze.

Theres an issue for tracking the testing progress at [2]. Any help is
highly appreciated!

Best regards,
Kaspar

[1] https://github.com/RIOT-OS/RIOT/tree/2017.04-RC1
[2] https://github.com/RIOT-OS/Release-Specs/issues/42
___
devel mailing list
devel@riot-os.org
https://lists.riot-os.org/mailman/listinfo/devel

Re: [riot-devel] flash command without compiling

[Kaspar Schleiser]

Hey,

On 04/18/2017 10:15 AM, Oleg Hahm wrote:

I remember that (years ago) I thought that this would be a bad idea, but got
overruled.


Probably the newbie friendlyness is to be blamed...

Anyhow, I have a branch for on-hardware CI testing, where I've added 
another flash target that doesn't have the dependency. Find the commit 
here [1].


Kaspar

[1] 
https://github.com/kaspar030/RIOT/commit/c183d152bf36a1e4f2d6ac3ea3b172047dd43eee

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

Re: [riot-devel] flash command without compiling

[Kaspar Schleiser]

Hey,

On 04/17/2017 04:47 PM, Jose Alamos wrote:

I noticed the 'make flash' recompiles everything before flashing. What's
the reason behind this?


Does it actually recompile?

The flash target in Makefile.include depends on the "all" target, 
ensuring that the build is up-to-date. I guess at some point we thought 
that is a good idea.


Removing that dependency stops the forced update.

Kaspar

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

[riot-devel] 2017.04 feature freeze delayed

[Kaspar Schleiser]

Hey RIOT'ers,

due to the easter holidays, the feature freeze will be delayed until
Tuesday.
That means there are three more days for polishing your PR's! ;)

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

Re: [riot-devel] Question about priority inversion mechanism in Riot OS

[Kaspar Schleiser]

Hi Felix,

On 04/11/2017 05:54 PM, Felix Levitre wrote:
> I would like to know if there is a mechanism to avoid priority inversion in 
> Riot OS.

Nope, there's no technical mechanism in place.

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

[riot-devel] Release 2017.4 release planning

[Kaspar Schleiser]

Hey fellow RIOT'ers,

short reminder:

The upcoming release's feature freeze is on April 14th. That means there 
are ten days left to polish your work in progress.


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

Re: [riot-devel] [RIOT][xTimer] Question about xtimer implementation.

[Kaspar Schleiser]

Hi Phuong,

On 04/01/2017 04:40 PM, Minh Phuong Dang wrote:
> The CPU has 32bit timers/counters and it has countdown mode only. When
> the timer reaches zero it generates timer interrupt request to the CPU.
> I reference to another platforms porting which are implemented count up
> timer mode only.

I usually just substract the every actual timer value from e.g.,
"0x". That way the value just gets interpreted as "counting up".

> I do not really understand how does xtimer module work, would you please
> show me how to implement for countdown timer case ?

This needs to be done in your board's periph/timer implementation, thus
it should be independent from xtimer.

Hope this helps!
Kaspar



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

Re: [riot-devel] questions about riot os

[Kaspar Schleiser]

Hi,

On 03/22/2017 12:13 AM, Arjun Hary wrote:
> Is there a plan or a timeline for it? 

Nordic seems to have released its BLE stack for Mynewt under a
compatible license. AFAIK someone is already looking into porting that
to RIOT, but I don't know what's the state there.

Help is very appreciated!

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

Re: [riot-devel] questions about riot os

[Kaspar Schleiser]

Hi Arjun,

On 03/20/2017 05:03 PM, Arjun Hary wrote:
> 1) After adding the softdevice the code size jumped to 46K bytes which
> includes compilation of 6lowpan, ipv6. Is there a way to compile the
> nordic ble linbrary without adding these modules. I tried the
> DISABLE_MODULE macro and though the makefile complained , the code size
> still remained the same. It looks like 6lowpan and ipv6 are required
> modules. How do I change this.

You'll need to remove the corresponding nordic softdevice dependencies
from Makefile.dep. Currently, if you add modules to DISABLE_MODULE, they
get removed *after* dependency resolution. In this case, meta-modules
that are just used for dependency tracking are removed after their
dependencies are added in.

> 2)  Also as a general question, I see that RIOT claims the FLASH size
> usage is around 5K. What features does the 5K include. Does it incude
> pthreads, task switching, synchronization , messaging etc. 

That very much depends. Please take a look at tests/minimal, which
currently compiles to ~2.7k flash for ARM platforms.

5k flash is enough for RIOT's threading, synchronization and messaging.
The pthreads wrapper will not fit, though. Also, newlib's POSIX stdio is
quite large, e.g., a simple printf will pull in ~4k of code on ARM
platforms.

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

Re: [riot-devel] To global seed or not to global seed

[Kaspar Schleiser]

Hey,

On 03/08/2017 10:06 AM, Cenk Gündoğan wrote:
> 
>> How about an interface a la
>>
> Looks good at first sight. We also would need some sort of
> synchronization for concurrent access, e.g. a mutex in the `rnd_t`
> struct, if two threads should use the same local state.

Do we need that kind of synchronization if all state is localized in the
overloaded rnd_t, at that level?

Applications *seeding* the same state in multiple threads will be rare
and can synchronize externally.

Whether "reading" from the rng needs to be synchronized should be up to
the RNG implementation.

Kaspar



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

Re: [riot-devel] To global seed or not to global seed

[Kaspar Schleiser]

Hey,

On 03/08/2017 12:18 AM, Cenk Gündoğan wrote:
> we rather
> should opt to allow local states for each thread (not excluding a global
> state).

Interesting. Up to now our trouble with RNGs was mostly on how to make
them more random. Now we're trying to make them predictable. What's your
use case for that?

How about an interface a la

rand_init_(rnd__t *rnd);
rand_seed32(rnd_t *rnd, uint32_t);
rand_seed(rnd_t *rnd, const uint8_t *in, size_t len);
rand_get(rnd_t *rnd, uint8_t *out, size_t n);
rand_get32(rnd_t *rnd);

typedef struct {

} rnd_t;

typedef struct {
rnd_t rnd;
;
} rnd_tinymt32_t;

That way we'd have:

- user controlled state
- the ability to overload (e.g., combine hwrng, collected entropy, prng
but with the same interface)

Kaspar



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

[riot-devel] Code Quality Task Force

[Kaspar Schleiser]

Hey fellow RIOTers,

our CI currently fails on added files having either doxygen or cppcheck
warnings.

Unfortunately if changed files contain either warning, it cannot
determine whether the warnings are new or have been there.

So I hereby launch the Code Quality Task Force, and declare it's first
task to get rid of all those warnings.

Let's go as follows:

1. move all vendor headers into a clearly recognizable sub directory
containing "/vendor/", for easy exclusion (Hauke will do that)

2. Activate CI failing on all doxygen warnings. We'll do that in #6688.
(Oleg will do that).

3. Pull request (and merge) fixes to #6688 until all warnings are gone
and the PR passes CI, then merge the PR.

4. create a PR similar to #6688, but for cppcheck warnings. Same fixing
procedure.

6. meet up on next RIOT Summit and have a beer together.

Everyone is invited and very welcome to help at any point! :)

@Oleg, do you have numbers on the amount of cppcheck/doxygen warnings we
currently have?

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/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

[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

[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