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 <m...@periphon.net> To: FPC developers' list <fpc-devel@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@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
_______________________________________________ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel