I have found a way out.
You need to add 'CROSSOPT=-Cpcortexm3' at the end of the line:-
make clean buildbase installbase CROSSINSTALL=1 OS_TARGET=embedded
CPU_TARGET=arm SUBARCH=armv7m
in the wiki page.
Then the rtl builds in thumb2.
Geoffrey
On 21 Dec 2011, at 10:55, Geoffrey Ba
On 21 Dec 2011, at 10:43, fpc-devel-requ...@lists.freepascal.org wrote:
> From: Jeppe Græsdal Johansen
> Subject: Re: [fpc-devel] arm embedded on 2.6.0rc1
> Date: 20 December 2011 21:20:07 GMT
> To: FPC developers' list
> Reply-To: FPC developers' list
>
>
&
I have been trying to cross-compile arm embedded for a cortexm3 using 2.6.0rc1.
I had this working previously with 2.4.0 and stellaris controllers.
Following the instructions on the wiki page 'TARGET_Embedded' and adding
suitable devices into cpuinfo etc. where they have been missed out, I can b
ched 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
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 may
device info should go in the compiler. As there is no OS I think the minimal
RTL and info essential to the compiler/as/ld ie. flash, ram size, should be
there as compiler user options, but nothing device specific.
Geoffrey
>
> Thanks,
>
> John
>
> From: Geoffrey Barton
&g
On 21 Aug 2011, at 00:35, John Clymer wrote:
> DIFF attached for comment and review. Provides the following features /
> difference:
>
> 1) Switched operation of cpuinfo.pas - there is still a SET containing the
> ct_ constants, but that now indexes an array of structures rather than a
> col
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
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 int
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 conven
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
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
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
eemed 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
> To: FPC developers' list
> Sent:
On 16 Aug 2011, at 11:16, John Clymer wrote:
> Stellaris ALWAYS has the Code starting at $:.
>
> STM32's do something odd where the FLASH starts at $0800:, and the memory
> between $: and $07FF: is mappable to either the FLASH or the
> built-in boot loader. (Which thro
On 16 Aug 2011, at 04:39, John Clymer wrote:
> So, after some work, I have a compiler working for the LM3S8962 board (a
> successful Blinking LED :-) )
>
> However, as I was going through some of the various datasheets, I see that
> all the Stellaris controllers have similar memory maps. Tha
list
> 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
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 fro
aris.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
>
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
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
On 14 Jul 2010, at 17:35, Jonas Maebe wrote:
Geoffrey Barton wrote on Wed, 14 Jul 2010:
the resulting constant disassembles as:-
1bc:01a5.word 0x01a5
which seems to be one greater than the address of the procedure.
Is this right?
Yes.
If so, why?
To identify the
disassembling from an elf file produce by FPC cross-assembling for arm
embedded, an empty procedure:-
procedure UART0int:nostackframe;
begin
end;
looks like this:-
01a4 :
1a4: 46f7mov pc, lr
1a6: 46c0nop (mov r8, r8)
if I grab the ad
On 14 Jul 2010, at 10:49, Bernd Mueller wrote:
Michael Schnell wrote:
On 07/14/2010 11:02 AM, Bernd Mueller wrote:
... which could easily be done in gcc btw. ...
I'm quite sure that FPC's ASM can compile hex constants (using
"DC" ???)
that is not the point. You don't wont to bother with (
tex_m3
tech ref manuals.
primask is a (real as far as I can see) one bit register. I will try
flipping it on the hardware debugger and see if it changes anywhere
else...
rgds
Geoffrey
Geoffrey Barton skrev:
On 12 Jul 2010, at 19:06, Jeppe Johansen wrote:
Add the missing instructions to
rce.
(and then submit patch) :-)
well, once I have some code which works on the chip, I will ask
someone where to put it :-)
Geoffrey
Geoffrey Barton skrev:
I wrote a procedure to turn on interrupts:-
procedure intenable;nostackframe;
begin
asm
cpsie i
end;
end;
The compilation
yes, trying to :-) It is an embedded LM3S9B92 controller.
Geoffrey
On 13 Jul 2010, at 09:01, Michael Schnell wrote:
On 07/12/2010 06:24 PM, Geoffrey Barton wrote:
I wrote a procedure to turn on interrupts:-
Are you doing a project without an OS ?
-Michael
I wrote a procedure to turn on interrupts:-
procedure intenable;nostackframe;
begin
asm
cpsie i
end;
end;
The compilation fails with 'Error: Unrecognized opcode cpsie'
The compiler also does not recognise 'cpsid' and also 'primask' as in
'mrs r0,primask'
any ideas/workarounds?
Geo
7x256
endif"
it says:
"ifeq ($(ARCH),arm)
CPU_UNITS=stm32f103
endif"
Then run fpcmake -Tall in the rtl/embedded dir
Then you can build the compiler and rtl again using "make buildbase
CPU_TARGET=arm OS_TARGET=embedded CROSSINSTALL=1 CROSSOPT="-
Cpcortexm3 -O-""
Date: Mon, 19 Apr 2010 15:06:23 +0200
From: Jeppe Johansen
Subject: Re: [fpc-devel] arm embedded
To: FPC developers' list
Message-ID: <4bcc554f.9070...@kom.aau.dk>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
1)
stm32f103 is a thumb2 only device, and you cannot generate a rtl fo
On 19 Apr 2010, at 13:29, Geoffrey Barton wrote:
1 In the rtl/embedded/arm directory are three target processor
files. The one for stm32f103 does not get compiled into the units/
arm-embedded/rtl directory. I added it to the CPU_UNITS line in the
makefile.fpc in the embedded directory
Two related questions (FPC 2.5.1):-
1 In the rtl/embedded/arm directory are three target processor files.
The one for stm32f103 does not get compiled into the units/arm-
embedded/rtl directory. I added it to the CPU_UNITS line in the
makefile.fpc in the embedded directory before building ppc
On 3 Apr 2010, at 11:00, fpc-devel-requ...@lists.freepascal.org wrote:
Message: 1
Date: Fri, 02 Apr 2010 12:42:37 +0200
From: Jeppe Johansen
Subject: Re: [fpc-devel] arm embedded
To: FPC developers' list
Message-ID: <4bb5ca1d.80...@kom.aau.dk>
Content-Type: text/plain; charset=ISO-8859-1; fo
I have been trying to build and run the arm embedded compiler as
instructed on http://wiki.freepascal.org/
Embedded#Adding_new_controllers on windowsXP. I had fpc version 2.4.0
installed (and working). I then installed the latest version from SVN.
I copied the file 'tled1.pp' into fpc and th
34 matches
Mail list logo
