Re: [riot-devel] RIOT developers monthly meeting

[Thomas Eichinger]

Hi,

I forgot, but was there a particular reason having these on Mondays? 

For me personally it would be easier to tune in any other day of the week. I’m 
just generally asking since my actual RIOT development availability is very 
limited anyways. 

Best, Thomas 

> On Nov 28, 2017, at 4:59 AM, Francisco Javier Acosta Padilla 
>  wrote:
> 
> +1 on my side too.
> 
> -- 
> Francisco Javier Acosta Padilla
> Research Engineer at INRIA Saclay
> INFINE Team
> 
>> On 28 November 2017 at 12:24:00, Alexandre Abadie 
>> (alexandre.aba...@inria.fr) wrote:
>> 
>> Hi,
>> 
>> Hi,
>> 
>> as hinted yesterday, I usually need to go around 5:30pm. So I was wondering 
>> if we can move the meeting to 4pm.
>> 
>> +1
>> 
>> 
>> Cheers,
>> Martine 
>> 
>> 2017-11-27 16:33 GMT+01:00 Francisco Javier Acosta Padilla 
>> :
>>> 
>>> RIOT developers monthly meeting
>>> Scheduled: 27 Nov 2017 17:00 to 18:00
>>> Location: https://zoom.us/j/235153205
>>> Invitees: devel@riot-os.org, Francisco Javier Acosta Padilla
>>> Hi there, 
>>> 
>>> Francisco Acosta is inviting you to a scheduled Zoom meeting. 
>>> 
>>> Join from PC, Mac, Linux, iOS or Android: https://zoom.us/j/235153205
>>> 
>>> Or iPhone one-tap :
>>> US: +16699006833,,235153205#  or +16465588656,,235153205# 
>>> Or Telephone:
>>> Dial(for higher quality, dial a number based on your current location)：
>>> US: +1 669 900 6833  or +1 646 558 8656
>>> Meeting ID: 235 153 205
>>> International numbers available: 
>>> https://zoom.us/zoomconference?m=3QuTkS0wteDtL_3pyOjFM0KBPZ_220mB
>>> 
>>> 
>>> -- 
>>> Francisco Javier Acosta Padilla
>>> Research Engineer at INRIA Saclay
>>> INFINE Team
>>> 
>>> ___
>>> 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
___
devel mailing list
devel@riot-os.org
https://lists.riot-os.org/mailman/listinfo/devel

Re: [riot-devel] Notification: Hack'n'ACK @ Tue Nov 28, 2017 5pm - 10pm (RIOT Events)

[Martine Lenders]

Hi,
we are now set-up in Berlin for this month's Hack'n'ACK. If you like to
join via PlaceCam [1] feel free to do so at

*http://placecam.de/call.php?c=lmakKMrDG8a35aIBNqLBvOnApExkKFntj9xXawGNgTc-
*

RIOTers with access to the PlaceCam account: remember to remove your
PlaceCam config (located at `.local/share/daviko GmbH/PlaceCam/PlaceCam.ini`
on Linux) before starting PlaceCam, if you are logged in, so we can have an
uninterrupted conference call.

Cheers,
Martine

[1] 
*https://github.com/RIOT-OS/RIOT/wiki/Instructions-for-remote-participation#videoconferencing
*

2017-11-27 16:59 GMT+01:00 Google Calendar :

> more details »
> 
> Hack'n'ACK
>
> *When*
> Tue Nov 28, 2017 5pm – 10pm Berlin
>
> *Where*
> FU Berlin; HAW Hamburg (map
> )
>
> *Calendar*
> RIOT Events
>
> *Who*
> •
> Martine Lenders - creator
>
> 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 modify your RSVP
> response. 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] Plans for switching over to a new network infrastructure in GNRC

[Martine Lenders]

Hi,

yep, there is still some major optimization work required. But the feature
set provided in #7925 is a little bit larger than the previous NDP
implementation was (namely: the UNREACHABLE state as proposed in RFC 7048
is now fully working) + many places that made the old implementation
smaller, were just plain wrong assumptions that were major quality defects
in the old implementation. What is weird though is, that the 6LN
configuration got so much bigger... I would have expected it to be way
smaller :-/. (Also MSP430 [not listed] is unexpectedly large, but I blame
that on the old GCC doing some bad optimization work).

Cheers,
Martine

2017-11-28 15:21 GMT+01:00 Koen Zandberg :

> Hi,
>
> As #7925 was merged yesterday, there is now a nightly build with the
> gnrc_netif code merged. From this I present you the build size differences
> 
> between today (with gnrc_netif) and yesterday (before the merge). Absolute
> numbers on a single application on a single board can be found by pressing
> the relevant diff. Selection of the tests, boards and metric (bss, data and
> text) is at the top of the page.
>
> Some remarks: These are the diffs between the previous and the current
> build size, not absolute numbers. Furthermore, this is a comparison between
> nightlies, not from merge to merge, so all merges from yesterday are
> included in this diff.
>
> Cheers,
> Koen
>
> On 11/01/2017 04:26 PM, Martine Lenders wrote:
>
> Hi,
>
> FYI there is a re-integration PR now: https://github.com/RIOT-
> OS/RIOT/pull/7925
>
> Cheers,
> Martine
>
> 2017-10-27 17:56 GMT+02:00 Martine Lenders :
>
>> Hi all,
>>
>> after the release is before the release, so let's use the drive to
>> continue the good work.
>>
>> Some of you might have noticed, that we are currently working on a big
>> switch-over for GNRC-internal APIs, so if you are not involved in any
>> direct GNRC programming or need access to the network interfaces this won't
>> most likely only affect you a little bit (the calls how to get an interface
>> ID will change -- actually simplify ;-)) to not at all.
>>
>> This is quite a massive step, since basically most of the files that are
>> doing operations on, or related to network interfaces (i.e. IPv6, 6LoWPAN,
>> MAC and routing protocols) need to be touched. In addition we decided to
>> integrate this network interface layer directly with the new, shiny and
>> fixed neighbor discovery which saves us a lot of integration work into old
>> stuff, but doesn't make things easier. Some of that work is already done
>> and in master, but most of it will take some time to adapt.
>>
>> This is why we (the RIOT maintainers) decided to go a slightly different
>> route than usual: we made a feature branch where all the integration work
>> (and testing) for the new components will happen [1] and made a 1-2 week
>> plan to get this branch re-merged into master as fast as possible. In that
>> time this feature branch exist merging new changes to GNRC into master is
>> highly discouraged to not risk merge conflicts in the
>> gnrc_netif2_integration/master branch. We will notify you again when this
>> embargo is lifted.
>>
>> So what changes after all this is done (I call the new interface API
>> gnrc_netif2 here, but in the final result it will be called just
>> gnrc_netif):
>>
>> * Network interfaces:
>> - Simplification of GNRC's network interface architecture: currently
>> there are 4 APIs (gnrc_netdev, gnrc_netif, gnrc_ipv6_netif, and
>> gnrc_sixlowpan_netif) that represent network interfaces in some kind or
>> form. This makes things complicated if you need e.g. in NDP information
>> that is both device dependent (e.g. link-layer address) and IPv6 dependent
>> (e.g. IPv6 address). This is why gnrc_netif2 merges all these APIs into one
>> single API.
>> - Tighter integration into GNRC's principles: For most device related
>> options interfaces worked like any other GNRC module and used NETAPI, but
>> when it came to other stuff, like IPv6 addresses or 6LoWPAN configuration,
>> other APIs were used. With gnrc_netif2 all options can be set via NETAPI.
>> - Better thread synchronization: apart from the the fact that
>> GNRC-externally the options are now set over NETOPT (i.e. in the thread
>> context of the interface) we also use recursive mutexes GNRC-internally now
>> to better synchronize the access to the interface. In the previous
>> implementation normal mutexes were used (requiring some dangerous unlocking
>> in the middle of an operation) or no mutexes were used at all.
>> - Easier to extend: If you want to provide a new MAC protocol to GNRC
>> 

Re: [riot-devel] Plans for switching over to a new network infrastructure in GNRC

[Koen Zandberg]

Hi,

As #7925 was merged yesterday, there is now a nightly build with the
gnrc_netif code merged. From this I present you the build size
differences

between today (with gnrc_netif) and yesterday (before the merge).
Absolute numbers on a single application on a single board can be found
by pressing the relevant diff. Selection of the tests, boards and metric
(bss, data and text) is at the top of the page.

Some remarks: These are the diffs between the previous and the current
build size, not absolute numbers. Furthermore, this is a comparison
between nightlies, not from merge to merge, so all merges from yesterday
are included in this diff.

Cheers,
Koen


On 11/01/2017 04:26 PM, Martine Lenders wrote:
> Hi,
>
> FYI there is a re-integration PR
> now: https://github.com/RIOT-OS/RIOT/pull/7925
>
> Cheers,
> Martine
>
> 2017-10-27 17:56 GMT+02:00 Martine Lenders  >:
>
> Hi all,
>
> after the release is before the release, so let's use the drive to
> continue the good work.
>
> Some of you might have noticed, that we are currently working on a
> big switch-over for GNRC-internal APIs, so if you are not involved
> in any direct GNRC programming or need access to the network
> interfaces this won't most likely only affect you a little bit
> (the calls how to get an interface ID will change -- actually
> simplify ;-)) to not at all.
>
> This is quite a massive step, since basically most of the files
> that are doing operations on, or related to network interfaces
> (i.e. IPv6, 6LoWPAN, MAC and routing protocols) need to be
> touched. In addition we decided to integrate this network
> interface layer directly with the new, shiny and fixed neighbor
> discovery which saves us a lot of integration work into old stuff,
> but doesn't make things easier. Some of that work is already done
> and in master, but most of it will take some time to adapt.
>
> This is why we (the RIOT maintainers) decided to go a slightly
> different route than usual: we made a feature branch where all the
> integration work (and testing) for the new components will happen
> [1] and made a 1-2 week plan to get this branch re-merged into
> master as fast as possible. In that time this feature branch exist
> merging new changes to GNRC into master is highly discouraged to
> not risk merge conflicts in the gnrc_netif2_integration/master
> branch. We will notify you again when this embargo is lifted.
>
> So what changes after all this is done (I call the new interface
> API gnrc_netif2 here, but in the final result it will be called
> just gnrc_netif):
>
> * Network interfaces:
>     - Simplification of GNRC's network interface architecture:
> currently there are 4 APIs (gnrc_netdev, gnrc_netif,
> gnrc_ipv6_netif, and gnrc_sixlowpan_netif) that represent network
> interfaces in some kind or form. This makes things complicated if
> you need e.g. in NDP information that is both device dependent
> (e.g. link-layer address) and IPv6 dependent (e.g. IPv6 address).
> This is why gnrc_netif2 merges all these APIs into one single API.
>     - Tighter integration into GNRC's principles: For most device
> related options interfaces worked like any other GNRC module and
> used NETAPI, but when it came to other stuff, like IPv6 addresses
> or 6LoWPAN configuration, other APIs were used. With gnrc_netif2
> all options can be set via NETAPI.
>     - Better thread synchronization: apart from the the fact that
> GNRC-externally the options are now set over NETOPT (i.e. in the
> thread context of the interface) we also use recursive mutexes
> GNRC-internally now to better synchronize the access to the
> interface. In the previous implementation normal mutexes were used
> (requiring some dangerous unlocking in the middle of an operation)
> or no mutexes were used at all.
>     - Easier to extend: If you want to provide a new MAC protocol
> to GNRC you don't have to copy all the thread-handler stuff
> anymore. Just implement the operations provided in
> `gnrc_netif2_ops_t` and let gnrc_netif2 do the rest ;-).
> * new neighbor discovery:
>     - In comparison to the old neighbor discovery the new was
> designed more thoughtfully so it easier to maintain.
>     - Most issues with the old neighbor discovery were fixed
> (because with the new design we actually were able to pinpoint
> issues within minutes, not within days as with the old NDP)
>     - For the 

Re: [riot-devel] RIOT developers monthly meeting

[Francisco Javier Acosta Padilla]

+1 on my side too.

-- 
Francisco Javier Acosta Padilla
Research Engineer at INRIA Saclay
INFINE Team

On 28 November 2017 at 12:24:00, Alexandre Abadie (alexandre.aba...@inria.fr) 
wrote:

Hi,

Hi,

as hinted yesterday, I usually need to go around 5:30pm. So I was wondering if 
we can move the meeting to 4pm.

+1


Cheers,
Martine 

2017-11-27 16:33 GMT+01:00 Francisco Javier Acosta Padilla 
:

RIOT developers monthly meeting
Scheduled: 27 Nov 2017 17:00 to 18:00
Location: https://zoom.us/j/235153205
Invitees: devel@riot-os.org, Francisco Javier Acosta Padilla
Hi there, 

Francisco Acosta is inviting you to a scheduled Zoom meeting. 

Join from PC, Mac, Linux, iOS or Android: https://zoom.us/j/235153205

Or iPhone one-tap :
    US: +16699006833,,235153205#  or +16465588656,,235153205# 
Or Telephone:
    Dial(for higher quality, dial a number based on your current location)：
        US: +1 669 900 6833  or +1 646 558 8656
    Meeting ID: 235 153 205
    International numbers available: 
https://zoom.us/zoomconference?m=3QuTkS0wteDtL_3pyOjFM0KBPZ_220mB


-- 
Francisco Javier Acosta Padilla
Research Engineer at INRIA Saclay
INFINE Team

___
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] RIOT developers monthly meeting

[Alexandre Abadie]

Hi, 

- Mail original -

> Hi,

> as hinted yesterday, I usually need to go around 5:30pm. So I was wondering
> if we can move the meeting to 4pm.

+1 

> Cheers,
> Martine

> 2017-11-27 16:33 GMT+01:00 Francisco Javier Acosta Padilla <
> francisco.aco...@inria.fr > :

> > RIOT developers monthly meeting
> 
> > Scheduled: 27 Nov 2017 17:00 to 18:00
> 
> > Location: https://zoom.us/j/235153205
> 
> > Invitees: devel@riot-os.org , Francisco Javier Acosta Padilla
> 
> > Hi there,
> 

> > Francisco Acosta is inviting you to a scheduled Zoom meeting.
> 

> > Join from PC, Mac, Linux, iOS or Android: https://zoom.us/j/235153205
> 

> > Or iPhone one-tap :
> 
> > US: +16699006833 ,,235153205# or +16465588656 ,,235153205#
> 
> > Or Telephone:
> 
> > Dial(for higher quality, dial a number based on your current location)：
> 
> > US: +1 669 900 6833 or +1 646 558 8656
> 
> > Meeting ID: 235 153 205
> 
> > International numbers available:
> > https://zoom.us/zoomconference?m=3QuTkS0wteDtL_3pyOjFM0KBPZ_220mB
> 

> > --
> 
> > Francisco Javier Acosta Padilla
> 
> > Research Engineer at INRIA Saclay
> 
> > INFINE Team
> 

> > ___
> 
> > 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] RIOT developers monthly meeting

[Martine Lenders]

Hi,

as hinted yesterday, I usually need to go around 5:30pm. So I was wondering
if we can move the meeting to 4pm.

Cheers,
Martine

2017-11-27 16:33 GMT+01:00 Francisco Javier Acosta Padilla <
francisco.aco...@inria.fr>:

>
> RIOT developers monthly meeting
> Scheduled: 27 Nov 2017 17:00 to 18:00
> Location: https://zoom.us/j/235153205
> Invitees: devel@riot-os.org, Francisco Javier Acosta Padilla
> Hi there,
>
> Francisco Acosta is inviting you to a scheduled Zoom meeting.
>
> Join from PC, Mac, Linux, iOS or Android: https://zoom.us/j/235153205
>
> Or iPhone one-tap :
> US: +16699006833 <(669)%20900-6833>,,235153205#  or +16465588656
> <(646)%20558-8656>,,235153205#
> Or Telephone:
> Dial(for higher quality, dial a number based on your current location)：
> US: +1 669 900 6833 <(669)%20900-6833>  or +1 646 558 8656
> <(646)%20558-8656>
> Meeting ID: 235 153 205
> International numbers available: https://zoom.us/zoomconference?m=
> 3QuTkS0wteDtL_3pyOjFM0KBPZ_220mB
>
>
> --
> Francisco Javier Acosta Padilla
> Research Engineer at INRIA Saclay
> INFINE Team
>
> ___
> 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] HIL testing

[Peter Kietzmann]

Hi Hauke,

thanks for you efforts! This is great and really useful work. IMO it is
the right direction, even though I always hoped to find a way around
implementing our own I2C slave device. That's why I wanted to take this
opportunity to ask around for other experiences with I2C (slave) test
devices. Anyone, anything?

Best
Peter

Am 27.11.2017 um 18:33 schrieb Hauke Petersen:
> Hi everyone,
> 
> in today's developer meeting the discussion passed by the topic of HIL
> testing once again, this time in the context of the upcoming re-modeling
> of the I2C interface. Some weeks ago I had an idea for a simple HIL
> setup for automatically testing perihp/i2c drivers, and I promised to
> share it (although it is in very very early state). So here it is.
> 
> So the basic idea is to connect the I2C pins of the 'board-under-test'
> (i2c master for now) to a 2nd board (lets call it 'test peer'), running
> a fully controllable software i2c slave implementation. On the
> device-under-test we simply run the 'tests/periph_i2c' app, that lets us
> control the I2C master using shell commands (init/read/write incl
> parameters). On the 'test peer' we run a programmable soft i2c client,
> that offers shell commands expressing expectations, e.g. "expect 4 byter
> [abcd] written to addr 0x23".
> 
> Now for creating an automated I2C test-suite, I imagine something
> similar to our existing pyexpect scripts (testrunner), just with the
> added capability of handling two clients. So the test script could look
> something like this (mostly pseudocode...):
> 
> `PORT=/dev/ttyACM0 TESTPEER=/dev/ttyACM1 make hil-test`
> 
> triggers:
> 
> ```python
> ...
> def testfunc(testie, peer):
>     ...
>    # tell the 'test peer' to expect something to be written to addr 0x23
> and respond with a NACK
>     peer.sendline("expect_addr 0x23")
>    # write a random byte the addr 0x23
>     testie.sendline("w 0x23 a")
>     # the 'test peer' will tell if it sees the expected address
>     peer.expect("[SUCCESS]")
>     # the 'device-under-test' should recognize the NACK
>     testie.expect("error: no device with that address found on bus")
> 
>     # test writing (expect 4 bytes [affe] written to address 0x42)
>     peer.sendline("expect_write 0x42 a f f e")
>     testie.sendline("w 0x42 a f f e")
>     peer.expect("[SUCCESS]")
>     testie.expect("I2C_DEV(0): successfully wrote 4 bytes to the bus\n")
> 
>    ...
>     # many many more test cases here, including simulation of badly
> behaving slaves and bus recovery...
> ```
> 
> I have sketched a I2C slave implementation to run on the 'test peer' in
> [1] (under `tests/softi2ccli`). It is in no means production code, but a
> quick prove of concept. But IMHO this would be a very easy and straight
> forward way to have an automatic test-suite that would work on someones
> desk for now.
> 
> Integration into the bigger picture would hopefully be easy doable, but
> this not in the scope of this particular proposal here...
> For now my goal would simply be to build a test suite for assisting with
> the upcoming I2C remodeling to get some hands-on experience and speed up
> the testing efforts for that task.
> 
> Cheers,
> Hauke
> 
> [1] https://github.com/haukepetersen/RIOT/tree/add_softi2cli
> ___
> devel mailing list
> devel@riot-os.org
> https://lists.riot-os.org/mailman/listinfo/devel

-- 
Peter Kietzmann

Hamburg University of Applied Sciences
Dept. Informatik, Internet Technologies Group
Berliner Tor 7, 20099 Hamburg, Germany
Fon: +49-40-42875-8426
Web: http://www.haw-hamburg.de/inet
___
devel mailing list
devel@riot-os.org
https://lists.riot-os.org/mailman/listinfo/devel