
Embedded Rust Experiments: Is My STM32 MCU Running Fast? - ingve
https://nercury.github.io/rust/embedded/experiments/2019/01/27/rust-embedded-02-measuring-the-clock.html
======
userbinator
That diagram of the clocking system is a good example of how the bigger MCUs
are like having a whole computer on a single chip, with all the implications
of complexity that brings. It's not enough to set up a single clock; you also
need to make sure the clocks to the peripherals that are in use are also what
you need them to be.

(I wish such diagrams in datasheets would let you click on the appropriate
blocks to jump directly to their registers and description sections.)

~~~
henrikeh
Vendor tools for STM provide almost exactly what you wish for for the clock
diagram.

Example:
[http://www.emcu.it/STM32clk/STM32clk.html](http://www.emcu.it/STM32clk/STM32clk.html)

~~~
Rebelgecko
I haven't used the STM Cube configurator for a while, but last time I did it
was almost at FPGA software levels of user-unfriendlieness. If you changed the
indentation on a magic comment in your code and then adjusted one of the
clocks, CUBE would clobber your existing code and silently delete it.

~~~
henrikeh
Yes, Cube autogenerates a lot of code and will overwrite things that don’t
follow the inserted markers.

The original article even includes an example of using Cube to configure the
clocks and then use those configurations together with Rust.

I agree that it isn’t ideal at all and kinda wonky. But more links in the
datasheets would be nice.

------
edoo
It is always good to get to know your MCUs. When I first started using STM32s
I would also scope the crystal and then toggle some pins as fast as possible
to make sure.

Many gadgets later I trust the programmatic detection of external crystal use
and appropriate PLL function. If you HAVE to know if the crystal fails you can
use the CSS (Clock Security System) to generate interrupts in case you fall
back to the internal oscillator.

~~~
ChuckNorris89
TIP: You should never scope a crystal directly as that could damage it. In
production, for testing crystals, we output a PWM on a pin using the crystal
as a source and measure that if the MCU doesn't have a built in functionality.

~~~
philpem
I've never heard of putting a scope probe on a crystal damaging it, though the
load resistance (typically 1Megohm to ground) and capacitance (~5pF to ground)
will affect the frequency.

This is why the PWM-out is useful -- it gives you a buffered, divided-down
version of the crystal clock.

------
carlmr
I think the hybrid approach, high-level Rust + low-level C is actually
preferable. Rust really shines at the high-level things and you do what C is
good at on the drivers.

~~~
gpm
I don't see what C gives you at a low level that rust doesn't.

You can translate C line by line into identical rust at no cost except that
you have to write "unsafe" once per fn. With the exception of macros, but
rust's replacements there are just better.

Keeping everything in one language seems like a worthwhile reason not to use C
to me.

~~~
mrob
C gives you better options for static analysis of worst case stack usage, e.g.
[https://github.com/PeterMcKinnis/WorstCaseStack](https://github.com/PeterMcKinnis/WorstCaseStack)

Proprietary software for this is also available with superior UI and features,
and I expect people serious about high-reliability embedded systems already
use it.

Rust Nightly does have limited support for printing stack usage by function
with -Z emit-stack-sizes, but I could not find anything for analysis of worst
case stack usage in whole programs.

~~~
gpm
Presumably you lose static analysis benefits as soon as you are mixing
languages though?

------
neltnerb
Very nice writeup, those clock registers get so hairy and your notes are
phenomenal!

