fpcupdeluxe and the Pico
lazarus / 77-Embedded
----------------------------------------------------------------------
dbannon · 2024-03-04 11:23
Hi folks.
I note that Michael Ring's patches to FPC have been merges in FPC main
( https://gitlab.com/freepascal.org/fpc/source/-/merge_requests/531 )
and that's really great.
It would be even better if fpcupdelue updated to the newer compiler
and Lazarus, the Lazarus in there now is quite buggy, especially wrt
to some (important to me) code tools things. So, I thought I'd do so
testing to ease DonAlfredo workload a touch. I have established
Lazarus 3.2 works well with Michael's old compiler.
However, I have been unable to build a working Pico cross compiler
direct from FPC Main, first because I used ARMHF (Michael tells me the
armv6m does not do hard float) and then things like "invalid
combination of opcode and operands" its clear I have the wrong
combinations of options. Does anyone know the correct switches to use,
below was my second attempt -
Code: [Select]make clean all FPMAKEOPT="-T 4" CPU_TARGET=arm
OPT="-dFPC_ARMel" CROSSOPT="-CpARMV6M -CaEABI" CROSSBINDIR=/usr/bin
BINUTILSPREFIX=arm-none-eabi-
to be followed by, if the above can be made to work, with -
Code: [Select]make crossinstall OS_TARGET=linux CPU_TARGET=arm
OPT="-dFPC_ARMEL" CROSSBINDIR=/usr/bin BINUTILSPREFIX=arm-none-eabi-
CROSSOPT="-CpARMV6M -CaEABI"
INSTALL_PREFIX=/home/dbannon/bin/FPC/fpc-3.3.1
Any ideas please ?
Davo
----------------------------------------------------------------------
TRon · 2024-03-04 11:31
The wiki seems to suggest to use subarch
QuoteSome hints on Subarchs:
armv6m Subarch is good for Raspberry Pico, SAMD21 based board like
the Arduino Zero or STM32F0/G0/L0 families
----------------------------------------------------------------------
MiR · 2024-03-04 12:06
just out of interest, what does not work for you in latest Lazarus?
At least for me Code completion works, also debugging with a pico
probe (Although I had to first compile latest openocd patches from the
Raspberry Repo.
To be honest I do not need much from Lazarus besides debugging so it
would be nice to know where you struggle.
Michael
----------------------------------------------------------------------
TRon · 2024-03-04 16:34
Quote from: dbannon on March 04, 2024, 12:23:12 pmAny ideas please ?
At least a little better idea now
The following seem to produce a (working) cross-compiler for me.
Code: [Select]make \
clean \ // always clean up before doing anything
crosszipinstall \ // generate an archive that contains the cross
compiler and units, feel free to use crossinstall instead but make
sure you install (in)to the correct directory
FPC=fpc \ // (full path to your) fpc executable or as alternative
you can use PP=<(full path to)ppc executable>
CPU_TARGET=arm \ // seems that pico has an arm (no legs though)
OS_TARGET=embedded \ // pico is an embedded target
SUBARCH=armv6m \ // pico requires specific subarch and indicates
instructions(et) that can be used
CROSSBINDIR="../binutils" \ // path to directory where your binutils
are located (or leave empty when global installed)
BINUTILSPREFIX="arm-embedded-" \ // the prefix used for binutils
CROSSOPT="-CaEABI" // select appropriate ABI
Perhaps the above is able to provide some more details for trying your
own build ?
----------------------------------------------------------------------
dbannon · 2024-03-05 10:10
OK, so I have it working, I am about to start some tests to see how it
works with real code. Below is a script I used in my building and re-
building tests, important to note its NOT intended as a general
purpose script for this purpose, it has no error checking, in most
cases it will just move on to the next step if something bad happens.
First, TRon, where did you get the info about SUBARCH and
crosszipinstall from ? The latter was a red herring, does not appear
on our wiki and breaks the build but SUBARCH was the key to getting it
going even though its not mentioned anywhere in the Pico context. But
it sure worked and I thanks you !
Back to the "script", or as I prefer, list of commands ....
You should, as a minium, look at the top few lines, make sure you have
the current FPC source in ~/Downloads, fpc.zip. Make sure the
directories indicated are not already existing and containing
something (important or otherwise).
Code: Bash [Select][+][-]window.onload = function(){var x1 =
document.getElementById("main_content_section"); if (x1) { var x =
document.getElementsByClassName("geshi");for (var i = 0; i
#!/bin/bash # WARNING - do not think of this as an gp install script,
it does # absolutely NO ERROR CHECKING !!# Demo of how to build a
Raspberry Pico compiler from current 'main' FPC.# Use it as you see
fit. If it destroys your computer, cause you cat to become# pregnant
or any other problem, sorry, no responsibility accepted.# David
Bannon, 2024-03-05 export FPC_VER="fpc-3.3.1"export
SRC_DIR="$HOME/bin/FPC/SRC/$FPC_VER"export
FPC_DIR="$HOME/bin/FPC/$FPC_VER"mkdir -p "$FPC_DIR"mkdir -p
"$SRC_DIR" cd "$SRC_DIR"unzip ~/Downloads/fpc.zipcd fpcmake all make
install INSTALL_PREFIX="$FPC_DIR" make crossinstall CPU_TARGET=arm
OS_TARGET=embedded SUBARCH=armv6m CROSSBINDIR=/usr/bin
BINUTILSPREFIX=arm-none-eabi- CROSSOPT="-CpARMV6M -CaEABI"
INSTALL_PREFIX="$FPC_DIR" cp compiler/ppcx64 "$FPC_DIR"/bin/ppcx64
# cp rather ln -s because further processes seem to 'clean' itcp
compiler/ppcrossarm "$FPC_DIR"/bin/ppcrossarm## the make process does
not copy the rtl/embedded/arm/* files across. Why not ?cp
rtl/embedded/arm/* "$FPC_DIR"/lib/fpc/3.3.1/units/arm-
embedded/rtl/. cd "$FPC_DIR"mkdir -p etcbin/fpcmkcfg -d
basepath="$FPC_DIR" -o etc/fpc.cfgln -s "$FPC_DIR"/lib/fpc/3.3.1/units
units cd binecho "#!/bin/sh" > fpc.bashecho "# A script that ensure
when we start fpc here, it ignores all other fpc.cfg" >> fpc.bashecho
"$FPC_DIR""/bin/fpc -n @$FPC_DIR/etc/fpc.cfg \"\$@\"" >> fpc.bashchmod
u+x fpc.bash
A script to compile a job using this compiler may look like this -
Code: Bash [Select][+][-]window.onload = function(){var x1 =
document.getElementById("main_content_section"); if (x1) { var x =
document.getElementsByClassName("geshi");for (var i = 0; i
#!/bin/bashecho "------- Using the fpc from 3.3.1 ---------"export
MICHAELS_UNITS="$HOME"/Pico2/projects/pico-fpcexamples/units # these
come from https://github.com/michael-ring/pico-
fpcexamples"$HOME"/bin/FPC/fpc-3.3.1/bin/fpc.bash -va -Xu -XParm-none-
eabi- -Tembedded -Parm -CpARMV6M -Fu"$MICHAELS_UNITS" -Wpraspi_pico
project1
If you use this compiler in Lazarus (I use Lazarus 3.2, works fine),
make sure you call the compiler script, fpc.bash, not fpc itself.
Otherwise, it may read you existing, 'other' fpc config and probably,
that would be bad !
If this little package passes all my tests, I will write something up
on the wiki so we have a record of how to do this stuff.
Much thanks to Michael Ring and DonAlfredo
Davo
----------------------------------------------------------------------
TRon · 2024-03-05 10:46
Quote from: dbannon on March 05, 2024, 11:10:37 amFirst, TRon, where
did you get the info about SUBARCH and crosszipinstall from ?
In principle both from the makefile but I follow the commits on FPC
and there the SUBARCH option passed my prying eyes (before the
implementation/support of SUBARCH things were a bit complicated to
build for embedded targets).
from the makefile (I just took a random embedded target for example
purpose):
Quoteifeq ($(CPU_OS_TARGET),arm-embedded)
ifeq ($(SUBARCH),)
$(error When compiling for arm-embedded, a sub-architecture (e.g.
SUBARCH=armv4t or SUBARCH=armv7m) must be defined)
endif
override FPCOPT+=-Cp$(SUBARCH)
endif
Thus, no need to provide the -Cp argument manually
and for crosszipinstall:
Quote.PHONY: crossall crossinstall crosszipinstall
crosssinglezipinstall
crossall:
$(MAKE) all CROSSINSTALL=1
crossinstall:
$(MAKE) install CROSSINSTALL=1
crosszipinstall:
$(MAKE) zipinstall CROSSINSTALL=1
It is a phony target. You could just as well provide zipinstall
CROSSINSTALL=1 to your command.
Quote The latter was a red herring, does not appear on our wiki and
breaks the build
In that case, please retry with clean directories. I have been using
that since it was present and never got me into troubles. the auto-
build of the archive comes in very handy because it allows to store
the created archive somewhere safe for later use (very pleasant in
case for release compilers, perhaps not so in case you build trunk on
a regular base)
QuoteI thanks you !
You are more than welcome dbannon. Glad to hear/see that it was able
to get you further in your endeavors.
A quick note about the rest of your script. You could opt for creating
a bash alias (or script as you did) that invokes the correct compiler
(and its options) when addressing the pico compiler, e.g. name it fpc-
pico so that it doesn't pick up on the 'normal' FPC installation.
(whatever normal is for your use case)
Personally i had more issues with figuring out the -Wpraspi_pico
option. I did notice this (undocumented ?) -Wp option in on the
embedded wiki pages, but not what to use for the pico (had to dive
into the compiler source for that )
btw should that option not read -Wprp2040 and/or -Wprppico ? (edit:
strike that, apparently my sight was crooked when I looked it is
indeed raspi-pico )
Thank you for sharing
----------------------------------------------------------------------
MiR · 2024-03-05 11:03
Another hint:
The lpi files in my examples on github are your friend....
There you can set configurations for different targets in one place
and use lazbuild to apply them.
Here's a partial example:
You can configure Targets from inside Lazarus in a GUI way and re-use
what you have done with lazbuild:
lazbuild --build-all builds your code for all the default
target
lazbuild --build-all --build-mode="Adafruit Feather RP2040"
builds for the specific Adafruit Feather RP2040 board.
----------------------------------------------------------------------
dbannon · 2024-03-06 00:19
TRon - My main focus here was confirming that the "official" "main"
(you know what I mean) contains a usable pico compiler so that
DonAlfredo can switch over to using it rather than Michael's out of
date one. But it sounds like you have an "in use" version already ? I
could have saved some time ! There does not seem any great risk of a
FPC release soon but it pays to be prepared !
Quote from: TRon on March 05, 2024, 11:46:05 am....You could opt for
creating a bash alias (or script as you did) that invokes the correct
compiler (and its options) when addressing the pico compiler, e.g.
name it fpc-pico so that it doesn't pick up on the 'normal' FPC
installation. (whatever normal is for your use case)
Actually, I approach that differently, and beyond the scope of this
thread. I keep an env var, OLD_PATH, that has my path before I added
my default FPC, so I can, in the middle of a script (eg starting
Lazarus), build a new clean path to suit whatever compiler I want. I
glossed over that ...
QuotePersonally i had more issues with figuring out the -Wpraspi_pico
option. I did notice this (undocumented ?)
btw should that option not read -Wprp2040 and/or -Wprppico ?
-Wpraspi_pico appears in Michaels Lazarus example projects, under
Custom Options, so, I expect its the right one to use.
In cpuinfo.pas, both 'RP2040' and 'RASPI_PICO' are listed around
line #1063. But 'RP2040' is shown as having zero flashsize and that
cannot be right, RASPI_PICO seems to have numbers more consistent
with, eg https://petewarden.com/2024/01/16/understanding-the-
raspberry-pi-picos-memory-layout that is -
flashbase:$10000000;
flashsize:$00200000;
srambase:$20000000;
sramsize:$00042000),
I suspect RP2040 may be just a generic place holder ?
I was pretty sure I saw -WpXXXX documented somewhere but I cannot find
it now. I remember seeing it with a list of values and the words
"embedded only". I suggest its absence is a FPC documentation bug,
"-h" should show it IMHO ??
Michael - yep, I normally use Lazarus projects but wanted to
understand the process and a command line is clear and unambiguous. Do
you agree that "fpc -h" should mention -WpXXXX ? And should it be, in
the case, RP2040 or RASPI_PICO ?
Davo
----------------------------------------------------------------------
TRon · 2024-03-06 01:31
Quote from: dbannon on March 06, 2024, 01:19:34 amTRon - My main focus
here was confirming that the "official" "main" (you know what I mean)
contains a usable pico compiler so that DonAlfredo can switch over to
using it rather than Michael's out of date one.
I am not quite sure what it is exactly you are trying to say there...
trunk has been able to build for pico since the patches from MiR were
accepted (well, plus-minus a few hiccups ), FPCUpDeluxe is able to
build trunk and I have seen from Don Alfredo's post that he has
addressed issues wrt embedded targets so that means that FPCUpdeluxe
should be able to build a cross-compiler for you (haven't tried yet
though see edit). So unless Don A. is cheating and just copies over a
pre-build when you select embedded raspi target instead of actually
building it from trunk sources.....
But, imho it is always good to known and be able to manually build
your binutils, compilers and cross-compilers.
edit: tried fpcupdeluxe and seems to work as expected (use the link to
the wiki-page in my first reply that shows how to setup arm embedded
using fpcupdeluxe). Though other than available instructions (1,2,3)
make sure (at step 4) to select "none" for Arm target, "eabi" for ABI,
and don't forget to select the right subarch. Do not let the (error)
dialog that pops-up fool you, just press ok and it will try to
download anything that is missing.
Code: [Select]$ ./ppcrossarm -h
Free Pascal Compiler version 3.3.1-15371-g0fb4fca957-dirty
[2024/03/05] for arm
QuoteBut it sounds like you have an "in use" version already ? I
could have saved some time ! There does not seem any great risk of a
FPC release soon but it pays to be prepared !
Well, I have a cross-compiler that is able to compile... if it
actually works, I have no idea (fwiw: that is not too odd, I cross
compile for many targets for which I either do not have the
hardware/software or not the time to test myself) And yes, everything
you are able to learn about new targets/features from the (trunk)
compiler before the official release has been published is good. Very
good even, because if you run into issues then they can be reported
before the actual release and as a result /can/ be fixed *hint hint*
QuoteActually, I approach that differently, and beyond the scope of
this thread. I keep an env var, OLD_PATH, that has my path before I
added my default FPC, so I can, in the middle of a script (eg starting
Lazarus), build a new clean path to suit whatever compiler I want. I
glossed over that ...
Ok, yes that is also a solution (I used to use that as well but kept
forgetting the name of the environment variable and back then was
still using windows that all of a sudden required you to have elevated
access rights when wanting to change envars so switched over to using
the (undocumented) -V option, but with a small twist to suit my
needs). I'll leave it at that if it is out of scope.
Quote-Wpraspi_pico appears in Michaels Lazarus example projects, under
Custom Options, so, I expect its the right one to use.
Yeah but things do tend to change (in trunk) once in a while... (btw
I looked at the wrong record-field when I wrote down rppico, I had it
corrected in my (previous) post while you prepared your reply). So you
were right all along
QuoteIn cpuinfo.pas, both 'RP2040' and 'RASPI_PICO' are listed ...
Ah ok, thank you for the information because tbh I haven't looked very
close to the implementation details for the pico target. I trust your
judgement on that.
QuoteI was pretty sure I saw -WpXXXX documented somewhere but I cannot
find it now. I remember seeing it with a list of values and the words
"embedded only". I suggest its absence is a FPC documentation bug,
"-h" should show it IMHO ??
Oh, now I feel stupid (simply because I am ). You are absolutely
right,
Quote./ppcrossarm -h
Free Pascal Compiler version 3.3.1 [2024/03/04] for arm
Copyright (c) 1993-2024 by Florian Klaempfl and others
...
-WN Do not generate relocation code, needed for debugging
(Windows)
-Wp Specify the controller type; see fpc -i or fpc -iu
for possible values
-WP Minimum iOS deployment version: 3.0, 5.0.1, ...
(Darwin)
I spare you (and other readers) the ridiculous amount of output
produced by ./ppccrossarm -i and -iu
----------------------------------------------------------------------
dbannon · 2024-03-06 04:05
Quote from: TRon on March 06, 2024, 02:31:57 amtrunk has been able to
build for pico since the patches from MiR were accepted ...
Only about 3 months ago.
Quote[.....FPCUpDeluxe is able to build trunk and I have seen from Don
Alfredo's post that he has addressed issues wrt embedded targets so
that means that FPCUpdeluxe should be able to build a cross-compiler
for you
While good to hear, my tests here indicate that fpcupdeluxe is still
getting its Pico compiler from Michael's gitlab repo FPC source,
static for a year or so.
See attached image of a week old fpcupdeluxe. I start fpupdeluxe,
click the "Pico" button (Careful, it starts immediately, does not show
a summary of what its going to do, just runs ! ).
The key here might be "click the Pico button" bit - maybe it behaves
differently if you build it up from the left hand controls ?
Code: [Select]$ ./ppcrossarm -h
Free Pascal Compiler version 3.3.1-15371-g0fb4fca957-dirty
[2024/03/05] for arm
Yes ! That makes sense ! I was looking at -h from a fpc binary, not
ppcrossarm ! I'm surprised they are different but I guess it makes
sense.
Code: Pascal [Select][+][-]window.onload = function(){var x1 =
document.getElementById("main_content_section"); if (x1) { var x =
document.getElementsByClassName("geshi");for (var i = 0; i ppcrossarm
-iu for example lists all the pico (etc) boards, Code: Pascal
[Select][+][-]window.onload = function(){var x1 =
document.getElementById("main_content_section"); if (x1) { var x =
document.getElementsByClassName("geshi");for (var i = 0; i fpc -iu
lists nothing ! But a fpc binary that can find an appropriate
ppcrossarm will accept -WpXXX. So, should, IMHO, list it as an
option.
A very useful discussion, lots of things becoming clearer.
Davo
----------------------------------------------------------------------
DonAlfredo · 2024-03-06 06:36
QuoteWhile good to hear, my tests here indicate that fpcupdeluxe is
still getting its Pico compiler from Michael's gitlab repo FPC source,
static for a year or so.
The latest release of fpcupdeluxe should use normal FPC trunk !
----------------------------------------------------------------------
dbannon · 2024-03-06 09:27
Yep, fresh download just now, fpc comes from
https://gitlab.com/freepascal.org/fpc/source ! Great.
But Lazutils is not building -
Code: Pascal [Select][+][-]window.onload = function(){var x1 =
document.getElementById("main_content_section"); if (x1) { var x =
document.getElementsByClassName("geshi");for (var i = 0; i
fpcupdeluxe: Executing: /usr/bin/make
--directory=/home/dbannon/fpcupdeluxe/lazarus USESVN2REVISIONINC=0
FPC=/home/dbannon/fpcupdeluxe/fpc/bin/x86_64-linux/fpc.sh
PP=/home/dbannon/fpcupdeluxe/fpc/bin/x86_64-linux/ppcx64
PREFIX=/home/dbannon/fpcupdeluxe/lazarus
INSTALL_PREFIX=/home/dbannon/fpcupdeluxe/lazarus
INSTALL_BASEDIR=/home/dbannon/fpcupdeluxe/lazarus
LAZARUS_INSTALL_DIR=/home/dbannon/fpcupdeluxe/lazarus/
FPCDIR=/home/dbannon/fpcupdeluxe/fpcsrc
FPCMAKE=/home/dbannon/fpcupdeluxe/fpc/bin/x86_64-linux/fpcmake
PPUMOVE=/home/dbannon/fpcupdeluxe/fpc/bin/x86_64-linux/ppumove
OPT=-vw-n-h-l-d-u-t-p-c- -g -gl lazbuild (working dir:
/home/dbannon/fpcupdeluxe/lazarus) /usr/bin/make -C packager/registrat
ion /home/dbannon/fpcupdeluxe/fpc/bin/x86_64-linux/fpc.sh -MObjFPC
-Scghi -O1 -g -gl -l -vewnhibq -Fu.
-Fu/home/dbannon/fpcupdeluxe/fpcsrc/rtl -FE. -FU../units/x86_64-linux
-Cg -Fl/usr/lib/gcc/x86_64-linux-gnu/9 -vw-n-h-l-d-u-t-p-c- -g -gl
-dx86_64 fcllaz.pas (1002) Target OS: Linux for x86-64(3104) Compiling
fcllaz.pas(3104) Compiling lazaruspackageintf.pas(1008) 124 lines
compiled, 0.1 sec /usr/bin/make -C components/lazutils /home/dbannon/f
pcupdeluxe/fpc/bin/x86_64-linux/fpc.sh -MObjFPC -Scghi -O1 -g -gl -l
-vewnhibq -Fu../../packager/units/x86_64-linux -Fu.
-Fu/home/dbannon/fpcupdeluxe/fpcsrc/rtl -FE. -FUlib/x86_64-linux -Cg
-Fl/usr/lib/gcc/x86_64-linux-gnu/9 -vw-n-h-l-d-u-t-p-c- -g -gl
-dx86_64 lazutils.pas(1002) Target OS: Linux for x86-64(3104)
Compiling lazutils.pas make: *** [Makefile:3762: lazutils] Error
2(3104) Compiling utf8process.pp(3104) Compiling fileutil.pas(3104)
Compiling lazfileutils.pas(3104) Compiling lazutf8.pas(3104) Compiling
lazutilsstrconsts.pas(3104) Compiling uitypes.pas/home/dbannon/fpcupde
luxe/lazarus/components/lazutils/uitypes.pas(105,14) Error: (3285)
Expected another 2 array elements /home/dbannon/fpcupdeluxe/lazarus/co
mponents/lazutils/uitypes.pas(93,58) Fatal: (10026) There were 1
errors compiling module, stopping Fatal: (1018) Compilation
aborted Error: /home/dbannon/fpcupdeluxe/fpc/bin/x86_64-linux/ppcx64
returned an error exitcodefpcupdeluxe: ERROR: Lazarus Native Installer
(BuildModuleCustom: Lazbuild): make returned exit status #512. ERROR:
Fpcupdeluxe fatal error !Sequencer (UserIDE): Failure running
fpcupdeluxe: error executing sequence UserIDESequencer (Lazarus):
Failure running fpcupdeluxe: error executing sequence LazarusSequencer
(Default): Failure running fpcupdeluxe: error executing sequence
Default
This did, apparently, build OK with last weeks fpcupdeluxe. I'm using
a relatively old Linux, U20.04, and, to be honest, I don't need it,
so, maybe if its OK for everyone else, no heroic efforts for me please
!
Sorry !
Davo
----------------------------------------------------------------------
MiR · 2024-03-06 09:37
Building trunk for fpc and lazarus seems to be quite an adventure atm.
What worked for me was to use the december version of fpcupdeluxe
which still uses older bootstrap compiler (I guess) and that worked
fine 1-2 weeks ago.
Whith latest Bootstrap compiler errors change on a daily basis so it
looks as if there is quite some work happening on trunk. But this all
is target dependent, I had more issues on MacOSX for X86_64 than for
MacOSX arm64, other platforms may be unaffected.
----------------------------------------------------------------------
dbannon · 2024-03-06 10:43
Quote from: MiR on March 06, 2024, 10:37:33 amBuilding trunk for fpc
and lazarus seems to be quite an adventure atm.
We really don't need to track main in either case for the Pico. Just
known stable snapshots from, eg, last six months or so.
For Lazarus, why not a stable release such as 3.0 or 3.2 ?
FPC is harder, we have not had a release of FPC since the Pico patches
were merged so, without extensive testing, one snapshot of main is as
good as another. I guess.
DonAlfredo, fpcupdeluxe is a magnificent product, a fantastic effort
from yourself. You must have trouble finding the time, why not ask
people here to run a barrage of tests on proposed candidates ? I was
getting ready to do just that ....
Hmm, I see, Pico (and similar) are special cases. Most the other
choices in fpcupdeluxe are specifically selected by the user. Makes
sense..... Just unlucky here I guess. Anyway, for the Pico I'd suggest
a recent, stable, release of Lazarus and I'm happy to do some FPC
testing of any snapshot of main you nominate.
Davo
----------------------------------------------------------------------
TRon · 2024-03-06 18:28
Quote from: dbannon on March 06, 2024, 11:43:42 amWe really don't need
to track main in either case for the Pico. Just known stable snapshots
from, eg, last six months or so.
True. But you still would have to take an eye on things so that you
know which snapshots do work (and which don't).
QuoteFor Lazarus, why not a stable release such as 3.0 or 3.2 ?
It is guessing from my part (I usually do not use Lazarus) but most
probably because new features of the compiler are not supported by
stable Lazarus (it doe snot have notion of newly additions to the
compiler). f.e. certain targets can't even be build by Lazarus stable
(simply because the target was added in trunk compiler).
QuoteFPC is harder, we have not had a release of FPC since the Pico
patches were merged so, without extensive testing, one snapshot of
main is as good as another. I guess.
That is why I added the "hint hint" in one of my previous answers. You
can only be sure by testing and in case of issues please report them
so that they can be fixed.
The most simple form is just trying to build a certain target and give
the developers a shout when a build fails (with accompanied error
message). Some people have their own complete build-system in place to
do just that for the targets they care about.
@MiR:
Yes indeed, lately a lot of activity going on in trunk so it can
happen that things fail. As a generic remark to the reader just keep
trying till it works (again) but sometimes it can take a couple of
days. If persistent then try and see if the error is reported (in the
bug-tracker) and in case not the please report yourself.
----------------------------------------------------------------------
dbannon · 2024-03-06 23:24
Quote from: TRon on March 06, 2024, 07:28:16 pmQuoteFor Lazarus, why
not a stable release such as 3.0 or 3.2 ?
It is guessing from my part (I usually do not use Lazarus) but most
probably because new features of the compiler are not supported by
stable Lazarus (it doe not have notion of newly additions to the
compiler). f.e. certain targets can't even be build by Lazarus stable
(simply because the target was added in trunk compiler).
Its not often a whole new target is added. I have a Lazarus 2.0.10
install, it has full support for arm and ARMv6m. Generally, most of
Lazarus is target agnostic, My 2.0.10 has a lot more bugs, poor Help,
buggy code tools but if you are used to those minor things, would work
fine.
QuoteYou can only be sure by testing and in case of issues please
report them so that they can be fixed.I guess you missed my comments
about testing. Sigh ....
I would rather see fpcupdeluxe ship with a tested combination of
products. At present, fpcupdeluxe, for Pico, points to main for both
fpc and lazarus. Every time a merge happens in either, fpcupdeluxe
gets a new, untested product to install. Given there is no benefit in
tracking main in either, choosing know good snapshots would, IMHO make
more sense. But its quite unreasonable to ask DonAlfredo to do that
testing. I suggested, in the atypical case of Pico (and probably
similar) he should request users of Pico to run some tests for him.
Davo
----------------------------------------------------------------------
TRon · 2024-03-06 23:53
Quote from: dbannon on March 07, 2024, 12:24:14 amI guess you missed
my comments about testing. Sigh ....
I did so apologies.
QuoteI would rather see fpcupdeluxe ship with a tested combination of
products.
That is not the aim of/for FPCUpDeluxe. It is a tool that either
downloads and installs optional a) a released compiler version b) a
released lazarus version or c) fixes for one or both of them d) trunk
(main as you name it) for either one of them and d) any cross-compiler
.
Additional FPCUpDeluxe is able to bootstrap that for you and provide
all the necessary (cross)tools and startup code for selected
(cross)-targets.
QuoteAt present, fpcupdeluxe, for Pico, points to main for both fpc
and lazarus. Every time a merge happens in either, fpcupdeluxe gets a
new, untested product to install. Given there is no benefit in
tracking main in either, choosing know good snapshots would, IMHO make
more sense. But its quite unreasonable to ask DonAlfredo to do that
testing. I suggested, in the atypical case of Pico (and probably
similar) he should request users of Pico to run some tests for him.
Yes, that comes with the territory. FPCUpDeluxe allows you to fill in
hash codes for revisions in trunk (either FPC or Lazarus) so that we
the users are capable of selecting the source from any commit that we
want to use. Same as you can do so manually with git.
So that leave us the users to find a few hashes that work for us, in
particular for the pico target if you wish.
There really is no point for Don Alfredo to do that for us (I get it
that you want to offer your help with that) as there are literally
dozens of targets to keep track off (that is practically work for
ages).
So build FPC and Lazarus finding a hash that works for you and write
it down somewhere for later use (wiki comes to mind). But do realize
that whenever a stable release is able to target your preferred
hardware there is hardly any point in upgrading unless the rtl for
that target changed or was fixed (or in case you really want to use
that new cool feature that was introduced in trunk).
As far as my knowledge goes that means stick to a stable Lazarus
release and use (some version of) FPC trunk (and which version that
is, is something that we can determine by its hash). And that is even
if you want to rely on Lazarus (I myself do not use Lazarus for
development). I personally have no time figuring out which version of
Lazarus and FPC work together (or not), for me it is either it works
or it doesn't and on occasion I let my build-script try and build a
version of FPC trunk and Lazarus trunk (and in case it works I then
determine whether or not I want to keep the produced archives).
----------------------------------------------------------------------
cdbc · 2024-03-07 01:21
Hi Davo
I dunno if this could be of use to you, but I'm running a fairly
recent trunk on PCLinuxOS, installed with FpcUpDeluxe and it goes like
stink, literally NO problems & fast. You're talking about a hash,
could this be it?QuoteFree Pascal Compiler version
3.3.1-15019-g664f8fc2ba-dirty [2024/01/28] for x86_64
Copyright (c) 1993-2024 by Florian Klaempfl and others
Target OS: Linux for x86-64Dunno 'bout 'Pico' but if it's a stable
working compiler you're after...
Regards Benny
----------------------------------------------------------------------
TRon · 2024-03-07 01:37
Quote from: cdbc on March 07, 2024, 02:21:20 amDunno 'bout 'Pico' but
if it's a stable working compiler you're after...
At the least after november 11th 2023 (because that was the date that
support for pico from MiR was added to trunk) but the later the better
(and if I understood dbannon correctly then a FPC that is also able to
work with a stable Lazarus release)
----------------------------------------------------------------------
cdbc · 2024-03-07 01:57
Hi TRon
Does 3.0 count as a stable Laz release?
Regards Benny
----------------------------------------------------------------------
TRon · 2024-03-07 02:07
Quote from: cdbc on March 07, 2024, 02:57:58 amDoes 3.0 count as a
stable Laz release?
Dunno. Did it crash for you ?
Thus, again if I understood dbannon correctly:
- use FPUpDeluxe to create FPC (or do it manually/scripted)
- create cross-compiler using fpcUpDeluxe (or do it manually/scripted)
- use the hosted FPC to build Lazarus (stable) from source manually
(or scripted)
----------------------------------------------------------------------
cdbc · 2024-03-07 02:17
Hi
Nah... Had some teething-aches with QT5 and them damn window-titles in
laz & had to use non-native file-dialogs due to speed reasons, but
that's all fixed now and I'm a /happy/ camper
Regards Benny
----------------------------------------------------------------------
TRon · 2024-03-07 02:43
@cdbc:
Ah yes, I recognize the 'normal' issues that plague you
Unfortunately due to a bug in FPC I am unable to compile Lazarus 3.2
with recent trunk compiler. The workaround is present in Lazarus trunk
but that is besides the goal (and trunk FPC does not compile trunk
Lazarus atm).
edit: recent trunk compiler is also unable to build Lazarus 3.0 due to
this so that afaik means a trunk FPC compiler at least before feb 13th
2024.
----------------------------------------------------------------------
dsiders · 2024-03-07 04:05
Quote from: TRon on March 07, 2024, 03:43:13 am@cdbc:
Ah yes, I recognize the 'normal' issues that plague you
Unfortunately due to a bug in FPC I am unable to compile Lazarus 3.2
with recent trunk compiler. The workaround is present in Lazarus trunk
but that is besides the goal (and trunk FPC does not compile trunk
Lazarus atm).
edit: recent trunk compiler is also unable to build Lazarus 3.0 due to
this so that afaik means a trunk FPC compiler at least before feb 13th
2024.
I'm using FPC 3.3.1-15189-gae06528db4 (2024-02-18) to compile Lazarus
3.99 (main), 3.2, and 3.0. Apparently there are version after this one
that have issues too.
I have no idea what a "pico" is (some kind of spicy pepper?).
----------------------------------------------------------------------
TRon · 2024-03-07 05:03
Quote from: dsiders on March 07, 2024, 05:05:35 amI'm using FPC
3.3.1-15189-gae06528db4 (2024-02-18) to compile Lazarus 3.99 (main),
3.2, and 3.0. Apparently there are version after this one that have
issues too.
Thank you very much dsiders. I can at least confirm that the compiler
can be build with bootstrap 3.2.2 and is able to build Lazarus 3.2 as
well as Lazarus trunk.
That should be recent enough for both FPC and Lazarus (though Lazarus
and tools are known to have issues with new constructs from trunk).
QuoteI have no idea what a "pico" is (some kind of spicy pepper?).
I could start talking about the size of my little .... toe but, it is
actually about this
----------------------------------------------------------------------
dbannon · 2024-03-08 02:04
This is going on and on ....
My problem was that fpcupdeluxe was unable to build Lazarus main
using fpc main at the present. A know issue apparently.
My observation was that, from time to time, that is to be expected.
My point was that fpcupdeluxe does not need to use main in either FPC
or Lazarus. By using known good snapshots (how ever arrived at) it
would be more stable wrt Pico.
end.
Davo
(sorry, been out of circulation for a while. My aging U20.04 suddenly
(??) developed a number of software problems, I'm now on Debian
Bookworm. )
----------------------------------------------------------------------
TRon · 2024-03-08 02:41
Quote from: dbannon on March 08, 2024, 03:04:11 am My point was that
fpcupdeluxe does not need to use main in either FPC or Lazarus. By
using known good snapshots (how ever arrived at) it would be more
stable wrt Pico.
You seem to have missed the fact that it is you the user that can
instruct FPCUpDeluxe to use a particular snapshot by providing a
hashcode that belongs to it
BTW: current issue was reported to have been solved so in theory you
should be able to build trunk/trunk again. So, note down their hashes.
----------------------------------------------------------------------
dbannon · 2024-03-08 06:19
Quote from: TRon on March 08, 2024, 03:41:55 amYou seem to have missed
the fact that it is you the user that can instruct FPCUpDeluxe to use
a particular snapshot by providing a hashcode that belongs to it
Open fpcupdeluxe, click the Pico button, Dialog says "going to
install....", Yes or No. If you click Yes you get main for both, if
you click 'No' you go back to opening screen. There may well be a way
to request particular commits, but I don't see it.
Davo
----------------------------------------------------------------------
TRon · 2024-03-08 06:28
Quote from: dbannon on March 08, 2024, 07:19:18 amOpen fpcupdeluxe,
click the Pico button,
No wonder we're running around in circles
Remember that first reaction I posted that had a link to the wiki
page.... That means that you need to manually select what you want to
install. Select FPC version (trunk), select Lazarus version (3.2) and
press setup+ to set the details for the compilation and the branch
name (main) and hash-code (ae06528db4 known to be working) for FPC
then you can press the install FPC and Lazarus button (*). And yes
that means you need to do a second step (following the wiki pictures),
namely adding the arm cross-compiler (set subarch etc as discussed).
If you want a single button then I can create a form with a button on
it running a bash script that will do all in one go
edit (*) with the exception of this pesky issue but I am working on
that.
----------------------------------------------------------------------
DonAlfredo · 2024-03-08 09:25
Pressing the Pico button does:
Install FPC trunk/main and Lazarus trunk/mainGet latest release of
develtools4fpc from https://github.com/michael-
ring/develtools4fpc/releasesInstall cross-compiler targetting arm-
embedded with subarch armv6mSo, you can execute these steps by
yourselves, with the working Lazarus hash as first step.
----------------------------------------------------------------------
dbannon · 2024-03-08 10:19
First cut at a wiki page
https://wiki.freepascal.org/Building_a_Pico_Compiler
Davo
----------------------------------------------------------------------
DonAlfredo · 2024-03-08 10:27
This wiki entry is good, but the whole (complex) process of setting up
a Pico-environment is not for the faint-hearted.
The pico-button of fpcupdeluxe should take care of all of these
implementation details. I hope it still does.
----------------------------------------------------------------------
MiR · 2024-03-08 10:30
Instead of this:
cp rtl/embedded/arm/* "$FPC_DIR"/lib/fpc/3.3.1/units/arm-
embedded/rtl/.
better do that:
mkdir -p "$FPC_DIR"/lib/fpc/3.3.1/units/arm-embedded/armv6m/eabi/rtl/.
cp rtl/embedded/arm/* "$FPC_DIR"/lib/fpc/3.3.1/units/arm-
embedded/armv6m/eabi/rtl/.
this is compatible with what fpcupdeluxe does, and more important, it
allows you to use different subarchs, I for example work with armv6m,
armv7m at the same time... (And that is the reason why it is done that
way in fpcupdeluxe)
And fully agree to DonAlfredo, it is not for the fait at heart and
people should not later complain to him (or to me) when things do not
work with fpcupdeluxe, different archs and my pico fpc code....
Michael
----------------------------------------------------------------------
MiR · 2024-03-08 10:33
..and you should also put system.ppu to
"$FPC_DIR"/lib/fpc/3.3.1/units/arm-embedded/armv6m/eabi/
and you also need to add those paths to fpc.cfg...
Lots of things to do instead of the press of one button....
----------------------------------------------------------------------
dbannon · 2024-03-08 11:54
Quote from: MiR on March 08, 2024, 11:30:28 am....
mkdir -p "$FPC_DIR"/lib/fpc/3.3.1/units/arm-embedded/armv6m/eabi/rtl/.
cp rtl/embedded/arm/* "$FPC_DIR"/lib/fpc/3.3.1/units/arm-
embedded/armv6m/eabi/rtl/.
Trouble is that at that stage, the fpc makefile has already put
"$FPC_DIR"/lib/fpc/3.3.1/units/arm-embedded/rtl/ there and populated
it with some files. So we would end up with both -
"$FPC_DIR"/lib/fpc/3.3.1/units/arm-embedded/armv6m/eabi/rtl/files
"$FPC_DIR"/lib/fpc/3.3.1/units/arm-embedded/rtl/files
I could move the makefile ones but if a previous install has already
put another architecture there, thats not going to work ! I think what
you say makes a lot of sense but if it involves altering the makefile,
thats a whole new ball game. Similarly, unless the compiler thinks to
look in units/$CPU-$OS/$SUBARCH/$ABI/rtl its going to need alteration
to the fpc.cfg file. It might do, it does try hard to find the right
files. I'll run some tests.
But I also note that the "make crossinstall" is given both the ABI and
the SUBARCH but chooses not to use them when installing the first
batch of files.
QuoteAnd fully agree to DonAlfredo, it is not for the fait at heart
and people should not later complain to him (or to me) when things do
not work with fpcupdeluxe, different archs and my pico fpc code....
Yep, I agree too. Absolutely. But I also think its important that how
it actually works is documented somewhere too. And DonAlfredo does a
lot of work on fpcupdeluxe, I'd rather not add to his burden.
Davo
----------------------------------------------------------------------
DonAlfredo · 2024-03-08 12:07
QuoteBut I also think its important that how it actually works is
documented somewhere too.That would be good. Documentation is
available, but these details (regarding subarch) are not.
You might take a look at the Makefile commands that are visible when
building the cross-compiler. Also, the fpcupdeluxe sources will show
some.
A very important setting is : INSTALL_UNITDIR. This is how the magic
of separating subarchs and ABI's is handled. Again, its not easy. But
needed for correct handling of different setups.
----------------------------------------------------------------------
MiR · 2024-03-08 12:35
I guess the best is that before publishing the page you check that all
files of your build are in the same subdirectories as they are in a
build by fpcupdeluxe. (And that your fpc.cfg contains the same
settings for the relevant entries)
Then the risk of breaking anything is close to zero.
If you have questions feel free to ask, it has been ages since I last
did a fpc build outside of fpcupdeluxe but memory will very likely
come back as I did manual builds for years before finally DonAlfredo
was kind enough to lift this burden off my shoulders......
----------------------------------------------------------------------
TRon · 2024-03-08 19:54
Quote from: DonAlfredo on March 08, 2024, 10:25:31 amPressing the Pico
button does:
Install FPC trunk/main and Lazarus trunk/mainGet latest release of
develtools4fpc from https://github.com/michael-
ring/develtools4fpc/releasesInstall cross-compiler targetting arm-
embedded with subarch armv6mSo, you can execute these steps by
yourselves, with the working Lazarus hash as first step.
Yes, I was aware of this but apparently dbannon did not.
His 'confusion' (?) seem to originate from the fact that once in a
while trunk compiler and trunk Lazarus do not play nice with each
other.
For me personally I'll just shrug when that happens and try again
later. Though FPCUpDeluxe is perfectly capable of building either
using their respective hash-codes so that you can select a particular
moment in trunk/main for the build(s).
The trick is finding a combination that works and besides that as
mentioned before, when a new compiler release arrives, this discussion
is more or less moot as support for the pico is then available
(currently pico is only supported in trunk).
That said, it is always a good idea to know how something can be build
and describe the process so thank you very much for your entries in
the wiki dbannon
----------------------------------------------------------------------
Thaddy · 2024-03-08 20:14
which happened recently to the effect that multiple people were trying
to resolve that asap.
and they fixed it. there is a risk in using trunk! it is not a
release. Do not use trunk versions if you do not know what you are
doing. Use stable or maybe fixes.
----------------------------------------------------------------------
TRon · 2024-03-08 20:19
Quote from: DonAlfredo on March 08, 2024, 01:07:45 pmThat would be
good. Documentation is available, but these details (regarding
subarch) are not.
You might take a look at the Makefile commands that are visible when
building the cross-compiler. Also, the fpcupdeluxe sources will show
some.
A very important setting is : INSTALL_UNITDIR. This is how the magic
of separating subarchs and ABI's is handled. Again, its not easy. But
needed for correct handling of different setups.
Also, in case you haven't already, take note of this
----------------------------------------------------------------------
dbannon · 2024-03-08 23:28
Quote from: TRon on March 08, 2024, 08:54:26 pm.....
Yes, I was aware of this but apparently dbannon did not.
His 'confusion' (?) seem to originate from the fact that once in a
while trunk compiler and trunk Lazarus do not play nice with each
other.
TRon, can I respectfully and in the name of friendship, ask you to
stop telling everyone what I think ?
In the unlikely event that someone else is interested in whats
happening inside my brain, they would be better informed by looking at
my posts.
Thanks.
David
----------------------------------------------------------------------
TRon · 2024-03-08 23:40
Quote from: dbannon on March 09, 2024, 12:28:05 amQuoteHis 'confusion'
(?) seem to originate from the fact that once in a while trunk
compiler and trunk Lazarus do not play nice with each other.
TRon, can I respectfully and in the name of friendship, ask you to
stop telling everyone what I think ?
Yes, that is no problem at all.
It was by all means not meant to provide an insight to your thinking.
That is why I enclosed the confusion part into quotes and added the
question mark. I meant no disrespect.
----------------------------------------------------------------------
dbannon · 2024-03-09 02:44
OK, I have established, in this situation, that fpc, with an
unmodified fpc.cfg, does not look in the dir Michael suggested -
Code: [Select]"$FPC_DIR"/lib/fpc/3.3.1/units/arm-
embedded/armv6m/eabi/rtl/filesbut it does look in
Code: [Select]"$FPC_DIR"/lib/fpc/3.3.1/units/arm-
embedded/armv6m/files # note: minus the eabi/rtl
Michael knows far (far, far) more than I about embedded, but I suggest
that does solve the problem he is worried about ? 'armv6m' is enough
to distinguish which cpu we are talking about ? As I understand it,
armv6m implies ABI=eabi ? Dropping the 'rtl' is a pity but for obvious
reasons, 'rtl' means something quite different in the embedded world
(IMHO).
Of course, that approach would still involve changes to the Makefile,
its the one who creates the original abbreviated subdir as
demonstrated here (its obviously not a full list) -
Code: [Select]==== This is after running make crossinstall but before
the other, tidy up things =====
testFPC/FPC/fpc-3.3.1/lib/fpc/3.3.1/units/arm-embedded/rtl contains 63
files
-rw-r--r-- 1 dbannon dbannon 23296 Mar 9 11:37 charset.o
-rw-r--r-- 1 dbannon dbannon 18101 Mar 9 11:37 charset.ppu
-rw-r--r-- 1 dbannon dbannon 844608 Mar 9 11:37 classes.o
-rw-r--r-- 1 dbannon dbannon 954543 Mar 9 11:37 classes.ppu
....
-rw-r--r-- 1 dbannon dbannon 802772 Mar 9 11:37 system.o
-rw-r--r-- 1 dbannon dbannon 969333 Mar 9 11:37 system.ppu
....
-rw-r--r-- 1 dbannon dbannon 2020 Mar 9 11:37 uuchar.o
-rw-r--r-- 1 dbannon dbannon 1515 Mar 9 11:37 uuchar.ppu
==== However, we have missed these files, back in SRC ========
testFPC/FPC/SRC/fpc-3.3.1/fpc/rtl/embedded/arm/ contains 48 files
-rw-r--r-- 1 dbannon dbannon 3566 Nov 24 14:46 allwinner_a20.pp
-rw-r--r-- 1 dbannon dbannon 33207 Nov 24 14:46 at91sam7x256.pp
-rw-r--r-- 1 dbannon dbannon 2105 Nov 24 14:46 cortexm0.pp
....
-rw-r--r-- 1 dbannon dbannon 4531 Nov 24 14:46 raspi2.pp
-rw-r--r-- 1 dbannon dbannon 21574 Nov 24 14:46 rp2040.pp
....
-rw-r--r-- 1 dbannon dbannon 89634 Nov 24 14:46 stm32f756.pp
-rw-r--r-- 1 dbannon dbannon 26138 Nov 24 14:46 xmc4500.pp
WRT suggestions it should work like fpcupdeluxe, I still don't know
what fpcupdeluxe does here, new error when compiling Lazarus and I
don't see how I can just install a Pico FPC. Dare I mention, again,
this is expected sometimes when you use main ?
Code: [Select](3104) Compiling lazutf8.pas
(3104) Compiling lazutilsstrconsts.pas
(3104) Compiling uitypes.pas
/home/dbannon/fpcupdeluxe/lazarus/components/lazutils/uitypes.pas(105,
14) Error: (3285) Expected another 2 array elements
/home/dbannon/fpcupdeluxe/lazarus/components/lazutils/uitypes.pas(93,5
8) Fatal: (10026) There were 1 errors compiling module, stopping
Fatal: (1018) Compilation aborted
Error: /home/dbannon/fpcupdeluxe/fpc/bin/x86_64-linux/ppcx64 returned
an error exitcode
fpcupdeluxe: ERROR: Lazarus Native Installer (BuildModuleCustom:
Lazbuild): make returned exit status #512.
That leaves me with an incomplete fpc cross compiler, presumably
because it does Lazarus before the cross compiler.
Davo
----------------------------------------------------------------------
TRon · 2024-03-09 05:50
Quote from: dbannon on March 09, 2024, 03:44:02 amOK, I have
established, in this situation, that fpc, with an unmodified fpc.cfg,
does not look in the dir Michael suggested -
And it never will unless either a) the compiler is configured
correctly (as should be done) or b) provide the correct unit path to
the compiler on the command-line
QuoteOf course, that approach would still involve changes to the
Makefile, its the one who creates the original abbreviated subdir as
demonstrated here (its obviously not a full list) -
Asked and answered by MiR. It does not require changes to the makefile
QuoteWRT suggestions it should work like fpcupdeluxe, I still don't
know what fpcupdeluxe does here, new error when compiling Lazarus and
I don't see how I can just install a Pico FPC. Dare I mention, again,
this is expected sometimes when you use main ?
I not had the time to try recompile trunk/trunk again so yes you might
have ran into a similar situation. Trunk is a moving target the last
few weeks and I can only guess it will be unstable for a while.
----------------------------------------------------------------------
DonAlfredo · 2024-03-09 07:01
As stated before, you can use the single step method to have a look at
how fpcupdeluxe does its "magic".
Install (only) FPC trunk/main.Install arm-embedded cross-compiler.No
changes of Makefile are needed.
Have a look at (last part of) fpc.cfg to see how macros are used to
point FPC to the correct unit paths.
----------------------------------------------------------------------
dbannon · 2024-03-09 08:40
Quote from: DonAlfredo on March 09, 2024, 08:01:48 amInstall (only)
FPC trunk/main.Install arm-embedded cross-compiler.
Ahh, I did not read your previous post properly. I was just clicking
"embedded" and the "Install Just FPC". A very different result when I
do as you really suggest.
Yes, this process relies on redirecting from within fpc.cfg. I know it
works, I do that myself from time to time. But I would prefer a demo
to have a clean fpc.cfg.
I think I will leave the wiki page model as it is but add notes
indicating its a simple and less capable model then the system used in
fpcupdeluxe. After all, I still recommend users, especially new user,
use fpcupdeluxe. But I, personally, already have quite a few installs
of FPC, now I know to use one of them for Pico, and use my regular
Lazarus as well, for me, thats good.
Thanks for your help DonAlfredo and Michael.
Davo
----------------------------------------------------------------------
MiR · 2024-03-09 11:17
Perhaps you can have another look, I found one of my older scripts,
here are the steps I did at that time:
Code: Bash [Select][+][-]window.onload = function(){var x1 =
document.getElementById("main_content_section"); if (x1) { var x =
document.getElementsByClassName("geshi");for (var i = 0; i DELUXEDIR=$
HOME/fpcupdeluxeBINDIR=${DELUXEDIR}/fpc/bin/x86_64-darwin cd
~/devel/fpcUNITDIR=${DELUXEDIR}/fpc/units/arm-freertos/armv6m/rtlmake
-j clean CROSSINSTALL=1 OS_TARGET=freertos CPU_TARGET=arm
SUBARCH=armv6m CROSSOPT="-XParm-embedded-"
FPC=$DELUXEDIR/fpc/bin/x86_64-darwin/fpc.shmake -j clean buildbase
installbase CROSSINSTALL=1 OS_TARGET=freertos CPU_TARGET=arm
SUBARCH=armv6m CROSSOPT="-XParm-embedded- -CfSOFT"
FPC=$DELUXEDIR/fpc/bin/x86_64-darwin/fpc.sh
INSTALL_PREFIX=${DELUXEDIR}/fpc INSTALL_BINDIR=${BINDIR}
CROSSBINDIR=${BINDIR} INSTALL_UNITDIR=${UNITDIR}
You just need to change the target, then things should work as
expected..
Last step would be to adjust fpc.cfg....
----------------------------------------------------------------------
dbannon · 2024-03-09 11:28
Change the target or do you mean INSTALL_UNITDIR ?
DonAlfredo mentioned something about the UNITDIR but I did not
understand what he meant. Your script sets it, looks like that is
intended for just this purpose ? I did not know of any such parameter
to be honest.
Anyway, getting a bit late here tonight, maybe tomorrow (although I do
have some other pressing issues, maybe not too).
Davo
----------------------------------------------------------------------
MiR · 2024-03-09 11:30
Replace the text (arm-)freertos with (arm-)embedded in all places,
----------------------------------------------------------------------
TRon · 2024-03-10 06:00
I am going to be a bit side-topic here. Feel free to burn me in case
that is a problem.
Quote from: DonAlfredo on March 08, 2024, 11:27:24 amThe pico-button
of fpcupdeluxe should take care of all of these implementation
details. I hope it still does.
Unfortunately it doesn't.
Seeing that you also have an open issue on your github about it, I'll
spill some details and my comments:
First of all, the single pico button press fails and as described on
the github report here by pizzaprogram.
The reason for that is obvious but, the comment inside the source-code
of fpcupdeluxe seems to contradict the obviousness
Quote// Due to changes in Lazarus, we need a trunk/main version of
Lazarus that can be compiled with an embedded (old) FPC trunk
Form2.ForceLazarusRevision:='5b0ed449f3'
The logic of the comment is imho wrong (perhaps not when it was
written (I haven't verified) or the comment applies to other parts of
the pico build) because when looking at the source-code of uitypes.pas
inside that Lazarus revision ...
Code: Pascal [Select][+][-]window.onload = function(){var x1 =
document.getElementById("main_content_section"); if (x1) { var x =
document.getElementsByClassName("geshi");for (var i = 0; i {$IF
FPC_FULLVERSION >= 30200}deprecated 'Use System.UITypes instead
(available since FPC 3.2.0)';
.. then it is clear that that the system.uitypes units is used since
compiler version 3.2.0. FPC Trunk is beyond that version.
Then, taken into account that afaik the forced Lazarus revision is
over a year old things go haywire because System.UITypes got a bit of
an update in the period between the forced Lazarus revision and
current FPC trunk which leads to the error where the forced Lazarus
revision uitypes.pas defines (too) less entries for variable
ModalResultStr than required by System.UITypes (this ModalResultStr
array maps between the two different units and FPC's system.uitypes
has 14 entries (mrLast) while lazarus forced revision has 12 (mrLast))
Of course that can be fixed easily, either manually or otherwise but
that does not 'fix' the imho wrong logic expressed in the comment.
Because imho it should read more like something as:
"Due to use of FPC trunk there is need to find/use a particular
minimal revision of Lazarus with a uitypes unit that matches the
definitions of (FPC trunk) System.UITypes (or a revision that does not
rely on components/lazutils/uitypes.pas anymore or has been
fixed/updated to match system.uitypes unit of trunk FPC)"
Now, which exact Lazarus revision that is, I haven't been able to
figure out yet (time constraint)...
Hopefully that is enough information to be able to address the issue ?
edit: At least in/with this commit the uitypes unit from Lazarus was
removed.
----------------------------------------------------------------------
DonAlfredo · 2024-03-10 09:14
QuoteThe logic of the comment is imho wrongYou are right. This is a
bugger of fpcupdeluxe. A left-over I guess.
https://github.com/LongDirtyAnimAlf/fpcupdeluxe/commit/ab0d6462e83c919
9c55c9785e9864786b38d4e59
----------------------------------------------------------------------
TRon · 2024-03-10 09:27
Quote from: DonAlfredo on March 10, 2024, 10:14:35 amhttps://github.co
m/LongDirtyAnimAlf/fpcupdeluxe/commit/ab0d6462e83c9199c55c9785e9864786
b38d4e59
Thank you for your attention and (very) quick fix DonAlfredo.
fwiw:
I've downloaded FPCUpDeluxe sources from trunk (simple zip-file and
extracted it), loaded the FPCUpDeluxe project file into Lazarus 3.0,
build the project and used the produced FPCUpDeluxe executable. After
starting the executable and selecting verbose output in the setup+
options (a personal preference), I then pressed the pico button which
worked flawlessly for me (Linux x86_64 gtk and at the time of writing,
see also below).
In case interested to know how things can be replicated then do not
forget to save the FPCUpDeluxe log that it produced during the pico
build.
Code: [Select]New install.
Date: 11-3-24 00:27:07
Location: /media/ramdisk/install
FPC update at: 11-3-24 00:27:07
FPC symbolic name: 3.3.1-15395-g57a1b5a39b
FPC URL: https://gitlab.com/freepascal.org/fpc/source.git/
FPC previous rev/hash: FRET_UNKNOWN_REVISION
FPC new GIT hash: 57a1b5a39b
Lazarus update at: 11-3-24 00:31:04
Lazarus symbolic name: main_3_99-1849-g4967237fb1
Lazarus URL: https://gitlab.com/freepascal.org/lazarus/lazarus.git/
Lazarus previous rev/hash: FRET_UNKNOWN_REVISION
Lazarus new GIT hash: 4967237fb1
Depending on your host platform your mileage may vary.
The only flaw I've managed to notice so far is a stray system.ppu of
zero bytes (armv6m unit directory) and without further investigating
have no idea if that is because a flaw in FPCUpDeluxe pico build or
due to issues regarding the original (FPC) makefiles.
----------------------------------------------------------------------
TRon · 2024-03-14 06:20
fwiw: Another combination that seems to work for me (linux-x86_64) is
Free Pascal trunk with hash 277a3be9b06258b5b439b4ad363d98786985e8d1
and Lazarus 3.2 (I have not tried fixes yet). With a big thank you
to/for user parcel.
----------------------------------------------------------------------
DonAlfredo · 2024-03-14 06:38
Good feedback.
QuoteThe only flaw I've managed to notice so far is a stray system.ppu
of zero bytes This is needed to circumvent a Lazarus error. Lazarus
does not handle the (more or less complicated) use of FPC macros to
set the path towards the correct unit directory for each subarch and
abi.
----------------------------------------------------------------------
TRon · 2024-03-16 08:39
Quote from: DonAlfredo on March 14, 2024, 07:38:41 amThis is needed to
circumvent a Lazarus error. Lazarus does not handle the (more or less
complicated) use of FPC macros to set the path towards the correct
unit directory for each subarch and abi.
Ah, ic. That makes sense
Apparently, I seem unable to get rid of the annoying dialog (see
attachment) at all (for every time you start-up the IDE and for every
time you open a project, which get annoying pretty fast ).
Seems that by default Lazarus (3.2) thinks !? it is targeting armv4 or
something, and I simply refuse to create all kinds of empty system.ppu
files for all supported sub-targets (because: user configurable).
On the better news front, also Lazarus fixes does seem to work with
that FPC revision but, unfortunately, similar as with 3.2 not the
bigide though (chart components do not play nice, see 40780).
----------------------------------------------------------------------
MiR · 2024-03-17 14:22
Just quick update, today I submitted a patch to fpc because I saw
that (at least for me) on main compiler rp2040.ppu was not built.
The patch got accepted and during my verification afterwards I ran
into an issue and wanted to present the solution in case somebody else
hits the same problem:
Lazarus main is having another bad day today and does not compile with
fpc main. So I wanted to re-use my existing fpcupdeluxe based Lazarus
install and only wanted to update fpc in this install.
This works fine but you must delete both fpc and fpcsrc directory in
your fpcupdeluxe directory for this to work properly.
Otherwise you are either still on my old repo (when you used the Pico
button on an older version of fpcupdeluxe) or get some funky errors
when compiling the cross compiler.
Then build fpc trunk compiler and switch to cross and build the armv6m
compiler. Have fun afterwards...
Michael
----------------------------------------------------------------------
TRon · 2024-03-18 01:45
Quote from: MiR on March 17, 2024, 03:22:12 pmJust quick update,
today I submitted a patch to fpc because I saw that (at least for me)
on main compiler rp2040.ppu was not built.
Thank you for pushing the fix. I had it solved manually. in my script
before.
QuoteLazarus main is having another bad day today and does not compile
with fpc main. So I wanted to re-use my existing fpcupdeluxe based
Lazarus install and only wanted to update fpc in this install.
A word of warning and a long story short but do not update your FPC if
you have a working setup. The moment you need to rebuild your IDE you
literally deadlocked yourself. Unfortunately, the issue is with FPC
compiler , not Lazarus (FPC is failing to build Lazarus after a
certain date (*)).
I would suggest to create some patches that include your latest
commits, apply those just before building the (cross)compiler and
stick to a known working combination. I personally prefer to stick to
3.2 stable/fixes though that also requires a patch for Lazarus if you
want to build the big IDE.
It is very unfortunate you got caught in the middle of this MiR as it
has been a long time ago since I've seen that happen.
(*) edit: and just after I posted trunk/trunk seem to build OK for me
again (Lazarus: 1dad391a)
----------------------------------------------------------------------
MiR · 2024-03-18 12:14
For me it's most of the time fun to do a little detective work when
things do not build, part of why I (again) spend time with Pico.
Nothing compares to a nice round of plain gdb to debug some strange
startup issues....
So all good here....
Michael
----------------------------------------------------------------------
MiR · 2024-08-21 11:24
my order for Pico 2 will arrive tomorrow or wednesday, anybody else
already received the new toy?
----------------------------------------------------------------------
VisualLab · 2024-08-22 12:21
Quote from: MiR on August 21, 2024, 01:24:11 pmmy order for Pico 2
will arrive tomorrow or wednesday, anybody else already received the
new toy?
I'm staying with the current one, i.e. RP2040-Plus-M (clone). I don't
need to use more fancy peripherals. Moreover, for the software of this
microcontroller, the RPi foundation still promotes home handicraft
("cottage industry") solutions with mandatory options to jump through
additional hoops (VSCode + CMake or Python). And this discourages the
use of their solution. From my point of view, support for STM
microcontrollers looks better.
----------------------------------------------------------------------
TRon · 2024-08-29 14:37
No idea where else to put it.
https://www.hackster.io/news/a-surprise-hardware-bug-in-raspberry-pi-
s-rp2350-leads-to-unexpected-pull-down-behavior-76b51ec22ede.amp
----------------------------------------------------------------------
MiR · 2024-08-29 14:42
That's a bad one...
----------------------------------------------------------------------
TRon · 2024-08-29 14:52
Unfortunately. yes.
I have not seen this big in the news (yet) so thought to provide a
heads up for those experimenting (and not knowing).
Hopefully it gets addressed in an updated revision but that might be a
though one.
----------------------------------------------------------------------
MarkMLl · 2024-08-29 15:07
So to summarise: the RP2350 (Pico2) has an electrical fault on the
GPIO pins which doesn't exist on the earlier RP2040 (Pico).
MarkMLl
----------------------------------------------------------------------
TRon · 2024-08-29 15:20
Quote from: MarkMLl on August 29, 2024, 05:07:53 pmSo to summarise:
the RP2350 (Pico2) has an electrical fault on the GPIO pins which
doesn't exist on the earlier RP2040 (Pico).
In short, yes. see also 2.50 minute video:
https://www.youtube.com/watch?v=sqJQNF9sna
I mentioned it here because it was the first discussion I could find
that mentioned people wanting to experiment with products containing
the RP2350.
----------------------------------------------------------------------
VisualLab · 2024-10-07 20:18
Quote from: TRon on August 29, 2024, 05:20:51 pmQuote from: MarkMLl on
August 29, 2024, 05:07:53 pmSo to summarise: the RP2350 (Pico2) has an
electrical fault on the GPIO pins which doesn't exist on the earlier
RP2040 (Pico).
In short, yes. see also 2.50 minute video:
https://www.youtube.com/watch?v=sqJQNF9sna
I mentioned it here because it was the first discussion I could find
that mentioned people wanting to experiment with products containing
the RP2350.
It's good that I didn't buy it
P.S. The specified video is no longer available on YouTube.
----------------------------------------------------------------------
MarkMLl · 2024-10-07 20:32
Quote from: VisualLab on October 07, 2024, 10:18:27 pmP.S. The
specified video is no longer available on YouTube.
Well, I guess that's a cautionary tale: if linking to YouTube at least
annotate it with the name of the originator :-/
Way /way/ back, it was considered bad form to use a machine-generated
URL which wasn't even minimally descriptive of the content. Then along
came Notes/Domino, "Enterprise Grade" stuff from Netscape, and the
floodgates were opened...
MarkMLl
----------------------------------------------------------------------
TRon · 2024-10-07 20:46
Quote from: VisualLab on October 07, 2024, 10:18:27 pmP.S. The
specified video is no longer available on YouTube.
There you go.
channel: https://www.youtube.com/@DrJonEA
title: RP2350 Bug in GPIO Input Pull-Down Resistor Circuitry |
DrJonea.co.uk
But imho the article has more value.