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

[Bas Stottelaar]

Thanks all!

Kind Regards
Bas Stottelaar



Op ma 2 nov. 2020 om 11:39 schreef Emmanuel Baccelli <
emmanuel.bacce...@inria.fr>:

> Congrats to all involved! Thanks Koen for managing this release!
> Cheers,
> --Emmanuel
>
> On Mon, Nov 2, 2020 at 11:04 AM José Ignacio Alamos <
> jose.ala...@haw-hamburg.de> wrote:
>
>> Hi,
>>
>> Very nice! Congratulations to everyone! Thanks Koen!
>>
>> Cheers,
>> José
>>
>>
>> On 20/11/01 06:18PM, Leandro Lanzieri wrote:
>> > Hi all,
>> >
>> > Nice! Congratulations to everyone involved, and special thanks to Koen!
>> >
>> > Cheers,
>> > Leandro.
>> >
>> > On Fri, 2020-10-30 at 18:30 +0100, Koen Zandberg wrote:
>> > > And hopefully this time with newlines:
>> > >
>> > > Dear RIOTers,
>> > >
>> > > We are happy to announce the 25th official release of RIOT:
>> > >
>> > > --- * RIOT 2020.10 * ---
>> > >
>> > > The 2020.10 release includes:
>> > >
>> > >  - Support for PicoLIBC as standard C library implementation
>> > >  - A new radio abstraction layer for ieee802.15.4 radios
>> > >  - Improvement to the linking of modules
>> > >  - An improved algorithm for generating local unique identifiers
>> > >  - Pagewise addressing support for MTD devices
>> > >  - 23 additional modules supported by Kconfig
>> > >  - Initial rework of the clock modelling on stm32 devices
>> > >  - 5 new boards, 2 new device drivers, 7 packages updated
>> > >
>> > > 482 pull requests, composed of 1355 commits, have been merged since
>> > > the
>> > > last release, and 84 issues have been solved. 64 people contributed
>> > > with
>> > > code in 94 days. 2426 files have been touched with 133358 (+)
>> > > insertions and
>> > > 756906 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,
>> > > Koen Zandberg
>> > >
>> > >
>> > > [1]:https://github.com/RIOT-OS/RIOT/tree/2020.10
>> > >
>> > > [2]:https://github.com/RIOT-OS/RIOT/archive/2020.10.tar.gz
>> > >
>> > > [3]:https://github.com/RIOT-OS/RIOT/releases/tag/2020.10
>> > > ___
>> > > devel mailing list
>> > > devel@riot-os.org
>> > > https://lists.riot-os.org/mailman/listinfo/devel
>> > --
>> > Leandro Lanzieri Rodriguez
>> > Hamburg University of Applied Sciences
>> > Berliner Tor 7, 20099 Hamburg, Germany, Room 4.81c
>> > Dept. Computer Science, Internet Technologies Group
>> > http://inet.haw-hamburg.de/members/leandro-lanzieri
>> > Phone: +49 40 42875 - 8426
>>
>>
>>
>> > ___
>> > 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
>>
> ___
> 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

Re: [riot-devel] Release 2020.07

[Bas Stottelaar]

Congratulations!

Thanks for the hard work managing this release, Martine!

Bas

> Op 24 jul. 2020 om 22:41 heeft Francois-Xavier Molina 
>  het volgende geschreven:
> 
> Awesome! Congrats for some great work on this release Martine! And congrats 
> to everyone
> involved!
> 
> - Mail original -
>> De: "Martine Lenders" 
>> À: "devel" , "users" 
>> Envoyé: Vendredi 24 Juillet 2020 17:09:12
>> Objet: [riot-devel] Release 2020.07
> 
>> Dear RIOTers,
>> 
>> We are happy to announce the 24th official release of RIOT:
>> 
>> --- * RIOT 2020.07 * ---
>> 
>> The 2020.07 release puts a focus on the improvement of automated testing. In
>> that vein, various new CI integrations such as CircleCI for documentation
>> building and online presentation, and Github Actions to check the tooling of
>> RIOT when merged. The `riotctrl_shell` python module allows to abstract
>> shell
>> commands as python methods for testing using the newly created `riotctrl`
>> python package [1]. Kconfig migration reached phase 2 with various board
>> features being exposed to Kconfig. New network protocols were ported for
>> RIOT
>> such as MQTT (in form of the `paho-mqtt` package) and the lookup client
>> component for CoRE RD `cord_lc`. The OpenWSN network stack with 6TiSCH
>> support
>> was reintegrated into RIOT. Support for several new boards and new
>> sensors was
>> added. Additionally, this release contains a number of bug fixes and test
>> improvements.
>> 
>> 546 pull requests, composed of 10452 commits, have been merged since the
>> last release, and 84 issues have been solved. 64 people contributed with
>> code in 106 days. 2371 files have been touched with 822149 (+)
>> insertions and
>> 700313 deletions (-).
>> 
>> You can download the RIOT release from Github by cloning the repository
>> and checkout the release tag [2] or by downloading the tarball [3], and
>> look up the release notes for further details [4].
>> 
>> A big thank you to everybody who contributed! And special thanks to everyone
>> who helped out during the release testing, especially those who helped with
>> the integration of the automated testing, and who provided bug fixes!
>> Best regards,
>> Martine
>> 
>> [1] https://pypi.org/project/riotctrl/
>> [2] https://github.com/RIOT-OS/RIOT/tree/2020.07
>> [3] https://github.com/RIOT-OS/RIOT/archive/2020.07.tar.gz
>> [4] https://github.com/RIOT-OS/RIOT/releases/tag/2020.07
>> 
>> 
>> 
>> 
>> 
>> 
>> ___
>> 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] BG22/ EFR32

[Bas Stottelaar]

I'll probably update this branch tonight, hopefully in a more workable
version.

Any comments are appreciated and I will incorporate them.

Kind regards,

Bas Stottelaar



Op wo 8 jul. 2020 om 04:25 schreef Akshay Mishra :

> Thanks Bas, this can be a good start point for me.
>
> Thank You very much,
> Akshay
>
> On Wed, 8 Jul, 2020, 04:32 Bas Stottelaar, 
> wrote:
>
>> Hi Akshay,
>>
>> I’ve been able to run at the examples/default application, and get some
>> output on the terminal:
>> https://github.com/RIOT-OS/RIOT/pull/14367#issuecomment-655148512.
>>
>> The code (but in very rough shape!) can be found here:
>> https://github.com/basilfx/RIOT/tree/feature/sltb010a.
>>
>> So far, only UART (but not EUART) and GPIO work. RTT/RTC need a new
>> driver. I2C and Timers do compile, but don’t work yet.
>>
>> Kind regards,
>> Bas
>>
>> Op 7 jul. 2020, om 09:23 heeft Bas Stottelaar 
>> het volgende geschreven:
>>
>> Hi Aksay,
>>
>> I am still working on this, but I had some other things to do that took
>> more time ;-)
>>
>> The PR for Cortex-M33 support is here:
>> https://github.com/RIOT-OS/RIOT/pull/14367. Support for the board will
>> follow if I can get it to work.
>>
>> Kind regards,
>>
>> Bas Stottelaar
>>
>>
>>
>> Op ma 6 jul. 2020 om 17:07 schreef Akshay Mishra :
>>
>>> Hello Bas,
>>>
>>> Could you get the Cortex-M33 supported?
>>>
>>>
>>> On Thu, 25 Jun, 2020, 11:47 Akshay Mishra,  wrote:
>>>
>>>> Thanks Bas - I can also spend some time once you give me a starting
>>>> point.
>>>>
>>>> Regards,
>>>> Akshay
>>>>
>>>> On Thu, Jun 25, 2020 at 11:40 AM Bas Stottelaar <
>>>> basstottel...@gmail.com> wrote:
>>>>
>>>>> Hi Akshay,
>>>>>
>>>>> I received the SLTB010A yesterday and have already prepared all vendor
>>>>> files.
>>>>>
>>>>> Support for Cortex-M33 isn't there yet, but I hope it's
>>>>> straightforward (it's basically a successor of the M4 according to the
>>>>> Silabs docs). I also need to update the EFM32 device drivers in RIOT-OS to
>>>>> support the series 2 microcontrollers. According to AN0918.2
>>>>> <https://www.silabs.com/documents/public/application-notes/an0918.2-efm32-to-efr32xg2x-migration-guide.pdf>,
>>>>> it should be quite easy as long as we're using EMLIB (which we do). Gecko
>>>>> SDK was already updated to support the series 2 microcontrollers.
>>>>>
>>>>> It's a bit more work than I thought, but I hope to have a first
>>>>> version that works this weekend.
>>>>>
>>>>> Kind regards,
>>>>>
>>>>> Bas Stottelaar
>>>>>
>>>>>
>>>>>
>>>>> Op za 20 jun. 2020 om 23:59 schreef Akshay Mishra >>>> >:
>>>>>
>>>>>> Thanks Bas. That's a Cortex-M33 chip. I believe there isn't any CM33
>>>>>> as yet on RIOT otherwise.
>>>>>>
>>>>>> Warm regards,
>>>>>> Akshay
>>>>>>
>>>>>> On Sun, 21 Jun, 2020, 03:10 Bas Stottelaar, 
>>>>>> wrote:
>>>>>>
>>>>>>> I just ordered that board. I think I can make an initial PR this
>>>>>>> week.
>>>>>>>
>>>>>>> Kind regards
>>>>>>> Bas
>>>>>>>
>>>>>>> Op 20 jun. 2020 om 23:30 heeft Akshay Mishra 
>>>>>>> het volgende geschreven:
>>>>>>>
>>>>>>> 
>>>>>>> Hello Bas,
>>>>>>>
>>>>>>>  Yes SLTB010A is indeed the board I plan to use
>>>>>>>
>>>>>>> Thank You,
>>>>>>> Akshay
>>>>>>>
>>>>>>>
>>>>>>> On Sun, 21 Jun, 2020, 02:03 Bas Stottelaar, 
>>>>>>> wrote:
>>>>>>>
>>>>>>>> Hi Akshay,
>>>>>>>>
>>>>>>>> The EFM32 and EFR32 family are supported, but it depends on the
>>>>>>>> board definitions.
>>>>>>>>
>>>>>>>> Are you using the SLTB010A board? I see that that on

Re: [riot-devel] BG22/ EFR32

[Bas Stottelaar]

Hi Akshay,

I’ve been able to run at the examples/default application, and get some output 
on the terminal: 
https://github.com/RIOT-OS/RIOT/pull/14367#issuecomment-655148512 
<https://github.com/RIOT-OS/RIOT/pull/14367#issuecomment-655148512>.

The code (but in very rough shape!) can be found here: 
https://github.com/basilfx/RIOT/tree/feature/sltb010a 
<https://github.com/basilfx/RIOT/tree/feature/sltb010a>.

So far, only UART (but not EUART) and GPIO work. RTT/RTC need a new driver. I2C 
and Timers do compile, but don’t work yet.

Kind regards,
Bas

> Op 7 jul. 2020, om 09:23 heeft Bas Stottelaar  het 
> volgende geschreven:
> 
> Hi Aksay,
> 
> I am still working on this, but I had some other things to do that took more 
> time ;-)
> 
> The PR for Cortex-M33 support is here: 
> https://github.com/RIOT-OS/RIOT/pull/14367 
> <https://github.com/RIOT-OS/RIOT/pull/14367>. Support for the board will 
> follow if I can get it to work.
> 
> Kind regards,
> 
> Bas Stottelaar
> 
> 
> 
> Op ma 6 jul. 2020 om 17:07 schreef Akshay Mishra  <mailto:aks...@dspworks.in>>:
> Hello Bas,
> 
> Could you get the Cortex-M33 supported?
> 
> 
> On Thu, 25 Jun, 2020, 11:47 Akshay Mishra,  <mailto:aks...@dspworks.in>> wrote:
> Thanks Bas - I can also spend some time once you give me a starting point. 
> 
> Regards,
> Akshay
> 
> On Thu, Jun 25, 2020 at 11:40 AM Bas Stottelaar  <mailto:basstottel...@gmail.com>> wrote:
> Hi Akshay,
> 
> I received the SLTB010A yesterday and have already prepared all vendor files.
> 
> Support for Cortex-M33 isn't there yet, but I hope it's straightforward (it's 
> basically a successor of the M4 according to the Silabs docs). I also need to 
> update the EFM32 device drivers in RIOT-OS to support the series 2 
> microcontrollers. According to AN0918.2 
> <https://www.silabs.com/documents/public/application-notes/an0918.2-efm32-to-efr32xg2x-migration-guide.pdf>,
>  it should be quite easy as long as we're using EMLIB (which we do). Gecko 
> SDK was already updated to support the series 2 microcontrollers.
> 
> It's a bit more work than I thought, but I hope to have a first version that 
> works this weekend.
> 
> Kind regards,
> 
> Bas Stottelaar
> 
> 
> 
> Op za 20 jun. 2020 om 23:59 schreef Akshay Mishra  <mailto:aks...@dspworks.in>>:
> Thanks Bas. That's a Cortex-M33 chip. I believe there isn't any CM33 as yet 
> on RIOT otherwise. 
> 
> Warm regards,
> Akshay
> 
> On Sun, 21 Jun, 2020, 03:10 Bas Stottelaar,  <mailto:basstottel...@gmail.com>> wrote:
> I just ordered that board. I think I can make an initial PR this week.
> 
> Kind regards
> Bas
> 
>> Op 20 jun. 2020 om 23:30 heeft Akshay Mishra > <mailto:aks...@dspworks.in>> het volgende geschreven:
>> 
>> 
>> Hello Bas,
>> 
>>  Yes SLTB010A is indeed the board I plan to use
>> 
>> Thank You,
>> Akshay
>> 
>> 
>> On Sun, 21 Jun, 2020, 02:03 Bas Stottelaar, > <mailto:basstottel...@gmail.com>> wrote:
>> Hi Akshay,
>> 
>> The EFM32 and EFR32 family are supported, but it depends on the board 
>> definitions.
>> 
>> Are you using the SLTB010A board? I see that that one is using the 
>> EFR32BGxx. If so, I can start a PR to add support for it.
>> 
>> Kind regards,
>> Bas Stottelaar
>> 
>>> Op 20 jun. 2020, om 19:46 heeft Akshay Mishra >> <mailto:akshaymis...@gmail.com>> het volgende geschreven:
>>> 
>>> Hello RIOTers,
>>> I have been a very long time lurker here with some porting 
>>> and development but mostly using what's been done. I am looking at BG22 
>>> from Silabs and wanted to inquire if there has been any initiation towards 
>>> this family (EFR32BGxx).
>>> 
>>> Intent is to have RIOT and then nimble integrated on this.
>>> 
>>> thank you,
>>> Akshay
>>> 
>>> ___
>>> devel mailing list
>>> devel@riot-os.org <mailto:devel@riot-os.org>
>>> https://lists.riot-os.org/mailman/listinfo/devel 
>>> <https://lists.riot-os.org/mailman/listinfo/devel>
>> 
>> ___
>> devel mailing list
>> devel@riot-os.org <mailto:devel@riot-os.org>
>> https://lists.riot-os.org/mailman/listinfo/devel 
>> <https://lists.riot-os.org/mailman/listinfo/devel>
>> ___
>> devel mailing list
>> devel@riot-os.org <mailto:devel@riot-os.org>
>> https:/

Re: [riot-devel] BG22/ EFR32

[Bas Stottelaar]

Hi Aksay,

I am still working on this, but I had some other things to do that took
more time ;-)

The PR for Cortex-M33 support is here:
https://github.com/RIOT-OS/RIOT/pull/14367. Support for the board will
follow if I can get it to work.

Kind regards,

Bas Stottelaar



Op ma 6 jul. 2020 om 17:07 schreef Akshay Mishra :

> Hello Bas,
>
> Could you get the Cortex-M33 supported?
>
>
> On Thu, 25 Jun, 2020, 11:47 Akshay Mishra,  wrote:
>
>> Thanks Bas - I can also spend some time once you give me a starting
>> point.
>>
>> Regards,
>> Akshay
>>
>> On Thu, Jun 25, 2020 at 11:40 AM Bas Stottelaar 
>> wrote:
>>
>>> Hi Akshay,
>>>
>>> I received the SLTB010A yesterday and have already prepared all vendor
>>> files.
>>>
>>> Support for Cortex-M33 isn't there yet, but I hope it's straightforward
>>> (it's basically a successor of the M4 according to the Silabs docs). I also
>>> need to update the EFM32 device drivers in RIOT-OS to support the series 2
>>> microcontrollers. According to AN0918.2
>>> <https://www.silabs.com/documents/public/application-notes/an0918.2-efm32-to-efr32xg2x-migration-guide.pdf>,
>>> it should be quite easy as long as we're using EMLIB (which we do). Gecko
>>> SDK was already updated to support the series 2 microcontrollers.
>>>
>>> It's a bit more work than I thought, but I hope to have a first version
>>> that works this weekend.
>>>
>>> Kind regards,
>>>
>>> Bas Stottelaar
>>>
>>>
>>>
>>> Op za 20 jun. 2020 om 23:59 schreef Akshay Mishra :
>>>
>>>> Thanks Bas. That's a Cortex-M33 chip. I believe there isn't any CM33 as
>>>> yet on RIOT otherwise.
>>>>
>>>> Warm regards,
>>>> Akshay
>>>>
>>>> On Sun, 21 Jun, 2020, 03:10 Bas Stottelaar, 
>>>> wrote:
>>>>
>>>>> I just ordered that board. I think I can make an initial PR this week.
>>>>>
>>>>> Kind regards
>>>>> Bas
>>>>>
>>>>> Op 20 jun. 2020 om 23:30 heeft Akshay Mishra  het
>>>>> volgende geschreven:
>>>>>
>>>>> 
>>>>> Hello Bas,
>>>>>
>>>>>  Yes SLTB010A is indeed the board I plan to use
>>>>>
>>>>> Thank You,
>>>>> Akshay
>>>>>
>>>>>
>>>>> On Sun, 21 Jun, 2020, 02:03 Bas Stottelaar, 
>>>>> wrote:
>>>>>
>>>>>> Hi Akshay,
>>>>>>
>>>>>> The EFM32 and EFR32 family are supported, but it depends on the board
>>>>>> definitions.
>>>>>>
>>>>>> Are you using the SLTB010A board? I see that that one is using the
>>>>>> EFR32BGxx. If so, I can start a PR to add support for it.
>>>>>>
>>>>>> Kind regards,
>>>>>> Bas Stottelaar
>>>>>>
>>>>>> Op 20 jun. 2020, om 19:46 heeft Akshay Mishra 
>>>>>> het volgende geschreven:
>>>>>>
>>>>>> Hello RIOTers,
>>>>>> I have been a very long time lurker here with some
>>>>>> porting and development but mostly using what's been done. I am looking 
>>>>>> at
>>>>>> BG22 from Silabs and wanted to inquire if there has been any initiation
>>>>>> towards this family (EFR32BGxx).
>>>>>>
>>>>>> Intent is to have RIOT and then nimble integrated on this.
>>>>>>
>>>>>> thank you,
>>>>>> Akshay
>>>>>>
>>>>>> ___
>>>>>> devel mailing list
>>>>>> devel@riot-os.org
>>>>>> https://lists.riot-os.org/mailman/listinfo/devel
>>>>>>
>>>>>>
>>>>>> ___
>>>>>> devel mailing list
>>>>>> devel@riot-os.org
>>>>>> https://lists.riot-os.org/mailman/listinfo/devel
>>>>>>
>>>>> ___
>>>>> devel mailing list
>>>>> devel@riot-os.org
>>>>> https://lists.riot-os.org/mailman/listinfo/devel
>>>>>
>>>>> ___
>>>>> devel mailing list
>>>>> devel@riot-os.org
>>>>> https://lists.riot-os.org/mailman/listinfo/devel
>>>>>
>>>> ___
>>>> devel mailing list
>>>> devel@riot-os.org
>>>> https://lists.riot-os.org/mailman/listinfo/devel
>>>>
>>> ___
>>> devel mailing list
>>> devel@riot-os.org
>>> https://lists.riot-os.org/mailman/listinfo/devel
>>>
>>
>>
>> --
>> *Akshay Mishra*
>> *Chief Technology Officer*
>> GSM: +91 98693 21611
>> Skype: mishrakshay
>> Office: +91 22 2500 3488
>>
> ___
> 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] BG22/ EFR32

[Bas Stottelaar]

Hi Akshay,

I received the SLTB010A yesterday and have already prepared all vendor
files.

Support for Cortex-M33 isn't there yet, but I hope it's straightforward
(it's basically a successor of the M4 according to the Silabs docs). I also
need to update the EFM32 device drivers in RIOT-OS to support the series 2
microcontrollers. According to AN0918.2
<https://www.silabs.com/documents/public/application-notes/an0918.2-efm32-to-efr32xg2x-migration-guide.pdf>,
it should be quite easy as long as we're using EMLIB (which we do). Gecko
SDK was already updated to support the series 2 microcontrollers.

It's a bit more work than I thought, but I hope to have a first version
that works this weekend.

Kind regards,

Bas Stottelaar



Op za 20 jun. 2020 om 23:59 schreef Akshay Mishra :

> Thanks Bas. That's a Cortex-M33 chip. I believe there isn't any CM33 as
> yet on RIOT otherwise.
>
> Warm regards,
> Akshay
>
> On Sun, 21 Jun, 2020, 03:10 Bas Stottelaar, 
> wrote:
>
>> I just ordered that board. I think I can make an initial PR this week.
>>
>> Kind regards
>> Bas
>>
>> Op 20 jun. 2020 om 23:30 heeft Akshay Mishra  het
>> volgende geschreven:
>>
>> 
>> Hello Bas,
>>
>>  Yes SLTB010A is indeed the board I plan to use
>>
>> Thank You,
>> Akshay
>>
>>
>> On Sun, 21 Jun, 2020, 02:03 Bas Stottelaar, 
>> wrote:
>>
>>> Hi Akshay,
>>>
>>> The EFM32 and EFR32 family are supported, but it depends on the board
>>> definitions.
>>>
>>> Are you using the SLTB010A board? I see that that one is using the
>>> EFR32BGxx. If so, I can start a PR to add support for it.
>>>
>>> Kind regards,
>>> Bas Stottelaar
>>>
>>> Op 20 jun. 2020, om 19:46 heeft Akshay Mishra 
>>> het volgende geschreven:
>>>
>>> Hello RIOTers,
>>> I have been a very long time lurker here with some
>>> porting and development but mostly using what's been done. I am looking at
>>> BG22 from Silabs and wanted to inquire if there has been any initiation
>>> towards this family (EFR32BGxx).
>>>
>>> Intent is to have RIOT and then nimble integrated on this.
>>>
>>> thank you,
>>> Akshay
>>>
>>> ___
>>> devel mailing list
>>> devel@riot-os.org
>>> https://lists.riot-os.org/mailman/listinfo/devel
>>>
>>>
>>> ___
>>> devel mailing list
>>> devel@riot-os.org
>>> https://lists.riot-os.org/mailman/listinfo/devel
>>>
>> ___
>> devel mailing list
>> devel@riot-os.org
>> https://lists.riot-os.org/mailman/listinfo/devel
>>
>> ___
>> devel mailing list
>> devel@riot-os.org
>> https://lists.riot-os.org/mailman/listinfo/devel
>>
> ___
> devel mailing list
> devel@riot-os.org
> https://lists.riot-os.org/mailman/listinfo/devel
>
___
devel mailing list
devel@riot-os.org
https://lists.riot-os.org/mailman/listinfo/devel

Re: [riot-devel] BG22/ EFR32

[Bas Stottelaar]

I just ordered that board. I think I can make an initial PR this week.

Kind regards
Bas

> Op 20 jun. 2020 om 23:30 heeft Akshay Mishra  het 
> volgende geschreven:
> 
> 
> Hello Bas,
> 
>  Yes SLTB010A is indeed the board I plan to use
> 
> Thank You,
> Akshay
> 
> 
>> On Sun, 21 Jun, 2020, 02:03 Bas Stottelaar,  wrote:
>> Hi Akshay,
>> 
>> The EFM32 and EFR32 family are supported, but it depends on the board 
>> definitions.
>> 
>> Are you using the SLTB010A board? I see that that one is using the 
>> EFR32BGxx. If so, I can start a PR to add support for it.
>> 
>> Kind regards,
>> Bas Stottelaar
>> 
>>> Op 20 jun. 2020, om 19:46 heeft Akshay Mishra  het 
>>> volgende geschreven:
>>> 
>>> Hello RIOTers,
>>> I have been a very long time lurker here with some porting 
>>> and development but mostly using what's been done. I am looking at BG22 
>>> from Silabs and wanted to inquire if there has been any initiation towards 
>>> this family (EFR32BGxx).
>>> 
>>> Intent is to have RIOT and then nimble integrated on this.
>>> 
>>> thank you,
>>> Akshay
>>> 
>>> ___
>>> 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] BG22/ EFR32

[Bas Stottelaar]

Hi Akshay,

The EFM32 and EFR32 family are supported, but it depends on the board 
definitions.

Are you using the SLTB010A board? I see that that one is using the EFR32BGxx. 
If so, I can start a PR to add support for it.

Kind regards,
Bas Stottelaar

> Op 20 jun. 2020, om 19:46 heeft Akshay Mishra  het 
> volgende geschreven:
> 
> Hello RIOTers,
> I have been a very long time lurker here with some porting 
> and development but mostly using what's been done. I am looking at BG22 from 
> Silabs and wanted to inquire if there has been any initiation towards this 
> family (EFR32BGxx).
> 
> Intent is to have RIOT and then nimble integrated on this.
> 
> thank you,
> Akshay
> 
> ___
> devel mailing list
> devel@riot-os.org
> https://lists.riot-os.org/mailman/listinfo/devel

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

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

[Bas Stottelaar]

Hi Gaëten,

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

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

Kind regards,
Bas

> Op 26 aug. 2019 om 14:41 heeft Gaëtan Harter  het 
> volgende geschreven:
> 
> Dear RIOT developers,
> 
> as part of migrating CPU and CPU_MODEL definition to `Makefile.features` I am 
> facing custom handling of multiple boards in the same directory with sometime 
> creative handling but not a proper build system integration.
> 
> There are multiple issues with this:
> * none of the alternative boards are ever be compiled in the CI
> * when testing, giving multiple variables to specify a board is not really 
> handled
> * building the separate boards is not handled with `BUILD_IN_DOCKER`
> * custom non standard configuration variables that are not properly handled 
> in the whole build system
> 
> The current implementation are currently done through:
> 
> * Using a default `CPU_MODEL ?= default_model` however the `CPU_MODEL` 
> variable is not passed to docker
>  * mulle (2 possibilities)
>  * pba-d-01-kw2x (3 possibilities)
>  * cc2538dk (no documentation but I think this one is just a mis-write and 
> not a wanted thing)
> * Using a `STM32F103C8_FLASH_HACK` variable to just set a different 
> `CPU_MODEL`. It applies to `bluepill` and `blackpill` but is just documented 
> for the `bluepill`
> * An undocumented `BOARD_MODULE` variable that triggers a wildcard then a 
> grep to find `CPU_MODEL` (yes it queries your filesystem for a static 
> mapping). Its generic with many possible values but only implemented for 2 
> "board modules"
> 
> I would like to know who really uses these boards modifications, and what we 
> should do with them.
> Why were they implemented in the first place instead of having separate 
> boards? Would have prevented having them merged?
> 
> Should we just split all these boards, it would currently result in 5 or 6 
> boards (depending on the blackpill).
> 
> Should we keep support for multiple boards together? if yes, can we limit to 
> only changing `CPU_MODEL` through this variable and remove the other custom 
> handling? Still knowing they would not be automatically tested by CI.
> 
> I am willing to take care of the required changes when a direction is decided.
> 
> Regards,
> Gaëtan - cladmi
> ___
> devel mailing list
> devel@riot-os.org
> https://lists.riot-os.org/mailman/listinfo/devel
___
devel mailing list
devel@riot-os.org
https://lists.riot-os.org/mailman/listinfo/devel

Re: [riot-devel] EFM32 timers, PWM and xtimer

[Bas Stottelaar]

Hi Chrysn,

The two timers are needed, because they run in cascade mode. Only that way,
I can generate values for XTIMER_HZ that have sufficient resolution. I
don't recall the details, but I haven't found another way. The recommended
MCU oscillators are typically 38.4 or 40 MHz, and the prescaler is always a
power of two, so I cannot get 1us precision with only one timer.

The newer chips have an additional 32-bit timer with the same problem, but
this frees up timers for PWM. I have a PR that I still need to fix though
;-)

Kind regards,

Op ma 12 nov. 2018 om 17:40 schreef chrysn :

> Hello RIOT developers,
>
> working with the EFM32 port trying to use some PWM pins, I found that of
> the four TIMER peripherals (each of which is tied to particular sets of
> PWM pins it can drive), two adjacent[1] ones are in use
> for a combined RIOT timer peripheral that them forms also the
> XTIMER_DEV. This means that two timers (1 and 2 of 0, 1, 2 and 3) are
> practically unusable for any PWM.
>
> Before I go head-first into hacking something together with a timer
> implementation based on the RTC or the systick peripheral, was there a
> particular rationale behind making this the default timer on EFM32?
>
> AFAICS, the design does make sense when it comes to creating arbitrary
> timers (where the lower timer gets its fine-grained top value output a
> precise frequency), but that isn't really required when it comes to
> providing a timer for XTIMER which has its own XTIMER_HZ value which
> "just" needs to set to an adaequate value. How is the trade-off between
> having PWM devices vs. having a fine-grained-fixed-frequency capable
> timer usually handled?
>
> Thanks
> chrysn
>
> [1]:  That's a limitation of the chips, where TIMEROUF only works
> between adjacent timers.
>
> --
> To use raw power is to make yourself infinitely vulnerable to greater
> powers.
>   -- Bene Gesserit axiom
> ___
> devel mailing list
> devel@riot-os.org
> https://lists.riot-os.org/mailman/listinfo/devel
>
___
devel mailing list
devel@riot-os.org
https://lists.riot-os.org/mailman/listinfo/devel

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

[Bas Stottelaar]

I have been using gcov to visualize my coverage for the KNX tests. I did it
from the command line, so no Makefile hacking, and only for native. Can
share my commands that I have been using.

Kind regards,

Bas Stottelaar



Op di 9 okt. 2018 om 16:26 schreef Martine Lenders :

> Hi,
>
> as there is some discussion to split the unittests into several
> applications [1] and some stuff isn't included into them for good reasons
> (driver test e.g.), I'm not sure if this should be constrained to unittests
> (though they are indeed a good starting point).
>
> Regards,
> Martine
>
> PS: I'm not aware of work going into that direction, so +1 in general.
>
> [1] https://github.com/RIOT-OS/RIOT/issues/8941
>
> Am Di., 9. Okt. 2018 um 16:17 Uhr schrieb STEGEN Toon <
> tste...@nalys-group.com>:
>
>> Hi Guys,
>>
>>
>> Has anybody succeeded in getting gcov to work to check code coverage of
>> the unit tests?
>>
>> We will try to add support for this, but I want to make sure we're not
>> spending our time on unnecessary work.
>>
>>
>> Greets,
>>
>> Toon Stegen
>> ___
>> devel mailing list
>> devel@riot-os.org
>> https://lists.riot-os.org/mailman/listinfo/devel
>>
> ___
> devel mailing list
> devel@riot-os.org
> https://lists.riot-os.org/mailman/listinfo/devel
>
___
devel mailing list
devel@riot-os.org
https://lists.riot-os.org/mailman/listinfo/devel

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

[Bas Stottelaar]

Nice!

Thanks for your effort for managing this, Dylan!

Kind regards,

Bas



Op do 2 aug. 2018 om 12:49 schreef Dylan Laduranty :

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

Re: [riot-devel] External Flash Memory Usage

[Bas Stottelaar]

Hi Janna,

You could take a look at [1]. You should be able to run it natively (also,
check out the README.md). That example shows how to use a file system,
which would be something useful in your case.

Kind regards,

Bas Stottelaar

[1] https://github.com/RIOT-OS/RIOT/tree/master/examples/filesystem



Op wo 4 jul. 2018 om 12:12 schreef Janna Om :

> Hello,
> I am new to embedded programming.
> I want to write my log data to an external memory and read it out again.
> Unfortunately, i don't see how i can do that.
> Maybe someone can help me and tell me what i need and how i can do it?
> I work with iot-lab M3 nodes.
> Many thanks in advance!
> With kind regards,
> Janna
> ___
> devel mailing list
> devel@riot-os.org
> https://lists.riot-os.org/mailman/listinfo/devel
>
___
devel mailing list
devel@riot-os.org
https://lists.riot-os.org/mailman/listinfo/devel

Re: [riot-devel] Dropping FEATURES_MCU_GROUP?

[Bas Stottelaar]

+1 if it's not used.

Kind regards,

Bas Stottelaar


2018-04-24 7:02 GMT+02:00 Joakim Nohlgård <joakim.nohlg...@eistec.se>:

> Hi developers,
> Is the old FEATURES_MCU_GROUP variable used by tools anymore?
> AFAIK Murdock tracks build status per board/app tuple, without
> grouping by families or anything.
> It might be time to drop it from the board configurations to avoid
> confusing newcomers.
>
> Best regards,
> Joakim
> ___
> 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 policy on hardware support without example board

[Bas Stottelaar]

Hi all,

I think this board would come close: it features the ATmega1284P with an
RTC:
https://www.microchip.com/DevelopmentTools/ProductDetails.aspx?PartNO=ATMEGA1284P-XPLD
.

Kind regards,

Bas Stottelaar


2018-03-16 7:03 GMT+01:00 Joakim Nohlgård <joakim.nohlg...@eistec.se>:

> Hi again,
>
> Is there no readily available commercial dev boards which feature an
> RTC crystal? Generally, boards in the main repo have to be available
> commercially or at least accessible for a large number of users
> (IoT-lab boards for example are only available in the IoT-lab test
> sites, but they are open to the public). I don't think your custom dev
> board will be accepted unless you are selling it, at least in small
> volumes, so that other users may benefit from the board config. It may
> be easier to just find some pre-made dev board which have similar
> peripheral set up and add a configuration for that to be able to add
> the CPU.
>
> /Joakim
>
> On Thu, Mar 15, 2018 at 4:55 PM, Matthew Blue
> <matthew.blue.ne...@gmail.com> wrote:
> > Hello Joakim,
> >
> > I do have such a board: the board I am developing for. I also already
> > have it ported and passing many of the manual tests. However, my concern
> > is that I do not anticipate this board being generally available,
> > because of the kind of product it is going to be in. Is it okay for me
> > to be the only developer with access to a board in the main repository?
> > I assumed that others would wish everything in /boards to be generally
> > available. However, adding it to the main repository would allow the CI
> > system to run automated tests against its peripherals.
> >
> > There are other boards using the same MCU, but they do not have the
> > peripherals that my board has. For instance, I have almost finished RTT
> > support for the ATMegas, but none of the Arduinos breaks out the pins
> > that would allow you to add a 32kHz crystal.
> >
> > Sincerely,
> > Matthew
> >
> >
> > On Thu, 15 Mar 2018 09:20:37 +0100
> > Joakim Nohlgård <joakim.nohlg...@eistec.se> wrote:
> >
> >> Hi Matthew,
> >> Generally, everything in the main repository should be covered by the
> >> automatic compilation tests performed by the CI system, which is why
> >> all CPUs must have at least one board using them. Perhaps you have
> >> some development board which uses the same CPU that you can add a
> >> basic configuration for? A board configuration can be quite simple if
> >> you only need the basic features, and should not take a lot of effort
> >> to produce. Maybe there is an Arduino board or similar which uses the
> >> same CPU?
> >> The drivers for TCA9539 and ADS1015 can be integrated in the main repo
> >> as long as there is a simple test program for them so that they are
> >> built by the CI, and so that they can be tested on actual hardware
> >> with only adding the pin/bus configuration for the experiment setup.
> >> See the existing tests for some drivers in the main repo e.g.
> >> tests/driver_ina220
> >>
> >> Best regards,
> >> Joakim
> >>
> >> On Wed, Mar 14, 2018 at 6:49 PM, Matthew Blue
> >> <matthew.blue.ne...@gmail.com> wrote:
> >> > Hello all,
> >> >
> >> > I am building mesh networking sensor arrays for agriculture, and I
> >> > am working on RIOT as an operating system for them. I have a number
> >> > of bits of hardware that I need to write support for and I would
> >> > like to contribute that back to RIOT. However, since this is ag
> >> > equipment designed to be deployed in large quantities, I expect
> >> > that it will not really be available for developers other than
> >> > myself to test on.
> >> >
> >> > What is the RIOT community's policy on submitting support for things
> >> > like CPUs and peripherals without a board implementing them? I
> >> > intend to support what I contribute into the foreseeable future. I
> >> > suspect that having hardware already supported will influence
> >> > future board designs if they are intended to run a system like RIOT
> >> > (it influenced some of my design choices).
> >> >
> >> > Some of the specific bits I intend to add are the ATmega1284P MCU,
> >> > the TCA9539 I2C GPI expander, and the ADS1015 ADC (and variants).
> >> >
> >> > Sincerely,
> >> > Matthew
> >> > ___
> >> > devel mailing list
> >> > devel@riot-os.org
> >> > https://lists.riot-os.org/mailman/listinfo/devel
> >> ___
> >> devel mailing list
> >> devel@riot-os.org
> >> https://lists.riot-os.org/mailman/listinfo/devel
> >
> > ___
> > devel mailing list
> > devel@riot-os.org
> > https://lists.riot-os.org/mailman/listinfo/devel
> ___
> devel mailing list
> devel@riot-os.org
> https://lists.riot-os.org/mailman/listinfo/devel
>
___
devel mailing list
devel@riot-os.org
https://lists.riot-os.org/mailman/listinfo/devel

Re: [riot-devel] Notification: Monthly RIOT developer meeting @ Mon Feb 26, 2018 5pm - 6pm (CET) (RIOT Events)

[Bas Stottelaar]

Hi all,

Can we add Koen's mail [1] about easing maintainer burden to the agenda? I
think there are some points RIOT could benefit from.

Kind regards,

Bas Stottelaar

[1] https://lists.riot-os.org/pipermail/devel/2018-February/005627.html


2018-02-25 20:08 GMT+01:00 Francisco Acosta <francisco.aco...@inria.fr>:

> Hi devs!
>
> Just a gentle reminder for our next developers meeting which will take
> place this Monday February 26th at 17:00 CET.
>
> Proposed agenda:
>
> - Next release goals
> - Testing the RIOT
>
> As always, you're invited to propose topics you'd like to discuss. I'll
> open a pad asap for the meeting notes and to list the topics.
>
> Thanks in advance for you attendance!
>
> Best,
>
> Francisco.
>
>
>
> On 25 February 2018 16:59:58 CET, Google Calendar <
> calendar-notificat...@google.com> wrote:
> >This is a notification for:
> >
> >Title: Monthly RIOT developer meeting
> >When: Mon Feb 26, 2018 5pm – 6pm Berlin
> >Where: Online
> >Calendar: RIOT Events
> >Who:
> > * Martine Lenders - creator
> >
> >Event details:
> >https://www.google.com/calendar/event?action=VIEW=
> NnFpMGh0a2RpajN0OWQ3bjhoa3VmdWdiMTFfMjAxODAyMjZUMTYwMDAwWiBr
> M3FsOHNldHY3bDQ4b2Zub2wwdGZ1dTZ0c0Bn
> >
> >Invitation from Google Calendar: https://www.google.com/calendar/
> >
> >You are receiving this email at the account peterschme...@gmail.com
> >because
> >you are subscribed for notifications on calendar RIOT Events.
> >
> >To stop receiving these emails, please log in to
> >https://www.google.com/calendar/ and change your notification settings
> >for
> >this calendar.
> >
> >Forwarding this invitation could allow any recipient to modify your
> >RSVP
> >response. Learn more at
> >https://support.google.com/calendar/answer/37135#forwarding
> ___
> devel mailing list
> devel@riot-os.org
> https://lists.riot-os.org/mailman/listinfo/devel
>
___
devel mailing list
devel@riot-os.org
https://lists.riot-os.org/mailman/listinfo/devel

Re: [riot-devel] RIOT code generator

[Bas Stottelaar]

Hi Alex,

I like it! I have added two issues with some ideas on the Github page
directly.

Kind regards,

Bas Stottelaar


2018-02-14 8:39 GMT+01:00 Alexandre Abadie <alexandre.aba...@inria.fr>:

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

Re: [riot-devel] Micropython Port for RIOT OS

[Bas Stottelaar]

Hi Dimitris,

You should check out https://github.com/RIOT-OS/RIOT/pull/2968 
. It’s a PR by Kaspar, so you should 
check out his fork if you want to test it.

On the MicroPython side: https://github.com/micropython/micropython/pull/1249 
.

Kind regards,
Bas

> Op 5 mrt. 2017, om 13:27 heeft Dimitris Kazantzas 
>  het volgende geschreven:
> 
> Hi, while browsing the wiki I checked the GSOC ideas. I noticed the idea for 
> the port of micropython for RIOT OS. The wiki said that there is already a 
> prototype port. Where could I find this port?
> ___
> 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] PWM on Atmega256rfr2

[Bas Stottelaar]

Hi Steffen,

Have you taken a look at existing implementations? For instance, the PWM
driver for the STM32 [1, 2]?

* The pwm_init enables the PWM peripheral, given a frequency and
resolution. Frequency and resolution relate [3].
* The number of available channels is returned by pwm_channels. Many MCUs
have multiple channels (outputs) for one timer/counter.
* A value is set via pwm_set.
* The pwm_start/pwm_stop should start/stop the PWM, without disabling the
peripheral.
* The pwm_poweron/pwm_poweroff should power-on/power-off the peripheral.

You'll have to start by extending periph_cpu to add a definition for the
PWM structure for your board (see [2] as an example). Then implement the
driver (see [1] as an example).

Kind regards,

Bas Stottelaar

[1]
https://github.com/RIOT-OS/RIOT/blob/master/cpu/stm32_common/periph/pwm.c
[2]
https://github.com/RIOT-OS/RIOT/blob/master/cpu/stm32_common/include/periph_cpu_common.h#L132-L150
[3] https://community.nxp.com/thread/97642

2017-01-22 18:03 GMT+01:00 Steffen Robertz <steffen.robe...@rwth-aachen.de>:

> Hi,
>
> I recently started using RIOT OS for my Bachelor Thesis.
> My first task is to implement the pwm periphal in order to use it with an
> rgb led.
> And that already is where my problems start: I don't understand how the
> functions in pwm.h are supposed to work and therefore can't implement them
> in my pwm.c.
>
> Can anybody provide more information than the comments in the pwm.h?
>
> Any help will be appriciated.
>
> Best regards,
>
> Steffen
>
> ___
> 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] SiLabs Gecko

[Bas Stottelaar]

Hi Akshay,

Somewhat related, but I have been working on EFM32 support for RIOT-OS in
the past year. You can find my work (in progress) at [1]. A PR for one
specific board (Thunderboard Sense) is at [2].

Chances are that [3] relies on the use of 'emlib'. In that case, I would
strongly suggest to look at my work to not reinvent the wheel. I have
implemented most peripherals (on top of emlib) for all EFM32 MCU's
available (>400).

Kind regards,

Bas Stottelaar

[1] https://github.com/basilfx/EFM2RIOT
[2] https://github.com/RIOT-OS/RIOT/pull/5652
[3] https://siliconlabs.github.io/Gecko_SDK_Doc/ezr32lg/html/ez
radio__comm_8c_source.html


2016-12-08 10:54 GMT+01:00 Hauke Petersen <hauke.peter...@fu-berlin.de>:

> Hi Akshay,
>
> if I understand it correctly, you use the ezr32lg? So I would suggest you
> start by porting that CPU first:
> - create the `ezr32lg` cpu
> - create a `ezr32_common` folder
> - move everything from the `ezr32wg` to the common folder that can be
> re-used (I would suppose this includes all periph drivers + most of the
> arch code)
>
> Next than you can implement the radio driver, as a rough guideline have a
> look at the (early) device driver implementation guideline [1].
>
> Cheers,
> Hauke
>
> [1] https://github.com/RIOT-OS/RIOT/wiki/Guide:-Writing-a-
> device-driver-in-RIOT
>
>
>
> On 08.12.2016 10:28, Akshay Mishra wrote:
>
> Thanks Martine,
> It is possible that there is no RF support (I thought so but was not
> sure.). I can look at porting it if there can be pointers.
>
> The example used was gnrc_networking on the latest git clone.
>
> One confession, :-|, is that the EZR32WG is supported and I worked on the
> basic examples only modifying the WG to LG which changes it from Cortex-M4
> to Cortex-M3.
>
> *Akshay Mishra*
>
> On 8 December 2016 at 14:31, Martine Lenders < <m...@martine-lenders.eu>
> m...@martine-lenders.eu> wrote:
>
>> Hi Akshay,
>> I fear you have to be a bit more specific than that. What application
>> are you using e.g., which network stack? Also, I might be mistaking
>> but it seems like there is no RF support for the EZR32LG in master
>> yet. Maybe that is the problem?
>>
>> Cheers,
>> Martine
>>
>> 2016-12-08 8:34 GMT+01:00 Akshay Mishra < <aks...@dspworks.in>
>> aks...@dspworks.in>:
>> > Hello,
>> > I tried it on the SLWSTK6220a with the EZR32LG. While I was
>> able to
>> > get riot-os working on it, the ipv6 address does not get assigned.
>> >
>> > How does the interface get enabled ? I did not enable any tap on the
>> host.
>> >
>> > Thanks,
>> > Akshay
>> >
>> >
>> > ___
>> > 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 
> listdevel@riot-os.orghttps://lists.riot-os.org/mailman/listinfo/devel
>
>
>
> ___
> devel mailing list
> devel@riot-os.org
> https://lists.riot-os.org/mailman/listinfo/devel
>
>
___
devel mailing list
devel@riot-os.org
https://lists.riot-os.org/mailman/listinfo/devel

Re: [riot-devel] RIOT on Realtek RTL8710AF

[Bas Stottelaar]

Hi Thomas,

I have started a port (or PoC) of RIOT-OS for the general purpose RTL7810:
[1]. Back then, the PADI IoT Stamp was not yet released.

Some of the sources (and flash script) is based on the work of [2]. Due to
the lack of a decent SDK, I quit.

Kind regards,

Bas Stottelaar

[1]: https://github.com/basilfx/RIOT/tree/feature/rtl8710
[2]: https://bitbucket.org/rebane/


2016-11-18 6:20 GMT+01:00 Thomas Eichinger <tho...@riot-os.org>:

> All,
>
> Just got some of these PADI IoT Stamps [1] into my hands. Did anybody
> on this list start working on RIOT support for a Realtek RTL8710AF
> already?
>
> Best, Thomas
>
> [1] https://www.pine64.org/?page_id=917
> ___
> 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] Silicon Labs Microcontroller handed out at summit

[Bas Stottelaar]

Hi all,

No official documentation yet, but I just found this link:
https://www.mit.bme.hu/system/files/oktatas/targyak/9979/Silabs_Wireless_Gecko_MIT.pdf.
Page 32 describes all the sensors.

Seems like the part number/name is SLTB001A, and Thunderboard Sense is just
the marketing name.

Kind regards,

Bas Stottelaar


2016-07-18 11:21 GMT+02:00 Bas Stottelaar <basstottel...@gmail.com>:

> Hi Mathias,
>
> There are two chips: one is the board controller (for mbed-related stuff,
> virtual com, mass storage).
>
> The other is the actual chip, an EFR32MG1P132F256GM48 (as seen here:
> https://github.com/basilfx/EFM2Riot/blob/master/dist/doc/images/thunderboard_sense.png).
> That is, definitely a M4 with FPU.
>
> Kind regards,
>
> Bas Stottelaar
>
>
> 2016-07-18 10:45 GMT+02:00 Mathias Tausig <
> mathias.tau...@fh-campuswien.ac.at>:
>
>> Hy!
>>
>> Great that you already started working on it.
>> But I don't think that datasheet is quite accurate. The chip on the
>> backside of
>> the board states, that it is a Cortex-M3 processor, not an M4.
>>
>> On Mon, 2016-07-18 at 10:23 +0200, Bas Stottelaar wrote:
>> > Hi Mathias,
>> >
>> > I managed to get it working, based on the SLSTK3401a. I was lucky that
>> it
>> > shared the same pinout regarding the RX/TX. The reference manual and
>> > datasheet are available. I put the links in here:
>> >
>> https://github.com/basilfx/EFM2Riot/blob/master/dist/doc/Thunderboard%20Sense
>> .
>> > md
>> >
>> >
>> > You can find my PR here: https://github.com/RIOT-OS/RIOT/pull/5652.
>> Since I
>> > also work on other EFM32 targets, I have more to see here:
>> > https://github.com/basilfx/EFM2Riot.
>> >
>> > I don't have a driver for the radio. I leave that (the actual
>> challenge) up
>> > to who wants to win the hoodie :-)
>> >
>> > Kind regards,
>> >
>> > Bas Stottelaar
>> >
>> >
>> > 2016-07-18 10:15 GMT+02:00 Mathias Tausig <
>> > mathias.tau...@fh-campuswien.ac.at>:
>> >
>> > >
>> > > Hy!
>> > >
>> > > Does anyone have a link to the specification (or even some sort of
>> > > dccumentation) for the Silicon Labs microcontroller that was handed
>> out on
>> > > Friday at the summit? Unfortunately, the silabs website knows no
>> product
>> > > of that
>> > > name or part number.
>> > >
>> > > cheers
>> > > Mathias
>> > >
>> > > --
>> > > DI Mathias Tausig,
>> > > Kompetenzzentrum für IT-Security,
>> > >
>> > > FH Campus Wien,
>> > > Informationstechnologien und Telekommunikation.
>> > >
>> > > Favoritenstrasse 226, Raum B.2.18,
>> > > 1100 Wien, Austria.
>> > > T: +43 1 606 68 77-2142, F: +43 1 606 68 77-2139.
>> > > mathias.tau...@fh-campuswien.ac.at
>> > > PGP Key-ID: 75656BBF
>> > >
>> > > ___
>> > > 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
>> --
>> DI Mathias Tausig,
>> Kompetenzzentrum für IT-Security,
>>
>> FH Campus Wien,
>> Informationstechnologien und Telekommunikation.
>>
>> Favoritenstrasse 226, Raum B.2.18,
>> 1100 Wien, Austria.
>> T: +43 1 606 68 77-2142, F: +43 1 606 68 77-2139.
>> mathias.tau...@fh-campuswien.ac.at
>> PGP Key-ID: 75656BBF
>>
>> ___
>> 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] Silicon Labs Microcontroller handed out at summit

[Bas Stottelaar]

Hi Mathias,

There are two chips: one is the board controller (for mbed-related stuff,
virtual com, mass storage).

The other is the actual chip, an EFR32MG1P132F256GM48 (as seen here:
https://github.com/basilfx/EFM2Riot/blob/master/dist/doc/images/thunderboard_sense.png).
That is, definitely a M4 with FPU.

Kind regards,

Bas Stottelaar


2016-07-18 10:45 GMT+02:00 Mathias Tausig <
mathias.tau...@fh-campuswien.ac.at>:

> Hy!
>
> Great that you already started working on it.
> But I don't think that datasheet is quite accurate. The chip on the
> backside of
> the board states, that it is a Cortex-M3 processor, not an M4.
>
> On Mon, 2016-07-18 at 10:23 +0200, Bas Stottelaar wrote:
> > Hi Mathias,
> >
> > I managed to get it working, based on the SLSTK3401a. I was lucky that it
> > shared the same pinout regarding the RX/TX. The reference manual and
> > datasheet are available. I put the links in here:
> >
> https://github.com/basilfx/EFM2Riot/blob/master/dist/doc/Thunderboard%20Sense
> .
> > md
> >
> >
> > You can find my PR here: https://github.com/RIOT-OS/RIOT/pull/5652.
> Since I
> > also work on other EFM32 targets, I have more to see here:
> > https://github.com/basilfx/EFM2Riot.
> >
> > I don't have a driver for the radio. I leave that (the actual challenge)
> up
> > to who wants to win the hoodie :-)
> >
> > Kind regards,
> >
> > Bas Stottelaar
> >
> >
> > 2016-07-18 10:15 GMT+02:00 Mathias Tausig <
> > mathias.tau...@fh-campuswien.ac.at>:
> >
> > >
> > > Hy!
> > >
> > > Does anyone have a link to the specification (or even some sort of
> > > dccumentation) for the Silicon Labs microcontroller that was handed
> out on
> > > Friday at the summit? Unfortunately, the silabs website knows no
> product
> > > of that
> > > name or part number.
> > >
> > > cheers
> > > Mathias
> > >
> > > --
> > > DI Mathias Tausig,
> > > Kompetenzzentrum für IT-Security,
> > >
> > > FH Campus Wien,
> > > Informationstechnologien und Telekommunikation.
> > >
> > > Favoritenstrasse 226, Raum B.2.18,
> > > 1100 Wien, Austria.
> > > T: +43 1 606 68 77-2142, F: +43 1 606 68 77-2139.
> > > mathias.tau...@fh-campuswien.ac.at
> > > PGP Key-ID: 75656BBF
> > >
> > > ___
> > > 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
> --
> DI Mathias Tausig,
> Kompetenzzentrum für IT-Security,
>
> FH Campus Wien,
> Informationstechnologien und Telekommunikation.
>
> Favoritenstrasse 226, Raum B.2.18,
> 1100 Wien, Austria.
> T: +43 1 606 68 77-2142, F: +43 1 606 68 77-2139.
> mathias.tau...@fh-campuswien.ac.at
> PGP Key-ID: 75656BBF
>
> ___
> 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] Silicon Labs Microcontroller handed out at summit

[Bas Stottelaar]

Hi Mathias,

I managed to get it working, based on the SLSTK3401a. I was lucky that it
shared the same pinout regarding the RX/TX. The reference manual and
datasheet are available. I put the links in here:
https://github.com/basilfx/EFM2Riot/blob/master/dist/doc/Thunderboard%20Sense.md


You can find my PR here: https://github.com/RIOT-OS/RIOT/pull/5652. Since I
also work on other EFM32 targets, I have more to see here:
https://github.com/basilfx/EFM2Riot.

I don't have a driver for the radio. I leave that (the actual challenge) up
to who wants to win the hoodie :-)

Kind regards,

Bas Stottelaar


2016-07-18 10:15 GMT+02:00 Mathias Tausig <
mathias.tau...@fh-campuswien.ac.at>:

> Hy!
>
> Does anyone have a link to the specification (or even some sort of
> dccumentation) for the Silicon Labs microcontroller that was handed out on
> Friday at the summit? Unfortunately, the silabs website knows no product
> of that
> name or part number.
>
> cheers
> Mathias
>
> --
> DI Mathias Tausig,
> Kompetenzzentrum für IT-Security,
>
> FH Campus Wien,
> Informationstechnologien und Telekommunikation.
>
> Favoritenstrasse 226, Raum B.2.18,
> 1100 Wien, Austria.
> T: +43 1 606 68 77-2142, F: +43 1 606 68 77-2139.
> mathias.tau...@fh-campuswien.ac.at
> PGP Key-ID: 75656BBF
>
> ___
> 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] Long time sleeping of the microcontroller

[Bas Stottelaar]

Hi Bernard,

I have created two examples that leverages the low-power modes of the EFM32 MCU 
that I am working on.

Although this example is still very hardware dependent (because it is 
device-specific that the RTT can wakeup the MCU from sleep), I can get it down 
to 10µA in sleep (without other optimizations) with a wakeup time of ~2µs.

If you are interested, see 
https://github.com/basilfx/EFM2Riot/blob/master/dist/examples/sleep_wakeup/main.c
 
,
 
https://github.com/basilfx/EFM2Riot/blob/master/dist/examples/sleep_wakeup_measure/main.c
 

 and probably 
https://github.com/basilfx/EFM2Riot/blob/master/dist/cpu/efm32_common/lpm_arch.c
 

 too.

Kind regards,
Bas

> Op 4 jun. 2016, om 14:15 heeft Bernhard Nägele  
> het volgende geschreven:
> 
> Hello RIOT-enthusiasts,
> I'm searching for a good way to bring a RIOT-system to lowest power modes for 
> several minutes.
> As far as I understand the function of the xtimer is designed to provide the
> timebase for thread/task switching and providing short low-power-delays.
> It is therefore not designed to support slow clock timers inside low-power 
> microcontrollers.
> Is this true?
> Can you give tell me your opinion about using the slow-clock timer simply 
> inside
> the application? The idea is to bring the peripherals to lowest power mode, 
> then
> stop all threads except the main thread, mask interrupts und stop then the
> microcontroller under the control of the application. The wakeup could happen
> by using an interrupt from the slow-clock-timer inside the CPU.
> 
> Is this a way which could work?
> 
> Best regards,
> Bernhard
> ___
> 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] Two additions

[Bas Stottelaar]

Hi all,

I finally joined the mailing list :-)

Two questions about potential contributions:

* Out of personal interest I have created/implemented the Fortuna (CS)PRNG
[1,2] (still WIP + needs AES256). Contrary to the Tiny Mersenne Twister,
this PRNG is bigger and slower, but more secure. I believe native/boards
with crypto accelerators could benefit.

* I ported U8glib [3] and got it working with a SPI LCD:
https://www.youtube.com/watch?v=bG5_EwFTiDc. I already showed this on IRC,
but wanted to share this with the rest that hasn't seen it yet. It can also
emulate a display on stdout.

Would both be valuable contributions, or can I better wait for the
(hopefully upcoming) 'RIOT package manager' [4]?

Kind regards,
Bas Stottelaar

[1] https://www.schneier.com/cryptography/paperfiles/fortuna.pdf
[2] https://github.com/basilfx/RIOT/tree/feature/fortuna
[3] https://github.com/basilfx/RIOT/tree/feature/u8glib
[4] https://github.com/RIOT-OS/RIOT/pull/4478
___
devel mailing list
devel@riot-os.org
https://lists.riot-os.org/mailman/listinfo/devel