Forum > Embedded - ARM

How to build with MBF framework and STM32 [solved]

(1/8) > >>

petex:
hello,
I am experiencing frustration with getting the MBF framework to work with STM32. I see lots of units related to the STM32 so I am guessing it does work.

I have down loaded the package. From what I can see is that some (including cpuinfo.pas) of the existing units need to be patched with STM32 definitions before starting.

Why does this need to be done ? Is it not possible to have a clean build ?
Where are these units that need to be patched ?
Are they part of the compiler ?

I am guessing that some initial $DEFINES are required to define the particular controller, or maybe these are done behind the scenes by the compiler user options. (-CpARMV7M
-WpSTM32F103X8 )

Is there a WIKI to explain how to use this framework with STM32 controller types ? I didn't see any sample or test projects using STM32.

ccrause:

--- Quote from: petex on January 15, 2021, 10:57:17 am ---I have down loaded the package. From what I can see is that some (including cpuinfo.pas) of the existing units need to be patched with STM32 definitions before starting.

Why does this need to be done ? Is it not possible to have a clean build ?
Where are these units that need to be patched ?
Are they part of the compiler ?

I am guessing that some initial $DEFINES are required to define the particular controller, or maybe these are done behind the scenes by the compiler user options. (-CpARMV7M
-WpSTM32F103X8 )

--- End quote ---
Michael or maybe Don is best suited to help you get going with MBF.

From quick inspection the patches add several STM controllers to the compiler.  Several files need to be updated for this to work.  If your particular controller is already supported by trunk you probably don't need the patches (I haven't studied them in detail).


--- Quote from: petex on January 15, 2021, 10:57:17 am ---I am guessing that some initial $DEFINES are required to define the particular controller, or maybe these are done behind the scenes by the compiler user options. (-CpARMV7M
-WpSTM32F103X8 )
--- End quote ---
The compiler generates defines for the CPU type (subarch) and controller automatically (if the controller is supported by the compiler obviously).

Have you tried compiling one of the examples without applying the patches?  If there isn't a project file for your particular controller, just open one of the existing ones and change the -Cp, -Wp and -d settings according to your desired controller.

Edit:
Apologies for the misinformation in the above sentence. It seems that MBF needs to provide controller specific settings which are provided in controller specific include files. Luckily Michael is now helping you!

DonAlfredo:

--- Quote ---Michael or maybe Don is best suited to help you get going with MBF.
--- End quote ---

Indeed. Michael will be best suited to help.

Please note.

Work is done to integrate FreeRTOS and FPC for ARM mCPU's. This looks very (VERY) promising. We are in the process of integrating our efforts and Michael will introduce the necessary changes into FPC trunk (if acceptable by the devs) shortly (I hope).

Stay tuned.

petex:
The first error encountered is no definition for __CONTROLLERTYPE__

I assume this is substituted with "STM32f013" in order to pull in the specific STM32 modules.

I tried setting it specifically e.g.
{$DEFINE __CONTROLLERTYPE__ = STM32F103}
{$DEFINE __CONTROLLERTYPE__  STM32F103}
but that syntax doesn't work. I suppose the compiler sets this up like FPC_VERSION.

Must be missing something here ????

MiR:
Sorry for coming late to the party....

Too bad that you are experiencing troubles with mbf.

I have been mostly working on mbf-freertos in the last time as this is (for me personally) the way to go in the future.

I started using the git-wiki for fpc-freertos and based on your comment it looks like it makes sense to do the same thing for mbf.

Please let me go through mbf with bluepill in mind, I will provide a new version later today based on what i find, i already found one or two places that could be done better for that special chip.

Please also note that mbf for bluepill is curently only good for gpio, uart and spi, i2c does not work for stm32f1, but it is something that can be implemented, I just never needed it and it was never asked for.

Michael

Navigation

[0] Message Index

[#] Next page

Go to full version