Forum > Embedded

fpcupdeluxe and the Pico

<< < (2/12) > >>

TRon:

--- Quote from: dbannon on March 05, 2024, 11:10:37 am ---First, TRon, where did you get the info about SUBARCH and  crosszipinstall from ?

--- End quote ---
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):

--- Quote ---ifeq ($(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

--- End quote ---
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

--- End quote ---
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

--- End quote ---
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)


--- Quote ---I thanks you !

--- End quote ---
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  8-)

MiR:
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:

      <CustomOptions Value="
-Wpraspi_pico
-godwarfsets
-godwarfcpp
-Xu"/>

You can configure Targets from inside Lazarus in a GUI way and re-use what you have done with lazbuild:

lazbuild --build-all <lpifile> builds your code for all the default target

lazbuild --build-all --build-mode="Adafruit Feather RP2040" <lpifile> builds for the specific Adafruit Feather RP2040 board.

dbannon:
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)

--- End quote ---
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 ...


--- Quote ---Personally 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 ?

--- End quote ---
-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:

--- Quote from: dbannon on March 06, 2024, 01:19:34 am ---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.

--- End quote ---
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: ---$ ./ppcrossarm -h
Free Pascal Compiler version 3.3.1-15371-g0fb4fca957-dirty [2024/03/05] for arm


--- End code ---


--- Quote ---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 !

--- End quote ---
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*


--- Quote ---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 ...

--- End quote ---
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.

--- End quote ---
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  :)


--- Quote ---In cpuinfo.pas, both 'RP2040'  and 'RASPI_PICO'  are listed ...

--- End quote ---
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.


--- Quote ---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 ??

--- End quote ---
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<x>     Specify the controller type; see fpc -i or fpc -iu for possible values
      -WP<x>     Minimum iOS deployment version: 3.0, 5.0.1, ... (Darwin)

--- End quote ---
I spare you (and other readers) the ridiculous amount of output produced by ./ppccrossarm -i and -iu

dbannon:

--- Quote from: TRon on March 06, 2024, 02:31:57 am ---trunk has been able to build for pico since the patches from MiR were accepted ...

--- End quote ---
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

--- End quote ---

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: ---$ ./ppcrossarm -h
Free Pascal Compiler version 3.3.1-15371-g0fb4fca957-dirty [2024/03/05] for arm

--- End code ---

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  [+][-]window.onload = function(){var x1 = document.getElementById("main_content_section"); if (x1) { var x = document.getElementsByClassName("geshi");for (var i = 0; i < x.length; i++) { x[i].style.maxHeight='none'; x[i].style.height = Math.min(x[i].clientHeight+15,306)+'px'; x[i].style.resize = "vertical";}};} ---ppcrossarm -iu for example lists all the pico (etc) boards,
--- Code: Pascal  [+][-]window.onload = function(){var x1 = document.getElementById("main_content_section"); if (x1) { var x = document.getElementsByClassName("geshi");for (var i = 0; i < x.length; i++) { x[i].style.maxHeight='none'; x[i].style.height = Math.min(x[i].clientHeight+15,306)+'px'; x[i].style.resize = "vertical";}};} ---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

Navigation

[0] Message Index

[#] Next page

[*] Previous page

Go to full version