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
Perhaps someone can help me with interrupts on riscv32:
I have now changed the compiler to create proper interrupt routines, all
used registers are saved on stack, so far so good:
MTIP_ISR:
.Lc2:
sw x1,-4(x2)
sw x8,-8(x2)
sw x10,-12(x2)
sw x11,-16(x2)
addi
,static}
{$linklib esp_event,static}
Am 05.04.20 um 14:50 schrieb Michael Ring via fpc-devel:
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
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
is..
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 to compile
, 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 Ring via fpc
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.
Compile compiler 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 trunk compiling
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
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
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
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
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.20 um
.
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.patch
I have
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
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
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
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
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
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
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] Possible error
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
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
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
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
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
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
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
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
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
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
-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
ode 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 to compile
tru
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
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...
Das UF2 File wird nur
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
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
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
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
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
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:
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
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:
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 Ring via fpc
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
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 may
(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 build with hardfloat
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
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,
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
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
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
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
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
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
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
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
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
62 matches
Mail list logo
