> In concrete, we target 3 registers from RCC: GPIO_AHBENR, APB1ENR, and APB2ENR > > https://github.com/Ell-i/Runtime/blob/master/stm32/cores/arduelli/arduelli_gpio.h#L107 > https://github.com/Ell-i/Runtime/blob/master/stm32/cores/arduelli/arduelli_usart.h#L71 > https://github.com/Ell-i/Runtime/blob/master/stm32/cores/arduelli/arduelli_timer.h#L70 > > However, we generate a initialisation register for each enabled peripheral, > leading to 15 initialisation registers in the case of the stm32f334 (with > usart activated): 4 for gpio, 8 for timer, and 3 for usart, instead of only 3. Right. > I propose to use a similar alternative to the one we use for the GPIOs, where > we generate the final state of the registers by collecting the variables and > ORing them: > > https://github.com/Ell-i/Runtime/blob/master/stm32/cores/arduelli/arduelli_gpio.h#L154 That's been the goal. > I have one concrete question before proceeding: Is it necessary to activate > the peripherals one by one (for power stability, maybe)?, or, in other words, > is there any problem if all the peripherals required for each register are > activated at once? Another goal is that you should be able to selectively include peripherals during linking time, depending what libraries you need etc. Putting those two goals together, we should OR the RCC register contents together during linking time, in order not to clock unnecessary peripherals. I see two ways proceeding: 1. Go towards the planned DSL (Domain Specific Language) for describing peripheral initialisations. 2. Create an ad hoc tool that handles the situation somehow intelligently. --Pekka
Attachment:
smime.p7s
Description: S/MIME cryptographic signature
