Has anyone tried the embedded target in a while?
rev 19168 there was a change to heap.inc and other files I assume
* moved heap manager on embedded systems into a separate unit
* moved console io on embedded systems into a seperate unit, this unit
might setup input/output e.g. to be redirected
I tried a make build from the current svn tree and it fails to build
(mysqlcon something). apt-get is giving me 2.4.0, so still a big stuck.
David
On 10/19/2011 05:08 AM, Marco van de Voort wrote:
In our previous episode, Jeppe Gr?sdal Johansen said:
And from that point to the present (19
is there an svn release number that does compile with 2.4.0 that will
get me to 2.4.4 or better so that I can compile the trunk?
David
On 10/20/2011 02:06 AM, Sven Barth wrote:
Am 19.10.2011 15:55, schrieb Leonardo M. Ramé:
From: Paul Ishenin
To: ""Leonardo
With the cortex-m0 parts now hitting the market I think it is time to
bring up the topic of thumb support again, not arm not thumb2 but thumb
(the only common instruction set across almost the entire arm family
(the exception being the pre-armv4t)).
cortex-m0 and -m1 are armv6-m based, the -
Someone pointed me at this page:
http://wiki.freepascal.org/TARGET_Embedded
And I started adding a device (and perhaps more after that), starting
with a cortex-m3 though which is thumb/thumb2 only.
Following the instructions on the page work fine:
fpc -Parm -Tembedded -Wplpc2124 tled1.pp
A
Actually I would prefer thumb first then thumb2 cpuinfo.pas does not
have an architecture tied to thumb but the cortexm3 and armv7m can be
easily moved to thumb temporarily or create say a cpu_cortexm3_thumb in
the tcputype list, etc...
David
On 08/19/2011 11:00 PM, David Welch wrote
Sorry, figured it out -Cpcortexm3
On 08/19/2011 11:05 PM, David Welch wrote:
Actually I would prefer thumb first then thumb2 cpuinfo.pas does not
have an architecture tied to thumb but the cortexm3 and armv7m can be
easily moved to thumb temporarily or create say a cpu_cortexm3_thumb in
the
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 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 defi
humb2 - 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 a
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
rogram is free software; you may redistribute it under the terms of
the GNU General Public License version 3 or later.
This program has absolutely no warranty.
This assembler was configured for a target of `arm-none-eabi'.
So what did I do wrong? and what is the unsafe thing about?
Thanks,
Davi
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:
/op
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
except for a few older ARM's both platforms support thumb code, so
anything that is shared could be compiled for thumb with some target
specific trampolines to get there
ARM:
0x0: b _pre_start
...
_pre_start:
ldr r0,_start
bx r0
.pool
cortex-m3:
0x: _stac_top
0x0004:
All I am saying is thumb (not thumb2) is common between many ARM cores
and the cortex-m3. These lpc21xx parts use an ARM7TDMI which is an
ARMv4T and supports thumb. the lpc2000 are also ARM7TDMI's and LPC1000
is cortex-m0 which is the successor to cortex-m3 so no doubt it is
thumb/thumb2 ba
Most if not all of my references to thumb meant the original ARMv4T
thumb instruction set, definitely not the thumb2 extensions, nor ARMv5
or ARMv6 extensions.
If for example you had a thumb backend to fpc, you could easily solve
this problem, all of these libraries would run on both platfor
cpuinfo.pas(156,2) Fatal: Can't open include file "controllerunit.inc"
On 08/25/2011 05:50 PM, Florian Klämpfl wrote:
OS_TARGET=embedded CPU_TARGET=arm SUBARCH=cortexm3
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal
=/something/something/
--program-prefix=arm-embedded- --disable-werror
For the non-windows folks so we can play too. Too me a while to figure
out why I was not even able to build per the target embedded instructions.
Thanks,
David
On 08/25/2011 10:13 PM, David Welch wrote:
cpuinfo.pas(156,2) Fatal
>
> John
>
>
> ____
> From: David Welch
> To: FPC developers' list
> Sent: Fri, August 26, 2011 6:17:43 AM
> Subject: Re: [fpc-devel] DIFF patch for changing to table driven processor
> definitions for ARM
>
>
> Can someone with the power to updat
-only ARM
+David Welch 2011 08 26 (dwelch at dwelch com)
+based on lpc21x4 created by Sten Larsson (sten_larsson at yahoo com)
+}
+
+unit arm_bare_ram;
+
+{$goto on}
+
+ interface
+
+ implementation
+
+procedure PASCALMAIN; external name 'PASCALMAIN';
+
+procedure _FPC_haltproc;
when building for SUBARCH=cortexm3, fails with:
make[3]: *** No rule to make target `thumb2_bare.ppu', needed by
`fpc_units'. Stop.
On 08/26/2011 05:09 PM, David Welch wrote:
Another diff to be considered.
Index: rtl/embedded/arm/arm_b
One case would be as a framework to build other targets instead of
having to delete a bunch of stuff then add a bunch of stuff you just add
stuff.
I have an interest in a generic target where the target specific stuff
is not embedded in the compiler but is in the code. At the moment the
me
See attached.
Index: rtl/embedded/arm/lpc1768.pp
===
--- rtl/embedded/arm/lpc1768.pp (revision 0)
+++ rtl/embedded/arm/lpc1768.pp (revision 0)
@@ -0,0 +1,160 @@
+
+unit lpc1768;
+
+{$goto on}
+{$define lpc1768}
+
+interface
+
+var
24 matches
Mail list logo