Posted on May 17, 2011 at 13:36The key to writing Portable code is to never use any feature that relies upon any specific tools, environment, or target hardware.
In practice, of course, this is impossible.
In practice, you need to make sure that you make no
direct use of any specific tool, environment, or target hardware features.
Instead, you must ''encapsulate'' all dependencies in easily isolated forms.
A prime example of this is the way that the ST Firmware Library
never uses the standard 'C' int, char, or other types; instead, it defines u8, s16, etc - thus it is not dependent on how a particular compiler implements the standard 'C' types.
Similarly, rather than coding reliance on any chip-specific features directly into all your code, you should provide generic ''drivers'' - so that only the ''drivers'' need to be changed to port the code to another chip.
eg, instead of accessing the SPI peripheral registers directly, provide generic functions like spi_write, spi_read, etc - then only the implementations of those functions need to be changed for a different chip!
Thus you would have an AVR-specific spi_read, spi_write etc for your AVR, and an STM32-specific spi_read, spi_write etc for your STM32 - and all the other code should just port unchanged!
If you haven't already written your AVR code in this portable manner - ie the whole code is full of dependencies on the AVR chip and the specific compiler, etc - then I suggest that you start by re-writing the AVR code to be portable.
Once you have portable code running on your AVR, it will be a lot easier to port it to the STM32.
