[riot-devel] Leaving the project

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,

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

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

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

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

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

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-devel] Upcoming `CPU` and `CPU_MODEL` definition migration.

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

Re: [riot-devel] LWM2M using ethos

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

Re: [riot-devel] CC2538dk Riotboot support

ists 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 `rio

Re: [riot-devel] CC2538dk Riotboot support

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, if you only use the default `riotboot

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

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

Re: [riot-devel] CC2538dk Riotboot support

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, if you only use

Re: [riot-devel] CC2538dk Riotboot support

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

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

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

Re: [riot-devel] Hello world stopped working

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

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

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

Re: [riot-devel] Notification: Hack'n'ACK @ Tue Oct 30, 2018 5pm - 10pm (CET) (RIOT Events)

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 -

Re: [riot-devel] shell and putchar

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

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

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

Re: [riot-devel] Git submodule in RIOT-OS/applications

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-devel] Build system API change, central definition of `test` target

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

[riot-devel] Enable CORS on Murdock

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

[riot-devel] Release 2018.07

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

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

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

[riot-devel] Preparing release 2018.07 - RC2

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

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

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

[riot-devel] Notes RIOT internal Meeting Friday 20.04.2018

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

Re: [riot-devel] General configuration Task Force

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

[riot-devel] Preparing release 2018.07

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,

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

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

Re: [riot-devel] PIC programmer with Linux support?

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

Re: [riot-devel] makefile: info boards supported

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

Re: [riot-devel] Host Name

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

Re: [riot-devel] Improve Documentation

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

Re: [riot-devel] Timers

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

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

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

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

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

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

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

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

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

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

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 f

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

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

Re: [riot-devel] Help needed: iotlab-m3 accessory quest.

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

Re: [riot-devel] RPL as fix for the border router issue

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

Re: [riot-devel] Configure Raspberry Pi as 802.15.4/6LoWPAN Border Gateway

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

Re: [riot-devel] Measuring power on the iot-lab testbed

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

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

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