Am 09.08.2011 17:04, schrieb Jeppe Græsdal Johansen: > 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,
Yes. I think as well that everything should stick in the compiler. FPC is open source, so no need for a convolution of compiler support and external files. Full support of all devices will lead to a huge number of interwinded include files in the rtl anyways. > 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 Well, it can be done also by some sets like controllers_stellaris128flash64ram. I don't think that a big full fledged class hierary is needed. Even the case statement might be sufficient. _______________________________________________ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel