2008-09-25 06:57 PM
header files revisited
2011-05-17 03:45 AM
Dear STOne-32
I am asking again if it is possible to release to the public the single header definition file for STM32 microcontrollers. It is probably the only micro on the market missing it. There are bits and pieces in FWLIB all over the places, making it difficult to understand and debug. I know, that your software guys are the best in the world, but I don't understand why they're so strongly opposed to releasing the register definition file. I can create one myself, but was hoping to save my time and avoid mistakes. below is an example from ADC examples in FWLIB in main.c you have /* Private typedef -----------------------------------------------------------*/ /* Private define ------------------------------------------------------------*/ #define ADC1_DR_Address ((u32)0x4001244C) #define ADC3_DR_Address ((u32)0x40013C4C) Now you know, what I mean. Thanks for your support. Jan2011-05-17 03:45 AM
Quote:
There are bits and pieces in FWLIB all over the places, making it difficult to understand and debug.
That's a matter of opinion, isn't it?Quote:
I know, that your software guys are the best in the world, but I don't understand why they're so strongly opposed to releasing the register definition file.
Presumably, they think that the way they've done it in the FWLib is perfectly adequate...?2011-05-17 03:45 AM
It would be nice to maintain such a file in a sourceforge project under a permissive license.
Part of the work was already done: I would also split the Cortex-M3 generic definitions (the NVIC as example) from the STM32 specific ones. regards, Giovanni --- ChibiOS/RT2011-05-17 03:45 AM
On the Rowley Crossworks there are a header, I haven´t used, but it seems complete. The examples of ''STM32F10x-EVAL Board Support Package'' use this header. Of course you have to check the Crossworks license.
It would be nice if ST offer their own header.2011-05-17 03:45 AM
Quote:
I would also split the Cortex-M3 generic definitions (the NVIC as example) from the STM32 specific ones.
There's the rub: the OP's premise is that he finds any partitioning ''difficult to understand and debug'' - hence he wants it all in one, big amorphous file. Personally, I find one, big amorphous file ''difficult to understand and debug'' - and I prefer to have it partinioned! Clearly, you can't please everyone; and ST have chosen to go with the partitioned approach - for whatever reason(s).2011-05-17 03:45 AM
There are different people and different (programming) styles.
I'm happy for you, that you have what you like (fragmented headers) I'm gratefull for what is available, however there are cases where the firmware library approach is not the best option. I like a simple header files (or a small number of them), so using either library or freestanding code would be possible. I think I am not the only one with a similar approach. As there is no hope for an easy way, need to go for a difficult way. Thanks everyone for reading. Jan2011-05-17 03:45 AM
Quote:
Personally, I find one, big amorphous file ''difficult to understand and debug'' - and I prefer to have it partinioned! One particular issue with the firmware library is that some of the definitions are in .c files, and others are in .h files. Also, the naming convention is inconsistent, and does not always match the bit names used in the manual. I like Freescale's approach: a set of .h files, one for each module, all #included together in one ''master'' .h for each model of chip, plus one .c file to specify the addresses of the register blocks. Steve. PS: There's a related discussion inhttp://www.st.com/mcu/modules.php?mop=modload&name=Splatt_Forums&file=viewtopic&topic=6434&forum=23
.2011-05-17 03:45 AM
Hi all,
I'm pleased to announce you that we have released a new FW Library version 2.0.3 that adds and extends support for header files where a description of all registers and bit definitions are provided in a file called ''stm32f10x_map.h''. To download the Library please clickhttp://www.st.com/stonline/products/support/micro/files/um0427.zip
. Enjoy it ! and thank you for all you queries. ( Here attached as well) Cheers, STOne-32. :)2011-05-17 03:45 AM
Jan - absolutely! You're not alone.
As mentioned in the other thread, I've also decided not to use the firmware library. [RANT] While I welcome the idea of ST producing a library which abstracts away the details of a chip, for the benefit of new users, and to make it simpler to get applications up and running, my issue with this particular library is that it doesn't actually do this! For the most part, the data passed to the library functions merely replicates the contents of the registers. Though the firmware documentation describes this to an extent, making full use of the features still requires using the chip's reference manual. This actually increases the work involved, as you need to then look at the library source code to see which registers it's accessing, which negates the point of having such a library in the first place! In addition, when debugging (with the Keil tool, at least), you're presented with the registers, again requiring detailed, low-level, knowledge. To summarise: for newcomers, or for those who want to produce something quickly, the firmware library is great. For everyone else, we need proper headers! [/RANT] Steve.