bare-metal-programming-guide VS NAU881x-stm32-C

What cruftware? STM32 will run your code right away after reset clears[0].

0. https://github.com/cpq/bare-metal-programming-guide

If you want to build a deep understanding, there's nothing better than going bare-metal, in my opinion. Here's an amazing tutorial for bare-metal programming STM32s using just a compiler and a datasheet.

I have just the article for you: https://github.com/cpq/bare-metal-programming-guide

Not really an answer to the question, but someone linked this bare-metal programming guide repo a couple of days ago. Following the guide and trying to port it to your board might be really good exercise for someone at the beginning of their journey. At least I find it thorough enough and quite pedagogic.

If you have a lot of programming knowledge and are willing to RTFM it's not a bad way to dive in, provided you've got a guide like this one to help you get started. It's a super easy source of projects because if you have a discovery board of some sort, you've already got all these peripherals available. It would be trivial (and thus boring) to use them with your IDE's automagic HAL stuff and configuration, but using them from a manually-bootstrapped project (starting from square 1 with linker scripts and blank text file) it becomes a pretty interesting project all on its own, without even finding something practical to do with the device. Many hours of manual reading guaranteed.

Later, I walked through this post on baremetal STM32 and lots of details made a lot more sense. I'm still learning a lot, making mistakes and figuring things out as I go. That's part of the appeal for me, but then my livelihood isn't depending on this — I'm doing it just for fun.

Can I suggest a https://github.com/cpq/bare-metal-programming-guide ? Spend a couple of hours, follow it, maybe that is the fundamental basics you're searching for?

I also found this linux discussion of the regmap format of the codec, but I don't know whether the 7x9 regmap discussion is relevant, since I am adapting this driver that seems to work with "normal" microcontroller I2C usage.