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