fpcupdeluxe and the Pico

[dbannon]

• Install (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]

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][+][-]

1. DELUXEDIR=$HOME/fpcupdeluxe
2. BINDIR=${DELUXEDIR}/fpc/bin/x86_64-darwin
3.  
4. cd ~/devel/fpc
5. UNITDIR=${DELUXEDIR}/fpc/units/arm-freertos/armv6m/rtl
6. make -j clean CROSSINSTALL=1 OS_TARGET=freertos CPU_TARGET=arm SUBARCH=armv6m CROSSOPT="-XParm-embedded-" FPC=$DELUXEDIR/fpc/bin/x86_64-darwin/fpc.sh
7. make -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}
8.  

You just need to change the target, then things should work as expected..

Last step would be to adjust fpc.cfg....

[dbannon]

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]

Replace the text (arm-)freertos with (arm-)embedded in all places,

[TRon]

I am going to be a bit side-topic here. Feel free to burn me in case that is a problem.

The 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 

// 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][+][-]

1. {$IF FPC_FULLVERSION >= 30200}
2. deprecated 'Use System.UITypes instead (available since FPC 3.2.0)';
3.  

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

The logic of the comment is imho wrong

You are right. This is a bugger of fpcupdeluxe. A left-over I guess.
https://github.com/LongDirtyAnimAlf/fpcupdeluxe/commit/ab0d6462e83c9199c55c9785e9864786b38d4e59

[TRon]

https://github.com/LongDirtyAnimAlf/fpcupdeluxe/commit/ab0d6462e83c9199c55c9785e9864786b38d4e59

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]

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]

Good feedback.

The 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]

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.

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]

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]

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.

Thank you for pushing the fix. I had it solved manually. in my script before.

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.

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]

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]

my order for Pico 2 will arrive tomorrow or wednesday, anybody else already received the new toy?

[VisualLab]

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