would like to
know if anything is missing/with need for improvement in the device's
unit.
Michael
Am 12.10.14 um 22:30 schrieb Sietse Achterop:
On 10/12/2014 08:06 PM, Michael Ring wrote:
Thanks Michael!
The following (now using armv4) works!
make clean buildbase instal
Am 13.10.14 um 01:00 schrieb Jeppe Græsdal Johansen:
Den 12-10-2014 22:30, Sietse Achterop skrev:
On 10/12/2014 08:06 PM, Michael Ring wrote:
Thanks Michael!
The following (now using armv4) works!
make clean buildbase installbase CROSSINSTALL=1 OS_TARGET=embedded
CPU_TARGET=arm
I remember seeing the problem that gdb does not correctly disassemble
code...
Please do a
arm-none-eabi-readelf -A xxx.elf
you should see:
File Attributes
Tag_CPU_name: "7-M"
Tag_CPU_arch: v7
Tag_CPU_arch_profile: Microcontroller
Tag_THUMB_ISA_use: *Thumb-2*
Compiling, linking and r
pretty sure that it is not in release 2.6.4.
Michael
Am 23.10.14 um 20:52 schrieb Michael Ring:
I remember seeing the problem that gdb does not correctly disassemble
code...
Please do a
arm-none-eabi-readelf -A xxx.elf
you should see:
File Attributes
Tag_CPU_name: "7-M"
Ta
irectory at
rtl/units/arm-embedded
Those should largely contain variable length thumb2 code.
Hello,
thanks for the reply.
My program code is ok, and also lpc1768.o and the cortexm3_start code
is ok.
But code from system.o is wrong.
And thanks to Michael Ring I now can be more consise:
You need to change two files,
+++ compiler/arm/cpuinfo.pas(working copy)
+++ compiler/systems/t_embed.pas(working copy)
I have already done that work, I can send you a patchfile for trunk that
adds the following devices:
STM32F401CB
STM32F401RB,STM32F401VB,STM32F401CC,STM32F401RC,S
p;ST.
Michael
Am 30.11.14 um 16:53 schrieb Sietse Achterop:
On 11/30/2014 11:55 AM, Michael Ring wrote:
You need to change two files,
+++ compiler/arm/cpuinfo.pas(working copy)
+++ compiler/systems/t_embed.pas(working copy)
Thanks Florian van Michael,
You can find the files I cha
01.12.14 um 20:33 schrieb Sietse Achterop:
Hello list,
@Florian: thanks for finding my error. I saw that something was case
insensitive, but not in this way(:
it now works!
@Michael:
On 11/30/2014 08:14 PM, Michael Ring wrote:
Please download my diff here:
http://temp.michael
Take the following unit, my goal is to have the code called in the unit
inlined in the main code.
This works fine when
type
pLongWord = ^LongWord;
is defined in the interface of the unit.
if this is defined in Implementation then Inlining of the code does not
work.
Is this correct behavi
schrieb Florian Klaempfl:
Am 06.04.2015 um 17:53 schrieb Michael Ring:
Take the following unit, my goal is to have the code called in the unit
inlined in the main code.
This works fine when
type
pLongWord = ^LongWord;
is defined in the interface of the unit.
if this is defined in
Paul,
I can generate the pascal unit for the nrf51 module from the CMSIS Data
of this chip.
Drop me a note if are you interested, this unit should make your life a
lot easier.
Michael
Am 16.04.15 um 20:29 schrieb Jeppe Johansen:
On 04/16/2015 12:49 PM, Paul Michell wrote:
I assume this
k this is worth attempting I would be happy to help set this up.
Kind regards,
Paul
On Friday 17 Apr 2015 08:44:55 Michael Ring wrote:
I can generate the pascal unit for the nrf51 module from the CMSIS Data
of this chip.
Drop me a note if are you i
I am not sure if this is a problem of the Generics.Collections unit I am
using (https://github.com/dathox/generics.collections) as this unit is
always compiled with -Mdelphi or if this is an issue with fpc's parser.
The following snippet compiles fine in delphi mode, but does not compile
in Ob
On 27.04.2015 20:19, Michael Ring wrote:
I am not sure if this is a problem of the Generics.Collections unit I am
using (https://github.com/dathox/generics.collections) as this unit is
always compiled with -Mdelphi or if this is an issue with fpc's parser.
The following snippet compiles fine
Did not work, now I get
Fatal: Syntax error, ";" expected but "identifier PUBLIC" found
I did a cut & paste of your code into my code
Michael
Am 27.04.15 um 21:19 schrieb Sven Barth:
On 27.04.2015 20:31, Michael Ring wrote:
Argh, soory, cut & waste erro
t found
"specialize") and the generics library where TComparer comes from
explicitly sets delphi mode.
Michael
Am 27.04.15 um 22:34 schrieb Jeppe Johansen:
There's a missing ; after the specialization
,
On 04/27/2015 09:46 PM, Michael Ring wrote:
Did not work, now I get
Fa
A4,RA7,RA8,RA9,RA10]);
for i := 0 to 4 do
;
end;
end.
Am 28.04.15 um 18:07 schrieb Paul Michell:
Micheal
On Sunday 19 Apr 2015 17:24:35 Michael Ring wrote:
I have created a patch for you that adds the interface-unit for the
nrf51 chips.
I've adapted my build script to gen
One question, why do you enable flow control? Afaik the serial interface
only uses rx/tx.
For the strings problem, I guess it's time to start up the debugger ;-)
(I am removing the dust from my nrf51 dongle, too ;-) )
It looks like you are on Linux, can you please install cgdb and make
sure
Hi Sven! (and perhaps others...)
A while ago (Aehm.. Feb 2013) you announced that type helpers are available for
FreePascal. Which is great news ;-)
You also menitioned that there is a limitation,
"As with class and type helpers only one helper for a given type can be active"
but reading on,
begin
end;
procedure testlongWordHelper2.setValue2(a : longWord);
begin
end;
function testlongWordHelper2.getValue2 : longWord;
begin
end;
begin
t.Value1 := 10;
t.Value2 := 10;
end.
Am 09.07.15 um 17:17 schrieb Sven Barth:
Am 09.07.2015 14:38 schrieb "Michael Ring" <mailto:m..
55 schrieb Michael Ring:
Here's a simplified example, it fails with a compiler error when
compiling it with trunk:
test.pas(37,5) Error: Illegal qualifier
program test;
{$modeswitch objpas}
{$modeswitch advancedrecords}
{$modeswitch typehelpers}
type
testlongWord = longWord;
var
t : tes
I have been waiting for this day quite a while now...
Finally there is a good low level debugger for embedded targets on Mac,
Linux and Windows...
As a owner of the Freescale K64F Board (with a Cortex-M4 Chip on it) I
can replace the on-board debugger with a free version of JLink-Debugger.
When I remember correctly this error is caused by optimization. Try
building with -O-
Michael
Am 04.10.15 um 10:40 schrieb Edmund Grimley Evans:
3.0.0~rc1 has arrived in Debian experimental, but has failed to build
on several architectures:
https://buildd.debian.org/status/package.php?p=fpc&s
I had a LPC1114 on the breadboard area of a development board for quite
a while, fpc (trunk) is able to create binaries for this cpu.
For lpc devices you need a linker script that creates a special
checksum, besides this it works ootb.
Of course you have to work a lot more low level that with m
Wow Jeppe, I am impressed, you used your time much better than I did,
your port looks pretty complete!
Please have a look at
https://github.com/yunkot/pxl
this lib was mentioned yesterday on lazarus list, this looks like a good
layer above the lowlevel code, there are already implementations
/2015 10:10 PM, Michael Ring wrote:
Wow Jeppe, I am impressed, you used your time much better than I did,
your port looks pretty complete!
Please have a look at
https://github.com/yunkot/pxl
this lib was mentioned yesterday on lazarus list, this looks like a
good layer above the lowlevel code
/2015 10:47 PM, Michael Ring wrote:
I want to interface my Freedom-K64F code with this lib, on first view
this looks pretty straightforward. Any chance to get your great patch
for the use on arbitrary system units into trunk ? (the one you wrote
for me to make cmsis work)
Am 11.10.15 um 22:33
the bitband records? So far I've never
once seen it used in normal code, and the places where it could be
useful you might just as well calculate the offset yourself, or refer
to it in an external unit(maybe one with the helpers? :)
Best Regards,
Jeppe
On 10/11/2015 11:02 PM, Michael R
Hi Simon, have a look at
https://github.com/yunkot/pxl
there is some work going on right now to make this lib fully support
embedded targets.
It today supports Raspberry PI, Intel Galileo and BeagleBone Black and
there is already initial support for lpc11xx + stm32f4xx chips and
support for
Same here when building fpc-arm an a mac with fpc 2.6.4
Von meinem iPad gesendet
> Am 15.11.2015 um 17:31 schrieb MohsenTi :
>
> Hi
> I checkout fpc trunk and try to build it but fpmake raise access violation
> exception
> how to solve it ?
>
> ./fpmake compile --localunitdir=.. --os=linux --c
Works again for me, thank you for fixing!
Michael
Am 15.11.15 um 19:26 schrieb Michael Van Canneyt:
On Sun, 15 Nov 2015, Jonas Maebe wrote:
On 15/11/15 17:31, MohsenTi wrote:
Hi
I checkout fpc trunk and try to build it but fpmake raise access
violation exception
how to solve it ?
./fpmake
I can build trunk fpc but I cannot build the crosscompiler for
arm-embedded for trunk >=32395
This is how I compile:
SUBARCH=armv7em
CROSSOPT="-O2"
make clean buildbase CROSSINSTALL=1 OS_TARGET=embedded CPU_TARGET=arm
SUBARCH=$SUBARCH CROSSOPT="$CROSSOPT" BINUTILSPREFIX=arm-none-eabi- ||
Thank you very much!
Michael
Am 21.11.15 um 15:30 schrieb Jonas Maebe:
Michael Ring wrote:
I can build trunk fpc but I cannot build the crosscompiler for
arm-embedded for trunk >=32395
Sorry, fixed.
Jonas
___
fpc-devel maillist - fpc-de
@Paul:
Jeppe was so nice to check in a new set of units for stm32f4, teensy and
arduino due, this means that my older, much bigger unit for the teensy
is now replaced with a much leaner version. Can you please check if this
causes issues for your distribution?
I am working on highlevel teens
I hope to have something ready for teensy before the end of the week, it
would be great if you could test.
Michael
Am 23.11.15 um 05:45 schrieb Paul Breneman:
Michael,
Jeppe was so nice to check in a new set of units for stm32f4, teensy and
arduino due, this means that my older, much bigger
Starting with rev 33023 I do get a compile error on my mac both for fpc
and fpc-arm crosscompiler:
/usr/local/bin/ppc386 -Ur -Xs -O2 -n -Fui386 -Fusystems
-Fu/Users/ring/devel/fpc-arm/rtl/units/i386-darwin -Fii386 -FE.
-FUi386/units/i386-darwin -dRELEASE-di386 -dGDB -dBROWSERLOG -Fux86
-S
Working again, thank you!
Am 30.01.16 um 20:38 schrieb Sven Barth:
Am 30.01.2016 16:39 schrieb "Michael Ring" <mailto:m...@michael-ring.org>>:
>
> Starting with rev 33023 I do get a compile error on my mac both for
fpc and fpc-arm crosscompiler:
>
> /usr/
Are you sure about RAM? I checked in cpuinfo, it is set to 128MB, this
matches what is written in the user manual, (Page 70)
http://www.st.com/st-web-ui/static/active/en/resource/technical/document/datasheet/DM00037051.pdf
or are the last 16k for some special use? Could not find a hint while
q
chip?
Michael
Am 19.03.16 um 12:36 schrieb Michael Ring:
Are you sure about RAM? I checked in cpuinfo, it is set to 128MB, this
matches what is written in the user manual, (Page 70)
http://www.st.com/st-web-ui/static/active/en/resource/technical/document/datasheet/DM00037051.pdf
or are the
03 schrieb Andrew Haines:
On 03/19/2016 07:36 AM, Michael Ring wrote:
Re-reading your initial mail I am kind of wondering what you actually
did ?
When using -WpSTM32F407VG you will automagially use stm32f407xx.pp unit
which is the correct one for your chip and also stack should be correct
as r
Aehm, and yes, I meant 128kb, not 128MB ;-)
Michael
Am 19.03.16 um 14:20 schrieb Michael Ring:
OK, seems you are not using trunk or an outdated version of trunk as
there are quite a number of units for stm32f4 available in current trunk:
stm32f401xx.pp
stm32f407xx.pp
stm32f411xe.pp
Builf fails with the following message:
/Users/ring/devel/fpc-arm/compiler/ppcrossarm -Cparmv7em @rtl.cfg -Ur
-Tembedded -Parm -XParm-none-eabi- -Xr -Ur -Xs -O2 -n -Fi../inc
-Fi../arm -FE. -FU/Users/ring/devel/fpc-arm/rtl/units/arm-embedded -darm
-dRELEASE -O2 -Fi../objpas/sysutils sysutils.pp
TnX!
Am 27.03.16 um 21:28 schrieb Marco van de Voort:
In our previous episode, Michael Ring said:
the following patch solves the issue, can someboby please apply?
Applied.
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http
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
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
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
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 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
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
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
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
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
:
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
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
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
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
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
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
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
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
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
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
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
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
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
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
);
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
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
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 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
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
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
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
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
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
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
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
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
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
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
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 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
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
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
,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
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
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-
..
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
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
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
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
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
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 ($
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
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.
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.
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
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
101 - 200 of 243 matches
Mail list logo
