Re: [fpc-devel] Stellaris Update
On 16 Aug 2011, at 04:39, John Clymer wrote:
So, after some work, I have a compiler working for the LM3S8962 board (a
successful Blinking LED :-) )
However, as I was going through some of the various datasheets, I see that
all the Stellaris controllers have similar memory maps. That is:
A) Each type of device has a specific spot in the memory map to sit at.
B) If a device has less or no device of a given type, that memory map is
Reserved
C) The SRAM and FLASH memories always start at the same address
As such, I'm leaning towards:
{$FLASH_START x}
{$FLASH_SIZE x }
{$SRAM_START x }
{$SRAM_SIZE x }
By doing this, only 1 config will work for all stellaris parts (as was
originally laid out in the cpuinfo file.)
I'm also looking to do a survey of all STM32 devices to see if a similar
situation exists. I think, for all Cortex M3 devices of a particular
manufacturer, a similar scheme can be used. The M3 specs make requirements
that limit the flexibility to come up with oddball memory layouts.
It is clear from the ARM cortex m3 tech ref manual that all derivatives (all
manufacturers) have internal code starting at $ and ram starting at
$2000, so only two parameters are required for all possible cortex m3
parts, written either as ram top, flash top, or ram size, flash size.
Geoffrey
John Clymer
___
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
Re: [fpc-devel] Stellaris Update
Am 16.08.2011 05:39, schrieb John Clymer:
So, after some work, I have a compiler working for the LM3S8962 board (a
successful Blinking LED :-) )
However, as I was going through some of the various datasheets, I see
that all the Stellaris controllers have similar memory maps. That is:
A) Each type of device has a specific spot in the memory map to sit at.
B) If a device has less or no device of a given type, that memory map is
Reserved
C) The SRAM and FLASH memories always start at the same address
So why would the directives be needed?
As such, I'm leaning towards:
{$FLASH_START x}
{$FLASH_SIZE x }
{$SRAM_START x }
{$SRAM_SIZE x }
By doing this, only 1 config will work for all stellaris parts (as was
originally laid out in the cpuinfo file.)
What config? Memory layout in the compiler? Even without the directives
mentioned above, mulitple stellaris controllers can share the same
memory layout config in t_embedded?
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Stellaris Update
One of my current fixes i have in place allows using the PPCCROSSARM compiler
to compile Pascal to Assembly. Once in Assembly, the files can be assembled
and
linked like any other program. So, you have the capability to do just about an
exotic configuration you want - you just have to do so via assembly rather than
straight to object code. (If I've missed a way to go directly to an object file
from a pascal file - I'd be very happy - I didn't see any command line switches
to compile and generate .o files.)
To accommodate the compile to assembly option was only a 2 line change to
t_embed.pas.
However, I also agree with the sentiment that the compiler should be
downloadable and able to produce a binary for people not accustomed to command
lines, makefiles, etc. To that end, and to 90% of most conceivable cases, the
{$FLASH_START}, etc [with some sane defaults] mechanism provides enough power
to
accommodate most of the compilers potential users.
John
From: DaWorm daw...@gmail.com
To: FPC developers' list fpc-devel@lists.freepascal.org
Sent: Tue, August 16, 2011 8:49:51 AM
Subject: Re: [fpc-devel] Stellaris Update
STM32F103 and other ST Micro M3 parts have the ability to remap the vector
table. You can create applications to start anywhere in memory, and use a
bootloader to remap the table and jump to the new power up vector. In IAR C
this is handled in the linker config file. Someone on the list thought it
better not to go that route. However it is done, it should be done at an
individual application level, not tied to the part.___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Stellaris Update
Stellaris ALWAYS has the Code starting at $:.
STM32's do something odd where the FLASH starts at $0800:, and the memory
between $: and $07FF: is mappable to either the FLASH or the
built-in boot loader. (Which throws a kink in the works.)
But, as far as the point of catching the 90% of possible uses - one could drop
down to strictly {$FLASH_SIZE} and {$SRAM_SIZE}.
The other option (unless one wants a gazzillion items on the case() statements
in t_embed.pas) - is to set them extremely large so they don't get exceeded.
However, the danger in that is if someone has an 8K part, and the program ends
up spilling over 8K - it won't get picked up.
Also started un-commenting some parts of rtl.cfg in the embedded folder. Is
there any desire to support more of the RTL than the minimum (i.e. have a
default stdin and stdout - so WriteLn, etc work via the serial port ?) Or is
the intent that embedded includes on the bare minimal RTL to bring the machine
up ?
Thanks,
John
From: Florian Klämpfl flor...@freepascal.org
To: FPC developers' list fpc-devel@lists.freepascal.org
Sent: Tue, August 16, 2011 12:35:03 PM
Subject: Re: [fpc-devel] Stellaris Update
Am 16.08.2011 05:39, schrieb John Clymer:
So, after some work, I have a compiler working for the LM3S8962 board (a
successful Blinking LED :-) )
However, as I was going through some of the various datasheets, I see
that all the Stellaris controllers have similar memory maps. That is:
A) Each type of device has a specific spot in the memory map to sit at.
B) If a device has less or no device of a given type, that memory map is
Reserved
C) The SRAM and FLASH memories always start at the same address
So why would the directives be needed?
As such, I'm leaning towards:
{$FLASH_START x}
{$FLASH_SIZE x }
{$SRAM_START x }
{$SRAM_SIZE x }
By doing this, only 1 config will work for all stellaris parts (as was
originally laid out in the cpuinfo file.)
What config? Memory layout in the compiler? Even without the directives
mentioned above, mulitple stellaris controllers can share the same
memory layout config in t_embedded?
___
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
Re: [fpc-devel] Stellaris Update
Sorry, missed the second set of questions
I was able to get the stellaris part setup in t_embed.pas and cpuinfo.pas, then
I got build errors when I build an executable - it was missing the Controller's
startup file - these are in rtl\embedded\arm. Once FPC finishes compiling the
program, it wants to link with a unit with the same name as the Controller.
So,
if each controller gets supported separately, then that folder is going to be
chock full of controller specific startup files - most of which will be
duplicates inside the same family.
Unless I'm missing something, in order to get a binary for the LM3S8962, using
that specific controller as the target, I had to have a file in that folder
with
that same name - and with the unit inside named the same as the microcontroller.
John
From: Florian Klämpfl flor...@freepascal.org
To: FPC developers' list fpc-devel@lists.freepascal.org
Sent: Tue, August 16, 2011 12:35:03 PM
Subject: Re: [fpc-devel] Stellaris Update
Am 16.08.2011 05:39, schrieb John Clymer:
So, after some work, I have a compiler working for the LM3S8962 board (a
successful Blinking LED :-) )
However, as I was going through some of the various datasheets, I see
that all the Stellaris controllers have similar memory maps. That is:
A) Each type of device has a specific spot in the memory map to sit at.
B) If a device has less or no device of a given type, that memory map is
Reserved
C) The SRAM and FLASH memories always start at the same address
So why would the directives be needed?
As such, I'm leaning towards:
{$FLASH_START x}
{$FLASH_SIZE x }
{$SRAM_START x }
{$SRAM_SIZE x }
By doing this, only 1 config will work for all stellaris parts (as was
originally laid out in the cpuinfo file.)
What config? Memory layout in the compiler? Even without the directives
mentioned above, mulitple stellaris controllers can share the same
memory layout config in t_embedded?
___
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
Re: [fpc-devel] Stellaris Update
On 16 Aug 2011, at 11:16, John Clymer wrote:
Stellaris ALWAYS has the Code starting at $:.
STM32's do something odd where the FLASH starts at $0800:, and the memory
between $: and $07FF: is mappable to either the FLASH or the
built-in boot loader. (Which throws a kink in the works.)
But, as far as the point of catching the 90% of possible uses - one could
drop down to strictly {$FLASH_SIZE} and {$SRAM_SIZE}.
The other option (unless one wants a gazzillion items on the case()
statements in t_embed.pas) - is to set them extremely large so they don't get
exceeded. However, the danger in that is if someone has an 8K part, and the
program ends up spilling over 8K - it won't get picked up.
Also started un-commenting some parts of rtl.cfg in the embedded folder. Is
there any desire to support more of the RTL than the minimum (i.e. have a
default stdin and stdout - so WriteLn, etc work via the serial port ?) Or is
the intent that embedded includes on the bare minimal RTL to bring the
machine up ?
In my case I was trying for the bare minimum, particularly as some of the
Stellaris parts have masked ROM ('Stellarisware') containing useful drivers for
various functions including USB and ethernet and these are easily called from
FPC. This saves flash code space.
Geoffrey
Thanks,
John
From: Florian Klämpfl flor...@freepascal.org
To: FPC developers' list fpc-devel@lists.freepascal.org
Sent: Tue, August 16, 2011 12:35:03 PM
Subject: Re: [fpc-devel] Stellaris Update
Am 16.08.2011 05:39, schrieb John Clymer:
So, after some work, I have a compiler working for the LM3S8962 board (a
successful Blinking LED :-) )
However, as I was going through some of the various datasheets, I see
that all the Stellaris controllers have similar memory maps. That is:
A) Each type of device has a specific spot in the memory map to sit at.
B) If a device has less or no device of a given type, that memory map is
Reserved
C) The SRAM and FLASH memories always start at the same address
So why would the directives be needed?
As such, I'm leaning towards:
{$FLASH_START x}
{$FLASH_SIZE x }
{$SRAM_START x }
{$SRAM_SIZE x }
By doing this, only 1 config will work for all stellaris parts (as was
originally laid out in the cpuinfo file.)
What config? Memory layout in the compiler? Even without the directives
mentioned above, mulitple stellaris controllers can share the same
memory layout config in t_embedded?
___
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
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Stellaris Update
Am 16.08.2011 12:24, schrieb John Clymer: Sorry, missed the second set of questions I was able to get the stellaris part setup in t_embed.pas and cpuinfo.pas, then I got build errors when I build an executable - it was missing the Controller's startup file - these are in rtl\embedded\arm. Once FPC finishes compiling the program, it wants to link with a unit with the same name as the Controller. So, if each controller gets supported separately, then that folder is going to be chock full of controller specific startup files - most of which will be duplicates inside the same family. This files are needed anyways to provide the declartions for hardware access. Common declarations/startup code can be easily placed in commonly used include files, and, see below. Unless I'm missing something, in order to get a binary for the LM3S8962, using that specific controller as the target, I had to have a file in that folder with that same name - and with the unit inside named the same as the microcontroller. This could be changed in the compiler, this is why we have controllerunitstr and it proved to work well for me when working with LPCs. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Stellaris Update
Am 16.08.2011 12:16, schrieb John Clymer:
Stellaris ALWAYS has the Code starting at $:.
STM32's do something odd where the FLASH starts at $0800:, and the
memory between $: and $07FF: is mappable to either the FLASH
or the built-in boot loader. (Which throws a kink in the works.)
But, as far as the point of catching the 90% of possible uses - one
could drop down to strictly {$FLASH_SIZE} and {$SRAM_SIZE}.
The other option (unless one wants a gazzillion items on the case()
statements in t_embed.pas) - is to set them extremely large so they
don't get exceeded. However, the danger in that is if someone has an 8K
part, and the program ends up spilling over 8K - it won't get picked up.
Also started un-commenting some parts of rtl.cfg in the embedded
folder. Is there any desire to support more of the RTL than the minimum
(i.e. have a default stdin and stdout - so WriteLn, etc work via the
serial port ?) Or is the intent that embedded includes on the bare
minimal RTL to bring the machine up ?
The idea is to have a minimum default. Users needing more can uncomment
the needed parts and recompile the rtl.
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Stellaris Update
Am 16.08.2011 12:16, schrieb John Clymer:
Stellaris ALWAYS has the Code starting at $:.
STM32's do something odd where the FLASH starts at $0800:, and the
memory between $: and $07FF: is mappable to either the FLASH
or the built-in boot loader. (Which throws a kink in the works.)
But, as far as the point of catching the 90% of possible uses - one
could drop down to strictly {$FLASH_SIZE} and {$SRAM_SIZE}.
The other option (unless one wants a gazzillion items on the case()
statements in t_embed.pas)
Better than some wrecked programs because somebody put a wrong
FLASH_SIZE/SRAM_SIZE somewhere. Pascal tries to prevent the user to
shoot himself into the foot. *_SIZE /*_START is a good possibility to
shoot oneself into the foot while if it is once put into the compiler,
it just works.
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Stellaris Update
I was missing something then ! Thanks. (It's usually the obvious things - staring me right in the face - that I miss) Given that one controller unit file can be re-used amongst multiple controllers, that leaves a giant case() statement - which I can live with. And, there is a 2 line patch to allow the compiler to compile to assembly - then use binutils to assemble and patch. This gives the flexibility to accommodate non-standard setups. Expecting to provide a patch set in about a week to include a huge number of stellaris parts support. John From: Florian Klämpfl flor...@freepascal.org To: FPC developers' list fpc-devel@lists.freepascal.org Sent: Tue, August 16, 2011 2:46:06 PM Subject: Re: [fpc-devel] Stellaris Update Am 16.08.2011 12:24, schrieb John Clymer: Sorry, missed the second set of questions I was able to get the stellaris part setup in t_embed.pas and cpuinfo.pas, then I got build errors when I build an executable - it was missing the Controller's startup file - these are in rtl\embedded\arm. Once FPC finishes compiling the program, it wants to link with a unit with the same name as the Controller. So, if each controller gets supported separately, then that folder is going to be chock full of controller specific startup files - most of which will be duplicates inside the same family. This files are needed anyways to provide the declartions for hardware access. Common declarations/startup code can be easily placed in commonly used include files, and, see below. Unless I'm missing something, in order to get a binary for the LM3S8962, using that specific controller as the target, I had to have a file in that folder with that same name - and with the unit inside named the same as the microcontroller. This could be changed in the compiler, this is why we have controllerunitstr and it proved to work well for me when working with LPCs. ___ 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
[fpc-devel] Stellaris Update
So, after some work, I have a compiler working for the LM3S8962 board (a
successful Blinking LED :-) )
However, as I was going through some of the various datasheets, I see that all
the Stellaris controllers have similar memory maps. That is:
A) Each type of device has a specific spot in the memory map to sit at.
B) If a device has less or no device of a given type, that memory map is
Reserved
C) The SRAM and FLASH memories always start at the same address
As such, I'm leaning towards:
{$FLASH_START x}
{$FLASH_SIZE x }
{$SRAM_START x }
{$SRAM_SIZE x }
By doing this, only 1 config will work for all stellaris parts (as was
originally laid out in the cpuinfo file.)
I'm also looking to do a survey of all STM32 devices to see if a similar
situation exists. I think, for all Cortex M3 devices of a particular
manufacturer, a similar scheme can be used. The M3 specs make requirements
that
limit the flexibility to come up with oddball memory layouts.
John Clymer
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Stellaris Update
STM32F103 and other ST Micro M3 parts have the ability to remap the vector table. You can create applications to start anywhere in memory, and use a bootloader to remap the table and jump to the new power up vector. In IAR C this is handled in the linker config file. Someone on the list thought it better not to go that route. However it is done, it should be done at an individual application level, not tied to the part. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
