Trying to build STM32F411 Nucleo

[FredPraca]

Hello, I'm trying to build a runtime for STM32F411RE Nucleo board. One of the problems I face is that for example, stm32-timers.ads refers to _TIM6Base, _TIM7BASE, _TIM12Base, _TIM13Base and _TIM14Base which do not exist in the SVD file I got for STM32F411. For stm32-usarts.ads from _uartstm32f4, the same kind of problem appears with _USART1Peripheral . What is the right way to proceed and correct these problems?

Thanks for help

[pat-rogers]

On 5/23/2017 4:19 PM, Frédéric Praca wrote:

Hello, I'm trying to build a runtime for STM32F411RE Nucleo board. One of the problems I face is that for example, /stm32-timers.ads/ refers to /TIM6_Base/, /TIM7_BASE/, /TIM12_Base/, /TIM13_Base/ and /TIM14_Base/ which do not exist in the SVD file I got for STM32F411. For /stm32-usarts.ads/ from /uart_stm32f4/, the same kind of problem appears with /USART1_Peripheral/ . What is the right way to proceed and correct these problems?

The right thing to do, not necessarily by you, is to move all the classifier functions out of the driver and into the STM32.Device packages that correspond to the specific MCU families (where the specific peripheral objects are declared).

[FredPraca]

Sorry for this surely dumb question but what do you mean by classifier functions ?

[pat-rogers]

On 5/23/2017 4:48 PM, Frédéric Praca wrote:

Sorry for this surely dumb question but what do you mean by /classifier functions/ ?

Not at all! In the Timers package these are the functions that are used to distinguish properties of the timers, eg whether it is Basic or Advanced, and so on. Look for a comment containing "Classifier functions" toward the bottom of the visible part and you will see them. In many cases these are used only for contracts, but in some cases they are also used to implement the functionality in the body.

And by the way, they cannot go in the STM32.Device packages due to circularities. Will require some thought. I'm looking into it. It is something I've been meaning to do.

[Note that the PWM package also contains such device-specific queries.]

[FredPraca]

Ok, thanks. I'll take a look at it, it will allow me to better understand the way everything is linked.

Without taking a look, I wondered this morning on my way to work if a child package or a separate unit would do the trick. What do you think about it ?

[pat-rogers]

For the STM32.Timers package and the STM32.Device package, the difficulty with a child package of either one, or even a separate package altogether, is that the Timer package spec is where the references to these functions occur, so circular unit dependencies are unavoidable if we move the functions out directly. I'm still looking at it, but I am beginning to believe we'll have to have a different version of the Timers and USARTs packages for the F411. (We'd want a dedicated Devices package (and RCC package presumably) anyway, to complement those in arch/ARM/STM32/devices/ currently.) We already do that sort of thing for other devices' drivers by putting them in distinct directories under the drivers/ dir.

[FredPraca]

Is the approach taken by Levraichacal here the good one ? I mean, creating specific versions for each driver is the good way to do from now as you already done? If so, bringing his version up to date might be a solution :)

[pat-rogers]

On 6/6/2017 10:36 PM, Frédéric Praca wrote:

Is the approach taken by Levraichacal here the good one ? I mean, creating specific versions for each driver is the good way to do ?

Yes, that's the idea, because some of the drivers should be compatible.