Posted on May 17, 2011 at 12:45Quote:
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''.
Thanks, this is really excellent news.
I downloaded the new fwlib, and went to my code where I had created a duplicate definition of CAN_TSR_TME0 (for example). Looking through the fwlib, I see in stm32f10x_map.h:
#define CAN_TSR_TME0 ((u32)0x04000000) /* Transmit Mailbox 0 Empty */
In stm32f10x_can.c, I see this:
#define TSR_TME0 ((u32)0x04000000) /* Transmit mailbox 0 empty */
stm32f10x_can.c includes stm32f10x_can.h, which includes stm32f10x_map.h. So the definition of CAN_TSR_TME0 from stm32f10x_map.h is available to stm32f10x_can.c, and yet, instead of simply removing CAN_TSR_TME0 from stm32f10x_can.c and using the definition from the header, instead someone renamed the definition in the .c to TSR_TME0, perhaps to avoid a conflict with the other #define.
There's obviously many reasons why that's a bad idea:
1) Duplicate definitions need to be maintained in parallel
2) Only the definition in stm32f10x_can.c is being tested by ST's fwlib example programs, so if the one in _map.h is wrong, it won't be noticed by anyone running the example apps.
3) Because stm32f10x_can.c has it's own definitions, a working example app won't tell you that everything necessary is in stm32f10x_map.h, in fact things could be missing. If they were all *only* in _map.h, a simple grep of ''#define'' in *.c would be able to show you no #defines in any .c, and hence no bit definitions in any .c, meaning they all must be in _map.h
I hate to look a gift horse in the mouth, and I realize it's rather obsessive-compulsive of me to complain when you're just giving people what they asked for, but I also look forward to a future release of fwlib that doesn't have duplicate #defines.
Thanks again,
Miles
