<html><head><style type="text/css"><!-- DIV {margin:0px;} --></style></head><body><div style="font-family:times new roman,new york,times,serif;font-size:12pt"><div>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.)<br><br>Haven't looked into possibly a compiler option (and may easily be more trouble than a command line option):<br>{$ARM_FLASH_START xxxxxxxx}<br>{$ARM_FLASH_LENGTH xxxxxxxx}<br></div><div style="font-family:times new roman, new york, times, serif;font-size:12pt">{$ARM_SRAM_START xxxxxxxx}<br>{$ARM_SRAM_LENGTH xxxxxxxx}<br><br>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.<br><br>John<br><br><div style="font-family:arial, helvetica,
sans-serif;font-size:10pt"><font face="Tahoma" size="2"><hr size="1"><b><span style="font-weight: bold;">From:</span></b> Pierre Free Pascal <pierre@freepascal.org><br><b><span style="font-weight: bold;">To:</span></b> FPC developers' list <fpc-devel@lists.freepascal.org><br><b><span style="font-weight: bold;">Sent:</span></b> Tue, August 9, 2011 1:00:53 PM<br><b><span style="font-weight: bold;">Subject:</span></b> RE: [fpc-devel] Arm Thumb2 - Stellaris status<br></font><br>
<br><br>> -----Message d'origine-----<br>> De : <a ymailto="mailto:fpc-devel-bounces@lists.freepascal.org" href="mailto:fpc-devel-bounces@lists.freepascal.org">fpc-devel-bounces@lists.freepascal.org</a> [mailto:fpc-devel-<br>> <a ymailto="mailto:bounces@lists.freepascal.org" href="mailto:bounces@lists.freepascal.org">bounces@lists.freepascal.org</a>] De la part de Geoffrey Barton<br>> Envoyé : mardi 9 août 2011 10:20<br>> À : FPC developers' list<br>> Objet : Re: [fpc-devel] Arm Thumb2 - Stellaris status<br>> <br>> <br>> On 8 Aug 2011, at 21:13, Florian Klämpfl wrote:<br>> <br>> > Am 08.08.2011 12:49, schrieb John Clymer:<br>> >> Kicking it around in the back of my head at work today...<br>> >><br>> >> I tried doing a compile to assembly language for the stellaris - and it<br>> >> choked giving the error from t_embed.pas. The error comes from the<br>>
>> portion of the program trying to generate a linker script.<br>> >><br>> >> Looking at t_embed.pas, it looks like every single flavor of ARM<br>> >> controller will require it's own subsection of the case() statement.<br>> >> This can easily get long and ugly. As the only thing that changes<br>> >> between most of the arm variants is the memory layout - why not provide<br>> >> a generic "stellaris" switch - with reads in a text file containing the<br>> >> memory map and stack top (the rest of the link file remains the same<br>for<br>> >> all variants of ARM) ?<br>> >><br>> >> This way - switching to a new variant of stellaris only requires<br>> >> tweaking a memory map file - rather than a re-build and patch of<br>> >> t_embed.pas ? For that matter - entirely foreign Cortex M3 parts could<br>> >> be easily supported
without requiring changes to the compiler.<br>> >><br>> >> Just pondering how to make it easier and more flexible ...<br>> ><br>> > Yes, this can be done. However, somebody who knows enough about a<br>> > certain controller family must do this.<br>> <br>> What in your view is the best way to separate link options such as these<br>> variations in memory maps between devices? I often have several projects<br>at<br>> once and they can be using different parts within the same family; having<br>to<br>> re-compile the compiler when switching between projects is not ideal.<br><br><br> What about adding some command line options<br>similar to -WB:<br> -WB40000<br>sets the default load address of Windows PE executables<br>to 0x40000. Its value is stored in global variable ImageBase.<br><br>If only four or five values need to be set, we could just<br>implement option -WE option:<br>E for embedded,
<br>with <br> -WEFlashOriginHexDecimalValue<br> -WEFlashLengthHexDecimalValue<br> -WERamOriginHexDecimalValue<br> -WERamLengthHexDecimalValue<br> -WEStackTopHexDecimalValue<br><br>Of course, this depends if the list of required values is limited or not.<br>Another problem is if the script should include or not those<br>lines.<br> But here also, we could create a list of args,<br>some would be tagged as having a default value, which would be used<br>if no command line option is given, while other args would <br>have no default, meaning that the linker line would only be inserted<br>if the corresponding value are set at command line.<br> If that case, it might be better to combine Origin and Length into a<br>unique<br>argument<br> -WEFlashHexValueOfOrigin-HexValueOfLength<br>where HexValueOfOrigin and HexValueOfLength would both bereplaced by<br>the valid values in order to avoid having only Origin and no
Length for<br>Flash (or Ram, or anything else that would be needed).<br><br> Maybe a special 'custom' controller type would be handy for this...<br><br>Pierre Muller<br> <br><br><br>_______________________________________________<br>fpc-devel maillist - <a ymailto="mailto:fpc-devel@lists.freepascal.org" href="mailto:fpc-devel@lists.freepascal.org">fpc-devel@lists.freepascal.org</a><br><span><a target="_blank" href="http://lists.freepascal.org/mailman/listinfo/fpc-devel">http://lists.freepascal.org/mailman/listinfo/fpc-devel</a></span><br></div></div>
</div></body></html>