[fpc-devel] Arm Thumb2 - Stellaris status

[John Clymer]

Did an analysis of the Stellaris current product lineup, there are over 180 
current Stellaris products on TI's selection guide.  Boiling through the FLASH 
and RAM availability, there are 31 unique configuratios of FLASH / SRAM between 
those 180 devices.  So, the case() statements in t_embed.pas will have 31 more 
entries to completely support the entire line of Stellaris processors (and a few 
more with products slated for future release).

Currently, everything is in a handful of giant arrays.  Just wondering if it 
would be better to switch to a record structure for the controller entries - 
rather than individual arrays.  (Add in a variety of STM parts and the other 
manufacturers, and there could easily be over 100 memory configurations in the 
table.)


Looking at RTL support.  Currently for each ARM variant, they have a contoller 
unit (the controllerunitstr entry).  Inside the current controller units, 
registers are defined.  These registers definitions "automatically" become part 
of the variable space of an application.  Is the intent for ALL controller 
registers be provided inside the RTL ?  I would think this would be better 
provided by outside files.  (i.e.  "uses LM3S8962" - brings in a file containing 
all the 8962 register definitions.)  


Having an outside file (it would be akin to a C header file - interface only 
specifications for the registers, and that would be it) would be much clearer 
than hiding the details inside a "hidden" file.  If the user wants to chase down 
exactly where the definition is coming from, using a non-RTL file saves the user 
from having to dig through the compiler source to determine where it was coming 
from.  (Although for a newb, it may be preferable to have them automatigically 
available.)

My suggestion would be that the register definitions come in an UNIT file that 
only defines registers.  The controller unit in the compiler source would only 
provide the bare minimum necessary to bring the system up and call PASCALMAIN.  
However, if it is deemed better to have the entire register set defined inside 
the RTL - that would be fine too.

John




________________________________
From: Florian Klämpfl <florian at freepascal.org>
To: FPC developers' list <fpc-devel at lists.freepascal.org>
Sent: Tue, August 9, 2011 7:59:06 PM
Subject: Re: [fpc-devel] Arm Thumb2 - Stellaris status

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 at lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.freepascal.org/pipermail/fpc-devel/attachments/20110818/bdd40e9f/attachment.html>