Why comdef.h need for stm32f070xx ? not working!

Posted on November 22, 2016 at 13:36

Hi Hasan,

Could you please provide more details on your case? Which KEIL version are you using ?

Have you an Error message when use comdef.h ?

You can ask ARM support, maybe they can help you on this.

Regards

Posted on November 22, 2016 at 17:51

Does it depends on compiler ?

No, it depends mainly on your code and its dependency on the Defines, TypeDefs and Macros that this include file provides. Frequently developers have specific coding styles and rules. If you mash together code from different places, and inconsistent style and conflicting definitions, you are going to have to resolve those.

The HAL and SPL have their own include files defining what they need.

C has things like stdlib.h, stddef.h and ctypes.h, Microsoft has windows.h

Posted on November 23, 2016 at 02:17

Dear Sir Clive1,

Many thanks returns to you!

'' If you mash together code from different places, and inconsistent style and conflicting definitions, you are going to have to resolve those.''

Its true that I have added some user code files from Coocox, some of them are state files and some of are utilities.

If you take a look the condef.h file, some buffer unit  for data is clearly defined 

ypedef  unsigned char      boolean;        /* Boolean value type. */

typedef  unsigned int       uint32;      /* Unsigned 32 bit value */

typedef  unsigned short     uint16;      /* Unsigned 16 bit value */

typedef  unsigned char      uint8;       /* Unsigned 8  bit value */

typedef  signed int         int32;       /* Signed 32 bit value */

typedef  signed short       int16;       /* Signed 16 bit value */

typedef  signed char        int8;        /* Signed 8  bit value */

typedef  float              FP32;        /* Single precision floating point */

typedef  double             FP64;        /* Double precision floating point */

typedef  unsigned char      bool;        /* Boolean value type. */

//typedef  unsigned int       uint32_t;      /* Unsigned 32 bit value */

//typedef  unsigned short     uint16_t;      /* Unsigned 16 bit value */

//typedef  unsigned char      uint8_t;       /* Unsigned 8  bit value */

//typedef  signed int         int32_t;       /* Signed 32 bit value */

//typedef  signed short       int16_t;       /* Signed 16 bit value */

//typedef  signed char        int8_t;        /* Signed 8  bit value */

Some other file described local macros and variables  in this way,

LOCAL MACROS

==================================================================================================*/

#define HEATER_1_ON HAL_GPIO_WritePin(TRIAC_CON1_GPIO_Port, TRIAC_CON1_Pin, GPIO_PIN_SET)

#define HEATER_1_OFF HAL_GPIO_WritePin(TRIAC_CON1_GPIO_Port, TRIAC_CON1_Pin, GPIO_PIN_RESET)

#define HEATER_2_ON HAL_GPIO_WritePin(TRIAC_CON2_GPIO_Port, TRIAC_CON2_Pin, GPIO_PIN_SET)

#define HEATER_2_OFF HAL_GPIO_WritePin(TRIAC_CON2_GPIO_Port, TRIAC_CON2_Pin, GPIO_PIN_RESET)

/*==================================================================================================

 LOCAL VARIABLES

==================================================================================================*/

static uint32       buzzer_count=0;

static uint32       heater_on_count=0;

static bool         alarm_onoffState=TRUE;

static bool buzzer_status=FALSE;

static double prev_err=0, I_err=0, D_err=0; 

 Macros are defined with reference to HAL.

You have nicely explain those stuff, I understand.

Now what can we do to adapt these files in Keil?

State files and some of are utilities are written in @version v1.0, I dont know how they did!

Do you think, I should make state files using QT or other supporting C/C++ environment?

Regards

Hasan

Posted on November 25, 2016 at 16:15

You need to focus on the dependencies in your own project, rather than think of it a Keil vs CooCox. The different chains provide slightly different system include files, but issue with typedef is one of having inconsistent coding styles throughout your source code base. The comdef.h here is adding some types while not redefining ones defined elsewhere.

You might need to refactor things to make them cleaner and more consistent, not because Keil is different form CooCox, but because the code isn't particularly clean and portable.

Take a step back and review the code base, use static analysis or syntax checking tools, if those help. I'd recommend tools like Understand C++/C

Posted on November 28, 2016 at 05:37

''You need to focus on the dependencies in your own project, rather than think of it a Keil vs CooCox.'' 

 

Well said, I was trying both to understand where is the fault point. Keil is straight one!

''The comdef.h here is adding some types while not redefining ones defined elsewhere.''

I also believe it, but where should I define them? where it would be ?

Other state files include comdef.h by #include.

Another issue, following example code in Keil, I have kept things same (HAL library,inc,CMSIS) in include path, but if I add state files in includes, error out puts says, ../Drivers/STM32F0xx_HAL_Driver/Inc/stm32f0xx_hal_rcc_ex.h(2051): error:  #20: identifier ''HAL_StatusTypeDef'' is undefined

 

 

''use static analysis or syntax checking tools''

Kindly explain in detail as you are a  proficient user.