Hi,
I am currently thinking about switching development from PIC-based
microcontrollers (based on mikroe compilers) to ARM Cortex-M3/4
controllers because they seem to be supported by fpc.
I have compiled latest binutils for arm based on instructions from the
wiki ( ./configure --target=arm-
I have tried to build the crosscompiler for arm-embedded for both
windows and mac host, both builds fail at the same line:
/bin/mkdir -p /Users/ring/devel/fpc/rtl/units/arm-embedded
/Users/ring/devel/fpc/compiler/ppcrossarm -Cparmv7m @rtl.cfg -Ur
-Tembedded -Parm -XParm-embedded- -Xr -Ur -Xs -O
Today I found some time to research since when excactly arm-embedded
does not compile anymore, I found that since revision 23325 compile does
not work anymore, can anybody help, it seems that the problem itself is
hidden somewhere else in code...
Michael
Error Message:
/bin/mkdir -p /Users/r
ror, the 'only' change is that sysutils gets
included in the build.
For now, how can I add "-mimplicit-it=thumb" to the as commandline
without my small hack? can I put this somewhere in fpc.cfg?
Michael
Am 19.01.13 16:19, schrieb Florian Klämpfl:
Am 19.01.2013 12:18, schrieb
command line you use for compiling?
Den 19-01-2013 22:58, Michael Ring skrev:
Thank you very much Florian, this problem is now indeed fixed. I have
encountered another one:
/Users/ring/devel/fpc/rtl/units/arm-embedded/sysutils.s: Assembler
messages:
/Users/ring/devel/fpc/rtl/units/arm-embedded
In the last days I have had a nice fight with lazarus-trunk, but it
seems I succeeded in the end ;-)
I have integrated openocd debugger class as a child of the gdbmi
debugger classes, basic code upload & debugging now works for me in
lazarus, still has some rough edges, this is why I am seekin
?
Which GDB version is your prefered version for debugging FreePascal?
Thank you again,
Michael
On 05/02/2013 22:14, Michael Ring wrote:
I have integrated openocd debugger class as a child of the gdbmi
debugger classes, basic code upload & debugging now works for me in
lazarus, still has
Yes, OpenOCD implements a gdbserver so debugging is done via gdb.
I did not want to break existing code so I created a new class based on
TGDBMIServerDebugger, this has been done before for the ssh based
debugging so I followed this road.
I will join the german lazarus forum, see you there...
Am 07.02.13 16:04, schrieb Martin:
On 07/02/2013 07:14, Michael Ring wrote:
One more thing, do you know why ExecuteCommand is defined as
protected and not public in GDBMIDebugger? I need to send some extra
commands to GDB to make the remote connection, using ExecuteCommand
is an elegant way
I have seen a lot of work on mpis platform in svn over the last weeks.
Are there plans to create a mips-embedded target or is this strictly
mips-linux?
I am asking because modern PIC32MX Controllers from Microchip are mips
based, I somehow prefer arm-microcontrollers but when you want to build
This all sounds promising, I can contribute definitions for PIC32MX1/MX2
series of controllers.
Michael
Am 17.02.13 09:21, schrieb Florian Klämpfl:
Am 14.02.2013 23:44, schrieb Michael Ring:
I have seen a lot of work on mpis platform in svn over the last weeks.
Are there plans to create a
that I feel the
urge to start before you I will definitely let you know, with some
guidance I should be able to get at least something basic working... ;-)
Michael
Am 17.02.13 15:11, schrieb Michel Catudal:
Le 2013-02-17 07:48, Michael Ring a écrit :
This all sounds promising, I can
I am not sure if I have hit work in progress code here
my arm-embedded app crashes during initialization, the reason is that
now exceptions are part of the rtl but there is no properly initialized
heapmanager:
Procedure InitExceptions;
{
Must install uncaught exception handler (ExceptPr
ation
//FinalizeHeap;
end.
Am 03.03.13 09:52, schrieb Florian Klämpfl:
Am 02.03.2013 23:17, schrieb Michael Ring:
I am not sure if I have hit work in progress code here
my arm-embedded app crashes during initialization, the reason is that
now exceptions are part of the rtl but there is no pro
using memory at address _stack_top - _stklen - _heapsize
Correct ??
Michael
Am 03.03.13 11:14, schrieb Sven Barth:
On 03.03.2013 11:04, Michael Ring wrote:
For a little more flexible solution I would like to ask you one more
questions, it may seem dumb to you but I have never been that deep into
I just saw that armv6m has showed up in the sourcecode of trunk version.
You guys are great, thank you very much
I just checked, I do have a LPCXpresso LPC812 Board here, now I can put
it to good use!
Michael
___
fpc-devel maillist - fpc-devel
I am running on a mac, building svn 23683
svn 23681 (one before implementation of armv6m) compiles fine.
commandline for building was:
make clean buildbase CROSSINSTALL=1 OS_TARGET=embedded CPU_TARGET=arm
SUBARCH=armv7m CROSSOPT="-gw2 -O-" BINUTILSPREFIX=arm-none-eabi-
make -C rtl all
make
open source.
Michael
Am 03.03.13 20:56, schrieb Florian Klämpfl:
Am 03.03.2013 19:51, schrieb Michael Ring:
I just saw that armv6m has showed up in the sourcecode of trunk version.
You guys are great, thank you very much
I just checked, I do have a LPCXpresso LPC812 Board here, now
>= @_bss_end then
+RegisterHeapBlock(_heap_start,_heapsize);
+
finalization
//FinalizeHeap;
end.
Am 03.03.13 20:09, schrieb Michael Ring:
I am running on a mac, building svn 23683
svn 23681 (one before implementation of armv6m) compiles fine.
commandline for building was:
ma
03.03.13 21:45, schrieb Florian Klämpfl:
> Am 03.03.2013 21:27, schrieb Michael Ring:
>> I have created a new patch, this time it uses the values of the two
>> commandline parameters -Ch and -Cs to set the size of Stack and Heap. I
>> am not sure if those params were for th
Verified, works again on my mac, TnX!
Michael
Am 03.03.13 23:00, schrieb Florian Klämpfl:
Am 03.03.2013 20:09, schrieb Michael Ring:
$
$00142333
$00144647
$00144B00
$001AF725
$001970A5
$0003295E
make[3]: *** [system.ppu] Error 217
make[2]: *** [embedded_all
I fould the following announcement:
http://article.gmane.org/gmane.comp.debugging.openocd.devel/17362
So ulink is supported by openocd, not sure if ulink2 is compatible with
ulink.
from what I have googled about ulink2 it seems that it is closely bound
to the uVision Debugger from Keil and t
Florian, did you find some spare time to work on this?
Michael
Am 03.03.13 22:59, schrieb Florian Klämpfl:
Am 03.03.2013 22:09, schrieb Michael Ring:
That would of course be even better, the compiler could calculate if
vars+stack+heap fit in the given memory configuration and issue at
minimum
://au.element14.com/stmicroelectronics/st-link/icd-programmer-for-stm8-stm32/dp/1779159
Kind Regards
Justin
*From:* Michael Ring <mailto:m...@michael-ring.org>
*Sent:* Thursday, March 14, 2013 12:25 AM
*To:* FPC developers' list <mailto:fpc-devel@lists.freepascal.org>
*Subject:* Re
Thany you very much, will give it a try later or tomorrow.
Michael
Am 16.03.13 11:37, schrieb Florian Klämpfl:
Am 03.03.2013 11:04, schrieb Michael Ring:
In r23853 I committed a patch which creates automatically a heap on the
embedded targets if heapmgr is used. Further, sysutils depends now
s, now some questions
On 07/02/2013 23:51, Michael Ring wrote:
Index: debugger/debugger.pp
===
--- debugger/debugger.pp(revision 40204)
+++ debugger/debugger.pp(working copy)
@@ -3304,6 +3304,7 @@
const
OLD_GDB_DBG
I have created some units for nxp cortex-m0 cpu's and have integrated
them into the arm-embedded rtl
but they fail to assemble, seems that the generated assembler code is
not cortex-m0 compatible !!??!!:
make clean buildbase CROSSINSTALL=1 OS_TARGET=embedded CPU_TARGET=arm
SUBARCH=armv6m CRO
Sorry, please ignore thismail, this is my fault, I have an error in the
cortexm0_start.inc code, sorry!
Am 20.04.13 22:12, schrieb Michael Ring:
I have created some units for nxp cortex-m0 cpu's and have integrated
them into the arm-embedded rtl
but they fail to assemble, seems tha
lso had a look at the changeset for avr-embedded, there were a
lot of changes in the codegen and other places, do you expect that the
same will need to be done for mips or was avr a special case?
Michael
Am 17.02.13 17:44, schrieb Michael Ring:
Your timeline sounds fine to me, I am currently q
Am 13.05.13 20:36, schrieb Florian Klämpfl:
Am 13.05.2013 20:07, schrieb Michael Ring:
OK, I got kind of bored last weekend and started to implement
mips-embedded target. The crosscompiler builds fine and already shows
the list of (not yet implemented) pic32mx controllers, I am now
searching
Am 14.05.13 08:47, schrieb Michael Schnell:
On 05/13/2013 08:07 PM, Michael Ring wrote:
... pic32mx controllers ...
BTW.:
AFAIK, the PIC controllers (16 and 32 Bit) use a propriety debug
interface to be accessed by "PICKit" an "ICD-3" adapters. They do use
a gnu base
Hi Michel!
You are talking about integrating mips into your debugger, what does
this mean? Are you talking about Setedit or something else?
Michael
Am 14.05.13 22:01, schrieb Michel Catudal:
Le 2013-05-14 06:13, Marco van de Voort a écrit :
In our previous episode, Michael Ring said:
I
If you find the time to find out how to actually start up & use their
gdbserver I will be more than happy to integrate it into lazarus, right
now I take what I can get and that seems to be openocd.
I have wasted quite some time in trying to make LPC-Link for the
LPCExpresso Boards work and I d
, that's pretty slow. I will check if a
j-link or st-link work better, but I do not have high hopes.
But perhaps the ejtagproxy or pic32prog can solve this problem, will
keep you posted.
Michael
Am 16.05.13 08:53, schrieb Michael Schnell:
On 05/15/2013 12:11 PM, Michael Ring wrote:
If you
://github.com/synthetos/PiOCD/wiki/Using-a-Raspberry-Pi-as-a-JTAG-Dongle
Michael
Am 15.05.13 23:48, schrieb Michel Catudal:
Le 2013-05-15 06:11, Michael Ring a écrit :
If you find the time to find out how to actually start up & use their gdbserver
I will be more than happy to integrate it
mance.
Michael
Am 16.05.13 09:55, schrieb Michael Ring:
Nice find, question is why did I not find this link ;-)
I etched some testboards yesterday and connected them to my
ARM-USB-TINY, openocd detects the chip just fine but Michel was right,
flash read performance is a mess, it took two minutes to
I was having troubles today installing ppcrossarm from trunk, I have a
workarround for the problem but I question myself how to really fix the
problem:
SUBARCH=armv7m
make clean buildbase CROSSINSTALL=1 OS_TARGET=embedded CPU_TARGET=arm
SUBARCH=$SUBARCH CROSSOPT="-godwarfsets -gw2 -O-"
BINUTI
28.05.13 10:59, schrieb Michael Ring:
I was having troubles today installing ppcrossarm from trunk, I have a
workarround for the problem but I question myself how to really fix
the problem:
SUBARCH=armv7m
make clean buildbase CROSSINSTALL=1 OS_TARGET=embedded CPU_TARGET=arm
SUBARCH=$SUBARCH
Thank you!
Michael
Am 28.05.13 14:56, schrieb Yury Sidorov:
Fixed in r24626. Your guesswork is right :)
Yury.
- Original Message - From: Michael Ring
To: fpc-devel@lists.freepascal.org
Sent: Tuesday, May 28, 2013 1:24 PM
Subject: Re: [fpc-devel] Problem with fpcmake when doing
I am currently writing/porting startup code for the pic32 chips, the
inline assembler of fpc seems to lack support for some opcodes, any idea
how I can workarround this?
With grep I found for example mtc1 in opcode.inc, but mtc0 is missing,
this opcode is important for the initialization of th
ichael
Am 28.05.13 21:31, schrieb Sergei Gorelkin:
28.05.2013 22:50, Michael Ring пишет:
I am currently writing/porting startup code for the pic32 chips, the
inline assembler of fpc seems
to lack support for some opcodes, any idea how I can workarround this?
With grep I found for example mtc1 in opcod
ub',
+'ehb',
+'ext',
+'ins',
+'mfc0',
+'mtc0',
+'sdbbp',
+'wrpgpr',
'end_def'
Am 28.05.13 21:49, schrieb Sergei Gorelkin:
28.05.2013 23:40, Michael Ring пишет:
Thank you Sergei, I will have a look at that code.
I
05.2013 2:08, Sergei Gorelkin пишет:
29.05.2013 1:26, Michael Ring пишет:
I did the changes, parts of the opcodes now work fine, I think I
have found the problem with the li
+ and + mfc0 op-codes, if last parameter is 0 then the asm statement
is generated wrong:
This works:
and$a0,$a0,1
/usr/local/bin/ppc386 -Ur -Xs -O2 -n -Fui386 -Fusystems
-Fu/Users/ring/devel/fpc/rtl/units/i386-darwin -Fii386 -FE.
-FUi386/units/i386-darwin -dRELEASE -gw2 -di386 -dGDB -dBROWSERLOG
-Fux86 -Sew pp.pas
paramgr.pas(620,54) Error: Identifier not found "paracgsize"
paramgr.pas(640) Fatal: There
compiles again, TnX!
Michael
Am 02.06.13 16:37, schrieb Jonas Maebe:
On 02 Jun 2013, at 16:19, Michael Ring wrote:
/usr/local/bin/ppc386 -Ur -Xs -O2 -n -Fui386 -Fusystems
-Fu/Users/ring/devel/fpc/rtl/units/i386-darwin -Fii386 -FE.
-FUi386/units/i386-darwin -dRELEASE -gw2 -di386 -dGDB
Hi, perhaps I am overseeing a simple solution for my problem:
On the pic32 there are two flash areas, one at 0x9d00 for the main
program and another at 0xbfc0 that is called Boot Flash. On reset
the program starts in the boot flash at the first address.
I have written the startup code
symbols in different segments
the error is from the .size line.
Am 02.06.13 22:51, schrieb Jeppe Græsdal Johansen:
Den 02-06-2013 22:41, Michael Ring skrev:
Hi, perhaps I am overseeing a simple solution for my problem:
On the pic32 there are two flash areas, one at 0x9d00 for the
main pr
This version worked,
thank you for your help!
Michael
Am 02.06.13 23:20, schrieb Jeppe Græsdal Johansen:
Den 02-06-2013 23:15, Michael Ring skrev:
Unfortunately that does not seem to work (or I use it wrong):
This procedure:
procedure _general_exception_handler; assembler; nostackframe
Thank you, the startup code is compiling now, I will send you a patch
with the missing opcodes to have full support of mips32r2 soon.
Michael
Am 03.06.13 22:04, schrieb Sergei Gorelkin:
29.05.2013 21:44, Michael Ring пишет:
This is looking good now on first view, all statements seem to pass
32',
'dsllv',
'dsra',
'dsra32',
'dsrav',
'dsrl',
'dsrl32',
'dsrlv',
'dsub',
'dsubu',
'end_def'
'la',
'ld',
'ldl',
'ldr',
'li',
'lld',
&#x
.text.n_pic32mx1xxfxxxb_$$_reset
# path: mipsel/
# file: pic32mx_start.inc
# indx: 2
.Ll3:
jr $ra
nop
.setmacro
.setreorder
.endPIC32MX1XXFXXXB_$$_RESET
.Lt2:
.Le1:
.size PIC32MX1XXFXXXB_$$_RESET, .Le1 - PIC32MX1XXFXXXB_$$_RESET
.
:
16.06.2013 22:17, Michael Ring пишет:
I have now browsed through the current mips documentation and have
created a file that includes all
opcodes, the version they are first in (starting with mips32) and a
small comment what the mnemonic
does.
This file is attached to this mail.
The problem here is that
; list
Objet : Re: [fpc-devel] How can I distribute code in two different memory
areas? (.section)
Den 17-06-2013 08:20, Sergei Gorelkin skrev:
16.06.2013 23:39, Michael Ring пишет:
I had some time this weekend (while beeing grilled by the sun on my
balcony) to work on another
thing that did not wo
You should better install the native port of lazarus & freepascal on the
raspberry and connect the machine to a display/mouse/keyboard. Install
latest raspian from http://www.raspberrypi.org/downloads
and here's a user-guide for installing lazarus/fpc:
http://elinux.org/Lazarus_on_RPi
Then y
Hi!
I have spent a while trying to figure out what I am doing wrong but I do
not have clue. I can compile a binary for pic32 just fine
but when I load it into gdb I get an error: Dwarf Error: bad length
(0x6f59) in compilation unit header (offset 0x7e + 0)
when I look at the file with rea
I have now found out why debug symbols get discarded by
pic32mx-elf32-gdb. The problem is a bug in the generation of
dwarf-debuginfo. My guess is that the problem should also exist in linux
target.
For mips unaligned data in dward debug info needs to be defined as
.4byte and .2byte instead o
-elf32-
to compile use:
ppcrossmipsel -MObjFPC -Scghi -Ch1024 -Cs1024 -Tembedded -Pmipsel -gw2
-vewnhix -l -Cppic32mx -WpPIC32MX220F032C -XPpic32mx-elf32-
-FD/usr/local/bin -a -godwarfsets -godwarfmethodclassprefix hello.pas
-al -ar
Michael
Am 05.07.13 22:23, schrieb Michael Ring:
I have now foun
[20]=(
#9'.2byte'#9,#9'.4byte'#9,#9'.8byte'#9
);
Am 07.07.13 09:26, schrieb Florian Klämpfl:
Am 05.07.2013 22:23, schrieb Michael Ring:
I have now found out why debug symbols get discarded by
pic32mx-elf32-gdb. The problem is a bug in the generatio
This is looking good now, I can also compile the rtl with enabled
debuginfo and this now also loads without error into gdb, thank you very
much!
Michael
Am 07.07.13 17:10, schrieb Florian Klaempfl:
Can anybody help with a fix?
Do I understand it correctly, that it is sufficient so replace .l
Trunk for armv7m buils just fine with this commandline:
make clean buildbase CROSSINSTALL=1 OS_TARGET=embedded CPU_TARGET=arm
SUBARCH=armv7m CROSSOPT="-O-" BINUTILSPREFIX=arm-none-eabi-
doing the same for armv6m:
make clean buildbase CROSSINSTALL=1 OS_TARGET=embedded CPU_TARGET=arm
SUBARCH=a
Working again, thank you!
Michael
Am 03.09.13 09:00, schrieb Jeppe Græsdal Johansen:
Should be fixed in trunk now.
Regards,
Jeppe
Den 03-09-2013 08:44, Michael Ring skrev:
Trunk for armv7m buils just fine with this commandline:
make clean buildbase CROSSINSTALL=1 OS_TARGET=embedded
I today installed the GA of Mavericks, it seems that crt1.o was deleted
from /usr/lib:
[ring@macbookpro devel]$ fpc hello.pas
Free Pascal Compiler version 2.6.2 [2013/02/03] for i386
Copyright (c) 1993-2012 by Florian Klaempfl and others
Target OS: Darwin for i386
Compiling hello.pas
Assembling
'Downloads' anymore on my system, not sure if
this is because I updated my system or because they changed the way that
the commandline tools are installed.
Michael
[ring@macbookpro devel]$ fpc hello.pas
-XR/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Deve
After
xcode-select --install
crt1.o is once again visible in /usr/lib.
No idea why Apple decided to go this strange way, thank you for your help!
Michael
Am 04.10.13 14:42, schrieb Jonas Maebe:
On 04 Oct 2013, at 14:38, Jonas Maebe wrote:
If you did not get a pop-up as described in that th
I tried today's trunk, unfortunately it does not build:
/Users/ring/devel/fpc/compiler/ppcrossarm -Cparmv7m @rtl.cfg -Ur
-Tembedded -Parm -XParm-none-eabi- -Xr -Ur -Xs -O2 -n -Fi../inc
-Fi../arm -FE. -FU/Users/ring/devel/fpc/rtl/units/arm-embedded -darm
-dRELEASE -O- -Us -Sg system.pp
flt_pac
OK, thank you!
Am 01.11.13 12:10, schrieb Jonas Maebe:
On 01/11/13 09:22, Michael Ring wrote:
I tried today's trunk, unfortunately it does not build:
/Users/ring/devel/fpc/compiler/ppcrossarm -Cparmv7m @rtl.cfg -Ur
-Tembedded -Parm -XParm-none-eabi- -Xr -Ur -Xs -O2 -n -Fi../inc
-Fi../ar
Hi, while playing arround I found a strange behaviour that seems to have
to do with the fact that writes to bitpacked records are byte aligned.
Here are the details:
I have create a bitpacked record set for the GPIO Registers of the
processor. On Port D of the processor I have 16 LED's, one fo
huge number of bits (>8)
gets modified at the same time)
What do you think?
Michael
Am 11.12.13 10:34, schrieb Jonas Maebe:
On 11 Dec 2013, at 08:43, Michael Ring wrote:
The strb command seems to be the problem, documentation from STM states:
Each I/O port bit is freely programmable, ho
I've downloaded today's snapshot from ftp.freepascal.org.
While 2.03 Version cross-compiles on windows for linux the version 2.11
Snapshot doesn't.
Here's the Error Output:
C:/Programme/fpc/fpcbuild-2.11/fpcsrc/rtl/units/i386-linux -di386
-dRELEASE -Fi../objpas/sysutils ../unix/sysutils.pp
Thanks!
Vincent Snijders wrote:
Michael Ring wrote:
I've downloaded today's snapshot from ftp.freepascal.org.
While 2.03 Version cross-compiles on windows for linux the version
2.11 Snapshot doesn't.
Here's the Error Output:
This has been fixed today. Maybe it works
Checkin Comment was:
Optimized support for 32x32 => 64bit multiplications on ARM
This code uses UMULL and SMULL to perform the multiplications, which
take two 32bit source registers and two 32bit destination registers.
... umull is not supported by cortex-m0 chips ...
system.inc(1770,8) Warn
I tried rev. 26354, the problem is not yet fixed, perhaps Jonas is right
and there's more to do... I both tried armv7m and armv6m, both break:
ring/devel/fpc/rtl/units/arm-embedded -darm -dRELEASE -O- -gw2
-Fi../objpas/sysutils sysutils.pp
dati.inc(80,34) Fatal: Internal error 2002090902
Fatal
Does not seem to be a good day today to compile trunk ;-)
On my Mac I get this error Message:
cwstring.pp(1,1) Fatal: illegal character "'�'" ($BB)
cwstring.pp(1,1) Fatal: Compilation aborted
make[5]: *** [cwstring.ppu] Error 1
make[4]: *** [darwin_all] Error 2
make[3]: *** [rtl] Error 2
make[2]
Working again for armv7m and armv6m, thank you!
Michael
Am 02.01.14 16:24, schrieb Florian Klämpfl:
Am 02.01.2014 15:18, schrieb Michael Ring:
I tried rev. 26354, the problem is not yet fixed, perhaps Jonas is right
and there's more to do... I both tried armv7m and armv6m, both break:
Error Message is:
*/bin/mkdir -p /Users/ring/devel/fpc/rtl/units/arm-embedded
/Users/ring/devel/fpc/compiler/ppcrossarm -Cparmv7m @rtl.cfg -Ur
-Tembedded -Parm -XParm-none-eabi- -Xr -Ur -Xs -O2 -n -Fi../inc
-Fi../arm -FE. -FU/Users/ring/devel/fpc/rtl/units/arm-embedded -darm
-dRELEASE -O- -gw2
;p:PFileTextRecChar;flags:longint; pchangeable:
boolean);
+procedure do_open(var f;p:pChar;flags:longint; pchangeable: boolean);
begin
end;
Am 07.03.14 16:35, schrieb Michael Ring:
Error Message is:
*/bin/mkdir -p /Users/ring/devel/fpc/rtl/units/arm-embedded
/Users/ring/devel/fpc/compiler/ppcrossarm
Thank you Jeppe,
I did not want to look impatient, was just wondering if this problem
somehow did not catch attention... ;-)
Michael
Am 12.03.14 17:41, schrieb Jeppe Græsdal Johansen:
Den 12-03-2014 16:51, Michael Ring skrev:
As there was no reaction I created a patch, question is if this
I need to preset 4 longWords at a specific memory location in flash of
the microcontroller that define the startup behaviour of the chip.
I came up with two solutions, but both more feel like a hack than a
proper way to do things, any ideas how to do this better?
a) by hijacking the declara
I knew for a while that dwarf output for the target is not 100% correct,
I now found one example of a wrongly generated debuginfo, could somebody
please help me and fix this problem in compiler?
I see the problem both with dwarf2 or dwarf4 debug info, with dwarf2 the
error message is a little
Thanks,
but does not solve the problem, it's not about reading the data, it's
about defining the data so that it is included in the elf file in the
correct section so that the microcontroller is programmed with the
values when the elf file is uploaded to the microcontroller.
Michael
Am 23.04
:
http://wiki.freepascal.org/TARGET_Embedded_Mipsel
Michael
Am 23.04.14 14:19, schrieb Michael Schnell:
On 04/23/2014 10:34 AM, Michael Ring wrote:
Thanks,
but does not solve the problem, it's not about reading the data, it's
about defining the data so that it is included in the elf f
Am 23.04.14 15:30, schrieb Michael Schnell:
Some questions that might put us in a working position:
Can you state the cause why xc32 is not usable ?
binutils from xc32 is not usable, I could not link correctly when I used
th xc32- tools.
For our project (from your first message seemingly diff
Am 23.04.14 15:35, schrieb Michael Schnell:
The wiki page speaks of gdb. Does same use PICKit a similar tool to
connect to the chip ?
If mplabx is you primary development env then you do not need another
debugger.
The JLink-Probe is for those like me that do not want to work in a
C-Style IDE.
Thank you for this tip Sergei, this seems to work just fine!
Michael
Am 23.04.14 10:44, schrieb Sergei Gorelkin:
23.04.2014 12:34, Michael Ring пишет:
Thanks,
but does not solve the problem, it's not about reading the data, it's
about defining the data so
that it is included in th
Hi!
consts seem to sometimes mix up dwarf debuginfo.
the following simple program:
program hello;
const
const1: longword = 1;
// const2: longword = 1;
// const3: longword = 1;
// const4: longword = 1;
//var
// i : integer;
begin
end.
causes the following dwarf error on load in gdb:
Re
I cannot build target arm-embedded on trunk because the Makefile for
libndsfpc is not generated correctly:
/Applications/Xcode6-Beta5.app/Contents/Developer/usr/bin/make -C
libndsfpc distclean
Makefile:199: *** The Makefile doesn't support target arm-embedded,
please run fpcmake first. Stop.
Fixed in trunk, thank you!
Am 04.08.14 um 22:04 schrieb Michael Ring:
I cannot build target arm-embedded on trunk because the Makefile for
libndsfpc is not generated correctly:
/Applications/Xcode6-Beta5.app/Contents/Developer/usr/bin/make -C
libndsfpc distclean
Makefile:199: *** The
There seems to be a bug in the codegenerator for armv6m thumb code.
tst r0,#-2147483648
is not valid armv6m assembler code, documentation says that tst only can
use registers:
TST Rn, Rm
where:
Rn Is the register holding the first operand. Rm The register to test
against.
Cortex-M0+ Devic
Will do so
Michael
Am 08.08.14 um 13:57 schrieb Sven Barth:
Am 08.08.2014 10:29 schrieb "Michael Ring" <mailto:m...@michael-ring.org>>:
>
> There seems to be a bug in the codegenerator for armv6m thumb code.
>
> tst r0,#-2147483648
>
> is not valid
I am currently getting an error message:
[ring@MacbookPro fpc-arm]$ svn update
Updating '.':
svn: E175002: Unable to connect to a repository at URL
'http://svn.freepascal.org/svn/fpc/trunk'
svn: E175002: The OPTIONS request returned invalid XML in the response:
XML parse error at line 1: no ele
The patch worked, generated assembler looks ok, will test on device this
evening
Am 08.08.14 um 14:27 schrieb Nico Erfurth:
On 08.08.14 10:28, Michael Ring wrote:
There seems to be a bug in the codegenerator for armv6m thumb code.
tst r0,#-2147483648
is not valid armv6m assembler code
Here's an overview about important files, based on what I know from the
arm/mipsel targets:
fpc/compiler/avr/cpuinfo.pas//Here you add new controllers
fpc/compiler/systems/t_embed //Linker scripts, new controllers need
to also get added here
fpc/compiler/systems/i_embed //I gues
I guess it depends on what you understand by the word support ;-)
The Pinguino has a PIC32MX440F256H; translated headers for this chip are
available. Flashing and Debugging with JLink V9 Adapter should also work
fine with gdb, it did with every other PIC32MX I tried.
There's also support for
This smells like a problem I had on pic32. In my case the pic32 chips do
not have a floating point unit and the processor creates an illegal
instruction (or something similar) exception.
I solved this for me by patching out the call to the hardware
coprocessor when softfpu is selected.
You c
Sven, you were faster than me ,-)
Michael
Am 08.09.14 um 22:54 schrieb Sven Barth:
Am 08.09.2014 20:26 schrieb "Reinier Olislagers"
mailto:reinierolislag...@gmail.com>>:
>
> On 08/09/2014 20:05, Sven Barth wrote:
> > Could you please recompile FPC with OPT="-gl" (maybe also -O-) and
> > comp
This problem also looks similar, there are two procedures in setjump.inc
and they both address the fpu:
ctc1 $v0,$31
cfc1 $v0,$31
Michael
Am 09.09.14 um 08:29 schrieb Reinier Olislagers:
Applied a similar patch [1]; progress, thanks!
gdb bt now shows:
^C
Program received signal SI
Sergei, I have reworked the patch based on your comment:
http://svn.freepascal.org/cgi-bin/viewvc.cgi?view=revision&revision=28634
Do you think this is solved better now?
Michael
Am 09.09.14 um 08:52 schrieb Sergei Gorelkin:
09.09.2014 9:53, Sven Barth пишет:
On 08.09.2014 22:54, Mic
Am 09.09.14 um 13:32 schrieb Sergei Gorelkin:
09.09.2014 14:33, Michael Ring пишет:
Sergei, I have reworked the patch based on your comment:
http://svn.freepascal.org/cgi-bin/viewvc.cgi?view=revision&revision=28634
Do you think this is solved better now?
No, my point was that
I am wondering why compile did not fail, or did you rename your binutils
tools? In case you did not rename them those commandlines should work:
make clean buildbase installbase CROSSINSTALL=1 OS_TARGET=embedded
CPU_TARGET=arm SUBARCH=armv7m INSTALL_PREFIX=/home/sietse
*BINUTILSPREFIX=arm-none
-eabi-* *-vu* tled1.pp
Ch and Cs set heap and stacksize, -vu enables (some) debug output
Michael
Am 12.10.14 um 20:06 schrieb Michael Ring:
I am wondering why compile did not fail, or did you rename your
binutils tools? In case you did not rename them those commandlines
should work:
make clean
1 - 100 of 243 matches
Mail list logo
