I've now ported a nontrivial firmware application over to stm32-metapac and I'm delighted with the results. It has enabled me to extend my G0 prototype to support C011 with very few code changes. So, thank you for all the hard work there.

I ran into something interesting during the porting process. First, I kept getting zero-byte binaries, but this was my own mistake. (In case anyone's reading this with that problem: make sure you've specified the rt and pac features and included the -Tlink.x linker arg in your target triple. And not, say, in a different but unrelated target triple you copied from another project. Learn from my mistakes.)

Then I started getting very small binaries -- like 5 kiB instead of the ~18 kiB I was expecting. This is almost always a sign that rustc has decided that some code has become an unconditional panic or UB and eliminated the rest of the program.

After spending some time hunting and reading the machine code, the problem turned out to be my use of the AFRH register in the GPIO block. Previously, using the traditional PAC, I had

    p.GPIOA.afrh.write(|w| {
        w.afsel9().af1(); // USART1_TX
        w.afsel10().af1(); // USART1_RX
        w
    });

During the port to the metapac, I rewrote this code to

    device::GPIOA.afr(1).write(|w| {
        w.set_afr(9, 1); // USART1_TX
        w.set_afr(10, 1); // USART1_RX
    });

(This reflects the discovery that the registers described in the reference manual as AFRL / AFRH are modeled in the metapac as a two-element array -- which I'm not totally convinced about, but I can see the advantages for HALs!)

This code was compiling into an unconditional program-ending panic. Perhaps you can see the problem already. :-) If, like me, it isn't obvious, the answer is: the AFR field arrays in each of the two AFRx registers are treated as 8-element arrays. This means to set (say) AFRH9, you need to set_afr(1, 1) instead of set_afr(9, 1).

Given that the fields in the AFRH register are numbered from 8 in the reference manual and all other SDKs, this seems like it's going to bite other people in the future. I've altered my code to use set_afr(9 - 8, 1) to try and remind me what's going on in the future.

I wonder if you can think of a way to address? Since the setters already contain an index-checking assert, I suppose they could insist that the accesses start at 8 and subtract 8, but... even though that would have fixed my bug, it seems really weird and inconsistent.

Allowing the use of constants for the indices maybe? Passing AFR8 which is secretly equivalent to 0 would make the code easier to read in terms of the datasheet. However, since the registers are modeled as an array, the types of AFRL and AFRH must match -- meaning that this would open the risk of using AFR8 as an index to AFRL, which would be bad.

Anyway, as you can probably infer from my questions, I don't see a super obvious fix here -- but I wanted to raise it before it surprises other people.