[fpc-devel] Arm Thumb2 - Stellaris status

[John Clymer]

So, consensus is to include the register definitions - then I will work on 
these.  To get all the possible register structures for all possible peripherals 
will take some time.  And naming conventions come into play as well.

I prefer having my device registers defined in structures.  Other people prefer 
non-structured "flat" definitions for the registers.

i.e.

PortA -> DDR
PortA -> PIN

vs.

DDRA
PINA

The current stellaris has a start for structures, unless there are objections, I 
would continue with these.

The actual names of the registers will be best to match the datasheet 
(otherwise, non-compiler writing / source reading people will need a manual [and 
somewhat lengthy one at that] to provide the correcting naming of each 
peripheral and register.)  BUT - there is no standard for what the peripheral 
structure instances should be named - so again, this would need to be documented 
if the target audience is people that won't be tearing the compiler apart.  [And 
again, more work...]

John




________________________________
From: Geoffrey Barton <mrb at periphon.net>
To: FPC developers' list <fpc-devel at lists.freepascal.org>
Sent: Fri, August 19, 2011 1:19:38 PM
Subject: Re: [fpc-devel] Arm Thumb2 - Stellaris status


On 19 Aug 2011, at 10:10, Florian Klämpfl wrote:

> Am 19.08.2011 11:07, schrieb Geoffrey Barton:
>> 
>> On 19 Aug 2011, at 09:55, Florian Klämpfl wrote:
>> 
>>> Am 19.08.2011 10:33, schrieb Geoffrey Barton:
>>>> 
>>>> because one is forever re-compiling the compiler when one
>>>> switches to a device with a new peripheral, and if your main
>>>> activity is not compiler development but product development one
>>>> has to go back and find out how to do it each time. Better that
>>>> the core stays the same.
>>> 
>>> This is true, it makes things maybe easier for the first
>>> implementor, he hacks together some units and directives but it is
>>> harder for any latter user. He basically needs to do the same
>>> amount of work as the initial implementator: find out that he needs
>>> some directive, find the correct units etc.
>> 
>> exactly so, IMHO! (and in my own experience).
>> 
>> If all he needs to add are a few peripheral definitions and drivers
>> and there have been provided some examples of structures which work
>> well in practice for these, a new user can be doing useful work very
>> quickly and contributing to the collective knowledge from day one.
> 
> What I mean is: if the first user of a controller does things properly
> (create startup and interface unit, extend t_embedded.pas), subsequent
> users of the same controller have much less work, they need only to pass
> the correct parameter to the compiler and not to fiddle with
> configuration files, directives etc. The compiler takes care of everything.

and I agree with you 100%.

as the 'first user' though I had other pressures on me, such as having to prove 
that using FPC on Stellaris was viable so that I could avoid being forced into 
writing in C. I therefore concentrated on the one device I had on the evm; maybe 
thats what everybody does. Then one looks for the time to tidy things up, or for 
someone else to come along wanting to go the same route and needing a 
jump-start.

_______________________________________________
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/20110819/14541fa4/attachment.html>