Repository navigation
Trying to build STM32F411 Nucleo #196
Description
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?
Thanks for help
Activity
pat-rogers commentedon May 23, 2017
FredPraca commentedon May 23, 2017
Sorry for this surely dumb question but what do you mean by classifier functions ?
pat-rogers commentedon May 23, 2017
FredPraca commentedon May 24, 2017
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 commentedon May 24, 2017
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 commentedon Jun 6, 2017
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 commentedon Jun 8, 2017