[riot-devel] The default location where package sources are fetched has changed

[Alexandre Abadie]

Dear RIOTers,

Last friday we merged [1] which refactored the default location where package 
sources are fetched. Until then, they were fetched in the application build 
directory, e.g. in "/bin/pkg//". This was 
inefficient because packages were fetched each time the application was built 
for a new board and thus was consuming unnecessary disk space.

The new strategy is now to fetch the package sources in a global and unique 
location, under "$(RIOTBASE)/build/pkg/". This way the packages are 
fetched only once, during the very first build of an application that requires 
them. The fetched source are not duplicated anymore, so this saves disk space.

Note that this new strategy is only possible when the packages are built 
"out-of-source": when all build files (*.o, *.a, etc) are created outside of 
the package source tree. The RIOT build system and CMake allows for that so 
packages built with the RIOT module mechanism (with "include 
$(RIOTBASE)/Makefile.base" somewhere) or CMake can benefit from the global 
location. This is the case for most of the available packages in RIOT, except 
Micropython (custom Makefile) and OpenThread (autotools). For those two, the 
build uses the old behavior: packages are fetched and build within the 
application build directory.

If you have worked on implementing a new package for RIOT, you'll have to 
rebase and adapt your package Makefile. The change is minimal, use other 
existing packages as examples.

If you have any comments or questions, feel free to ask here.

Regards,

Alex

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

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

[Alexandre Abadie]

Hi,

> I'll look at LOW_MEMORY_BOARDS, but if other SAMD21 don't need it, then
> my board
> shouldn't need it either.

All other SAMD21 boards with stdio over USB are in this list so I think yours 
should be there as well :)

> I've seen strange problems with
> puts/printf, where
> part of the output is missing (and thus I get test timeouts).

Same here, I think there's an issue stdio over USB. If the string to be printed 
starts with a space or a tab, it's not printed over USB.

Alex

- Le 1 Juin 20, à 10:58, Kees Bakker k...@ijzerbout.nl a écrit :

> Thanks Alex,
> 
> The tests that need sudo, I've skipped. For now I don't care about
> these. I was able to
> rerun quite a few tests by skipping the ones that caused the the board
> to hang. I also
> skip all the tests that need sudo. For now I don't care about these.
> 
> I'll look at LOW_MEMORY_BOARDS, but if other SAMD21 don't need it, then
> my board
> shouldn't need it either.
> 
> I also need to look at my execution environment. I don't docker (yet),
> so maybe I'm
> using incompatible gcc and/or newlib. I've seen strange problems with
> puts/printf, where
> part of the output is missing (and thus I get test timeouts).
> -- Kees
> 
> On 31-05-2020 21:40, Alexandre Abadie wrote:
>> Hi Kees,
>>
>> Indeed that's a lot of failures!
>>
>> Regarding the failures during flash, the flashing over USB workflow is rather
>> fragile: if something went wrong (a crash) when testing an application, the
>> board might no recover and cannot be flashed automatically anymore after.
>> There's also the issue with connecting the terminal application to stdio that
>> can timeout sometimes.
>>
>> The main issues are with the "failures during test" list. I tried some of 
>> them
>> on arduino-mkr1000 and also got failures. So there are bugs.
>>
>> Note that you can run each of them individually using "make BOARD=> board>
>> -C tests/ flash test". This is what is called by the
>> "compile_and_test_board.py" script.
>>
>> Regarding "tests/bench_xtimer", you can fix the build issue by adding your 
>> board
>> to the LOW_MEMORY_BOARDS list [1]. For the other build failures, I guess some
>> Python packages are missing. Maybe add BUILD_IN_DOCKER=1 to the test command.
>>
>> Alex
>>
>> [1] 
>> https://github.com/RIOT-OS/RIOT/blob/master/tests/bench_xtimer/Makefile#L7
>>
>> - Le 31 Mai 20, à 21:06, Kees Bakker k...@ijzerbout.nl a écrit :
>>
>>> Let me explain a little bit more why I am struggling right now.
>>>
>>> First thing you should know is that I'm creating the support for
>>> a new SODAQ board (Sara SFF).
>>>
>>> Second, I haven't run the automated tests before, so I don't
>>> know what to expect.
>>>
>>> The complete run gives me the result below. No need to comment
>>> on it. I just wanted to let you know what I have to chew on. I will
>>> probably get back with more questions.
>>>
>>> ERROR:sodaq-sara-sff:Tests failed: 110
>>> Failures during compilation:
>>> - [tests/bench_xtimer](tests/bench_xtimer/compilation.failed)
>>> - [tests/pkg_nanopb](tests/pkg_nanopb/compilation.failed)
>>> - [tests/suit_manifest](tests/suit_manifest/compilation.failed)
>>>
>>> Failures during test:
>>> - [examples/micropython](examples/micropython/test.failed)
>>> - [tests/bench_runtime_coreapis](tests/bench_runtime_coreapis/test.failed)
>>> - [tests/bench_sizeof_coretypes](tests/bench_sizeof_coretypes/test.failed)
>>> - [tests/bloom_bytes](tests/bloom_bytes/test.failed)
>>> - [tests/cond_order](tests/cond_order/test.failed)
>>> -
>>> [tests/cpp11_condition_variable](tests/cpp11_condition_variable/test.failed)
>>> - [tests/cpp11_mutex](tests/cpp11_mutex/test.failed)
>>> - [tests/cpp11_thread](tests/cpp11_thread/test.failed)
>>> - [tests/gnrc_ipv6_nib_dns](tests/gnrc_ipv6_nib_dns/test.failed)
>>> - [tests/mutex_order](tests/mutex_order/test.failed)
>>> - [tests/periph_gpio](tests/periph_gpio/test.failed)
>>> - [tests/periph_rtt](tests/periph_rtt/test.failed)
>>> - [tests/periph_timer](tests/periph_timer/test.failed)
>>> - [tests/periph_timer_periodic](tests/periph_timer_periodic/test.failed)
>>> -
>>> [tests/periph_timer_short_relative_set](tests/periph_timer_short_relative_set/test.failed)
>>> - [tests/periph_uart_nonblocking](tests/periph_uart_nonblocking/test.failed)
>>> - [tests/periph_wdt](tests/periph_wdt/test.failed)
>>> - [tests/p

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

[Alexandre Abadie]

lash.failed)
> - [tests/cpp_ext](tests/cpp_ext/test.flash.failed)
> - [tests/driver_apds99xx](tests/driver_apds99xx/test.flash.failed)
> - [tests/driver_apds99xx_full](tests/driver_apds99xx_full/test.flash.failed)
> - [tests/driver_bme680](tests/driver_bme680/test.flash.failed)
> - [tests/driver_ds1307](tests/driver_ds1307/test.flash.failed)
> - [tests/driver_grove_ledbar](tests/driver_grove_ledbar/test.flash.failed)
> - [tests/driver_hd44780](tests/driver_hd44780/test.flash.failed)
> - [tests/driver_my9221](tests/driver_my9221/test.flash.failed)
> - [tests/embunit](tests/embunit/test.flash.failed)
> - [tests/emcute](tests/emcute/test.flash.failed)
> - [tests/float](tests/float/test.flash.failed)
> - [tests/fmt_print](tests/fmt_print/test.flash.failed)
> - [tests/gnrc_dhcpv6_client](tests/gnrc_dhcpv6_client/test.flash.failed)
> -
> [tests/gnrc_dhcpv6_client_6lbr](tests/gnrc_dhcpv6_client_6lbr/test.flash.failed)
> - [tests/gnrc_ipv6_ext](tests/gnrc_ipv6_ext/test.flash.failed)
> - [tests/gnrc_ipv6_ext_frag](tests/gnrc_ipv6_ext_frag/test.flash.failed)
> - [tests/gnrc_ipv6_ext_opt](tests/gnrc_ipv6_ext_opt/test.flash.failed)
> - [tests/gnrc_ipv6_fwd_w_sub](tests/gnrc_ipv6_fwd_w_sub/test.flash.failed)
> - [tests/gnrc_ipv6_nib](tests/gnrc_ipv6_nib/test.flash.failed)
> - [tests/gnrc_ipv6_nib_6ln](tests/gnrc_ipv6_nib_6ln/test.flash.failed)
> - [tests/gnrc_ndp](tests/gnrc_ndp/test.flash.failed)
> - [tests/gnrc_netif](tests/gnrc_netif/test.flash.failed)
> - [tests/gnrc_rpl_p2p](tests/gnrc_rpl_p2p/test.flash.failed)
> - [tests/gnrc_rpl_srh](tests/gnrc_rpl_srh/test.flash.failed)
> - [tests/gnrc_sixlowpan](tests/gnrc_sixlowpan/test.flash.failed)
> - [tests/gnrc_sixlowpan_frag](tests/gnrc_sixlowpan_frag/test.flash.failed)
> -
> [tests/gnrc_sixlowpan_iphc_w_vrb](tests/gnrc_sixlowpan_iphc_w_vrb/test.flash.failed)
> -
> [tests/gnrc_sock_async_event](tests/gnrc_sock_async_event/test.flash.failed)
> - [tests/gnrc_sock_dns](tests/gnrc_sock_dns/test.flash.failed)
> - [tests/gnrc_sock_ip](tests/gnrc_sock_ip/test.flash.failed)
> - [tests/gnrc_sock_neterr](tests/gnrc_sock_neterr/test.flash.failed)
> - [tests/gnrc_sock_udp](tests/gnrc_sock_udp/test.flash.failed)
> - [tests/gnrc_tcp](tests/gnrc_tcp/test.flash.failed)
> - [tests/heap_cmd](tests/heap_cmd/test.flash.failed)
> - [tests/irq](tests/irq/test.flash.failed)
> - [tests/irq_disable_restore](tests/irq_disable_restore/test.flash.failed)
> - [tests/isr_yield_higher](tests/isr_yield_higher/test.flash.failed)
> - [tests/kconfig](tests/kconfig/test.flash.failed)
> - [tests/l2util](tests/l2util/test.flash.failed)
> - [tests/libc_newlib](tests/libc_newlib/test.flash.failed)
> - [tests/log_color](tests/log_color/test.flash.failed)
> - [tests/log_printfnoformat](tests/log_printfnoformat/test.flash.failed)
> - [tests/lwip_sock_ip](tests/lwip_sock_ip/test.flash.failed)
> - [tests/lwip_sock_tcp](tests/lwip_sock_tcp/test.flash.failed)
> - [tests/lwip_sock_udp](tests/lwip_sock_udp/test.flash.failed)
> - [tests/malloc](tests/malloc/test.flash.failed)
> - [tests/memarray](tests/memarray/test.flash.failed)
> - [tests/msg_avail](tests/msg_avail/test.flash.failed)
> - [tests/msg_send_receive](tests/msg_send_receive/test.flash.failed)
> - [tests/msg_try_receive](tests/msg_try_receive/test.flash.failed)
> - [tests/mtd_flashpage](tests/mtd_flashpage/test.flash.failed)
> - [tests/mtd_mapper](tests/mtd_mapper/test.flash.failed)
> - [tests/pkg_tensorflow-lite](tests/pkg_tensorflow-lite/test.flash.failed)
> - [tests/stdin](tests/stdin/test.flash.failed)
> - [tests/vfs_plus_stdio](tests/vfs_plus_stdio/test.flash.failed)
> -
> [tests/xtimer_mutex_lock_timeout](tests/xtimer_mutex_lock_timeout/test.flash.failed)
> -
> [tests/xtimer_periodic_wakeup](tests/xtimer_periodic_wakeup/test.flash.failed)
> 
> 
> On 30-05-2020 22:19, Kees Bakker wrote:
>> Well, not easier for me, I'm afraid. It will delay adding my board
>> even longer (which is already several months in progress).
>> And it's just a hobby for me. Otherwise it begins to look like
>> work :-)
>>
>> Nevertheless, I'll see what I can do.
>>
>> On 30-05-2020 22:14, Alexandre Abadie wrote:
>>> Hi,
>>>
>>> You can just put all of them in the same issue. It will be easier to track. 
>>> That
>>> is what is done in [1].
>>>
>>> Alex
>>>
>>> [1] https://github.com/RIOT-OS/RIOT/issues/12651
>>>
>>> - Le 30 Mai 20, à 21:42, Kees Bakker k...@ijzerbout.nl a écrit :
>>>
>>>> OK, first one created. I'm afraid there are many more to come.
>>>>
>>>> On 30-05-2020 21:27, Alexandre Abadie wrote:
>>>>> Hi Kees,
>>>>>
>>>>> To my 

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

[Alexandre Abadie]

Hi,

You can just put all of them in the same issue. It will be easier to track. 
That is what is done in [1].

Alex

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

- Le 30 Mai 20, à 21:42, Kees Bakker k...@ijzerbout.nl a écrit :

> OK, first one created. I'm afraid there are many more to come.
> 
> On 30-05-2020 21:27, Alexandre Abadie wrote:
>> Hi Kees,
>>
>> To my knowledge, there is no wiki page for this kind of thing.
>> The simplest is probably to open an issue and list there the failures with 
>> their
>> output. This way we can easily track the on going work to fix them.
>>
>> See [1] as an example.
>>
>> Alex
>>
>> [1] https://github.com/RIOT-OS/RIOT/issues/12651
>>
>> - Le 29 Mai 20, à 23:14, Kees Bakker k...@ijzerbout.nl a écrit :
>>
>>> Hi,
>>>
>>> Now that I'm happily running automated tests for my SAMD21 board(s) I am
>>> wondering which tests should succeed. There are several that fail, but I
>>> don't know if that "normal" or not.
>>>
>>> Some examples of test that fail
>>>
>>> xtimer_periodic_wakeup: hangs at the end, last couple of printf don't
>>> come out
>>> tests/thread_flood: [ERROR] expected 30, created 29
>>>
>>> Is there maybe a wiki with the status of the tests (per board?).
>>> --
>>> 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

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

[Alexandre Abadie]

Hi Kees,

To my knowledge, there is no wiki page for this kind of thing.
The simplest is probably to open an issue and list there the failures with 
their output. This way we can easily track the on going work to fix them.

See [1] as an example.

Alex

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

- Le 29 Mai 20, à 23:14, Kees Bakker k...@ijzerbout.nl a écrit :

> Hi,
> 
> Now that I'm happily running automated tests for my SAMD21 board(s) I am
> wondering which tests should succeed. There are several that fail, but I
> don't know if that "normal" or not.
> 
> Some examples of test that fail
> 
> xtimer_periodic_wakeup: hangs at the end, last couple of printf don't
> come out
> tests/thread_flood: [ERROR] expected 30, created 29
> 
> Is there maybe a wiki with the status of the tests (per board?).
> --
> 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

Re: [riot-devel] Problem with test connecting to ttyACM0

[Alexandre Abadie]

Ok, I replied in the meantime :)

Good to know that you solved your issue!

- Le 27 Mai 20, à 22:04, Kees Bakker k...@ijzerbout.nl a écrit :

> Found it.
> 
> There is a MAKE_TERM_CONNECT_DELAY that defaults to 0. This is the time
> between "make reset" and "make cleanterm".
> 
> In my case (and I'm guessing, all boards with Arduino bootloader) you
> need a brief delay, for example 2 seconds.
> 
> The default of MAKE_TERM_CONNECT_DELAY can be overruled by setting
> envvar TESTRUNNER_CONNECT_DELAY.
> 
> Hurray, my first successful test
> 
> $ TESTRUNNER_CONNECT_DELAY=3
> ~/src/RIOT/dist/tools/compile_and_test_for_board/compile_and_test_for_board.py
> ~/src/RIOT sodaq-sara-sff ~/src/RIOT/results --applications
> tests/evtimer_msg
> INFO:sodaq-sara-sff:Saving toolchain
> INFO:sodaq-sara-sff.tests/evtimer_msg:Board supported: True
> INFO:sodaq-sara-sff.tests/evtimer_msg:Board has enough memory: True
> INFO:sodaq-sara-sff.tests/evtimer_msg:Application has test: True
> INFO:sodaq-sara-sff.tests/evtimer_msg:Run compilation
> INFO:sodaq-sara-sff.tests/evtimer_msg:Run test
> INFO:sodaq-sara-sff.tests/evtimer_msg:Run test.flash
> INFO:sodaq-sara-sff.tests/evtimer_msg:Success
> INFO:sodaq-sara-sff:Tests successful
> 
> On 27-05-2020 21:31, Kees Bakker wrote:
>> Alexandre, do you have a suggestion?
>> Anyone?
>>
>> On 26-05-2020 21:59, Kees Bakker wrote:
>>> Hi,
>>>
>>> My setup is more or less correct. When I do
>>> $ BOARD=sodaq-sara-sff make -C tests/evtimer_msg flash term
>>> ...
>>> 2020-05-26 21:50:39,186 # Are the reception times of all 4 msgs close to
>>> the supposed values?
>>> 2020-05-26 21:50:39,187 # At   2361 ms received msg 0: "#2 supposed to
>>> be 2361"
>>> 2020-05-26 21:50:39,187 # At   2702 ms received msg 1: "#0 supposed to
>>> be 2701"
>>> 2020-05-26 21:50:39,670 # At   3202 ms received msg 2: "#1 supposed to
>>> be 3202"
>>> 2020-05-26 21:50:42,116 # At   5656 ms received msg 3: "#3 supposed to
>>> be 5656"
>>> 2020-05-26 21:50:42,127 # By now all msgs should have been received
>>> 2020-05-26 21:50:42,127 # If yes, the tests were successful
>>>
>>> It connects nicely to the /dev/ttyACM0 with all the expected
>>> output.
>>>
>>> However, when I make the "test" target it fails to find /dev/ttyACM0
>>>
>>> $ BOARD=sodaq-sara-sff make RIOT_CI_BUILD=1 CC_NOCOLOR=1
>>> --no-print-directory -C /home/kees/src/RIOT/tests/evtimer_msg test
>>> r
>>> /home/kees/src/RIOT/dist/tools/pyterm/pyterm -p "/dev/ttyACM0" -b
>>> "115200" --no-reconnect --noprefix --no-repeat-command-on-empty-line
>>> Connect to serial port /dev/ttyACM0
>>> could not open port /dev/ttyACM0: [Errno 2] No such file or directory:
>>> '/dev/ttyACM0'
>>> make[1]: *** [/home/kees/src/RIOT/Makefile.include:726: cleanterm] Error 2
>>> Traceback (most recent call last):
>>>   File "/usr/lib/python3/dist-packages/pexpect/spawnbase.py", line 166,
>>> in read_nonblocking
>>>     s = os.read(self.child_fd, size)
>>> OSError: [Errno 5] Input/output error
>>>
>>> In fact, I'm trying to run compile_and_test_for_board.py, but that fails
>>> on the "make test" command.
>>>
>>> Is there a timeout value somewhere that needs to be increased?
>> ___
>> 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] Problem with test connecting to ttyACM0

[Alexandre Abadie]

Hi,

There's the TESTRUNNER_CONNECT_DELAY environnement variable that can be set for 
this purpose from the board Makefile.include file.
This is normally used for any samd21 based board with an Arduino bootloader. 
Maybe increase the TERM_DELAY variable from the command line or in the 
Makefile.include here [1].

Alex

[1] 
https://github.com/RIOT-OS/RIOT/blob/master/boards/common/samd21-arduino-bootloader/Makefile.include#L27

- Le 27 Mai 20, à 21:31, Kees Bakker k...@ijzerbout.nl a écrit :

> Alexandre, do you have a suggestion?
> Anyone?
> 
> On 26-05-2020 21:59, Kees Bakker wrote:
>> Hi,
>>
>> My setup is more or less correct. When I do
>> $ BOARD=sodaq-sara-sff make -C tests/evtimer_msg flash term
>> ...
>> 2020-05-26 21:50:39,186 # Are the reception times of all 4 msgs close to
>> the supposed values?
>> 2020-05-26 21:50:39,187 # At   2361 ms received msg 0: "#2 supposed to
>> be 2361"
>> 2020-05-26 21:50:39,187 # At   2702 ms received msg 1: "#0 supposed to
>> be 2701"
>> 2020-05-26 21:50:39,670 # At   3202 ms received msg 2: "#1 supposed to
>> be 3202"
>> 2020-05-26 21:50:42,116 # At   5656 ms received msg 3: "#3 supposed to
>> be 5656"
>> 2020-05-26 21:50:42,127 # By now all msgs should have been received
>> 2020-05-26 21:50:42,127 # If yes, the tests were successful
>>
>> It connects nicely to the /dev/ttyACM0 with all the expected
>> output.
>>
>> However, when I make the "test" target it fails to find /dev/ttyACM0
>>
>> $ BOARD=sodaq-sara-sff make RIOT_CI_BUILD=1 CC_NOCOLOR=1
>> --no-print-directory -C /home/kees/src/RIOT/tests/evtimer_msg test
>> r
>> /home/kees/src/RIOT/dist/tools/pyterm/pyterm -p "/dev/ttyACM0" -b
>> "115200" --no-reconnect --noprefix --no-repeat-command-on-empty-line
>> Connect to serial port /dev/ttyACM0
>> could not open port /dev/ttyACM0: [Errno 2] No such file or directory:
>> '/dev/ttyACM0'
>> make[1]: *** [/home/kees/src/RIOT/Makefile.include:726: cleanterm] Error 2
>> Traceback (most recent call last):
>>   File "/usr/lib/python3/dist-packages/pexpect/spawnbase.py", line 166,
>> in read_nonblocking
>>     s = os.read(self.child_fd, size)
>> OSError: [Errno 5] Input/output error
>>
>> In fact, I'm trying to run compile_and_test_for_board.py, but that fails
>> on the "make test" command.
>>
>> Is there a timeout value somewhere that needs to be increased?
> 
> ___
> 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] How to make my boards appear in the info-boards-supported list

[Alexandre Abadie]

Hi Kees,

This is not normal, they should appear. This is a bug in the build system. I 
tried locally and could reproduce.

The best would be to open an issue on GitHub that describes the problem.

Alex

- Le 24 Mai 20, à 23:32, Kees Bakker k...@ijzerbout.nl a écrit :

> Hey,
> 
> I want to run tests on my SODAQ board(s), but they don't
> appear in the output of
>   make -C examples/hello-world info-boards-supported
> 
> What are they missing?
> --
> 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

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

[Alexandre Abadie]

Hi, 

While browsing the opened PRs, I think the USB support for STM32 should also go 
in that release: [1] 

Alex 

[1] https://github.com/RIOT-OS/RIOT/pull/12556 

- Le 13 Déc 19, à 14:15, Francois-Xavier Molina 
 a écrit : 

> Dear RIOTers,

> This is a friendly reminder for you to send your suggestions for features you
> would like to see merged
> during this release cycle.

> Best regards, and happy hacking!

>> De: "Francois-Xavier Molina" 
>> À: "devel" , "users" 
>> Envoyé: Jeudi 28 Novembre 2019 09:59:05
>> Objet: Release [2020.01] - dates and feature requests

>> Dear RIOTers,

>> The release dates for the upcoming release cycle are fixed as follows:
>> - 08.01.2020 - soft feature freeze, for high impact features

>> - 15.01.2020 - hard feature freeze, for all features

>> - 05.02.2020 - 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!
>> Francisco Molina

> ___
> 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] Release [2020.01] - dates and feature requests

[Alexandre Abadie]

Hi there, 

Sorry for the late reply. 

I have some suggestions of new features that I'd like to see in the release: 
- add the arduino bootloader feature to samd21 based boards (arduino-mkr, sodaq 
and feather-m0). That would improve a lot the user experience with these 
boards. See [1] for details. 
- some PRs related to AI (TensorFlow) on microcontrollers: [2], [3] and [4]. 
- a series of PRs to improve the hifive1 port [5], [6], [7], [7bis] and another 
one to come, 
- it would be good to finally merge [8] (kw41z radio) 
- still in radio drivers, maybe also [9] (at86rf215) 
- it would be great to merge the PR about external BOARDSDIR variable [10] 

There are many more things that could go in the release but as usual, they need 
reviews. 

Cheers! 

Alex 

[1] https://github.com/RIOT-OS/RIOT/pull/12304 
[2] https://github.com/RIOT-OS/RIOT/pull/12805 
[3] https://github.com/RIOT-OS/RIOT/pull/12846 
[4] https://github.com/RIOT-OS/RIOT/pull/12847 
[5] https://github.com/RIOT-OS/RIOT/pull/12663 
[6] https://github.com/RIOT-OS/RIOT/pull/12902 
[7] https://github.com/RIOT-OS/RIOT/pull/12917 
[7bis] https://github.com/RIOT-OS/RIOT/pull/10833 
[8] https://github.com/RIOT-OS/RIOT/pull/12277 
[9] https://github.com/RIOT-OS/RIOT/pull/12128 
[10] https://github.com/RIOT-OS/RIOT/pull/12183 

- Le 28 Nov 19, à 9:59, Francois-Xavier Molina 
 a écrit : 

> Dear RIOTers,

> The release dates for the upcoming release cycle are fixed as follows:
> - 08.01.2020 - soft feature freeze, for high impact features

> - 15.01.2020 - hard feature freeze, for all features

> - 05.02.2020 - 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!
> Francisco Molina

> ___
> 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] Release 2019.07 - dates and feature requests

[Alexandre Abadie]

Hi, 

USB support would be a major milestone for RIOT. It would be awesome to have it 
in the next release. 

I would like to see the following things in the next release: 
- LwM2M support, see [1] 
- Support for WolfSSL (provides secure sockets, DTLS, etc), see [2] 

I think both are already in a good shape, just missing reviews and testing. 

Alex 

[1] https://github.com/RIOT-OS/RIOT/pull/11036 
[2] https://github.com/RIOT-OS/RIOT/pull/10308 

- Le 1 Juin 19, à 18:42, Dylan Laduranty  a écrit 
: 

> 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 < [
> mailto:hauke.peter...@fu-berlin.de | hauke.peter...@fu-berlin.de ] > 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 < [
>>> mailto:kevin.we...@haw-hamburg.de | kevin.we...@haw-hamburg.de ] > 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
 [ mailto:devel@riot-os.org | devel@riot-os.org ]
 [ https://lists.riot-os.org/mailman/listinfo/devel |
 https://lists.riot-os.org/mailman/listinfo/devel ]

>>> ___
>>> devel mailing list [ mailto:devel@riot-os.org | devel@riot-os.org ] [
>>> https://lists.riot-os.org/mailman/listinfo/devel |
>>> https://lists.riot-os.org/mailman/listinfo/devel ]

>> ___
>> devel mailing list
>> [ mailto:devel@riot-os.org | devel@riot-os.org ]
>> [ https://lists.riot-os.org/mailman/listinfo/devel |
>> https://lists.riot-os.org/mailman/listinfo/devel ]

> --
> Dylan Laduranty

> ___
> 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] Release 2019.01

[Alexandre Abadie]

Dear RIOTers,

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

--- * RIOT 2019.01 * ---

The 2019.01 release includes a number of new features including DMA support on
all STM32 boards, WiFi with IP connectivity on ESP32 and ESP8266, and riotboot,
a simple bootloader supporting multiple firmware slots, compatible with most Arm
Cortex-M boards supported by RIOT. Support for several new boards and new 
sensors
was added, as well as for the new CPU architecture Armv8-M (Cortex-M23). Last
but not least, this release contains a number of bug fixes and enhances test
automation.

About 387 pull requests with about 912 commits have been merged since the last
release and about 36 issues have been solved. 54 people contributed with code
in 110 days. Approximately 1554 files have been touched with 176241 insertions
and 50593 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,
Alex & Emmanuel


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

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

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

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

Re: [riot-devel] just got my Vega

[Alexandre Abadie]

Hi,

> Who's interested in collaborating on bringing RIOT onto the thing?

I also received mine today so I can also help. Maybe one day there will be some 
in IoT-LAB.

Alex

- Le 12 Fév 19, à 12:53, Kaspar Schleiser kas...@schleiser.de a écrit :

> Hey fellow RIOT'ers,
> 
> I've just received a VEGAboard (rv32m1-vega).
> 
> It's feature list is very promising. On-board BLE/802.15.4, plenty of
> RAM and flash, (apparently) specs & reference manuals for everything.
> I'm curious how it's power consumption will be.
> 
> I think it'll be a challenge integrating the thing properly. It has five
> cores with different instruction sets, four of them on the same bus, if
> I read the datasheet correctly. I'm also very looking forward to see
> messages floating between the cores! ;)
> 
> Who's interested in collaborating on bringing RIOT onto the thing?
> 
> Kaspar
> 
> ___
> devel mailing list
> devel@riot-os.org
> https://lists.riot-os.org/mailman/listinfo/devel
___
devel mailing list
devel@riot-os.org
https://lists.riot-os.org/mailman/listinfo/devel

[riot-devel] Release 2019.01 feature freeze

[Alexandre Abadie]

Dear RIOTers,

We've created the 2019.01 release branch, so we are now officially in
feature freeze. This means from now only bugfixes will be backported to
the `2019.01-branch`.

New features can still be merged into master during this period.

The tracking issue of Release candidate 1 [1] is opened.
If you want to perform some manual tests, please put your name on the 
corresponding items.
Tasks 01 and 02 will be done automatically.

Thanks all for the awesome work!

Best regards,

Alex & Emmanuel

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

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

[Alexandre Abadie]

Here is the missing link for [1]: https://github.com/RIOT-OS/RIOT/milestone/25

Alex

- Le 19 Déc 18, à 11:39, Alexandre Abadie alexandre.aba...@inria.fr a écrit 
:

> Dear RIOTers,
> 
> Release 2019.01 is coming very soon but Emmanuel and I will be taking care of
> the release process to make this one another success.
> 
> The important dates are fixed as follows:
> 
> - pre-feature freeze for high impact features: January 11th, 2018
> - final feature freeze: January 18th, 2018
> - final release date: we hope to have the next release on January 31th
> 
> Please contact us on this mailing-list if you have features you would really
> want to have, and if you think they would be ready for the release.
> Also remember to update and rebase your PRs that you want review for.
> 
> Issues and PRs targetting this release are listed on GitHub at [1].
> 
> We wish you a merry hacking!
> 
> Cheers,
> 
> Alex & Emmanuel
> ___
> 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] Preparing release 2019.01

[Alexandre Abadie]

Dear RIOTers,

Release 2019.01 is coming very soon but Emmanuel and I will be taking care of 
the release process to make this one another success.

The important dates are fixed as follows:

- pre-feature freeze for high impact features: January 11th, 2018
- final feature freeze: January 18th, 2018
- final release date: we hope to have the next release on January 31th

Please contact us on this mailing-list if you have features you would really 
want to have, and if you think they would be ready for the release.
Also remember to update and rebase your PRs that you want review for.

Issues and PRs targetting this release are listed on GitHub at [1].

We wish you a merry hacking!

Cheers,

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

Re: [riot-devel] Nucleo-f767zi on-board Ethernet

[Alexandre Abadie]

Hi Robin,

Thanks for your interest into RIOT and STM32 boards.

There is an (old) existing PR [1] that tries to add an Ethernet driver for 
stm32f4. Maybe it's not very different for F7 and you could use it as a 
starting point ?

Regards,

Alex

[1] https://github.com/RIOT-OS/RIOT/pull/5643

- Le 14 Déc 18, à 14:49, Robin ro...@chilio.net a écrit :

> Hi all,
> 
> 
> i just got access to an Nucelo F767zi board (STM32 MCU) with an on-board
> Ethernet Controller attached via RMII.
> 
> Since i found no existing netdev driver for this hardware configuration
> nor any related pull requests I plan to do an implementation by myself.
> 
> 
> I just wanted to ask if anybody already has experiences with the
> on-board ethernet and may got some useful tips or information?
> 
> 
> Thanks in advance & Regards
> 
> Robin
> 
> ___
> 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

[Alexandre Abadie]

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

[riot-devel] New nodes available on IoT-LAB

[Alexandre Abadie]

Dear RIOT users and developpers,

Today the IoT-LAB team released multiple types of open nodes on the Saclay 
site. You can find the details on the IoT-LAB website [1].

These new nodes should simplify the testing on heterogeneous hardware and help 
in verifing their interoperability. Most of them are already supported by RIOT 
(nRF52DK, nRF52840DK, FRDM-KW41Z, phyNode, microbit, B-L4752-IOT01A and SAMR30 
Xplained), some are not (nRF51DK and nrf52840-MDK) but PRs are already opened 
[2], [3]. Finally, there are also PRs that provides radio drivers for some of 
them, [4] and [5].
In IoT-LAB, we hope that having these nodes in IoT-LAB will help reviewing 
these PRs and increase the quality and stability of the RIOT code base.

Regards,

Alex

[1] https://www.iot-lab.info/deployment/saclay/
[2] https://github.com/RIOT-OS/RIOT/pull/10409 
[3] https://github.com/RIOT-OS/RIOT/pull/9833
[4] https://github.com/RIOT-OS/RIOT/pull/7107
[5] https://github.com/RIOT-OS/RIOT/pull/10268
___
devel mailing list
devel@riot-os.org
https://lists.riot-os.org/mailman/listinfo/devel

Re: [riot-devel] Cortex M33 support

[Alexandre Abadie]

Hi,

Not M33, but Microchip is also selling an evaluation board with an M23.

See 
https://uk.farnell.com/microchip/dm320205/kit-eval-xplained-pro-32-bits/dp/2901261

Alex

PS: I'm not working on it.

- Le 17 Oct 18, à 14:17, Juan Ignacio Carrano j.carr...@fu-berlin.de a 
écrit :

> Hi everyone,
> 
> Is anybody working / wanting to work on Cortex M33 support? Currently
> there are no chips available for the general public. AFAICT Nordic and
> NXP are the only ones with pre-production parts.
> 
> I'm trying to get samples from both. It would be great if we could have
> at least some basic support for when the devices reach the market.
> 
> Also, if somebody has closer contact with either Nordic or NXP, it would
> be great.
> 
> Regards,
> 
> Juan Ignacio Carrano
> 
> ___
> 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] Driver design rules in RIOT

[Alexandre Abadie]

- Le 26 Sep 18, à 13:44, Gunar Schorcht gu...@schorcht.net a écrit :

> Cool, that's exactly what I was looking for.
> 
> Unfortunaly, it seem not to be reachable from the top level wiki page or
> I missed it. The only way to find is to use a search engine.

Maybe it could be moved in a specific section of the doxygen documentation.

> 
> On 26.09.2018 13:31, Hauke Petersen wrote:
>> Hi,
>> 
>> long done :-)
>> 
>> See
>> https://github.com/RIOT-OS/RIOT/wiki/Guide:-Writing-a-device-driver-in-RIOT
>> 
>> Cheers,
>> Hauke
>> 
>> On 09/26/2018 11:11 AM, Emmanuel Baccelli wrote:
>>> Hi there,
>>>
>>> based on this exchange,
>>> is there matter for a wiki page on this?
>>> (Or for alternative documentation,
>>> e.g. reviving the concept of RDM [1] ?)
>>>
>>> Best
>>>
>>> Emmanuel
>>>
>>> [1] https://github.com/RIOT-OS/RIOT/pull/6191
>>>
>>>
>>> On Wed, Sep 26, 2018 at 11:38 AM Gunar Schorcht >> > wrote:
>>>
>>> Hi Hauke,
>>>
>>> many thanks for your comprehensive and clearifying answers. Most
>>> of them
>>> met my thoughts about driver design.
>>>
>>> >> - Should a driver support at least data-ready interrupts (if
>>> possible at
>>> >> all) to realize event-driven data retrieval?
>>> > If the driver comes with a 'full/extra' configuration, this is
>>> part of
>>> > it anyway, right? In the simples 'basic' configuration I don't think
>>> > this needs to be part of I would say.
>>>
>>> Agreed.
>>>
>>> >> - Should a driver always return normalized/converted data, or
>>> rather
>>> >> return the raw data and the application needs to convert them? The
>>> >> conversion is sometimes quite complex. I saw both approaches of
>>> them for
>>> >> similar sensors.
>>> > My opinion is quite clear: I am always in favor of returning
>>> > normalized/converted data. In 90% of the cases the conversion is not
>>> > expensive, so just do it. In those rare cases, where the
>>> conversions is
>>> > actually relatively expensive, we can always fall back by providing
>>> > additional `xx_read_raw()` or similar functions, that allow to
>>> access
>>> > the data before conversion.
>>>
>>> Agreed. All the drivers I wrote til now, either return
>>> normalized/converted and raw data with same read function or offer an
>>> additional read_raw function.
>>>
>>> >> The design rules that are clear to me are:
>>> >>
>>> >> - Drivers have to provide an interface for polling with init
>>> and read
>>> >> that is compatible with SAUL.
>>> > that is a nice to have, but not a MUST.
>>>
>>> Ok.
>>>
>>> >> - Output are always 16 bit integers.
>>> > Not quite true. The SAUL interface is build around 16-bit
>>> integers, and
>>> > at least when reading/writing data via SAUL the data needs to be
>>> > converted. But the driver specific interface can always use
>>> other data
>>> > types/lengths. If it is however easily possible to use int16,
>>> one should
>>> > use it.
>>>
>>> Ok.
>>>
>>> >> What else?
>>> > All this information should go into the 'device driver guide'
>>> >
>>> 
>>> (https://github.com/RIOT-OS/RIOT/wiki/Guide:-Writing-a-device-driver-in-RIOT).
>>> > This guide needs however still work - and I will not have the
>>> time to do
>>> > it. So it would be nice if other people can help here :-)
>>>
>>> Agreed.
>>>
>>> Regards
>>> Gunar
>>>
>>> --
>>> Wenn du laufen willst, lauf eine Meile. Wenn du ein neues Leben
>>> kennenlernen willst, dann lauf Marathon. (Emil Zatopek)
>>>
>>> ___
>>> 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
>> 
> 
> 
> --
> Wenn du laufen willst, lauf eine Meile. Wenn du ein neues Leben
> kennenlernen willst, dann lauf Marathon. (Emil Zatopek)
> 
> 
> ___
> 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: Monthly RIOT developer meeting @ Mon Sep 24, 2018 4pm - 5pm (CEST) (RIOT Events)

[Alexandre Abadie]

Hi,

The jitsi link doesn't work.

Alex

- Le 24 Sep 18, à 15:46, francisco acosta francisco.aco...@inria.fr a écrit 
:

> Hi RIOTers!
> 
> Well, there’s the developers meeting today, and I’d like to
> take the opportunity to talk about some recent things on RIOT,
> e.g. build system and dependencies, which might touch other
> topics as well.
> 
> Please fill the agenda at  [1] and let’s meet using jitsi at
> [2].
> 
> Cheers!
> 
> Francisco Javier Acosta Padilla
> Research Engineer at INFINE team
> Inria Saclay Ile-de-France
> 
> [1] https://pad.inria.fr/p/np_GNLfEaDEVl7HoytA_riot_devel_24092018
> [2] https://jitsi.tools.ietf.org/riot-devel
> 
> On 23 September 2018 at 16:00:30, Google Calendar
> (calendar-notificat...@google.com) wrote:
>> This is a notification for:
>>  
>> Title: Monthly RIOT developer meeting
>> When: Mon Sep 24, 2018 4pm – 5pm Central European Time - Berlin
>> Where: Online
>> Calendar: RIOT Events
>> Who:
>> * Martine Lenders - creator
>>  
>> Event details:
>> https://www.google.com/calendar/event?action=VIEW=NnFpMGh0a2RpajN0OWQ3bjhoa3VmdWdiMTFfMjAxODA5MjRUMTQwMDAwWiBrM3FsOHNldHY3bDQ4b2Zub2wwdGZ1dTZ0c0Bn=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
___
devel mailing list
devel@riot-os.org
https://lists.riot-os.org/mailman/listinfo/devel

Re: [riot-devel] What's the password of the user in RIOT-LORA-VM

[Alexandre Abadie]

Hi Kees,

- Le 16 Sep 18, à 12:47, Kees Bakker k...@sodaq.com a écrit :

> It was nice to meet you at the RIOT event. 

Same here, unfortunately we couldn't discuss more. At least now I can put a 
face on your name :)

> Thanks for all the work you put into this. For me it was also beneficial 
> because
> I never had much experience with LoRa, and with your tutorial
> I learned about how to use the keys and such.

Thanks a lot for this message.
And to be complete, I'd also like a add another thanks to Jose (@jia200x) for 
his help. He improved the LoRaWAN part of the tutorial quite a bit.

For those interested, the instructions of the tutorial are on github: 
https://aabadie.github.io/riot-course/slides/tutorial-summit-2018/#1

> Anyway, what is the password of the user "user" in the VM?

The user password is 'user' (without quotes).

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

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

[Alexandre Abadie]

Hi,

- Le 22 Aoû 18, à 12:31, Kaspar Schleiser kas...@schleiser.de a écrit :

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

+1 for storing the images on the wiki.

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

Re: [riot-devel] [riot-users] End of I2C embargo

[Alexandre Abadie]

Wonderful news! 
Many thanks a lot Dylan for managing this huge rework and also to all people 
involved. 

Alex 

- Le 2 Aoû 18, à 12:49, Dylan Laduranty  a écrit 
: 

> Dear RIOTers,

> The I2C rework is now merged into RIOT's master branch, then I am really happy
> to announce you the end of the I2C embargo ! Don't hesitate to ping pending 
> PRs
> that were blocked by this embargo so maintainers can have a look at it.

> This rework will not be present in the 2018.07 release as we lack of time to 
> get
> things merged, but you can use the master branch if you want to use it.

> We also create a wiki page [1] to summarize the changes introduced by this
> rework. We will keep working to improve this documentation.

> Of course, we cannot guarantee that the new I2C interface is completely
> bug-free. So if you encounter any errors, weird behaviour or if you have any
> questions, don't hesitate to send an email to the mailing list or create an
> issue on Github. We will continue to improve our work.

> Finally, I would like to deeply thanks every people involved in this huge
> rework, thank you for your time and your hard will. I'm really proud of what 
> we
> have done here ! You guys are amazing :)

> Keep RIOTing !

> [1] [ https://github.com/RIOT-OS/RIOT/wiki/I2C-rework |
> https://github.com/RIOT-OS/RIOT/wiki/I2C-rework ]

> --
> Dylan Laduranty

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

[riot-devel] RIOT Hackathon in Paris

[Alexandre Abadie]

Dear RIOTers,

We are organizing a 4 days hackathon, May 22-25th in Paris. 
Information about this event can be found on the wiki [1].

Everyone is welcome to participate!

Attendance is free, but registration is mandatory on the wiki.
To register, put your name on the list, and either add yourself to an existing 
topic, or list a new topic. 

Doubts? Questions? PM or reply to this thread ;)

Thanks!

Alex

[1] https://github.com/RIOT-OS/RIOT/wiki/Hackathon-in-Paris-May-22-25,-2018
___
devel mailing list
devel@riot-os.org
https://lists.riot-os.org/mailman/listinfo/devel

Re: [riot-devel] SPI on Arduino Zero for AT86RF233

[Alexandre Abadie]

Hi, 

Not sure it will help but I recently tried to use a Semtech LoRa radio with an 
Arduino Zero and using a second SPI (for the radio) was working with the 
following configuration: 
{ 
.dev = >SPI, 
.miso_pin = GPIO_PIN(PA, 19), 
.mosi_pin = GPIO_PIN(PA, 16), 
.clk_pin = GPIO_PIN(PA, 17), 
.miso_mux = GPIO_MUX_C, 
.mosi_mux = GPIO_MUX_C, 
.clk_mux = GPIO_MUX_C, 
.miso_pad = SPI_PAD_MISO_3, 
.mosi_pad = SPI_PAD_MOSI_0_SCK_1 
} 

in the driver params, I had this line for the SPI: 
#define SX127X_PARAM_SPI (SPI_DEV(1)) 

Let us know if it works for you. 

Alex 

- Mail original -

> Hey,

> I’m trying to use the AT86RF233 with the Arduino M0 Pro (using the Arduino
> Zero configuration).

> Using the default SPI configuration (and pins) didn’t work, why I tried to
> change the SPI to the Arduino_Pins 11,12,13 in order to have CS (PIN 10)
> using the same SERCOM as the other SPI pins.

> However, I didn’t get it to work and it seems that using SPI with SERCOM1
> does not initialize.

> Is there anything I did completely wrong or is it just a stupid idea to
> connect the AT86RF233 with an Arduino M0?

> SPI Config in arduino/periph_conf.h:

> static const spi_conf_t spi_config[] = {
> {
> .dev = >SPI,
> .miso_pin = ARDUINO_PIN_ICSP_MISO,
> .mosi_pin = ARUDINO_PIN_ICSP_MOSI,
> .clk_pin = ARUDINO_PIN_ICSP_CLK,
> .miso_mux = GPIO_MUX_D,
> .mosi_mux = GPIO_MUX_D,
> .clk_mux = GPIO_MUX_D,
> .miso_pad = SPI_PAD_MISO_0,
> .mosi_pad = SPI_PAD_MOSI_2_SCK_3
> }
> ,
> {
> .dev = >SPI,
> .miso_pin = ARDUINO_PIN_12,
> .mosi_pin = ARDUINO_PIN_11,
> .clk_pin = ARDUINO_PIN_13,
> .miso_mux = GPIO_MUX_D,
> .mosi_mux = GPIO_MUX_D,
> .clk_mux = GPIO_MUX_D,
> .miso_pad = SPI_PAD_MISO_3,
> .mosi_pad = SPI_PAD_MOSI_0_SCK_1
> }
> };

> at86rf2xx_params.h:

> #ifndef AT86RF2XX_PARAM_SPI
> #define AT86RF2XX_PARAM_SPI (SPI_DEV( 1 ))
> #endif
> #ifndef AT86RF2XX_PARAM_SPI_CLK
> #define AT86RF2XX_PARAM_SPI_CLK (SPI_CLK_5MHZ)
> #endif
> #ifndef AT86RF2XX_PARAM_CS
> #define AT86RF2XX_PARAM_CS ARDUINO_PIN_10
> #endif
> #ifndef AT86RF2XX_PARAM_INT
> #define AT86RF2XX_PARAM_INT ARDUINO_PIN_7
> #endif
> #ifndef AT86RF2XX_PARAM_SLEEP
> #define AT86RF2XX_PARAM_SLEEP ARDUINO_PIN_8
> #endif
> #ifndef AT86RF2XX_PARAM_RESET
> #define AT86RF2XX_PARAM_RESET ARDUINO_PIN_9
> #endif

> #define AT86RF2XX_PARAMS_BOARD {.spi = AT86RF2XX_PARAM_SPI, \
> .spi_clk = AT86RF2XX_PARAM_SPI_CLK, \
> .cs_pin = AT86RF2XX_PARAM_CS, \
> .int_pin = AT86RF2XX_PARAM_INT, \
> .sleep_pin = AT86RF2XX_PARAM_SLEEP, \
> .reset_pin = AT86RF2XX_PARAM_RESET}

> Thanks

> Tobias

> --

> Tobias Guggemos, M.Sc

> Ludwig-Maximilians-Universität München (LMU)

> Institue of Computer Science

> Oettingenstr. 67, Room E003

> D-80538 München, Germany

> Munich Network Management Team (MNM)

> Tel: +49 89 2180-9209

> http://www.mnm-team.org/~guggemos

> ___
> 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] Interest in Graphical Custom IDE / Development Environment / Networking Tool for RIOT (?)

[Alexandre Abadie]

Hi, 

Interesting and promising project. 
I have some experience in Qt development, is there a GitHub or something for 
the project ? 

Alex 

- Mail original -

> Hi Everyone,

> I've been on the mailing list for a while and recently have been
> revisiting my own projects and have started work on an IDE or
> Development Environment for IoT in Qt.

> Right I'm developing an IoT IDE/Communicator and thought I'd reach out
> to you RIOT Developers.

> What just occurred to me is that there might be some interest in RIOT to
> have a native Qt development environment. Being platform independent, it
> would run on either Windows, Linux or OSX. If it is of interest, I could
> just change the branding where needed, eg logo's and screens and so
> forth to make something fit.

> In terms of functionality, one of the things that would be handy is to
> have an integrated communications terminal type window.

> Supporting all of the various types of packet data that you might want
> to exchange with RIOT. We could customise the list to get a 100% fit.

> For the Edit Window, I've come up with some editing options. Nothing too
> complicated.

> Then the primary function would be to do a 'make' on some project
> directory, display the results and be able to do a 'Run'. Much like the
> Qt Creator program does now only in a slightly cut down form.

> These are things that I'm working on right now.

> Since RIOT has it's own makefile style system and so forth it shouldn't
> be so difficult to integrate.

> Once these basics are running, I'm planning to have some sort of Event
> Window where the User can generate and playback various types of Network
> events. Much like the Application on Chrome 'Postman'.

> This would allow the User to examine and test code and packet exchanges
> in an interesting visual way.

> Since I have some free time at the moment and motivation to complete
> this project I'd welcome collaborators from RIOT to complete some of the
> project.

> Any comments / interest ?

> Regards

> David Lyon

> clixx.io Pty Limited, Sydney Australia

> ___
> 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] RIOT code generator

[Alexandre Abadie]

Hi devs,

During the last few days, I worked on a small command line interface tool [1] 
for generating starting code for application, test and board support. The idea 
came out from a discussion with Jose (@jia200x) in one of his PR [2].
Basically, this tool is meant for simplifying the bootstrap of new RIOT code, 
especially with correct copyright headers, doxygen comments, etc. I think that 
this could be handy for newcomers.

The project is in very early stage but there are already ideas for later:
- add driver code generator: with options for auto_init, netdev, etc
- integrate the tool in RIOT build system: make generate-driver, make 
generate-test, make generate-application, etc
- add tests to the tool itself ...

Maybe some of you have other ideas to improve the tool ? This is an open-source 
project, so if you think it's useful, don't hesitate to contribute !

Alex

[1] https://github.com/aabadie/riot-generator
[2] https://github.com/RIOT-OS/RIOT/pull/8508#issuecomment-362576314
___
devel mailing list
devel@riot-os.org
https://lists.riot-os.org/mailman/listinfo/devel

Re: [riot-devel] mBed default UART

[Alexandre Abadie]

Hi, 

For this board, I think the default UART for stdio is available directly via 
the USB port. You just need to open /dev/ttyACM0 (on Linux) at 115200baud. 

Alex 

- Mail original -

> Hi guys,

> I'm wondering if you guys can help me out with the default UART device for
> the mbed_lpc1768 board, to see printf and puts outputs in a serial client
> like putty.

> I tried all pins (9/10/13/14/27/28) with several baudrates withouht success.
> Is there any other action I need to do before this works?

> Thanks in advance,
> Tiago C

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

Re: [riot-devel] RIOT developers monthly meeting

[Alexandre Abadie]

Hi, 

- Mail original -

> Hi,

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

+1 

> Cheers,
> Martine

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

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

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

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

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

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

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

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

Re: [riot-devel] [riot-maintainer] Monthly meetings for organisation purposes

[Alexandre Abadie]

Hi, 

I'll also attend. 

Alex 

- Mail original -

> Hi Paco,

> I'm in as well.

> Cheers,
> Martine

> 2017-11-04 1:03 GMT+01:00 Thomas Eichinger < tho...@riot-os.org > :

> > Hi Paco,
> 

> > Thanks for the initiative!
> 

> > I will try to tune in.
> 

> > Without wanting to start a tools discussion, I had very good experiences
> > with
> > larger groups using zoom.us .
> 

> > Best, Thomas
> 

> > On Nov 3, 2017, at 4:29 PM, Francisco Javier Acosta Padilla <
> > francisco.aco...@inria.fr > wrote:
> 

> > > Hi again!
> > 
> 

> > > A kind reminder to let us now who’s willing to attend the meeting on
> > > Monday,
> > > November 6th at 17:00 CET (UTC +1).
> > 
> 

> > > I don’t have an agenda yet but if we can establish it before it would
> > > speed
> > > up the meeting. So far I propose:
> > 
> 

> > > 1. Sort the most urgent bugs-issues by priority
> > 
> 
> > > 2. Assign (more/new) people to the bugs-issues
> > 
> 
> > > 3. Mark the related issues/PRs to be solved as “in progress”
> > 
> 

> > > The goal is to have the selected issues solved before the next meeting,
> > > if
> > > it
> > > happens before, be free to assign new ones and move them to the “in
> > > progress” column.
> > 
> 

> > > Please don’t hesitate to propose your ideas for the topics of the
> > > meeting!
> > 
> 

> > > Cheers!
> > 
> 

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

> > > On 1 November 2017 at 12:25:51, Martine Lenders ( m...@martine-lenders.eu
> > > )
> > > wrote:
> > 
> 
> > > > Hi Cenk,
> > > 
> > 
> 

> > > > 2017-11-01 11:05 GMT+01:00 Cenk Gündoğan < list-r...@cgundogan.de > :
> > > 
> > 
> 

> > > > > > > On 17-10-31 18:03:01, Francisco Javier Acosta Padilla wrote:
> > > > 
> > > 
> > 
> 
> > > > > > > […]
> > > > 
> > > 
> > 
> 
> > > > > > > > P.S: @Martine, can you set up the next Hack meeting? Thanks
> > > > 
> > > 
> > 
> 
> > > > > > >
> > > > 
> > > 
> > 
> 
> > > > > >
> > > > 
> > > 
> > 
> 
> > > > > > Anything different to do than the usual ad-hoc placecam set-up?
> > > > 
> > > 
> > 
> 
> > > > > >
> > > > 
> > > 
> > 
> 

> > > > > Jup, provide a working mic for the FU's PlaceCam laptop this time (:
> > > > 
> > > 
> > 
> 

> > > > We had... the problem was that the machine we ran placecam on was so
> > > > slow
> > > > and
> > > > old that ALSA wasn't able to stream that audio including video ^^
> > > > (that's
> > > > definitely a problem we need to solve until next week).
> > > 
> > 
> 

> > > > Cheers,
> > > 
> > 
> 
> > > > Martine
> > > 
> > 
> 
> > > > ___
> > > 
> > 
> 
> > > > 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
> > 
> 

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

Re: [riot-devel] Mikroelectronik lora flip and click

[Alexandre Abadie]

Hi, 

- Mail original -

> Dear all,
> I want to use the microlectronik lora flip and click with a samr21 xplained
> pro board in order to transfer the ieee802.15.4 traffic over lora to the
> internet.

The mikrolectronika lora flip and click is based on a microchip rn2483 module 
so, with this PR [1] it's certainly possible to use it with a SAM21 XPlained 
pro board. 

> Has anyone tried something like this, is this possible with riot?

I never tried that but it sounds interesting. You will have to take care of the 
size and frequency of the packets you want to send via LoRaWAN. Under certain 
conditions, the access to the physical layer is very limited compared to 
802.15.4. 

Alex 

[1] https://github.com/RIOT-OS/RIOT/pull/7505 

> Best regards,
> Ilias

> ___
> 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] Release 2017.07

[Alexandre Abadie]

Dear RIOTers,

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

--- * RIOT 2017.07 * ---

This release provides fixes, code cleanup and improved documentation,
as well as enhancements.

New features brought by this release include:
 - CAN bus support (Controller Area Network)
 - Support for CoAP OBSERVE requests
 - Basic Thread stack integration (initial support for OpenThread)
 - Radio duty cycling with LwMAC protocol
 - LoRa radio drivers supporting Semtech hardware

About 230 pull requests with about 442 commits have been merged since
the last release and about 13 issues have been solved. 45 people
contributed with code in 56 days. 1395 files have been touched with
211720 insertions and 65729 deletions.

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

Many thanks to everyone for their contributions, discussions, testing and
reviewing efforts.

Keep RIOTing!

Alex

[1] https://github.com/RIOT-OS/RIOT/releases/tag/2017.07
[2] https://github.com/RIOT-OS/RIOT/archive/2017.07.tar.gz
[3] https://github.com/RIOT-OS/RIOT/blob/2017.07-branch/release-notes.txt

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

[riot-devel] Release 2017.07 - RC2

[Alexandre Abadie]

Dear RIOT'ers,

I've just tagged the second release candidate of the next release 2017.07 [1].

There is an issue for tracking the testing progress at [2]. If you have some 
hardware required for testing (sensors, radios, boards), please try the related 
test applications and raise issues if you still find some.

Final 2017.07 release is still planned for the 14th of July.

Best,

Alex

[1] https://github.com/RIOT-OS/RIOT/tree/2017.07-RC2
[2] https://github.com/RIOT-OS/Release-Specs/issues/45


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

Re: [riot-devel] Help needed for porting to stm32l4

[Alexandre Abadie]

Hi, 

Are you porting this board [1], then this CPU family is already supported by 
RIOT [2] (It's not M0 but M4). You'll just have to add the specific ldscript 
for the CPU (STM32L476VG), see [3] for examples. Finally, you'll have to add 
the board specific configuration in the board directory. See [4] for the 
nucleo-l476 configuration and [5] for other supported discovery boards. 

Hope this helps, 

Alex 

[1] http://www.st.com/en/evaluation-tools/32l476gdiscovery.html 
[2] https://github.com/RIOT-OS/RIOT/tree/master/cpu/stm32l4 
[3] https://github.com/RIOT-OS/RIOT/tree/master/cpu/stm32l4/ldscripts 
[4] https://github.com/RIOT-OS/RIOT/tree/master/boards/nucleo-l476 
[5] https://github.com/RIOT-OS/RIOT/tree/master/boards/stm32f4discovery 

- Mail original -

> Hi Martine,
> Yes, I checked it out. And according to it, I am missing cpu family (+
> board). However there is no specific RIOT requirement mentioned. What I
> meant is that, the bare minimum for an initial port is not defined.

> Any suggestion on it?
> Regards

> On Wed, Jul 5, 2017 at 1:08 AM, Martine Lenders < m...@martine-lenders.eu >
> wrote:

> > Hi Nazmul,
> 
> > have you seen the Porting Guide [1]? It should provide you with all
> > information you need.
> 

> > Best Regards,
> 
> > Martine
> 

> > [1] https://github.com/RIOT-OS/RIOT/wiki/Porting-Guide
> 

> > 2017-07-05 6:40 GMT+02:00 Nazmul Alam < fadedre...@gmail.com > :
> 

> > > Hi Rioters,
> > 
> 
> > > I want to port RIOT to stm32L4discovery device, the cpu is corex_m0 and I
> > > think RIOT has implementation for cortex_m0 cpu.
> > 
> 

> > > Any suggestion from where I can start?
> > 
> 

> > > Thanks in advance.
> > 
> 

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

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

[riot-devel] 2017.07 feature freeze

[Alexandre Abadie]

Dear RIOT'ers,

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

Final 2017.07 release is still planned for the 14th of July.

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

Best,

Alex

[1] https://github.com/RIOT-OS/RIOT/tree/2017.07-RC1
[2] https://github.com/RIOT-OS/Release-Specs/issues/44

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

[riot-devel] Release 2017.07 - feature freeze is next week

[Alexandre Abadie]

Dear RIOTers,

Here is reminder about the decided planning for the next release:

- Feature freeze is next friday, 30th of June

- Release is still planned 2 weeks after, the 14th of July


Next week there will be the monthly Hack'n'ACK which is the good time to have 
pending PRs merged before the feature freeze. Any help in reviewing or testing 
will be greatly appreciated, so stay tuned.

If you are mentioned [1], assigned [2] or have review requested [3] to opened 
PRs, please try to put some more effort to fix/review/ack/merge them.

Of course, we won't be able to merge everything before the end of next week. So 
if a PR cannot be ready for this release, I'll silently postpone it to the next 
version (2017.10 [4]).

Thanks a lot and happy hACKing !

Alex

[1] https://github.com/pulls/mentioned
[2] https://github.com/pulls/assigned
[3] https://github.com/pulls/review-requested
[4] 
https://github.com/RIOT-OS/RIOT/pulls?q=is%3Aopen+is%3Apr+milestone%3A%22Release+2017.10%22

___
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] Planning for release 2017.07

[Alexandre Abadie]

Dear RIOTers,

The next release, 2017.07, is now on its way!

For this release, we've decided to keep the anticipated merge window for "high 
impact"-changes introduced for 2017.04 planning. By high impact, we can think 
of low-level/complex changes, features with very large changeset (example: the 
CAN stack [1]) or big refactoring that may introduce regression if not 
reviewed/tested carefully enough.
But the exact definition of "high impact" is of course up to the maintainers.

Also, as a reminder, I recall that the project currently have 230 PR and 335 
issues opened.
If you are mentioned [2], assigned [3] or have review requested [4] to one of 
them, please try to put as much as possible efforts to fix/review/ack/merge 
them.

So for the upcoming 2017.07 release, the decided schedule is as follows:

- the merge window for "high impact" changes ends at mid-June (only 10 days 
left).
- regular feature freeze is end of June.
- planned release date is on July 14th.

Keep on the good work!

Alex

[1] https://github.com/RIOT-OS/RIOT/pull/5793
[2] https://github.com/pulls/mentioned
[3] https://github.com/pulls/assigned
[4] https://github.com/pulls/review-requested
___
devel mailing list
devel@riot-os.org
https://lists.riot-os.org/mailman/listinfo/devel

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

[Alexandre Abadie]

Hi,

- Mail original -
> This sounds great! 

Indeed. I just gave it a try on IoT-LAB (only available on one of the 
development server for the moment) and it works very well. The 
gnrc_border_router application has to be built using a BAUDRATE of 50 but 
otherwise there's nothing special to change.

> Would it be possible to merge this with the current
> version of the script (say with an additional parameter), so we can
> use it in the `iotlab-term` target version of the border router [1]?

From what I understand are you thinking of adding something like this:
iotlab-term:
$(Q)sudo ethos_uhcpd.py $(M3HOST) $(TAP) $(IPV6_PREFIX)
?

Then it should be quite straightforward but not very useful since the command 
on its own is already very simple.
Besides that the  command can already been used from A8 nodes.

Cheers,

Alex

> 
> Cheers,
> Martine
> 
> [1]
> https://github.com/RIOT-OS/RIOT/blob/master/examples/gnrc_border_router/Makefile#L65
> 
> 2017-04-11 16:33 GMT+02:00 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 

Re: [riot-devel] STM32L073 cpu support in conjunction with spi driver

[Alexandre Abadie]

Hi Neo,

Looking at the configuration you provide, it's hard to tell exactly what is the 
problem. How did you configure the clock for APB1 and APB2 in periph.conf ?
If you set them to use highest speed (32MHz for this MCU), then the 
spi_divtable is wrong and you can reuse the values used for nucleo-l073 where 
the SPI works.

Hope that it helps,

Alex

- Mail original -
> Hello RIOT developers,
> 
> on the weekend I tried the STM32L073 support in conjunction with spi
> support but I had no success.
> 
> I wanted to test this on a board equiped with a STM32L073CZ MCU (48pin
> TQFP). Therefore I made a copy of the linker file (stm32l073rz.ld ->
> stm32l073cz.ld) and I altered the boards Makefile.include file to
> support this derivate (export CPU_MODEL = stm32l073cz).
> 
> I enabled spi support in the feature list inside of the Makefile
> (FEATURES_PROVIDED += periph_spi) and altered the device descriptor in
> the periph_conf.h file but I got no hardware response on the analyzer
> when I tried to run the second spi interface (SPI2). The MCU does nothing.
> 
> /**
>   * @nameSPI configuration
>   *
>   * @noteThe spi_divtable is auto-generated from
>   *  `cpu/stm32_common/dist/spi_divtable/spi_divtable.c`
>   * @{
>   */
> static const uint8_t spi_divtable[2][4] = {
>  {   /* for APB1 @ 800Hz */
>  5,  /* -> 125000Hz */
>  3,  /* -> 50Hz */
>  2,  /* -> 100Hz */
>  0   /* -> 400Hz */
>  },
>  {   /* for APB2 @ 800Hz */
>  5,  /* -> 125000Hz */
>  3,  /* -> 50Hz */
>  2,  /* -> 100Hz */
>  0   /* -> 400Hz */
>  }
> };
> 
> static const spi_conf_t spi_config[] = {
>  {
>  .dev = SPI1,
>  .mosi_pin = GPIO_PIN(PORT_A, 7),
>  .miso_pin = GPIO_PIN(PORT_A, 6),
>  .sclk_pin   = GPIO_PIN(PORT_A, 5),
>  .cs_pin = GPIO_UNDEF,
>  .af= GPIO_AF0,
>  .rccmask  = RCC_APB2ENR_SPI1EN,
>  .apbbus   = APB2
>  },
>  {
>  .dev = SPI2,
>  .mosi_pin = GPIO_PIN(PORT_B, 15),
>  .miso_pin = GPIO_PIN(PORT_B, 14),
>  .sclk_pin = GPIO_PIN(PORT_B, 13),
>  .cs_pin   = GPIO_UNDEF,
>  .af   = GPIO_AF0,
>  .rccmask  = RCC_APB1ENR_SPI2EN,
>  .apbbus   = APB1
>  }
> };
> 
> #define SPI_NUMOF   (sizeof(spi_config) / sizeof(spi_config[0]))
> /** @} */
> 
> The application I tried to run was the tests/periph_spi test application.
> 
> Do I have to enable some other features or dependencies to get the spi
> interface running?
> 
> As far as I have seen the spi driver was rewritten since the last
> release and I tried to configure it as described on the riot-os.org/api
> web page.
> 
> Any thoughts what could be wrong with this configuration?
> 
> Thanks a lot!
> 
> Regards,
> 
> Neo
> 
> ___
> 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] Support for STM32F7 Series

[Alexandre Abadie]

Hi Neo,

- Mail original -
> Hello RIOT developers,
> 
> is anyone working on a STM32F7 port of RIOT OS?

Not that I know. Are you interested in working on that ? That would be very 
much appreciated.

Cheers,

Alex

> 
> Regards,
> 
> Neo
> 
> ___
> 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] Release 2017.01

[Alexandre Abadie]

Well done !

Congrats to everybody and mainly to Peter for driving this release :)

Cheers,

Alex

- Mail original -
> Dear RIOTers,
> 
> we are happy to announce the tenth official release of RIOT:
> 
> 
> --- * RIOT 2017.01 * ---
> 
> This release provides a lot of new features, fixes and enhancements.
> Among others these features contain an initial - still experimental -
> TCP implementation based on the GNRC network stack, support for reading
> from and writing to SD cards, a new power management architecture as
> well additional third party packages such as TweetNaCl, a cryptographic
> library, and Heatshrink a data compression library optimized for
> embedded real-time systems. We added support for new  platforms
> including the Calliope mini, Maple mini, and a couple of STMs Nucleo
> boards. Device support was extended by several new drivers, e.g., for
> NXP PN532 NFC, Microchip MRF24J40 802.15.4 radio (experimental), or
> Bosch BME280 pressure/humidity/temperature sensor.
> We completely refactored the SPI interface, allowing for internally
> handled hardware or software chip select lines and shared bus usage for
> multiple devices with different SPI configurations.
> 
> About 278 pull requests with about 606 commits have been merged since
> the last release and about 84 issues have been solved. 44 people
> contributed with code in 87 days. 2230 files have been touched with
> 220275 insertions and 159840 deletions.
> 
> You can download the RIOT release from Github by cloning the repository
> [1] or by downloading the tarball [2], and look up the release notes for
> further details [3].
> 
> Thanks everyone for your contributions, discussions, testing efforts,
> and keep RIOTing!
> 
> Best regards
> Peter
> 
> [1] https://github.com/RIOT-OS/RIOT/releases/tag/2017.01
> [2] https://github.com/RIOT-OS/RIOT/archive/2017.01.tar.gz
> [3] https://github.com/RIOT-OS/RIOT/blob/2017.01-branch/release-notes.txt
> ___
> 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] Support for SODAQ Autonomo was added

[Alexandre Abadie]

Hi, 

- Mail original -

> Hello!

> Congrats! Looking forward for the complete support on your board, thanks and
> I think we’ll see soon the Arduino Zero on the list ;)

It should arrive soon... 

2016-09-30 12:48:03,162 - INFO # main(): This is RIOT! (Version: 
2016.10-devel-333-g8a698-trek-saclay-arduino_zero) 
2016-09-30 12:48:03,163 - INFO # Hello World! 
2016-09-30 12:48:03,167 - INFO # You are running RIOT on a(n) arduino-zero 
board. 
2016-09-30 12:48:03,171 - INFO # This board features a(n) samd21 MCU. 

Thanks Kees, you made a really helpful job ! 

Alex 

- Mail original -

> Hello!

> Congrats! Looking forward for the complete support on your board, thanks and
> I think we’ll see soon the Arduino Zero on the list ;)

> Cheers!

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

> On 29 September 2016 at 22:44:53, Kees Bakker ( k...@sodaq.com ) wrote:
> ___
> devel mailing list
> devel@riot-os.org
> https://lists.riot-os.org/mailman/listinfo/devel
> Cheers!

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

> On 29 September 2016 at 22:44:53, Kees Bakker ( k...@sodaq.com ) wrote:
> > Hi,
> 

> > It is my pleasure to announce that a new board is supported in RIOT,
> 
> > SODAQ Autonomo.
> 
> > The board has many similarities to the Arduino Zero, so it shouldn't be
> 
> > too hard to get
> 
> > that board supported as well. If anyone feels the need to pick that up,
> 
> > be my guest.
> 
> > Meanwhile I'll continue to work on improving the support of my own
> 
> > board. And all
> 
> > the devices that I'm interested in, such as:
> 
> > * data flash AT45DB161
> 
> > * SODAQ 3G/2G (Bee slot device with UBlox modem)
> 
> > * BME280
> 

> > --
> 
> > Kees Bakker
> 
> > Founder
> 
> > SODAQ
> 
> > M. 0031617737165
> 
> > www.sodaq.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
___
devel mailing list
devel@riot-os.org
https://lists.riot-os.org/mailman/listinfo/devel

Re: [riot-devel] I2C - Arduino <-> SAMR21-xpro

[Alexandre Abadie]

Hi Alessandro, 

Unfortunately, the current I2C API in RIOT only supports the master mode so you 
won't be able to use your samr21-xpro as slave on this kind of bus. 
I don't know how complex it is to add support for this feature btw. 

Cheers, 

Alex 

- Mail original -

> Hi all,
> There is someone who tried to interface arduino to RIOT (the board in my case
> is SAMR21-xpro) through the I2C ?

> I would config the Arduino as MASTER (i've already did it with wire.h) and
> samr21 as SLAVE.

> I did a code like this :
> 
> int main(void)
> {
> puts("I2C Reader");

> /* define own shell commands */
> //char line_buf[SHELL_DEFAULT_BUFSIZE];
> //shell_run(shell_commands, line_buf, SHELL_DEFAULT_BUFSIZE);

> char data;
> int read=0;
> while(1){
> puts("waiting for data...");
> i2c_poweron(0);
> do{
> read = i2c_read_byte(0, 8, data);
> if(read==-1)
> {
> puts("ERROR : UNDEFINED DEVICE");
> break;
> }else if(read>0)
> printf("data arrived : %c",data);

> }while(read<1);
> }
> return 0;
> }
> 

> Arduino will send 5 byte at time, but the samr21 doesn't receive
> nothingany ideas?

> Thanks all !

> best regards,
> Alessandro

> ___
> 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] Hack'n'ACK July 2016

[Alexandre Abadie]

Hi,

Unfortunately, I won't be available tomorrow. It will be for next time.

Cheers,

Alex

- Mail original -
> Hi,
> tomorrow we have our monthly Hack'n'ACK again. Oleg and I will most
> likely sit together at FU Berlin and are happy about any other dev
> from Berlin that likes to join. Hamburg & Saclay are you holding a
> Hack'n'ACK at your location, too?
> 
> 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

Re: [riot-devel] Problem with UDP and SAMR21-XPRO

[Alexandre Abadie]

Hi,

> though I do not have the same setup ready for testing, I _cannot_ confirm any
> problems with UDP on latest RIOT master branch.
> 
> I just tested UDP on a SAMR21-XPRO running gnrc_networking example and
> successfully send and received UDP data from and to a RasPi with Openlabs
> transceiver running netcat on latest Raspbian-Linux.
> 
> Could you clarify which RIOT branch/commit you use?

Latest master. From what you say, the problem comes from the RIOT BR.

Cheers,

Alex


> 
> Best,
>   Sebastian
> 
> > Am 21.06.2016 um 21:42 schrieb Alexandre Abadie
> > <alexandre.aba...@inria.fr>:
> > 
> > Hi Mattia,
> > 
> > Thanks for reporting this issue.
> > 
> >> I've discovered a possible bug in RIOT. I'm working with 2 samr21-xpro: on
> >> the first is running gnrc_border_router (I'll call it A) and on the other
> >> (I'll call it B) is running gnrc_networking. I've well configured my
> >> scenario infact I can ping both my nodes from linux shell. But, when I
> >> send
> >> a UDP packet to B (with nc) it is forwarded correctly on tap interface (I
> >> seen it on wireshark) but it arrives corrupted (wrong checksum) to B and
> >> it
> >> is dropped by UDP thread. I've enabled packet dump and the packet arrives
> >> with different packet lengths in ipv6 and udp headers (fixed to 8, it is
> >> the UDP header length) and the udp payload is removed.
> > 
> > I have the exact same problem although I didn't track it as deep as you
> > did.
> > 
> >> How can I fix this problem?
> > 
> > A regression was introduced 2 or 3 weeks ago in master and you could first
> > "git bisect" to try to identify the incriminated commit.
> > 
> > Thanks,
> > 
> > Alex
> > ___
> > 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] Fwd: [iot-lab-admin] New RIOT tutorials

[Alexandre Abadie]

FYI

By the way, it seems that with the latest version of master, the UDP connection 
is not working any more, although ping is still working.

Alex

- Mail transféré -
> Hi devs,
> 
> I wrote two new tutorials describing the configuration of a border router and
> CoAP on iotlab with RIOT. For me moment, they only target A8-M3 nodes.
> The CoAP tutorial doesn't fully work though because of the old version of Git
> not compatible with the "pkg" mecanism in RIOT (option -C not recognized in
> git 1.7).
> Can someone give it try and make some feedback, at least for the BR one ?
> 
> Border router tutorial: https://www.iot-lab.info/?page_id=5355
> CoAP tutorial: https://www.iot-lab.info/?page_id=5371
> 
> Thanks,
> 
> Alex
> ___
> FIT IoT-LAB admin mailing-list
> ad...@iot-lab.info
> 
___
devel mailing list
devel@riot-os.org
https://lists.riot-os.org/mailman/listinfo/devel

Re: [riot-devel] Working on port to SODAQ Autonomo (SAMD21)

[Alexandre Abadie]

Hi,

Following this thread, I better understand the problems I had when I tried to 
port RIOT on Arduino/Genuino Zero in [1]. I'll test your changes in 
cpu/samd21/periph/uart.c to see if they fix them. Note that it uses an Atmel 
ATSAMD21G18 MCU which is again another variant of samd21.

Alex

[1] https://github.com/RIOT-OS/RIOT/pull/5475

- Mail original -
> As promissed ...
> 
> The final change to make it work was selecting the correct "mux". There
> were a few hardcoded things in
> * boards/samr21-xpro/include/periph_conf.h
> * cpu/samd21/periph/uart.c
> 
> SAMR21_XPRO has the first serial connected to:
>RX - PA5
>TX - PA4
> static const uart_conf_t uart_config[] = {
>  /* device, RX pin, TX pin, mux */
>  {>USART, GPIO_PIN(PA,5), GPIO_PIN(PA,4), GPIO_MUX_D},
> 
> 
> My SODAQ Autonomo board has the first serial connected to:
>RX - PA9
>TX - PA10
> static const uart_conf_t uart_config[] = {
>  /* device, RX pin, TX pin, mux */
>  {>USART, GPIO_PIN(PA,9), GPIO_PIN(PA,10), GPIO_MUX_C},
> 
> Is that all? No, welcome to the SERCOM world of ARM Cortex M0.
> In cpu/sam???/periph/uart.c some changes are needed too. In the next
> diff, the samr21
> is the "old" samd21.
> 
> --- cpu/samd21/periph/uart.c2016-06-13 22:41:15.358773522 +0200
> +++ cpu/samr21/periph/uart.c2016-05-31 19:57:02.788554067 +0200
> @@ -86,10 +86,9 @@
>   /* reset the UART device */
>   dev->CTRLA.reg = SERCOM_USART_CTRLA_SWRST;
>   while (dev->SYNCBUSY.reg & SERCOM_USART_SYNCBUSY_SWRST) {}
> -/* set asynchronous mode w/o parity, LSB first, PAD2 to TX, PAD1 to
> RX, sample rate 16x and
> +/* set asynchronous mode w/o parity, LSB first, PAD0 to TX, PAD1 to
> RX and
>* use internal clock */
>   dev->CTRLA.reg = (SERCOM_USART_CTRLA_DORD |
> -  SERCOM_USART_CTRLA_TXPO(0x1) |
> SERCOM_USART_CTRLA_RXPO(0x1) |
> SERCOM_USART_CTRLA_SAMPR(0x1) |
> SERCOM_USART_CTRLA_MODE_USART_INT_CLK);
> 
> 
> Notice the TXPO and RXPO. These indicate which "pads" the pin can use on
> a certain SERCOM.
> So, what we can learn from this is that we need to expand uart_conf_t.
> We need PAD configuration
> too. (BTW, Arduino Core is doing similar things.)
> 
> Was this a TL;DR? Sorry about it then.
> -- Kees
> 
> 
> On 13-06-16 23:28, Peter Kietzmann wrote:
> > Congrats! Looking forward to hear the trick that did it :-).
> >
> > Good night
> > Peter
> >
> > Am 13.06.2016 um 23:21 schrieb Kees Bakker:
> >> On 13-06-16 20:55, Kees Bakker wrote:
> >>>
> >>> That is more or less already what I did. I filled in uart_config[]
> >>> with two devices
> >>> and I have a serial line connect to my PC. This configuration works
> >>> with the Arduino
> >>> setup. But not yet with RIOT.
> >>
> >> I almost gave up ..., but then ...
> >>
> >> �main(): This is RIOT! (Version:
> >> 2016.07-devel-191-g42127-rapper-sodaq-autonomo)
> >> Hello World!
> >> You are running RIOT on a(n) sodaq-autonomo board.
> >> This board features a(n) samd21 MCU.
> >>
> >> Yeah, it's working. Well, hello world is.
> >> (( It's getting too late now. I'll explain later this week what was
> >> needed to make it work. ))
> >>
> >
> 
> 
> --
> Kees Bakker
> Founder
> SODAQ
> M. 0031617737165
> www.sodaq.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] Riot on iot-lab

[Alexandre Abadie]

Hi,

If someone wants to have a look, here is the PR : 
https://github.com/RIOT-OS/RIOT/pull/5462

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

Note that we can already write RIOT based firmwares for m3 and fox.

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

[riot-devel] Riot on iot-lab

[Alexandre Abadie]

Hi devs,

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

I recently worked on several things on iotlab:
- 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).
- porting riot to the a8-m3 open nodes with [1]. I need this soon in order to 
write tutorials showing how to configure a BR with RIOT and use coap (I'll 
reuse most of the examples). I'll have to build ethos and uhcpd on the a8 and 
the iotlab team wants to first start on those ones (before testing the m3). Can 
someone review this soon ?

Thanks you !

Alex

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

Re: [riot-devel] arduino-uno support

[Alexandre Abadie]

Hi,

I have one so I'll be able to give a try and test. As a side note, the 
atmega328p has very limited ressources (32KB flash, 2KB SRAM) so this will 
limit the use cases with RIOT (no network stack, etc).

Alex

- Mail original -
> On Thu, May 12, 2016 at 11:01 PM, Martine Lenders 
> wrote:
> 
> > Hi Laurent,
> > definitely! If you have a working port, provide a PR as soon as you see
> > fit. I personally only have a Arduino Leonardo, but it shouldn't be hard to
> > find an Arduino Uno. Also: the simulated one could be helpful for future
> > testing runs. Keep us in the loop :-).
> >
> 
> +1!
> Emmanuel
> 
> 
> >
> > Cheers,
> > Martine
> >
> > 2016-05-12 21:34 GMT+02:00 Laurent Navet :
> >
> >> Hi,
> >>
> >> Just to let you know that I have a basic port of the arduino-uno board
> >> based on an atmega328p uc.
> >> My work is largely based on the atmega2560 port.
> >> For now, I've managed to build the hello-world and
> >> timer_periodic_wakeup examples, and to load and execute generated .elf
> >> using the simavr[1] emulator.
> >>
> >> ..
> >> main(): This is RIOT! (Version: 2016.07-devel-114-gc449-paddy-uno).
> >> Hello World!.
> >> You are running RIOT on a(n) arduino-uno board..
> >> This board features a(n) atmega328p MCU..
> >>
> >> Let me know if you're always interested by this port as suggested in
> >> the Project Idea List[2.
> >> Though, It certaily needs some cleanup and tests on real hardware before
> >> PR.
> >>
> >> Regards,
> >> Laurent
> >>
> >> [1] https://github.com/buserror/simavr
> >> [2] https://github.com/RIOT-OS/RIOT/wiki/Project-Idea-List
> >>
> >> --
> >> « On ne résout pas un problème avec les modes de pensée qui l’ont
> >> engendré. »
> >> « You cannot solve current problems with current thinking. Current
> >> problems are the result of current thinking »
> >> ___
> >> 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

[riot-devel] Sample applications

[Alexandre Abadie]

Dear Rioters,

I started to use riot-os a few weeks ago now and I'd like to tell you that your 
project is totally awesome and quite well documented.

I first began to write some sample applications with in mind the idea of 
providing some easy to use/understand starter tutorials showing the 
possibilities offered by riot-os (UART, GPIO, NET, etc). I tried to have the 
examples as much documented as possible (but we all know that this can always 
be improved).
The code is already available on GitHub [1]. By the way I noticed that you 
already have a repo targeting the same idea [2]. 

What do you think of merging both or maybe create another repository called 
"riot-tutorials" where "aabadie/riot-apps" could be moved ? Are you interested 
in such a contribution ?

Cheers,

Alex

[1] https://github.com/aabadie/riot-apps
[2] https://github.com/RIOT-OS/applications
___
devel mailing list
devel@riot-os.org
https://lists.riot-os.org/mailman/listinfo/devel