Raspberry Pi Pico and Freepascal

[MiR]

Raspberry Organization announced the Raspberry Pi Pico:

https://www.raspberrypi.org/blog/raspberry-pi-silicon-pico-now-on-sale/

https://www.raspberrypi.org/products/raspberry-pi-pico/specifications/

which looks like a quite interesting (and cheap) microcontroller board with dual-core Cortex-M0.

The chip will also show up in Boards from Adafruit, Sparkfun and Arduino so I guess it will get quite popular.

I would like to spend some time in making this board available in Freepascal, anybody interested in joining the effort?

My boards should arrive in a week or so, I already created a version of FreePascal that automagically creates uf2 files for easy uploading of firmware to the board, now there is 'only' the task of creating a good unit for the board.

If you would like to help out please order at least two boards as you can use one board as a debug probe with software provided by Raspberry Foundation.

Michael

[MarkMLl]

You beat me to it :-)

Review at https://hackaday.com/2021/01/20/raspberry-pi-enters-microcontroller-game-with-4-pico/

The really interesting question is whether some cut-down version of FPC's threads could be implemented.

MarkMLl

[MiR]

I think Christo Crause has done some threads groundwork for freepascal on the esp32-freertos platform, theoretically freertos should run just fine on the board so what he did should also apply to the Pico.

[ccrause]

I think Christo Crause has done some threads groundwork for freepascal on the esp32-freertos platform, theoretically freertos should run just fine on the board so what he did should also apply to the Pico.

It is a proof of concept with some ESP specific bits, but that can be fixed.  An alternative could be to use the pthreads library add-on which should be (more or less) compatible with FPC's cthreads wrapper unit.

[MiR]

I implemented initial support for Raspi pico boards here:

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

Supported boards are:

RASPI_PICO
FEATHER_RP2040
ITZYBITZY_RP2040

I have not yet received Hardware so expect issues.....

StartupCode will likely need additional fixing to send the 2nd cpu to sleep on startup and names of IRQ Handlers are a mess and will likely have to change, RPI decided to give them non-CMSIS conformant naming (in fact there is no real naming) so I got creative myself here....

The repo also includes support for tons of STM32 chips and support for creating UF2 bootloader images.

[MiR]

My pico's arrived....

As weather is bad over the weekend I will play with them and will see that I create a pico related page on the Lazarus Wiki......

[MarkMLl]

There is a bare metal version of FreePascal for the Raspi: Ultibo.

Are you saying that the FPC compiler will run hosted by Ultibo? Are you also saying that FPC already been ported to the Pico?

MarkMLl

[MiR]

I guess there is a misunderstanding on Germo's side what the Raspberry Pi Pico is

it is a Cortex-M0 Dualcore and has nothing to do with the original Raspberry Pi, as far as I know Ultibo covers the native Programming on the Raspberry Pi (but honestly I did not check if they also work on a port to the Pico)

fpc will soon be ported to be able to support the raspberry pi pico, this is work in progress and cal be followed in my freepascal repo (which I will upgrade later today to cover the changes I did since I received the hardware)

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

I have also already written some chapters on the Freepascal Wiki, you can already follow the first steps there but I will take the weekend to finish up the initial writeup, currently there are still some todo's in the documentation as I first do all on my Mac and then 'backport' the documentation bits to Windows.

Landing page on the Wiki is here:

https://wiki.freepascal.org/ARM_Embedded_Tutorial_-_FPC_and_the_Raspberry_Pi_Pico



Michael

[PascalDragon]

Perhaps these sources could help develop a Pi Pico version of FreePascal

As MiR said, the Raspberry Pi and the Raspberry Pi Pico are two entirely different things. The Pico is essentially a Microcontroller like an Arduino or ESP32 while the normal Pi is a hardware suitable for a normal OS (be it Linux, Windows or Ultibo).

[MarkMLl]

No. I tried to say that there is a version of FreePascal (Named Ultibo) that creates Bare Metal code for a Raspberry Pi.
Perhaps these sources could help develop a Pi Pico version of FreePascal

Ultibo is an operating system, not a compiler. Do you know the difference?

MarkMLl

[MarkMLl]

Ultibo is the version of FreePascal that create 'Bare Metal' code. Do you know what that is?

Rubbish. Ultibo is a minimal OS that runs on a bare-metal RPi, and typically integrates user-defined functionality (i.e. the sort of thing that on a larger-scale OS would be loaded from some sort of file). It is built using standard FPC with some very minor additions to support that specific target, it is still fundamentally the same FPC and the Ultibo and core FPC developers work together... it is NOT a fork of the FPC project and the changes are minimal. Similarly, the Lazarus IDE has minor tweaks to support Ultibo as a target.

The Pico is a completely different chip from what's been used in the conventional RPis, as multiple people are trying to tell you. Neither the Ultibo project nor its supporting tools are substantial help.

And I'd add that I've been doing bare-metal stuff for around 30 years.

MarkMLl

[lucamar]

No. I tried to say that there is a version of FreePascal (Named Ultibo) that creates Bare Metal code for a Raspberry Pi.
Perhaps these sources could help develop a Pi Pico version of FreePascal

Ultibo is an operating system, not a compiler. Do you know the difference?
MarkMLl

To quote the ultibo site ( http://www.ultibo.org ): [... snip ...]

A, perhaps, better quote would be this, from their FAQ:

What is Ultibo?
Ultibo core is an embedded or bare metal development environment for Raspberry Pi. It is not an operating system but provides many of the same services as an OS, things like memory management, networking, filesystems and threading plus much more. So you don’t have to start from scratch just to create your ideas.

So it's "kind of but not quite" an OS providing a minimum environment for application level development.  Kind of like MS-DOS on steroids for RPi

[MarkMLl]

So it's "kind of but not quite" an OS providing a minimum environment for application level development.  Kind of like MS-DOS on steroids for RPi

Well of course, "what is an OS" has been a subject of debate ever since MS released their "DOS" which became the immediate butt of jokes from the UNIX crowd.

Is something still an OS if all its application code is preloaded into the same binary image? I think that some of the early Windows versions did that, and more to the point there's a whole lot of embedded OSes from people like Wind River (or were they bought up? I forget) which similarly came as binary modules to which application code was linked.

For that matter, is a hypervisor an OS? After all, in cases like IBM's CP it very often came prebuilt with a small number of CMS VMs and the fact that they could load programs is not directly relevant.

Does an OS have to be preemptive? Is being preemptive a sufficient condition (clearly not, since most embedded hardware uses interrupts).

Does an OS have to have memory protection? No, because- as particular examples- early IBM mainframes didn't have memory protection, and there have been cut-down unix clones which ran without an MMU (e.g. CTOS/BTOS plus things like Coherent).

Is "Arduino" an OS? The water is obviously muddied there because "Arduino" describes lots of different things: the development framework (which includes GCC), the libraries and APIs, the hardware definitions, and a number of actual physical "deliverables".

The important point though is that Ultibo itself is not a compiler, and is of limited direct help when considering porting a compiler to a new target.

MarkMLl

[lucamar]

The important point though is that Ultibo itself is not a compiler, and is of limited direct help when considering porting a compiler to a new target.

One (maybe the only?) thing which might relate to that is their adaptation of the RTL. Other than that ... I can think of nothing; maybe they built Ultibo with FPC in mind, so it's better adapted to FP programming than other OS(-alikes) but whether that is germaine to the point ... I don't really know. I don't know that much about it.

[MarkMLl]

The important point though is that Ultibo itself is not a compiler, and is of limited direct help when considering porting a compiler to a new target.

One (maybe the only?) thing which might relate to that is their adaptation of the RTL. Other than that ... I can think of nothing; maybe they built Ultibo with FPC in mind, so it's better adapted to FP programming than other OS(-alikes) but whether that is germaine to the point ... I don't really know. I don't know that much about it.

I've never investigated the extent to which Pascal (including FPC's dialect) is adequate for an OS. My suspicion is that the coroutine functionality provided by e.g. Modula-2 helps a lot, and I have in fact used Modula-2 for an x86 protected-mode OS with /no/ assembly-code glue (it did, however, use custom tools to bind the binary to a descriptor table definition hence exploit various hardware-provided gates).

MarkMLl