This discussion has been locked.
You can no longer post new replies to this discussion. If you have a question you can start a new discussion

Porting Chipcon's CC2430 examples to KEIL's 51 environment

Hi!

I would like to use KEIL's C51 tools for Chipcons CC2430 instead of IAR's buggy IDE... What is the best way to port the Chipcons example files (from their website) writen for IAR's EW? Has someone allready done this and is there a downloadable conversion available?
Chipcon's IAR deal seems to limit their support in this issue...

Parents
  • Most compilers have a "Strict ANSI" option to disable all compiler-specific extensions.

    If IAR has this, try turning it on - this should identify all the uses of IAR-specific extensions.

    Then look up all those extensions in the IAR manuals.

    Then look in the Keil manuals to find the corresponding Keil implementations.

    Then make #define macros, typedef's, etc, to encapsulate all the compiler specifics

    As you make changes, ensure that the code continues to build & work with the IAR tools!

Reply
  • Most compilers have a "Strict ANSI" option to disable all compiler-specific extensions.

    If IAR has this, try turning it on - this should identify all the uses of IAR-specific extensions.

    Then look up all those extensions in the IAR manuals.

    Then look in the Keil manuals to find the corresponding Keil implementations.

    Then make #define macros, typedef's, etc, to encapsulate all the compiler specifics

    As you make changes, ensure that the code continues to build & work with the IAR tools!

Children
  • The IAR EW has the "Stict ANSI" option that gives round 3500 errors (// commentings included...) and "Relaxed ANSI" option that disables only IAR Extensions and this one gives only round 950 errors...

    Anyway, due to the "I/O" file containig KEIL definitions compiling the libraries gives round 30 - 50 errors and some of them look like a piece of cake.

    As i said, i have to start working or buy the IAR-compiler :(

    Thanks...

  • The lesson to learn from this is:

    Always encapsulate your compiler-specifics in typedefs, #defines, etc...

  • Always encapsulate your compiler-specifics in typedefs, #defines, etc...

    OR

    have compiler-specifics, and only compiler-specifics in a separate .h file

    Erik

  • "OR

    have compiler-specifics, and only compiler-specifics in a separate .h file"


    That's not an "OR" - that's an "AND"!

    You'd put all the definitions in the .h file and then use them throughout the code...

    eg, never use the Keil keyword extension 'xdata' directly - always use it via an XDATA macro, or whatever...

  • OR - AND, now we are talking logic

    "my" logic stem from the fact that i once were exposed to the worst mess i have ever seen where every 3rd line was encased in an #ifdef to make compiling across compilers possible.

    Going by Andys suggestion (which I support with my caveat) as stated you could do as the - i ... naah person that did the above.

    eg, never use the Keil keyword extension 'xdata' directly - always use it via an XDATA macro
    I go a bit further totally avoiding "split" definitions as e.g. unsigned char defined this way

    #define U8    unsigned char
    #define S8    signed   char
    #define UI8   unsigned char   idata
    #define UX8   unsigned char   xdata
    #define UC8   unsigned char   code
                                                // pointer in data in
    #define U8DI  unsigned char   idata * data  // data       idata
    #define U8DX  unsigned char   xdata * data  // data       xdata
    #define U8IX  unsigned char   xdata * idata // idata      xdata
    #define U8XX  unsigned char   xdata * xdata // xdata      xdata
    #define U8IC  unsigned char   code  * idata // idata      code
    #define U8DC  unsigned char   code  * data  // data       code
    #define U8XC  unsigned char   code  * xdata // xdata      code
    #define U8CC  unsigned char   code  * code  // code       code 
    Erik