- check whether endianness of the compilers differs and adapt where needed.
- check the device specific header files for compiler specific syntax. Eventually include the file
> to allow using common header files. (see f.e. cc2510fx.h). - check whether the startup code contains the correct initialization (watchdog, peripherals).
- check whether the sizes of short, int, long match.
- check if some 16 or 32 bit hardware registers require a specific addressing order (least significant or most significant byte first) and adapt if needed (first and last relate to time and not to lower/upper memory location here, so this is not the same as endianness).
- check whether the keyword volatile is used where needed. The compilers might differ in their optimization characteristics (as different versions of the same compiler might also use more clever optimizations this is good idea anyway). See Common interrupt pitfall: variable not declared volatile.
- check that the compilers are not told to supress warnings.
- check and convert compiler specific extensions (interrupts, memory areas, pragmas etc.).
- check for differences in type promotion. Especially check for math operations on char or unsigned char variables. For the sake of C99 compatibility SDCC will probably promote these to int more often than other compilers. Eventually insert explicit casts to (char) or (unsigned char). Also check that the ~ operator is not used on bit variables, use the ! operator instead. See sections TIPS and Compatibility with previous versions.
- check the assembly code generated for interrupt routines (f.e. for calls to possibly non-reentrant library functions).
- check whether timing loops result in proper timing (or preferably consider a rewrite of the code with timer based delays instead).
- check for differences in printf parameters (some compilers push (va_arg) char variables as int others push them as char. See section Compatibility with previous versions).
- check the resulting memory map. Usage of different memory spaces: code, stack, data (for mcs51/ds390 additionally idata, pdata, xdata). Eventually check if unexpected library functions are included.
09 November 2006
Migrating from demo compilers to SDCC
I found these tips from SDCC manual pages and though that it should be useful. If you would like to migrate from a demo C Compiler with the limitation of code size, such as Keil C51 and Raisonance RIDE-51, to SDCC, please consider to port your present code to SDCC by following these instructions.
Subscribe to:
Post Comments (Atom)
2 comments:
You wrote "However, for the serious engineering projects, the SDCC may not be the solution. "
Without any support for a statement like this it sounds as if you are working for a serious engineering solution tool vendor...
I'm sorry about that unclear statement. Serious engineering is commercially use in my meaning. If you want to make money from your project you should buy the full version of the commercial compiler like Keil C.
Post a Comment