Attached is the re-vamped patch to add controller tables to AVR and ARM support. The compiler tree that this patch was grabbed from was tested in the embedded target with 3 CortexM3 devices, and 1 ARM7TDMI device (in native ARM mode.) [LM3S8962, LM3S2111, STM32F103RB and AT91SAM7S256] The program generated was a blinking LED program on 4 development boards.

Synopsis of changes:

1) rtl/embedded/arm - added files for lm3fury, lm3tempest [same file for now] AND thumb2bare.

2) compiler/<ARCH>/cpuinfo for ARM and AVR - include a common controllerunit definition from an include file

3) compiler/avr/cpuinfo for AVR - made changes to accommodate the new structure
- and nothing more
- tested compiler against svn checkout - both broke at same spot in compilation

4) compiler/arm/cpuinfo for ARM - changed to records vice arrays for cpu info. Added support for STM32F103RB, and a whole slew of Stellaris parts (not all, but quite a few)

5) compiler/system/t_embed.pas - removed static coded linker scripts on a per controller basis - switched to a master linker script that uses size information from controller table to generate linker information.

6) pmodules, globals, ncgutils, options files - changes to accommodate the switch to a record

7) added in root directory, sample buildarm.bat and buildthumb2.bat batch files
- to show necessary command line options to build a compiler (obviously, site requirements will change directories - but I think this will prove useful.)

NOTE: The thumb2_bare target - this is a bare bones, no frills thumb2 target. The generated vector table comprises ONLY the core processor faults. There is a 2K static array that gets used as the stack.

If there are no major objections or blatant errors I've missed, could someone post this to the repository - or give me some directions to do so.

Thanks,

John

John Clymer wrote

...

Does this only handle thumb issues or other differences of the instruction sets of different ARM versions as well ?

Especially I am concerned about the "atomic" options (that some ARMs provide e.g. LDREX / STREX instructions for).

-Michael

What does the topic say?

Especially I am concerned about the "atomic" options (that some ARMs provide e.g. LDREX / STREX instructions for).

If you are really concerned, you should finally start to create a patch.

Florian Klämpfl wrote

If you are really concerned, you should finally start to create a patch.

As I already said very often, I am concerned and trying to help, but right not in need of anything nor requesting anything to be done. This state might or might not change one day soon. Staying informed will help to do something more obviously useful at that point in time.

-Michael

John Clymer wrote

If there are no major objections or blatant errors I've missed, could someone post this to the repository - or give me some directions to do so.

Thanks for your work! I have committed your changes slightly modified to svn in rev. 18848. What I changed is basically the arm architecture handling: Building for arm-embedded now always requires to pass SUBARCH to make, e.g.
make all OS_TARGET=embedded CPU_TARGET=arm SUBARCH=cortexm3 Depending on SUBARCH, the right switches are passed to the compiler and only the fitting cpu interface units are built. If no SUBARCH is given, make will complain. It is on purpose, that no default is set, so people have really to choose a certain subarch.

cpuinfo.pas(156,2) Fatal: Can't open include file "controllerunit.inc"

Florian Klämpfl wrote

OS_TARGET=embedded CPU_TARGET=arm SUBARCH=cortexm3

Can someone with the power to update the wiki (maybe we all do I dont know) change the target embedded page to reflect the SUBARCH thing?

Also either put a link to

http://wiki.lazarus.freepascal.org/Binutils

or spell out something like this:

./configure --target=arm-linux --prefix=/something/something/ --program-prefix=arm-embedded- --disable-werror

For the non-windows folks so we can play too. Too me a while to figure out why I was not even able to build per the target embedded instructions.

Thanks,
David

David Welch wrote

cpuinfo.pas(156,2) Fatal: Can't open include file "controllerunit.inc" On 08/25/2011 05:50 PM, Florian Klämpfl wrote: > OS_TARGET=embedded CPU_TARGET=arm SUBARCH=cortexm3

You can modify the wiki yourself, you just need to register.

Felipe Monteiro de Carvalho

David Welch wrote

cpuinfo.pas(156,2) Fatal: Can't open include file "controllerunit.inc"

Fixed, I forgot to commit a file, sorry.

2011/8/26 Florian Klämpfl :

Part of what I submitted was 2 batch files in the root directory - buildarm.bat and buildthumb2.bat - that was my attempt to provide an example with the BINUTILS equates spelled out.

John

________________________________

need to apply this patch, like the wiki thing maybe there is a place I have to sign up to be able to check in to svn, otherwise. The lpc and sam7 parts are ARM7TDMI which is an armv4t not remotely able to support the armv7 instructions. the correction also needs to be made to allow armv7m or cortexm3. If we are going to mix the architecture (armv7m) and marketings name for the core (cortexm3) we should be consistent and start doing things like provide an arm7tdmi for the other two families. LIkewise anywhere it says if cortexm3 it should say if cortexm3 or armv7m then. if armv4 or if armv4t or if arm7tdmi then... Ideally not use the name cortexm3 and instead only use armv7m. Have a wiki page or readme that says if stellaris or stm32 or lpc1xxx then armv7m if lpc2xxx or sam7 or generic arm then armv4...

Index: rtl/embedded/Makefile
=================================================================== --- rtl/embedded/Makefile (revision 18854)
+++ rtl/embedded/Makefile (working copy)
@@ -317,7 +317,7 @@
ifeq ($(SUBARCH),cortexm3)
CPU_UNITS=lm3fury lm3tempest thumb2_bare stm32f103 endif
-ifeq ($(SUBARCH),armv7)
+ifeq ($(SUBARCH),armv4)
CPU_UNITS=lpc21x4 at91sam7x256
endif
endif

Another diff to be considered.

Index: rtl/embedded/arm/arm_bare_ram.pp
=================================================================== --- rtl/embedded/arm/arm_bare_ram.pp (revision 0)
+++ rtl/embedded/arm/arm_bare_ram.pp (revision 0)
@@ -0,0 +1,63 @@
+{
+Startup code for a simple ram-only ARM
+David Welch 2011 08 26 (dwelch at dwelch com)
+based on lpc21x4 created by Sten Larsson (sten_larsson at yahoo com) +}
+
+unit arm_bare_ram;
+
+{$goto on}
+
+ interface
+
+ implementation
+
+ procedure PASCALMAIN; external name 'PASCALMAIN'; +
+ procedure _FPC_haltproc; assembler; nostackframe; public name '_haltproc';
+ asm
+ .Lhalt:
+ b .Lhalt
+ end;
+
+ var
+ _stack_top: record end; external name '_stack_top';
+ _bss_start: record end; external name '_bss_start';
+ _bss_end: record end; external name '_bss_end'; +
+ procedure _FPC_start; assembler; nostackframe;
+ label
+ _start;
+ asm
+ .init
+ .align 16
+ .globl _start
+ _start:
+ ldr sp,.L_stack_top
+ // clear onboard ram
+ ldr r1,.L_bss_start
+ ldr r2,.L_bss_end
+ mov r0,#0
+.Lzeroloop:
+ cmp r1,r2
+ strls r0,[r1],#4
+ bls .Lzeroloop
+
+ bl PASCALMAIN
+ bl _FPC_haltproc
+ .L_hang:
+ b .L_hang
+.L_bss_start:
+ .long _bss_start
+.L_bss_end:
+ .long _bss_end
+
+
+
+.L_stack_top:
+ .long _stack_top
+ .text
+ end;
+
+end.
+
Index: rtl/embedded/Makefile.fpc
=================================================================== --- rtl/embedded/Makefile.fpc (revision 18855)
+++ rtl/embedded/Makefile.fpc (working copy)
@@ -53,7 +53,7 @@
endif

ifeq ($(SUBARCH),armv7)
-CPU_UNITS=lpc21x4 at91sam7x256
+CPU_UNITS=lpc21x4 at91sam7x256 arm_bare_ram
endif
endif

Index: rtl/embedded/Makefile
=================================================================== --- rtl/embedded/Makefile (revision 18855)
+++ rtl/embedded/Makefile (working copy)
@@ -317,8 +317,8 @@
ifeq ($(SUBARCH),cortexm3)
CPU_UNITS=lm3fury lm3tempest thumb2_bare stm32f103 endif
-ifeq ($(SUBARCH),armv7)
-CPU_UNITS=lpc21x4 at91sam7x256
+ifeq ($(SUBARCH),armv4)
+CPU_UNITS=lpc21x4 at91sam7x256 arm_bare_ram
endif
endif
ifeq ($(ARCH),avr)
Index: compiler/arm/cpuinfo.pas
=================================================================== --- compiler/arm/cpuinfo.pas (revision 18855)
+++ compiler/arm/cpuinfo.pas (working copy)
@@ -61,6 +61,8 @@
tcontrollertype =
(ct_none,

+ ct_arm_bare_ram,
+
{ Phillips }
ct_lpc2114,
ct_lpc2124,
@@ -212,7 +214,19 @@
sramsize:0
),

+
(
+ controllertypestr:'ARM_BARE_RAM';
+ controllerunitstr:'ARM_BARE_RAM';
+ interruptvectors:8;
+ flashbase:$00000000;
+ flashsize:$00000000;
+ srambase:$D6000000;
+ sramsize:$0000C000
+ ),
+
+
+ (

     	controllertypestr:'LPC2114';
         controllerunitstr:'LPC21x4';
         interruptvectors:8;

Index: compiler/systems/t_embed.pas
=================================================================== --- compiler/systems/t_embed.pas (revision 18855)
+++ compiler/systems/t_embed.pas (working copy)
@@ -220,6 +220,7 @@
ct_none:

            begin
            end;

+ ct_arm_bare_ram,
ct_lpc2114,
ct_lpc2124,
ct_lpc2194,
@@ -312,16 +313,19 @@

               Add('MEMORY');
               Add('{');

-              LinkStr := '    flash : ORIGIN = 0x' + IntToHex(flashbase,8)
-                + ', LENGTH = ' + IntToStr(flashsize div 1024)+'K';
-              Add(LinkStr);
+              if(flashsize0) then
+                begin
+                  LinkStr := '    flash : ORIGIN = 0x' + IntToHex(flashbase,8)
+                    + ', LENGTH = ' + IntToStr(flashsize div 1024)+'K';
+                  Add(LinkStr);
+                end;
               LinkStr := '    ram : ORIGIN = 0x' + IntToHex(srambase,8)
               	+ ', LENGTH = ' + IntToStr(sramsize div 1024)+'K';
               Add(LinkStr);
               Add('}');
-              Add('_stack_top = 0x' + IntToHex(sramsize+srambase-4,8) + ';');
+              Add('_stack_top = 0x' + IntToHex(sramsize+srambase,8) + ';');
             end;
         end
     else
@@ -329,6 +333,8 @@
       	 internalerror(200902011);
   end;
+
+  with embedded_controllers[current_settings.controllertype] do
   with linkres do
     begin
       Add('SECTIONS');
@@ -341,14 +347,28 @@
       Add('    *(.rodata, .rodata.*)');
       Add('    *(.comment)');
       Add('    _etext = .;');
-      Add('    } >flash');
+      if(flashsize0) then
+        begin
+          Add('    } >flash');
+        end
+      else
+        begin
+          Add('    } >ram');
+        end;
       Add('    .data :');
       Add('    {');
       Add('    _data = .;');
       Add('    *(.data, .data.*)');
       Add('    KEEP (*(.fpc .fpc.n_version .fpc.n_links))');
       Add('    _edata = .;');
-      Add('    } >ram AT >flash');
+      if(flashsize0) then
+        begin
+          Add('    } >ram AT >flash');
+        end
+      else
+        begin
+          Add('    } >ram');
+        end;
       Add('    .bss :');
       Add('    {');
       Add('    _bss_start = .;');
@@ -360,6 +380,7 @@
       Add('}');
       Add('_end = .;');
     end;
+
 {$endif ARM}
 {$ifdef i386}

when building for SUBARCH=cortexm3, fails with:

make[3]: *** No rule to make target `thumb2_bare.ppu', needed by `fpc_units'. Stop.

Crap ! Forgot to SVN ADD ...

File attached.

________________________________

John Clymer wrote

Crap ! Forgot to SVN ADD ... File attached.

Is there any use in having such generic controllers? What's the use case of them?

One case would be as a framework to build other targets instead of having to delete a bunch of stuff then add a bunch of stuff you just add stuff.

I have an interest in a generic target where the target specific stuff is not embedded in the compiler but is in the code. At the moment the memory address is still hardcoded but that is it it can easily be re-used countless times. More so if there were run time programmable addresses for the linker. It is not too hard to add a target every time I want to use fpc for something, it would be far easier if there were a set of generic targets so that at worst all I had to do was modify the memory addresses and not have to add a whole target. A memory only arm, a flash+memory arm, a memory only cortex-m3 and a flash+memory cortexm3. (yes can and have done a bootloader for a cortex-m3 loading programs into ram and running them needing a ram only link). I would recommend folks use the generic target and develop the target specific library code outside the compiler first avoiding having to rebuild the compiler and application during the development process, not that the compiler is a slow build, it is fast, but saving that complication

I assume this will settle down but if you look at just the last week, if you were trying to add an embedded target the framework keeps changing and you would have to keep starting over and over again if you were not ready to pull the trigger. with a generic target you could take your time developing your libraries, etc.

In short I am saying it saves time for the individuals trying to add targets.

David

David Welch wrote

In short I am saying it saves time for the individuals trying to add targets.

No, it saves no time in total and is against any OSS spirit: imagine ten people developing for say the lpc2148 (or any other not yet supported controller). All of them use the bare controller and hack the stuff together to get that unknown controller working and waste a lot of time with this.

Instead, the first one using a new controller does a proper set of patches, they are applied to FPC. The other nine save a lot of time by just using the already implemented lpc2148 target and might spent the saved time into other new stuff for FPC ;)

I assume I speak for others, but for those of us that have been working in the embedded field for a while, some of us prefer to roll our own support code, rather than rely on compiler supplied implementations. Personnally, I've used 6 different ARM/Thumb2 cored processors in various projects. I have NEVER used compiler or vendor provided library.

I prefer NOT to use them because they add overhead, complexity, and are often times innefficient.

I thought OSS was about freedom of choice. Mandating that end users follow a certain path removes their available choices.

As far as custom linker maps - if one uses the Generic "controller" and tells the compiler to compile to object code, but NOT link. Then one can provide their own linker script - with whatever crazy controller layout they desire.

________________________________

Well, this is not about libraries but startup code and declarations of hardware registers etc. which add no overhead.

I thought OSS was about freedom of choice.

Yes.

Mandating that end users follow a certain path removes their available choices.

If really needed, they can still downstrip an existing cpu unit and work with a customized compiler. This is something a commercial compiler does not allow .

This can be done with an existing cpu unit as well. After all, the code *must* run on a real device.

The bare ram arm and it's memory map just looks random.

Downside is that embedded users are condemned to use trunk and never a stable release. There are quite a lot of "bosses" around that only want to use stable releases in production.
Compiler patches or separate units, if one doesn't want to share code it won't make a difference.

My 2 cents,

Ludo

Ludo Brands wrote

Downside is that embedded users are condemned to use trunk and never a stable release.

Why? Currently newly added controllers will appear in fixes soon or later?

There are quite a lot of "bosses" around that only want to use stable releases in production.

Yes, but then they have just to wait.

Compiler patches or separate units, if one doesn't want to share code it won't make a difference.

Luckily enough not everybody thinks like this ;)

Fixed, changed into armv7m and armv4t.

I was pointed to CMSIS as what to fashion things after. The CMSIS consists of both function library and register definitions. I've looked at CMSIS - and it is over kill for what I'm looking, yet, if I use the LM3xxxxx processor, I'm forced to having the compiled in register definitions.

Each manufacturer has it's own way of defining their registers - which may or may not be in compliance with CMSIS. And with which each developer may or may not agree with.

By leaving the register definitions external to the compiler, then one can simply do a "uses CMSIS, LM3Sxxxx;" at the beginning of the program. Then, it's also much easier for someone to chase down where the register they are using is defined.

I've seen registers defined in C as straight #defines - which prevents the register names from being used inside of GDB. I've seen them defined individually - or as structures. ( I prefer structures, others prefer flat.)

Each way of defining the registers has pluses and minuses. Why restrict the end users right to decide how they want their registers defined.

My intent with GENERIC_THUMB2 is to give someone that doesn't want to use the compilers implementation the choice to create their own. It also gives people a way to boot strap a new Thumb2 implementation. One can write the register definitions, then add the definitions with the start-up into the compiler. It also gives someone a way to get started - without being a compiler writer if their MCU isn't supported.

And, as I said - I don't see how giving someone the choice of implementations is a bad thing.

John

________________________________