STM32F20xx generic working HAL example code for MicroCPro Software

[christian239955]

Posted on September 03, 2014 at 14:25

Hello Dear Community-Members,

I am having a problem with the STM32F207VG generated code from STM32CubeMX and the MicroC Pro Software from MircoE.

As I am new in this area I would need some help. The generated HAL from STM32CubeMX for the STM32F207VG is producing a lot of compiling errors if I am using the MicroCPro Software from MicroE. I have a call for that ongoing by MicroE and was now think are the problems may be related to the STM32CubeMX generated code.

Therefore my question I would need a generic working HAL example code of the STM32F20xx to try it with the MicroCPro Software.

#wanton-self-promotion

[Andrew Neil]

Posted on September 03, 2014 at 15:13

You mean this: 

http://www.mikroe.com/mikroc/arm/

[christian239955]

Posted on September 03, 2014 at 15:25

Yes

[Tesla DeLorean]

Posted on September 03, 2014 at 16:48

is producing a lot of compiling errors if I am using the MicroCPro Software

Like your project doesn't reflect the defines needed, or specify the include paths to be searched? Why wouldn't you be more specific about exactly what errors you are seeing? Or try one of the platforms that is actually supported and see how that works, and then port to your chosen platform?

[christian239955]

Posted on September 03, 2014 at 17:00

Hi,

okay most of them are Undeclared identifier, but they ''seem'' to be declared Examples: Undeclared identifier '__DSB' in expression core_cm3.h                Undeclared identifier 'HAL_UNLOCKED' in expression stm32f2xx_hal_can.c

[Andrew Neil]

Posted on September 03, 2014 at 17:07

but they ''seem'' (sic) to be declared 

How do they ''seem''  to be declared?

As clive1 says, why not just build one of the examples in one of the ''mainstream'' toolsets (the freebie versions should do) - and spot the differenc(es)?

Or hire someone to do that for you...?

[Tesla DeLorean]

Posted on September 03, 2014 at 17:41

Doing inline assembler from ARM's own include files falls squarely on the tool vendor to support, and the use of the appropriate compiler define. ie should it use Keil, IAR or GNU syntax for things.

[christian239955]

Posted on September 04, 2014 at 11:31

Hi,

I just had a look and Keil and is seems to be a great alternative, but at for now I am just happy that I understand the toolset I am using at this stage. I am really a newbie in this area and trying to understand what is going on by learning by doing, with some help and reading the hell what I can find.

Thanks for the tips to look at other toolsets and samples, which helps me to understand what is going on.

The comment form the Vendor MikroC is that their compiler do not have routines like _DSB() which therefore causes the compiler to message that there are Undeclared Identifiers. Sorry for that “they seem to be declared�.

[frankmeyer9]

Posted on September 04, 2014 at 13:56

The comment form the Vendor MikroC is that their compiler do not have routines like _DSB() which therefore causes the compiler to message that there are Undeclared Identifiers. Sorry for that “they seem to be declared�.

Those macros like

_DSB()

are found in the

core_xxx.h

files in the

.../Libraries/CMSIS/Include

folder, which should be seen in your project. If you look closely, you see that this files require the toolchain to be defined, as Keil, IAR and gcc have different ways to embed assembler instruction in C code. You can either try adapt this files for your toolchain (not recommended), go with the stuff that MicroC provides, or switch to another toolchain. If MicroC still comes with incompatibe and encrypted libraries, I would think hard before going that lock-in road ...