Raspberry Pi Pico and Freepascal

[MiR]

Today I have adjusted code to a major internal change in the pico-sdk, to better support flash chips in different sizes and from different manufacturers the foundation has created board specific 2nd stage bootloaders.

I have implemented this also in my repo, but there are also changes needed in the fpc compiler itself to support this.

So, please make sure that you upgrade to both latest/greatest versions of both of my repositories:

https://github.com/michael-ring/freepascal

and

https://github.com/michael-ring/pico-fpcexamples

Users of fpcupdeluxe should select 'embedded' as FPC-Version in Basic Tab and then Install/update FPC only or both FPC+Laz.

Then switch to Cross Tab, select 'arm' and 'embedded' and then select subarch armv6m and then 'Install Compiler'

Please currently do not us 'update all' as there may be an issue with that function, please see:

https://github.com/LongDirtyAnimAlf/fpcupdeluxe/issues/374

Update:

for now, please use

https://github.com/LongDirtyAnimAlf/fpcupdeluxe/releases/tag/1.8.2m

version, this fixes the issue that after rebuild the system unit cannot be found.

Update: latest fpcupdeluxe 1.8.2r fixes the issues

Have fun,

Michael

[dbannon]

Hi Michael, time I said thanks for this, especially the well written docs on the wiki.  Great job !

Documenting stuff is boring but essential for our open source ideals !

Davo

[MiR]

Thank you!

Just a quick update, I did a workaround to fix a crash when sysutils are used, please both update fpc and my repo if you need to use sysutils

(See issue #38864)

Michael

[MarkMLl]

I've just been reading through this thread, since I've noticed somebody I'm likely to buy some oddments from selling a Pico on a development breakout board for about £16.

Any idea what the poster @turronet means here:

As a noob I ordered 1 pico only, so I'll buy the debugger soon.

Is he referring entirely to something like https://wiki.freepascal.org/ARM_Embedded_Tutorial_-_Raspberry_Pi_Pico_Debugging_the_onboard_LED where a second Pico is used as a remote debugging bridge for gdb?

MarkMLl

[MiR]

Yes, he is referring to the article.

[VisualLab]

I purchased an RPi Pico clone (RP2040-Plus) a week ago. And I've been browsing the Raspberry Pi Pico SDK for a few days now. In the header file address_mapped.h in the directory (relative path): ... \pico-sdk-master\src \rp2_common\hardware_base\include\hardware, I came across a line of code:

Code: C  [Select][+][-]

1. *(io_rw_32 *) hw_set_alias_untyped((volatile void *) addr) = mask;

The file address_mapped.h is available at: https://raspberrypi.github.io/pico-sdk-doxygen/address__mapped_8h_source.html. The quoted line comes from the function: hw_set_bits. Its code is:

Code: C  [Select][+][-]

1. __force_inline static void hw_set_bits(io_rw_32 *addr, uint32_t mask) {
2.     *(io_rw_32 *) hw_set_alias_untyped((volatile void *) addr) = mask;
3. }

This line has a macro named "hw_set_alias_untyped" (located in the same file). The question is: to "what" is assigned the value of "mask" argument?

On the left side there is a macro "hw_set_alias_untyped" which will be replaced with: "((uintptr_t) (addr))". After its substitution and expansion, the following expression will appear (unless I made a mistake):

Code: C  [Select][+][-]

1. *(io_rw_32 *) ((uintptr_t)(volatile void *) addr) = mask;

The argument "addr" is the address of register RP2040, mapped to memory. This address ("addr") is cast to the amorphous pointer ("volatile void *") and then to the pointer "uintptr_t" (again: unless I made a mistake). To make the analysis easier, I simplified it to:

Code: C  [Select][+][-]

1. macro_result = ((uintptr_t)(volatile void *) addr) // simplification that I mean
2. *(io_rw_32 *) macro_result = mask; // the resulting expression after simplification

Is the macro output some "anonymous variable" (no name)? Is the left part of the expression a dereference of a pointer of type "io_rw_32" whose content is computed from this expression? Does this mean that the contents of the "mask" argument are assigned to "that something" that arises after dereference?

[avra]

I have just received YD-RP2040 16MB USB-C compatible with single WS2812 and USR key, and it worked great in every test I made so far 

[VisualLab]

I can see that the YD-RP2040 board differs from the original RPi Pico and the clone I bought (Waveshare RP2040-Plus) with the ADC3 signal on pin 35. In the original and the clone:

- pin 35 is used to connect the reference voltage for the ADC,
- ADC3 signal is permanently connected to the temperature sensor.

In the YD-RP2040 board, the pin for connecting the reference voltage for the ADC is leaded out separately. It seems to me that the YD-RP2040 board is better designed than the original (ie RPi Pico) and the Waveshare clone. I do not see any advantages of the solution introduced by the RPi foundation regarding the ADC3 signal. It struck me as a quirk from the beginning.

Anyway, the actions of the RPi foundation are a mixture of good ideas about hardware solutions (e.g. RPi 1-4, RP2040 microcontroller) with stupid software ideas (OS for RPi based on Debian /root account locked in GUI/, choice of Visual Studio Code and CMake for RPi Pico, Python). Python is not suitable for electronics applications (basic of automation). Yes, Python is popular. But with it it is like with the Trabant car in DDR - a lot of people used it because it was cheap. It was mass-produced, because it had a primitive design, which made it easy and cheap to produce.

[MarkMLl]

In the YD-RP2040 board, the pin for connecting the reference voltage for the ADC is leaded out separately. It seems to me that the YD-RP2040 board is better designed than the original (ie RPi Pico) and the Waveshare clone. I do not see any advantages of the solution introduced by the RPi foundation regarding the ADC3 signal. It struck me as a quirk from the beginning.

It must be said that the SDK etc. is intended for the RP2040 rather than for the Pico. The real "gotcha" is that the crosspoint switching between peripherals and pins is subdivided, so UART0 can appear on only a small number of pins, UART1 on a different group and so on. That's not too bad, until you have something like the Cytron board that I've got which has put an ESP8266 on pins which can only be connected to UART0... meaning that any serial output that would normally be on UART0 has to be moved to either UART1 or USB. And whenever the firmware is reloaded is resets the USB, which means that the host computer might allocate it to a different named device.

Anyway, the actions of the RPi foundation are a mixture of good ideas about hardware solutions (e.g. RPi 1-4, RP2040 microcontroller) with stupid software ideas (OS for RPi based on Debian /root account locked in GUI/,

I presume that you're talking there about the "classic" RPi plus Raspbian or whatever they call it these days: you /are/ aware aren't you that you can set up other named accounts? I'm not sure that's any worse than the Ubuntu philosophy where the standard is (or at least was) to have a root account which can't be logged into directly.

choice of Visual Studio Code and CMake for RPi Pico, Python). Python is not suitable for electronics applications (basic of automation). Yes, Python is popular. But with it it is like with the Trabant car in DDR - a lot of people used it because it was cheap. It was mass-produced, because it had a primitive design, which made it easy and cheap to produce.

Cmake is pretty gruesome and I'm having a hard time with its documentation for even simple jobs, but I think that what's happened is that they used it for the SDK and assumed it would be welcomed for application firmware as well.

VSCode has a Trojan that I'm still characterising, don't use.

Python... I loathe the language, but the last few years have demonstrated that it's serviceable for tacking stuff together. If you have to criticise anybody, I suggest directing your ire at the people who think that a good way to design a user interface is to embed Javascript and a browser engine into a program.

MarkMLl

[avra]

I can see that the YD-RP2040 board differs from the original RPi Pico...

I like all the changes they made 

Anyway, the actions of the RPi foundation are a mixture of good ideas about hardware solutions (e.g. RPi 1-4, RP2040 microcontroller) with stupid software ideas (OS for RPi based on Debian /root account locked in GUI/, choice of Visual Studio Code and CMake for RPi Pico, Python). Python is not suitable for electronics applications (basic of automation).

- I like Debian and Manjaro, so I am fine with their default choice. Who doesn't has plenty of options. Changing whole distro, or just a desktop environment is not hard.
- I like VScode editor, debugging and extensions. Without VScode, I would be stuck with Arduino IDE or have to learn a new IDE for each target I need (and yes, I worked with Eclipse).
- Python is fine for many use cases, even in electronics (CircuitPython). It is now what BASIC used to be in 20th century. Yes, for some apliances there might be much better tools, but it is nice for quick prototyping and if that is the only language you know, you will not want to learn a new language unless you hit some serious wall. In today's world bying a bigger hammer is more often used then investing time and knowledge to optimize existing solution (unless we speak of real high volume production where every cent counts and where it is more then justified).

VSCode has a Trojan that I'm still characterising, don't use.

If you can live without some extensions, then maybe VScodium could be the solution:
https://mspoweruser.com/vscodium-is-a-clean-vscode-build-without-the-microsoft-customizations/

[MarkMLl]

The RPi's OS does undoubtedly have some significant issues.

* Too much needs root permission on account of GPIO etc. access.

* While kernel GPIO support is improving, the v2 API had major deficiencies when I last looked.

* The home-grown window manager fails to pass various settings to X11, giving some apps major problems.

* It's decidedly short of GUI support for creating new users and modifying access rights.

And so on...

I agree with your (@Avra) point about VSCode being a half-decent IDE, and in any event being vastly superior to Eclipse etc... it's a great pity that Lazarus doesn't have C/C++ support.

However, the only way I'm prepared to run it is either in a Docker container (which will probably break debugging access to the Picoprobe) or completely isolated from my main development system. I've seen some extremely worrying background behaviour, and I'd point out that it's installed with root access and that even on Debian all VSCode updates come directly from MS servers and run MS-supplied installation scripts with root permissions.

MarkMLl

[VisualLab]

It must be said that the SDK etc. is intended for the RP2040 rather than for the Pico. The real "gotcha" is that the crosspoint switching between peripherals and pins is subdivided, so UART0 can appear on only a small number of pins, UART1 on a different group and so on. That's not too bad, until you have something like the Cytron board that I've got which has put an ESP8266 on pins which can only be connected to UART0... meaning that any serial output that would normally be on UART0 has to be moved to either UART1 or USB.

That is why I rate the RP2040 positively from the hardware side.

I presume that you're talking there about the "classic" RPi plus Raspbian or whatever they call it these days: you /are/ aware aren't you that you can set up other named accounts? I'm not sure that's any worse than the Ubuntu philosophy where the standard is (or at least was) to have a root account which can't be logged into directly.

Of course it can be changed. But messing around with various Linux configuration files is a pain. In addition, some changes need to be made in the startup script files. The more that it looks different in different distributions (files and their location in individual directories).

VSCode has a Trojan that I'm still characterising, don't use.

I am not using VSCode. I generally hate pseudo-programs written with scripting languages (allergic to MS Teams). In particular, I hate monster applications written with JavaScript (including those based on Electron). It works poorly with OS. The performance is also not the best, not to mention ergonomics. In addition, some activities related to programming the microcontroller must be performed in VSCode by typing commands in the console. This is not a step back - it is a step back 30-40 years. It is all the more surprising that RPi Pico was intended by the creators to popularize programming and electronics, and in particular to encourage young people to learn them.

I got used to IDEs such as Delphi, Visual Studio (standard) or NetBeans quite quickly (NetBeans sometimes it is a bit slow, but you can work). They really make life easier. The Foundation could use NetBeans as an IDE, which is free. There are modules (plugins) for it that support C and C++ (I tested, they work).

Python... I loathe the language, but the last few years have demonstrated that it's serviceable for tacking stuff together. If you have to criticise anybody, I suggest directing your ire at the people who think that a good way to design a user interface is to embed Javascript and a browser engine into a program.

My (very critical) opinion about Python was shaped by its use. The first languages I started programming with were (chronologically): ObjectPascal, Pascal, C++, C, Java, PHP, JavaScript, C#, Python. This is probably why I think JavaScript and Python (PHP too) are crap. It is different with people who know one language, such as Python or JavaScript. When a person gets used to the comforts, then an attempt to use something primitive is painfully felt.

[VisualLab]

- I like Debian and Manjaro, so I am fine with their default choice. Who doesn't has plenty of options. Changing whole distro, or just a desktop environment is not hard.

I used Red Hat for many years, then Fedora (and other derivatives) and CentOS. Then I tried to use Ubuntu, but it "gets on my nerves". I was interested in Linux only as an OS for a workstation/desktop (I'm not interested in servers). And here Linux is pretty poor. This, of course, is not due to the fact that Linux programmers cannot create a desktop version, they just don't want to create such a version. So, after more than 20 years of trying to use Linux on a desk, I don't expect it to come. The architecture and design assumptions (changing every now and then like in a kaleidoscope) mean that there will not be a comfortable desktop version of Linux that could boldly compete with Windows.

- I like VScode editor, debugging and extensions. Without VScode, I would be stuck with Arduino IDE or have to learn a new IDE for each target I need (and yes, I worked with Eclipse).

For those who start learning with the Arduino IDE (and the Arduino board), they are sufficient. Of course, a real IDE would be better, but it costs money (eg. VisualMicro). Or you have to assemble something yourself from existing applications (and libraries). And a beginner, unfortunately, is unlikely to be able to do it.

- Python is fine for many use cases, even in electronics (CircuitPython). It is now what BASIC used to be in 20th century.

I completely agree with the trim comparison (it is quite popular on the Internet anyway). But that is criticism rather than praise. A totally deserved criticism.

[avra]

I've seen some extremely worrying background behaviour, and I'd point out that it's installed with root access and that even on Debian all VSCode updates come directly from MS servers and run MS-supplied installation scripts with root permissions.

Portable version of VScode that does not update on it self can be used on Windows, and to avoid MS telemetry and scripts VScodium might be a solution. According to https://duckduckgo.com/?q=docker+usb+access&ia=web it seams that some kind of host USB access can be given to a container.

[MarkMLl]

I've seen some extremely worrying background behaviour, and I'd point out that it's installed with root access and that even on Debian all VSCode updates come directly from MS servers and run MS-supplied installation scripts with root permissions.

Portable version of VScode that does not update on it self can be used on Windows, and to avoid MS telemetry and scripts VScodium might be a solution. According to https://duckduckgo.com/?q=docker+usb+access&ia=web it seams that some kind of host USB access can be given to a container.

This isn't an update issue. It's some sort of background scanner running, possibly talking to Github... I'd rather not say much more until I'm 100% sure of my facts.

I am wrong in one detail of what I've been saying: checking, it came from an MS-sourced .deb rather than Debian's repository, so I can't hold Debian responsible for it. But there's almost certainly something nasty in it, and containerising it wouldn't help as long as it still had network access (I'm pretty sure it would make things worse on at least Docker, since the Picoprobe is not a named device and nobody's found a way of mapping it).

MarkMLl