cancel
Showing results for 
Search instead for 
Did you mean: 

Function Prototypes in Std Periph Library (V3.3.0)

bengriffiths9
Associate II
Posted on August 04, 2010 at 12:45

Function Prototypes in Std Periph Library (V3.3.0)

11 REPLIES 11
swhite2
Associate III
Posted on May 17, 2011 at 14:00

Have you specified all the .h file paths in the IDE? I'm using v3.3.0 with EWARM 5.xx without issues.

bengriffiths9
Associate II
Posted on May 17, 2011 at 14:00

>> Have you specified all the .h file paths in the IDE?

I don't quite follow what you mean by this. I have (double checked) added the additional include directories in the project.

E.g. $PROJ_DIR$\CM3\CoreSupport

core_cm3.h has been added to the project.

As far as I can see it - ''core_cm3.c'' doesn't include ''core_cm3.h'' and I can't find anywhere where the prototype for (e.g.) __WFI() is given/defined.

>> I'm using v3.3.0 with EWARM 5.xx without issues.

That's good - that gives me hope that it's something I've doen (or not done) that's causing the problem - rather than a problem with the library.

Do you have the ''Require Prototypes'' option ticked?

swhite2
Associate III
Posted on May 17, 2011 at 14:00

Yes, I have the ''Require Prototypes'' option ticked.

I don't know where you put the library files and therefore don't know if

$PROJ_DIR$\CM3\CoreSupport

is correct. The point is that you must tell the compiler where all the headers are located. From memory there's three different paths in v3.3.0. Of course you have to do the same for your .h files as well.

FYI $PROJ_DIR$ is the folder where the .ewp (IAR project settings file) is located.

Finally you only need to include the stm32f10x.h header for everything to work. That said you must also define USE_STDPERIPH_DRIVER so that it includes everything else.

bengriffiths9
Associate II
Posted on May 17, 2011 at 14:00

It appears to me that core_cm3.c does not include core_cm3.c so the source file can't see it's prototypes.

Hence the compiler is not happy because when it attempts to compile core_cm3.c it can't see/find the prototypes.
chikos332
Associate II
Posted on May 17, 2011 at 14:00

Hi,

The #include ''core_cm3.h'' is located into the file '' \CMSIS\CM3\DeviceSupport\ST\STM32F10x\stm32f10x.h''

so what you need is to include this file into your project files (into you main) and to add this path to the project configuration:

$PROJ_DIR$\..\..\.. .... ...\CMSIS\CM3\DeviceSupport\ST\STM32F10x

(the number of ..\ depends on your own relative project path of course).

Cheers
chikos332
Associate II
Posted on May 17, 2011 at 14:00

Hi,

The prototypes of functions into core_cm3.c are declared into the same file (in core_cm3.c) and they are just declared as extern in the core_cm3.h in order to be called by other files ...

Note that int he template project provided by ST the option ''Require Prototypes'' is disabled, so it may be the only way configuration goes right.

Now there are some solutions for that:

 - The simplest one is to go to the options of core_cm3.c file (right click on file in the project window), enable the option 'Override inherited settings' then disable the option 'Require prototypes' for this file. It will be effective only for the core_cm3.c file and your other project files won't be affected.

 - The second way is to comment the prototypes declarations into core_cm3.c and remove the 'extern' argument for the prototypes into core_cm3.h.

Cheers.

bengriffiths9
Associate II
Posted on May 17, 2011 at 14:00

Chikos,

Thanks for the response.

Your post got me to do a little digging. Interestingly you are correct - there are prototypes in core_cm3.c - but only when you're using the GCC compiler/tool-chain.

If you're using the IAR (& Presumably the Realview) tool chain, there are no prototypes.

Looks to me like ST/ARM have dropped a boob here!
mikeshanahan9
Associate II
Posted on May 17, 2011 at 14:00

Hi chikos,

I agree that your suggestion about editing core_cm3.c would work.

However, I thought that the whole point of libraries generally, and CMSIS in particular, was that we should leave them alone; otherwise they become non-standard? Of course, if we find what we think is a bug, then we should inform the library's owner via their defined reporting method...

Incidentally, an interesting paper reviewing ARM's CMSIS has been written by Niall Cooling of Feabhas Ltd (a UK embedded development training company) - see feabhas.com for a link. It was written in May 2010, and covers CMSIS V1.30 (the current version?).

On page 30, he notes that core_cm3.c does not include its own core_cm3.h, commenting that it's ''...not a big deal here, but certainly not good practice.''

In addition, as an aside, he notes that CMSIS uses anonymous unions, which, whilst arguably beneficial where they've used them, also happens to break MISRA-C:2004 rule 1.1 (only use C99 features), which ARM claim CMSIS adheres to!

As he concludes, ''...CMSIS has real promise, but there's still work to be done.''.

As a general point regarding ''requiring prototypes'', I also feel that this is good practice - it protects from inadvertent incorrect calls to functions. So it's a bit bad if a library requires us to turn off this feature (even if only for its files - it's another thing to remember to maintain across projects!).

Cheers.

chikos332
Associate II
Posted on May 17, 2011 at 14:00

Hi Mike,

Thanks for these relevant remarks 🙂

Yes you are right, a library is supposed to remain untouched and this issue should be reported to ARM guys in order to be fixed in future.

We're just looking for ''temporary'' solutions/workarrounds that allows us to go on development (we won't wait for a new release from ARM or ST, it would take months).

Well, I can't find the article/white paper of Niall Cooling but I thank you again for this clear and interesting post.

Cheers.