Re: [fpc-devel] Arm Thumb2 - Stellaris status
Ramtop for a generic part defined as having 1 MB of SRAM In the generic startup file, place an 8 KB array, inside a chunk of assembly, set stack_top = top of the array. So long as the program doesn't exceed the SRAM space AND the program doesn't exceed the array size - no problem. (The actual size will have to be debated a bit, I think 8KB should suffice - but this would preclude small devices from being used this way.) From: Geoffrey Barton m...@periphon.net To: FPC developers' list fpc-devel@lists.freepascal.org Sent: Sun, August 21, 2011 7:06:05 PM Subject: Re: [fpc-devel] Arm Thumb2 - Stellaris status On 21 Aug 2011, at 15:33, John Clymer wrote: As part of my table-ization of cpuinfo.pas, I am including a generic part for each (no code published for this yet.) The caveat to this is that FLASH size and SRAM sizes are just set to extremely large (1 MB each for now). Which means if the code size exceeds the space of the device - the compiler/linker will not catch the overflow of the available resource. (Running objsize on the ELF file will display the sizes - so I just run that after every successful compile.) As I pointed out, this will always fail because the stacktop is set beyond the available ram. It will cause an exception I think. How do you propose to be able to set the actual ram top for the generic part, or am I missing something? Also, still testing, but I have the interrupt reserved word working (more or less, more testing needed.) This takes the interrupt codeword with an integer. The integer is the offset into the vectors table. If no interrupt is provided for the given address, it defaults to DefaultHandler in the startup file - which is just a continual loop - so one can breakpoint on it. (This can be enabled / disabled via a define in the source.) This is should only be enabled for the embedded target - but I need to double check to ensure that is the case. This is a useful development; ideally the integer would be backed by an enumeration as it is a big table. One thing which I did find missing was the interrupt enable and disable assembler codes, so I patched them with data bytes hidden in functions. The keil C compiler does not like these if you link to units doing this (throws a data/code wobbly). See the file attached to bug tracker ID0017365 for how I hacked interrupts. Fortunately, I have a few days off before the school semester starts - so I will be working on this quite heavily over the next few days. all power to your elbow... Geoffrey John From: Geoffrey Barton m...@periphon.net To: FPC developers' list fpc-devel@lists.freepascal.org Sent: Sun, August 21, 2011 6:01:22 PM Subject: Re: [fpc-devel] Arm Thumb2 - Stellaris status On 20 Aug 2011, at 15:46, David Welch wrote: The great strength of ARM is that the peripherals, even if in different locations in different manufacturers parts, are identical in hardware terms if they are all cortex m3; that is the IP which they license from ARM.com. So maybe that is another reason for keeping the peripheral offset definitions and peripheral drivers separate and out of the compiler. Geoffrey Not sure what you are saying here, almost none of the peripherals are the same from vendor to vendor. With the cortex-m3 the systick timer and the VNIC for example are from ARM, sure, but the majority of the items you are going to use timers, dma, pwm, gpio, clocks and enables, etc are vendor specific and vastly different from vendor to vendor. Within a vendor they are very similar if not the same but from ti to st most of the items are not compatible, likewise from ti to lpc/nxp or ti to atmel, etc. You are right, of course. I have not looked at the data for other than Stellaris devices, I just generalised from the ARM TRM. Normally these are libraries and not buried in the compiler proper, I agree with that. Perhaps that is what you were saying and I misunderstood. not quite, but it is my aspiration :-) And as with libraries you can take them or leave them, that would want to be the case here (without having to dig into the compiler proper). Would need to roll your own target to avoid/modify a library. Ideally with the compiler you want to specify the arm core to take advantages of instructions each newer core supports. Not use them to tie to boards or systems. I was hoping for thumb support but I now see that the choices are limited to arm and thumb+thumb2 (without any separation between thumb and thumb2). Actually thumb2 wasnt working for me, I got an arm+thumb2 mix, so I will ride this along for a while and see what comes up, otherwise limit my use to ARM targets, or start working on a thumb backend. Adding backends as well as arm embedded are of interest to me so I may work on a little of both. So far it seems to be very straight forward
Re: [fpc-devel] Arm Thumb2 - Stellaris status
Ok, not a full answer yet, but ...
Also have a fresh svn tree, built and got similar results.
Redirected build output to a text file, copied and pasted the line compiling
unitstr file to batch file. ADDED -Cpcortexm3 and rebuilt.
Disassembled the resulting object file and got:
stm32f103.o: file format elf32-littlearm
Disassembly of section .text.n_stm32f103__fpc_haltproc:
STM32F103__FPC_HALTPROC:
0:e7fe b.n0 STM32F103__FPC_HALTPROC
2:46f7 movpc, lr
Disassembly of section .text.n_stm32f103__fpc_start:
STM32F103__FPC_START:
0:f8df 1034 ldr.wr1, [pc, #52]; 38
STM32F103__FPC_START+0x38
4:4a0d ldrr2, [pc, #52]; (3c
STM32F103__FPC_START+0x3c)
6:4b0e ldrr3, [pc, #56]; (40
STM32F103__FPC_START+0x40)
8:429a cmpr2, r3
a:bf9e itttls
c:f851 0b04 ldrls.wr0, [r1], #4
10:f842 0b04 strls.wr0, [r2], #4
14:e7f8 bls.n8 STM32F103__FPC_START+0x8
16:4906 ldrr1, [pc, #24]; (30
STM32F103__FPC_START+0x30)
18:4a06 ldrr2, [pc, #24]; (34
STM32F103__FPC_START+0x34)
1a:f04f mov.wr0, #0
1e:4291 cmpr1, r2
20:bf9c ittls
22:f841 0b04 strls.wr0, [r1], #4
26:e7fa bls.nfff8 PASCALMAIN+0xfff8
28:f7ff bffe b.w0 PASCALMAIN
2c:f7ff bffe b.w0 STM32F103__FPC_START
...
44:0048 .word0x0048
48:46f7 movpc, lr
4a:46f7 movpc, lr
This looks more like what I would expect for Thumb mode, so it's a build
problem
where the cpu is not getting set to Thumb2 mode when it builds the Thumb2 RTL
files.
John
From: David Welch dwe...@dwelch.com
To: FPC developers' list fpc-devel@lists.freepascal.org
Sent: Sun, August 21, 2011 12:24:34 AM
Subject: Re: [fpc-devel] Arm Thumb2 - Stellaris status
thumb2 is an extension to thumb not arm, you can mix thumb and arm in T
variants
like the v4T v5T and anything after that v6 on up, except for the cortex-m
variants which are thumb+thumb2 only and cannot execute ARM 32 bit instructions
(yes thumb2 32 bit thumb extensions but nothing from the ARM instruction set).
Here is an example of the problem I am seeing:
took a clean copy from svn
svn co http://svn.freepascal.org/svn/fpc/trunk fpc
cd fpc
make clean buildbase installbase CROSSINSTALL=1 OS_TARGET=embedded
CPU_TARGET=arm INSTALL_PREFIX=/fpcarm
test.pp
procedure Wait(d : dword);
begin
while d0 do
dec(d);
end;
begin
while true do
begin
Wait($2);
end;
end.
test.pp
./compiler/ppcrossarm -Parm -Tembedded -Wpstm32f103re -Cpcortexm3 test.pp
Free Pascal Compiler version 2.7.1 [2011/08/20] for arm
Copyright (c) 1993-2011 by Florian Klaempfl and others
Target OS: Embedded
Compiling test.pp
Assembling program
Linking test
/opt/embarm/arm-embedded-ld: warning: library search path
/usr/local/lib/fpc/2.7.1/units/arm-embedded/rtl/ is unsafe for
cross-compilation
14 lines compiled, 0.0 sec
then dumped the binary:
0800 _START-0x158:
800:2000fffc strdcspc, [r0], -ip
804:08000405 stmdaeqr0, {r0, r2, sl}
808:08000405 stmdaeqr0, {r0, r2, sl}
80c:08000405 stmdaeqr0, {r0, r2, sl}
810:08000405 stmdaeqr0, {r0, r2, sl}
814:08000405 stmdaeqr0, {r0, r2, sl}
818:08000405 stmdaeqr0, {r0, r2, sl}
...
08000194 PASCALMAIN:
8000194:46ec movip, sp
8000196:e92d 4800 stmdbsp!, {fp, lr}
800019a:f1ac 0b04 sub.wfp, ip, #4
800019e:b08a subsp, #40; 0x28
80001a0:f000 f844 bl800022c FPC_INITIALIZEUNITS
80001a4:e004 b.n80001b0 PASCALMAIN+0x1c
80001a6:bf00 nop
80001a8:f44f 3000 mov.wr0, #131072; 0x2
80001ac:f7ff ffd8 bl8000160 P$PROGRAM_WAIT$LONGWORD
80001b0:e7fa b.n80001a8 PASCALMAIN+0x14
80001b2:f000 f8ff bl80003b4 FPC_DO_EXIT
80001b6:46dd movsp, fp
80001b8:b001 addsp, #4
80001ba:e91d 8800 ldmdbsp, {fp, pc}
80001be:bf00 nop
...
08000404 STM32F103__FPC_START:
8000404:e59f103c ldrr1, [pc, #60]; 8000448
STM32F103__FPC_START+0x44
8000408:e59f203c ldrr2, [pc, #60]; 800044c
STM32F103__FPC_START+0x48
800040c:e59f303c ldrr3, [pc, #60]; 8000450
STM32F103__FPC_START+0x4c
8000410:e1520003 cmpr2, r3
8000414:94910004 ldrlsr0, [r1], #4
First off 0x08000405 implies a thumb target but it is not thumb code, it is arm
code so 0x08000404 would be correct but that is still wrong because cores with
that vector table (cortex-m) cannot execute arm
Re: [fpc-devel] Arm Thumb2 - Stellaris status
Den 21-08-2011 00:00, David Welch skrev: A! that makes sense. I assume that is either leftover from a prior build? And how do I get a new/fresh build to look in the right place? It's installed in /fpcarm. This directory should contain a bin and units directory. You simply need to change your main fpc.cfg file to match those settings. I don't know precisely how that would be done on a unix system. Maybe it would even install directly to your current install directory, if you just run this? make buildbase OS_TARGET=embedded CPU_TARGET=arm CROSSOPT=-Cpcortexm3 CROSSINSTALL=1 sudo make installbase OS_TARGET=embedded CPU_TARGET=arm CROSSOPT=-Cpcortexm3 CROSSINSTALL=1 On a side note, I find it strange that it even accepts your old leftover files. I thought the linker normally would complain about interwork stuff ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Arm Thumb2 - Stellaris status
On 20 Aug 2011, at 15:46, David Welch wrote: The great strength of ARM is that the peripherals, even if in different locations in different manufacturers parts, are identical in hardware terms if they are all cortex m3; that is the IP which they license from ARM.com. So maybe that is another reason for keeping the peripheral offset definitions and peripheral drivers separate and out of the compiler. Geoffrey Not sure what you are saying here, almost none of the peripherals are the same from vendor to vendor. With the cortex-m3 the systick timer and the VNIC for example are from ARM, sure, but the majority of the items you are going to use timers, dma, pwm, gpio, clocks and enables, etc are vendor specific and vastly different from vendor to vendor. Within a vendor they are very similar if not the same but from ti to st most of the items are not compatible, likewise from ti to lpc/nxp or ti to atmel, etc. You are right, of course. I have not looked at the data for other than Stellaris devices, I just generalised from the ARM TRM. Normally these are libraries and not buried in the compiler proper, I agree with that. Perhaps that is what you were saying and I misunderstood. not quite, but it is my aspiration :-) And as with libraries you can take them or leave them, that would want to be the case here (without having to dig into the compiler proper). Would need to roll your own target to avoid/modify a library. Ideally with the compiler you want to specify the arm core to take advantages of instructions each newer core supports. Not use them to tie to boards or systems. I was hoping for thumb support but I now see that the choices are limited to arm and thumb+thumb2 (without any separation between thumb and thumb2). Actually thumb2 wasnt working for me, I got an arm+thumb2 mix, so I will ride this along for a while and see what comes up, otherwise limit my use to ARM targets, or start working on a thumb backend. Adding backends as well as arm embedded are of interest to me so I may work on a little of both. So far it seems to be very straight forward to add a platform/device to fpc arm embedded, so if the stock support is too bulky or confusing individuals can cherry pick items they want and make their own simpler target. The approach used in coide is quite interesting. Have a look on coocox.org. They have it down to box ticking. Actually what we definitely need here in the near term is an arm generic target and a thumb2 generic target that does not have any of the vendor specific items in it, perhaps not even core specific peripherals. I agree. I understand this is a work in progress and sorting everything out will take some time. Unfortunately the discussion is rather torn between the basic simplicity camp and the portmanteau camp. I rather think the latter is more suitable for a commercial company which can afford the maintenance, otherwise it is always out-of-date. Keeping up with new ARM cores is perhaps enough to do already. Geoffrey. David ___ 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] Arm Thumb2 - Stellaris status
As interesting is that it will assemble thumb2 code as arm code and not fail/stop during that step in the build. Thanks for the help, will try that. David On 08/21/2011 05:23 AM, Jeppe Græsdal Johansen wrote: Den 21-08-2011 00:00, David Welch skrev: A! that makes sense. I assume that is either leftover from a prior build? And how do I get a new/fresh build to look in the right place? It's installed in /fpcarm. This directory should contain a bin and units directory. You simply need to change your main fpc.cfg file to match those settings. I don't know precisely how that would be done on a unix system. Maybe it would even install directly to your current install directory, if you just run this? make buildbase OS_TARGET=embedded CPU_TARGET=arm CROSSOPT=-Cpcortexm3 CROSSINSTALL=1 sudo make installbase OS_TARGET=embedded CPU_TARGET=arm CROSSOPT=-Cpcortexm3 CROSSINSTALL=1 On a side note, I find it strange that it even accepts your old leftover files. I thought the linker normally would complain about interwork stuff ___ 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] Arm Thumb2 - Stellaris status
As part of my table-ization of cpuinfo.pas, I am including a generic part for each (no code published for this yet.) The caveat to this is that FLASH size and SRAM sizes are just set to extremely large (1 MB each for now). Which means if the code size exceeds the space of the device - the compiler/linker will not catch the overflow of the available resource. (Running objsize on the ELF file will display the sizes - so I just run that after every successful compile.) Also, still testing, but I have the interrupt reserved word working (more or less, more testing needed.) This takes the interrupt codeword with an integer. The integer is the offset into the vectors table. If no interrupt is provided for the given address, it defaults to DefaultHandler in the startup file - which is just a continual loop - so one can breakpoint on it. (This can be enabled / disabled via a define in the source.) This is should only be enabled for the embedded target - but I need to double check to ensure that is the case. Fortunately, I have a few days off before the school semester starts - so I will be working on this quite heavily over the next few days. John From: Geoffrey Barton m...@periphon.net To: FPC developers' list fpc-devel@lists.freepascal.org Sent: Sun, August 21, 2011 6:01:22 PM Subject: Re: [fpc-devel] Arm Thumb2 - Stellaris status On 20 Aug 2011, at 15:46, David Welch wrote: The great strength of ARM is that the peripherals, even if in different locations in different manufacturers parts, are identical in hardware terms if they are all cortex m3; that is the IP which they license from ARM.com. So maybe that is another reason for keeping the peripheral offset definitions and peripheral drivers separate and out of the compiler. Geoffrey Not sure what you are saying here, almost none of the peripherals are the same from vendor to vendor. With the cortex-m3 the systick timer and the VNIC for example are from ARM, sure, but the majority of the items you are going to use timers, dma, pwm, gpio, clocks and enables, etc are vendor specific and vastly different from vendor to vendor. Within a vendor they are very similar if not the same but from ti to st most of the items are not compatible, likewise from ti to lpc/nxp or ti to atmel, etc. You are right, of course. I have not looked at the data for other than Stellaris devices, I just generalised from the ARM TRM. Normally these are libraries and not buried in the compiler proper, I agree with that. Perhaps that is what you were saying and I misunderstood. not quite, but it is my aspiration :-) And as with libraries you can take them or leave them, that would want to be the case here (without having to dig into the compiler proper). Would need to roll your own target to avoid/modify a library. Ideally with the compiler you want to specify the arm core to take advantages of instructions each newer core supports. Not use them to tie to boards or systems. I was hoping for thumb support but I now see that the choices are limited to arm and thumb+thumb2 (without any separation between thumb and thumb2). Actually thumb2 wasnt working for me, I got an arm+thumb2 mix, so I will ride this along for a while and see what comes up, otherwise limit my use to ARM targets, or start working on a thumb backend. Adding backends as well as arm embedded are of interest to me so I may work on a little of both. So far it seems to be very straight forward to add a platform/device to fpc arm embedded, so if the stock support is too bulky or confusing individuals can cherry pick items they want and make their own simpler target. The approach used in coide is quite interesting. Have a look on coocox.org. They have it down to box ticking. Actually what we definitely need here in the near term is an arm generic target and a thumb2 generic target that does not have any of the vendor specific items in it, perhaps not even core specific peripherals. I agree. I understand this is a work in progress and sorting everything out will take some time. Unfortunately the discussion is rather torn between the basic simplicity camp and the portmanteau camp. I rather think the latter is more suitable for a commercial company which can afford the maintenance, otherwise it is always out-of-date. Keeping up with new ARM cores is perhaps enough to do already. Geoffrey. David ___ 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] Arm Thumb2 - Stellaris status
In our previous episode, John Clymer said: As part of my table-ization of cpuinfo.pas, I am including a generic part for each (no code published for this yet.) The caveat to this is that FLASH size and SRAM sizes are just set to extremely large (1 MB each for now). Which means if the code size exceeds the space of the device - the compiler/linker will not catch the overflow of the available resource. (Running objsize on the ELF file will display the sizes - so I just run that after every successful compile.) I don't use embedded arm, but on other microcontrollers, bootloaders are often also at the end of the flash. The main reason for this is to avoid having to modify the linker file for normal programs (to switch between bootloadable and not). For that, you need to have the exact amount of flash in your CPU profile. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Arm Thumb2 - Stellaris status
On 21 Aug 2011, at 15:33, John Clymer wrote: As part of my table-ization of cpuinfo.pas, I am including a generic part for each (no code published for this yet.) The caveat to this is that FLASH size and SRAM sizes are just set to extremely large (1 MB each for now). Which means if the code size exceeds the space of the device - the compiler/linker will not catch the overflow of the available resource. (Running objsize on the ELF file will display the sizes - so I just run that after every successful compile.) As I pointed out, this will always fail because the stacktop is set beyond the available ram. It will cause an exception I think. How do you propose to be able to set the actual ram top for the generic part, or am I missing something? Also, still testing, but I have the interrupt reserved word working (more or less, more testing needed.) This takes the interrupt codeword with an integer. The integer is the offset into the vectors table. If no interrupt is provided for the given address, it defaults to DefaultHandler in the startup file - which is just a continual loop - so one can breakpoint on it. (This can be enabled / disabled via a define in the source.) This is should only be enabled for the embedded target - but I need to double check to ensure that is the case. This is a useful development; ideally the integer would be backed by an enumeration as it is a big table. One thing which I did find missing was the interrupt enable and disable assembler codes, so I patched them with data bytes hidden in functions. The keil C compiler does not like these if you link to units doing this (throws a data/code wobbly). See the file attached to bug tracker ID0017365 for how I hacked interrupts. Fortunately, I have a few days off before the school semester starts - so I will be working on this quite heavily over the next few days. all power to your elbow... Geoffrey John From: Geoffrey Barton m...@periphon.net To: FPC developers' list fpc-devel@lists.freepascal.org Sent: Sun, August 21, 2011 6:01:22 PM Subject: Re: [fpc-devel] Arm Thumb2 - Stellaris status On 20 Aug 2011, at 15:46, David Welch wrote: The great strength of ARM is that the peripherals, even if in different locations in different manufacturers parts, are identical in hardware terms if they are all cortex m3; that is the IP which they license from ARM.com. So maybe that is another reason for keeping the peripheral offset definitions and peripheral drivers separate and out of the compiler. Geoffrey Not sure what you are saying here, almost none of the peripherals are the same from vendor to vendor. With the cortex-m3 the systick timer and the VNIC for example are from ARM, sure, but the majority of the items you are going to use timers, dma, pwm, gpio, clocks and enables, etc are vendor specific and vastly different from vendor to vendor. Within a vendor they are very similar if not the same but from ti to st most of the items are not compatible, likewise from ti to lpc/nxp or ti to atmel, etc. You are right, of course. I have not looked at the data for other than Stellaris devices, I just generalised from the ARM TRM. Normally these are libraries and not buried in the compiler proper, I agree with that. Perhaps that is what you were saying and I misunderstood. not quite, but it is my aspiration :-) And as with libraries you can take them or leave them, that would want to be the case here (without having to dig into the compiler proper). Would need to roll your own target to avoid/modify a library. Ideally with the compiler you want to specify the arm core to take advantages of instructions each newer core supports. Not use them to tie to boards or systems. I was hoping for thumb support but I now see that the choices are limited to arm and thumb+thumb2 (without any separation between thumb and thumb2). Actually thumb2 wasnt working for me, I got an arm+thumb2 mix, so I will ride this along for a while and see what comes up, otherwise limit my use to ARM targets, or start working on a thumb backend. Adding backends as well as arm embedded are of interest to me so I may work on a little of both. So far it seems to be very straight forward to add a platform/device to fpc arm embedded, so if the stock support is too bulky or confusing individuals can cherry pick items they want and make their own simpler target. The approach used in coide is quite interesting. Have a look on coocox.org. They have it down to box ticking. Actually what we definitely need here in the near term is an arm generic target and a thumb2 generic target that does not have any of the vendor specific items in it, perhaps not even core specific peripherals. I agree. I understand this is a work in progress and sorting everything out
Re: [fpc-devel] Arm Thumb2 - Stellaris status
Den 21-08-2011 17:06, Geoffrey Barton skrev:
On 21 Aug 2011, at 15:33, John Clymer wrote:
As part of my table-ization of cpuinfo.pas, I am including a generic
part for each (no code published for this yet.) The caveat to this
is that FLASH size and SRAM sizes are just set to extremely large (1
MB each for now). Which means if the code size exceeds the space of
the device - the compiler/linker will not catch the overflow of the
available resource. (Running objsize on the ELF file will display
the sizes - so I just run that after every successful compile.)
As I pointed out, this will always fail because the stacktop is set
beyond the available ram. It will cause an exception I think. How do
you propose to be able to set the actual ram top for the generic part,
or am I missing something?
Also, still testing, but I have the interruptreserved word working
(more or less, more testing needed.) This takes the interrupt
codeword with an integer. The integer is the offset into the vectors
table. If no interrupt is provided for the given address, it
defaults to DefaultHandler in the startup file - which is just a
continual loop - so one can breakpoint on it. (This can be enabled /
disabled via a define in the source.) This is should only be enabled
for the embedded target - but I need to double check to ensure that
is the case.
This is a useful development; ideally the integer would be backed by
an enumeration as it is a big table. One thing which I did find
missing was the interrupt enable and disable assembler codes, so I
patched them with data bytes hidden in functions. The keil C compiler
does not like these if you link to units doing this (throws a
data/code wobbly). See the file attached to bug tracker ID0017365 for
how I hacked interrupts.
The CPS* instruction with the correct operand syntax was added in #18334
SVN trunk already has experimental support for the interrupt keyword.
It's enabled with FPC_HAS_SYSTEMS_INTERRUPT_TABLE in fpcdefs.inc. I
discovered a small bug with the current implementation which is fixed
with the attached patch(which also includes some other stuff... the
bugfix is in ncgutil. It didn't search the program file for interrupt
handlers before)
Index: compiler/fpcdefs.inc
===
--- compiler/fpcdefs.inc(revision 18784)
+++ compiler/fpcdefs.inc(working copy)
@@ -33,7 +33,7 @@
$define FPC_HAS_SYSTEMS_INTERRUPT_TABLE
to fpcdefs.inc to reactivate
the corresponding code }
-{$undef FPC_HAS_SYSTEMS_INTERRUPT_TABLE}
+{$define FPC_HAS_SYSTEMS_INTERRUPT_TABLE}
{ This fake CPU is used to allow incorporation of globtype unit
into utils/ppudump without any CPU specific code PM }
Index: compiler/ncgutil.pas
===
--- compiler/ncgutil.pas(revision 18784)
+++ compiler/ncgutil.pas(working copy)
@@ -3197,7 +3197,30 @@
end;
hp:=tused_unit(hp.next);
end;
+for i := 0 to current_module.symlist.Count-1 do
+ begin
+sym:=tsym(current_module.symlist[i]);
+if not assigned(sym) then
+ continue;
+if sym.typ = procsym then
+ begin
+for i2 := 0 to tprocsym(sym).ProcdefList.Count-1 do
+ begin
+pd:=tprocdef(tprocsym(sym).ProcdefList[i2]);
+if pd.interruptvector = 0 then
+ begin
+if pd.interruptvector high(interruptTable) then
+ Internalerror(2011030602);
+if interruptTable[pd.interruptvector] nil then
+ internalerror(2011030601);
+interruptTable[pd.interruptvector]:=pd;
+break;
+ end;
+ end;
+ end;
+ end;
+
new_section(current_asmdata.asmlists[al_globals],sec_init,'VECTORS',sizeof(pint));
current_asmdata.asmlists[al_globals].concat(Tai_symbol.Createname_global('VECTORS',AT_DATA,0));
{$IFDEF arm}
Index: compiler/pdecsub.pas
===
--- compiler/pdecsub.pas(revision 18784)
+++ compiler/pdecsub.pas(working copy)
@@ -2308,7 +2308,7 @@
idtok:_INTERRUPT;
pd_flags :
[pd_implemen,pd_body,pd_notobject,pd_notobjintf,pd_notrecord,pd_nothelper];
handler : @pd_interrupt;
- pocall : pocall_oldfpccall;
+ pocall : pocall_interrupt;
pooption : [po_interrupt];
mutexclpocall :
[pocall_internproc,pocall_cdecl,pocall_cppdecl,pocall_stdcall,
pocall_pascal,pocall_far16,pocall_oldfpccall];
Index: compiler/systems.pas
===
--- compiler/systems.pas(revision 18784)
+++
Re: [fpc-devel] Arm Thumb2 - Stellaris status
I found FPC_HAS_SYSTEMS_INTERRUPT_TABL, enabled it - but it was still broken for Thumb2 (stellaris, stm32). For Thumb2, it was broken in the following ways: 1) Stack_top should be placed at vector 0. 2) Each address should have the LSB set - to force Thumb mode when the PC gets loaded with that value. I defined FPC_HAS_SYSTEMS_INTERRUPT_TABLE a little further down - so that was only enabled on ARM and AVR (trying not to break other things...) I also have some added logic in ncgutil - for M3 devices - to place the stack_top into vector 0, then place handlers for vectors 1 to TOP. The WriteVector routine for Thumb also adds an offset of 1 to each vector - so as to force Thumb mode upon load to PC. John From: Jeppe Græsdal Johansen jjoha...@student.aau.dk To: FPC developers' list fpc-devel@lists.freepascal.org Sent: Sun, August 21, 2011 7:27:48 PM Subject: Re: [fpc-devel] Arm Thumb2 - Stellaris status Den 21-08-2011 17:06, Geoffrey Barton skrev: On 21 Aug 2011, at 15:33, John Clymer wrote: As part of my table-ization of cpuinfo.pas, I am including a generic part for each (no code published for this yet.) The caveat to this is that FLASH size and SRAM sizes are just set to extremely large (1 MB each for now).Which means if the code size exceeds the space of the device - the compiler/linker will not catch the overflow of the available resource. (Running objsize on the ELF file will display the sizes - so I just run that after every successful compile.) As I pointed out, this will always fail because the stacktop is set beyond the available ram. It will cause an exception I think. How do you propose to be able to set the actual ram top for the generic part, or am I missing something? Also, still testing, but I have the interrupt reserved word working (more or less, more testing needed.)This takes the interrupt codeword with an integer.The integer is the offset into the vectors table. If no interrupt is provided for the given address, it defaults to DefaultHandler in the startup file - which is just a continual loop - so one can breakpoint on it. (This can be enabled / disabled via a define in the source.) This is should only be enabled for the embedded target - but I need to double check to ensure that is the case. This is a useful development; ideally the integer would be backed by an enumeration as it is a big table. One thing which I did find missing was the interrupt enable and disable assembler codes, so I patched them with data bytes hidden in functions. The keil C compiler does not like these if you link to units doing this (throws a data/code wobbly). See the file attached to bug tracker ID0017365 for how I hacked interrupts. The CPS* instruction with the correct operand syntax was added in #18334 SVN trunk already has experimental support for the interrupt keyword. It's enabled with FPC_HAS_SYSTEMS_INTERRUPT_TABLE in fpcdefs.inc. I discovered a small bug with the current implementation which is fixed with the attached patch(which also includes some other stuff... the bugfix is in ncgutil. It didn't search the program file for interrupt handlers before) ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Arm Thumb2 - Stellaris status
Den 21-08-2011 17:43, John Clymer skrev: I found FPC_HAS_SYSTEMS_INTERRUPT_TABL, enabled it - but it was still broken for Thumb2 (stellaris, stm32). For Thumb2, it was broken in the following ways: 1) Stack_top should be placed at vector 0. I disagree, but I guess that's a question of interpretation. I don't think it's really a vector. So currently vector 0 is for the reset vector at address 0x8004, and _stack_top is placed in front of the table 2) Each address should have the LSB set - to force Thumb mode when the PC gets loaded with that value. That's the linkers job. And it is handled correctly currently as long as the labels where they are pointing to are marked with the .thumb_func directive(as they are when using -Cpcortexm3) I defined FPC_HAS_SYSTEMS_INTERRUPT_TABLE a little further down - so that was only enabled on ARM and AVR (trying not to break other things...) I also have some added logic in ncgutil - for M3 devices - to place the stack_top into vector 0, then place handlers for vectors 1 to TOP. The WriteVector routine for Thumb also adds an offset of 1 to each vector - so as to force Thumb mode upon load to PC. You shouldn't add anything to get thumb vectors, as I explained further up. John ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Arm Thumb2 - Stellaris status
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 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] 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 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
Re: [fpc-devel] Arm Thumb2 - Stellaris status
On 20 Aug 2011, at 07:20, 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. I think that anybody using a device would have to have already assigned pin connections in the board design and should know well which peripherals they are using. OR - we could leave the peripheral definitions to the user. (Which I'm assuming is not the preferred route.) It is to me. People can contribute definitions and drivers as they use the parts and these can just go in 'uses'. Geoffrey 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 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] Arm Thumb2 - Stellaris status
On 20 Aug 2011, at 09:01, David Welch wrote: 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. The great strength of ARM is that the peripherals, even if in different locations in different manufacturers parts, are identical in hardware terms if they are all cortex m3; that is the IP which they license from ARM.com. So maybe that is another reason for keeping the peripheral offset definitions and peripheral drivers separate and out of the compiler. Geoffrey 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
Re: [fpc-devel] Arm Thumb2 - Stellaris status
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 dwe...@dwelch.com To: FPC developers' list fpc-devel@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
Re: [fpc-devel] Arm Thumb2 - Stellaris status
The great strength of ARM is that the peripherals, even if in different locations in different manufacturers parts, are identical in hardware terms if they are all cortex m3; that is the IP which they license from ARM.com. So maybe that is another reason for keeping the peripheral offset definitions and peripheral drivers separate and out of the compiler. Geoffrey Not sure what you are saying here, almost none of the peripherals are the same from vendor to vendor. With the cortex-m3 the systick timer and the VNIC for example are from ARM, sure, but the majority of the items you are going to use timers, dma, pwm, gpio, clocks and enables, etc are vendor specific and vastly different from vendor to vendor. Within a vendor they are very similar if not the same but from ti to st most of the items are not compatible, likewise from ti to lpc/nxp or ti to atmel, etc. Normally these are libraries and not buried in the compiler proper, I agree with that. Perhaps that is what you were saying and I misunderstood. And as with libraries you can take them or leave them, that would want to be the case here (without having to dig into the compiler proper). Would need to roll your own target to avoid/modify a library. Ideally with the compiler you want to specify the arm core to take advantages of instructions each newer core supports. Not use them to tie to boards or systems. I was hoping for thumb support but I now see that the choices are limited to arm and thumb+thumb2 (without any separation between thumb and thumb2). Actually thumb2 wasnt working for me, I got an arm+thumb2 mix, so I will ride this along for a while and see what comes up, otherwise limit my use to ARM targets, or start working on a thumb backend. Adding backends as well as arm embedded are of interest to me so I may work on a little of both. So far it seems to be very straight forward to add a platform/device to fpc arm embedded, so if the stock support is too bulky or confusing individuals can cherry pick items they want and make their own simpler target. Actually what we definitely need here in the near term is an arm generic target and a thumb2 generic target that does not have any of the vendor specific items in it, perhaps not even core specific peripherals. I understand this is a work in progress and sorting everything out will take some time. David ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Arm Thumb2 - Stellaris status
Den 20-08-2011 16:46, David Welch skrev: I was hoping for thumb support but I now see that the choices are limited to arm and thumb+thumb2 (without any separation between thumb and thumb2). Actually thumb2 wasnt working for me, I got an arm+thumb2 mix, so I will ride this along for a while and see what comes up, otherwise limit my use to ARM targets, or start working on a thumb backend. Adding backends as well as arm embedded are of interest to me so I may work on a little of both. Why thumb support? The choices are indeed currently only either ARM or Thumb2(which is Thumb+32 bit extensions). Thumb2 is a variable length instruction set that looks like an arm+thumb mix, so I guarantee you that it works :) ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Arm Thumb2 - Stellaris status
The thumb2 is meant to support Cortex M3 devices (STM32, Stellaris, etc.) AFAIK - the mixing of modes is not currently an option. From: Jeppe Græsdal Johansen jjoha...@student.aau.dk To: FPC developers' list fpc-devel@lists.freepascal.org Sent: Sat, August 20, 2011 7:23:39 PM Subject: Re: [fpc-devel] Arm Thumb2 - Stellaris status Den 20-08-2011 16:46, David Welch skrev: I was hoping for thumb support but I now see that the choices are limited to arm and thumb+thumb2 (without any separation between thumb and thumb2). Actually thumb2 wasnt working for me, I got an arm+thumb2 mix, so I will ride this along for a while and see what comes up, otherwise limit my use to ARM targets, or start working on a thumb backend. Adding backends as well as arm embedded are of interest to me so I may work on a little of both. Why thumb support? The choices are indeed currently only either ARM or Thumb2(which is Thumb+32 bit extensions). Thumb2 is a variable length instruction set that looks like an arm+thumb mix, so I guarantee you that it works :) ___ 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] Arm Thumb2 - Stellaris status
I'm not sure how FPC should handle the peripherals, but I don't think it should be at the compiler level. Even if the part I'm using has, for instance, an ADC, if I'm not using it I do not want support for it built in to my app. With what I use currently (IAR C) I uncomment a #define for each peripheral I want to add support for. I'm sure something similar can be done for FPC at the unit level. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Arm Thumb2 - Stellaris status
right, when I build for stellaris or stm32f103re I get the cortex-m like vector table that uses arm 32 bit instruction startup code that branches to a pascalmain that is thumb2. something that wont execute on hardware. Had it been a thumb target with a traditional exeception table that would have been good and in fact desirable for some platforms (nintendo gba for example). but the arm/thumb2 combination doesnt mix very well. Maybe I need to re-try everything from scratch to see if I skipped a step or left out something and specified the wrong target or cpu. Note you are giving up a stack location by using addresses in the form 0x10007FFC instead of 0x10008000. Minor point but it stands out in the binary. This is all clearly a work in progress, I understand that... David On 08/20/2011 11:49 AM, John Clymer wrote: The thumb2 is meant to support Cortex M3 devices (STM32, Stellaris, etc.) AFAIK - the mixing of modes is not currently an option. *From:* Jeppe Græsdal Johansen jjoha...@student.aau.dk *To:* FPC developers' list fpc-devel@lists.freepascal.org *Sent:* Sat, August 20, 2011 7:23:39 PM *Subject:* Re: [fpc-devel] Arm Thumb2 - Stellaris status Den 20-08-2011 16:46, David Welch skrev: I was hoping for thumb support but I now see that the choices are limited to arm and thumb+thumb2 (without any separation between thumb and thumb2). Actually thumb2 wasnt working for me, I got an arm+thumb2 mix, so I will ride this along for a while and see what comes up, otherwise limit my use to ARM targets, or start working on a thumb backend. Adding backends as well as arm embedded are of interest to me so I may work on a little of both. Why thumb support? The choices are indeed currently only either ARM or Thumb2(which is Thumb+32 bit extensions). Thumb2 is a variable length instruction set that looks like an arm+thumb mix, so I guarantee you that it works :) ___ 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
Re: [fpc-devel] Arm Thumb2 - Stellaris status
I am rapidly seeing the problem, the linker script is hardcoded both by family (ARM as a whole) and by target. So for example if you wanted a ram-only ARM generic target, you are in trouble, or if you wanted a flash/ram target arm generic target you are in trouble. You have to override the compiled in maps. Once you get target specific compiled in memory maps then the compiled in register addresses make sense. At that point do the libraries, pll init, timers, etc make sense? David On 08/20/2011 11:57 AM, DaWorm wrote: I'm not sure how FPC should handle the peripherals, but I don't think it should be at the compiler level. Even if the part I'm using has, for instance, an ADC, if I'm not using it I do not want support for it built in to my app. With what I use currently (IAR C) I uncomment a #define for each peripheral I want to add support for. I'm sure something similar can be done for FPC at the unit level. ___ 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] Arm Thumb2 - Stellaris status
thumb2 is an extension to thumb not arm, you can mix thumb and arm in T
variants like the v4T v5T and anything after that v6 on up, except for
the cortex-m variants which are thumb+thumb2 only and cannot execute ARM
32 bit instructions (yes thumb2 32 bit thumb extensions but nothing from
the ARM instruction set).
Here is an example of the problem I am seeing:
took a clean copy from svn
svn co http://svn.freepascal.org/svn/fpc/trunk fpc
cd fpc
make clean buildbase installbase CROSSINSTALL=1 OS_TARGET=embedded
CPU_TARGET=arm INSTALL_PREFIX=/fpcarm
test.pp
procedure Wait(d : dword);
begin
while d0 do
dec(d);
end;
begin
while true do
begin
Wait($2);
end;
end.
test.pp
./compiler/ppcrossarm -Parm -Tembedded -Wpstm32f103re -Cpcortexm3 test.pp
Free Pascal Compiler version 2.7.1 [2011/08/20] for arm
Copyright (c) 1993-2011 by Florian Klaempfl and others
Target OS: Embedded
Compiling test.pp
Assembling program
Linking test
/opt/embarm/arm-embedded-ld: warning: library search path
/usr/local/lib/fpc/2.7.1/units/arm-embedded/rtl/ is unsafe for
cross-compilation
14 lines compiled, 0.0 sec
then dumped the binary:
0800 _START-0x158:
800: 2000fffcstrdcs pc, [r0], -ip
804: 08000405stmdaeq r0, {r0, r2, sl}
808: 08000405stmdaeq r0, {r0, r2, sl}
80c: 08000405stmdaeq r0, {r0, r2, sl}
810: 08000405stmdaeq r0, {r0, r2, sl}
814: 08000405stmdaeq r0, {r0, r2, sl}
818: 08000405stmdaeq r0, {r0, r2, sl}
...
08000194 PASCALMAIN:
8000194: 46ecmov ip, sp
8000196: e92d 4800 stmdb sp!, {fp, lr}
800019a: f1ac 0b04 sub.w fp, ip, #4
800019e: b08asub sp, #40 ; 0x28
80001a0: f000 f844 bl 800022c FPC_INITIALIZEUNITS
80001a4: e004b.n 80001b0 PASCALMAIN+0x1c
80001a6: bf00nop
80001a8: f44f 3000 mov.w r0, #131072 ; 0x2
80001ac: f7ff ffd8 bl 8000160 P$PROGRAM_WAIT$LONGWORD
80001b0: e7fab.n 80001a8 PASCALMAIN+0x14
80001b2: f000 f8ff bl 80003b4 FPC_DO_EXIT
80001b6: 46ddmov sp, fp
80001b8: b001add sp, #4
80001ba: e91d 8800 ldmdb sp, {fp, pc}
80001be: bf00nop
...
08000404 STM32F103__FPC_START:
8000404: e59f103cldr r1, [pc, #60] ; 8000448
STM32F103__FPC_START+0x44
8000408: e59f203cldr r2, [pc, #60] ; 800044c
STM32F103__FPC_START+0x48
800040c: e59f303cldr r3, [pc, #60] ; 8000450
STM32F103__FPC_START+0x4c
8000410: e1520003cmp r2, r3
8000414: 94910004ldrls r0, [r1], #4
First off 0x08000405 implies a thumb target but it is not thumb code, it
is arm code so 0x08000404 would be correct but that is still wrong
because cores with that vector table (cortex-m) cannot execute arm
instructions.
Looking at that first instruction in the reset handler
08000404 STM32F103__FPC_START:
8000404: e59f103cldr r1, [pc, #60] ; 8000448
STM32F103__FPC_START+0x44
IPUBWL
1110 01011001 r15, r1, 0x03C
And that was properly decoded by objdump, immediate offset rn+offset12,
load, word sized, etc.
PC is 0x800040C at that time so load address is 0x800040C+0x03C = 0x8000448
You can tell both by 32 bit numbers in the dump but the dominance of an
0xE as the first nibble also implies these are arm instructions not
thumb (need to see a long chunk of code to see the pattern). Had they
been thumb instructions but decoded wrong by the disassembler then the
first and fourth nibbles would have been dominated by like 6's and 7's
or at least would stand out compared to the other
nibbles.
if we decode this as thumb/thumb2
0xE59F
//B(2) unconditional branch
if((inst0xF800)==0xE000)
{
rb=(inst0)0x7FF;
if(rb(110)) rb|=(~0)11;
rb=1;
rb+=pc;
rb+=2;
write_register(15,rb);
return(0);
}
111001011001
11100 1011001
...111011001
...1110110010
...11 1011 0011 1110
pc = 0x405+4 = 0x409
pc + 0x...FFB3E =
0x409 - (0x4C1 + 1) = 0x747
Unconditional branch to 0x0747 so it is a valid instruction, but
doesnt make much sense
This does though, the start code from stm32f103.pp
.globl _start
.text
_start:
// Copy initialized data to ram
ldr r1,.L_etext
ldr r2,.L_data
ldr r3,.L_edata
.Lcopyloop:
cmp r2,r3
ittt ls
ldrls r0,[r1],#4
strls r0,[r2],#4
bls .Lcopyloop
The instructions the assembler was able to encode it did:
8000404: e59f103cldr r1, [pc, #60]
8000408: e59f203cldr r2, [pc, #60]
800040c: e59f303cldr
Re: [fpc-devel] Arm Thumb2 - Stellaris status
Den 20-08-2011 22:24, David Welch skrev:
thumb2 is an extension to thumb not arm, you can mix thumb and arm in
T variants like the v4T v5T and anything after that v6 on up, except
for the cortex-m variants which are thumb+thumb2 only and cannot
execute ARM 32 bit instructions (yes thumb2 32 bit thumb extensions
but nothing from the ARM instruction set).
Here is an example of the problem I am seeing:
took a clean copy from svn
svn co http://svn.freepascal.org/svn/fpc/trunk fpc
cd fpc
make clean buildbase installbase CROSSINSTALL=1 OS_TARGET=embedded
CPU_TARGET=arm INSTALL_PREFIX=/fpcarm
test.pp
procedure Wait(d : dword);
begin
while d0 do
dec(d);
end;
begin
while true do
begin
Wait($2);
end;
end.
test.pp
./compiler/ppcrossarm -Parm -Tembedded -Wpstm32f103re -Cpcortexm3 test.pp
Free Pascal Compiler version 2.7.1 [2011/08/20] for arm
Copyright (c) 1993-2011 by Florian Klaempfl and others
Target OS: Embedded
Compiling test.pp
Assembling program
Linking test
/opt/embarm/arm-embedded-ld: warning: library search path
/usr/local/lib/fpc/2.7.1/units/arm-embedded/rtl/ is unsafe for
cross-compilation
14 lines compiled, 0.0 sec
then dumped the binary:
0800 _START-0x158:
800:2000fffc strdcspc, [r0], -ip
804:08000405 stmdaeqr0, {r0, r2, sl}
808:08000405 stmdaeqr0, {r0, r2, sl}
80c:08000405 stmdaeqr0, {r0, r2, sl}
810:08000405 stmdaeqr0, {r0, r2, sl}
814:08000405 stmdaeqr0, {r0, r2, sl}
818:08000405 stmdaeqr0, {r0, r2, sl}
...
08000194 PASCALMAIN:
8000194:46ec movip, sp
8000196:e92d 4800 stmdbsp!, {fp, lr}
800019a:f1ac 0b04 sub.wfp, ip, #4
800019e:b08a subsp, #40; 0x28
80001a0:f000 f844 bl800022c FPC_INITIALIZEUNITS
80001a4:e004 b.n80001b0 PASCALMAIN+0x1c
80001a6:bf00 nop
80001a8:f44f 3000 mov.wr0, #131072; 0x2
80001ac:f7ff ffd8 bl8000160 P$PROGRAM_WAIT$LONGWORD
80001b0:e7fa b.n80001a8 PASCALMAIN+0x14
80001b2:f000 f8ff bl80003b4 FPC_DO_EXIT
80001b6:46dd movsp, fp
80001b8:b001 addsp, #4
80001ba:e91d 8800 ldmdbsp, {fp, pc}
80001be:bf00 nop
...
08000404 STM32F103__FPC_START:
8000404:e59f103c ldrr1, [pc, #60]; 8000448
STM32F103__FPC_START+0x44
8000408:e59f203c ldrr2, [pc, #60]; 800044c
STM32F103__FPC_START+0x48
800040c:e59f303c ldrr3, [pc, #60]; 8000450
STM32F103__FPC_START+0x4c
8000410:e1520003 cmpr2, r3
8000414:94910004 ldrlsr0, [r1], #4
First off 0x08000405 implies a thumb target but it is not thumb code,
it is arm code so 0x08000404 would be correct but that is still wrong
because cores with that vector table (cortex-m) cannot execute arm
instructions.
It implies thumb mode, which is the only valid mode on Cortex-M3
Looking at that first instruction in the reset handler
08000404 STM32F103__FPC_START:
8000404:e59f103c ldrr1, [pc, #60]; 8000448
STM32F103__FPC_START+0x44
The problem is that you are using an RTL built for ARM. That's what the
warning is about. You installed the compiler in /fpcarm, but it's using
units from /usr/local/lib/fpc/2.7.1/units/arm-embedded/rtl/
A correctly compiled unit would look like this:
STM32F103__FPC_START:
0: f8df 1034 ldr.w r1, [pc, #52] ; 38
STM32F103__FPC_START+0x38
4: 4a0dldr r2, [pc, #52] ; (3c
STM32F103__FPC_START+0x3c)
6: 4b0eldr r3, [pc, #56] ; (40
STM32F103__FPC_START+0x40)
8: 429acmp r2, r3
a: bf9eitttls
IPUBWL
1110 01011001 r15, r1, 0x03C
And that was properly decoded by objdump, immediate offset
rn+offset12, load, word sized, etc.
PC is 0x800040C at that time so load address is 0x800040C+0x03C =
0x8000448
You can tell both by 32 bit numbers in the dump but the dominance of
an 0xE as the first nibble also implies these are arm instructions not
thumb (need to see a long chunk of code to see the pattern). Had they
been thumb instructions but decoded wrong by the disassembler then the
first and fourth nibbles would have been dominated by like 6's and 7's
or at least would stand out compared to the other
nibbles.
if we decode this as thumb/thumb2
0xE59F
//B(2) unconditional branch
if((inst0xF800)==0xE000)
{
rb=(inst0)0x7FF;
if(rb(110)) rb|=(~0)11;
rb=1;
rb+=pc;
rb+=2;
write_register(15,rb);
return(0);
}
111001011001
11100 1011001
...111011001
...1110110010
...11 1011 0011 1110
pc = 0x405+4 = 0x409
pc + 0x...FFB3E =
0x409 - (0x4C1 + 1) = 0x747
Unconditional branch to 0x0747 so it is a valid
Re: [fpc-devel] Arm Thumb2 - Stellaris status
A! that makes sense. I assume that is either leftover from a prior build? And how do I get a new/fresh build to look in the right place? If I remove the offending fpc/2.7.1 directory and rebuild. (without trying to change the prefix) it puts the same stuff back in that directory: /opt/embarm/arm-embedded-ld: warning: library search path /usr/local/lib/fpc/2.7.1/units/arm-embedded/rtl/ is unsafe for cross-compilation Am I doing this wrong? make clean buildbase installbase CROSSINSTALL=1 OS_TARGET=embedded CPU_TARGET=arm If I change it to this? make clean buildbase installbase CROSSINSTALL=1 OS_TARGET=embedded CPU_TARGET=cortexm3 and provide the necessary cortexm3-embedded-* tools. make: -iVSPTPSOTO: Command not found make: -iSP: Command not found make: -iTP: Command not found make: -iSO: Command not found make: -iTO: Command not found Makefile:203: *** The Makefile doesn't support target cortexm3-embedded, please run fpcmake first. Stop. Thanks, David /usr/local/lib/fpc/2.7.1/units/arm-embedded/rtl/ is unsafe for cross-compilation The problem is that you are using an RTL built for ARM. That's what the warning is about. You installed the compiler in /fpcarm, but it's using units from /usr/local/lib/fpc/2.7.1/units/arm-embedded/rtl/ A correctly compiled unit would look like this: STM32F103__FPC_START: 0: f8df 1034 ldr.w r1, [pc, #52] ; 38 STM32F103__FPC_START+0x38 4: 4a0d ldr r2, [pc, #52] ; (3c STM32F103__FPC_START+0x3c) 6: 4b0e ldr r3, [pc, #56] ; (40 STM32F103__FPC_START+0x40) 8: 429a cmp r2, r3 a: bf9e ittt ls ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Arm Thumb2 - Stellaris status
On 19 Aug 2011, at 04:28, John Clymer wrote:
Did an analysis of the Stellaris current product lineup, there are over 180
current Stellaris products on TI's selection guide. Boiling through the
FLASH and RAM availability, there are 31 unique configuratios of FLASH / SRAM
between those 180 devices. So, the case() statements in t_embed.pas will
have 31 more entries to completely support the entire line of Stellaris
processors (and a few more with products slated for future release).
could it not just be two numeric command line options which are used to write
the relevant strings to 'linkres'? This would be future proof.
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.)
Looking at RTL support. Currently for each ARM variant, they have a
contoller unit (the controllerunitstr entry). Inside the current controller
units, registers are defined. These registers definitions automatically
become part of the variable space of an application. Is the intent for ALL
controller registers be provided inside the RTL ? I would think this would
be better provided by outside files. (i.e. uses LM3S8962 - brings in a
file containing all the 8962 register definitions.)
I agree. The ones I included in 'stellaris.pas' were enough to get the basic
system working with a non-trival test and to give anybody who took it further
some suggestions which I found worked ok eg. putting the registers in absolute
records. Really they should all be in separate files for each peripheral, then
you only need to include whichever ones are relevant to the device you are
actually using.
Having an outside file (it would be akin to a C header file - interface only
specifications for the registers, and that would be it) would be much clearer
than hiding the details inside a hidden file. If the user wants to chase
down exactly where the definition is coming from, using a non-RTL file saves
the user from having to dig through the compiler source to determine where it
was coming from. (Although for a newb, it may be preferable to have them
automatigically available.)
In fact I have subsequently been using the C header files for bit definitions
after conversion using h2pas. This saved a lot of time.
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.
Units are convenient too; you can include access methods alongside the register
definitions.
Geoffrey
John
From: Florian Klämpfl flor...@freepascal.org
To: FPC developers' list fpc-devel@lists.freepascal.org
Sent: Tue, August 9, 2011 7:59:06 PM
Subject: Re: [fpc-devel] Arm Thumb2 - Stellaris status
Am 09.08.2011 17:04, schrieb Jeppe Græsdal Johansen:
On 09-08-2011 15:53, Geoffrey Barton wrote:
On 9 Aug 2011, at 14:14, John Clymer wrote:
I was thinking more of a generic controller class, including a
memory.def (or whatever one wants to name it) file. That would be
easiest as it would only effect the t_embed.pas file (and cpuinfo.pas
file to add the generic type.)
Haven't looked into possibly a compiler option (and may easily be
more trouble than a command line option):
{$ARM_FLASH_START }
{$ARM_FLASH_LENGTH }
{$ARM_SRAM_START }
{$ARM_SRAM_LENGTH }
But, I still think a static memory definition file would require the
least amount of code changes. And would only effect only the ARM
related files.
The compiler option works well when you have conditional options for
different target builds using ifdefs, which I do I lot. It makes it
very easy to see if it is in the source file as it can be locked to
other options and you only need to select it in one place.
A separate linker file starts to make FPC handle like any other
compiler :( instead of the joy to use it is :)
I agree. Keeping the configurations in code is easier to manage,
Yes. I think as well that everything should stick in the compiler. FPC
is open source, so no need for a convolution of compiler support and
external files. Full support of all devices will lead to a huge number
of interwinded include files in the rtl anyways.
compared to the spiderweb of magically named files of other embedded
compilers
I think that maybe creating an abstract class hierachy of chip families,
instead of the current solution of a single large case statement, would
be a better solution in the long run
Well
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 http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Arm Thumb2 - Stellaris status
On 19 Aug 2011, at 09:19, Florian Klämpfl wrote: 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? because one is forever re-compiling the compiler when one switches to a device with a new peripheral, and if your main activity is not compiler development but product development one has to go back and find out how to do it each time. Better that the core stays the same. Geoffrey ___ 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] Arm Thumb2 - Stellaris status
Am 19.08.2011 10:33, schrieb Geoffrey Barton: because one is forever re-compiling the compiler when one switches to a device with a new peripheral, and if your main activity is not compiler development but product development one has to go back and find out how to do it each time. Better that the core stays the same. This is true, it makes things maybe easier for the first implementor, he hacks together some units and directives but it is harder for any latter user. He basically needs to do the same amount of work as the initial implementator: find out that he needs some directive, find the correct units etc. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Arm Thumb2 - Stellaris status
On 19 Aug 2011, at 09:55, Florian Klämpfl wrote: Am 19.08.2011 10:33, schrieb Geoffrey Barton: because one is forever re-compiling the compiler when one switches to a device with a new peripheral, and if your main activity is not compiler development but product development one has to go back and find out how to do it each time. Better that the core stays the same. This is true, it makes things maybe easier for the first implementor, he hacks together some units and directives but it is harder for any latter user. He basically needs to do the same amount of work as the initial implementator: find out that he needs some directive, find the correct units etc. exactly so, IMHO! (and in my own experience). If all he needs to add are a few peripheral definitions and drivers and there have been provided some examples of structures which work well in practice for these, a new user can be doing useful work very quickly and contributing to the collective knowledge from day one. G ___ 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] Arm Thumb2 - Stellaris status
Am 19.08.2011 11:07, schrieb Geoffrey Barton: On 19 Aug 2011, at 09:55, Florian Klämpfl wrote: Am 19.08.2011 10:33, schrieb Geoffrey Barton: because one is forever re-compiling the compiler when one switches to a device with a new peripheral, and if your main activity is not compiler development but product development one has to go back and find out how to do it each time. Better that the core stays the same. This is true, it makes things maybe easier for the first implementor, he hacks together some units and directives but it is harder for any latter user. He basically needs to do the same amount of work as the initial implementator: find out that he needs some directive, find the correct units etc. exactly so, IMHO! (and in my own experience). If all he needs to add are a few peripheral definitions and drivers and there have been provided some examples of structures which work well in practice for these, a new user can be doing useful work very quickly and contributing to the collective knowledge from day one. What I mean is: if the first user of a controller does things properly (create startup and interface unit, extend t_embedded.pas), subsequent users of the same controller have much less work, they need only to pass the correct parameter to the compiler and not to fiddle with configuration files, directives etc. The compiler takes care of everything. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Arm Thumb2 - Stellaris status
On 19 Aug 2011, at 10:10, Florian Klämpfl wrote: Am 19.08.2011 11:07, schrieb Geoffrey Barton: On 19 Aug 2011, at 09:55, Florian Klämpfl wrote: Am 19.08.2011 10:33, schrieb Geoffrey Barton: because one is forever re-compiling the compiler when one switches to a device with a new peripheral, and if your main activity is not compiler development but product development one has to go back and find out how to do it each time. Better that the core stays the same. This is true, it makes things maybe easier for the first implementor, he hacks together some units and directives but it is harder for any latter user. He basically needs to do the same amount of work as the initial implementator: find out that he needs some directive, find the correct units etc. exactly so, IMHO! (and in my own experience). If all he needs to add are a few peripheral definitions and drivers and there have been provided some examples of structures which work well in practice for these, a new user can be doing useful work very quickly and contributing to the collective knowledge from day one. What I mean is: if the first user of a controller does things properly (create startup and interface unit, extend t_embedded.pas), subsequent users of the same controller have much less work, they need only to pass the correct parameter to the compiler and not to fiddle with configuration files, directives etc. The compiler takes care of everything. and I agree with you 100%. as the 'first user' though I had other pressures on me, such as having to prove that using FPC on Stellaris was viable so that I could avoid being forced into writing in C. I therefore concentrated on the one device I had on the evm; maybe thats what everybody does. Then one looks for the time to tidy things up, or for someone else to come along wanting to go the same route and needing a jump-start. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Arm Thumb2 - Stellaris status
So, consensus is to include the register definitions - then I will work on these. To get all the possible register structures for all possible peripherals will take some time. And naming conventions come into play as well. I prefer having my device registers defined in structures. Other people prefer non-structured flat definitions for the registers. i.e. PortA - DDR PortA - PIN vs. DDRA PINA The current stellaris has a start for structures, unless there are objections, I would continue with these. The actual names of the registers will be best to match the datasheet (otherwise, non-compiler writing / source reading people will need a manual [and somewhat lengthy one at that] to provide the correcting naming of each peripheral and register.) BUT - there is no standard for what the peripheral structure instances should be named - so again, this would need to be documented if the target audience is people that won't be tearing the compiler apart. [And again, more work...] John From: Geoffrey Barton m...@periphon.net To: FPC developers' list fpc-devel@lists.freepascal.org Sent: Fri, August 19, 2011 1:19:38 PM Subject: Re: [fpc-devel] Arm Thumb2 - Stellaris status On 19 Aug 2011, at 10:10, Florian Klämpfl wrote: Am 19.08.2011 11:07, schrieb Geoffrey Barton: On 19 Aug 2011, at 09:55, Florian Klämpfl wrote: Am 19.08.2011 10:33, schrieb Geoffrey Barton: because one is forever re-compiling the compiler when one switches to a device with a new peripheral, and if your main activity is not compiler development but product development one has to go back and find out how to do it each time. Better that the core stays the same. This is true, it makes things maybe easier for the first implementor, he hacks together some units and directives but it is harder for any latter user. He basically needs to do the same amount of work as the initial implementator: find out that he needs some directive, find the correct units etc. exactly so, IMHO! (and in my own experience). If all he needs to add are a few peripheral definitions and drivers and there have been provided some examples of structures which work well in practice for these, a new user can be doing useful work very quickly and contributing to the collective knowledge from day one. What I mean is: if the first user of a controller does things properly (create startup and interface unit, extend t_embedded.pas), subsequent users of the same controller have much less work, they need only to pass the correct parameter to the compiler and not to fiddle with configuration files, directives etc. The compiler takes care of everything. and I agree with you 100%. as the 'first user' though I had other pressures on me, such as having to prove that using FPC on Stellaris was viable so that I could avoid being forced into writing in C. I therefore concentrated on the one device I had on the evm; maybe thats what everybody does. Then one looks for the time to tidy things up, or for someone else to come along wanting to go the same route and needing a jump-start. ___ 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] Arm Thumb2 - Stellaris status
Am 19.08.2011 12:02, schrieb John Clymer: So, consensus is to include the register definitions - then I will work on these. To get all the possible register structures for all possible peripherals will take some time. And naming conventions come into play as well. I prefer having my device registers defined in structures. Other people prefer non-structured flat definitions for the registers. i.e. PortA - DDR PortA - PIN vs. DDRA PINA The current stellaris has a start for structures, unless there are objections, I would continue with these. The actual names of the registers will be best to match the datasheet (otherwise, non-compiler writing / source reading people will need a manual [and somewhat lengthy one at that] to provide the correcting naming of each peripheral and register.) BUT - there is no standard for what the peripheral structure instances should be named - so again, this would need to be documented if the target audience is people that won't be tearing the compiler apart. [And again, more work...] Afaik there is a standard for the Cortex platform how to do it, google for ARM Cortex Microcontroller Software Interface Standard ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Arm Thumb2 - Stellaris status
On 19 Aug 2011, at 11:11, Florian Klämpfl wrote: Am 19.08.2011 12:02, schrieb John Clymer: So, consensus is to include the register definitions - then I will work on these. To get all the possible register structures for all possible peripherals will take some time. And naming conventions come into play as well. I prefer having my device registers defined in structures. Other people prefer non-structured flat definitions for the registers. i.e. PortA - DDR PortA - PIN surely porta.ddr vs. DDRA PINA The current stellaris has a start for structures, unless there are objections, I would continue with these. The actual names of the registers will be best to match the datasheet (otherwise, non-compiler writing / source reading people will need a manual [and somewhat lengthy one at that] to provide the correcting naming of each peripheral and register.) yes, it would be best to take them from the C definitions in 'stellarisware'. I shortened and changed some of them as they were unnecessarily flowery or obscure. BUT - there is no standard for what the peripheral structure instances should be named - so again, this would need to be documented if the target audience is people that won't be tearing the compiler apart. [And again, more work...] Afaik there is a standard for the Cortex platform how to do it, google for ARM Cortex Microcontroller Software Interface Standard there is a generic doc on the arm.com site and a stellaris specific one on the TI site. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Arm Thumb2 - Stellaris status
On Aug 19, 2011 7:13 AM, Geoffrey Barton m...@periphon.net wrote: Afaik there is a standard for the Cortex platform how to do it, google for ARM Cortex Microcontroller Software Interface Standard there is a generic doc on the arm.com site and a stellaris specific one on the TI site. Following the CMSIS would definitely make development easier, but it comes with a tradeoff. The generic nature of it makes it very wordy and somewhat inefficient (sometimes you have to make several function calls to do what a single assign could do). If possible, it might be best to have the compiler expose the raw registers, and add CMSIS as a unit that can be included in your application source. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Arm Thumb2 - Stellaris status
Did an analysis of the Stellaris current product lineup, there are over 180
current Stellaris products on TI's selection guide. Boiling through the FLASH
and RAM availability, there are 31 unique configuratios of FLASH / SRAM between
those 180 devices. So, the case() statements in t_embed.pas will have 31 more
entries to completely support the entire line of Stellaris processors (and a
few
more with products slated for future release).
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.)
Looking at RTL support. Currently for each ARM variant, they have a contoller
unit (the controllerunitstr entry). Inside the current controller units,
registers are defined. These registers definitions automatically become part
of the variable space of an application. Is the intent for ALL controller
registers be provided inside the RTL ? I would think this would be better
provided by outside files. (i.e. uses LM3S8962 - brings in a file
containing
all the 8962 register definitions.)
Having an outside file (it would be akin to a C header file - interface only
specifications for the registers, and that would be it) would be much clearer
than hiding the details inside a hidden file. If the user wants to chase
down
exactly where the definition is coming from, using a non-RTL file saves the
user
from having to dig through the compiler source to determine where it was coming
from. (Although for a newb, it may be preferable to have them automatigically
available.)
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.
John
From: Florian Klämpfl flor...@freepascal.org
To: FPC developers' list fpc-devel@lists.freepascal.org
Sent: Tue, August 9, 2011 7:59:06 PM
Subject: Re: [fpc-devel] Arm Thumb2 - Stellaris status
Am 09.08.2011 17:04, schrieb Jeppe Græsdal Johansen:
On 09-08-2011 15:53, Geoffrey Barton wrote:
On 9 Aug 2011, at 14:14, John Clymer wrote:
I was thinking more of a generic controller class, including a
memory.def (or whatever one wants to name it) file. That would be
easiest as it would only effect the t_embed.pas file (and cpuinfo.pas
file to add the generic type.)
Haven't looked into possibly a compiler option (and may easily be
more trouble than a command line option):
{$ARM_FLASH_START }
{$ARM_FLASH_LENGTH }
{$ARM_SRAM_START }
{$ARM_SRAM_LENGTH }
But, I still think a static memory definition file would require the
least amount of code changes. And would only effect only the ARM
related files.
The compiler option works well when you have conditional options for
different target builds using ifdefs, which I do I lot. It makes it
very easy to see if it is in the source file as it can be locked to
other options and you only need to select it in one place.
A separate linker file starts to make FPC handle like any other
compiler :( instead of the joy to use it is :)
I agree. Keeping the configurations in code is easier to manage,
Yes. I think as well that everything should stick in the compiler. FPC
is open source, so no need for a convolution of compiler support and
external files. Full support of all devices will lead to a huge number
of interwinded include files in the rtl anyways.
compared to the spiderweb of magically named files of other embedded
compilers
I think that maybe creating an abstract class hierachy of chip families,
instead of the current solution of a single large case statement, would
be a better solution in the long run
Well, it can be done also by some sets like
controllers_stellaris128flash64ram. I don't think that a big full
fledged class hierary is needed. Even the case statement might be
sufficient.
___
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] Arm Thumb2 - Stellaris status
On 8 Aug 2011, at 21:13, Florian Klämpfl wrote: Am 08.08.2011 12:49, schrieb John Clymer: Kicking it around in the back of my head at work today... I tried doing a compile to assembly language for the stellaris - and it choked giving the error from t_embed.pas. The error comes from the portion of the program trying to generate a linker script. Looking at t_embed.pas, it looks like every single flavor of ARM controller will require it's own subsection of the case() statement. This can easily get long and ugly. As the only thing that changes between most of the arm variants is the memory layout - why not provide a generic stellaris switch - with reads in a text file containing the memory map and stack top (the rest of the link file remains the same for all variants of ARM) ? This way - switching to a new variant of stellaris only requires tweaking a memory map file - rather than a re-build and patch of t_embed.pas ? For that matter - entirely foreign Cortex M3 parts could be easily supported without requiring changes to the compiler. Just pondering how to make it easier and more flexible ... Yes, this can be done. However, somebody who knows enough about a certain controller family must do this. What in your view is the best way to separate link options such as these variations in memory maps between devices? I often have several projects at once and they can be using different parts within the same family; having to re-compile the compiler when switching between projects is not ideal. ___ 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] Arm Thumb2 - Stellaris status
-Message d'origine- De : fpc-devel-boun...@lists.freepascal.org [mailto:fpc-devel- boun...@lists.freepascal.org] De la part de Geoffrey Barton Envoyé : mardi 9 août 2011 10:20 À : FPC developers' list Objet : Re: [fpc-devel] Arm Thumb2 - Stellaris status On 8 Aug 2011, at 21:13, Florian Klämpfl wrote: Am 08.08.2011 12:49, schrieb John Clymer: Kicking it around in the back of my head at work today... I tried doing a compile to assembly language for the stellaris - and it choked giving the error from t_embed.pas. The error comes from the portion of the program trying to generate a linker script. Looking at t_embed.pas, it looks like every single flavor of ARM controller will require it's own subsection of the case() statement. This can easily get long and ugly. As the only thing that changes between most of the arm variants is the memory layout - why not provide a generic stellaris switch - with reads in a text file containing the memory map and stack top (the rest of the link file remains the same for all variants of ARM) ? This way - switching to a new variant of stellaris only requires tweaking a memory map file - rather than a re-build and patch of t_embed.pas ? For that matter - entirely foreign Cortex M3 parts could be easily supported without requiring changes to the compiler. Just pondering how to make it easier and more flexible ... Yes, this can be done. However, somebody who knows enough about a certain controller family must do this. What in your view is the best way to separate link options such as these variations in memory maps between devices? I often have several projects at once and they can be using different parts within the same family; having to re-compile the compiler when switching between projects is not ideal. What about adding some command line options similar to -WB: -WB4 sets the default load address of Windows PE executables to 0x4. Its value is stored in global variable ImageBase. If only four or five values need to be set, we could just implement option -WE option: E for embedded, with -WEFlashOriginHexDecimalValue -WEFlashLengthHexDecimalValue -WERamOriginHexDecimalValue -WERamLengthHexDecimalValue -WEStackTopHexDecimalValue Of course, this depends if the list of required values is limited or not. Another problem is if the script should include or not those lines. But here also, we could create a list of args, some would be tagged as having a default value, which would be used if no command line option is given, while other args would have no default, meaning that the linker line would only be inserted if the corresponding value are set at command line. If that case, it might be better to combine Origin and Length into a unique argument -WEFlashHexValueOfOrigin-HexValueOfLength where HexValueOfOrigin and HexValueOfLength would both bereplaced by the valid values in order to avoid having only Origin and no Length for Flash (or Ram, or anything else that would be needed). Maybe a special 'custom' controller type would be handy for this... Pierre Muller ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Arm Thumb2 - Stellaris status
I was thinking more of a generic controller class, including a memory.def (or
whatever one wants to name it) file. That would be easiest as it would only
effect the t_embed.pas file (and cpuinfo.pas file to add the generic type.)
Haven't looked into possibly a compiler option (and may easily be more trouble
than a command line option):
{$ARM_FLASH_START }
{$ARM_FLASH_LENGTH }
{$ARM_SRAM_START }
{$ARM_SRAM_LENGTH }
But, I still think a static memory definition file would require the least
amount of code changes. And would only effect only the ARM related files.
John
From: Pierre Free Pascal pie...@freepascal.org
To: FPC developers' list fpc-devel@lists.freepascal.org
Sent: Tue, August 9, 2011 1:00:53 PM
Subject: RE: [fpc-devel] Arm Thumb2 - Stellaris status
-Message d'origine-
De : fpc-devel-boun...@lists.freepascal.org [mailto:fpc-devel-
boun...@lists.freepascal.org] De la part de Geoffrey Barton
Envoyé : mardi 9 août 2011 10:20
À : FPC developers' list
Objet : Re: [fpc-devel] Arm Thumb2 - Stellaris status
On 8 Aug 2011, at 21:13, Florian Klämpfl wrote:
Am 08.08.2011 12:49, schrieb John Clymer:
Kicking it around in the back of my head at work today...
I tried doing a compile to assembly language for the stellaris - and it
choked giving the error from t_embed.pas. The error comes from the
portion of the program trying to generate a linker script.
Looking at t_embed.pas, it looks like every single flavor of ARM
controller will require it's own subsection of the case() statement.
This can easily get long and ugly. As the only thing that changes
between most of the arm variants is the memory layout - why not provide
a generic stellaris switch - with reads in a text file containing the
memory map and stack top (the rest of the link file remains the same
for
all variants of ARM) ?
This way - switching to a new variant of stellaris only requires
tweaking a memory map file - rather than a re-build and patch of
t_embed.pas ? For that matter - entirely foreign Cortex M3 parts could
be easily supported without requiring changes to the compiler.
Just pondering how to make it easier and more flexible ...
Yes, this can be done. However, somebody who knows enough about a
certain controller family must do this.
What in your view is the best way to separate link options such as these
variations in memory maps between devices? I often have several projects
at
once and they can be using different parts within the same family; having
to
re-compile the compiler when switching between projects is not ideal.
What about adding some command line options
similar to -WB:
-WB4
sets the default load address of Windows PE executables
to 0x4. Its value is stored in global variable ImageBase.
If only four or five values need to be set, we could just
implement option -WE option:
E for embedded,
with
-WEFlashOriginHexDecimalValue
-WEFlashLengthHexDecimalValue
-WERamOriginHexDecimalValue
-WERamLengthHexDecimalValue
-WEStackTopHexDecimalValue
Of course, this depends if the list of required values is limited or not.
Another problem is if the script should include or not those
lines.
But here also, we could create a list of args,
some would be tagged as having a default value, which would be used
if no command line option is given, while other args would
have no default, meaning that the linker line would only be inserted
if the corresponding value are set at command line.
If that case, it might be better to combine Origin and Length into a
unique
argument
-WEFlashHexValueOfOrigin-HexValueOfLength
where HexValueOfOrigin and HexValueOfLength would both bereplaced by
the valid values in order to avoid having only Origin and no Length for
Flash (or Ram, or anything else that would be needed).
Maybe a special 'custom' controller type would be handy for this...
Pierre Muller
___
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] Arm Thumb2 - Stellaris status
On 9 Aug 2011, at 14:14, John Clymer wrote:
I was thinking more of a generic controller class, including a memory.def (or
whatever one wants to name it) file. That would be easiest as it would only
effect the t_embed.pas file (and cpuinfo.pas file to add the generic type.)
Haven't looked into possibly a compiler option (and may easily be more
trouble than a command line option):
{$ARM_FLASH_START }
{$ARM_FLASH_LENGTH }
{$ARM_SRAM_START }
{$ARM_SRAM_LENGTH }
But, I still think a static memory definition file would require the least
amount of code changes. And would only effect only the ARM related files.
The compiler option works well when you have conditional options for different
target builds using ifdefs, which I do I lot. It makes it very easy to see if
it is in the source file as it can be locked to other options and you only need
to select it in one place.
A separate linker file starts to make FPC handle like any other compiler :(
instead of the joy to use it is :)
Geoffrey
John
From: Pierre Free Pascal pie...@freepascal.org
To: FPC developers' list fpc-devel@lists.freepascal.org
Sent: Tue, August 9, 2011 1:00:53 PM
Subject: RE: [fpc-devel] Arm Thumb2 - Stellaris status
-Message d'origine-
De : fpc-devel-boun...@lists.freepascal.org [mailto:fpc-devel-
boun...@lists.freepascal.org] De la part de Geoffrey Barton
Envoyé : mardi 9 août 2011 10:20
À : FPC developers' list
Objet : Re: [fpc-devel] Arm Thumb2 - Stellaris status
On 8 Aug 2011, at 21:13, Florian Klämpfl wrote:
Am 08.08.2011 12:49, schrieb John Clymer:
Kicking it around in the back of my head at work today...
I tried doing a compile to assembly language for the stellaris - and it
choked giving the error from t_embed.pas. The error comes from the
portion of the program trying to generate a linker script.
Looking at t_embed.pas, it looks like every single flavor of ARM
controller will require it's own subsection of the case() statement.
This can easily get long and ugly. As the only thing that changes
between most of the arm variants is the memory layout - why not provide
a generic stellaris switch - with reads in a text file containing the
memory map and stack top (the rest of the link file remains the same
for
all variants of ARM) ?
This way - switching to a new variant of stellaris only requires
tweaking a memory map file - rather than a re-build and patch of
t_embed.pas ? For that matter - entirely foreign Cortex M3 parts could
be easily supported without requiring changes to the compiler.
Just pondering how to make it easier and more flexible ...
Yes, this can be done. However, somebody who knows enough about a
certain controller family must do this.
What in your view is the best way to separate link options such as these
variations in memory maps between devices? I often have several projects
at
once and they can be using different parts within the same family; having
to
re-compile the compiler when switching between projects is not ideal.
What about adding some command line options
similar to -WB:
-WB4
sets the default load address of Windows PE executables
to 0x4. Its value is stored in global variable ImageBase.
If only four or five values need to be set, we could just
implement option -WE option:
E for embedded,
with
-WEFlashOriginHexDecimalValue
-WEFlashLengthHexDecimalValue
-WERamOriginHexDecimalValue
-WERamLengthHexDecimalValue
-WEStackTopHexDecimalValue
Of course, this depends if the list of required values is limited or not.
Another problem is if the script should include or not those
lines.
But here also, we could create a list of args,
some would be tagged as having a default value, which would be used
if no command line option is given, while other args would
have no default, meaning that the linker line would only be inserted
if the corresponding value are set at command line.
If that case, it might be better to combine Origin and Length into a
unique
argument
-WEFlashHexValueOfOrigin-HexValueOfLength
where HexValueOfOrigin and HexValueOfLength would both bereplaced by
the valid values in order to avoid having only Origin and no Length for
Flash (or Ram, or anything else that would be needed).
Maybe a special 'custom' controller type would be handy for this...
Pierre Muller
___
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] Arm Thumb2 - Stellaris status
For what it's worth, IAR's C compiler for Cortex-M3 uses an ICF file
to hold that information, so there is precedent for doing it that way.
It holds the following (edited slightly to remove fluff):
define symbol __ICFEDIT_intvec_start__ = 0x0800;
define symbol __ICFEDIT_region_ROM_start__ = 0x08EC;
define symbol __ICFEDIT_region_ROM_end__ = 0x0801EFFF;
define symbol __ICFEDIT_region_RAM_start__ = 0x2000;
define symbol __ICFEDIT_region_RAM_end__ = 0x20004FFF;
define symbol __ICFEDIT_size_cstack__ = 0x400;
define symbol __ICFEDIT_size_heap__ = 0x4;
define memory mem with size = 4G;
define region ROM_region = mem:[from __ICFEDIT_region_ROM_start__
to __ICFEDIT_region_ROM_end__];
define region RAM_region = mem:[from __ICFEDIT_region_RAM_start__
to __ICFEDIT_region_RAM_end__];
define block CSTACKwith alignment = 8, size = __ICFEDIT_size_cstack__ { };
define block HEAP with alignment = 8, size = __ICFEDIT_size_heap__ { };
initialize by copy { readwrite };
do not initialize { section .noinit };
place at address mem:__ICFEDIT_intvec_start__ { readonly section .intvec };
place in ROM_region { readonly };
place in RAM_region { readwrite,
block CSTACK, block HEAP };
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Arm Thumb2 - Stellaris status
On 09-08-2011 15:53, Geoffrey Barton wrote:
On 9 Aug 2011, at 14:14, John Clymer wrote:
I was thinking more of a generic controller class, including a
memory.def (or whatever one wants to name it) file. That would be
easiest as it would only effect the t_embed.pas file (and cpuinfo.pas
file to add the generic type.)
Haven't looked into possibly a compiler option (and may easily be
more trouble than a command line option):
{$ARM_FLASH_START }
{$ARM_FLASH_LENGTH }
{$ARM_SRAM_START }
{$ARM_SRAM_LENGTH }
But, I still think a static memory definition file would require the
least amount of code changes. And would only effect only the ARM
related files.
The compiler option works well when you have conditional options for
different target builds using ifdefs, which I do I lot. It makes it
very easy to see if it is in the source file as it can be locked to
other options and you only need to select it in one place.
A separate linker file starts to make FPC handle like any other
compiler :( instead of the joy to use it is :)
I agree. Keeping the configurations in code is easier to manage,
compared to the spiderweb of magically named files of other embedded
compilers
I think that maybe creating an abstract class hierachy of chip families,
instead of the current solution of a single large case statement, would
be a better solution in the long run
Geoffrey
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Arm Thumb2 - Stellaris status
DaWorm schrieb: For what it's worth, IAR's C compiler for Cortex-M3 uses an ICF file to hold that information, so there is precedent for doing it that way. It holds the following (edited slightly to remove fluff): [...] IMO these are all values required by the linker, not by the compiler itself. Both an internal or external linker should read these definitions from an ICF (or similar) file. The name of that file, or of the concrete device, can be passed to the linker as a commandline argument. Some tables (devices) can be added to the linker code, of course, in detail when the devices also require specific linker code (in subclasses). [dunno about concrete requirements] DoDi ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Arm Thumb2 - Stellaris status
Am 09.08.2011 17:04, schrieb Jeppe Græsdal Johansen:
On 09-08-2011 15:53, Geoffrey Barton wrote:
On 9 Aug 2011, at 14:14, John Clymer wrote:
I was thinking more of a generic controller class, including a
memory.def (or whatever one wants to name it) file. That would be
easiest as it would only effect the t_embed.pas file (and cpuinfo.pas
file to add the generic type.)
Haven't looked into possibly a compiler option (and may easily be
more trouble than a command line option):
{$ARM_FLASH_START }
{$ARM_FLASH_LENGTH }
{$ARM_SRAM_START }
{$ARM_SRAM_LENGTH }
But, I still think a static memory definition file would require the
least amount of code changes. And would only effect only the ARM
related files.
The compiler option works well when you have conditional options for
different target builds using ifdefs, which I do I lot. It makes it
very easy to see if it is in the source file as it can be locked to
other options and you only need to select it in one place.
A separate linker file starts to make FPC handle like any other
compiler :( instead of the joy to use it is :)
I agree. Keeping the configurations in code is easier to manage,
Yes. I think as well that everything should stick in the compiler. FPC
is open source, so no need for a convolution of compiler support and
external files. Full support of all devices will lead to a huge number
of interwinded include files in the rtl anyways.
compared to the spiderweb of magically named files of other embedded
compilers
I think that maybe creating an abstract class hierachy of chip families,
instead of the current solution of a single large case statement, would
be a better solution in the long run
Well, it can be done also by some sets like
controllers_stellaris128flash64ram. I don't think that a big full
fledged class hierary is needed. Even the case statement might be
sufficient.
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Arm Thumb2 - Stellaris status
On 7 Aug 2011, at 11:14, John Clymer wrote:
Ok. Give me a week or so (very hectic schedule right now...) And I will see
if I can't patch it up some.
To save you some time perhaps, the following was for lm3s9b92 and
rtl/embedded/arm/stellaris.pas; I only tested with that device:-
1 in cpuinfo.pas, tcontrollertype should include, ct_lm3s9b92 rather
than stellaris
2 also 'stellaris' in controllerunitstr should be 'lm3s9b92
3 in compiler/systems/t_embed.pas add:-
ct_lm3s9b92:
with linkres do
begin
Add('ENTRY(_START)');
Add('MEMORY');
Add('{');
Add('flash : ORIGIN = 0x, LENGTH = 256K');
Add('ram : ORIGIN = 0x2000, LENGTH = 96K');
Add('}');
Add('_stack_top = 0x20017FFC;');
end;
I also found I needed to comment out the controller types other than stellaris
in rtl/embedded/makefile.fpc.
Then remake make,and make the compiler.
New to this - what is procedure to generate and submit patch set ?
+1
but Florian did offer to integrate any updates himself :)
Geoffrey
Thanks !
From: Florian Klämpfl flor...@freepascal.org
To: FPC developers' list fpc-devel@lists.freepascal.org
Sent: Sun, August 7, 2011 12:15:02 AM
Subject: Re: [fpc-devel] Arm Thumb2 - Stellaris status
Am 06.08.2011 13:35, schrieb John Clymer:
Ok, maybe I'm missing something...
I can compile and get a binary for an STM32F103RE. However, if I
attempt for the STELLARIS target, I get an error. I see where the error
is coming from in t_embed.pas. It looks like the t_embed.pas file is
missing linking information for the Stellaris.
Yes. arm embedded devices are only supported as far as somebody
contributed the compiler and rtl support. Problem is: we don't have any
chance to test it, so only users of these devices can contribute the
support.
Can someone confirm this
is the case before I go on a wild chase changing things ?
___
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] Arm Thumb2 - Stellaris status
On Sun, Aug 7, 2011 at 12:14 PM, John Clymer j...@johnclymer.net wrote: New to this - what is procedure to generate and submit patch set ? http://wiki.lazarus.freepascal.org/Creating_A_Patch -- Felipe Monteiro de Carvalho ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Arm Thumb2 - Stellaris status
Kicking it around in the back of my head at work today...
I tried doing a compile to assembly language for the stellaris - and it choked
giving the error from t_embed.pas. The error comes from the portion of the
program trying to generate a linker script.
Looking at t_embed.pas, it looks like every single flavor of ARM controller
will
require it's own subsection of the case() statement. This can easily get long
and ugly. As the only thing that changes between most of the arm variants is
the memory layout - why not provide a generic stellaris switch - with reads
in
a text file containing the memory map and stack top (the rest of the link file
remains the same for all variants of ARM) ?
This way - switching to a new variant of stellaris only requires tweaking a
memory map file - rather than a re-build and patch of t_embed.pas ? For that
matter - entirely foreign Cortex M3 parts could be easily supported without
requiring changes to the compiler.
Just pondering how to make it easier and more flexible ...
From: Geoffrey Barton m...@periphon.net
To: FPC developers' list fpc-devel@lists.freepascal.org
Sent: Mon, August 8, 2011 12:17:03 PM
Subject: Re: [fpc-devel] Arm Thumb2 - Stellaris status
On 7 Aug 2011, at 11:14, John Clymer wrote:
Ok. Give me a week or so (very hectic schedule right now...) And I will see
if
I can't patch it up some.
To save you some time perhaps, the following was for lm3s9b92 and
rtl/embedded/arm/stellaris.pas; I only tested with that device:-
1in cpuinfo.pas, tcontrollertype should include, ct_lm3s9b92 rather than
stellaris
2also 'stellaris' in controllerunitstr should be 'lm3s9b92
3in compiler/systems/t_embed.pas add:-
ct_lm3s9b92:
with linkres do
begin
Add('ENTRY(_START)');
Add('MEMORY');
Add('{');
Add('flash : ORIGIN = 0x, LENGTH = 256K');
Add('ram : ORIGIN = 0x2000, LENGTH = 96K');
Add('}');
Add('_stack_top = 0x20017FFC;');
end;
I also found I needed to comment out the controller types other than stellaris
in rtl/embedded/makefile.fpc.
Then remake make,and make the compiler.
New to this - what is procedure to generate and submit patch set ?
+1
but Florian did offer to integrate any updates himself :)
Geoffrey
Thanks !
From: Florian Klämpfl flor...@freepascal.org
To: FPC developers' list fpc-devel@lists.freepascal.org
Sent: Sun, August 7, 2011 12:15:02 AM
Subject: Re: [fpc-devel] Arm Thumb2 - Stellaris status
Am 06.08.2011 13:35, schrieb John Clymer:
Ok, maybe I'm missing something...
I can compile and get a binary for an STM32F103RE. However, if I
attempt for the STELLARIS target, I get an error. I see where the error
is coming from in t_embed.pas. It looks like the t_embed.pas file is
missing linking information for the Stellaris.
Yes. arm embedded devices are only supported as far as somebody
contributed the compiler and rtl support. Problem is: we don't have any
chance to test it, so only users of these devices can contribute the
support.
Can someone confirm this
is the case before I go on a wild chase changing things ?
___
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] Arm Thumb2 - Stellaris status
On 8 Aug 2011, at 11:49, John Clymer wrote:
Kicking it around in the back of my head at work today...
I tried doing a compile to assembly language for the stellaris - and it
choked giving the error from t_embed.pas. The error comes from the portion
of the program trying to generate a linker script.
Looking at t_embed.pas, it looks like every single flavor of ARM controller
will require it's own subsection of the case() statement. This can easily
get long and ugly. As the only thing that changes between most of the arm
variants is the memory layout - why not provide a generic stellaris switch
- with reads in a text file containing the memory map and stack top (the rest
of the link file remains the same for all variants of ARM) ?
yes, this could be applied to any of the M3 variants.
This way - switching to a new variant of stellaris only requires tweaking a
memory map file - rather than a re-build and patch of t_embed.pas ? For that
matter - entirely foreign Cortex M3 parts could be easily supported without
requiring changes to the compiler.
Just pondering how to make it easier and more flexible ...
absolutely, I did not go any further as I needed one particular controller at
the time to prove I could use FPC on a commercial project, so just hacked what
Jeppe had done. Really all the reg definitions can be separate too (and not in
stellaris.pas). Even the interrupts can be handled separately as you can flip
the NVIC into ram in your application, it just happened to be convenient to put
uart0 in stellaris.pas as this port is configured for debugging by default on
all the stellaris mcus.
From: Geoffrey Barton m...@periphon.net
To: FPC developers' list fpc-devel@lists.freepascal.org
Sent: Mon, August 8, 2011 12:17:03 PM
Subject: Re: [fpc-devel] Arm Thumb2 - Stellaris status
On 7 Aug 2011, at 11:14, John Clymer wrote:
Ok. Give me a week or so (very hectic schedule right now...) And I will
see if I can't patch it up some.
To save you some time perhaps, the following was for lm3s9b92 and
rtl/embedded/arm/stellaris.pas; I only tested with that device:-
1 in cpuinfo.pas, tcontrollertype should include, ct_lm3s9b92 rather
than stellaris
2 also 'stellaris' in controllerunitstr should be 'lm3s9b92
3 in compiler/systems/t_embed.pas add:-
ct_lm3s9b92:
with linkres do
begin
Add('ENTRY(_START)');
Add('MEMORY');
Add('{');
Add('flash : ORIGIN = 0x, LENGTH = 256K');
Add('ram : ORIGIN = 0x2000, LENGTH = 96K');
Add('}');
Add('_stack_top = 0x20017FFC;');
end;
I also found I needed to comment out the controller types other than
stellaris in rtl/embedded/makefile.fpc.
Then remake make,and make the compiler.
New to this - what is procedure to generate and submit patch set ?
+1
but Florian did offer to integrate any updates himself :)
Geoffrey
Thanks !
From: Florian Klämpfl flor...@freepascal.org
To: FPC developers' list fpc-devel@lists.freepascal.org
Sent: Sun, August 7, 2011 12:15:02 AM
Subject: Re: [fpc-devel] Arm Thumb2 - Stellaris status
Am 06.08.2011 13:35, schrieb John Clymer:
Ok, maybe I'm missing something...
I can compile and get a binary for an STM32F103RE. However, if I
attempt for the STELLARIS target, I get an error. I see where the error
is coming from in t_embed.pas. It looks like the t_embed.pas file is
missing linking information for the Stellaris.
Yes. arm embedded devices are only supported as far as somebody
contributed the compiler and rtl support. Problem is: we don't have any
chance to test it, so only users of these devices can contribute the
support.
Can someone confirm this
is the case before I go on a wild chase changing things ?
___
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
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Arm Thumb2 - Stellaris status
Am 08.08.2011 12:49, schrieb John Clymer: Kicking it around in the back of my head at work today... I tried doing a compile to assembly language for the stellaris - and it choked giving the error from t_embed.pas. The error comes from the portion of the program trying to generate a linker script. Looking at t_embed.pas, it looks like every single flavor of ARM controller will require it's own subsection of the case() statement. This can easily get long and ugly. As the only thing that changes between most of the arm variants is the memory layout - why not provide a generic stellaris switch - with reads in a text file containing the memory map and stack top (the rest of the link file remains the same for all variants of ARM) ? This way - switching to a new variant of stellaris only requires tweaking a memory map file - rather than a re-build and patch of t_embed.pas ? For that matter - entirely foreign Cortex M3 parts could be easily supported without requiring changes to the compiler. Just pondering how to make it easier and more flexible ... Yes, this can be done. However, somebody who knows enough about a certain controller family must do this. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Arm Thumb2 - Stellaris status
Ok. Give me a week or so (very hectic schedule right now...) And I will see if I can't patch it up some. New to this - what is procedure to generate and submit patch set ? Thanks ! From: Florian Klämpfl flor...@freepascal.org To: FPC developers' list fpc-devel@lists.freepascal.org Sent: Sun, August 7, 2011 12:15:02 AM Subject: Re: [fpc-devel] Arm Thumb2 - Stellaris status Am 06.08.2011 13:35, schrieb John Clymer: Ok, maybe I'm missing something... I can compile and get a binary for an STM32F103RE. However, if I attempt for the STELLARIS target, I get an error. I see where the error is coming from in t_embed.pas. It looks like the t_embed.pas file is missing linking information for the Stellaris. Yes. arm embedded devices are only supported as far as somebody contributed the compiler and rtl support. Problem is: we don't have any chance to test it, so only users of these devices can contribute the support. Can someone confirm this is the case before I go on a wild chase changing things ? ___ 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] Arm Thumb2 - Stellaris status
Ok, maybe I'm missing something... I can compile and get a binary for an STM32F103RE. However, if I attempt for the STELLARIS target, I get an error. I see where the error is coming from in t_embed.pas. It looks like the t_embed.pas file is missing linking information for the Stellaris. Can someone confirm this is the case before I go on a wild chase changing things ? Thanks, John Clymer___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Arm Thumb2 - Stellaris status
On 6 Aug 2011, at 12:35, John Clymer wrote: Ok, maybe I'm missing something... I can compile and get a binary for an STM32F103RE. However, if I attempt for the STELLARIS target, I get an error. I see where the error is coming from in t_embed.pas. It looks like the t_embed.pas file is missing linking information for the Stellaris. Can someone confirm this is the case before I go on a wild chase changing things ? Yes, it should have the part specific memory map there. Geoffrey Thanks, 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] Arm Thumb2 - Stellaris status
Am 06.08.2011 13:35, schrieb John Clymer: Ok, maybe I'm missing something... I can compile and get a binary for an STM32F103RE. However, if I attempt for the STELLARIS target, I get an error. I see where the error is coming from in t_embed.pas. It looks like the t_embed.pas file is missing linking information for the Stellaris. Yes. arm embedded devices are only supported as far as somebody contributed the compiler and rtl support. Problem is: we don't have any chance to test it, so only users of these devices can contribute the support. Can someone confirm this is the case before I go on a wild chase changing things ? ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
