[ell-i-developers] Re: Possible Optimization in RCC Initialisation Registers

  • From: Pekka Nikander <pekka.nikander@xxxxxx>
  • To: ell-i-developers@xxxxxxxxxxxxx
  • Date: Thu, 18 Sep 2014 07:17:42 +0300

> 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.


> 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.


Attachment: smime.p7s
Description: S/MIME cryptographic signature

Other related posts: