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 xxxxx}
{$FLASH_SIZE xxxxx }
{$SRAM_START xxxxx }
{$SRAM_SIZE xxxxx }

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

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.

It is clear from the ARM cortex m3 tech ref manual that all derivatives (all manufacturers) have internal code starting at $00000000 and ram starting at $20000000, 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

So why would the directives be needed?

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?

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

________________________________

Stellaris ALWAYS has the Code starting at $0000:0000.

STM32's do something odd where the FLASH starts at $0800:0000, and the memory between $0000:0000 and $07FF:FFFF 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

________________________________

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

________________________________

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

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.

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.

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.

The idea is to have a minimum default. Users needing more can uncomment the needed parts and recompile the rtl.

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

________________________________