[riot-devel] putting the nrf52 to sleep
Dear RIOTers, How do I put the nrf52 to sleep? I need to wake on GPIO interrupt but go in low-power mode till then. I could not find the reference for the same, thanks, Akshay ___ devel mailing list devel@riot-os.org https://lists.riot-os.org/mailman/listinfo/devel
Re: [riot-devel] BG22/ EFR32
I have been able to build and flash the code on the BG22 board. On Wed, Jul 8, 2020 at 12:16 PM Bas Stottelaar wrote: > 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 in
Re: [riot-devel] BG22/ EFR32
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 >>> 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 < >>>>>>> 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 >>>>>>>
Re: [riot-devel] BG22/ EFR32
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
Re: [riot-devel] BG22/ EFR32
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
Re: [riot-devel] BG22/ EFR32
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
Re: [riot-devel] BG22/ EFR32
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
[riot-devel] BG22/ EFR32
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
Re: [riot-devel] SiLabs Gecko
Hello Bas, I checked against EFM2RIOT. EZR32LG works with it also like a charm. Also the siliconlabs driver rely on peripherals which you do seem to have covered. the efm32_common covers the peripherals. thanks, On 8 December 2016 at 15:37, Bas Stottelaar wrote: > 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/ezradio__comm_8c_source.html > > > 2016-12-08 10:54 GMT+01:00 Hauke Petersen : > >> 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> 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>: >>> > 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 > > ___ devel mailing list devel@riot-os.org https://lists.riot-os.org/mailman/listinfo/devel
Re: [riot-devel] SiLabs Gecko
I have located the track. Now the license question -- Is it ok to use bits of code from the Silicon Labs driver here ( https://siliconlabs.github.io/Gecko_SDK_Doc/ezr32lg/html/ ezradio__comm_8c_source.html) as per RIOT-OS licensing norms ? On 8 December 2016 at 14:58, 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 > 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 : >> > 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 list devel@riot-os.org https://lists.riot-os.org/mailman/listinfo/devel
Re: [riot-devel] SiLabs Gecko
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 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 : > > 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 list devel@riot-os.org https://lists.riot-os.org/mailman/listinfo/devel
[riot-devel] SiLabs Gecko
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
Re: [riot-devel] LoRaWAN implementation under RIOT
I am willing to donate 2 LoRa transceiver modules towards this effort if there is somebody working on it. We have our own modules on LoRa and it is without any MCU onboard. Warm Regards, Akshay *Akshay Mishra* *Chief Technology Officer* GSM: +91 98693 21611 Skype: mishrakshay Office: +91 22 2500 3488 On 26 October 2016 at 20:00, Emmanuel Baccelli wrote: > Hi there, > > Any news on this? > Is there a branch available somewhere? > > Best, > > Emmanuel > > On Mon, Jun 20, 2016 at 3:20 PM, Anon Anonymous > wrote: > >> Hi, RIOTers! >> >> After a couple of months I've finished a Semtech's SX1276 LoRa >> transceiver driver (physical level, RX and TX) under RIOT (pull request >> coming soon!) and the next step is a LoRaWAN MAC level implementation. >> >> My question is: >> Which RIOT interfaces should I choose to implement next to introduce >> LoRaWAN MAC level as seamlessly as possible into existing RIOT's networking >> stacks? >> >> Thanks in advance for any help and clarifications! >> >> Best regards. >> >> ___ >> 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] Soil Moisture Sensor
On 13 October 2016 at 15:08, Peter Kietzmann wrote: > Hi, > > Am 13.10.2016 um 11:17 schrieb ALESSANDRO NICOLI: > > Hi Peter, > > I've used the default parameters for ADC_0, that are described in the > > attached (RIOT/boards/samr21-xpro/include/periph_conf.h). > > okay but that configuration is not in RIOT master :-) cause there is no > official ADC driver until now. > > > > > Hi Akshay, > > Yes, i tried to let the sensor floats in air, with a 10bit precision, and > > it gives me back a plausible value (less than 40/1024). > > Than i tried to put it in mineral water, and it replied with a value next > > to 1000/1024, that it seems to be correct. > > It seems the ADC actually works correctly and your issue is about the > behaviour of the sensor in soil? > > does the same soil sample work for other sensors ? I "feel" there is some loose connection on your sensor connection or some such thing on this board. maybe when you insert it comes out/ shorts somewhere. > > > > Only in the soil (where it should works correctly) it gives back a > no-sense > > value...and i don't know why. > > > > Did you play around with the density of the soil and -of course- water > level of the plant? > > Best > Peter > > > > > thanks a lot! > > > > *best regards, * > > *Alessandro* > > > > 2016-10-12 9:48 GMT+02:00 : > > > >> Send devel mailing list submissions to > >> devel@riot-os.org > >> > >> To subscribe or unsubscribe via the World Wide Web, visit > >> https://lists.riot-os.org/mailman/listinfo/devel > >> or, via email, send a message with subject or body 'help' to > >> devel-requ...@riot-os.org > >> > >> You can reach the person managing the list at > >> devel-ow...@riot-os.org > >> > >> When replying, please edit your Subject line so it is more specific > >> than "Re: Contents of devel digest..." > >> > >> > >> Today's Topics: > >> > >>1. Soil Moisture Sensor (ALESSANDRO NICOLI) > >>2. Re: Soil Moisture Sensor (Peter Kietzmann) > >>3. Re: Soil Moisture Sensor (Akshay Mishra) > >>4. I2C driver function to read a register with 16 bits address > >> (Kees Bakker) > >>5. Re: alternative socket-api (Kaspar Schleiser) > >>6. Re: I2C driver function to read a register with 16 bits > >> address (Hauke Petersen) > >>7. Coding conventions amendment (Oleg Hahm) > >> > >> > >> -- > >> > >> Message: 1 > >> Date: Tue, 11 Oct 2016 16:32:22 +0200 > >> From: ALESSANDRO NICOLI > >> To: RIoT Dev List > >> Subject: [riot-devel] Soil Moisture Sensor > >> Message-ID: > >> >> ftkog6iw...@mail.gmail.com> > >> Content-Type: text/plain; charset="utf-8" > >> > >> Hi all, > >> I'm trying to use a Soil moisture sensor with a Samr21-xpro and RIOT os. > >> The sensor used is as follows : > >> > >> https://www.seeedstudio.com/Grove-Moisture-Sensor-p-955.html > >> > >> > >> I have *4 soil jars (with different moisture concentrations)* that i'm > >> gonna use for testing, i've already tried to get moisture values with > >> *Arduino > >> Uno* and they seem to be acceptable. > >> *For both, i used the built in ADC with 10 bits of resolution.* > >> > >> But when i try to use the samr21, it gets me always 330 as value (10 > bits > >> ADC). > >> For the SAMR21* i used the default parameters for ADC_0*. > >> > >> There is a way to rectify the readings, or some kind of calibration to > do? > >> > >> > >> Thanks a lot, > >> *best regards, * > >> *Alessandro* > >> -- next part -- > >> An HTML attachment was scrubbed... > >> URL: <http://lists.riot-os.org/pipermail/devel/attachments/ > >> 20161011/89c17d33/attachment-0001.html> > >> > >> -- > >> > >> Message: 2 > >> Date: Tue, 11 Oct 2016 16:46:21 +0200 > >> From: Peter Kietzmann > >> To: RIOT OS kernel developers > >> Subject: Re: [riot-devel] Soil Moisture Sensor > >> Message-ID: > >> Content-Type: text/plain; charset="utf-8" &
Re: [riot-devel] Soil Moisture Sensor
Start with measuring the voltage value? Try giving some different analog input less than 3.3V On Tuesday, 11 October 2016, ALESSANDRO NICOLI < alessandro.nic...@studenti.unipr.it> wrote: > Hi all, > I'm trying to use a Soil moisture sensor with a Samr21-xpro and RIOT os. > The sensor used is as follows : > > https://www.seeedstudio.com/Grove-Moisture-Sensor-p-955.html > > > I have *4 soil jars (with different moisture concentrations)* that i'm > gonna use for testing, i've already tried to get moisture values with > *Arduino > Uno* and they seem to be acceptable. > *For both, i used the built in ADC with 10 bits of resolution.* > > But when i try to use the samr21, it gets me always 330 as value (10 bits > ADC). > For the SAMR21* i used the default parameters for ADC_0*. > > There is a way to rectify the readings, or some kind of calibration to do? > > > Thanks a lot, > *best regards, * > *Alessandro* > -- *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
Re: [riot-devel] NFC & Atmel AT86RF232B
My colleague Nidhya should be posting on this. Expect EoD India time. Akshay On Thursday, 19 March 2015, Baptiste Clenet wrote: > Hello, > > I'm also interesting in AT86RF212B driver. > Ashkay has already done some improvements with this driver. > Does anybody have a WIP branch to try this driver? > > Cheers, > > 2015-03-18 22:14 GMT+01:00 Joakim Gebart >: > >> Hello, >> >> On Wed, Mar 18, 2015 at 10:08 PM, Craig Younkins > > wrote: >> > I think the at86rf231 driver works with the 212B or will otherwise >> require >> > minimal changes. I have not tested it but anticipate using it. In the >> linux >> > kernel they are both supported in the same file. >> >> Yes, the AT86RF212B works with the at86rf231 driver. The driver is >> undergoing some work right now, see >> https://github.com/RIOT-OS/RIOT/pull/2562 and >> http://lists.riot-os.org/pipermail/devel/2015-March/002247.html >> >> I have seen a memory corruption bug with the driver but not had the >> time to pinpoint it exactly, it seems to happen randomly, but in the >> vicinity of the radio RX code. I will open a PR when I find a solution >> unless someone else beats me to it. >> >> Best regards, >> Joakim >> www.eistec.se >> >> > >> > Craig Younkins >> > >> > On Wed, Mar 18, 2015 at 5:04 PM, Joël Chotard > > >> > wrote: >> >> >> >> Hi all, >> >> >> >> Does somebody is working on a RIOT NFC device driver ? and the ATMEL >> sub-G >> >> AT86RF212B driver ? >> >> >> >> Joël >> >> ___ >> >> devel mailing list >> >> devel@riot-os.org >> >> http://lists.riot-os.org/mailman/listinfo/devel >> > >> > >> > >> > ___ >> > devel mailing list >> > devel@riot-os.org >> > http://lists.riot-os.org/mailman/listinfo/devel >> > >> ___ >> devel mailing list >> devel@riot-os.org >> http://lists.riot-os.org/mailman/listinfo/devel >> > > > > -- > > *Clenet BaptisteFR: +33 6 29 73 05 39 <%2B33%206%2029%2073%2005%2039>* > > ___ devel mailing list devel@riot-os.org http://lists.riot-os.org/mailman/listinfo/devel
Re: [riot-devel] 802.15.4 for Linux
Hello Oleg,
We are able to use a Raspberry Pi and sniff 802.15.4 packets. We have a
hardware based on the AT86RF212B which has a 802.15.4 MAC within it. It
works for the India band at 865-867MHz transmitting 27dBm but supports the
EU band (868 MHz). We should be able to communicate as well and can share
some details on the status on the same.
The AT86RF212B driver will also be released once fully tested on the RIOT
(it is similar to the AT86RF2xx) as also for the Linux kernel.
Please let me know (offline please) if there is interest within the user
group here to allow us to schedule a lot for sale for the AT86RF212B
module.
Thanks,
Akshay
On 30 January 2015 at 15:32, Oleg Hahm wrote:
> Dear reasoning IoTlers,
>
> I know, we had this question already several times before , but I'm not
> sure
> about the current state and if some of you have made new experiences in
> this
> domain: is there any off-the-shelf hardware available that provides an IEEE
> 802.15.4 interface for Linux systems - preferable something like a USB
> stick?
> If yes, does this hardware work with a standard Linux vanilla kernel and
> which
> version is required? Or does it need any custom/developer version of a
> driver?
> How well are upper layers like 6lowpan supported by Linux in the meantime?
> And
> has anyone ever tried to connect such a device to a RIOT driven device?
>
> Thanks,
> Oleg
> --
> printk("autofs: Out of inode numbers -- what the heck did you do??\n");
> linux-2.0.38/fs/autofs/root.c
>
> ___
> devel mailing list
> devel@riot-os.org
> http://lists.riot-os.org/mailman/listinfo/devel
>
>
___
devel mailing list
devel@riot-os.org
http://lists.riot-os.org/mailman/listinfo/devel
Re: [riot-devel] 802.15.4 for Linux
Hello Oleg,
We are able to use a Raspberry Pi and sniff 802.15.4 packets. We have a
hardware based on the AT86RF212B which has a 802.15.4 MAC within it. It
works for the India band at 865-867MHz transmitting 27dBm but supports the
EU band (868 MHz). We should be able to communicate as well and can share
some details on the status on the same.
The AT86RF212B driver will also be released once fully tested on the RIOT
(it is similar to the AT86RF2xx) as also for the Linux kernel.
Please let me know (offline please) if there is interest within the user
group here to allow us to schedule a lot for sale for the AT86RF212B
module.
Thanks,
Akshay
On 30 January 2015 at 15:32, Oleg Hahm wrote:
> Dear reasoning IoTlers,
>
> I know, we had this question already several times before , but I'm not
> sure
> about the current state and if some of you have made new experiences in
> this
> domain: is there any off-the-shelf hardware available that provides an IEEE
> 802.15.4 interface for Linux systems - preferable something like a USB
> stick?
> If yes, does this hardware work with a standard Linux vanilla kernel and
> which
> version is required? Or does it need any custom/developer version of a
> driver?
> How well are upper layers like 6lowpan supported by Linux in the meantime?
> And
> has anyone ever tried to connect such a device to a RIOT driven device?
>
> Thanks,
> Oleg
> --
> printk("autofs: Out of inode numbers -- what the heck did you do??\n");
> linux-2.0.38/fs/autofs/root.c
>
> ___
> devel mailing list
> devel@riot-os.org
> http://lists.riot-os.org/mailman/listinfo/devel
>
>
___
devel mailing list
devel@riot-os.org
http://lists.riot-os.org/mailman/listinfo/devel
Re: [riot-devel] SAMR21 ram overflow issue w/ rpl_udp example
You could play with larger numbers with reduced stack size. Reduce the kernel stack size. Akshay On Friday, 16 January 2015, Steve Miao wrote: > Thanks Cenk, It worked. I tried 64 and 32 before I posted the message. I > should have tried smaller numbers. > > Regards, > Steve > > On Fri, Jan 16, 2015 at 12:48 PM, Cenk Gündogan < > cenk.guendo...@fu-berlin.de > > wrote: > >> Hi Steve! >> >> The default routing table size is at 128 entries, that's too much for the >> samr21-xrpo :) >> >> Can you try the following: >> BOARD=samr21-xpro make clean all RPL_MAX_ROUTING_ENTRIES=6 >> and see how this works out for you? >> You can even play a little bit around with the entry size, maybe you will >> find better values for your use case. >> >> Cheers, >> Cenk >> >> >> On 16.01.2015 18:44, Steve Miao wrote: >> >> Hi RIOTers, >> I am trying to compile the latest rpl_udp example for my SAMR21 Xpro. >> The compile was fine but I had an error message from the link. It bailed >> out with a ram overflow error. >> >> ~/RIOT/examples/rpl_udp$ make BOARD=samr21-xpro >> ... >> /home/user/gcc-arm-none-eabi-4_9-2014q4/bin/../lib/gcc/arm-none-eabi/4.9.3/../../../../arm-none-eabi/bin/ld: >> /home/user/RIOT/examples/rpl_udp/bin/samr21-xpro/rpl_udp.elf section `.bss' >> will not fit in region `ram' >> /home/user/gcc-arm-none-eabi-4_9-2014q4/bin/../lib/gcc/arm-none-eabi/4.9.3/../../../../arm-none-eabi/bin/ld: >> region `ram' overflowed by 3544 bytes >> collect2: error: ld returned 1 exit status >> make: *** [all] Error 1 >> >> The toolchain version is "gcc version 4.9.3 20141119 (release) >> [ARM/embedded-4_9-branch revision 218278] (GNU Tools for ARM Embedded >> Processors)". The RIOT source code was pulled off github as of today. >> Any suggestion? Thanks. >> >> Regards, >> Steve M. >> >> >> ___ >> devel mailing listde...@riot-os.org >> http://lists.riot-os.org/mailman/listinfo/devel >> >> >> >> ___ >> devel mailing list >> devel@riot-os.org >> http://lists.riot-os.org/mailman/listinfo/devel >> >> > ___ devel mailing list devel@riot-os.org http://lists.riot-os.org/mailman/listinfo/devel
Re: [riot-devel] Flashing the Samr21 xpro
We get about 2KiB/s on the SAMD21 which is the same MCU. -Akshay On 12 January 2015 at 15:30, Thomas Eichinger wrote: > Hi Lucas, > > I was playing with the openocd configuration a bit, mainly > `adapter_speed`, back when support for this was added without > any significant outcome. > Problem is, the EDBG chip, on the bottom of the board, handling > communication with the MCU is specified to run on 1MHz and the > openocd docs mention, for CMSIS-DAP, it is not advised to let > signal frequency exceed half of the operating frequency. > (I’d guess Nyquist-Shannon applies) > > That said, 0.481KiB/s still seems slow for this. I’m at least > reaching 1.787KiB/s for flashing and 11.190KiB/s for verification. > When did you check out the OpenOCD code? > > Best, Thomas > > > On 10 Jan 2015, at 14:25, Lucas Jenß wrote: > > > > Hey everyone, > > > > I’ve been playing around with the Samr21 xpro and flashing > > the device is _really_ slow, i.e. 0.481 KiB/s. Is this expected > > or is there a way to improve it? I’m using the current OpenOCD > > Git HEAD because the 0.8.0 release does not seem to contain the > > configs for the board yet. I tried to flash the hello-world > > example. > > > > Cheers, > > Lucas > > ___ > > devel mailing list > > devel@riot-os.org > > http://lists.riot-os.org/mailman/listinfo/devel > > ___ > devel mailing list > devel@riot-os.org > http://lists.riot-os.org/mailman/listinfo/devel > ___ devel mailing list devel@riot-os.org http://lists.riot-os.org/mailman/listinfo/devel
Re: [riot-devel] Flashing the Samr21 xpro
we've used this board but don't remember the speeds, can update monday. the speeds are quite reasonable AFAIK. -Akshay On 10 January 2015 at 21:08, Ludwig Ortmann wrote: > Hi, > > does anyone know if it's possible to flash this board faster in > principal? > > Cheers, Ludwig > > On Sat, Jan 10, 2015 at 02:25:50PM +0100, Lucas Jenß wrote: > > Hey everyone, > > > > I’ve been playing around with the Samr21 xpro and flashing > > the device is _really_ slow, i.e. 0.481 KiB/s. Is this expected > > or is there a way to improve it? I’m using the current OpenOCD > > Git HEAD because the 0.8.0 release does not seem to contain the > > configs for the board yet. I tried to flash the hello-world > > example. > > > > Cheers, > > Lucas > > ___ > > devel mailing list > > devel@riot-os.org > > http://lists.riot-os.org/mailman/listinfo/devel > ___ > devel mailing list > devel@riot-os.org > http://lists.riot-os.org/mailman/listinfo/devel > ___ devel mailing list devel@riot-os.org http://lists.riot-os.org/mailman/listinfo/devel
Re: [riot-devel] Network refactoring
On the same MCU -- how critical is it to stick to 1024 byte kernel stack. Can we play with it? Reducing this size fits the rpl udp in 32KB but as yet not sure how stable it will be. Akshay On Monday, 5 January 2015, Ludwig Ortmann wrote: > Hi, > > On Mon, Jan 05, 2015 at 06:00:34PM +0100, Oleg Hahm wrote: > > Maybe we can discuss a tentative schedule and set some milestones for the > > refactoring during a (PlaceCam) conf call this week? What do you think? > > How about making the milestone setting part of the bi-weekly virtual > meeting next week? I guess more interested parties (me among others) > can attend then ;) > > It would be great if there is some pre-discussed input for that topic > in that meeting though, so please: do have a preliminary talk. > > Cheers, Ludwig > ___ > devel mailing list > devel@riot-os.org > http://lists.riot-os.org/mailman/listinfo/devel > ___ devel mailing list devel@riot-os.org http://lists.riot-os.org/mailman/listinfo/devel
[riot-devel] Synchronization in RIOT
Dear RIOTers, Is there any synchronization among nodes that is being considered. I was thinking of setting up a basic PTP in RIOT. Any opinion ? The SAMR21 supports slotted transmissions which could benefit ... -Akshay ___ devel mailing list devel@riot-os.org http://lists.riot-os.org/mailman/listinfo/devel
Re: [riot-devel] Problem with RPL-UDP example for SAMR21
Thanks Ludwig and Oleg. This was what I was looking for. I believe optimization will have to wait till the new release which should be fine for me. Thanks and Regards, Akshay On Sunday, 14 December 2014, Oleg Hahm wrote: > Hi Akshay! > > >I wanted to know if the 32KB of SRAM on the SAMR21 will be > > sufficient to run the RPL ? Is there some footprint statistic that one > can > > consider when planning a probable system architecture. > > It is definitely our goal to archive support for a full featured network > stack > with RPL, 6LoWPAN (w/ support for full IPv6 MTU), and UDP within 32kB RAM > on a > 32-bit platform (such as the SAMR21). > > Currently, however, there are some issues to consider: > 1.) We're completely re-implementing the whole network stack. The new > version > will be less memory hungry. In the current (aka legacy) network stack > every layer keeps its own buffer, while the new version will make use > of a > global, shared buffer. I think the work on the new network stack will > be > completed in early Q1 2015. > 2.) The current default for RPL is the storing mode (MOP 2) with a maximum > routing table size of 128 entries. Since dynamic memory allocation for > most IoT applications is a bad choice and each entry consists of two > full > IPv6 addresses, a static array is allocated for the routing table. > Hence, > alone the routing table will consume more than 4k of RAM, if you build > a > RPL application in the default configuration. The size of the routing > table can be configured at compile time by supplying > RPL_MAX_ROUTING_ENTRIES=X. The MOP can be set in > sys/net/include/rpl/rpl_config.h > > Hope that helps. > > Cheers, > Oleg > -- > /* The HME is the biggest piece of shit I have ever seen. */ > linux-2.6.6/drivers/scsi/esp.h > ___ devel mailing list devel@riot-os.org http://lists.riot-os.org/mailman/listinfo/devel
Re: [riot-devel] Problem with RPL-UDP example for SAMR21
Hello RIOTers,
I wanted to know if the 32KB of SRAM on the SAMR21 will be
sufficient to run the RPL ? Is there some footprint statistic that one can
consider when planning a probable system architecture.
-Akshay
On 12 December 2014 at 19:28, Akshay Mishra wrote:
>
> Thanks Ludwig,
> We are using the SAMR21 and the bss is nearly 32k which is as good as the
> RAM size (for the rpl_udp) ! No wonder it crashes.
>
> -Akshay
>
>
> On 12 December 2014 at 19:25, Ludwig Ortmann
> wrote:
>>
>> Hi,
>>
>> sorry, I misread the "and RPL" to mean "without RPL" because I had
>> that question the other day.
>> To get sizes with RPL, just use the examples/rpl_udp instead of
>> sixlowapp from applications.
>>
>> BTW: You might also want to look at this while you're at it.
>> https://github.com/RIOT-OS/RIOT/pull/2155
>>
>> It should reduce the RAM need quite a bit.
>>
>> Cheers, Luwig
>>
>> On Fri, Dec 12, 2014 at 02:44:17PM +0100, Ludwig Ortmann wrote:
>> > Hi Akshay,
>> >
>> > that depends on the board.
>> >
>> > Please checkout this application
>> > https://github.com/RIOT-OS/applications/tree/master/sixlowapp
>> > and compile (make clean all) it for your board.
>> >
>> > Note: This only works if there is a transceiver configured. For the
>> > samr21-xpro that means you have to merge the branch of the pull
>> > request which adds transceiver support first.
>> >
>> > Afterwards, add the values printed for bss and data to get the static
>> > RAM usage.
>> > Similarly, add bss and text to calculate ROM usage.
>> >
>> > Cheers, Ludwig
>> >
>> > On Fri, Dec 12, 2014 at 06:59:58PM +0530, Akshay Mishra wrote:
>> > > Hello Oleg,
>> > > What is the RAM size required for running a RIOT with full
>> > > 6LoWPAN and RPL ?
>> > >
>> > > -Akshay
>> > >
>> > > On 9 December 2014 at 20:20, Oleg Hahm wrote:
>> > > >
>> > > > Hi Maxence!
>> > > >
>> > > > > Did you find something about my problem ?
>> > > >
>> > > > Sorry for the lack of responsiveness. I had some weird problems
>> with the
>> > > > board
>> > > > last Friday (couldn't get any output using the rpl_udp example,
>> while other
>> > > > examples work fine). Will investigate further and let you know as
>> soon as I
>> > > > figure something out.
>> > > >
>> > > > Cheers,
>> > > > Oleg
>> > > > --
>> > > > panic("Fod fight!");
>> > > > linux-2.2.16/drivers/scsi/aha1542.c
>> > > >
>> > > > ___
>> > > > devel mailing list
>> > > > devel@riot-os.org
>> > > > http://lists.riot-os.org/mailman/listinfo/devel
>> > > >
>> > > >
>> >
>> > > ___
>> > > devel mailing list
>> > > devel@riot-os.org
>> > > http://lists.riot-os.org/mailman/listinfo/devel
>> >
>> > ___
>> > devel mailing list
>> > devel@riot-os.org
>> > http://lists.riot-os.org/mailman/listinfo/devel
>> ___
>> devel mailing list
>> devel@riot-os.org
>> http://lists.riot-os.org/mailman/listinfo/devel
>>
>
___
devel mailing list
devel@riot-os.org
http://lists.riot-os.org/mailman/listinfo/devel
Re: [riot-devel] Problem with RPL-UDP example for SAMR21
Thanks Ludwig,
We are using the SAMR21 and the bss is nearly 32k which is as good as the
RAM size (for the rpl_udp) ! No wonder it crashes.
-Akshay
On 12 December 2014 at 19:25, Ludwig Ortmann
wrote:
>
> Hi,
>
> sorry, I misread the "and RPL" to mean "without RPL" because I had
> that question the other day.
> To get sizes with RPL, just use the examples/rpl_udp instead of
> sixlowapp from applications.
>
> BTW: You might also want to look at this while you're at it.
> https://github.com/RIOT-OS/RIOT/pull/2155
>
> It should reduce the RAM need quite a bit.
>
> Cheers, Luwig
>
> On Fri, Dec 12, 2014 at 02:44:17PM +0100, Ludwig Ortmann wrote:
> > Hi Akshay,
> >
> > that depends on the board.
> >
> > Please checkout this application
> > https://github.com/RIOT-OS/applications/tree/master/sixlowapp
> > and compile (make clean all) it for your board.
> >
> > Note: This only works if there is a transceiver configured. For the
> > samr21-xpro that means you have to merge the branch of the pull
> > request which adds transceiver support first.
> >
> > Afterwards, add the values printed for bss and data to get the static
> > RAM usage.
> > Similarly, add bss and text to calculate ROM usage.
> >
> > Cheers, Ludwig
> >
> > On Fri, Dec 12, 2014 at 06:59:58PM +0530, Akshay Mishra wrote:
> > > Hello Oleg,
> > > What is the RAM size required for running a RIOT with full
> > > 6LoWPAN and RPL ?
> > >
> > > -Akshay
> > >
> > > On 9 December 2014 at 20:20, Oleg Hahm wrote:
> > > >
> > > > Hi Maxence!
> > > >
> > > > > Did you find something about my problem ?
> > > >
> > > > Sorry for the lack of responsiveness. I had some weird problems with
> the
> > > > board
> > > > last Friday (couldn't get any output using the rpl_udp example,
> while other
> > > > examples work fine). Will investigate further and let you know as
> soon as I
> > > > figure something out.
> > > >
> > > > Cheers,
> > > > Oleg
> > > > --
> > > > panic("Fod fight!");
> > > > linux-2.2.16/drivers/scsi/aha1542.c
> > > >
> > > > ___
> > > > devel mailing list
> > > > devel@riot-os.org
> > > > http://lists.riot-os.org/mailman/listinfo/devel
> > > >
> > > >
> >
> > > ___
> > > devel mailing list
> > > devel@riot-os.org
> > > http://lists.riot-os.org/mailman/listinfo/devel
> >
> > ___
> > devel mailing list
> > devel@riot-os.org
> > http://lists.riot-os.org/mailman/listinfo/devel
> ___
> devel mailing list
> devel@riot-os.org
> http://lists.riot-os.org/mailman/listinfo/devel
>
___
devel mailing list
devel@riot-os.org
http://lists.riot-os.org/mailman/listinfo/devel
Re: [riot-devel] Problem with RPL-UDP example for SAMR21
Hello Oleg,
What is the RAM size required for running a RIOT with full
6LoWPAN and RPL ?
-Akshay
On 9 December 2014 at 20:20, Oleg Hahm wrote:
>
> Hi Maxence!
>
> > Did you find something about my problem ?
>
> Sorry for the lack of responsiveness. I had some weird problems with the
> board
> last Friday (couldn't get any output using the rpl_udp example, while other
> examples work fine). Will investigate further and let you know as soon as I
> figure something out.
>
> Cheers,
> Oleg
> --
> panic("Fod fight!");
> linux-2.2.16/drivers/scsi/aha1542.c
>
> ___
> devel mailing list
> devel@riot-os.org
> http://lists.riot-os.org/mailman/listinfo/devel
>
>
___
devel mailing list
devel@riot-os.org
http://lists.riot-os.org/mailman/listinfo/devel
Re: [riot-devel] Switch to BSD?
This (migrating to a BSD license) should be an "awesome" step, especially for small design companies like us. Thanks, Akshay On 4 December 2014 at 03:29, Emmanuel Baccelli wrote: > Dear RIOTers, > > we have been receiving an increasing amount of negative feedback from > various companies concerning the practical usability of our LGPL license in > their context, being a show-stopper. > > For this reason, INRIA, Freie Universitaet (FU) Berlin and Hamburg > University of Applied Science (HAW) are currently considering changing the > license of their contributions to RIOT to a less restrictive license (i.e. > BSD, potentially as soon as next release). > > Such a switch to BSD is betting that the effect of a potentially smaller > percentage of user/devel contributing back to the master branch will be > dwarfed by the effect of a user/devel community growing much bigger and > quicker. This seems doable considering the current momentum around RIOT. > > In a second phase, if such a license switch takes place for INRIA/FU/HAW > contributions, we would then contact other contributors individually, to > check their status concerning a similar switch for their own contributions. > > But in the first place, we would like to debate this topic. In particular: > is anyone violently opposing the idea of migrating to a less restrictive > license, such as BSD? If so, why? On the other hand, if you explicitly > support the license change, feel free to indicate this as well. Please send > your opinion to the list before Dec. 10th. > > Cheers, > > Emmanuel > > ___ > devel mailing list > devel@riot-os.org > http://lists.riot-os.org/mailman/listinfo/devel > > ___ devel mailing list devel@riot-os.org http://lists.riot-os.org/mailman/listinfo/devel
Re: [riot-devel] Features for the next release
Hello RIOTers, Is there any known status on the Linux Border router. We are looking for a Linux Border implementation that'd talk to our RIOT nodes and we can (aspire to) take up this project if we get to know the state it is in and move us from our current state. Unless ofcourse there is a better solution to get the packets to the Internet. -Akshay On 2 December 2014 at 22:27, Oleg Hahm wrote: > Dear rioting IoTlers, > > I scanned through all open issues for the next release [1] and updated the > list in the wiki [2]. Since the originally planned feature freeze was > *yesterday*, we should decide quickly which of the listed features and > bugfixes we really see as *required* and *realistic* for this release. > > Please re-evaluate carefully all issues that might somehow effect your work > and check if it's feasible to complete the work on it within the next > *seven* > days. > > Please check also if you find something missing in the list in the wiki > that > should definitely make it into the release. > > Cheers, > Oleg > > [1] https://github.com/RIOT-OS/RIOT/milestones/Release%202014.12 > [2] https://github.com/RIOT-OS/RIOT/wiki/Release:-2014.12 > -- > The good thing about object oriented jokes is they bring their own laughter > method. > > ___ > devel mailing list > devel@riot-os.org > http://lists.riot-os.org/mailman/listinfo/devel > > ___ devel mailing list devel@riot-os.org http://lists.riot-os.org/mailman/listinfo/devel
Re: [riot-devel] SAMR21: SPI, at86rf233, I2C
Hello Baptiste, On 13 November 2014 21:52, Baptiste Clenet wrote: > Hi, > > I have seen the pull request from Troels51 concerning the SAMR21. > Is that normal that it uses the transceiver at86rf231 instead of the > at86rf233? The SAMR21 Explained pro board uses the *at86rf233 *transceiver > so something should be changed. > > By the way, Rane implemented the SPI here: > https://github.com/wiredsource/RIOT/blob/master/cpu/samd21/periph/spi.c > Did you implement yours from his source code? > > Finally, I'm almost done with I2C, I just need to check each function > (i2c_read_regs works). > > Can you please share the PR if the driver is done or in some shape to be shared ... thanks, Akshay > Best, > > *Baptiste* > > ___ > devel mailing list > devel@riot-os.org > http://lists.riot-os.org/mailman/listinfo/devel > > ___ devel mailing list devel@riot-os.org http://lists.riot-os.org/mailman/listinfo/devel
Re: [riot-devel] SAMR21: SPI, at86rf233, I2C
We wrote it ourselves. Will share. :-( On Thursday, 13 November 2014, Baptiste Clenet wrote: > Hi, > > I have seen the pull request from Troels51 concerning the SAMR21. > Is that normal that it uses the transceiver at86rf231 instead of the > at86rf233? The SAMR21 Explained pro board uses the *at86rf233 *transceiver > so something should be changed. > > By the way, Rane implemented the SPI here: > https://github.com/wiredsource/RIOT/blob/master/cpu/samd21/periph/spi.c > Did you implement yours from his source code? > > Finally, I'm almost done with I2C, I just need to check each function > (i2c_read_regs works). > > Best, > > *Baptiste* > ___ devel mailing list devel@riot-os.org http://lists.riot-os.org/mailman/listinfo/devel
Re: [riot-devel] RIOT OS for the Atmel SAM R21 (ARM m0+)
On 30 October 2014 18:52, Baptiste Clenet wrote: > Hello, > > I'm using SERCOM2 for I2C. So that fits with your configuration. > Concerning SPI, I thought Rane had already done the driver? > > Yes ! Rane, can you share the SPI patch for SAMR21 ? -Akshay > Best, > > 2014-10-30 13:55 GMT+01:00 Akshay Mishra : > >> How should we decide on which SERCOM to assign for SPI and which for I2C >> for the SAMD21 cpu. >> >> Currently SERCOM0 is assigned for UART but others are free and I'd take >> SERCOM1 for SPI for now and hence sending out this mail to stay consistent >> if there is any other approach to the driver. >> >> -Akshay >> >> On 27 October 2014 19:09, Baptiste Clenet wrote: >> >>> Hi Rane, >>> >>> I'm also very interesting about the adc, uart, spi and transceiver that >>> you have developped. >>> When will you add your contributions to the main RIOT repo? >>> >>> Best, >>> >>> Baptiste >>> >>> 2014-10-24 18:48 GMT+02:00 Akshay Mishra : >>> >>>> >>>> >>>> On 24 October 2014 18:31, Rane Balslev wrote: >>>> >>>>> Hi guys >>>>> >>>>> >>>>> We have been working on the port and now have a working adc, uart, spi >>>>> and transceiver. >>>>> >>>>> >>>> Rane, are your contributions in the main RIOT main branch? Do you have >>>> a public repository where this can be used ? >>>> >>>> I am migrating this to SAMD21 and your port would be useful >>>> >>>> -Akshay. >>>> >>>> >>>>> I would appreciate if you had some examples on the use of *sixlowpan *so >>>>> i could try testing something... >>>>> >>>>> If you do please contact me. >>>>> >>>>> best regards >>>>> Rane Balslev >>>>> Aarhus University >>>>> >>>>> ___ >>>>> devel mailing list >>>>> devel@riot-os.org >>>>> http://lists.riot-os.org/mailman/listinfo/devel >>>>> >>>>> >>>> >>>> ___ >>>> devel mailing list >>>> devel@riot-os.org >>>> http://lists.riot-os.org/mailman/listinfo/devel >>>> >>>> >>> >>> >>> ___ >>> devel mailing list >>> devel@riot-os.org >>> http://lists.riot-os.org/mailman/listinfo/devel >>> >>> >> >> ___ >> devel mailing list >> devel@riot-os.org >> http://lists.riot-os.org/mailman/listinfo/devel >> >> > > > -- > > *Clenet BaptisteFR: +33 6 29 73 05 39 <%2B33%206%2029%2073%2005%2039>* > *Élève-Ingénieur ESEO Angers, dernière année, spécialisation: Architecte > système temps réél embarqué* > > > *Bidiplôme Master Robotics à l'Université de Plymouth en 2013-2014* > > ___ > devel mailing list > devel@riot-os.org > http://lists.riot-os.org/mailman/listinfo/devel > > ___ devel mailing list devel@riot-os.org http://lists.riot-os.org/mailman/listinfo/devel
Re: [riot-devel] RIOT OS for the Atmel SAM R21 (ARM m0+)
How should we decide on which SERCOM to assign for SPI and which for I2C for the SAMD21 cpu. Currently SERCOM0 is assigned for UART but others are free and I'd take SERCOM1 for SPI for now and hence sending out this mail to stay consistent if there is any other approach to the driver. -Akshay On 27 October 2014 19:09, Baptiste Clenet wrote: > Hi Rane, > > I'm also very interesting about the adc, uart, spi and transceiver that > you have developped. > When will you add your contributions to the main RIOT repo? > > Best, > > Baptiste > > 2014-10-24 18:48 GMT+02:00 Akshay Mishra : > >> >> >> On 24 October 2014 18:31, Rane Balslev wrote: >> >>> Hi guys >>> >>> >>> We have been working on the port and now have a working adc, uart, spi >>> and transceiver. >>> >>> >> Rane, are your contributions in the main RIOT main branch? Do you have a >> public repository where this can be used ? >> >> I am migrating this to SAMD21 and your port would be useful >> >> -Akshay. >> >> >>> I would appreciate if you had some examples on the use of *sixlowpan *so >>> i could try testing something... >>> >>> If you do please contact me. >>> >>> best regards >>> Rane Balslev >>> Aarhus University >>> >>> ___ >>> devel mailing list >>> devel@riot-os.org >>> http://lists.riot-os.org/mailman/listinfo/devel >>> >>> >> >> ___ >> devel mailing list >> devel@riot-os.org >> http://lists.riot-os.org/mailman/listinfo/devel >> >> > > > ___ > devel mailing list > devel@riot-os.org > http://lists.riot-os.org/mailman/listinfo/devel > > ___ devel mailing list devel@riot-os.org http://lists.riot-os.org/mailman/listinfo/devel
Re: [riot-devel] Compile RIOT
On 28 October 2014 18:45, Maxence Chotard wrote: > Hi everyone, > > I would like to know if it is possible to compile and load RIOT project for > Atmel Sam R21 on Windows, using Atmel studio 6 ? > > This is a good question. I believe it should be possible because there is a gnu toolchain with the Atmel studio so it may be worth an attempt in my opinion. -Akshay > Cheers, > Maxence > > ___ > devel mailing list > devel@riot-os.org > http://lists.riot-os.org/mailman/listinfo/devel > ___ devel mailing list devel@riot-os.org http://lists.riot-os.org/mailman/listinfo/devel
Re: [riot-devel] RIOT OS for the Atmel SAM R21 (ARM m0+)
On 24 October 2014 18:31, Rane Balslev wrote: > Hi guys > > > We have been working on the port and now have a working adc, uart, spi and > transceiver. > > Rane, are your contributions in the main RIOT main branch? Do you have a public repository where this can be used ? I am migrating this to SAMD21 and your port would be useful -Akshay. > I would appreciate if you had some examples on the use of *sixlowpan *so > i could try testing something... > > If you do please contact me. > > best regards > Rane Balslev > Aarhus University > > ___ > devel mailing list > devel@riot-os.org > http://lists.riot-os.org/mailman/listinfo/devel > > ___ devel mailing list devel@riot-os.org http://lists.riot-os.org/mailman/listinfo/devel
Re: [riot-devel] Port of RIOT on Samr21
On 22 October 2014 18:38, Baptiste Clenet wrote: > Hi, > > Thank you for your answer Thomas, Akshay. > Akshay, which part are you working on then? > > I am creating support for the SAMD21-XPRO. I will start working on the SPI which can be used by the SAMR21 as well. -Akshay > Thomas, I'm looking at the uart.c that you wrote. Why did you only develop > one UART? > After reading the datasheet, I see that the samd21 has got 5 SERCOM which > can be used by USART, I2C, SPI and LIN slave. > With RIOT, we can set 4 USART and 4 I2C. How do we proceed with the 5 > SERCOM? > You chose PIN_PA04 and PIN_PA05 for UART 0. Which one should I use for > UART 1,2,3? > And Atmel chose to define I2C on PIN_PA16 and PIN_PA17, on which pin will > be the following I2C? > > Best, > > > > -- > > *Clenet Baptiste* > > > ___ > devel mailing list > devel@riot-os.org > http://lists.riot-os.org/mailman/listinfo/devel > > ___ devel mailing list devel@riot-os.org http://lists.riot-os.org/mailman/listinfo/devel
