Re: [riot-devel] Auto init in OpenThread
Hi, 2017-05-03 0:27 GMT+02:00 Jose Alamos : > […] > What's your opinion on how to deal with this? (e.g #ifdef > MODULE_OPENTHREAD in auto_init_ file?) > For now this would be the solution (that Shugou is going for as well), but as I said: let's come up with a better one soon-ish. ___ devel mailing list devel@riot-os.org https://lists.riot-os.org/mailman/listinfo/devel
Re: [riot-devel] Auto init in OpenThread
Hi Jose, that is exactly the same problem Shugou currently has with lwMAC [1] and I had when porting lwIP and emb6. When we originally wrote the auto-initialization we had cases like this (different stacks, different MAC protocols) in mind, but refrained from providing a solution since it simply wasn't needed at the time. So I guess the time to come together and come up with a solution is now, unless we want to let auto_init_ become our next sys/transceiver [2] ;-). Cheers, Martine [1] https://github.com/RIOT-OS/RIOT/pull/6554#discussion_r113234821 [2] https://github.com/RIOT-OS/RIOT/blob/044d3c704e62578a24e0676daeb2943ffa137a56/sys/transceiver/transceiver.c 2017-05-03 0:27 GMT+02:00 Jose Alamos : > Dear RIOTers, > > I'm currently finishing the OpenThread port (#5552). > The implementation is radio independent via netdev, but requires the > driver setup function to be called before passing the netdev pointer to the > OpenThread contrib (check what I'm doing atm in [1]). > > The auto_init_ functions like [2] do exactly that, but call > gnrc_netdev related functions instead of OpenThread related functions. > > What's your opinion on how to deal with this? (e.g #ifdef > MODULE_OPENTHREAD in auto_init_ file?) > > Jose > > > [1]:https://github.com/RIOT-OS/RIOT/pull/5552/files#diff- > 97be33bc304ff9c4bd5b5efe9e9fa8c1R122 > [2]: https://github.com/RIOT-OS/RIOT/blob/master/sys/auto_ > init/netif/auto_init_at86rf2xx.c#L61 > > ___ > 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] Auto init in OpenThread
Dear RIOTers, I'm currently finishing the OpenThread port (#5552). The implementation is radio independent via netdev, but requires the driver setup function to be called before passing the netdev pointer to the OpenThread contrib (check what I'm doing atm in [1]). The auto_init_ functions like [2] do exactly that, but call gnrc_netdev related functions instead of OpenThread related functions. What's your opinion on how to deal with this? (e.g #ifdef MODULE_OPENTHREAD in auto_init_ file?) Jose [1]: https://github.com/RIOT-OS/RIOT/pull/5552/files#diff-97be33bc304ff9c4bd5b5efe9e9fa8c1R122 [2]: https://github.com/RIOT-OS/RIOT/blob/master/sys/auto_init/netif/auto_init_at86rf2xx.c#L61 ___ devel mailing list devel@riot-os.org https://lists.riot-os.org/mailman/listinfo/devel
Re: [riot-devel] Regarding RIOT joining EdgeX Foundry
Hey Thomas! On Tue, May 02, 2017 at 01:24:12PM -0700, Thomas Eichinger wrote: > Thanks for your feedback. I think there is no such thing as an official > trial trial period so I understand correctly that this trial period would be > a RIOT internal thing? Yupp, that's what I meant. Sorry for my sloppy wording. Cheers, Oleg -- The good thing about object oriented jokes is they bring their own laughter method. signature.asc Description: PGP signature ___ devel mailing list devel@riot-os.org https://lists.riot-os.org/mailman/listinfo/devel
Re: [riot-devel] Regarding RIOT joining EdgeX Foundry
Hi Oleg, Thanks for your feedback. I think there is no such thing as an official trial trial period so I understand correctly that this trial period would be a RIOT internal thing? As far as I get it nobody objects the idea of RIOT as a project joining EdgeX in general. People who would be interested in participating in this endeavor please contact me off list to start organizing the upcoming administrational steps. Best, Thomas On 28 Apr 2017, at 23:41 PDT(-0700), Oleg Hahm wrote: Hi Aaron, hi Thomas! Thanks for sparking this discussion and sharing your thoughts about this topic! On Sat, Apr 29, 2017 at 11:03:03AM +1200, Aaron Sowry wrote: I think this is a good idea, forming a special interest group a.k.a task force gathering people having time to spare to invest in EdgeX, reporting back to the community as we used to do for technical topics. I think a task force would at least fulfill the desire to "keep an eye on the results" as you say, and would probably be a positive thing to have regardless of how much involvement RIOT decides to have in EdgeX. I very much like the idea of joining the EdgeX Foundry with some kind of trial period in mind having a group of people committed to monitor this period and the general alignment between RIOT's goals and the direction EdgeX is taking. Cheers, Oleg -- Unix is user friendly... its just selective about who its friends are. ___ 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 Research Seminar: a short report
Hi Ken, this is planned for the summer. We discussed with Thomas, and the rough plan was to propose this topic for the IETF hackathon [1] in Prague this summer, whereby some RIOTers and some OpenWSN people would attend and hammer it out. Until then, OpenWSN Fresh is getting ready AFAIK. [1] https://www.ietf.org/hackathon/99-hackathon.html On Sat, Apr 29, 2017 at 3:22 PM, Ken Bannister wrote: > Emmanuel, Thomas: > > Thanks for the links! I was very interested to see Thomas's slides on > OpenWSN "fresh" [1]. It would be valuable to have a 6TiSCH implementation > in RIOT. Are there any more details available on this project? > > Thanks, > Ken > > http://riot-os.org/files/RIOT-Seminar-2017/RIOT-Spring- > Seminar-Watteyne.pdf > > On 04/28/2017 06:26 AM, Emmanuel Baccelli wrote: > > Hi everyone, > > there was a seminar organized earlier this month in Paris. The goal of > that seminar was to gather various research teams working (or considering > to work) around RIOT at Inria. > > The agenda + slides are available at http://riot-os.org/seminar-2017.html > > Some synopsis/highlights below: > > - Securing IoT is important now. (see slides from C. Bormann) > - Formally verified open source IoT software is desirable and some is > already available today (see slides from K. Bhargavan) > - Public key crypto is the hardest part of IoT crypto, but significant > performance improvements are on the horizon (see slides from B. Smith) > - Industrial IoT deployments are already happening. (see slides from T. > Watteyne) > - Object security, and content-centric networking can be used for > security. (see slides from M. Enguehard) > - Need public experimental infrastructure & open data for IoT. (see slides > from E. Fleury) > - Large open source project need tools/languages to (i) flexibly express > how code should be and (ii) automate code transformation (see slides from > J. Lawall) > - OS adaptation and programming abstractions are needed for intermittently > powered IoT devices, and peripherals restoration is the hard part (see > slides from G. Salagnac) > - IoT software components and component dynamic updates are desirable. > (see slides from J. Bourcier) > > If you have comments or questions, just ask here and/or contact the > authors directly! > > Cheers > > Emmanuel > > > > ___ > 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] SPI automatic interface configuration inside of cpu.c/periph_init(();
Hi Neo, the global/automatic SPI initialization might not be ideal, but the benefits are greater than the drawbacks. One of the major design issues this is solving is the handling of shared peripherals (as in SPI/I2C): when doing the initialization somewhere in the driver code, different driver will re-initialize the same peripheral, potentially with contradicting settings... For your specific problem: if you only use one specific SPI and use pins configured to another SPI dev for other purposes, then the other SPI should not be configured, so you should use an application specific `periph_conf.h` file. This should fix your issues. Cheers, Hauke On 29.04.2017 14:56, Neo wrote: Dear RIOT developers, I think it is not a good idea to initilialize the SPI interface automatically via the periph_init() function because it is not as static as mentioned. In my application I have 2 SPI interfaces defined in the periph_conf.h file - but I wanted only to configure the second one of these interfaces. I the older days everything went well, but when I pulled in the new sources I was wondering why now the spi_init() function was invoked 3 times2 times automatically by the periph_init() function (initializing all defined interfaces) and one time by my own (initializing only the second interface).and it took some time to find out what was going wrong. For my opinion interface initialization should be under control of the application which interface is set up. Best regards, Neo ___ devel mailing list devel@riot-os.org https://lists.riot-os.org/mailman/listinfo/devel ___ devel mailing list devel@riot-os.org https://lists.riot-os.org/mailman/listinfo/devel
