On 09-08-2011 15:53, Geoffrey Barton wrote:
On 9 Aug 2011, at 14:14, John Clymer wrote:
I was thinking more of a generic controller class, including a
memory.def (or whatever one wants to name it) file. That would be
easiest as it would only effect the t_embed.pas file (and cpuinfo.pas
file to add the generic type.)
Haven't looked into possibly a compiler option (and may easily be
more trouble than a command line option):
{$ARM_FLASH_START xxxxxxxx}
{$ARM_FLASH_LENGTH xxxxxxxx}
{$ARM_SRAM_START xxxxxxxx}
{$ARM_SRAM_LENGTH xxxxxxxx}
But, I still think a static memory definition file would require the
least amount of code changes. And would only effect only the ARM
related files.
The compiler option works well when you have conditional options for
different target builds using ifdefs, which I do I lot. It makes it
very easy to see if it is in the source file as it can be locked to
other options and you only need to select it in one place.
A separate linker file starts to make FPC handle like any other
compiler :( instead of the joy to use it is :)
I agree. Keeping the configurations in code is easier to manage,
compared to the spiderweb of magically named files of other embedded
compilers
I think that maybe creating an abstract class hierachy of chip families,
instead of the current solution of a single large case statement, would
be a better solution in the long run
Geoffrey
_______________________________________________
fpc-devel maillist - [email protected]
http://lists.freepascal.org/mailman/listinfo/fpc-devel
