Re: [riot-devel] Driver for the at86rf215
Hi Robert, No Problem! Good that you asked before so there weren't duplicated attempts :P Cheers, José On Fri, 2019-10-25 at 08:22 +0200, Robert Hartung wrote: > Hi José, > hrmpf. Should've looked again into the list of PRs, was a while ago > ;) > Will contribute with reviewing and testing. > Regards > Robert > > On 24.10.19 16:26, José Alamos wrote: > > Hi Robert, > > > > Note there's already a PR for this radio [1]. > > It's using 2 `netdev_ieee802154` for handling each radio. > > > > Maybe you can sync there and contribute with feedback and testing. > > > > Best, > > José > > > > [1]: https://github.com/RIOT-OS/RIOT/pull/12128 > > On Thu, 2019-10-24 at 16:20 +0200, Robert Hartung wrote: > > > Hello fellow developers, > > > > > > I am targeting this question to developers here first before > > > opening > > > any > > > issues. We are looking to implement a driver for the at86rf215. > > > The > > > challenge here is, that we cannot fit it into the existing > > > at86rf2xx > > > driver for a simple reason: It has two interfaces for Sub-Ghz and > > > 2.4Ghz > > > communication, but shares a single interrupt pin. My idea was to > > > have > > > a > > > single device, which has multiple communication interfaces. From > > > what > > > I've seen and researched about netdev, this is not possible, as a > > > netdev > > > has a driver, which consists of the callbacks, including the isr > > > handler. > > > > > > The Idea would then be to have a meta device for the interrupt > > > handling > > > and then calling the actual isr for the radio that the interrupt > > > was > > > ment for. Any one having a similar problem or any ideas how to > > > solve > > > this issue? > > > > > > Best Regards > > > Robert > > > > > > > ___ > > devel mailing list > > devel@riot-os.org > > https://lists.riot-os.org/mailman/listinfo/devel > > ___ devel mailing list devel@riot-os.org https://lists.riot-os.org/mailman/listinfo/devel
Re: [riot-devel] Driver for the at86rf215
Hi Robert, Note there's already a PR for this radio [1]. It's using 2 `netdev_ieee802154` for handling each radio. Maybe you can sync there and contribute with feedback and testing. Best, José [1]: https://github.com/RIOT-OS/RIOT/pull/12128 On Thu, 2019-10-24 at 16:20 +0200, Robert Hartung wrote: > Hello fellow developers, > > I am targeting this question to developers here first before opening > any > issues. We are looking to implement a driver for the at86rf215. The > challenge here is, that we cannot fit it into the existing at86rf2xx > driver for a simple reason: It has two interfaces for Sub-Ghz and > 2.4Ghz > communication, but shares a single interrupt pin. My idea was to have > a > single device, which has multiple communication interfaces. From what > I've seen and researched about netdev, this is not possible, as a > netdev > has a driver, which consists of the callbacks, including the isr > handler. > > The Idea would then be to have a meta device for the interrupt > handling > and then calling the actual isr for the radio that the interrupt was > ment for. Any one having a similar problem or any ideas how to solve > this issue? > > Best Regards > Robert > ___ devel mailing list devel@riot-os.org https://lists.riot-os.org/mailman/listinfo/devel
Re: [riot-devel] Release 2019.07 - dates and feature requests
Hi, I would like to manage to get GNRC LoRaWAN [1] merged into master. The PR is in good shape and only needs some testing/review. With this into master, I would like to move forward into a common API for all LoRaWAN implementations in RIOT (and of course, add more interesting features to the stack). Cheers, José [1]: https://github.com/RIOT-OS/RIOT/pull/11022 On Mon, 2019-06-03 at 09:56 +0200, Gaëtan Harter wrote: > Hi, > > I would personally like to manage to get the migration to FLASHFILE > finally finished https://github.com/RIOT-OS/RIOT/pull/8838 (I only > have > the tracking PR currently, so it's my fault if it did not move) and > the > fix for flashers on the board I use for testing the release > https://github.com/RIOT-OS/RIOT/pull/10870 as I currently use them > for > testing anyway. I could need help for that last one if you have > examples > that put any of the mentioned boards in a no more flashable state > with RIOT. > > Cheers, > Gaëtan > > > On 6/1/19 6:42 PM, Dylan Laduranty wrote: > > Hi all, > > #11077 and #11085 could be in the incoming release but it will > > require to > > have #11075 and #10916 merged first. > > Hopefully, #11075 should be pretty straightforward and #10916 > > (which > > introduces the stack) is in the final review state. > > Any help with the review and/or test process will be highly > > appreciated ! > > Cheers, > > > > Le sam. 1 juin 2019 à 01:40, Hauke Petersen < > > hauke.peter...@fu-berlin.de> a > > écrit : > > > > > Hej, > > > > > > big +1! Getting the USB+Ethernet slave mode to work would be a > > > major > > > milestone towards simple to deploy border routers and such. > > > > > > So ~4 more weeks seems doable, right?! > > > > > > Cheers, > > > Hauke > > > > > > > > > On 5/31/19 10:11 PM, Mario Gómez wrote: > > > > > > Hi all! > > > > > > My grain of salt: > > > > > > For high impact features: > > > > > > PR #11085 (Serial console over USB) & PR #11077 (USB CDC ECM > > > support) > > > > > > Those two combined with something like the SAM-BA bootloader > > > (Arduino SAMD > > > bootloader compatible with BOSSA) would allow us to make easy- > > > upgradeable > > > one-chip border-router USB dongles based on the ATSAMR21. USB CDC > > > ECM > > > essentially could remove the need for ethos. > > > > > > Regards, > > > Mario. > > > > > > On Fri, May 31, 2019 at 6:51 AM Kevin Weiss < > > > kevin.we...@haw-hamburg.de> > > > wrote: > > > > > > > Dear RIOTers, > > > > > > > > > > > > The release dates for the upcoming release cycle are fixed as > > > > follows: > > > > > > > > - 28.06.2019 - soft feature freeze, for high impact features > > > > > > > > - 08.07.2019 - hard feature freeze, for all features > > > > > > > > - 31.07.2019 - Release date > > > > > > > > Could you please send your suggestions for features which you > > > > would like > > > > to see merged during this release cycle. > > > > > > > > > > > > Best regards, and happy hacking! > > > > > > > > Kevin Weiss > > > > ___ > > > > devel mailing list > > > > devel@riot-os.org > > > > https://lists.riot-os.org/mailman/listinfo/devel > > > > > > > > > > ___ > > > devel mailing listde...@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] Wakaama_RIOT
Hello Brenton, There's an open PR with a basic LWM2M Wakaama client for RIOT here [1]. You can maybe give it a look. Does this solve your issue? Cheers, José [1]: https://github.com/RIOT-OS/RIOT/pull/11036 On Wed, 2019-04-10 at 15:11 +0200, Brenton Chetty wrote: > Hey guys, sorry to worry you'll. I just graduated, and I'm an intern. > I need to update a STM32 device over the air using a Leshan Server, > and a Wakaama Client (RIOT). I managed to send a .bin file from the > Server to the RIOT_Wakaama client using the Linux native interface. I > used the 2015 RIOT_Wakaama client example created by Robby14 > (Github), as i do not know how to use the Wakaama pkg in the RIOT > base. Any ideas on how i should proceed with this task? How do I use > the wakaama pkg? Any advice would be greatly appreciated! > > With thanks > Brenton > ___ > 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
