[fpc-devel] Arm Thumb2 - Stellaris status

Sat Aug 20 11:36:38 CEST 2011

For the cortex-m3 parts, one standard run-time is sufficient for all cortex 
parts, as their core systems are defined enough to get into a main pascal 
routine with the same code.

I'm specifically looking at Stellaris right now, specifically the Fury line of 
controllers, which is the largest line thus far.

However, in reviewing the Stellaris lineup - ALL Stellaris parts have their 
peripherals mapped out at exactly the same locations.  Which means that 1 
peripheral / register definition file could be used for all Stellaris parts.  
The confusion on this would be that symbols would exist for peripherals that 
might not exist for a specifically chosen part.  I'm just peeking around at 
other vendor's product lines to see how much work would be involved - and also 
trying to make things as generic as possible for re-use.

There are 180+ Stellaris parts currently active, of which 79 are Fury class 
parts.  Of the Fury class parts, there are 8 possible combinations of FLASH and 
SRAM amounts.  I'm looking to put all 79 parts into the table of controllers, 
HOWEVER, each part will reference a unit specific the same controller unit 
file.  I'm looking to change cpuinfo.pas to a structure, and part of that 
structure will be the FLASH and SRAM configurations, so that t_embed.pas won't 
even need a gazillion case() statements to generate the link info.

Once done with Fury class, I would move on to STM32 - as I have those available 
for ready use as well.

When STM32 and part of Stellaris have been created, a good framework should be 
in place to more easily add more vendors and/or parts.

________________________________
From: David Welch <dwelch at dwelch.com>
To: FPC developers' list <fpc-devel at lists.freepascal.org>
Sent: Sat, August 20, 2011 12:01:14 PM
Subject: Re: [fpc-devel] Arm Thumb2 - Stellaris status

Just jumping in here and maybe it was discussed but the cortex-m3 appears to 
have been designed so that if you match the arm abi you can put the address of 
handlers directly in the vector table and not have to trampoline off of a 
wrapper function.  basically 8 well chosen register are put on the stack so you 
dont have to preserve them, so that the handler has the look and feel of a 
standard function and not the look and feel of an interrupt handler.

I would not mix all cortex-m3 based devices into one definition.

Perhaps lumping all the stellaris parts into one but that would still get huge.  
Maybe all the 800 series in one, all the 1000 series in another, and so on.  
That is the way the vendors tend to manage information for their parts, and it 
makes sense as a sub-set of a larger family is very closely related and easier 
to manage the subtle differences.

Is it your intention to get all of the stellaris parts into this project all at 
once?  Or build some framework, add one or a few parts from each family and then 
over the course of time add a part or two here and there?

I would start with one family 800 series or 1000 series, one of the more simpler 
ones, and try to capture that series. If one series of parts is too bulky or 
complicated that is your answer, you may need to isolate each part by itself.

I would not try to cross vendors to the stm or lpc/nxp cortex-m3 or cortex-m0 
parts etc.  the memory maps and peripherals across vendors are too different.  
boot strategies, flash programming, etc.  I suspect everyone using an arm7 in a 
controller now will be using one of the cortex-m cores before long if they are 
not already.  Is it st or lpc that has both cortex-m3 and cortex-m0 based parts 
now?  I would have to look up the difference but know I bought/saw both at some 
point.

David

On 08/20/2011 02:20 AM, John Clymer wrote:
> Also, just peeked at current line up of STM32 controllers, there are 150
> different controllers available, consisting of 33 possible combinations
> of FLASH memory and SRAM size.
> 
> I will try to get the controller specific parts boiled up into record
> structures this weekend, and get some added controllers installed into
> cpuinfo.pas. (And fix any compiler breakages from the change.) I have
> the SVN download - so generated diffs should be a bit easier (still
> learning SVN though...)
> 
> Also, I read through the ARM docs regarding the "standard" library - and
> can setup registers based on the each vendors published "C" library so
> they match the ARM/vendor docs. However, as each controller in the
> line-up has only certain peripherals, is it the intention that EACH
> controller gets it's own controller file with memory definitions for
> peripherals ? That's 300+ unit files between STM32 and TI's Stellaris
> line-ups.
> 
> OR - does one try to merge as many controllers into 1 memory definition
> as possible. i.e. ALL of stellaris could be defined for the maximal
> configuration of peripherals (as they have a standard mapping layout for
> peripherals i.e. ALL LM3 devices have UART0 at the exact same location -
> and all have the same register layout.) The caveat to this that one
> could compile code that won't actually run on a given device.
> 
> OR - we could leave the peripheral definitions to the user. (Which I'm
> assuming is not the preferred route.)
> 
> John
> 
> ------------------------------------------------------------------------
> *From:* Florian Klämpfl <florian at freepascal.org>
> *To:* FPC developers' list <fpc-devel at lists.freepascal.org>
> *Sent:* Fri, August 19, 2011 12:19:05 PM
> *Subject:* Re: [fpc-devel] Arm Thumb2 - Stellaris status
> 
> Am 19.08.2011 05:28, schrieb John Clymer:
>  > 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.)
> 
> Maybe it's indeed better to have an array of records, each record
> describing one controller.
> 
>  >
>  > 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.
> 
> Well, isn't it for a user easier just to pass the controller he uses on
> the command line and the compiler does the rest? Why bother with
> addional uses etc. if the compiler knows already anything?
> _______________________________________________
> fpc-devel maillist - fpc-devel at lists.freepascal.org
> <mailto:fpc-devel at lists.freepascal.org>
> http://lists.freepascal.org/mailman/listinfo/fpc-devel
> 
> 
> 
> _______________________________________________
> fpc-devel maillist  -  fpc-devel at lists.freepascal.org
> http://lists.freepascal.org/mailman/listinfo/fpc-devel

_______________________________________________
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/20110820/9d26235e/attachment.html>