When trying to build fpc (with fpcupdeluxe) I get the following error
for both Trunk and Stable(!!) version of fpc:
Compiling ./fcl-net/src/cnetdb.pp
cnetdb.pp(240,2) Error: User defined: fatal 'Please consult the netdb.h
file for your system to determine the order of ai_addr and ai_canonname'
There's a syntax error that is in trunk for a while now, here's the fix,
can anybody of the dev's please apply this?
Michael
ring@MacbookPro fpcsrc $ git diff rtl/arm/thumb.inc
diff --git a/rtl/arm/thumb.inc b/rtl/arm/thumb.inc
index 85d948a1e1..c7a9273be1 100644
--- a/rtl/arm/
Hi!
Christo has done some magic on the esp32 targets and together we are
currently trying to make everything available in an as consistent as
possible way.
One thing that is very necessary from my point of view is that we
properly support SUBARCH's when building rtl and packages as there are
PR:
https://gitlab.com/freepascal.org/fpc/source/-/merge_requests/638
Am 01.04.24 um 22:33 schrieb Michael Ring via fpc-devel:
I am using heapmgr but with trunk compiler the value of __heapsize is
plain wrong (and way too big)
When I compile my code with my old compiler for pico all is
I am using heapmgr but with trunk compiler the value of __heapsize is
plain wrong (and way too big)
When I compile my code with my old compiler for pico all is fine, when I
debug into heapmgr I see that __heapsize is set correctly to 16384 based
on this setting:
program spi_st7789;
{$MODE OB
Works, thank you!
Michael
Am 31.03.24 um 22:18 schrieb Florian Klämpfl via fpc-devel:
Am 31.03.2024 um 21:58 schrieb Michael Ring via fpc-devel
:
This is what I see (guess the same thing):
New Compiler:
FPC_INITIALIZE:
.Lc3882:
# path: /Users/ring/devel/fpc/rtl/inc/
# file: rtti.inc
As a workaround I compiled rtl with -Oonopeephole and verified that the
balign is there, looking good!
Should I open an issue on gitlab or will you take care?
Many thanks and have a nice rest of Easter holidays,
Michael
Am 31.03.24 um 21:58 schrieb Michael Ring via fpc-devel:
This is what
31.03.2024 um 21:35 schrieb Florian Klämpfl via fpc-devel
:
Am 31.03.2024 um 17:11 schrieb Michael Ring via fpc-devel
:
Hi,
it has been a while since I have been deep,deep down in the rabbit
hole of Cortex Assembly, so please forgive me if I am overlooking
something...
I have an
Hi,
it has been a while since I have been deep,deep down in the rabbit hole
of Cortex Assembly, so please forgive me if I am overlooking something...
I have an application for Raspberry Pico (target embedded) and it fails
during initialization as soon as I add a unit that includes an object
There's a small issue when compiling code for embedded, when there is a
linker error for unresolved externals it does not get displayed.
example:
~/fpcupdeluxe/lazarus/lazbuild -B pio_ws2812-raspi_pico.lpi
using config file /Users/ring/fpcupdeluxe/lazarus/lazarus.cfg
pio_ws2812.lpr(85)
Florian, it seems you missed a comment on that topic I wrote a while ago.
There is also the need to have a tuple that matches controllertype to
controllerunit to get rid of a big peace of duplicated code from
cpuinfo.pas in lazarus.
Lazarus needs to know which unit to include so that codetool
for this command:
~/fpcupdeluxe-embedded/fpc/bin/aarch64-darwin/fpc -Tembedded -Parm
-WpDISCOVERYF411VE -ix
it would be good to also get back the controllerunitstr that belongs to
DISCOVERYF411VE
or, when size does not matter much include the unit already in the more
generalized call:
~
stm32f10x_md stm32f10x_hd
stm32f10x_xl stm32f10x_conn stm32f10x_cl lpc13xx lpc1768 sam3x8e xmc4500
cortexm3 cortexm4 # thumb2_bare
CPU_UNITS_DEFINED=1
endif
ifeq ($(SUBARCH),armv7em)
Am 20.02.21 um 22:26 schrieb Michael Ring via fpc-devel:
lm4f120: yes, it should be moved in the makefile. But let
lm4f120: yes, it should be moved in the makefile. But let me dig a
little big, perhaps there are more files that are wrong, will come back
to you.
Michael
Am 20.02.21 um 21:51 schrieb Florian Klämpfl via fpc-devel:
Am 20.02.21 um 10:35 schrieb Michael Ring via fpc-devel:
I have created an
D88
{$endif defined(FPUARM_HAS_VFP_EXTENSION)}
Am 19.02.21 um 22:13 schrieb Michael Ring via fpc-devel:
You are the best, thank you!
Michael
Am 19.02.21 um 22:11 schrieb Florian Klämpfl via fpc-devel:
Am 19.02.21 um 21:55 schrieb Michael Ring via fpc-devel:
When rtl for arm-embedded/arm-freertos is buil
You are the best, thank you!
Michael
Am 19.02.21 um 22:11 schrieb Florian Klämpfl via fpc-devel:
Am 19.02.21 um 21:55 schrieb Michael Ring via fpc-devel:
When rtl for arm-embedded/arm-freertos is build with hardfloat the
fpu should also automagically get enabled, by default it is off which
When rtl for arm-embedded/arm-freertos is build with hardfloat the fpu
should also automagically get enabled, by default it is off which causes
a crash when floats are used.
This small patch fixes that problem in cortexm4f_start.inc
can you please apply this patch to trunk?
Thank you,
Michae
Thanks,
so I will try to have some fun with debugging softfp, 'fortuately' the
first issue manifested itself in multiplying two numbers, may the gods
of gdb smile on me!
Michael
Am 14.02.2021 um 14:19 schrieb Florian Klämpfl via fpc-devel:
Am 14.02.21 um 14:08 schrieb Michael Ri
I am having a lot of (no-)fun with floating point on Cortex-M0, current
summary would be to say that things get pretty unreliable once I start
using Floats.
I today stumbled over -CfLIBGCC, sounds interesting, but compiling
cross-compiler trunk with this option ends up in an error:
/Library
Code now compiles again, thank you for fixing!
Michael
Am 13.02.21 um 17:11 schrieb Michael Ring via fpc-devel:
I just updated to latest trunk and found out that armv7m and armv7em
RTL does not build anymore:
/Library/Developer/CommandLineTools/usr/bin/make -C rtl all
/Library/Developer
I just updated to latest trunk and found out that armv7m and armv7em RTL
does not build anymore:
/Library/Developer/CommandLineTools/usr/bin/make -C rtl all
/Library/Developer/CommandLineTools/usr/bin/make -C embedded all
/Users/ring/fpcupdeluxe/fpc/bin/x86_64-darwin/ppcarm -Cparmv7m -Ur
-Tembe
There is an issue with compiling code for armv7em, we may compile with
hardfloat support or without. The compiled files are link-incompatible
as ABI is different so mixing them is a bad thing.
I played arround with $FPCABI in fpc.cfg but found out that it is always
set to 'default' because the
Thank you, building from within fpcupdeluxe now works
Am 13.02.21 um 09:20 schrieb Jonas Maebe via fpc-devel:
On 12/02/2021 11:33, Michael Ring via fpc-devel wrote:
So, question one is if it is necessary to detect codesign path at all,
at least for my Mac's it is in /usr/bin
It ma
In a recent trunk version new code was introduced in the compiler
Makefile to make use of codesign for comparing stage compilers.
Problem is that there was an algorithm implemented to detect codesign in
the path and this code is not properly covering the case when for some
reason codesign is v
Jeppe already told me that floating point could be a little shaky on
Cortex-M, and he was right...
I am creating examples for the Raspberry Pi Pico and the ADC example
requires some floating point math.
All testing was done with trunk version of fpc from today
RTL was compiled with empty CRO
I am having an issue in the form that I want to link to freertos static
library and I do not want to provide a freertos library for every
flavour of interrupt vector tables that is out there. (and there are
quite some...)
Also, there are people who want to link to vendor specific arduino
libr
22.01.21 um 22:02 schrieb Michael Ring via fpc-devel:
> Are you guys willing to accept that patch in fpc trunk?
Yes.
The commit message for r48394 should rather acknowledge Michael Ring
as patch submitter ;-)
Christo
___
fpc-devel mail
I'm still
learning German (I assume it's German) and am not good enough yet to
make much sense of this.
Gareth aka. Kit
On 22/01/2021 22:37, Michael Ring via fpc-devel wrote:
Hi Florian, im Anhang der Path für den UF2 Support in freepascal, ich
hoffe er passt so für Dich...
D
Hi Florian, im Anhang der Path für den UF2 Support in freepascal, ich
hoffe er passt so für Dich...
Das UF2 File wird nur erzeugt wenn die Startadresse ungleich $
ist da normalerweise der UF2 Bootloader ab Addresse 0 steht und es damit
keinen sinnmacht ein uf2 file zu erzeugen wenn die
Hi!
Raspberry Pi organization announced the Raspberry Pi Pico (A dualcore
Cortex-M0) and by coincidence I played with uf2 file format in the past
days which is used by this board and many, many Adafruit boards to
upload firmware in an easy way.
So as a first step in the direction of supporti
this machine XCode is
installed so the Path to CommandlineTools points to some other place,
but things still seems to work fine.
Michael
Am 14.11.20 um 15:10 schrieb Jonas Maebe:
On 2020-11-14 11:03, Michael Ring via fpc-devel wrote:
I recently upgraded to Big Sur on two devices and tried
-Pro-1 compiler $ ls -l
/Library/Developer/CommandLineTools/SDKs/MacOSX.sdk (master)fpc
lrwxr-xr-x 1 root wheel 15 10 Dez 2019
/Library/Developer/CommandLineTools/SDKs/MacOSX.sdk -> MacOSX10.15.sdk
shall I try to create a patch?
Michael
Am 14.11.20 um 11:03 schrieb Michael Ring via
I recently upgraded to Big Sur on two devices and tried to compile trunk
based on official 3.2.0 compiler freshly downloaded from sourceforge but
compilation fails:
make all
/usr/local/bin/ppcx64 -Ur -Xs -O2 -n -Fux86_64 -Fusystems
-Fu/Users/ring/devel/fpc/rtl/units/x86_64-darwin -Fix86
Compile works fine again, thanks again!
Michael
Am 01.08.20 um 19:27 schrieb Sven Barth via fpc-devel:
Am 01.08.2020 um 13:36 schrieb Michael Ring via fpc-devel:
Null problemo, thanks for the update!
Should be fixed in r45981.
Regards,
Sven
Null problemo, thanks for the update!
Michael
Am 01.08.20 um 13:32 schrieb Sven Barth via fpc-devel:
Michael Ring via fpc-devel <mailto:fpc-devel@lists.freepascal.org>> schrieb am Sa., 1. Aug. 2020,
13:26:
Revision 45972 builds fine, all Revisions since 45973 create this
err
Revision 45972 builds fine, all Revisions since 45973 create this error
on my Mac. I checked with armv6m, armv7m and armv7em subarchs:
/Applications/Xcode.app/Contents/Developer/usr/bin/make -C rtl all
/Applications/Xcode.app/Contents/Developer/usr/bin/make -C embedded all
/Users/ring/fpcupdelux
Compiles again, thank you!
I should have copied the header of the mail into the message, then
things would have been more clear, sorry!
Michael
Am 17.07.20 um 18:46 schrieb Florian Klämpfl:
Am 17.07.20 um 18:03 schrieb Michael Ring via fpc-devel:
As the problem is still there I checked
As the problem is still there I checked where it comes from,
revision 45750
is to blame, 45749 compiles just fine, 45750 kills the build of rtl for
armv7em
Michael
Am 10.07.20 um 23:46 schrieb Michael Ring via fpc-devel:
I today updated to latest trunk, I am getting an error compiling rtl
I today updated to latest trunk, I am getting an error compiling rtl for
arm-embedded, but only for armv7em with enabled FPU, armv6m and armv7m
compile fine.
/Users/ring/fpcupdeluxe/fpc/bin/x86_64-darwin/ppcarm -Cparmv7em -Ur
-Tembedded -Parm -XParm-embedded- -Xr -Ur -Xs -O2 -n -Fi../inc -Fi..
Hi, Linking on arm-freertos target did not work after the merge of some
of Christo's fixes for esp32-freertos.
Here's the fix for the issue (also attached as diff), Florian, can you
please check & apply this patch?
Thank you,
Michael
diff --git a/compiler/systems/t_freertos.pas
b/compile
Hi, Linking on arm-freertos target did not work after the merge of some
of Christo's fixes for esp32-freertos.
Here's the fix for the issue (also attached as diff), Florian, can you
please check & apply this patch?
Thank you,
Michael
diff --git a/compiler/systems/t_freertos.pas
b/compile
I have to define a weak procedure in implementation of a unit to make
the linker happy in a special case:
procedure vPortFree; external name 'vPortFree';
procedure vPortFreeStub; assembler; nostackframe;
asm
.long vPortFree
.weak vPortFree
.set vPortFree,vPortFreeStub
bkpt
end;
is the
make -j clean buildbase FPC=~/fpcupdeluxe/fpc/bin/x86_64-darwin/fpc.sh
works fine with fpc checkout from a few days ago, with todays trunk I
get the following error:
/Library/Developer/CommandLineTools/usr/bin/make rtl
/Library/Developer/CommandLineTools/usr/bin/make -C
/Users/ring/devel/fpc/
Arg...
I feel completely stupid!
Thank you for the Hint Jonas, using pxBuffer^ did the trick!
Michael
Am 22.04.20 um 11:15 schrieb Jonas Maebe:
On 22/04/2020 00:09, Michael Ring via fpc-devel wrote:
function memset(pxBuffer:pointer; value : byte; count
Alexander Grotewohl
https://dcclost.com
*From:* fpc-devel on behalf
of Michael Ring via fpc-devel
*Sent:* Tuesday, April 21, 2020 6:09:57 PM
*To:* fpc-devel@lists.freepascal.org
*Cc:* Michael Ring
*Subject:* [fpc-devel] Poss
I have the following code in a unit (I need to provide a memset function
to be able to link to freertos):
function memset(pxBuffer:pointer; value : byte; count : Tsize):pointer;
cdecl;
begin
FillChar(pxBuffer,count,value);
Result := pxBuffer;
end;
When I look at the assembler code genera
Trunk now builds without issues for armv6m, armv7m and armv7em, here's
the patch to add the license and the renames to make the interrupts
cmsis compatible.
http://temp.michael-ring.org/cmsis_plus_license.patch
Michael
Am 20.04.20 um 23:11 schrieb Michael Ring via fpc-devel:
Am 20.04.
Am 20.04.20 um 22:14 schrieb Florian Klämpfl:
Am 20.04.20 um 00:03 schrieb Michael Ring via fpc-devel:
Thanks!
Your commit is close, but not yet there...
to make it work it was necessary for me to re-create the Makefiles,
arm-freertos was missing in the root makefile and some others, did
s in trunk.
Here's a zip with the missing files:
http://temp.michael-ring.org/freertos-arm-missing.zip
Michael
Am 19.04.20 um 23:00 schrieb Florian Klämpfl:
Am 19.04.20 um 17:25 schrieb Michael Ring via fpc-devel:
I have uploaded my patch to:
http://temp.michael-ring.org/fpc-arm-freertos.
arm-none-eabi-gcc.
Michael
Am 19.04.20 um 15:30 schrieb Florian Klämpfl:
Am 06.04.20 um 20:54 schrieb Michael Ring via fpc-devel:
I was able to compile my first hello world for esp32, however I had
to patch a few files so that compiling works for 4.0 / 4.1 Branch of
esp-idf
Florian, can you
doesn't it make sense to also include subarchs in xtensa-freertos?
diff --git a/utils/fpcm/fpcmake.ini b/utils/fpcm/fpcmake.ini
index 16396ca921..9151c09021 100644
--- a/utils/fpcm/fpcmake.ini
+++ b/utils/fpcm/fpcmake.ini
@@ -295,6 +295,13 @@ endif
override FPCOPT+=-Cp$(SUBARCH)
endif
+ifeq ($
Working again, thank you!
Am 19.04.20 um 13:05 schrieb Florian Klämpfl:
Am 19.04.20 um 10:45 schrieb Michael Ring via fpc-devel:
Building for armv6m does not work, building for armv7m/em is fine:
Thanks for noticing. Fixed.
___
fpc-devel maillist
Building for armv6m does not work, building for armv7m/em is fine:
make clean buildbase CROSSINSTALL=1 OS_TARGET=embedded CPU_TARGET=arm
SUBARCH=armv6m
/Library/Developer/CommandLineTools/usr/bin/make rtl_all
FPC=/Users/ring/devel/fpc/compiler/ppcrossarm
FPCFPMAKE=/Users/ring/devel/fpc/comp
Compile compiler&rtl works again!
Michael
Am 12.04.20 um 17:35 schrieb Michael Ring via fpc-devel:
Thanks, but unfortunately this created some issues, both when I build
plain armv6m/armv7em embedded compiler+rtl and my freertos target
(Errors are the same)
armv6m embedded from t
es changed, 66 insertions(+), 48 deletions(-)
In case you need the freertos target, it is here, work in progress, I am
now creating freertos bindings:
http://temp.michael-ring.org/targetarmfreertos.patch
Am 12.04.20 um 16:26 schrieb Florian Klämpfl:
Am 12.04.20 um 14:13 schrieb Michael Ri
Thank you very much for your effort!
Michael
Am 12.04.20 um 11:34 schrieb Florian Klämpfl:
Am 12.04.20 um 10:49 schrieb je...@j-software.dk:
I'm pretty sure that's what fpv4_s16 is. That was implemented for
cortex m4. Don't have the spec here currently though
Yes. It looks like this. Neverth
..
Michael
Am 11.04.20 um 21:42 schrieb Florian Klaempfl:
Am 11.04.2020 um 21:03 schrieb Michael Ring via fpc-devel:
I have now set up new target freertos-arm and want to start playing
arround with freertos.
I have compiled freertos with STM32CubeIDE, only 'problem' is that I
need
I have now set up new target freertos-arm and want to start playing
arround with freertos.
I have compiled freertos with STM32CubeIDE, only 'problem' is that I
need to compile with floting point enabled, with Soft-Float the build fails.
For STM32F401RE Chip the C-compiler selects
-mfpu=fpv4-
missing points to the wiki
Am 06.04.20 um 21:15 schrieb Florian Klämpfl:
Am 06.04.20 um 20:54 schrieb Michael Ring via fpc-devel:
I was able to compile my first hello world for esp32, however I had
to patch a few files so that compiling works for 4.0 / 4.1 Branch of
esp-idf
Florian, can you
,static}
+//{$linklib esp_timer,static}
{$linklib bootloader_support,static}
{$linklib pthread,static}
-{$linklib soc_esp32,static}
+//{$linklib soc_esp32,static}
{$linklib hal,static}
{$linklib c,static}
{$linklib esp_event,static}
Am 05.04.20 um 14:50 schrieb Michael Ring via fpc-devel:
Jus
Just to be sure, from your Path settings it looks like you are using
esp-idf from the release/v4.0 Branch, correct?
Michael
Am 04.04.20 um 19:44 schrieb Florian Klämpfl:
Am 04.04.20 um 16:06 schrieb Christo Crause via fpc-devel:
I'm keen to test the xtensa-freertos target, but it seems there a
How deep will freertos integration be tied to Espressif SDK? The arm
target would also benefit a lot to have a proper interface to freertos
Michael
Am 23.03.20 um 18:36 schrieb Florian Klämpfl:
Am 23.03.20 um 18:10 schrieb Christo Crause via fpc-devel:
I've noticed some Xtensa support appear i
I just saw that trunk was updated, thank you for providing trunk support
for avr atmega4808/09 chips!
Michael
Am 25.01.20 um 22:08 schrieb Florian Klämpfl:
Am 22.01.20 um 18:25 schrieb Christo Crause via fpc-devel:
On a related note, I have some developer board aliases from Michael
(R) and Di
y := x;
end;
Am 12.01.20 um 01:04 schrieb Michael Ring:
Here's my latest patch, I have included an (untested) unit for
gd32vf103 chips
The defines for interrupts should be correct, but I did not start
testing if interrupts work. for the sifive chips the interrupts are
definitively wr
I can second that wish,
It would be really great to have this patch in trunk,
I use it successfully for a while now and debugging on avr is working as
expected and increases productivity a lot.
Michael
Am 27.06.19 um 21:13 schrieb christo:
Today is the anniversary of bug report 0033914. It t
ff in variants.
It will be fixed some day :)
On 6/2/19 10:54 PM, Michael Ring wrote:
Thank you, not using -gw2 did the trick for avr5.
Is this issue also known to you? I am trying to build avr6 support:
BINUTILSPREFIX=avr- ; CROSSOPT="-O- -g -dDEBUG"
SUBARCH=avr6
make
evel/fpc-avr/rtl/units/avr-embedded
-XR/Library/Developer/CommandLineTools//SDKs/MacOSX.sdk/ -davr -dRELEASE
-O- -g -dDEBUG -Us -Sg system.pp @system.cfg
system.pp(293,1) Fatal: Internal error -1413909275
Michael
Am 02.06.19 um 17:56 schrieb Christo Crause:
On Sun, Jun 2, 2019 at 4:51 PM Mi
I tried answering a question on the list today and to do so I did my
'first time ever' compile of the avr target.
This is how I tried to build the avr-embedded target on my Mac:
SUBARCH=avr5; BINUTILSPREFIX=avr- ; CROSSOPT="-O- -gw2 -dDEBUG"
make clean buildbase CROSSINSTALL=1 OS_TARGET=em
My 10 Cents on 'Embedded friendlyness':
Objects and simple functions/procedures do not differ much in
flash/memory usage as long as you do not use constructors/destructors.
Calling your first constuctor adds arround 750 bytes of extra code (on
avr platform). As those avr devices can have very
working solution. (see
https://learn.adafruit.com/proper-step-debugging-atsamd21-arduino-zero-m0/restoring-bootloader)
Michael
Am 27.05.19 um 12:53 schrieb Dimitrios Chr. Ioannidis via fpc-devel:
Hi Michael,
On 2019-05-26 14:14, Michael Ring wrote:
Just one note of caution:
When you encounter
64-win64\fpc.exe
-Tembedded
-Parm
-MObjFPC
-Scgi
-Ch8192
-Cs8192
-O1
-gw2
-l
-vewnhibq
-Fi..\..\Source
-Filib\arm-embedded
-Fu..\..\Source
-Fu.
-FUlib\arm-embedded
-FE.
-oBlinky
-Cparmv6m
-XParm-none-eabi-
-Wparduinozero"
PS: I used the "Microcontroller Board Framework" (
ht
turned on (O2).
Can you share more code that reproduces it?
Either way here's a patch that might fix it?
Best Regards,
Jeppe
On 2/3/19 5:31 PM, Michael Ring wrote:
Forgot to mention I am using Trunk compiler from today revision 41187
ond optimization level was -O1
Michael
Am 03
Forgot to mention I am using Trunk compiler from today revision 41187
ond optimization level was -O1
Michael
Am 03.02.19 um 17:20 schrieb Michael Ring:
I think I found another issue with Code generation, this time on
Cortex-M4:
I need to write Byte Aligned to the Data Register of the SPI
I think I found another issue with Code generation, this time on Cortex-M4:
I need to write Byte Aligned to the Data Register of the SPI Interface
of a STM32 Chip
so what I (try) to do is:
using pByte(@DR)^ to force a single byte transfer and I succeed with the
byte alignment...
BU
My basic testcase looks fine now and also the 'real' code now works as
expected when I switch back from shr commands to div
Thank you very much, Jeppe!
Michael
Am 26.01.19 um 15:20 schrieb Jeppe Johansen:
Does the attached patch work?
On 1/26/19 12:20 PM, Michael Ring wrote:
I
I thought I was going crazy when debugging code that worked fine on
cortex m3/4 but created unexpected results on cortex m0.
Turns out that the compiler creates incorrect assembler code for
cortexm0 for div when used with constant expressions. Optimization level
was -O1 and -O-
Take this cod
);
pend:=psrc+aligncount;
while psrc
Hi Michael,
there was a discussion in this issue
https://bugs.freepascal.org/view.php?id=33323
Cheers,
Benito
Am 28.11.18 um 19:51 schrieb Michael Ring:
The more I dig the more I ask myself if not the rtl routine is to
blame for the
is wrongly calculating the numbers of
bytes that need to be read byte aligned before a pointer-sized copy can
be done
Michael
Am 28.11.18 um 19:51 schrieb Michael Ring:
The more I dig the more I ask myself if not the rtl routine is to
blame for the issue in the first place because it only ta
The more I dig the more I ask myself if not the rtl routine is to blame
for the issue in the first place because it only takes alignment of the
destination into account when doing it's job.
Aligncount is calculated base on destination (which is RAM), for this
reason the last line always crashe
Hi,
I am debugging an issue that I see on mipsel embedded target (and
perhaps also on arm-embedded for corteX-m0, I had crashes in the same
rtl routine a while ago)
because RAM is small on embedded devices I use:
{$WRITEABLECONST OFF}
which means that const are read from flash and not from
A whilke ago I have proposed a fix in fpc-devel in Thread: "MacOS Mojave
beta - crt1.o not installed to /usr/lib"
Using the CommandLineTools directory (and not the XCode directory) makes
it possible to use fpc without the need to have the very huge xcode
installed, I deleted it a while ago and
ain a repro of controller units, I can automagically generate
Headers for most relevant microcontrollers currently available.
Michael
Am 30.09.18 um 19:53 schrieb Florian Klämpfl:
Am 30.09.2018 um 19:48 schrieb Michael Ring:
Hi Florian!
I have already reduced size to the same size to the size
what do you think?
FYI, here are the current patches for SAMCD+STM32 family:
https://github.com/michael-ring/mbf/tree/master/Patches
Michael
Am 30.09.18 um 19:34 schrieb Florian Klämpfl:
Am 30.09.2018 um 19:33 schrieb Michael Ring:
Unfortunately a few files are missing in trunk, however I
about "no rule to make target mipsel/startup.s" probably because that
file is missing from trunk (at least I cannot find it either).
Secondly the cpu units such as pic32mx1xxfxxxb etc. are also missing.
There is a comment for svn rev. 27188: "partially merged the
mips-embedded bran
definitions for microcontrollers are available in the rtl/embedded/arm
directory, there is one (sometimes several) pascal file for a class of
microcontrollers of one vendor.
There is some light glue in the compiler/arm/cpuinfo.pas and
systems/t_embed.pas directory to make a new microcontroller
oper/CommandLineTools//SDKs/MacOSX.sdk/usr/lib/'+startupfile)
then
+
result:='/Library/Developer/CommandLineTools/SDKs/MacOSX.sdk/usr/lib/'+startupfile
end
else
result:='';
Am 01.07.18 um 22:52 schrieb Michael Ring:
I only adjusted -Fl to match the current versi
ry/Developer/CommandLineTools/SDKs/MacOSX.sdk/usr/lib/'+startupfile
end
else
result:='';
Am 01.07.18 um 22:52 schrieb Michael Ring:
I only adjusted -Fl to match the current version installed, having a
wrong issue there did not change the build behaviour. The chan
hardcoding the path
/Library/Developer/CommandLineTools//SDKs/MacOSX.sdk/ in FPC will solve
this.
Thank you,
Michael
Am 01.07.18 um 22:34 schrieb Jonas Maebe:
On 01/07/18 22:18, Michael Ring wrote:
make clean buildbase CPU_TARGET=x86_64 INSTALL_PREFIX=$HOME/3.1.1
FPCOPT="-XR/Libra
We've had this discussion (Jonas and me) a looong time ago (2013) with
MacOS Maverics
In the past, when xcode commandline tools was installed it created a
link to crt1.10.5.o in /usr/lib.
It now seems that this is not done anymore (at least not on my
computer...) and as /usr/lib is write
10:09 schrieb Florian Klämpfl:
Am 13.08.2016 um 18:57 schrieb Michael Ring:
Hi!
I am trying to bring interrupt handling routine size down (and speed up) for
mipsel-embedded target.
I need to use inline assembler routines like this one
procedure TSystemCore.setCoreTimerComp(value : lon
:
Am 21.08.2016 um 13:32 schrieb Michael Ring:
Was getting high hopes for a moment...
@Charlie: the last point you mention, this optimization is already there. As
long as I do not call a
procedure and directly include inline assembler in the interrupt routine all is
fine, only really
used
Was getting high hopes for a moment...
@Charlie: the last point you mention, this optimization is already
there. As long as I do not call a procedure and directly include inline
assembler in the interrupt routine all is fine, only really used
registers are in the list of registers that need to
9/08/16 22:49, Michael Ring wrote:
Am 19.08.16 um 14:49 schrieb Jonas Maebe:
Michael Ring wrote on Sat, 13 Aug 2016:
I am trying to bring interrupt handling routine size down (and speed
up) for mipsel-embedded target.
I need to use inline assembler routines like this one
Am 19.08.16 um 14:49 schrieb Jonas Maebe:
Michael Ring wrote on Sat, 13 Aug 2016:
I am trying to bring interrupt handling routine size down (and speed
up) for mipsel-embedded target.
I need to use inline assembler routines like this one
procedure TSystemCore.setCoreTimerComp(value
Error message is as below, happens on building trunk-fpc or
trunk-crosscompilers for arm/mipsel
/bin/mkdir -p mipsel/units/i386-darwin
/Users/ring/devel/fpc-mipsel/compiler/ppc -Ur -Xs -O2 -n -Fumipsel
-Fusystems -Fu/Users/ring/devel/fpc-mipsel/rtl/units/i386-darwin
-Fimipsel -FE. -FUmipsel/un
Hi!
I am trying to bring interrupt handling routine size down (and speed up)
for mipsel-embedded target.
I need to use inline assembler routines like this one
procedure TSystemCore.setCoreTimerComp(value : longWord); assembler;
nostackframe;
asm
mtc0 $a1,$11,0
end ['a1'];
inside of the i
This tip worked just fine, I was too blind to see how this works .
Thank you Jonas!
Michael
Am 30.06.16 um 15:47 schrieb Jonas Maebe:
Michael Ring wrote on Thu, 30 Jun 2016:
So far I understood the fpc code that registers s0-s7 are
automagically flagged when used as those are the
Hi!
I am trying to make the interrupt keyword work for mipsel (to use with
pic32mx)
I have found the appropriate places in cgcpu.pas and I have the basics
up and running, correct code for mipsel is generated.
One issue I have at the moment is that I waste quite a number of
precious memory
have something to play with when traveling to Maker Faire in
Hannover this weekend ;-)
Michael
Am 24.05.16 um 20:58 schrieb Florian Klämpfl:
Am 23.05.2016 um 17:51 schrieb Michael Ring:
I have started again to work on pic32 (mipsel-embedded) target and found an
issue in the Dwarf Debug
Info
I have started again to work on pic32 (mipsel-embedded) target and found
an issue in the Dwarf Debug Info:
(Please also refer to this old discussion on the problem:
http://lists.freepascal.org/fpc-devel/2013-July/032447.html )
The problem is that .long should be replaced with .4byte for debu
1 - 100 of 243 matches
Mail list logo
