Proposal: stm32: move oscillator + pll config to machine package

[kenbell]

Problem

Currently, the pattern for STM32 MCUs is to do the oscillator and PLL configuration in the runtime package. This is causing a few issues:

1. Declaration of magic values separate from the code that initializes the system frequency, e.g.: https://github.com/tinygo-org/tinygo/blob/dev/src/machine/machine_stm32l0.go#L13
2. Lack of access to tick counter in machine package, leading to
   • Arbitrary loop counts used for delays, e.g.: https://github.com/tinygo-org/tinygo/blob/dev/src/machine/machine_stm32_i2c_reva.go#L53
   • Linker hacks to access tick counter anyway, e.g.: https://github.com/tinygo-org/tinygo/blob/dev/src/machine/machine_stm32_i2c_revb.go#L10

Proposed Changes

1. Move the initCLK (and where present initOSC) functions to machine package
2. Move runtime_stm32_timers.go to machine package
3. Make initCLK initialize: Oscillators, PLL, Timers

The runtime package would be responsible for calling initCLK (to preserve initialization order) as well as UART initialization / putchar

Bigger Picture

This would be the first of multiple steps to improve the clock frequency code:

1. Move OSC, PLL code into machine package
2. Specify external oscillator frequencies in board-specific files (HSE/LSE)
3. Remove magic values, use calculated clock frequencies based on actual clock speed
4. Remove arbitrary retry/tick counts in i2c/other driver logic, use calculated delays (more robust across chips with different clock frequencies)
5. Harmonize the PLL & OSC initialization code (there's a few basic patterns)

[deadprogram]

[aykevl]

This sounds like a good idea. I don't like duplication and generally I think moving code out of the runtime is a good idea: the runtime package should be concerned with the runtime (GC, scheduler, time.Now implementation, map/slice/string runtime calls, etc) and not so much with hardware details.

However, what may be complicated is designing a good API around it. Things in the machine package are generally designed so that they can also be used from use code, without interfering with the runtime package too much. For example, the putchar function in the runtime normally simply calls machine.UART0.WriteByte, this doesn't interfere much with the behavior of the UART (apart from sending that byte, of course).

[deadprogram]

@kenbell now that #1751 was merged, should this be able to be closed on next release?

[kenbell]

It's partly done right now - i want to get back to it. Needs some more thought about how we expose 'ticks' to the machine package still, since we've settled on using timers rather than systick to get high-precision sleep.

Fundamentally, I think the concept of 'ticks' belongs in the machine package - but not sure on the best way to get it there.

We can close though, and I'll raise another issue when I've got a firm proposal on the next steps from here.

[deadprogram]

Closing since the current release version of TinyGo contains these changes. Thanks @kenbell