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...

  • What is the best way to port
    my way:
    compile with Keil
    read the errors
    find out what causes a frequent one of them
    use CodeWright to correct that one
    run again

    Erik

  • Yep, that's the way to do it... but this was a kind of attempt to save some working time :)

    Keil seems to have the CC2430 in their supported devices list so i wonder do they have an ported version about the Chipcons example files... The chipcon's "I/O" file for CC2430 also contains definitions for detecting the Keil compiler... and the error listing given by Keil is supprisingly small. I quess the real problems step in if i'm messing the Chipcons libraries (IAR Macros, interrupts etc) while porting the examples. As you may know it allways takes a bit more work to track down the errors from radio system...

    -Timo-

  • The chipcon's "I/O" file for CC2430 also contains definitions for detecting the Keil compiler...

    I quess the real problems step in if i'm messing the Chipcons libraries (IAR Macros, interrupts etc) while porting the examples.


    have you tried to contact Chipcon about this? the fact that there is such a switch seems to indicate that they want to match with Keil.
    If the "Chipcons libraries" gives problems, they may have a Keil version or be willing to let you have the source.

    Erik

  • 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!

  • I have contacted Chipcons support twice and at the second time i got the honest answer:

    Application examples for the new generation of Chipcon RF chips (CC2430,CC2510 and CC1110) are written for use with the IAR tool chain only. Support for Keil on these products is unfortunatley not provided.

    You may still of course port the examples to Keil but there is no Keil debugging environment for the new generation of chips.


    So thats it, have to start working...

    -Timo

  • 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