How should microzig_main automatically call `init` for chip/hal/board/app?

[Grazfather]

From this comment from @tact1m4n3.

In the nordic and wch hals (maybe others) we have the example apps explicitly call board.init().

Maybe we should add logic to microzig_main to call it if its present. It already does this for the app and for the hal.

Makes sense to me, my only real concern is whether this call should supercede an init for the chip/cpu, or be called in addition to it.

• If its the former, then the board init should probably call the chip init, which should probably call the cpu init.
  • This grants extra flexibility (A board might opt not to call a chip init, for the reason below)
  • But it's also extra boilerplate (more boards should call chip init, which should call cpu init) and duplicated code (they might opt to manually do some work, which is more places to make sure to update)
• If it's the latter, I think we run the risk of some configs doing extra work (best case) or trashing each other.
  • For example, a chip setting up RCC to set up the clocks, only for a board, with an external clock, to immediately set them up again with an external clock.

[mattnite]

Yes, let's add board.init(), app -> board -> hal is the priority we want for sure.

I immediately thought that we should add chip and cpu as well, however:

• chip is supposed to be generated code, you can hand code it yourself, but it really should just help make sense of MMIO and other chips specific info, no real code.
• We effectively have init with cpu with the startup code

[tact1m4n3]

app -> board -> hal is the priority

👍

I would add init functions only for hal and board. For cpu it doesn't make sense since the cpu already provides the entry point. For chip I agree that it is best to not include any real code there.