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 <travisgri...@gmail.com>: > 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 > devel@riot-os.org > 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 devel@riot-os.org https://lists.riot-os.org/mailman/listinfo/devel
