[riot-devel] SAMD21 Configuration ( was Monthly meetings for organisation purposes)

Robert Hartung hartung at ibr.cs.tu-bs.de
Mon Nov 6 22:38:54 CET 2017

The one for atmega_common is finished. Just waiting for other PRs to be

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 <travisgriggs at gmail.com
> <mailto:travisgriggs at 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 at riot-os.org <mailto:devel at riot-os.org>
>     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
> devel at riot-os.org
> 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: hartung at ibr.cs.tu-bs.de

More information about the devel mailing list