The one for atmega_common is finished. Just waiting for other PRs to be merged.
On 06.11.2017 22:25, Dylan Laduranty wrote: > Hi Travis, > > I have to said that I agree with you. The current clock support and so > the low power implementation are from being perfect (I'm speaking of > SAML21 which is basically the only hardware I'm focusing on RIOT right > now). I don't know how the others maintainers see the future of RIOT, > but having a working low power implementation would be very useful. > > I'm currently playing with the SAML21 low power mode for some company > stuff. > > I would love to help you in this endeavour ! > > Dylan > > > 2017-11-06 16:48 GMT+01:00 Travis Griggs <[email protected] > <mailto:[email protected]>>: > > I don’t know what language the HackNAck pre meeting will be in, my > presumption is that it will be primarily Deutsch. If I were able to > be there, I would want to sit and talk with at least a subset of the > core RIOT people about the SAM core osc/clock/periph configuration. > Since that probably won’t happen, I thought I’d at least put some > words on paper on the subject. > > Background Retrospective First > By way of introduction… I first become aware of RIOT last March at > ELC in Portland during Thomas Eichenberg’s presentation. At the > time, we (myself and Dan Evans who goes by photonthunder) were > attempting to make FreeRTOS work on the SAMD21. We used FreeRTOS > because there was an example showing how to mix it with ASF to run > on said chip. Our primary desire was for basic multitask scheduling. > We were not enamored with the ASF and the shackles they placed on > how you wrote your code. FreeRTOS is not, by defaul,t tickless, and > making it tickless can be a bit of a challenge. In our application, > power consumption is king, so tickless was essential. > > Thomas Eichenberg was very helpful and accommodating in helping us > get the first samd21 branch included in RIOT. Since that time, Dan > and I have really appreciated the help and guidance that have been > thrown our way through PRs and other activities. I can’t say it’s > been consistent, sometimes we get great responses, sometimes we just > hear crickets, BUT we are really grateful for the answers that do come. > > Over the last 8 months, I’ve watched all of the GitHub traffic. I’ve > observed that the majority of PRs that go by are application level > drivers. RIOT has more protocol drivers than I can count. It’s truly > impressive. PRs surrounding power consumption seem to be fewer and > make slower progress. I believe that a significant amount of IoT > applications are (or will be) confronted with real power > constraints. If someone came to me seeking my recommendations > regarding RIOT, I would probably say “Basic multitasking OS stuff? > Solid. Protocol stacks? They’ve got you covered! Power? You’re going > to have to work at it.” When I pinged the IRC channel within 24 > hours of Thomas’s presentation, this was the basic feedback I got > back from Michael Anderson (iomemsys). I think that this is still > pretty much the case. > > SAMD21 Situation > The original samd21 port was basically done by cloning the samr21 > and trimming back the radio parts. Since then, there have been a > number of tasks to “unify” various pieces of source code moving > things up the tree, either to sam0_common, or even cortexm_common. > The samd21 chip is a pretty versatile chip. It sports 5 oscillator > sources. Two pseudo sources (1 PLL and 1 DFLL). 9 generic clock > generators can be driven from these 7 sources, with a variety of > options for configuring dividers and power modes. Configuring your > CPU clock and peripherals is a lot like driving a multi transmission > semi tractor trailer. You’ve got gearboxes galore to shift around to > produce different results. > > The original samr21 offered users a single clock/peripheral > configuration using the startup 8MHz RC Oscillator. xtimer was hard > coded. Later someone added a second path to use the PLL at higher > frequencies. Dan and I have floated PRs to include a DFLL based > option. Recently, another configuration PR has been put up. The > basic approach to all of these has been to come up with a “recipe” > for how to configure the registers, give it a name that is derived > from one of the components, try to hunt down all of the existent > dependencies and capture them, and use #ifdef branches to capture > that particular recipe. It’s like getting a box of legos, but being > told you can only put them together 4 ways. And each new recipe has > to be expressed as a derivative of the original recipes. > > It is my belief that this is just not a scalable approach to > configuring the samd21 for RIOT. It will continue to limit the > application programmer's ability to tune the chip's flexibility to > their application. I believe that a model that allows the user to > better follow the model presented in the data sheets is what is > needed. I would expect to be able to configure all of oscillators in > one place, preferably in a coding construct/format that approximated > something tabular. I would expect to be able to do something with > the array of clock generators, indicating which were enabled, > sourced to what, and divided appropriately. And I would like to be > able to configure each peripheral’s clock source. > > Dan and I groused through the SAML data sheet earlier today. Like > the SAMD, the SAML has a handful of oscillator sources and > lock-loops, and it has 8 generic clocks, which can serve as sources. > So maybe there’s an argument to do both together. Dan and I just > have samd21 boards though, so to do this kind of work, we need > someone with access to SAMLs to agree to iterate regularly with us. > _______________________________________________ > devel mailing list > [email protected] <mailto:[email protected]> > https://lists.riot-os.org/mailman/listinfo/devel > <https://lists.riot-os.org/mailman/listinfo/devel> > > > > <https://www.avast.com/sig-email?utm_medium=email&utm_source=link&utm_campaign=sig-email&utm_content=webmail> > Garanti sans virus. www.avast.com > <https://www.avast.com/sig-email?utm_medium=email&utm_source=link&utm_campaign=sig-email&utm_content=webmail> > > > <#DAB4FAD8-2DD7-40BB-A1B8-4E2AA1F9FDF2> > > > _______________________________________________ > devel mailing list > [email protected] > https://lists.riot-os.org/mailman/listinfo/devel > -- Robert Hartung, M.Sc. Technische Universität Braunschweig Institut für Betriebssysteme und Rechnerverbund Mühlenpfordtstr. 23, Raum 115 38106 Braunschweig Fon: +49 (531) 391 - 3264 Fax: +49 (531) 391 - 5936 E-Mail: [email protected] _______________________________________________ devel mailing list [email protected] https://lists.riot-os.org/mailman/listinfo/devel
