from:"Gaëtan Harter"

[riot-devel] Leaving the project

2019-10-18 Thread Gaëtan Harter


Hi RIOT developers,

I will am leaving my job today so will most likely disappear from the 
RIOT project. I was hoping to finish more reviews but the last weeks 
were quite busy. Feel free to take over the issues and changes you are 
interested in.


If you want to stay in contact in the future, use my private email 
address hartergae...@gmail.com.


Cheers,
Gaëtan @cladmi


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

Re: [riot-devel] Release 2019.10 - dates and feature requests

2019-09-17 Thread Gaëtan Harter


Hi Ken,

On 9/4/19 9:52 PM, Ken Bannister wrote:

|Dear RIOTers,


The release dates for the upcoming release cycle are fixed as follows:

- 01.10.2019 - soft feature freeze, for high impact features

- 10.10.2019 - hard feature freeze, for all features

- 31.10.2019 - Release date
|
|
|
|Please send your suggestions for features which you would like to see
merged during this release cycle. I'm also happy to discuss with those
at the summit over the next couple of days.



I am interested by having these two fixes as they are currently the last 
ones required for running the release tests on these boards. Otherwise I 
will still add them to a local branch during testing as I did for the 
last 2 releases.


* boards/pba-d-01-kw2x: fix flashing from invalid state #11549
* boards/frdm: fix flashing from invalid state #12261

If possible, going as far as possible with the migration of 
CPU/CPU_MODEL as we are currently into a transitional state:


* Tracking: move CPU/CPU_MODEL to Makefile.features #11477

Somehow I am also interested by 'cleanterm' to have a terminal without 
added behavior or output to simplify parsing outputs and interactions.
This would allow starting to work on functions abstracting the shell 
https://github.com/RIOT-OS/RIOT/pull/10949 for automated testing


* Makefile.include: add cleanterm target and use it for tests #12107


But as always, what does not go in will wait :)

Best regards,
Gaëtan




Best regards, and happy hacking!

Ken Bannister|


___
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] Issue with implementation of multiple boards in one directory

2019-08-27 Thread Gaëtan Harter


Hi Bas,

On 8/26/19 3:34 PM, Bas Stottelaar wrote:

Hi Gaëten,

BOARD_MODULE is used by the Silicon Labs SLWSTK6000b because it is one board 
with many supported CPU daughter boards (different CPU, other radio configs). 
You would buy that board, but also need to buy this daughter board separately.

A similar approach is used by the EFM32 CPU family. The (incomplete) list of 
daughter boards is here: 
https://github.com/RIOT-OS/RIOT/blob/master/boards/slwstk6000b/modules.txt



So somehow, the `slwstk6000b` board has no sense on its own. It must be 
put with a daughter board. We could rename the combinations to


* `slwstk6000b-slwrb4150a`
* `slwstk6000b-slwrb4162a`

There are currently only two supported daughter boards in RIOT if I 
understand correctly:

https://github.com/RIOT-OS/RIOT/tree/master/boards/slwstk6000b/modules


The issue with relying on a specific configuration variable is that it 
is not documented and not correctly integrated in the whole system.


The variable is not handled with `BUILD_IN_DOCKER`, `scan-build` and if 
two boards would be using `BOARD_MODULE`, it would break the parsing 
done by `info-boards-supported`.


It could be fixed, but it would add an extra specific handling for 
something that is for me just different "boards" in the RIOT "board" 
concept. It would also still currently only compile the first 
combination in CI if no specific handling of multiple boards in one 
directory is done.


My goal is to keep the functionality without, if possible, the specific 
handling.


Kind regards,
Gaëtan


Kind regards,
Bas


Op 26 aug. 2019 om 14:41 heeft Gaëtan Harter  het 
volgende geschreven:

Dear RIOT developers,

as part of migrating CPU and CPU_MODEL definition to `Makefile.features` I am 
facing custom handling of multiple boards in the same directory with sometime 
creative handling but not a proper build system integration.

There are multiple issues with this:
* none of the alternative boards are ever be compiled in the CI
* when testing, giving multiple variables to specify a board is not really 
handled
* building the separate boards is not handled with `BUILD_IN_DOCKER`
* custom non standard configuration variables that are not properly handled in 
the whole build system

The current implementation are currently done through:

* Using a default `CPU_MODEL ?= default_model` however the `CPU_MODEL` variable 
is not passed to docker
  * mulle (2 possibilities)
  * pba-d-01-kw2x (3 possibilities)
  * cc2538dk (no documentation but I think this one is just a mis-write and not 
a wanted thing)
* Using a `STM32F103C8_FLASH_HACK` variable to just set a different 
`CPU_MODEL`. It applies to `bluepill` and `blackpill` but is just documented 
for the `bluepill`
* An undocumented `BOARD_MODULE` variable that triggers a wildcard then a grep to find 
`CPU_MODEL` (yes it queries your filesystem for a static mapping). Its generic with many 
possible values but only implemented for 2 "board modules"

I would like to know who really uses these boards modifications, and what we 
should do with them.
Why were they implemented in the first place instead of having separate boards? 
Would have prevented having them merged?

Should we just split all these boards, it would currently result in 5 or 6 
boards (depending on the blackpill).

Should we keep support for multiple boards together? if yes, can we limit to 
only changing `CPU_MODEL` through this variable and remove the other custom 
handling? Still knowing they would not be automatically tested by CI.

I am willing to take care of the required changes when a direction is decided.

Regards,
Gaëtan - cladmi
___
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

[riot-devel] Issue with implementation of multiple boards in one directory

2019-08-26 Thread Gaëtan Harter


Dear RIOT developers,

as part of migrating CPU and CPU_MODEL definition to `Makefile.features` 
I am facing custom handling of multiple boards in the same directory 
with sometime creative handling but not a proper build system integration.


There are multiple issues with this:
* none of the alternative boards are ever be compiled in the CI
* when testing, giving multiple variables to specify a board is not 
really handled

* building the separate boards is not handled with `BUILD_IN_DOCKER`
* custom non standard configuration variables that are not properly 
handled in the whole build system


The current implementation are currently done through:

* Using a default `CPU_MODEL ?= default_model` however the `CPU_MODEL` 
variable is not passed to docker

  * mulle (2 possibilities)
  * pba-d-01-kw2x (3 possibilities)
  * cc2538dk (no documentation but I think this one is just a mis-write 
and not a wanted thing)
* Using a `STM32F103C8_FLASH_HACK` variable to just set a different 
`CPU_MODEL`. It applies to `bluepill` and `blackpill` but is just 
documented for the `bluepill`
* An undocumented `BOARD_MODULE` variable that triggers a wildcard then 
a grep to find `CPU_MODEL` (yes it queries your filesystem for a static 
mapping). Its generic with many possible values but only implemented for 
2 "board modules"


I would like to know who really uses these boards modifications, and 
what we should do with them.
Why were they implemented in the first place instead of having separate 
boards? Would have prevented having them merged?


Should we just split all these boards, it would currently result in 5 or 
6 boards (depending on the blackpill).


Should we keep support for multiple boards together? if yes, can we 
limit to only changing `CPU_MODEL` through this variable and remove the 
other custom handling? Still knowing they would not be automatically 
tested by CI.


I am willing to take care of the required changes when a direction is 
decided.


Regards,
Gaëtan - cladmi
___
devel mailing list
devel@riot-os.org
https://lists.riot-os.org/mailman/listinfo/devel

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

2019-07-29 Thread Gaëtan Harter


Hi,

Congratulations!

Gaëtan

On 7/25/19 12:37 PM, Martine Lenders wrote:

Hi,

Congretulations!

Cheers,
Martine

Am Do., 25. Juli 2019 um 11:46 Uhr schrieb Kevin Weiss <
kevin.we...@haw-hamburg.de>:


Dear RIOTers,

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

--- * RIOT 2019.07 * ---

The 2019.07 release includes a number of new features including many new
boards and cpu, riotboot added to many new and old boards, USB is now available,
BLE improvements, Ethernet on stm32 platforms, as well as many bug fixes and
documentation updates. Testing has also improved with both On-Target Testing
increasing and now Hardware Assisted Automated Tests being run.

About 300 pull requests with about 659 commits have been merged since the last
release and about 50 issues have been solved. 26 people contributed with code
in 106 days. Approximately 1377 files have been touched with 181993 insertions
and 19668 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!

Best regards,
Kevin Weiss


[1]:https://github.com/RIOT-OS/RIOT/tree/2019.07

[2]:https://github.com/RIOT-OS/RIOT/archive/2019.07.tar.gz

[3]:https://github.com/RIOT-OS/RIOT/releases/tag/2019.07

___
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

[riot-devel] Upcoming `CPU` and `CPU_MODEL` definition migration.

2019-07-23 Thread Gaëtan Harter


Dear RIOT developers, board contributors,


as agreed in https://github.com/RIOT-OS/RIOT/pull/11478 `CPU` and 
`CPU_MODEL` variables will be moved from board `Makefile.include` to 
`Makefile.features` files.


This migration will start after 2019.07 release will have been finalized.
The tracking pull request following this is available at 
https://github.com/RIOT-OS/RIOT/pull/11477
Some issues/board specific handling are still unresolved and will have 
to be tackled along the way. I will come to ask for help when I cannot 
chose a solution myself.


I wanted to inform you of this change that will affect open pull 
requests and current practices.
Please update your pull requests and take it into account during reviews 
after the release.


Update of `CPU_FAM`, `CPU_ARCH` and related variables should also follow 
the same migration in `cpu` in following steps.



The mid-term goal is to allow parsing dependencies in a consistent and 
independent step removing the need for the current workarounds.
The long term goal, is that having a consistent state, could help trying 
new ideas on how to define the dependencies with a way to verify 
regressions.



### Reasoning

The reason behind this is that the board/cpu `Makefile.include` files 
need to allow different configuration depending on the used modules.


However, in the current parsing, `Makefile.dep` is evaluated after 
`Makefile.include` so leads to using value before being correctly defined.

The plan is to move the parsing before.

As dependencies resolution depend on the `CPU` or `CPU_MODEL` variables 
they need to have the value moved out of `Makefile.include` and it will 
be to `Makefile.features.


It will remove duplication as boards `Makefile.features` were already 
including `CPU/Makefile.features` by hardwriting the cpu value. 
`Makefie.dep` was doing it too due to the next issue.
It will fix the inconsistency that the evaluation of supported boards 
used by CI was ignoring board and cpu `Makefile.include` so led to 
ignoring dependencies defined in board and cpu `Makefile.include` and 
also the value of `CPU` and `CPU_MODEL`.
This led to hacks to filter on `BOARD` instead of `CPU_MODEL` in the 
`Makefile.dep`.




I will do my best to prevent regressions and do a smooth transition.
As it can still happen, please notify if you find any issues caused by this.

Thank you for your comprehension

Regards,
Gaëtan - @cladmi
___
devel mailing list
devel@riot-os.org
https://lists.riot-os.org/mailman/listinfo/devel

Re: [riot-devel] LWM2M using ethos

2019-06-25 Thread Gaëtan Harter

Ashim, Ken,

from what I understand, `ethos` works by multiplexing `ethernet` packets 
with `stdio` ones where `tunslip` does it with `ip` packets.

So `ethos` uses `tap` interfaces as it works at link layer where 
`tunslip` uses `tun` as it works at network layer.

Cheers
Gaëtan

On 6/25/19 12:30 PM, Ken Bannister wrote:
I am a user of these tools rather than a developer, and do not know 
enough of the internals to answer your questions. It may even be 
possible that you can use ethos/tap for this application, and I just 
couldn't find the right configuration. Perhaps someone else can chime in.

On 6/25/19 3:25 AM, Ashim Asharaph wrote:

Dear Ken

Thank you very much! Everything worked like a charm. I just have a few 
follow up questions. It seems that usually tap is preferred over tun 
for most of the RIOT applications. Why is this? Also is it possible to 
get a tun interface set up with ethos?

Kind regards
Ashim Asharaph

Ken Bannister  06/22/19 1:34 PM >>>

[The e-mail server of the sender could not be verified (SPF Record)]

I forgot one other thing. You'll need the header for SLIP parameters.
Grab the one from gcoap and copy it to the location of your Makefile [1].

[1]
https://github.com/RIOT-OS/RIOT/blob/master/examples/gcoap/slipdev_params.h 

On 6/22/19 7:23 AM, Ken Bannister wrote:

Hi Ashim,

I tried to get ethos to work with a samr21-xpro, but failed. I was not
permitted to assign an IP address to the wired interface. Rather than
pursue that, I was successful with SLIP, the legacy border router tool.

See the gist for the Wakaama Makefile modified for SLIP [1]. Compile
and flash that, which uses fd00:dead:beef for the network prefix. In a
separate terminal, set up a TUN interface on your workstation. I use
Ubuntu 19.04:

    $ sudo dist/tools/tunslip/tunslip6 -s ttyUSB0 -t tun0
fd00:dead:beef::1/64

Then in the terminal for the border router, configure the interface:

    > ifconfig 7 add unicast fd00:dead:beef::2/64
    > nib neigh add 7 fd00:dead:beef::1

Then you should be able to startup the Wakaama client to talk to the
LwM2M server.

Ken

[1] https://gist.github.com/kb2ma/462a1375ee50735cd58fb3aac7c3c021

On 6/21/19 10:29 AM, Ashim Asharaph wrote:

Dear RIOT developers

I would like to get LWM2M communication through ethos between a board
and computer (without using a border router). It is necessary to do
it this way because the board does not have any wireless or ethernet
capability. I am testing the idea on a samr21-xpro for now. I am
using the wakaama example from one of the PRs and have enabled ethos.

The problem is that the wired interface does not have a global ip
address. The wakaama client can register itself with the Leshan
server but the server cannot communicate with the client due to the
absence of a global address. I have also tried binding the Leshan
server to the tap interface, but that does not work. Any suggestions
would be highly appreciated.

Kind regards
Ashim Asharaph

___
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

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

Re: [riot-devel] CC2538dk Riotboot support

2019-06-07 Thread Gaëtan Harter

On 6/7/19 1:08 PM, Brenton Chetty wrote:

Please ignore my previous email. I forgot to add '$()' for $(IMAGE_OFFSET).
Everything seems fine now. Just need to find out how to erase the necessary
flash instead of a complete erase.

The `-e` option is used by default, if it works without it at all, you
should be good.

-e Erase (full)-

Regards
Brenton

On Fri, Jun 7, 2019 at 11:20 AM Brenton Chetty wrote:

Hi Gaëtan

I managed to get riotboot to select the newer image between slots 0 and 1.
I had to first flash "riotboot.bin" (from $RIOTBASE/bootloaders), then
slots 0 and 1 without doing a full erase.
How do i link the Makefile in (boards/cc2538dk/Makefile.include) to
(sys/riotboot/Makefile.include) so that i can use 'IMAGE_OFFSET' for the
'-a' option in 'cc2538-bsl.py'. It currently says 'IMAGE_OFFSET' was not
declared (same with SLOT(0/1)_OFFSET).
Also, why was it that i needed to flash "riotboot.bin" first. Shouldn't
the bootloader automatically be flashed when using the
"riotboot/flash-combined-slot0" command?
Note, the flashbase address for the cc2538 is 0x20. I flashed
"riotboot.bin" at 0x20, then slot0 at 0x201000, then slot1 at 0x240700.
For "riotboot.bin", I compiled using
SECTIONS
{
.flashcca :
{
KEEP(*(.flashcca))
} > cca
}
// so the filesize for "riotboot.bin" was 512KB, then slot images were
around 15KB each. The CCA section consists of 44 bytes at the end of flash

Regards
Brenton

On Mon, May 27, 2019 at 2:31 PM Gaëtan Harter
wrote:

Hi Brenton,

if you only use the default `riotboot/flash` or `flash` in
`tests/riotboot` targets, you do not need flasher changes.
But you should not use `riotboot/flash-slot0` and `riotboot/flash-slot1`
targets for the moment.

To have the support declared and merged in RIOT, it also needs to
support flashing the `slot-` firmwares alone. These require having
flasher that can flash with an offset`.

For `cc2538-bsl.py` it looks like there is the `-a` option for this.

Maybe changing it to use `IMAGE_OFFSET` if set would be enough.
An example is in

https://github.com/RIOT-OS/RIOT/blob/8fe12bc82cfbb83a90efd018e11c044d0a40696b/makefiles/tools/edbg.inc.mk#L14-L15

The `flash.sh` is currently using `jlink` without using the common
`jlink` scripts thing, it is in my todo list after
https://github.com/RIOT-OS/RIOT/pull/11554 to migrate to use the common
one where applicable.

Cheers,
Gaëtan

On 5/24/19 2:32 PM, Francisco Acosta wrote:

Hi Brenton!

So far I remember we didn't take it into account, and I don't know if
someone is taking care of it.

As far as I know, there are two ways of supporting that CPU:

1. The way we do it now, which is linking the image in another start
address so the bootloader can recognise it and boot it.

2. Modify the start address on the CC2538 register dedicated to this.
This might be a bit tricky but also interesting for the sake of research
and compatibility.

However, I'd advice the first option to have the full benefits of the
bootloader and struggling less with the particular settings on that
chip.

Overall, the steps would be the following:

1. Adapt the linker scripts to succeed tests/cortexm_common_ldscript.
This consists on making the linker scripts on cpu/cc2838/ldscripts
comply with cpu/cortexm_common/ldscrpts/cortexm.ld. You might take a
look how is it done for stm32 or sam0 families.

2. Provide the length and start variables to link slots correctly:
- ROM_LEN
- RAM_LEN
- ROM_START_ADDR
- RAM_START_ADDR

Again, take a look on the supported CPUs as examples.

3. Make tests/riotboot pass

4. Perform a firmware update or flash different firmwares with different
versions so the bootloader choses the newest.

Optionally you might want to test if the WIP SUIT update format works.

Don't hesitate to make more questions if you have some!

Cheers,

Paco.

On 24/05/2019 13:43, Brenton Chetty wrote:

Hey guys, has anyone succeeded in providing riotboot support for the
cc2538dk board as yet?

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

Re: [riot-devel] CC2538dk Riotboot support

2019-06-03 Thread Gaëtan Harter

Hi Brenton,

I noticed there is `-e` in `FFLAGS` which performs a full erase of the
rom so flashing a second slot while the first one or the bootloader is
there cannot work.

We removed this full erase from all flashers for boards using
`riotboot`. If the flasher erases only what is required for flashing it
could be removed from the default configuration. And it was the case for
`edbg/openocd/jlink`.

Regards,
Gaëtan

So you can try without the `-e` in `FFLAGS` and see if first flashing
`slot1` works and if it is also not destroying your normal workflow ?

On 5/31/19 1:50 PM, Brenton Chetty wrote:

Hi Gaëtan, i managed to get the tests/riotboot to pass whilst using
'riotboot/flash-combined-slot0'. I also used the '-a' option For
'cc2538-bsl.py'. This allowed me to use the 'riotboot/flash-slot0'
successfully. However, i couldn't get slot 1 working. How do think i should
approach this problem. And currently i can only use 'riotboot/flash-slot0'
whilst using the '-a' option For 'cc2538-bsl.py'. What is the RIOT approach
to implementing this?

With regards
Brenton

On Mon, May 27, 2019 at 2:31 PM Gaëtan Harter
wrote:

Hi Brenton,

To have the support declared and merged in RIOT, it also needs to
support flashing the `slot-` firmwares alone. These require having
flasher that can flash with an offset`.

For `cc2538-bsl.py` it looks like there is the `-a` option for this.

Maybe changing it to use `IMAGE_OFFSET` if set would be enough.
An example is in

https://github.com/RIOT-OS/RIOT/blob/8fe12bc82cfbb83a90efd018e11c044d0a40696b/makefiles/tools/edbg.inc.mk#L14-L15

Cheers,
Gaëtan

On 5/24/19 2:32 PM, Francisco Acosta wrote:

Hi Brenton!

So far I remember we didn't take it into account, and I don't know if
someone is taking care of it.

As far as I know, there are two ways of supporting that CPU:

1. The way we do it now, which is linking the image in another start
address so the bootloader can recognise it and boot it.

2. Modify the start address on the CC2538 register dedicated to this.
This might be a bit tricky but also interesting for the sake of research
and compatibility.

However, I'd advice the first option to have the full benefits of the
bootloader and struggling less with the particular settings on that
chip.

Overall, the steps would be the following:

2. Provide the length and start variables to link slots correctly:
- ROM_LEN
- RAM_LEN
- ROM_START_ADDR
- RAM_START_ADDR

Again, take a look on the supported CPUs as examples.

3. Make tests/riotboot pass

4. Perform a firmware update or flash different firmwares with different
versions so the bootloader choses the newest.

Optionally you might want to test if the WIP SUIT update format works.

Don't hesitate to make more questions if you have some!

Cheers,

Paco.

On 24/05/2019 13:43, Brenton Chetty wrote:

Hey guys, has anyone succeeded in providing riotboot support for the
cc2538dk board as yet?

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

Re: [riot-devel] Release 2019.07 - dates and feature requests

2019-06-03 Thread Gaëtan Harter


Hi,

I would personally like to manage to get the migration to FLASHFILE 
finally finished https://github.com/RIOT-OS/RIOT/pull/8838 (I only have 
the tracking PR currently, so it's my fault if it did not move) and the 
fix for flashers on the board I use for testing the release 
https://github.com/RIOT-OS/RIOT/pull/10870 as I currently use them for 
testing anyway. I could need help for that last one if you have examples 
that put any of the mentioned boards in a no more flashable state with RIOT.


Cheers,
Gaëtan


On 6/1/19 6:42 PM, Dylan Laduranty wrote:

Hi all,
#11077 and #11085 could be in the incoming release but it will require to
have #11075 and #10916 merged first.
Hopefully, #11075 should be pretty straightforward and #10916 (which
introduces the stack) is in the final review state.
Any help with the review and/or test process will be highly appreciated !
Cheers,

Le sam. 1 juin 2019 à 01:40, Hauke Petersen  a
écrit :


Hej,

big +1! Getting the USB+Ethernet slave mode to work would be a major
milestone towards simple to deploy border routers and such.

So ~4 more weeks seems doable, right?!




Cheers,
Hauke


On 5/31/19 10:11 PM, Mario Gómez wrote:

Hi all!

My grain of salt:

For high impact features:

PR #11085 (Serial console over USB) & PR #11077 (USB CDC ECM support)

Those two combined with something like the SAM-BA bootloader (Arduino SAMD
bootloader compatible with BOSSA) would allow us to make easy-upgradeable
one-chip border-router USB dongles based on the ATSAMR21. USB CDC ECM
essentially could remove the need for ethos.

Regards,
Mario.

On Fri, May 31, 2019 at 6:51 AM Kevin Weiss 
wrote:


Dear RIOTers,


The release dates for the upcoming release cycle are fixed as follows:

- 28.06.2019 - soft feature freeze, for high impact features

- 08.07.2019 - hard feature freeze, for all features

- 31.07.2019 - Release date

Could you please send your suggestions for features which you would like
to see merged during this release cycle.


Best regards, and happy hacking!

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



___
devel mailing 
listdevel@riot-os.orghttps://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] CC2538dk Riotboot support

2019-05-27 Thread Gaëtan Harter

On 5/27/19 2:36 PM, Emmanuel Baccelli wrote:

Seems to me that a quick riotboot porting guide could be useful somewhere
in the wiki.

More in the `riotboot` documentation in the repository I would say.

On Mon, May 27, 2019 at 2:30 PM Gaëtan Harter
wrote:

Hi Brenton,

To have the support declared and merged in RIOT, it also needs to
support flashing the `slot-` firmwares alone. These require having
flasher that can flash with an offset`.

For `cc2538-bsl.py` it looks like there is the `-a` option for this.

Maybe changing it to use `IMAGE_OFFSET` if set would be enough.
An example is in

https://github.com/RIOT-OS/RIOT/blob/8fe12bc82cfbb83a90efd018e11c044d0a40696b/makefiles/tools/edbg.inc.mk#L14-L15

Cheers,
Gaëtan

On 5/24/19 2:32 PM, Francisco Acosta wrote:

Hi Brenton!

So far I remember we didn't take it into account, and I don't know if
someone is taking care of it.

As far as I know, there are two ways of supporting that CPU:

1. The way we do it now, which is linking the image in another start
address so the bootloader can recognise it and boot it.

2. Modify the start address on the CC2538 register dedicated to this.
This might be a bit tricky but also interesting for the sake of research
and compatibility.

However, I'd advice the first option to have the full benefits of the
bootloader and struggling less with the particular settings on that
chip.

Overall, the steps would be the following:

2. Provide the length and start variables to link slots correctly:
- ROM_LEN
- RAM_LEN
- ROM_START_ADDR
- RAM_START_ADDR

Again, take a look on the supported CPUs as examples.

3. Make tests/riotboot pass

4. Perform a firmware update or flash different firmwares with different
versions so the bootloader choses the newest.

Optionally you might want to test if the WIP SUIT update format works.

Don't hesitate to make more questions if you have some!

Cheers,

Paco.

On 24/05/2019 13:43, Brenton Chetty wrote:

Hey guys, has anyone succeeded in providing riotboot support for the
cc2538dk board as yet?

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

Re: [riot-devel] CC2538dk Riotboot support

2019-05-27 Thread Gaëtan Harter

Hi Brenton,

To have the support declared and merged in RIOT, it also needs to
support flashing the `slot-` firmwares alone. These require having
flasher that can flash with an offset`.

For `cc2538-bsl.py` it looks like there is the `-a` option for this.

Maybe changing it to use `IMAGE_OFFSET` if set would be enough.
An example is in
https://github.com/RIOT-OS/RIOT/blob/8fe12bc82cfbb83a90efd018e11c044d0a40696b/makefiles/tools/edbg.inc.mk#L14-L15

Cheers,
Gaëtan

On 5/24/19 2:32 PM, Francisco Acosta wrote:

Hi Brenton!

So far I remember we didn't take it into account, and I don't know if
someone is taking care of it.

As far as I know, there are two ways of supporting that CPU:

1. The way we do it now, which is linking the image in another start
address so the bootloader can recognise it and boot it.

2. Modify the start address on the CC2538 register dedicated to this.
This might be a bit tricky but also interesting for the sake of research
and compatibility.

However, I'd advice the first option to have the full benefits of the
bootloader and struggling less with the particular settings on that
chip.

Overall, the steps would be the following:

2. Provide the length and start variables to link slots correctly:
- ROM_LEN
- RAM_LEN
- ROM_START_ADDR
- RAM_START_ADDR

Again, take a look on the supported CPUs as examples.

3. Make tests/riotboot pass

4. Perform a firmware update or flash different firmwares with different
versions so the bootloader choses the newest.

Optionally you might want to test if the WIP SUIT update format works.

Don't hesitate to make more questions if you have some!

Cheers,

Paco.

On 24/05/2019 13:43, Brenton Chetty wrote:
Hey guys, has anyone succeeded in providing riotboot support for the
cc2538dk board as yet?

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

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

2019-01-31 Thread Gaëtan Harter


Hi Gunar,

I would say that all CFLAGS/INCLUDES/LINK_FLAGS must be set in 
Makefile.include (or similar) files not the Makefile.dep ones.


But, currently, as board/cpu Makefile.include are parsed before 
Makefile.dep, you cannot really do it with the way we define them now.


It is a problem I slowly try to address followed by this issue:

https://github.com/RIOT-OS/RIOT/issues/9913

The next step is to somehow move the `CPU/CPU_MODEL` before 
`board/Makefile.include` and would currently be in `Makefile.features`.

I just got stuck providing upcoming PRs.
My wip/poc branch is
https://github.com/cladmi/RIOT/commits/pr/make/cpu/features
I should move my ass if there is interest.


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.



Do you have any specific issue/pull request in mind ?

Regards,
Gaëtan

On 1/31/19 3:06 PM, Gunar Schorcht wrote:

Hi,

what is the right location for additional settings of CFLAGS, INCLUDES
or LINK_FLAGS that are required by a pseudomodule which is enabled in
Makefile.include of CPU? Should these additional settings be done in
Makefile.include or in Makefile.dep of this CPU?

Regards
Gunar


___
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] Hello world stopped working

2018-12-06 Thread Gaëtan Harter


Hi Kees,

The PR 10404 was delayed because I needed to address the reviews, which 
I finally did yesterday.


A final review there could help get it in :)

Cheers,
Gaëtan

On 06.12.18 08:49, smlng wrote:

Hi all,

Joakim is right - there are several reports of broken/non-working firmwares
compiled with the arm-none-eabi-gcc and libs provided by Ubuntu:Bionic

see for instance:

- https://bugs.launchpad.net/ubuntu/+source/gcc-arm-none-eabi/+bug/1767223
- https://bugs.launchpad.net/ubuntu/+source/newlib/+bug/1768125

That's why our riotdocker image (and with that the Murdock-CI) uses the
official releases instead of the apt-packages.

Best,
   Sebastian


On 6. Dec 2018, at 08:43, Joakim Nohlgård  wrote:

Hi,
I don't believe that we require GCC 7 anywhere, it should still work
fine to build with for example the ARM provided GCC 6 release, or the
older Ubuntu/Debian toolchains. It seemed more like there is a problem
with the Ubuntu packaged arm-none-eabi toolchain that produces broken
binaries.

/Joakim

On Wed, Dec 5, 2018 at 10:05 PM Kees Bakker  wrote:


Hey Alex,

Thanks, that did the trick. Wow, what happened with that compiler?
I now see that we have PR #10404 and a few issues about it. Hmm,
that PR could have given me a warning.
-- Kees

On 05-12-18 21:20, Alexandre Abadie wrote:

Hi Kees,

You need a more recent version of the GNU ARM compiler, 7.x, and you only have 
6.3. The recommended toolchain is the official one from ARM that can be 
downloaded at [1].

Just uncompress the archive somewhere in your filesystem (in /opt for example) 
and update your PATH variable. This is what I do and it works well.

Cheers!

Alex

[1] https://developer.arm.com/open-source/gnu-toolchain/gnu-rm/downloads

- Le 5 Déc 18, à 21:09, Kees Bakker k...@sodaq.com a écrit :


Hi,

This may sound like a stupid question, but I can't get output
from hello world anymore. On my Sodaq Explorer and also on my
Sodaq One.

I have been away from RIOT for a few weeks and now that I get back
there is no output on UART0, and the LEDs don't work either.

Since last time, I upgraded my Ubuntu to 18.04. It has a newer compiler.
Could that be it?

binutils-arm-none-eabi  2.27-9ubuntu1+9
gcc-arm-none-eabi  15:6.3.1+svn253039-1build1
gdb-arm-none-eabi  7.10-1ubuntu3+9
libnewlib-arm-none-eabi  2.4.0.20160527-3
libstdc++-arm-none-eabi-newlib  15:6.3.1+svn253039-1+10

If not, what else could it be? It must be something obvious, but
so far I haven't found it.
--
Kees
___
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


___
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

2018-11-15 Thread Gaëtan Harter


Hi Julien,

I think this test should be doing what you want, I did not look at it 
just knew it existed.



https://github.com/RIOT-OS/RIOT/tree/master/test/bench_thread_yield_pingpong 




Regards,
Gaëtan - cladmi

On 15.11.18 16:41, Julien Gomez wrote:

Hello fellow developers !

I have a simple question: How one could compute the time elapsed when switching 
from thread A to thread B?

Any advice or lead is welcome!

Regards,
Julien


___
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 30, 2018 5pm - 10pm (CET) (RIOT Events)

2018-10-30 Thread Gaëtan Harter


We are live at https://jitsi.tools.ietf.org/riot-hacknack

On 29.10.18 17:00, Google Calendar wrote:

This is a notification for:

Title: Hack'n'ACK
When: Tue Oct 30, 2018 5pm – 10pm Central European Time - Berlin
Where: FU Berlin; HAW Hamburg
Calendar: RIOT Events
Who:
     * Martine Lenders - creator

Event details: 
https://www.google.com/calendar/event?action=VIEW&eid=bGJrNG1mdWNxZG9tY2Y3YzhvOWNnNGNtc2dfMjAxODEwMzBUMTYwMDAwWiBrM3FsOHNldHY3bDQ4b2Zub2wwdGZ1dTZ0c0Bn&es=1 



Invitation from Google Calendar: https://www.google.com/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 at 
https://support.google.com/calendar/answer/37135#forwarding


___
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] shell and putchar

2018-10-17 Thread Gaëtan Harter


Hi Neil,

digging through old unread emails

Answering inline.


On 7/6/18 4:58 PM, Neil Jones wrote:

Hi all,

I'm working on improving IRQ support on PIC32 and I'm testing UART Rx using
the shell.

The shell uses putchar, but putchar is buffered and needs a flush, thus
when typing at the console I get no feedback until I press enter (the line
feed gets echo'd and then we get the flush).

I'm surprised other newlib implementations don't see this ?



I think most developers have their local program doing the 'echo' for 
them and only sending lines by lines anyway.
So I personally do not really pay attention to this. I did not even knew 
we were doing 'echo' by default…





A flush is probably needed here:

#if !defined(SHELL_NO_ECHO) || !defined(SHELL_NO_PROMPT)
#ifdef MODULE_NEWLIB
/* use local copy of putchar, as it seems to be inlined,
  * enlarging code by 50% */
static void _putchar(int c) {
 putchar(c);
 fflush(STDOUT)   <--- HERE

}
#else
#define _putchar putchar
#endif
#endif




I agree it could make sense to add it when in `echo` mode only.

putchar(c)
#ifndef SHELL_NO_ECHO
fflush(stdout);
#endif


As for the shell prompt it is already handled here 
https://github.com/RIOT-OS/RIOT/blob/master/sys/shell/shell.c#L273-L280




I'm happy to do a PR for this, but this is very core functionality, I don't
want to break anything ??


But maybe other developers have more knowledge about this.

Cheers,
Gaëtan




Cheers,

Neil


___
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] Unit test code coverage using gcov

2018-10-09 Thread Gaëtan Harter


Hi Toon,

are you talking about native tests or embedded ones ?

For embedded I had some POC/wip that I ran with specific local setup in 
my previous job based on https://www.thanassis.space/coverage.html


https://github.com/iot-lab/openlab/tree/coverage

If there is an effort in this direction I am willing to help.

Cheers,
Gaëtan

On 10/9/18 4:25 PM, Martine Lenders wrote:

Hi,

as there is some discussion to split the unittests into several
applications [1] and some stuff isn't included into them for good reasons
(driver test e.g.), I'm not sure if this should be constrained to unittests
(though they are indeed a good starting point).

Regards,
Martine

PS: I'm not aware of work going into that direction, so +1 in general.

[1] https://github.com/RIOT-OS/RIOT/issues/8941

Am Di., 9. Okt. 2018 um 16:17 Uhr schrieb STEGEN Toon <
tste...@nalys-group.com>:


Hi Guys,


Has anybody succeeded in getting gcov to work to check code coverage of
the unit tests?

We will try to add support for this, but I want to make sure we're not
spending our time on unnecessary work.


Greets,

Toon Stegen
___
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] Git submodule in RIOT-OS/applications

2018-09-27 Thread Gaëtan Harter


Hi Jose,

for me it does not hurt to allow both.

It does not help with guarantee that it works with the current master 
but lets user just easily use with the release, or last working RIOT 
version.


So change the `RIOTBASE` to use a cloned version in the repository if it 
is there, and the RIOT version in the same directory like now if it is 
not cloned using something like


`$(if $(wildcard $(CURDIR)/../RIOT),$(wildcard $(CURDIR)/../RIOT),\
  $(CURDIR)/../../RIOT)`

And as Juan proposed ;) he will do the testing for the releases and 
update the submodule reference.



Adding a test in CI could be a separate improvement.


And the other question, why are they not part of RIOT anyway ?


Gaëtan

On 9/26/18 10:08 AM, Martine Lenders wrote:

Hi Jose,

while I agree that this would be easier for new users, I don't see how this
would help with applications being in a working state.

First of all, continuous integration is missing for those applications
anyways (IMHO we should change that), so a working state isn't guaranteed
in the first place. A submodule wouldn't help with that.

Second, if any problem arises with the application, we would be "stuck" on
that release (or would have to have hotfixes backported into the release,
specifically tailored to the application). So I'd rather would like to have
it synced with current master but included into the continous integration.

Regards,
Martine

Am Mi., 26. Sep. 2018 um 09:47 Uhr schrieb Jose 
:



Hello RIOT developers,


Does it make sense to provide a RIOT (git submodule) folder in the
RIOT-OS/applications, pointing to the latest RIOT release?

I can see some reasons:

- Applications will always be in a working state

- Might be easier for new users to clone and use


We would require to update the submodule at the end of a Release.

Any comments?

___
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

[riot-devel] Build system API change, central definition of `test` target

2018-09-10 Thread Gaëtan Harter


Dear RIOT developers,

the way to define tests for an application has been changed.
See the pull request for reference:

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

The `test` target is now defined in the main `Makefile.include`[1] and 
executes files from the `TESTS` variable. By default it is defined by 
listing executable files in the `application_dir/tests/` directory[2].


Please update your pull requests accordingly and remember to check this 
when reviewing other pull requests.


Thank you.

1: https://github.com/RIOT-OS/RIOT/blob/master/Makefile.include#L541
2: https://github.com/RIOT-OS/RIOT/blob/master/Makefile.include#L539

Cheers,
Gaëtan - @cladmi

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

Re: [riot-devel] Enable CORS on Murdock

2018-08-28 Thread Gaëtan Harter


To explain why I need it.

I currently worked with the Juan to develop this size comparison page.
It currently requires a CORS enabling extension like:

https://addons.mozilla.org/en-US/firefox/addon/cors-everywhere/


If you have the extension, you can get a summary of the size difference 
between two builds:


https://cladmi.github.io/devpages/cmpmurdocksize.html?origin=https%3A%2F%2Fci.riot-os.org%2FRIOT-OS%2FRIOT%2F9836%2F14074eeda106ded94f7f46ca46189993ba659683%2Fsizes.json&destination=https%3A%2F%2Fci.riot-os.org%2FRIOT-OS%2FRIOT%2F8711%2F05e9a2e1f1868c101838ed55f1af4d89bcc4643c%2Fsizes.json

There is also a per column sort function but it looks like it is 
currently doing a string comparison.



On 8/28/18 1:51 PM, Gaëtan Harter wrote:

Hello,

I wanted to write a script to compare two murdock build size output and 
thought, why not writing it in javascript so it could be rendered from a 
github page or something even sharing a link calculating the results.


While trying to write a webpage using Javascript downloading two Murdock 
'size.json' we faced the issue that it could not download the file from 
murdock as it does not allow Cross-origin resource sharing[1].


Is it be possible to enable it for all domains ? At least for 'get'

1: https://en.wikipedia.org/wiki/Cross-origin_resource_sharing

I have no idea how or where it should be done though.

Thanks, in advance.

Cheers,
Gaëtan
___
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

[riot-devel] Enable CORS on Murdock

2018-08-28 Thread Gaëtan Harter


Hello,

I wanted to write a script to compare two murdock build size output and 
thought, why not writing it in javascript so it could be rendered from a 
github page or something even sharing a link calculating the results.


While trying to write a webpage using Javascript downloading two Murdock 
'size.json' we faced the issue that it could not download the file from 
murdock as it does not allow Cross-origin resource sharing[1].


Is it be possible to enable it for all domains ? At least for 'get'

1: https://en.wikipedia.org/wiki/Cross-origin_resource_sharing

I have no idea how or where it should be done though.

Thanks, in advance.

Cheers,
Gaëtan
___
devel mailing list
devel@riot-os.org
https://lists.riot-os.org/mailman/listinfo/devel

[riot-devel] Release 2018.07

2018-08-13 Thread Gaëtan Harter


Dear RIOTers,

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

--- * RIOT 2018.07 * ---

The 2018.07 release includes new features, like NimBLE (ble stack),
a MQTT-SN client, SHA-1 based PRNG, an UUID implementation. The RISC-V 
CPU architecture support used by the hifive1 board.
Effort was done on refactoring, documentation, test improvements and bug 
fixes.


During the last release, maintainers contributed by running the 
automated test suites on their boards. This gave valuable feedback on 
the board support state, test reliability and where to focus effort to 
make testing easier and more reliable.


About 380 pull requests with about 675 commits have been merged since 
the last release and about 27 issues have been solved. 45 people 
contributed with code in 93 days. Approximately 1678 files have been 
touched with 147122 insertions and 16060 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].

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

Best Regards,
Gaëtan - @cladmi

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

Re: [riot-devel] Preparing release 2018.07 - RC2

2018-08-11 Thread Gaëtan Harter


Dear RIOTers,

all the tests for the Release Specs have now been successfully ran or 
only trigger false negative.
Thanks to everybody who contributed for this release or contributed to 
the testing.


I want to take care of the release today and only need to finish 
summarizing major contributions and issues for the release notes.
I strongly invite you to add your contributions if you want to be sure 
they end up listed as the list is not exhaustive.


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

Thank you in advance.

Cheers,
Gaëtan - @cladmi


On 08/02/2018 08:10 PM, Gaëtan Harter wrote:

Dear RIOTers,


(There is a message for all maintainers at the end)

The new release candidate 2018.07-RC2 for RIOT is now ready for testing.

I opened the testing issue for following the RC2 testing:

https://github.com/RIOT-OS/Release-Specs/issues/69

Please assign yourself on the tasks you will take care of.


You can also still add a note of your contributions for this release 
in the release notes: https://github.com/RIOT-OS/RIOT/pull/9566





To all boards maintainers, and developers that care about their boards
--


To all boards maintainers who do not maybe have time to follow the 
testing for the release in general.


As we have limited working power and hardware available here, many of 
your boards are never tested for the release. I would like to start 
addressing that and have a wider idea on the state of our hardware 
support and our automated testing, which tests work and which do not. 
But this requires you to take part of it, if you want to.


I would like to ask you if you could run the automated tests on your 
board on the release branch 2018.07-branch and send me the results. I 
will take care of processing them and summarize the outcome to have a 
better view on our current tests suites and what could be improved for 
the next release.


It is currently still a Pull request in the Release-Specs repository,
and I welcome your feedback.

https://github.com/RIOT-OS/Release-Specs/pull/68

You can run tests during lunch break or during the night, it should be 
automatic. And then send me the results with a pull request to 
https://github.com/cladmi/RIOT_2018_07_tests_results.


That would be really nice of you.



Thank you in advance for your work.

Cheers,
Gaëtan - @cladmi

___
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

[riot-devel] Preparing release 2018.07 - RC2

2018-08-02 Thread Gaëtan Harter


Dear RIOTers,


(There is a message for all maintainers at the end)

The new release candidate 2018.07-RC2 for RIOT is now ready for testing.

I opened the testing issue for following the RC2 testing:

https://github.com/RIOT-OS/Release-Specs/issues/69

Please assign yourself on the tasks you will take care of.


You can also still add a note of your contributions for this release in 
the release notes: https://github.com/RIOT-OS/RIOT/pull/9566





To all boards maintainers, and developers that care about their boards
--


To all boards maintainers who do not maybe have time to follow the 
testing for the release in general.


As we have limited working power and hardware available here, many of 
your boards are never tested for the release. I would like to start 
addressing that and have a wider idea on the state of our hardware 
support and our automated testing, which tests work and which do not. 
But this requires you to take part of it, if you want to.


I would like to ask you if you could run the automated tests on your 
board on the release branch 2018.07-branch and send me the results. I 
will take care of processing them and summarize the outcome to have a 
better view on our current tests suites and what could be improved for 
the next release.


It is currently still a Pull request in the Release-Specs repository,
and I welcome your feedback.

https://github.com/RIOT-OS/Release-Specs/pull/68

You can run tests during lunch break or during the night, it should be 
automatic. And then send me the results with a pull request to 
https://github.com/cladmi/RIOT_2018_07_tests_results.


That would be really nice of you.



Thank you in advance for your work.

Cheers,
Gaëtan - @cladmi

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

Re: [riot-devel] [riot-maintainer] Preparing release 2018.07

2018-08-02 Thread Gaëtan Harter


Dear RIOTers,

due to holidays, testing was a bit delayed and so is the release.
I would like to do the next release candidate today.

There are still a few open isuses that I want addressed and backported 
before:


https://github.com/RIOT-OS/RIOT/milestone/23

They are all marked with `backporting-needed` and would need some help 
to finalize the review.

If you can help on one of the open issues your help is welcomed.

Cheers,
Gaëtan - @cladmi


On 17.07.2018 14:26, Gaëtan Harter wrote:

Dear RIOTers,

I created the release branch 
https://github.com/RIOT-OS/RIOT/tree/2018.07-branch for the release.
It means that if you want to have some PRs included for the release they 
should be backported this week.

Remember to put the `Backporting-needed` label on the PRs when necessary.

Please update the milestone of your issues and PRs to the next release 
if they are not going to be included in this one.



I opened the testing issue for following release testing: 
https://github.com/RIOT-OS/Release-Specs/issues/65

Please assign yourself on the tasks you will take care of.

I tried to list all merged PRs and closed Issues for this release in the 
release milestone https://github.com/RIOT-OS/RIOT/milestone/23?closed=1

I still need to update it with the latest merged ones.


I started a first draft for the release notes: 
https://github.com/RIOT-OS/RIOT/pull/9566
Please contribute what you want included in the release notes directly 
to my branch or in the comments.


Thank you in advance for your work.

Cheers,
Gaëtan - @cladmi


On 02.07.2018 12:09, Gaëtan Harter wrote:

Dear RIOTers,

summer is already there and July release 2018.07 is coming.
I will be taking care of the release process for the first time and I 
welcome your feedback.


First the important dates are fixed as follows:

- preliminary/soft feature freezefor high impact features:    July 
16th, 2018

- final/hard feature freeze: July 23th, 2018
- final release date: When tests run successfully, hoping at the 1st 
of August to use the July 31th Hack'N'Ack for finalizing.


Please contact me if you have features you would really want to have, 
and if you think they would be ready for the release.


On your side, can you also please check you open pull requests and 
issues and update the release milestone to the current or the next 
release to help focus the efforts.

Also remember to update and rebase your PRs that you want review for.


My objective for this release, is to get and publish results of 
automated tests for more boards than previous releases.

Some automated tests have never been run or worked on some platforms.
I think that giving a reference state of the test results would help 
the effort of improving automated testing.



Happy hacking!

Cheers,
Gaëtan - @cladmi

___
Maintainer mailing list
maintai...@riot-os.org
https://lists.riot-os.org/mailman/listinfo/maintainer





___
Maintainer mailing list
maintai...@riot-os.org
https://lists.riot-os.org/mailman/listinfo/maintainer



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

[riot-devel] Notes RIOT internal Meeting Friday 20.04.2018

2018-07-20 Thread Gaëtan Harter


Hi,

see below notes from the meeting today.

Cheers,
Gaëtan


# ic2 attempt 2

Kevin asking why it is stuck
Gaëtan: there were not tests re-run on the rebased version even though 
there were fixes


# release

i2c will not go in the release, but the embargo remains in master.
However, fixes that are blocked by the embargo can go in for the 
release. The would need to wait for i2c to be merged to be integrated in 
master though.


Only 01-ci tests were run for the moment and no maintainers registered 
themselves for testing for the moment.

Paco will start to tests things this afternoon.
___
devel mailing list
devel@riot-os.org
https://lists.riot-os.org/mailman/listinfo/devel

Re: [riot-devel] General configuration Task Force

2018-07-17 Thread Gaëtan Harter


I am also interested to follow this after the release.

Gaëtan


On 09.07.2018 10:09, Jose wrote:

Dear maintainers,


Last Friday we had an offline discussion with some RIOT people about 
he lack of a mechanism to configure Kernel parameters as well as 
application specific configurations (private keys, timer values, etc). 
Although RIOT is configurable via CFLAGS, there's no way to (easily) 
expose all configurations and tweak RIOT in a centralized manner. As 
shown, other OS are using several strategies in order to accomplish 
this (KConfig, header files, etc).



I want to propose a "Kernel and Application specific configuration" 
Task Force to address these issues. What are your feelings about this? 
Anyone (besides me) is interested to work in this topic?



Cheers,

José

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


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

[riot-devel] Preparing release 2018.07

2018-07-02 Thread Gaëtan Harter


Dear RIOTers,

summer is already there and July release 2018.07 is coming.
I will be taking care of the release process for the first time and I 
welcome your feedback.


First the important dates are fixed as follows:

- preliminary/soft feature freezefor high impact features:    July 16th, 
2018

- final/hard feature freeze: July 23th, 2018
- final release date: When tests run successfully, hoping at the 1st of 
August to use the July 31th Hack'N'Ack for finalizing.


Please contact me if you have features you would really want to have, 
and if you think they would be ready for the release.


On your side, can you also please check you open pull requests and 
issues and update the release milestone to the current or the next 
release to help focus the efforts.

Also remember to update and rebase your PRs that you want review for.


My objective for this release, is to get and publish results of 
automated tests for more boards than previous releases.

Some automated tests have never been run or worked on some platforms.
I think that giving a reference state of the test results would help the 
effort of improving automated testing.



Happy hacking!

Cheers,
Gaëtan - @cladmi

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

Re: [riot-devel] Correct way to write simulator driver for x86

2018-06-28 Thread Gaëtan Harter


Hi Nazmul,

as you are doing a simulation for native only, you could directly use 
any linux native functions for the implementation.
There are already `native` modules using standard linux/posix 
interfaces. They should however be configured to not use RIOT posix 
includes directories.
This is done by overwriting `INCLUDES` by `NATIVEINCLUDES` in the module 
makefile.


```
git grep 'INCLUDES = $(NATIVEINCLUDES)'
boards/native/Makefile:INCLUDES = $(NATIVEINCLUDES)
boards/native/drivers/Makefile:INCLUDES = $(NATIVEINCLUDES)
cpu/native/Makefile:INCLUDES = $(NATIVEINCLUDES)
cpu/native/mtd/Makefile:INCLUDES = $(NATIVEINCLUDES)
cpu/native/netdev_tap/Makefile:INCLUDES = $(NATIVEINCLUDES)
cpu/native/socket_zep/Makefile:INCLUDES = $(NATIVEINCLUDES)
```

One constraint then, is that this module should not interact with RIOT 
in its API using `posix` constants as they could have different values 
in your native module and in the application modules. (posix defines 
names, not values).


I do not know if there are other constraints regarding implementing 
these kind of modules…


Regards,
Gaëtan

On 13.06.2018 23:41, Nazmul Alam wrote:

Hi Rioters,
I would like to use a simulation driver to fake temperature and 
humidity data (sht11)
for the native platform (x86). What would be the best way to provide 
an interface to the fake driver such that the temperature or humidity 
can be supplied from outside.


I know the tap interface is the way to communicate between the RIOT-OS 
and a Linux application. But is there is any other way to use IPC to 
directly communicate with the RIOT process?


My goal is to use large-scale RIOT-OS simulation for academic purpose.

Thanks.

--
with best regards,
Nazmul Alam Shovon

*শুভেচ্ছান্তে,
নাজমুল আলম শোভন*

blog : https://yourdigitaleffects.wordpress.com/


___
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] PIC programmer with Linux support?

2018-05-31 Thread Gaëtan Harter

Hi,

I submitted a PR to do it for pic32-wifire using a PICkit3: 
https://github.com/RIOT-OS/RIOT/pull/9259
I only needed to use a windows VM (that you can get from microsoft for 
free) to update the PICkit3 firmware.

I manage to run tests with it.

However for running on CI, flashing is quite slow, so may be a problem 
or would need a specific tag to say run on pic32.

Regards,
Gaëtan

On 22.05.2018 13:59, Martine Lenders wrote:

Hi,

if its still needed and if it helps: I have a PICkit3 (my property) at 
my office that I don't really need and am willing to donate to the 
cause. I needed it years ago for a private project that I gave away 
(and was able to confirm that it is still running after all those 
years during my vacation ^^) and I'm not really involved into MIPS 
development, so I really don't need it.

Cheers,
Martine

2018-05-18 15:28 GMT+02:00 Francisco Acosta >:

Hi Joakim!

On 18 May 2018 at 10:44:29, Joakim Nohlgård
(joakim.nohlg...@eistec.se ) wrote:
> Is this for pic32 HIL tests?
> Do the pic32 boards support jtag like the cortex boards? In that
case you
> could maybe use one of the ftdi ft2232 based jtag programmers
out there.
>

Unfortunately that’s not the case. They have a kind of serial
programming interface
which is not super standard. However there are several tools out
there which might
be useful here.

I’m thinking about pickit2 clones and compatible firmware which
might be the
solution in this case.

I’ll let you know whenever I have a more concrete solution.

Cheers,

Paco.

> /Joakim
>
> On Fri, May 18, 2018, 10:30 Kaspar Schleiser wrote:
>
> > 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

> >
> ___
> 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] makefile: info boards supported

2018-05-29 Thread Gaëtan Harter


Hi Jose,


for me it still makes sense to have commands to say "is it hardware 
supported" and a different one for "the board have enough memory when 
compiled in the reference environment".


The first one is a hard constraint and should never change (except by 
adding hardware support implementation), so it is really boards supported.
The second one is a soft constraint, it can change if the RIOT version 
string is not set to a fixed string like in CI and gets longer, you 
change a compile flag, if your gcc version is different, if you compile 
with DEVELHELP=1 or if you modify code in the main.c.

It is mainly an information for CI

So I would like to keep both.

There is already a trick to have access to the list of supported boards 
by using the debug command `make 
info-debug-variable-BOARD_INSUFFICIENT_MEMORY`.
A dedicated command could be added for this. I would even filter it with 
`BOARDS` if the variable is set.



But adding also a summary command could be useful for your need.


In my usage when testing, I mainly need to know "is my board supported", 
and then "has my board enough memory" and do not care about other boards 
so I set `BOARDS=my_board` for the `info-boards-supported` target.
I may also add dedicated commands for this instead of checking if my 
board is in the output.


Gaëtan

On 22.05.2018 11:52, Jose wrote:

Hello all,


I've been using the `make info-boards-supported` command for a RIOT 
related project. I need to show all supported boards for an 
application (examples, etc).



The problem I've found is the fact that `info-boards-supported` shows 
boards tagged by BOARD_INSUFFICIENT_MEMORY (so, in theory they can be 
compiled but strictly speaking they won't be supported by the board).



I know Murdock is currently using this command to compile all examples 
(and prevent linking them if they don't fit in the board). Would make 
sense to add another command that shows all boards that are 
(compile+flash) supported? I somehow feels "info-boards-supported" is 
misleading, but changing the name might be extra work since it's used 
by Murdock.



Comments? ;)


Cheers,

José

___
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] Transmission distance. Power profiler

2018-05-29 Thread Gaëtan Harter


Hi Janna,


just in case, note that the examples you gave in the iot-lab wiki were 
written for the iot-lab nodes port for Contiki.

So will not directly apply to RIOT for the macro names.


I understand that you can need both limiting power and increasing the 
threshold when you want to have a lower connectivity with the hardware 
deployment in IoT-LAB.




The "set_rssi_threshold" is currently not implemented in RIOT, but you 
could easily do it yourself (and do a PR maybe :))



The code I wrote in openlab was this one


https://github.com/iot-lab/openlab/commit/e1b7709b45d0fc926a15864e75081fbdd66c98fa 



https://github.com/iot-lab/openlab/commit/453b5205016cf508ee0bb1826f1a0cf31b13a096


And it could be adapted by using RIOT at86rf2xx API like:


https://github.com/RIOT-OS/RIOT/blob/master/drivers/at86rf2xx/at86rf2xx.c#L181-L183




From looking in the other at86rfxx drivers datasheets the configuration 
is the same but with different values for RSSI configuration



* at86rf231 page 103 
http://ww1.microchip.com/downloads/en/DeviceDoc/doc8111.pdf


* at86rf212b page 120 
http://ww1.microchip.com/downloads/en/DeviceDoc/Atmel-42002-MCU_Wireless-AT86RF212B_Datasheet.pdf


* at86rf233 page 113 
http://ww1.microchip.com/downloads/en/DeviceDoc/Atmel-8351-MCU_Wireless-AT86RF233_Datasheet.pdf



So the threshold definitions should be enclosed in the header with `#if  
MODULE_AT86RF231`.





Regards,

Gaëtan




On 28.05.2018 13:13, Janna Om wrote:

Hello,
i'm trying to reduce the transmission distance of iot-lab m3 sensor 
nodes.(The number of sensor nodes that can communicate directly with 
each other.)
I have used the solution proposed here 
https://github.com/iot-lab/iot-lab/wiki/Limit-nodes-connectivity. I 
could set the transmission power to -17dBm, but I couldn't find how to 
set the receiver sensitivity of the node. Is there a way in Riot to 
reduce the receiver sensitivity, or perhaps other ways to reduce the 
transmission range between the nodes?



Limit nodes connectivity · iot-lab/iot-lab Wiki · GitHub 


github.com
GitHub is where people build software. More than 27 million people use 
GitHub to discover, fork, and contribute to over 80 million projects.



I would also like to measure the energy consumption of nodes while 
running my application. Does the Riot have an approach like Contiki's 
power profiler?

Many thanks in advance!

With kind regards,
Janna



___
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] Host Name

2018-04-20 Thread Gaëtan Harter

Hello Jana,

in the IoT-LAB freertos port there is a dictionary for node short-id ->
node name:
https://github.com/iot-lab/openlab/blob/master/appli/iotlab/lib/iotlab_uid_num_hashtable.c

There is also the script to update it in case nodes have been changed.
You could adapt it in RIOT.
The short-id used is this one:
https://github.com/iot-lab/iot-lab/wiki/Lib-iotlab_uid.

If you are only interested in having your current node information, and
not resolve other nodes, you can also get this information from the
control node i2c link.

It is not really advertised but the code is available here:

https://github.com/iot-lab/openlab/blob/master/appli/iotlab/periph/iotlab_i2c/iotlab_i2c.c

https://github.com/iot-lab/openlab/blob/master/appli/iotlab/periph/iotlab_i2c/iotlab_i2c_.h

As I wrote it back then, I could do the port for RIOT if you are interested.

Regards,

Gaëtan

On 20.04.2018 03:58, Ludwig Knüpfer wrote:

Hello Jana,

If you're looking for a way to distinguish nodes based on their
hardware, this might be what you want:

http://riot-os.org/api/group__drivers__periph__cpuid.html

Cheers,
Ludwig

Am 19. April 2018 21:18:30 MESZ schrieb Janna Om :

Hello!
Is it possible with RIOT OS to get access to the host name?
I'm working with iot-lab m3 nodes and trying to get their ids or
host names.
I'm trying to make the node m3-id running my application to be
aware that its hostname is m3-id or that its ID = id.
Is there any possibility to achieve this goal.
Thank You in advance!

Kind regards,
Jana

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

Re: [riot-devel] Improve Documentation

2018-03-14 Thread Gaëtan Harter


Hi Josua,

it is also something I am interested in, not only an image but 
extracting informations on modules.


Could you put descriptive names on the informations you would be 
interested in?

And if you have some priorities in mind.

Also, if you have an example of something you wanted to know and had a 
hard time finding.


Regards,
Gaëtan

On 05.03.2018 12:06, Arndt, Josua wrote:


Joakim this sounds like you have some idea how to? Could you please 
elaborate?


Best regards,

Josua

*Von:* devel [mailto:devel-boun...@riot-os.org] *Im Auftrag von 
*Joakim Nohlgård

*Gesendet:* Donnerstag, 1. März 2018 16:42
*An:* RIOT OS kernel developers 
*Betreff:* Re: [riot-devel] Improve Documentation

I think this is certainly an interesting idea! You will probably not 
even need Doxygen for anything, plain graphviz (dot) is probably enough.


Best regards, Joakim

On Mar 1, 2018 16:21, "Arndt, Josua" > wrote:


Hello all,

as we are working on the PR to bring the Jiminy board to mainline
repo I had some problems to find where what is, or should be.

So I had the idea that a graph would help me visualize where which
module is implemented.

Something like this.

My idea was to maybe add a feature which uses doxygen to compile
dot graphs for a test/application and board.

So when executing “make doc board=Bordname” in the folder test_spi
then graphs for this project and board are created.

Maybe include graphs or such a Module, feature defines graph.

This would make it possible to just generate one graph for a test
and add this to the depending readme or wiki page.

When implementing you could fastly grasp which feature are
necessary and where they should be.

Also a comparison of the different cpu and boards could be done.

But for me the most important improvement would be I could build
this for a board and fastly grasp where which feature is implemented.

This would also help newcomers to get a fast overview  of what is
where.

Is there interest for such a feature? Does any one have an idea of
how to best implement this?




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

2018-02-26 Thread Gaëtan Harter


Hi,

I think that giving more precise APIs and removing the low level 
implementation detail from it is a good thing.
It means that the library can adapt to the current hardware and PM 
constraints.



I have questions regarding the transition to new timers.
As several modules have dependencies to xtimer both in headers or source 
files, they would need to be adapted to the new api.


Do you think that the new API could be implemented on top of the current 
xtimer with some glue code as a temporary solution ?
This would allow switching modules to the new API even if some boards 
still implement it with xtimer.



And just for precision regarding "removing 64bit time functions".
You want to remove all the 64bit arguments in timer API ?
This would mean that, when you want to say sleep "6hours" or "1 week", 
the developer should say he wants to use a 1second timer, and not the μs 
one.
Then, if there is only a μs timer, it would internally still be 
implemented as storing a 64b value somehow but at least its removed from 
the API.


I think its a good idea to put this in the API, because it gives more 
information to the timer library on what the developer wants to do.
In case where I have timers like "sleep(30 * USECS_PER_SEC)" in reality 
the timer does not need to even be precise at all.



The constraints I see with something like this, is give some precision 
control functionalities.


I would maybe want to control the trigger time offset if I repeat this 
sleep.
Its not a problem if it has a 0.5 seconds offset, but I would not like 
to have this offset adding over time.
So be sure that I can easily do, "trigger every N seconds, but do not 
drift over time".


Also, there may be cases where I would like to say "wake me up before 
XXX" instead of "wake me up after".
This could allow adapting for the last seconds with a higher precision 
timer if I need a more precise trigger time than the timer gives me.



Gaëtan

On 24.01.2018 23:37, Kaspar Schleiser wrote:

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

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

2018-01-05 Thread Gaëtan Harter


Hi all,


I want to give my opinion on the discussions that happened here in 
Berlin regarding the build system evolution.

And also, choose the direction for next development steps.



# Laze presentation #

Kaspar presented his new tool that replaces the current Make based build 
system based on a custom python software reading the configuration and 
generating `ninja` files to builds.

It uses YAML description for modules, application, and toolchain elements.


GOOD

* The YAML description is a good direction into what I need as a 
"descriptive language" for the modules.
* Using a meta build-system, removes the need to parse all the 
configuration from scratch each times an application is build which is a 
static time consumption for CI.

 It could be done in make but may be more cumbersome to write and maintain.
* Refined module build configuration to only show the needed flags and 
dependencies, it will help a lot for caching.

* I love python.

BAD

* Python is not a build system language, so not designed to do 'targets' 
generation but more executing commands after the other.
* Introducing our own custom build language framework instead of using 
an existing one, so a non standard tool.
* The build system implementation (how to parse yaml files, generate 
build rules), is not separated from the laze tool itself, so hard to 
have the implementation stored in the repository while having a generic 
tool installed globally.
* Many argument are based on speed, but the speed improvement are not 
all a result of using 'laze' only, but cleaning up concepts in general.



# Criticism of the current make build system #

However, I agree that our current build system has a lot of flaws that I 
would like to see solved.


* Its necessary to run `make clean` all the time because there are 
changes that do not correctly trigger rebuild, so you are never sure
* The module definition/configuration is not structured and descriptive 
so is problematic to provide finer granularity module building, all 
modules see all CFLAGS, INCLUDES, and included modules MODULE_ macros.
    * Its now impossible to cache results between applications as they 
are done with different config.
* Not all dependencies are explicitly described, so hard to understand 
the optional dependencies, the dependencies on interface, dependencies 
depending on configuration. This would also help refining module build 
configuration.
* Our current build system only takes care of building one application 
for one board. For the CI and maintainers, when building several 
targets, they must re-execute make from scratch for each configuration.
* And the initial  tool checking, is it linux, modules discovery, should 
be done every time. And this really adds up on many targets builds
    * It can only be solved correctly by first having structured module 
description as you can parse it once and apply it to different 
configurations
* There is no support for building in a common build directory so it 
takes a lot of space and also rebuilds multiple time the same thing.
    * It currently makes no sense, as module have different 
configurations, but after fixing the previous issues, one built module 
configuration could be shared between different apps, saving space and 
compile time.



# Next steps together #

To go forward and use what he developed as a possible solution, I 
proposed to start a documentation phase, on both his new system + YAML 
module format, and on what and how things are currently done in the 
build system.
Adding user and developer documentation for the current system would 
fill the lack of documentation and also help describing all the 
currently existing features, show the problems, find forgotten requirements.
And documenting his description format and his tool could show what are 
the benefits of his choices and also the tradeoffs.



One of my question is, is it interesting to integrate some changes in 
the current make system, like some early module description, even if 
replaced later by another build system ?


I will open issues on github to follow the next steps.

Cheers,
Gaëtan









On 01.12.2017 10:49, Kaspar Schleiser wrote:

Hi Matthias,

On 12/01/2017 10:29 AM, Matthias Waehlisch wrote:

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.


   Pointer?

https://github.com/kaspar030/RIOT/tree/add_laze_buildfiles

Don't expect a nice out-of-the-box experience (yet).

Kaspar
___
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] Updates to the build system - modules definition

2017-11-30 Thread Gaëtan Harter


Hi,

On 11/30/2017 11:52 AM, Kaspar Schleiser wrote:

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?
Its not specific to the current version of the interface, but to what I 
would like to achieve for the RAPstore project.
Configure a firmware using a graphical interface by selecting modules 
and configuring them.



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

USEMODULE += module_name?

In our context, it could be important to know the consequences of this.
On my computer, when I say 'aptitude install PACKAGE' I am informed of 
the additional dependencies.
Here with interdependencies, and modules affecting the global 
configuration it can be more important than this.


The cbor_ctime pseudomodule, when used with newlib, makes every source 
files compile with -DGNU_SOURCE=1.

I would not know that when simply adding it to USEMODULE.


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?
Regarding 'interdependency', I think about module that behave 
differently => are compiled differently if another module is included.

The optional dependencies that affect either your code or your API.

Adding this to a definition would help as documentation. It still allow 
specific requirements, still allows strange architecture for compilation 
optimization, but at least its said somewhere.


It took me some time to understand that `at86rf231` and `at86rf212b` are 
pseudomodules and are both implemented by `at86rf2xx` which is compiled 
differently depending on which one is included. 'git grep at86rf231' 
says nothing about it.


It would of course require tooling to help writing and maintaining these 
modules definition.
And even more for each information that the build system is not using 
and enforcing.



Gaëtan


Kaspar
___
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] Warning on compilation

2017-11-30 Thread Gaëtan Harter


Hi Baptiste,


using '-Wall -Wextra' by default was finally added just two days ago 
https://github.com/RIOT-OS/RIOT/pull/7919/.

But maybe other warnings could be interesting to add you are right.
I like statically checking as many things as possible.

"All the warnings options", depends on the compiler version of each 
target, and gcc or clang, so may not all be available.
Also, some warnings may be problematic for us if they are often just 
false positive.


If you found warnings that could be a good idea to fix, you can propose 
a PR with them, this way its easier to review with the CI build output.


In the list, not all are adding warnings, like '-pipe' or '-std=gnu99', 
-ffunctions-sections (which is already used).

And also -fno-strict-aliasing which removes important check.

Cheers,
Gaëtan


On 11/30/2017 04:20 PM, Baptiste Clenet wrote:

Hi,

I'm using samr21-xpro and I tried to add same warning options than
Atmel Studio for RIOT:

-pipe -fno-strict-aliasing -Wall -Wstrict-prototypes
-Wmissing-prototypes -Werror-implicit-function-declaration
-Wpointer-arith -std=gnu99 -ffunction-sections -fdata-sections
-Wchar-subscripts -Wcomment -Wformat=2 -Wimplicit-int -Wmain
-Wparentheses -Wsequence-point -Wreturn-type -Wswitch -Wtrigraphs
-Wunused -Wuninitialized -Wunknown-pragmas -Wfloat-equal -Wundef
-Wshadow -Wbad-function-cast -Wwrite-strings -Wsign-compare
-Waggregate-return  -Wmissing-declarations -Wformat
-Wmissing-format-attribute -Wno-deprecated-declarations -Wpacked
-Wredundant-decls -Wnested-externs -Wlong-long -Wunreachable-code
-Wcast-align --param max-inline-insns-single=500

I got long list of warnings.
Why RIOT does not used all the warning options?

Cheers,


___
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

2017-11-30 Thread Gaëtan Harter


Hi Thomas, Francisco, all,

I will try to summarize with three aspects formatted as problems.

Just for clarity, in the following text, use the words 'description', 
'informations', 'configuration', 'dependencies' to describe all the 
meta-information that can be attached to a module in addition to its 
source code.



I also am in demand of other issues that you have and that should be 
taken into account if the current system is refactored.
So I invite you to talk about your case too, I want to start discussions 
before working on it.


Also I welcome all remarks regarding my problems and the way I want to 
address them.



 1. Configuration is not documented

As Francisco is saying, about configuring an application and so its modules.
The problem, for me, is that its hard to know the possible 
configurations of a module and the impact of the configuration/dependencies.



   Details:

When building an application, I need to:

 * describe what I want to use in my application, which usually means
   saying which module/package I want
 * configure the application and the modules, by using either specific
   variables `DEVELHELP`, `OUTPUT` or manually setting CFLAGS
 * Specify requirements to work only on boards with this hardware support.

 * But it also means understanding the impact of adding a specific
   module / setting one configuration

Right now the impact is tedious to find. A dependency pulled by one 
module can have an impact on another module code, on its API, on all 
modules.
And modules configuration, is often only described into the doxygen or 
the source code: what CFLAGS should I put to configure the radio channel ?


I would like to clearly write down these public configurations and 
dependencies relations.



 2. Information is not readable

The module information cannot be presented and re-interpreted to show on 
a graphical interface.
It is not machine readable, and the same way of defining things has 
multiple meaning.



   Details:

I would need to have parseable files usable by an automated system, 
which is currently not the case.


For my needs, it would be necessary to refine the current information to 
make it more precise.
The 'dependencies' and configurations now used in the build system can 
be ambiguous to present because they have different meaning.


 * Some optional dependencies have different impact, they:
 o can change the source code behavior
 o can change the module API
 o can affect every modules
 * The same goes for configuration, is the configuration affecting the
   module API ?



 3. Modules definition is scattered but in RIOT global files

The meta-information on a module is not grouped together with the module 
but written in 3-4 files global to the RIOT repository.
This means reading different files to get a complete view on a module 
but also that it is not possible to use external modules trees without 
modifying the RIOT repository.



   Details:

I would like to make modules self contained. I think it would help 
developers as it improves readability and documentation by having only 
one place to understand a module.
Also, external modules would be defined in the same way as internal ones 
by just adding a tree of modules to load.



   Bonus. Unnecessary globally visible configuration

A bonus aspect that I would like to tackle in the long term when the 
updates would be in place.


Right now all CFLAGS/INCLUDES are global to all modules.
This means a different version of the `core` module is build if another 
high level module is included or has its configuration changed.


Having more informations on modules dependencies and configuration scope 
could help refine this.



 Details:

Having a determined context would makes tests more reliable, because we 
could know which configuration has been tested and which not.
It would require explicit build system configuration to make a 
configuration affect another module.
Solving this could allow doing build caching at a the build system level 
when build with common local context.
I am also interested in reproducible builds and so being able to 
describe what has been build with the minimal information required and 
verifying the produced output.



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.


Cheers,
Gaëtan - cladmi


On 11/27/2017 04:39 PM, Francisco Javier Acosta Padilla wrote:

Hi,

I think the problem to solve is that RIOT is very difficult to configure.

While working with other IoT operating systems, one can notice that 
RIOT is very hardly configurable, unless we are very familiar with the 
build system and specific RIOT CFLAGS and special key-words 
(USEMODULE, USEPKG, etc…).


Besides, I have no knowledge of a tool that can p

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

2017-11-24 Thread Gaëtan Harter



On 11/24/2017 04:55 PM, Martine Lenders wrote:

Hi Daniel,

2017-11-24 16:47 GMT+01:00 Daniel Petry >:


[…]

1) Move build information concerning a particular module into that
module's Makefile
2) Make the module makefiles able to be written with purely
declarative
language
3) Retain backwards compatibility with the current build system


 I don't think it is possible this way and I don't think that's what 
Gaëtan meant. Makefiles demand to be in make's language, so you can't 
just make up your own declarative language in them. You could however 
use some declaritive language files like json or yaml and generate 
Makefiles from them (or let make parse them).



Hi,

I may have mixed 'Makefile' and file written in a 'GNUMake' language in 
my description.


They address different steps of the build:
* Makefile is when you actually compile the source files to an archive 
with a given configuration (CC, CFLAGS, INCLUDES)
* All the Makefile.dep/Makefile.include/Makefile.features files that 
prepare this configuration and say which Makefile to execute


And its the part of configuration I would like to address.
Regarding `Makefile` I just want to remove the `DIRS +=` part of it.


What I want is add another file `module.desc` grouping the existing 
information and metadata on the module:

* Submodule
* is it a pseudomodule
* includes path
* dependencies
* global CFLAGS
* … and add more.

Regarding the "purely declarative", I would like to express it in 
GNUMake syntax and restrict to setting specially named variables.
My rational about this, is that if its written in XML, and let make 
parse them, it is still required to translate the information to 
variables that the make build system can understand.
So still needs to have a syntax to describe, for example, that a module 
has an optional dependency on another, and so be definable in a gnu make 
syntax.


Cheers,
Gaëtan


Cheers,
Martine



___
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

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

2017-11-23 Thread Gaëtan Harter


Dear RIOT developers,

I would like to introduce some packaging concepts around RIOT.
To consider modules like well defined distribution packages and not only 
source files added to an application firmware. This would allow software 
architecture/configuration informations to be parseable by external 
tools without reading source code and without an application context.


My need is allowing a graphical interface to describe, configure 
applications with possibly external modules and generate the Makefile.


I want to start a task force on this in two weeks after some preliminary 
discussions on the concepts.



 Current state

Some of these module information is already present but not in a easy to 
get way so it does not fit my need.


To highlight some of the problems:

 * it is scattered in different centralized files
 o Makes it hard to add external modules
 o Needs different files to get one module metadata
 * some is defined in a Turing complete language
 o Hard to parse
 o only available in a compilation context
 * some information/configuration only in source files


 Implementation

I am thinking about adding declaratively defined information/metadata on 
modules distributed to each module directory. This could be achieved by
changing to a new build system with these features already included. 
However, integration into the current build system would be preferred in 
order to be able

to incrementally integrate, test and document new changes.


   Roadmap

 * Initial feedback period of two weeks
 * Define and break down intermediate tasks
 * Iteration cycles on each sub task and integration


 Further steps

I would like to gather feedback on the concept here, and find interested 
people to start working on it, for reviewing, advices, giving their 
constraints and implementing if you have time.


I will give a two weeks time limit for the initial review until I start 
working onthis.


Thank you in advance.

Cheers,
Gaëtan
___
devel mailing list
devel@riot-os.org
https://lists.riot-os.org/mailman/listinfo/devel

[riot-devel] RFC: packaging "start_network.sh" on IoT-LAB

2017-04-11 Thread Gaëtan Harter


Dear RIOT developers,


Iam working on packaging an equivalent of gnrc_border_router 
"start_network.sh" script for IoT-LAB.


The reason why I need to adapt it is that users are not root on the ssh 
frontend, and that the frontend is shared between different users.
So I give sudo permissions for one executable, verify given arguments 
and execute ethos/uhcpd as regularuser so serial ports can be accessed.


I would like to have your feedback on the tool so I could fix things 
before release.



### The steps I do: ###

 * Verify the given prefix is unused
 * Create TAP interface
 * Allow INPUT traffic on the frontend forUDP:[ff15::abcd]:12345
 * Call uhcpd in the background with cap-net-raw capability so that it
   can use --bind-to-device
 * Run ethos
 * Correctly cleanup everything in case of error and experiment stop


### What I removed from "start_network.sh:###

 * Adding the local hard-writtenaddress: "ip a a fd00:dead:beef::1/128
   dev lo"


### Important to know ###

Currentlyip6tables are dropping all input on thessh frontend, so it can 
only be used as a client.(That's why I needed to allow traffic for uhcpd).
The original reason is to prevent users to run a public server on the 
frontend.
And even with private addresses, the user would have no way to secure it 
from other users with iptables, or binding to aspecificinterface.



For tunslip6, I also add the address PREFIX::1/64 on the tun0 interface, 
I could do something similar for ethos.



### Running the wrapper ###

The current arguments are:

   |ethos_uhcpd.py [-h] [--verbose] host tap ipv6_prefix
   |

|The output:|
||

   |sudo ethos_uhcpd.py --verbose m3-1 tap0 fd00::/64
   DEBUG:root:Calling: ip tuntap add tap0 mode tap user harter
   DEBUG:root:Calling: sysctl -w net.ipv6.conf.tap0.forwarding=1
   net.ipv6.conf.tap0.forwarding = 1
   DEBUG:root:Calling: sysctl -w net.ipv6.conf.tap0.accept_ra=0
   net.ipv6.conf.tap0.accept_ra = 0
   DEBUG:root:Calling: ip link set tap0 up
   DEBUG:root:Calling: ip addr add fe80::1/64 dev tap0
   DEBUG:root:Calling: ip route add fd00::/64 via fe80::2 dev tap0
   DEBUG:root:Calling: ip6tables -A INPUT -i tap0 -d ff15::abcd -p udp
   --dport 12345 -j ACCEPT
   DEBUG:root:Calling: /usr/bin/python -m iotlabsudo.execuser
   --cap-net-raw -- /opt/ethos_tools/bin/uhcpd tap0 fd00::/64
   --bind-to-device
   DEBUG:root:Calling: /usr/bin/python -m iotlabsudo.execuser --path
   /sbin -- /opt/ethos_tools/bin/ethos tap0 tcp:m3-1
   Switch from 'root' to 'harter'
   Switch from 'root' to 'harter'
   Joining IPv6 multicast group...
   entering loop...
   > ethos: sending hello.
   > ethos: activating serial pass through.
   > ethos: hello reply received


> help
   help
   Command  Description
   ---
   reboot   Reboot the node
   ps   Prints information about running threads.
   ping6Ping via ICMPv6
   random_init  initializes the PRNG
   random_get   returns 32 bit of pseudo randomness
   ifconfig Configure network interfaces
   fibroute Manipulate the FIB (info: 'fibroute [add|del]')
   ncache   manage neighbor cache by hand
   routers  IPv6 default router list
   6ctx 6LoWPAN context configuration tool
> uhcp_client(): no reply received
   uhcp_client(): sending REQ...
   got packet from fe80::221:d3ff:fe60:5a8d port 12345
   got packet from fe80::50c1::fe5d:a1c7 port 40483
   uhcp: push from fe80::50c1::fe5d:a1c7:40483 prefix=fd00::/64
   gnrc_uhcpc: uhcp_handle_prefix(): got same prefix again
   uhcp_client(): sending REQ...
   got packet from fe80::221:d3ff:fe60:5a8d port 12345
   got packet from fe80::e034:28ff:fe26:6ac3 port 49575
   uhcp: push from fe80::e034:28ff:fe26:6ac3:49575 prefix=fd00::/64
   gnrc_uhcpc: uhcp_handle_prefix(): got same prefix again||
   |||

|||And the interface|looks like:

   84: tap0:  mtu 1500 qdisc
   pfifo_fast state UP group default qlen 500
link/ether 52:c1:ff:5d:a1:c7 brd ff:ff:ff:ff:ff:ff
inet6 fe80::50c1::fe5d:a1c7/64 scope link
   valid_lft forever preferred_lft forever
inet6 fe80::1/64 scope link
   valid_lft forever preferred_lft forever


This is the current state, and with some documentation it could be 
released as is.



I thank you in advance for your feedback

Regards,
Gaëtan Harter - IoT-LAB Team

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

Re: [riot-devel] Riot on iot-lab

2016-05-25 Thread Gaëtan Harter


On 05/25/2016 06:17 PM, Oleg Hahm wrote:

Gaëtan,

On Wed, May 25, 2016 at 06:10:47PM +0200, Gaëtan Harter wrote:

- adding support of samr21-xpro boards as new custom nodes. Of course, I
wrote a firmware code based on RIOT for the continuous integration system
;). But to make it fully compatible with what the CI is expecting, I had to
patch slightly the RIOT shell code by removing the echo of the input command
and the display of the prompt character ('>'). This patch is based on
compiler options (SHELL_NO_PROMPT and SHELL_NO_ECHO) which are not set by
default. Would you accept such a contribution ? (I know it doesn't really
help RIOT).

Out of curiosity: what is different for the samr21-xpro nodes compared to the
"regular" iotlab-m3 nodes where we don't need this patch?

For M3 and A8-M3 nodes, the test firmwares are written using openlab.

thanks for the explanation. So, we're talking here actually not about the code
that the user is supposed to run, but about the software used for internal
tests?


Exactly




For samr21-xpro, as it is not supported by openlab, we thought it would be a
good idea to write this firmware using RIOT.

Sounds like a splendid idea to me, too. ;-)


In the same time it would give us a firmware compilable with platforms
supported by RIOT.

Then, adding support for any RIOT compatible board on IoT-LAB would only be
adding administration code.

Cool.

Cheers,
Oleg


___
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 on iot-lab

2016-05-25 Thread Gaëtan Harter


Hi Oleg,

On 05/25/2016 05:52 PM, Oleg Hahm wrote:

Hi Alex!

On Wed, May 25, 2016 at 09:00:04AM +0200, Alexandre Abadie wrote:

Don't know if it's the best place for asking this.

I think the mailing list is a good place for this discussion. :)


- adding support of samr21-xpro boards as new custom nodes. Of course, I
wrote a firmware code based on RIOT for the continuous integration system
;). But to make it fully compatible with what the CI is expecting, I had to
patch slightly the RIOT shell code by removing the echo of the input command
and the display of the prompt character ('>'). This patch is based on
compiler options (SHELL_NO_PROMPT and SHELL_NO_ECHO) which are not set by
default. Would you accept such a contribution ? (I know it doesn't really
help RIOT).

Out of curiosity: what is different for the samr21-xpro nodes compared to the
"regular" iotlab-m3 nodes where we don't need this patch?

For M3 and A8-M3 nodes, the test firmwares are written using openlab.

For samr21-xpro, as it is not supported by openlab, we thought it would 
be a good idea to write this firmware using RIOT.
In the same time it would give us a firmware compilable with platforms 
supported by RIOT.


Then, adding support for any RIOT compatible board on IoT-LAB would only 
be adding administration code.



Regards,
Gaëtan - IoT-LAB Team



Cheers,
Oleg


___
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] Help needed: iotlab-m3 accessory quest.

2016-04-20 Thread Gaëtan Harter


Hi Andreas,

I asked my colleague and we have no more left here.
When looking on Farnell/RadioSpare which sell them by 1-10 if needed, 
they don't have the 26pins models.


Also he mentioned that the models we used are made to be machine 
soldered on printed circuit boards.

So not easily usable for manual soldering on pin's.

So maybe Martine solution would be easier in this case.


Regards,
Gaëtan - IoT-LAB Team

On 04/20/2016 12:45 AM, Francisco Javier Acosta Padilla wrote:

Hi all,

Since this board was produced in a fixed quantity (and AFAIK is no 
more in production) is not likely to find some pieces with this 
connector so far. So, as Martine said, the most simple solution would 
be to solder directly some cables, which I know is very ugly. The 
other solution could be to break an existing open node to take away 
the female connector.


You can try to contact the HiKOB guys 
(http://www.hikob.com/en/contact/) who designed the boards and ask if 
they can send you the connector, in case of they have one.


Cheers,

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

On 19 April 2016 at 19:33:35, Martine Lenders (authmille...@gmail.com 
) wrote:



Hi Paul,

as far as I know the solution most other developers used were to just 
solder cables directly to the plug. But maybe we can find a nicer 
solution with the help of the IoT-Lab people :D.


Cheers,
Martine

Am 19.04.2016 19:08 schrieb "Andreas "Paul" Pauli" 
mailto:andreas.pa...@haw-hamburg.de>>:


Dear RIOT developers,

I'm desperately searching for plug connectors fitting the "open
node connector" on the iotlab-m3. I'd like to improve access to
the pins with my measurement equipment.
The sources I found so far, only take orders of at least 100
pieces. All I need is just a handful.

Any helpful hints?

thanks in advance
Paul
___
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] RPL as fix for the border router issue

2016-04-19 Thread Gaëtan Harter


Out of mailing-list:

Hi Martin,

Regarding manual-configuration for RPL, the way contiki is doing it to 
prevent manual config on the border router is bypassing the network 
layers and doing kind of horrible things.


As I see most RIOT like a linux host, if I should do the same stuff 
dynamically I would be using ssh to configure the host with the adapted 
addresses/interfaces/routes.

Or a script run at startup wih configuration files.

So what about a RIOT shell script (with expect on the serial line?) to 
configure it "automatically with a manually run script".
This way, there could be a start_network script which would take care of 
everything automatically with manual configuration anyway.



So even if I would love to have RPL border routers now to use on IoT-LAB 
I agree with not bypassing the manual configuration in a quick-fix way.



Regards,
Gaëtan - IoT-LAB Team

On 04/18/2016 05:36 PM, Martine Lenders wrote:

Hi,
at the f2f meeting today we Oleg proposed to have RPL run on the
border router as an alternative to [1] (since RPL always uses
link-local addresses as next hop, the neighbor cache would never be
asked for GUAs). This seemed to work (it ran for about 30 min), but we
(Cenk, Hauke and I) discussed that the manual configuration for RPL
currently needed is a big negative point in light of the fully
automated border router configuration. And while we could implement a
half-assed bootstapping mechanism until tomorrow, we decided against
this solution and stick with [1] for this release and have it done
properly instead with a proper interface bootstrapping/configuration
mechanism at some point in the future.

Cheers,
Martine

[1] https://github.com/RIOT-OS/RIOT/pull/5309
___
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] Configure Raspberry Pi as 802.15.4/6LoWPAN Border Gateway

2015-08-17 Thread Gaëtan Harter


Hi,

to get an IPv6 connection for testing on any host you can use an ipv6 
over ipv4 tunnel.
Either by setting it manually using one of your university server 
(http://www.tldp.org/HOWTO/Linux+IPv6-HOWTO/chapter-configuring-ipv6-in-ipv4-tunnels.html) 
or using a tunnel provider.


When testing 6LowPAN with IoT-LAB long time ago, I used 'gogo6' that 
provides /56 for free http://www.gogo6.com/freenet6/tunnelbroker and 
it's enough for testing.


Regards,
Gaëtan

On 08/03/2015 06:38 PM, Oleg Hahm wrote:

Hi Tobias!


with the help of other developers, I successfully got a Raspberry Pi with
the Openlabs 802.15.4 radio adapter [0] working as a 802.15.4 and 6LoWPAN
border gateway.

Nice work. I was able to reproduce your settings and it works pretty good.


A border gateway running Linux should allow adding more gateway and
translation functions useful for the IoT.

Unfortunately, I'm not able to test this part since I don't have an IPv6
connection from the Raspberry PI to any other computer (due to university
restrictions).


The configuration process, including example. can be found on the wiki [1]
and is tested with the Linux configuration on that page and current master
of RIOT.

I updated and fixed some minor glitches in the documentation. Great work!

Cheers,
Oleg


___
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] Measuring power on the iot-lab testbed

2015-04-26 Thread Gaëtan Harter


Hi Peter,

don't worry, I think it's an IoT-Lab problem.
Some nodes have this unstable consumption graph, it's tracked on the 
following issue:


https://github.com/iot-lab/iot-lab/issues/148

Can you try with one "good" node: like Grenoble 1+9+12 and see if the 
problem remains?



I added iot-lab admin as CC to let us follow the discussions.

Regards,
Gaëtan - IoT-Lab team

On 04/25/2015 05:13 PM, Peter Kietzmann wrote:

Hi devs,

after measuring the consumption of an iot-lab_M3 node (on the iot-lab 
testbed) I can't explain myself the graph of the measured power over 
time in [1] (please note that I zoomed the plot to better visualize 
the problem). It is just the normal example in 
RIOT/examples/hello-word. You can find my measuring profile which I 
used on the testbed in [2].


(i) There is a sawtooth-signal where one tooth lasts approx. 30 seconds
(ii) There is some kind of cycle which pulses each 1.5 seconds (This 
seems to be a "known" problem of the measurement unit)


Any ideas what this is or where it comes from?

Best,
Peter

[1] 
https://drive.google.com/file/d/0B2ig4jIQ4JbHSWpvaTZyOGRCb00/view?usp=sharing
[2] 
https://drive.google.com/file/d/0B2ig4jIQ4JbHS3FVdTc0TnZ5eDA/view?usp=sharing 





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

Re: [riot-devel] More convenient access to the IoT-LAB from a RIOT application

2015-03-19 Thread Gaëtan Harter


Hi Oleg,

I think it's a good idea, it will allow easier runnig RIOT code on the 
platform.

I will write feedback directly on the PR.

Regards,
Gaëtan

On 03/18/2015 07:23 PM, Oleg Hahm wrote:

Dear rewewing IoTlers,

I just opened a pull request in RIOT that should ease the work with RIOT
applications on the IoT-LAB testbed a little bit:
https://github.com/RIOT-OS/RIOT/pull/2640

Including the proposed Makefile like

  include $(RIOTBASE)/dist/Makefile.iot-lab

in an application's Makefile allows to create IoT-LAB experiments, flash,
reset and access the nodes right from the command line with Make in one go,
e.g. executing

export BOARD=iot-lab_M3
make iotlab-auth
make iotlab-exp IOTLAB_NODES=10 IOTLAB_DURATION=60 IOTLAB_SITE=grenoble
make iotlab-flash
make iotlab-term

will reserve an experiment for 10 nodes and 60 minutes in Grenoble, flash the
current application to all nodes and starts serial_aggregator for these nodes.

Let me know what you think about this idea and what could be improved.

Cheers,
Oleg


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


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

50 matches

Mail list logo