Re: [riot-devel] Proposal: Use Gitter to allow users and developers easier and simpler chat functionality
Hi, > I am a relatively new user to Riot OS. I understand that this type of > proposal from a new user may be frowned upon or unwarranted. So I understand > if this idea gets shot down and closed. However, I would like to see if there > is any interest in using Gitter rather than freednode and the mailing lists > (or maybe the mailing lists stay in parallel) for developers and users to > chat. > I have worked with other open source projects (ardupilot for one) that use > Gitter for real-time interactions between developers and with users. The > interface is clean and easy to use, integrates with GitHub nicely, and has > infinite message persistence. It sounds interesting, there are still some obscurities. What is the definition of this real-time, is it hard real time or very hard real-time? Because only the very hard real-time gives the most fixed connection between the user and developer. Also how infinite is this infinite persistence? > Does anyone else think this would be a big improvement in helping the > community grow? Sure, I fill it already, it is most funny mail what I have read here. Also this mailing list has a (not infinite) persistence. -- Johann ___ devel mailing list devel@riot-os.org https://lists.riot-os.org/mailman/listinfo/devel
Re: [riot-devel] Organizing device drivers
Hi, On Tue, 12 Jul 2016 10:49:07 +0200 Peter Kietzmann wrote: > Another solution would be to handle common and individual functions in > one file (without #ifdef). This might bloat code size but allows usage > of different versions in parallel. Also, it does not bloat the file > structure. The problem about naming schemes is still present here. I prefer clear only this solution, with the difference to handle common and individual functions in one directory. The derivative functions can be controlled using C if statements, which should be optimized by the compiler and the modern linker should remove the unused functions. I pour a little oil into the fire: some developer overdo it with the macros and the driver (also other) sources look like "a macro-monster has puked on the display". Regards, Johann Fischer ___ devel mailing list devel@riot-os.org https://lists.riot-os.org/mailman/listinfo/devel
Re: [riot-devel] Notification: Biweekly virtual meeting @ Wed Jun 15, 2016 2pm - 3pm (RIOT Events)
Am 15.06.2016 um 14:35 schrieb Martine Lenders: Hi, Should we rathe change to skype & co? Cheers, Martine +1 -- Johann Fischer ___ devel mailing list devel@riot-os.org https://lists.riot-os.org/mailman/listinfo/devel
Re: [riot-devel] Regarding RNDIS support
Hello Stefan, Am 06.06.2016 um 14:39 schrieb Stefan Schmidt: I am working on usb device support for RIOT. There is a PR[1] for it, but it is outdated and will be rebased/updated with [2]. [2] supports kinetis and sam[r,d]-21. The CDC-ACM and CDC-ECM support is very anstable and WIP. Currently I am working on the stability of CDC-ACM. I plan: - remove CDC-ECM first - add a netdev2-802154-over-usb interface and opposite driver for linux kernel Could you elaborate on this part? I'm not sure I understand what your plan is here. If your plan is to expose 15.4 level API over USB and write a matching Linux Kernel driver that fits into linux-wpan at least Alexander and myself would be interested in your plans. :) That's exactly what I planned. For the beginning we can take the netdev2 for it. If we (someday) have a proper MAC in RIOT, then it may be a better way to use it with linux hardmac interface and to build a 15.4 dongle based on RIOT. We currently have even the hardware for it [1] and a SAM-R21 Xplaned board can also be used as the dongle. Unfortunately, I have some ugly bugs in CDC-ACM code and the code needs clean up, when it is fixed i will update [2]. [1] http://www.phytec.de/produkt/internet-of-things/phystick-kw2x/ [2] https://github.com/RIOT-OS/RIOT/pull/3890 Cheers, -- Johann Fischer ___ devel mailing list devel@riot-os.org https://lists.riot-os.org/mailman/listinfo/devel
Re: [riot-devel] Regarding RNDIS support
Hi, Am 06.06.2016 um 11:55 schrieb shishir tiwari: Hello, As RIOT support Ethernet devices and USB device , Is someone working on rndis(Remote Network Driver Interface Specification) Protocol.?? I am working on usb device support for RIOT. There is a PR[1] for it, but it is outdated and will be rebased/updated with [2]. [2] supports kinetis and sam[r,d]-21. The CDC-ACM and CDC-ECM support is very anstable and WIP. Currently I am working on the stability of CDC-ACM. I plan: - remove CDC-ECM first - add a netdev2-802154-over-usb interface and opposite driver for linux kernel :-) About RNDIS: - why should RIOT supports a Microsoft proprietary protocol? - why not CDC-ECM or CDC-EEM ? Cheers, [1] https://github.com/RIOT-OS/RIOT/pull/3890 [2] https://github.com/jfischer-phytec-iot/RIOT/tree/test%40cdc-ecm -- Johann Fischer ___ devel mailing list devel@riot-os.org https://lists.riot-os.org/mailman/listinfo/devel
Re: [riot-devel] USB BLE HCI protocol
Hello Phanindra, Am 08.02.2016 um 11:03 schrieb PHANINDRA SURA: Hello, I would like to work on the above issue, related to Bluetooth low Energy,a topic of my interest. Please tell me the pre-requisites to be learnt for contributing to this task. You need the following hardware: - a Bluetooth compatible transceiver connected to a NXP Kinetis or Atmel SAM[R,D]21 MCU (for these both exist the usb device driver for RIOT). You need the following software support: - a Bluetooth compatible protocol stack (there is no one mainline) Where can I find relevant material to build my knowledge on these protocols. See [1...3], but based on the questions that you ask, I do not think it is an appropriate project for you, maybe one of [4]? [1] https://www.bluetooth.com/specifications [2] http://www.usb.org/developers/docs/ [3] http://lxr.free-electrons.com/source/drivers/bluetooth/btusb.c [4] https://github.com/RIOT-OS/RIOT/labels/Newbie-Task-Candidate -- Johann Fischer ___ devel mailing list devel@riot-os.org https://lists.riot-os.org/mailman/listinfo/devel
[riot-devel] usb device stack ...
Hello hardworking developers, if someone wants to test "USB Device Stack # 3890" on Phytec boards or want to use the Board (PhyNode, pba-d-01-kw2x) as a boarder router, I have completed the PR with instructions for the modifications [1]. [1] https://github.com/RIOT-OS/RIOT/pull/3890#issuecomment-154106351 -- Johann Fischer ___ devel mailing list devel@riot-os.org https://lists.riot-os.org/mailman/listinfo/devel
Re: [riot-devel] Using C++ in device drivers
Hi, What are your opinions on writing device drivers or system modules in C++? Please under no circumstances. Is there something worse, how about APL or Pascal? :-) I know some of the more constrained platforms might not yet have C++ support, but still it might be an interesting option for some device drivers. C++ objects for example can be used as an alternative to the device descriptor pattern we are using in many drivers. What's wrong with the "device descriptor"? Is the CPP Object something else? The scope in which CPP would be used for RIOT, is just an extension of C with poor readability and design. I don't have any particular driver in mind, I just want to hear any opinions around the community. It is noteworthy that this discussion occurs repeatedly in open source projects. It's pretty much my opinion about CPP (except for verbal abuse): http://harmful.cat-v.org/software/c++/linus And that is also interesting: http://harmful.cat-v.org/software/c++/coders-at-work -- Johann Fischer ___ devel mailing list devel@riot-os.org https://lists.riot-os.org/mailman/listinfo/devel
Re: [riot-devel] Notification: Hack'n'ACK @ Tue Jun 30, 2015 5pm - 10pm (RIOT Events)
Hi Oleg, Am 30.06.2015 um 12:06 schrieb Oleg Hahm: Dear readying IOTlers, is anyone planning to join tonight's H&A session remotely? Yes. Cheers, Oleg Am Mon, Jun 29, 2015 at 03:00:05PM + schrieb Google Calendar: This is a notification for: Title: Hack'n'ACK When: Tue Jun 30, 2015 5pm - 10pm Berlin Where: c-base Berlin; HAW Hamburg Calendar: RIOT Events Who: * Martine Lenders - creator Event details: https://www.google.com/calendar/event?action=VIEW&eid=bGJrNG1mdWNxZG9tY2Y3YzhvOWNnNGNtc2dfMjAxNTA2MzBUMTUwMDAwWiBrM3FsOHNldHY3bDQ4b2Zub2wwdGZ1dTZ0c0Bn 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 -- Johann Fischer ___ devel mailing list devel@riot-os.org https://lists.riot-os.org/mailman/listinfo/devel
Re: [riot-devel] C++ Style Guide
Hi Raphael, Am 25.06.2015 um 11:09 schrieb Hiesgen, Raphael: Hi, it is time to write a C++ Coding Style Guide for RIOT. Since C and C++ have different traditions here, I will simply start to suggest using the C++ Style used in CAF [1]. While it is not identical, the style is relates to the guidelines used by Google and C++ Standard Library. How I see it is very similar to RIOT coding style. 2 spaces per indentation level is not acceptable to me, should be 4 as in C coding style. Otherwise, I find it very good. By the way, can someone explain to me short why we need C ++ at all? Regards -- Johann Fischer ___ devel mailing list devel@riot-os.org https://lists.riot-os.org/mailman/listinfo/devel
Re: [riot-devel] Board Selection for RIOT
Hello Alexander, Phytec are happy to support master's students. If your work is related to RIOT or IEEE802.15.4 stack on Linux, we can support you with our phyNODE's [1] or the IoT Kit [2]. Please describe briefly your work and send it to me. [1] https://github.com/RIOT-OS/RIOT/wiki/Board%3A-Phytec-phyWAVE-KW22 [2] http://www.phytec.de/de/produkte/internet-of-things/evaluierungskit/produktdetails/p/iot-enablement-kit.html Best regards Johann Fischer Am 29.05.2015 um 05:19 schrieb Alexander Talavari: Hello, As part of my MScThesis i will be devoloping on RIOT and i was interest on your suggestion on what board i should buy. I am already testing it on my Linux Mint image but it would be nice to have the board that plays the best with RIOT. Best regards, Alexander Talavari PS I am copy pasting the description of my Thesis as proposed by my professor fyi RIOT [1] is an open source operating system designed for small and resource constrained devices. Such devices are expected to be the norm in the Internet of Things (IoT). RIOT provides support for standardized IoT protocols (e.g., 6LoWPAN and CoAP), as well as, as for experimental architectures (e.g., CCN-lite, a lightweight version of the CCN Information-Centric Networking [4] architecture [2]). FIT-IoT lab [3] is a distributed testbed that enables IoT experimentation at a large scale. FIT-IoT provides a variety of devices that can be used for experiments, including devices equipped with the RIOT OS. The purpose of this thesis is to implement a simple application for exchanging content (e.g., sensor measurements) in RIOT. The application will be developed in two versions one using CoAP and another using CCN-lite. Both versions will be evaluated and compared in the FIT-IoT lab. References [1] http://www.riot-os.org/ [2] CCN-lite, a lightweight implementation of the Content Centric Networking protocol CCNx of XEROX PARC, 2014 (http://ccn-lite.net). [3] https://www.iot-lab.info/ [4] G. Xylomenos, C.N. Ververidis, V.A. Siris, N. Fotiou, C. Tsilopoulos, X. Vasilakos, K.V. Katsaros, G.C. Polyzos, “A Survey of Information-Centric Networking Research,” IEEE Communications Surveys and Tutorials, vol. 16, no. 2, pp. 1024-1049, 2014 (http://www.mm.aueb.gr/publications/2013-icn-survey.pdf). ___ 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] kinetis common - differences between families
Am Sat, 14 Mar 2015 13:59:06 +0100 schrieb Jozef Maslik : Hi Jozef, > Some example with major differences: > SPI has min 3 variants: DSPI (K family), SPI (L, M family), SPI(L0x > family) UART has min 3 variants: 1. K, M family, 2. L family, 3. L0x > family low power UART is in L families (except L0x) We currently have the conflict in spi. The driver for the SPI at KL0x (or KW01) can simply mean spi_kl.c, etc... > Some functionality (as @Joakim wrote) can be handled by conditional > compilation like KINETIS_UART_ADVANCED, but I think, some extended > functionality can be omitted because it is not interesting for our > use case. We have done so for uart. > But I think, best way is to say, which families are interesting for > RIOT OS and compare only these. Maybe wiki page can be helpful for > this task. Coordination: "RIOT port for Freescale Kinetis CPUs": https://github.com/RIOT-OS/RIOT/issues/2188 > At this moment, I’m working with Cortex M0+ families (which are not > supported on RIOT yet) - I have port on KL02 and in future I want to > do port for KW01 (if someone else do not do it). "RIOT port for the KW01Z128 SiP", outdated, I'll update it in the next days: https://github.com/RIOT-OS/RIOT/pull/2328 > From my point of view, best option is to have one common > kinetis_family directory with all driver regardless of the family. > > Jozef > -- Johann Fischer ___ devel mailing list devel@riot-os.org http://lists.riot-os.org/mailman/listinfo/devel
Re: [riot-devel] About function pointers
Am Fri, 20 Feb 2015 08:01:58 +0100 schrieb Oleg Hahm : > Was this a vote for a function pointer based HAL or just a > Torvalds-like reflex? If the former is the case, then I'm apparently > the only one - counting the silent people on this topic as agreeing > or not caring - against this approach. In this case I would advice to > rethink and remodel the whole driver and HAL design. With the use of > function pointers it could be made extremely more (pseudo) > object-oriented what make many things much more convenient to > implement. Hi Oleg, I vote for "function pointer based HAL" and I think more of them will make RIOT much better :-). -- Johann Fischer ___ devel mailing list devel@riot-os.org http://lists.riot-os.org/mailman/listinfo/devel
Re: [riot-devel] Switch to BSD?
Hello Emmanuel and RIOTers, > In my opinion, what we need is statements from legal departments from > companies that are genuinely interested in RIOT technically. Is LGPLv2.1 a > show stopper for them, or not? What is the main reason why? This is the key > information the community should consider. > > Cheers, > > Emmanuel Statement of PHYTEC Messtechnik GmbH to LGPL and "Switch to BSD": We spend an equal amount of time on software development as on hardware development. Phytec contributes to the Linux Kernel. We know the (L)GPL license and work with it every day. Phytec is also founding member of OSADL (Open Source Automation Development Lab). We want to see RIOT as a "Linux" for small microcontrollers in IoT world. We find the LGPL pass very well with a project like RIOT and support the use of LGPL. As Linux-Kernel, RIOT is a part of an infrastructure and this should remain free and open. With the change to BSD we fear the RIOT will do more harm than good. LGPL binds community and the companies together and ensures that a project will not getting fragmented and falling apart. We do not support the change to BSD and we are sure that RIOT will be more attractive by other measures. Currently we rely on RIOT as first choice, with a change to BSD license we would think it over again. Best regards Mit freundlichen Grüßen M.Eng. Johann Fischer - Entwicklung - PHYTEC Messtechnik GmbH Robert-Koch-Str. 39 55129 Mainz Germany Tel.: +49 (0)6131 9221-0 Web: http://www.phytec.de PHYTEC Messtechnik GmbH, Robert-Koch-Str. 39, 55129 Mainz, Germany; Geschäftsführer: Dipl.-Ing. Michael Mitezki, Handelsregister Mainz, HRB 4656, Finanzamt Mainz-Mitte, St.Nr. 266500608, DE 149059855 This E-Mail may contain confidential or privileged information. If you are not the intended recipient (or have received this E-Mail in error) please notify the sender immediately and destroy this E-Mail. Any unauthorized copying, disclosure or distribution of the material in this E-Mail is strictly forbidden. ___ devel mailing list devel@riot-os.org http://lists.riot-os.org/mailman/listinfo/devel
Re: [riot-devel] Switch to BSD?
Am Tue, 16 Dec 2014 15:45:02 +0100 schrieb Emmanuel Baccelli : Hi Emmanuel, > > > I totally don't get this point. How do more possibilities to work > > > with RIOT for *others*, take fun away from *you*? > > > > > > > (L)GPL guarantees that my contribution will stay part of > > > > something that might improve, but is always available to me > > > > under clear tearms. > > > > > > I disagree. The RIOT community guarantees that your and everyone > > > else's contribution stay part of open and free software that might > > > improve. Additionally, it might become part of something else, > > > true. > > > > > I agree with Kaspar. Also as a company we have interests that if a > > competitor uses our work, it would be forced to admit changes or > > improvements back. > > > > > > OK. So is LGPLv2 indeed aligned with your company's policy and legal > department? > That would be interesting to know for this discussion. Yes, even if it is not always comfortable. > Best, > > Emmanuel -- M.Eng. Johann Fischer - Forschung & Entwicklung - PHYTEC Messtechnik GmbH Robert-Koch-Str. 39 55129 Mainz Germany Tel.: +49 (0)6131 9221-0 Web: http://www.phytec.de ___ devel mailing list devel@riot-os.org http://lists.riot-os.org/mailman/listinfo/devel
Re: [riot-devel] Switch to BSD?
Am Tue, 16 Dec 2014 12:44:57 +0100 schrieb Oleg Hahm : > Hey Kaspar! > > > If RIOT is BSD'ed, for *me* personally time spent on it is not fun > > time I like to in my unpaid spare time anymore, it becomes work > > that is also fun. Work others can (and will) sell under their terms. > > I totally don't get this point. How do more possibilities to work > with RIOT for *others*, take fun away from *you*? > > > (L)GPL guarantees that my contribution will stay part of something > > that might improve, but is always available to me under clear > > tearms. > > I disagree. The RIOT community guarantees that your and everyone > else's contribution stay part of open and free software that might > improve. Additionally, it might become part of something else, true. > I agree with Kaspar. Also as a company we have interests that if a competitor uses our work, it would be forced to admit changes or improvements back. Best regards Johann Fischer ___ devel mailing list devel@riot-os.org http://lists.riot-os.org/mailman/listinfo/devel
Re: [riot-devel] hwtimer implementation for Freescale MKW2xDxxx
Hello Hauke, Hello Gebart, > As far as I see it, we have a short- and a longterm solution: For now > I think the using the LPTMR seems reasonable, although it only offers > a single channels if I see it right. As for the offered resolution > this should be fine as long as there are no drivers and/or other > application code, that needs this resolution... Ok, then i will continue my work with LPTMR. > For the long-term we are planning/working on a new timer > infrastructure substituting the hwtmer and the vtimer. One design > objective is a more flexible backend that can cope with downcounting > and similar, so that the PIT timers should be usable. Addressing the > power-down and sleep issues of the timers and finding a generic way > to deal with this is also on the requirements list... I actually > expect some serious work on this starting by mid-January, so it's > only a matter of time... The problem with PIT is, that it is not running in low power mode. Let me know when you start it, I can help you, at least with tests :-) > About merging the Kinetis implementations: I would be careful with > this, as experience has shown that even MCU's from the same or very > similar families have their differences in their peripherals. This is > for example true for the STM CPUs, and that's why we have them > separated... But as I don't know the 'Freescale World' this concern > might be for nothing?! > The Kinetis MCU's peripherals are very similar (some peripheral are taken from ColdFire :-)). I think we should try it. > > Would there be any interest in merging the K60 and the KW2x > > peripherals into a single Kinetis port? @Gebart I will finish my LPTMR implementation and attach to #2059[1]. Then i will rebase it so that you can cherry-pick and test the peripheral driver (i2c, spi ...). If it works then we can start with kinetis_common. What do you think? Johann Fischer [1] https://github.com/RIOT-OS/RIOT/pull/2059 ___ devel mailing list devel@riot-os.org http://lists.riot-os.org/mailman/listinfo/devel
[riot-devel] hwtimer implementation for Freescale MKW2xDxxx
Hello RIOTers, I tried to implement a hwtimer for MKW2xDxxx and failed. The MCU has 4 downcounter PIT(Periodic Interrupt Timmer) 32-bit timers, PITs can be cascaded so that timer[0] acts as prescaler for timer[1]. PIT can be loaded with a start value. The timer will count down and generate an interrupt at 0. Then the start value will be reloaded and it will repeating. PITs can not run in low power modes. Apart from the fact that it is a down counter, the timer do not work in low power mode, and that bothers me. The MCU has also one Low-Power Timer. This one is a upcounter 16-bit timer with compare register and can be configured as as Free-Running Counter (reset on overflow not on compare match). Also LPTMR can run in (very) low power modes. I tried to implement the hwtimer with LPTMR. The implementation divided (or multiply) the tick-values by 1000 and run the timer with 1kHz. But this does not work reliable. There is also a RTC module, but it fits even less for the hwtimer. Ideas? Regards, Johann Fischer ___ devel mailing list devel@riot-os.org http://lists.riot-os.org/mailman/listinfo/devel
Re: [riot-devel] Switch to BSD?
On Tue, 9 Dec 2014 16:31:00 +0100 Emmanuel Baccelli wrote: > I agree with you: we need "another Linux" and not "another Contiki". But > two questions: > (1) can we realistically mimic the Linux story and stay with LGPL? > (2) why would RIOT necessarily become "another Contiki" if the license > evolves to BSD/MIT? > Concerning (1): what does our experience from the last year show? That LGPL > is far from a perfect solution, because too many company lawyers cannot > deal with it. On the other hand, we know that BSD/MIT also has its down > sides. So we have to trade-off between the "dangers of BSD/MIT" and the > "dangers of LGPL". There is no perfect solution, I agree. But still, we > have to make a choice. > > On one hand, if we do not change the license, we can force people to do > things our way, and it has indeed moral value. But it's difficult to force > people/companies to do things. Those who do not want to, or cannot, "give > back" will simply not use RIOT in the first place -- hence a much slower > adoption that looks like a potentially fatal problem in the short term. > If we change the license, some people/companies could indeed fork and close > their source, and that is not what we want. However, these people will use > RIOT and have a chance to change their mind about contributing back -- when > they realize the burden of rebasing their code all the time. The bet is > that the momentum in the community will remain sufficiently attractive to > aggregate enough contributions to thrive in the mid-term. Hello Emmanuel, sorry for late reply. The company where I work develops and produces embedded boards and makes the portings of linux kernel. We know the advantages and disadvantages of (L)GPL. We spend time and money to porting linux to our boards because we want to sale hardware and our customers benefit from it. > What is the most unclear to me is: what are the consequences of the choice > of license in the long run? Can you explain exactly what you expect of licence change? That more hardware will be supported? That RIOT will be more spread? There are also companies that have made the ports for contiki but will only give the porting for the hardware back to the project, but not the improvements of core (I can not say more). > However, one thing is for sure: this question is irrelevant if we're out in > the mid-term. > > The value of an open source community is equally (i) the quality of the > code base it provides and (i) the liveliness of the community. So > concerning (2), do you think BSD/MIT would: > > - harm the RIOT community? -yes, not everyone will agree with the change. > - harm the RIOT code base? -no, but I think it will not improve the code base. > If so how, and at which stage (short, mid long term), and how bad? Is it > worse the risks of too slow adoption if we stay with LGPL? This is what we > really have to gauge now. Johann Fischer ___ devel mailing list devel@riot-os.org http://lists.riot-os.org/mailman/listinfo/devel
Re: [riot-devel] Switch to BSD?
Hello RIOTers, Emmanuel Baccelli wrote: > 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. They always do that. We have seen it in other successful projects such as linux kernel. I see RIOT as a part of a free an open infrastructure. And for the IoT we need an open infrastructure. There are companies that use (public) infrastructure but want to give anything back and BSD license favored this behavior. RIOT should not be another Contiki. > 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. I am absolutely against the BSD license and I see no necessity for it. RIOT will be successful without this change. That is my personal opinion, not the company where I work. Best regards Johann Fischer ___ devel mailing list devel@riot-os.org http://lists.riot-os.org/mailman/listinfo/devel
