Re: [riot-devel] Notification: Hack'n'ACK @ Tue Aug 25, 2015 5pm - 10pm (RIOT Events)
I noticed that two of my assignments are in that list. I will not be able to participate in the hack n ack session tonight, however, feel free to ACK and merge anyway or take over the assignments if you want to. Best regards, Joakim Gebart On Tue, Aug 25, 2015 at 3:43 PM, Oleg Hahm oliver.h...@inria.fr wrote: Dear Hackers and Ackers, so far we have 12 candidates for the session tonight: https://github.com/RIOT-OS/RIOT/labels/Hack'n'ACK%20candidate Feel free to add more, but I would really love to see at least half of the candidates being merged tonight, so don't overestimate our capacities. Cheers, Oleg Am Mon, Aug 24, 2015 at 02:59:51PM + schrieb Google Calendar: This is a notification for: Title: Hack'n'ACK When: Tue Aug 25, 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=VIEWeid=bGJrNG1mdWNxZG9tY2Y3YzhvOWNnNGNtc2dfMjAxNTA4MjVUMTUwMDAwWiBrM3FsOHNldHY3bDQ4b2Zub2wwdGZ1dTZ0c0Bn 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 -- panic(Yeee, unsupported cache architecture.); linux-2.6.6/arch/mips/mm/cache.c ___ 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] C++ Style Guide
On Thu, Jun 25, 2015 at 11:44 AM, Johann Fischer j.fisc...@phytec.de wrote: 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. +1, indentation must match between the C and C++ coding conventions, there will be fewer style mistakes that way. By the way, can someone explain to me short why we need C ++ at all? I quite enjoy writing applications in C++ instead of C. The C++ support is basically just a service to other RIOT users like me who like to use C++ for writing their applications. I don't know if the RIOT community will be open to having RIOT modules and device drivers written in C++, (other than the C++ support modules, of course). Regards, Joakim ___ devel mailing list devel@riot-os.org https://lists.riot-os.org/mailman/listinfo/devel
Re: [riot-devel] C++ Style Guide
Good initiative! Could you create a new wiki article similar to https://github.com/RIOT-OS/RIOT/wiki/Coding-conventions for the C++ conventions? /Joakim On Thu, Jun 25, 2015 at 11:09 AM, Hiesgen, Raphael raphael.hies...@haw-hamburg.de wrote: 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. Raphael [1] https://github.com/actor-framework/actor-framework/blob/develop/CONTRIBUTING.md ___ 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] API proficiency levels
Did the discussion about redundant parameter validations and DEVELHELP die? I like the idea of getting rid of some redundant input validation. For example, if you are internally using spi_transfer_byte to provide spi_transfer_regs, then if the SPI device is valid for the first byte transferred, then it is probably going to be valid for the rest of the bytes in the same function call chain. There was some discussion about null pointer checks in a PR or a mailing list thread but I did not find it when I did a brief search. Best regards, Joakim Gebart www.eistec.se On Wed, Mar 25, 2015 at 5:02 PM, Kaspar Schleiser kas...@schleiser.de wrote: Hey, On 03/25/2015 11:12 AM, Hauke Petersen wrote: in general I like the idea, one problem I see is however, that is not always clear, to which level an API belongs (e.g. the GPIO API is definitely used also by high-level application programmers, while still belonging to the low-level peripheral drivers...). We could mark certain functions / parts of an API as advanced in the docs and provide safe alternatives. Seriously, it hurts to not be able to work around 10 redundant checks whether an int coming from flash is a correct SPI device... Kaspar ___ 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] Association time in mobile RPL/6lowpan networks
On May 21, 2015 8:37 AM, Cenk Gündogan cenk.guendo...@fu-berlin.de wrote: Hey Adam, I am currently adopting RPL to our new network stack and while doing so, I also added sane functionalities which were plainly missing in the old implementation. This also includes sending a DIS when initializing RPL for the first time. However, I am just now realizing that such a DIS can get lost in our typical LLN case - it may make sense to send a DIS periodically until a DIO is received? Does anyone has an opinion on this? Good idea, as long as the periodic interval is large enough to not waste power or cause interruptions in normal traffic if there is no other rpl node on the network. Forcing a DIS from userspace sounds like a good feature. It may help in testing/debuging the dodag tree interactively. I also thought about reseting the trickle timer from userspace to enforce DIOs. +1 for this. It would be nice to have some shell commands to call these functions too. Best regards, /Joakim Cheers, Cenk On 21.05.2015 04:36, Adam Hunt wrote: That's great. Is there any way to force a node to send a DIS message from userspace? On Wed, May 20, 2015, 5:34 PM Oleg Hahm oliver.h...@inria.fr wrote: Hi Adam! Has anyone tested the amount of time it takes for a node (full or reduced function) to join an RPL routed 6lowpan network? I realize that it's very likely to vary quite a bit depending on the network, I'm just curious if anyone has an approximate range. As you said: it depends quite a bit on the network and the parameters. Since nodes on the current RPL implementation won't send proactively DIS messages and the interval of sending DIOs increases, it will usually take just a couple of seconds if you try to join the network right after bootup, but can take more than one minute in a later phase. Cheers, Oleg -- printk (KERN_ERR %s: Oops - your private data area is hosed!\n, ...) linux-2.6.6/drivers/net/ewrk3.c ___ 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
[riot-devel] GSoC status
Hello fellow developers, Will there be public status updates from the GSoC projects during their work or will all be revealed at the end of summer? I am interested in all three projects and would like to know if I can support the students in any way. What is the time period that the students will be working on this? Best regards, Joakim Gebart Managing Director Eistec AB Aurorum 1C 977 75 Luleå Tel: +46(0)730-65 13 83 joakim.geb...@eistec.se www.eistec.se ___ devel mailing list devel@riot-os.org https://lists.riot-os.org/mailman/listinfo/devel
Re: [riot-devel] enums vs. macros
gcc's -fshort-enums might do what you describe: https://gcc.gnu.org/onlinedocs/gcc/Code-Gen-Options.html: -fshort-enums Allocate to an enum type only as many bytes as it needs for the declared range of possible values. Specifically, the enum type is equivalent to the smallest integer type that has enough room. Warning: the -fshort-enums switch causes GCC to generate code that is not binary compatible with code generated without that switch. Use it to conform to a non-default application binary interface. /Joakim On Wed, May 13, 2015 at 8:12 AM, Oleg Hahm oliver.h...@inria.fr wrote: Dear replying IoTlers, some time ago I had a discussion with Martine on GitHub about the usage of enums for flags [1]. Martine convinced me that seems to be wise to prefer macros over enums here, to avoid alignment issues. However, it feels somehow wrong not to use enums for this purpose (it's easier for the developer *and* the compiler if a valid data type is chosen). Does anyone know a trick around the issues that Martine mentioned: Because flags have a width in memory that is in most cases smaller than sizeof(enum) (most bit fields I know of are 16 bits max, on most of our newer platforms, sizeof(enum) is however 32 bits). This results in every assignment needed to be cast to either uint8_t or uint16_t. With macros you don't need to cast since they are typeless. Making the enum packed makes it's width unpredictable in terms of alignment issues, when used in struct (which is not the case here, I know). Cheers, Oleg [1] https://github.com/RIOT-OS/RIOT/pull/2614#discussion_r28941692 -- panic (No CPUs found. System halted.\n); linux-2.4.3/arch/parisc/kernel/setup.c ___ 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] Implementing a new MAC protocol for IEEE 802.15.4
On May 11, 2015 3:12 PM, Daniel Krebs m...@daniel-krebs.net wrote: Hi Joakim, +1 We use mostly Contiki-based applications presently and it would be a big improvement if it was possible to get ContikiMAC duty cycling working in RIOT as well. Who is we if I may ask? Just curious. Sorry about that, I should have started with At Eistec, we use mostly contiki... BR, Joakim # Requirements * Mesh topology = no single-point-of-failure Is this not a requirement of the routing? Did you have a look at the IEEE 802.15.4 specification? It's assumed to have a so called PAN coordinator that forces the network to a star topology. It's extendable to a tree of stars, but still you need a PAN coordinator in every region. This node is the mentioned single point of failure and additionally has increased energy consumption. This is exactly what I don't want. # Ideas / Questions * Do we need broadcasting? Routing protocols might need it. RPL sends solicitation messages to ask for routing information. There are broadcasting schemes for the implementation I aim for, but they don't come for free in terms of energy consumption, like e.g. on a network bus. I'll elaborate about this later if you want. * Add multi-hop / routing later? Is this even reasonable? Some kind of routing will be necessary for any useful applications, at least some kind of hardware address to IPv6 address mapping must exist to fill the neighbor cache. (e.g. RPL, NDP) Sure. Hardware addresses are needed anyway to get your data delivered to the destination node. Best regards, Daniel Krebs ___ 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] Implementing a new MAC protocol for IEEE 802.15.4
On Mon, May 11, 2015 at 11:37 AM, Daniel Krebs m...@daniel-krebs.net wrote: Hello RIOTers, I want to use RIOT for a low-power 802.15.4 network project. Having a bit familiarized with RIOT and my samr21-xpro boards now I want to tackle my next milestone, i.e. I need a MAC protocol that fits my requirements (see below). As it seems that there are only 2 MAC implementations for now [1,2], both not what I'm searching for and also not merged, I decided to try this on my own. Therefore I studied some papers and existing MAC schemes to not reinvent the wheel. There is one nice paper [3] that sums up quite nicely the most basic duty-cycling schemes (p. 4ff). There are some adaptions and refinements to these protocols which might improve the throughput or energy-saving further, but I think that these basic schemes already provide a good starting point. Namely there is ContikiMAC [4] that incorporates these improvements. While I want to start implementing a basic and simple protocol first, I wonder if it could be nice for RIOT to have some ContikiMAC-compatible MAC layer later. +1 We use mostly Contiki-based applications presently and it would be a big improvement if it was possible to get ContikiMAC duty cycling working in RIOT as well. I can't promise anything for now on how well this will work in the end, but I wanted to inform you about my undertaking and maybe you have some thought or pointers that could help me. As there is so much change in all over the network stack at the moment, it would be nice to know which (for me relevant) parts of the stack I should use that are not subject to change shortly. I gathered some notes and requirements, please find them below. Best regards, Daniel Krebs [1] https://github.com/rousselk/RIOT/commits/s-cosens [2] https://github.com/RIOT-OS/RIOT/pull/2467 [3] http://ieeexplore.ieee.org/stamp/stamp.jsp?arnumber=4539479 [4] http://dunkels.com/adam/dunkels11contikimac.pdf Requirements for MAC-layer == # Requirements * Mesh topology = no single-point-of-failure Is this not a requirement of the routing? * Low energy consumption * Relatively small single-hop network (~10 nodes) * New nodes can join and leave the network * No need to comply with IEEE 802.15.4 MAC schemes * No need for hard realtime * Should be reasonibly simple to implement # Ideas / Questions * Do we need broadcasting? Routing protocols might need it. RPL sends solicitation messages to ask for routing information. * Add multi-hop / routing later? Is this even reasonable? Some kind of routing will be necessary for any useful applications, at least some kind of hardware address to IPv6 address mapping must exist to fill the neighbor cache. (e.g. RPL, NDP) * Do we really need adaption to traffic load? * Find out which APIs to use in RIOT to have a modular MAC protocol that might work with multiple transceivers # Observations * Requirements seem to match ContikiMAC, so maybe aim for compatibility? Yes! # Implementation * Duty cycle nodes for energy saving * LPEAS = Implicit synchronization * Use 802.15.4 features, so this might only work with 802.15.4 networks ___ devel mailing list devel@riot-os.org https://lists.riot-os.org/mailman/listinfo/devel Best regards, Joakim ___ devel mailing list devel@riot-os.org https://lists.riot-os.org/mailman/listinfo/devel
Re: [riot-devel] WDT questions
It has to do with the difficulty of providing a reliable way of poking the watchdog in an event driven, tickless, system such as RIOT. Maybe it is time to start discussing a watchdog api? In order to get any traction within industry applications I believe it will be necessary to at least provide an api for applications to use the watchdog. Best regards, Joakim Gebart Eistec AB www.eistec.se On Apr 29, 2015 2:43 PM, Baptiste Clenet bapcle...@gmail.com wrote: Hi, I've got two questions concerning WDT: - Why do we disable it on the samr21 at launch time? - Why doesn't RIOT provide a wdt.h in drivers/include/periph? Cheers, -- *Clenet Baptiste* ___ 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] WDT questions
An idea: Create a multi-channel software watchdog that in turn pokes the hardware watchdog when all parameters are met. We could configure different timeouts for different channels and each critical process can have its own channel(s) which they update independently. Some risks of this approach is that it will be possible for software errors to make the software watchdog misbehave and poke the hardware watchdog and keep the system running when it should be reset. Best regards, Joakim Thanks for your explanations. I understand why it is counter productive. But how RIOT will make sure that the board is not stuck in a deadlock? This is mandatory for industrial context. Cheers, 2015-04-29 15:07 GMT+02:00 Joakim Gebart joakim.geb...@eistec.se: It has to do with the difficulty of providing a reliable way of poking the watchdog in an event driven, tickless, system such as RIOT. Maybe it is time to start discussing a watchdog api? In order to get any traction within industry applications I believe it will be necessary to at least provide an api for applications to use the watchdog. Best regards, Joakim Gebart Eistec AB www.eistec.se On Apr 29, 2015 2:43 PM, Baptiste Clenet bapcle...@gmail.com wrote: Hi, I've got two questions concerning WDT: - Why do we disable it on the samr21 at launch time? - Why doesn't RIOT provide a wdt.h in drivers/include/periph? Cheers, -- *Clenet Baptiste* ___ 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 -- *Clenet Baptiste* ___ 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] broken archives?
I am also seeing this for http://riot-os.org/pipermail/devel/. The root site (http://riot-os.org) still works. I think the URL is configured wrong in mailman. https://lists.riot-os.org/pipermail/devel/ works for me. As an alternate archive you can also use gmane: http://news.gmane.org/gmane.os.riot.devel Regards, Joakim Gebart www.eistec.se On Thu, Apr 2, 2015 at 3:40 PM, Julien Vermillard jvermill...@gmail.com wrote: still, it's sending me to http://riot-os.org/pipermail/devel/ with a NGINX 404 page On Thu, Apr 2, 2015 at 3:37 PM Emmanuel Baccelli emmanuel.bacce...@inria.fr wrote: Hi Julien does it still do that for you? On my end, it works perfectly well. Best, Emmanuel On Thu, Apr 2, 2015 at 3:27 PM, Julien Vermillard jvermill...@gmail.com wrote: Hi, I tried to consult this mailing list archives, but the archive link on this page: https://lists.riot-os.org/mailman/listinfo/devel return a 404 Julien ___ devel mailing list devel@riot-os.org https://riot-os.org/mailman/listinfo/devel ___ devel mailing list devel@riot-os.org https://riot-os.org/mailman/listinfo/devel ___ devel mailing list devel@riot-os.org https://riot-os.org/mailman/listinfo/devel ___ devel mailing list devel@riot-os.org https://riot-os.org/mailman/listinfo/devel
Re: [riot-devel] Removing thirdparty repositories
I haven't looked too closely, but I think at least the ideas put forward in https://github.com/RIOT-OS/thirdparty_cpu/pull/3 are useful. The PRs are old so they probably won't work on the current master but the LPM stuff is interesting. On the thirdparty_boards repo I didn't find anything interesting. Best regards, Joakim Gebart www.eistec.se On Sun, Mar 22, 2015 at 12:12 AM, Oleg Hahm oliver.h...@inria.fr wrote: Dear rousing IoTlers, since we don't need the thirdparty repositories for CPUs and boards any more for quite some time, I think we should finally remove them. Any objections? Can anyone with some experience with the Cortex ports take a look at the PRs in these repos that are still open and see if they contain anything useful that might be applied to the current implementation in RIOT master? Cheers, Oleg -- arrival order packet joke is critical to good a make ___ 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] Repository for Docker builds
On Sun, Mar 22, 2015 at 12:18 AM, Oleg Hahm oliver.h...@inria.fr wrote: Hi! Also, I need to have an organisation owner (Oleg, Kaspar, Emmanuel or Matthias Wählisch) create the repo since maintainers do not have the proper access to do it. Sure, I can do so. Let's wait if no one objects against the proposed name. This somehow disappeared from my radar. I think you need to give me admin access to the repository in order to move it to the RIOT organization (and rename it to riotdocker). What do you mean? If you create a new empty riotdocker repo in the RIOT organization we can push the Dockerfile commits to it. 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 ___ devel mailing list devel@riot-os.org http://lists.riot-os.org/mailman/listinfo/devel
[riot-devel] Radio duty cycling
Hello RIOTers, What is the current state of radio duty cycling in RIOT? I know that radio drivers implement on and off functions for the chip, but how do we make the best use of them? In order to reduce power consumption it will be necessary to duty cycle the radio . For comparison, in Contiki there are multiple RDC drivers that can be switched between at compile time, the most well-known is ContikiMAC [1]. Something similar would be very useful in battery powered scenarios for RIOT. [1]: http://dunkels.com/adam/dunkels11contikimac.pdf Best regards, Joakim Gebart Eistec AB www.eistec.se ___ devel mailing list devel@riot-os.org http://lists.riot-os.org/mailman/listinfo/devel
Re: [riot-devel] NSTF radio driver
Hi Thomas, On Fri, Feb 20, 2015 at 10:53 AM, Thomas Eichinger thomas.eichin...@fu-berlin.de wrote: Hi Joakim, On 20 Feb 2015, at 9:31 CET(+0100), Joakim Gebart wrote: Thank you for the prompt response. I will start reading the existing drivers but I think I will wait at least until there is a PR for the rf231 before I begin my implementation work. As Peter mentioned I'm working hard on refactoring the rf2xx driver. As we want to use it on EmbeddedWorld on Tuesday you can expect a PR for this soonish. :-) How is the new rf2xx driver coming along? I have been seeing some memory corruption problems on my platform and I think it originates somewhere in the radio stack, but I have not managed to pinpoint it further. I would like to test the new driver before I spend more time chasing down a bug that might have already been fixed in the refactoring process. Is there any WIP branch we can look at? Do you have any ETA for a PR? Best regards, Joakim ___ devel mailing list devel@riot-os.org http://lists.riot-os.org/mailman/listinfo/devel
Re: [riot-devel] kinetis common - differences between families
For the kw01 you should look at the PR that the Phytec guys are working on (Johann Fischer and Jonas Remmert et.al.) which can be found at https://github.com/RIOT-OS/RIOT/pull/2328 Best regards, Joakim On Mar 14, 2015 2:00 PM, Jozef Maslik ma...@binarylemon.com wrote: Hi, @Joakim, It is not easy question :) In short, we can say, there are differences between families based on core type but it is not true for all options. MCUs with core Cortex M4 have different modules compare to Cortex M0+ and here is difference compared to L0x family which use some modules from FSL 8bit parts (SPI, UART, timers…) 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) 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. 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. 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). From my point of view, best option is to have one common kinetis_family directory with all driver regardless of the family. Jozef On 14 Mar 2015, at 09:49, Joakim Gebart joakim.geb...@eistec.se wrote: We have used some conditional compilation in drivers where the differences have been somewhat manageable. See the UART driver for example. If the entire module is different then I guess I would prefer to have two separate C-files for the two solutions rather than forking the entire kinetis_common directory, because there are still many other modules which are the same between the processors. We have used such an approach for the RNGA, RNGB modules which are two different RNG modules which are present in the Kinetis processors. In the long run I think we will benefit more from each others' work if we try to keep all of the Kinetis code concentrated to one directory. If you look at the stm32fx cpu implementations you will find that there are some features only implemented in one of them and it is difficult to say which one is most up-to-date since different developers are using different CPUs to test their design and then they don't always port it to the other CPUs within the same family. Jozef: Do you know which modules are different and will need new drivers rather than only cpu-conf.h modifications? Below is a list of the currently implemented hardware drivers, as far as I know, they are fully functional on K60, KW22 (K20 with built-in transceiver), KW02 (based on some K0x, with built-in transceiver), and another K20 (unknown exact model): - ADC - CPUID (called UID in SIM module reference manual) - GPIO - hwtimer (uses LPTMR module) - I2C - MCG (supports all of PLL, FLL, fast and slow internal ref) - PWM (uses FTM module) - RNGA - RNGB - RTT (RTC module) - RTC (wrapping RTT) - SPI (DSPI module) - Timer (PIT module) - UART (conditionally compiling for some extra features present in the K60, K20, but not present in the KW0x, via #define KINETIS_UART_ADVANCED) Out of the supported CPUs, the KW0x is the oddest one since that has a M0+ core instead of an M3/M4. Best regards, Joakim Gebart Eistec AB www.eistec.se On Mar 13, 2015 7:57 PM, Hauke Petersen hauke.peter...@fu-berlin.de wrote: Hi Jozef, I have to say I was more or less expecting these slight differences... The RIOT way to go would be option 3. This is already done for the STM32Fx CPUs. Of course this leads to some duplication of code, but in the end it leaves the overall folder structure very clean and it is always clear, where the code you are currently building is coming from. In my opinion a finer grained dependency-tree like kinetis-common - kinetis-k-common - k60 on so on would lead to a structure that is as hard to maintain as some duplicated code... @gebart and @jfischer: would that solution work for you? Cheers, Hauke On 13.03.2015 19:47, Jozef Maslik wrote: Hi, How we want deal with the difference between variants of peripherals in Freescale Kinetis families (I mean, what is RIOT OS prefered way)? Here is difference between families - for example between K family vs L family. And if I remember correctly ;), there can be difference between specific chips in same family, too. For example SPI, kinetis_common contain driver spi.c but module on K60 is different compare to KL02 or KL10, etc. Here can be few options (minimal three ;)): 1. rename spi.c to real module name, at this situation it can be “DSPI” for K
Re: [riot-devel] kinetis common - differences between families
We have used some conditional compilation in drivers where the differences have been somewhat manageable. See the UART driver for example. If the entire module is different then I guess I would prefer to have two separate C-files for the two solutions rather than forking the entire kinetis_common directory, because there are still many other modules which are the same between the processors. We have used such an approach for the RNGA, RNGB modules which are two different RNG modules which are present in the Kinetis processors. In the long run I think we will benefit more from each others' work if we try to keep all of the Kinetis code concentrated to one directory. If you look at the stm32fx cpu implementations you will find that there are some features only implemented in one of them and it is difficult to say which one is most up-to-date since different developers are using different CPUs to test their design and then they don't always port it to the other CPUs within the same family. Jozef: Do you know which modules are different and will need new drivers rather than only cpu-conf.h modifications? Below is a list of the currently implemented hardware drivers, as far as I know, they are fully functional on K60, KW22 (K20 with built-in transceiver), KW02 (based on some K0x, with built-in transceiver), and another K20 (unknown exact model): - ADC - CPUID (called UID in SIM module reference manual) - GPIO - hwtimer (uses LPTMR module) - I2C - MCG (supports all of PLL, FLL, fast and slow internal ref) - PWM (uses FTM module) - RNGA - RNGB - RTT (RTC module) - RTC (wrapping RTT) - SPI (DSPI module) - Timer (PIT module) - UART (conditionally compiling for some extra features present in the K60, K20, but not present in the KW0x, via #define KINETIS_UART_ADVANCED) Out of the supported CPUs, the KW0x is the oddest one since that has a M0+ core instead of an M3/M4. Best regards, Joakim Gebart Eistec AB www.eistec.se On Mar 13, 2015 7:57 PM, Hauke Petersen hauke.peter...@fu-berlin.de wrote: Hi Jozef, I have to say I was more or less expecting these slight differences... The RIOT way to go would be option 3. This is already done for the STM32Fx CPUs. Of course this leads to some duplication of code, but in the end it leaves the overall folder structure very clean and it is always clear, where the code you are currently building is coming from. In my opinion a finer grained dependency-tree like kinetis-common - kinetis-k-common - k60 on so on would lead to a structure that is as hard to maintain as some duplicated code... @gebart and @jfischer: would that solution work for you? Cheers, Hauke On 13.03.2015 19:47, Jozef Maslik wrote: Hi, How we want deal with the difference between variants of peripherals in Freescale Kinetis families (I mean, what is RIOT OS prefered way)? Here is difference between families - for example between K family vs L family. And if I remember correctly ;), there can be difference between specific chips in same family, too. For example SPI, kinetis_common contain driver spi.c but module on K60 is different compare to KL02 or KL10, etc. Here can be few options (minimal three ;)): 1. rename spi.c to real module name, at this situation it can be “DSPI” for K family and “SPI” for L family. - exact name for K60 SPI module is “DSPI, then rename spi.c to dspi.c solve this major issue - module name for SPI on L family is simply “SPI” - I prefer this solution… 2. conditional compilation for different MCUs (one spi.c file) - this will be mess in code, because modules are too much different - I do not like this solution 3. another “common” directory - for each family - this can produce code duplication Regards, Jozef ___ 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] Google Summer of Code 2015
We have been getting quite a lot of students introducing themselves on the mailing lists now. How many students can be accepted? Who decides on which students are accepted? Google or RIOT? Best regards, Joakim On Mar 4, 2015 4:41 PM, Emmanuel Baccelli emmanuel.bacce...@inria.fr wrote: Hi everyone, we are happy to announce that RIOT was selected as mentoring open source organization for Google Summer of Code 2015. In short: this means that students are welcome to apply for (paid) project work in this context, to further develop RIOT, over the summer. For more details see [1]. Don't hesitate to forward this call for applications to students you know who may be interested in RIOT, and/or to apply if you are a student yourself! Student application opens March 16th and closes March 27th. But note that if you plan to apply, we recommend that you come forward even before this period, to share/shape ideas for your project (see process/templates below). Basically: you should engage a technical discussion with the RIOT community on devel@riot-os.org, as soon as possible. Templates for applications form can be found at [2], and GSOC project ideas for RIOT can be found at [3]. Note that these are just suggestions, and that you are welcome to propose your own project ideas! Cheers, Emmanuel [1] https://www.google-melange.com/gsoc/homepage/google/gsoc2015 [2] https://github.com/RIOT-OS/RIOT/wiki/GSOC-Student-Application-Template [3] https://github.com/RIOT-OS/RIOT/wiki/GSOC-Idea-List ___ 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] Repository for Docker builds
riotdocker is more descriptive for the github repo name, I like it. Best regards, Joakim On Feb 24, 2015 8:20 AM, Oleg Hahm oliver.h...@inria.fr wrote: Hi Joakim! What is a suitable name for the new repo? I have been using riotbuild for my Docker development at https://github.com/gebart/riotbuild I don't have any particular ideas for the name, so, for me riotbuild (or riotdocker) would be fine. Also, I need to have an organisation owner (Oleg, Kaspar, Emmanuel or Matthias Wählisch) create the repo since maintainers do not have the proper access to do it. Sure, I can do so. Let's wait if no one objects against the proposed name. Cheers, Oleg -- The problem with git jokes is everyone has their own version. ___ 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] NSTF radio driver
Dear RIOT developers, - Which radio driver is the most up to date with regards to the network stack restructuring work being done in #2278? - How stable is the radio device API currently? Are there any more API changes coming? - Would it be wise to wait until the restructuring todo list is mostly checked off until starting work on implementing a new radio device driver? - Which driver would be best to use as an example of a fully compliant radio driver? I am looking at implementing a driver for a new radio chip, but I do not want to have to redo the work again in a couple of weeks because of the network refactoring... https://github.com/RIOT-OS/RIOT/issues/2278 Best regards, Joakim Gebart Managing Director Eistec AB Aurorum 1C 977 75 Luleå Tel: +46(0)730-65 13 83 joakim.geb...@eistec.se www.eistec.se ___ devel mailing list devel@riot-os.org http://lists.riot-os.org/mailman/listinfo/devel
Re: [riot-devel] reserve main and let application define thread(s)
On Sat, Feb 14, 2015 at 3:28 PM, Kaspar Schleiser kas...@schleiser.de wrote:
Hi,
On 02/14/15 12:28, Ludwig Ortmann wrote:
I created quickdirty branches for both methods:
plain c:
https://github.com/LudwigOrtmann/RIOT/tree/wip/remove-main-application-init
macro magic:
https://github.com/LudwigOrtmann/RIOT/tree/wip/remove-main-make
Not sure which one I dislike better ;)
I like the main-application-init version because it is still somewhat
simple to follow. Perhaps it would be possible to still keep the
trampoline but make it execute application_init instead of main and
let auto_init() execute from the trampoline. This eliminates the need
to modify the example applications.
;)
I think we should come up with a method that enables inclusion of multiple
application threads. Maybe we can even replace auto_init in the process.
We could have something like
struct _auto_thread {
char* name;
char* stack;
int stacksize;
...
};
struct _auto_threads[] = {
{idle, idle_stack, STACKSIZE_IDLE, PRIORITY_IDLE, NULL },
{default, main_stack, STACKSIZE_MAIN, PRIORITY_MAIN, NULL },
{application, app_stack, ... }
};
The second struct we create during the build process and write it to a file
that gets includes by kernel_init.c. There, we just traverse the list in
order to start the threads.
For the makefiles we devise a way to declare these threads. Maybe something
easily parsable like
THREADS +=
(application;PRIORITY_MAIN+1;STACKSIZE_MAIN+STACKSIZE_PRINTF;dependency1,transceiver)
... with a lot of sensible defaults so John Duino can just do
THREADS += my_app
We could also introduce some kind of image build description file that
holds the necessary thread configuration:
E.g., defining one thread named default using a default stacksize, default
function name (default_thread), with a dependency on transceiver:
- examples/default/default.yaml:
default:
depends: [ transceiver ]
-
Defaults and modules:
- modules.yaml:
_defaults:
stacksize: STACKSIZE_MAIN
transceiver:
depends: [ pkt_buf ]
stacksize: INTERESTING_DEFINE
dumb_module:
thread: false # this module doesn't have a thread
init: true # we will call dumb_module_init on bootup
-
All that we parse and auto-generate the corresponding C code.
Not sure if we're entering a world of pain this way. ;)
This is a good looking solution for a large project with a clear and
well-specified build environment etc. but I think in this case we will
be over-complicating the build system.
BR,
Joakim Gebart
www.eistec.se
___
devel mailing list
devel@riot-os.org
http://lists.riot-os.org/mailman/listinfo/devel
Re: [riot-devel] How low can you go?
On Fri, Feb 6, 2015 at 10:10 AM, Thomas Eichinger thomas.eichin...@fu-berlin.de wrote: Hi, On 06 Feb 2015, at 09:36, Ludwig Ortmann ludwig.ortm...@fu-berlin.de wrote: Hi, On Fri, Feb 06, 2015 at 09:03:31AM +0100, Oleg Hahm wrote: Am Thu, Feb 05, 2015 at 02:09:52PM -0800 schrieb Adam Hunt: There's already a driver for for Atmel's AT86RF231 in the tree and while the AT86RF230 on the Raven boards are nearly the same the 230 lacks a couple minor features, namely a crypto processor and RNG. So, the RF link would be wide open but for experimentation and learning sacrifices are often necessary. As far as I know there were some considerations and work done towards a generic AT86RF23x or even AT86RF2xx driver. Thomas, am I right? Yes, I'm working on that (almost done). Yes, I will take up work on this again next week, as we have a stable netdev interface by today. That's great news! I have seen some compatibility issues when I have been attempting to use the 231 driver for the 212B (sub-GHz band), but I assume this is because every limit etc. is configured to work with the 2.4 GHz register values on the 231. BR, Joakim ___ devel mailing list devel@riot-os.org http://lists.riot-os.org/mailman/listinfo/devel
Re: [riot-devel] thread is not working
You can look at the startup files for other CPUs for a proper way of
doing initialization e.g. cpu/stm32f1/startup.c
Note that you must also make sure that your linker script provides the
correct symbols at the beginning and end of .data and .bss.
Best regards,
Joakim Gebart
Eistec AB
www.eistec.se
On 01/13/2015 10:45 PM, Ryan Kurte wrote:
Hi Shishir,
I seem to recall having the same issue when starting the EFM32 port.
The issue in my case was that without the startup files, the .bss
section was not getting cleared.
When the threads came to launch, the value in one of the kernel
functions was not correct. Which is pretty easy to check with a debugger.
The fix was to clear the .bss section in the _init routine, my
implementation (using symbols from the linker) is:
//Clear bss
for (uint32_t i = (uint32_t)__bss_start__; i
(uint32_t)__bss_end__; i++) {
addr = (int*)i;
*addr = (int)NULL;
}
I am not sure this is the /correct/ way to do it, but the .bss
definitely needs to be initialised to zeros.
Hope that helps,
Ryan
On 14 January 2015 at 07:56, Hauke Petersen
hauke.peter...@fu-berlin.de mailto:hauke.peter...@fu-berlin.de wrote:
Hi,
On 13.01.2015 19:04, shishir tiwari wrote:
Hi petersen,
Thanks for your information.
we are trying to put your method but still is it not working.
we are
studying and doing some experiments.
one more question : In hwtimer_init()-- hwtimer_arch_init()
this need
to be implemented in harsware is compulsory?? for scheduling
to work?
nope, the timer is generally not needed for scheduling.
Cheers,
Hauke
thanks
shishir tiwari
On Mon, Jan 12, 2015 at 10:01 PM, Hauke Petersen
hauke.peter...@fu-berlin.de
mailto:hauke.peter...@fu-berlin.de wrote:
Hi Shishir,
when RIOT initially starts up, the CPU is normally running
in interrupt mode
(using the interrupt mode stack). After creating the
stacks for the main and
the idle threads, the CPU must be put into thread-mode.
This means the main
threads initial context needs to put into the CPUs
registers and the stack
pointer must put to the main-threads stack. After this is
done the CPU can
just do 'normal' task switching for switching between threads.
So to put it short: in cpu_switch_context_exit() you
simply must load the
main threads context into the CPUs register and point the
stack pointer to
the main threads stack.
Let me know if you need further information!
Cheers,
Hauke
On 12.01.2015 15:35, shishir tiwari wrote:
Hey Everyone,
I have been porting RIOT OS to new processor(ARC) and
i had compilied
hello world program successfully.
When i debug the helloworld.elf in kernel_init
function the
thread_create() function has execute successfully.But
the thread
idle_thread and main_trampoline function is not
been called. why?
What is thing need to be done on this
cpu_switch_context_exit()
function. please explain me.
Thanks
Shishir Tiwari
___
devel mailing list
devel@riot-os.org mailto:devel@riot-os.org
http://lists.riot-os.org/mailman/listinfo/devel
___
devel mailing list
devel@riot-os.org mailto:devel@riot-os.org
http://lists.riot-os.org/mailman/listinfo/devel
___
devel mailing list
devel@riot-os.org mailto:devel@riot-os.org
http://lists.riot-os.org/mailman/listinfo/devel
___
devel mailing list
devel@riot-os.org mailto: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] hwtimer implementation for Freescale MKW2xDxxx
Hello Johann, I am developing for the K60 which has the same timer set up as the KW2x. The solution that I decided to go for is to let the LPTMR run at 32768 Hz and let the hwtimer use that one. It will not allow for 1 µs precision, but at least it will be able to wake the MCU from STOP modes. I have not yet made a PR from my work, but you can see the current WIP state at https://github.com/gebart/RIOT, mulle branch. Would there be any interest in merging the K60 and the KW2x peripherals into a single Kinetis port? See also some earlier threads regarding the Kinetis timers: http://lists.riot-os.org/pipermail/devel/2014-November/001426.html http://lists.riot-os.org/pipermail/devel/2014-October/001219.html http://lists.riot-os.org/pipermail/devel/2014-September/001086.html Best regards, Joakim Gebart Eistec AB www.eistec.se On 12/12/2014 11:14 AM, Johann Fischer wrote: 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 ___ devel mailing list devel@riot-os.org http://lists.riot-os.org/mailman/listinfo/devel
[riot-devel] Basing my cpu/board port off existing ports
What is the correct procedure regarding author and copyright headers
when I write a new port, but base the file off another port?
For example:
I start by copying the cpu/stm32f1 directory, as a basis for my new port.
The CPUs share no code other than RIOT generic code, such as API
(function declarations etc.).
Looking at cpu/stm32f1/lpm_arch.c [1], it has the following copyright header:
/*
* Copyright (C) 2013 INRIA
* Copyright (C) 2014 Freie Universität Berlin
*
* This file is subject to the terms and conditions of the GNU Lesser General
* Public License v2.1. See the file LICENSE in the top level directory for more
* details.
*/
/**
* @ingroup cpu_stm32f1
* @{
*
* @file lpm_arch.c
* @brief Implementation of the kernel's lpm interface
*
* @author Alaeddine Weslati alaeddine.wesl...@inria.fr
* @author Hauke Petersen hauke.peter...@fu-berlin.de
*
* @}
*/
All the functions in this file contain a single line `/* TODO */`, so
this file is only a stub necessary for building the project.
If I then implement all the functionality for the lpm functionality,
should I then add myself/my company as author and copyright or do I
leave the FU berlin stuff? Should I both add myself and keep the old
copyright? Should I remove the old copyright? What about @author
lines?
My gut feeling is that the correct way (legally) for me to implement
my own lpm_arch.c is to add Copyright (C) Eistec AB as a new line
below (C) FU Berlin as well as adding an @author line to the file
Doxygen block. This means that this file would end up with three
copyright lines, and three authors, of whom only one knows anything
about the code it contains.
[1]: https://github.com/RIOT-OS/RIOT/blob/master/cpu/stm32f1/lpm_arch.c
Best regards,
Joakim Gebart
Managing Director
Eistec AB
Aurorum 1C
977 75 Luleå
Tel: +46(0)730-65 13 83
joakim.geb...@eistec.se
www.eistec.se
___
devel mailing list
devel@riot-os.org
http://lists.riot-os.org/mailman/listinfo/devel
[riot-devel] Clarification on netdev netapi etc.
I see the terms netdev, netapi, pktbuf and more around the mailing lists and issue tracker, and I have understood that some of these terms refer to deprecated APIs and modules in RIOT, and some of them are referring to new APIs and modules. The page at https://github.com/RIOT-OS/RIOT/wiki/Model-for-the-network-stack describes some classes and use cases, and I believe it applies to the newer implementation. Could someone explain briefly some of the most used terms and what are the different APIs for network in RIOT and how they relate to each other? What documentation/source code files and directories are relevant? Which parts are deprecated/obsolete/on its way out? Best regards, Joakim Gebart Managing Director Eistec AB Aurorum 1C 977 75 Luleå Tel: +46(0)730-65 13 83 joakim.geb...@eistec.se www.eistec.se ___ devel mailing list devel@riot-os.org http://lists.riot-os.org/mailman/listinfo/devel
Re: [riot-devel] 802.15.4 SPI transceiver
There doesn't seem to be an existing RIOT driver for the MRF24J40MA. If you are not locked to that particular chip you have the AT86RF2xx which is also SPI and seem to have a quite actively maintained RIOT driver (it is used in the IoT-Lab_M3). Best regards, Joakim Gebart Eistec AB www.eistec.se On Tue, Dec 2, 2014 at 5:07 PM, Martin martin.landsm...@haw-hamburg.de wrote: Hi all, we searched for a suitable 802.15.4 transceiver with SPI interface to play around on e.g. the stm32f4discovery, and came across the MRF24J40MA [1]. Has anyone experience with the device? Best regards, Martin [1] http://www.farnell.com/datasheets/526949.pdf ___ 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] Separating module drivers from physical pin configuration
Dear Thomas, Thank you for your feedback, see my response inline below. On Mon, Dec 1, 2014 at 11:32 AM, Thomas Eichinger thomas.eichin...@fu-berlin.de wrote: Dear Joakim, On 30 Nov 2014, at 18:02, Joakim Gebart joakim.geb...@eistec.se wrote: I would like to have a separate driver for setting up the CPU pin mux. That is, separate the CPU logic module drivers (such as SPI, I2C, UART etc.) from the actual hardware ports and pins. You mean introducing a central point to handle all the PIN initialisation for the other peripherals? “Mux-driver, initialise pins for UART3!” I would expect that reconfiguring pin function muxing in the middle of a running application would be a quite uncommon use case, so I would expect something like during board init, I would call something like Mux-driver, initialize all pins according to board config X. And then the module drivers would not need to worry about which signal goes to what pin, only generating the signals. By improving the separation/abstraction it may make it easier use the same board directory for multiple variations of the same board, where the on board peripherals are the same, or almost the same, and only some minor additions. I see your point here, but couldn’t it be realised by using some different configuration in periph_conf.h separated by preprocessor guards? Like: ```C #ifdef MULLE_v1 #define SPI0_MISO_PIN PA12 ... #elif MULLE_v1.2 #define SPI0_MISO_PIN PB09 ... #endif ``` Yes, I guess you are right about the preprocessor conditionals, but there are some applications where you may want to configure something only a tiny bit different, e.g. rerouting the debug UART to another pin in the RPL border router, to let the default UART only handle SLIP traffic, and connect an extra UART cable to your PC only when you need the debug output. It is of course achievable by the traditional model as well, but if I know that all pin configs are done at a particular moment, and according to the config, then I do not have to worry about in what order I initialize drivers. Because of the hardware function muxing capabilities in advanced MCUs is usually in a separate module it is only logical that the driver for a CPU module does not need to know anything about which pin numbers on the IC is connected to its signals, the driver should only control the logic within its own module. The peripheral interface currently tries to exploit the greatest possible common set of functionality while minimising overhead. Since such a mux-driver would mainly be used in the other peripheral drivers it could be optional. Also it would need evaluation of the impact on more constraint platforms (cortex-M0 etc.) in terms of memory and clock rate. This is kind of a board/cpu software architecture design decision, I am merely looking for merits and deficiencies with this model. The main point of splitting it up is a logical division of responsibilities between software components. Since the pin function mux is its own hardware module it is only logical that it has its own driver, instead of letting all other drivers poke around inside it at will. Every driver in the current implementations is designed to handle its own hardware module, except it has to touch the pin muxing as well. Every driver also does basically the same thing during initialization, which means code duplication and risks for copy-and-paste errors or code rot. The outline of most drivers' init functions is: 1. Enable clock gate to I/O port/pin 2. Set pin mux to correct choice. 3. Enable clock gate to CPU module 4. Initialize CPU module configuration registers. The main change would be that steps 1 and 2 are handled in a central place = possibly less ROM usage. I like the idea in general but could you elaborate a little bit more on the concrete use case and implementation so we can discuss this in more detail. I don't have an implementation yet, still working on the best approach to do it, and whether it is a good choice, hence this thread. Best, Thomas Best regards, Joakim Gebart Eistec AB www.eistec.se ___ devel mailing list devel@riot-os.org http://lists.riot-os.org/mailman/listinfo/devel
