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
