• State Not Answered
  • Locked Locked
  • Replies 9 replies
  • Subscribers 22 subscribers
  • Views 1707 views
  • Users 0 members are here
Options
Related
How was your experience today?
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

Smart Linking

Sebastien MARSANNE

I am trying to make a SW developped with Metrowerks/Hiware on HC05 to work with 8051.
The SW currently needs around 60kb, is very modular and has many options and customizations depending on the customer requirement. In Metrowerks case, the linker has smart linking possibility:

The linker file is *.PRM and list the objects files to link.
If the object file is followed by a "+", all the functions, constant, variables will be placed and mapped in the MCU. (like KEIL)

If there is no "+", the linker will REMOVE automatically functions, rom strings, ram global variables AUTOMATICALLY. The linker tree dependencies can also manage constant function pointers.

Is there a way to do something similar and automatic in KEIL environment?

Otherwise, the cumbersome way is to wrap all C functions like this:

#ifdef My_Function
void My_Function(void)
{
...
}
#endif

And in the header file, comment out the function declaration.... making the source code less readable.

Ideas? Tricks?

Thanks!

Parents
  • 0 in reply to Drew Davis

    That sort of system is indeed the ultimate endpoint when many targets or versions share the same file. Either you break the file into separate .c's to get separate segments, or you put in #if's to selectively omit parts of the one .c file when you compile it.

    Either...
    The trick, as I see it, is to do both.

    Where a piece of code end up with 471 #ifdefs it is better to make two or more .c files, whereas when a 1000+ line file only has a few #ifdefs, that is the better solution. Another way to unclutter is, when you have a often repeated variance, to make that a macro and example:

    you have two different versions of a board, one with a 1232 type supervisor, the other using the internal supervisor.

    You will then see, all over your code

    #ifdef VER1
PORT12 = TRUE;
PORT12 = FALSE;
#else
WDSFR = 0xA5;
WDSFR = 0x5A:
#endif

Instead, move that to a macro
#define M_KICK_THE_DOG #ifdef VER1            PORT12 = TRUE;         PORT12 = FALSE;        #else                  WDSFR = 0xA5;          WDSFR = 0x5A:          #endif

and the abibe sequence becomes
M_KICK_THE_DOG
no clutter

    When the above has been "macronized" your code will become moch less cluttered.

    Erik

Reply
  • 0 in reply to Drew Davis

    That sort of system is indeed the ultimate endpoint when many targets or versions share the same file. Either you break the file into separate .c's to get separate segments, or you put in #if's to selectively omit parts of the one .c file when you compile it.

    Either...
    The trick, as I see it, is to do both.

    Where a piece of code end up with 471 #ifdefs it is better to make two or more .c files, whereas when a 1000+ line file only has a few #ifdefs, that is the better solution. Another way to unclutter is, when you have a often repeated variance, to make that a macro and example:

    you have two different versions of a board, one with a 1232 type supervisor, the other using the internal supervisor.

    You will then see, all over your code

    #ifdef VER1
PORT12 = TRUE;
PORT12 = FALSE;
#else
WDSFR = 0xA5;
WDSFR = 0x5A:
#endif

Instead, move that to a macro
#define M_KICK_THE_DOG #ifdef VER1            PORT12 = TRUE;         PORT12 = FALSE;        #else                  WDSFR = 0xA5;          WDSFR = 0x5A:          #endif

and the abibe sequence becomes
M_KICK_THE_DOG
no clutter

    When the above has been "macronized" your code will become moch less cluttered.

    Erik

Children