Circle bare metal environment for RPi

[bobby100]

https://github.com/rsta2/circle

What would be needed in order to run pascal code on top of the Circle environment?

[VisualLab]

A project competing with the Ultibo project. Only the project has many more participants.

[MarkMLl]

https://github.com/rsta2/circle

What would be needed in order to run pascal code on top of the Circle environment?

From a fairly brief read: you're not "running Pascal code on top of", you're "providing a main function which calls the underlying kernel". In other words the whole thing is linked together as a single file, you've not got a kernel compiled as one project with a separate demo program in some executable format being loaded from a storage device.

It's probably not viable, since (looking specifically at https://github.com/rsta2/circle/blob/master/include/circle/gpiopin2712.h) I think the API is defined as C++ objects which aren't supported by FPC.

MarkMLl

[bobby100]

@MarkMLI - thanks

@VisualLab - Ultibo lacks a lot of drivers. When I asked on Ultibo forum, I was told to write the drivers myself if I need one. Just like everyone can write a driver...

It seems, the easiest way for me in this situation is to learn C++, even if I have very bad emotions about C++.
It reminds me of VHS vs. Video 2000 vs. Betamax - the worst one got popular.

[Thaddy]

If you want to use bare metal, you are supposed to write your drivers and Ultibo comes with lots of examples.
What is that with you? Should we solve everything beforehand? Where's your contribution?
Nobody ever wrote that programming was easy.    - I am not going to "fix" ignorance.

Now playing: Free speech for the dumb (Metallica version, better than Discharge )

A little toned down: bare metal programming requires you:
- to know the metal as hardware
- to know the programming language on offer on a very low level detail

Anything else? Do not even try.

[MarkMLl]

A little toned down: bare metal programming requires you:
- to know the metal as hardware
- to know the programming language on offer on a very low level detail

Perhaps a little more constructively: if the project cited supports the hardware then you've already got drivers as an example. For most of the RPi you've also got adequate datasheets and/or reverse engineering.

Bare-metal programming isn't easy even with a fairly comprehensive underlying framework, because when it goes wrong- and it /will/ go wrong as soon as you get a pointer alignment out- the whole thing will crash without an underlying OS to at least give you a memory dump.

MarkMLl

[bobby100]

@Thaddy and MarkMLI
Love you guys and your sense for criticizing.

I have a paid job where I work 9 to 11 hours a day, programming PLCs, HMIs, writing loggers (Lazarus/FPC) for specific purposes etc. I am now writing monitoring software for a photovoltaic plant (Lazarus/FPC, of course)

I have some free time in the evening (kids are already grown up, visiting common rooms like the kitchen or living room just if they must) and if I am going to spend these 2 hours at the evening on writing drivers and frameworks, I'll never get to writing the actual app stuff I want to write. In the fact, I'll rather watch CSI at the evening if I get scared from a lot of work. Now, add to this that lainz left me in charge of BGRAControls because he's lacks of time (I am already scared)...

Back to the main point, take a look here:
https://github.com/probonopd/MiniDexed
I am a bit involved there by writing the PC-side support apps (Lazarus/FPC). I see a lot of points in the project (synth engine, MIDI implementation,adding  other synth engines etc.) that need to be done, so I have two possibilities at the moment:
- rewrite in Pascal (not so difficult if I do not need to care about underlying drivers etc.)
- learn C++, and work on the existing code
I simply have passion for synths (20 years of music career behind me) and I'll like to put all of my favorite synths on RaspberryPi. Forget Linux in this case - the bare metal MiniDexed starts in 10 seconds and you can play. No need for keyboard, mouse or big screen. Just like any other synth rack-module.

Back to your criticism - If I've learned something in my life (48 y. old), it would be - don't bite more than you can swallow. I can't take time to code all this from ground up. If I find a base to put my code on the top of it - good, I have time to do that and that was it. I am not lazy, I just do not have time or strength for more.

[MarkMLl]

Back to your criticism - If I've learned something in my life (48 y. old), it would be - don't bite more than you can swallow. I can't take time to code all this from ground up. If I find a base to put my code on the top of it - good, I have time to do that and that was it. I am not lazy, I just do not have time or strength for more.

I'd agree with that (youngster :-)

The first thing I'd say is that I'm not entirely happy with basing /anything/ ground-up on the RPi (specifically, the one that usually runs Linux, I'm not talking about the Pico etc.) because of its semi-open status: even with the amount of progress which the community has made over the years, one never really knows what's lurking in there ready to surprise.

I've looked at the Pico (but the emphasis on C++ and cmake is daunting, although there are other RP2040 boards including one that uses a separate ESP32 for networking). I've looked at the MilkV-Duo (to which I'll return when I have time), but the lack of hardware protection between the "Linux" and "Arduino-like" sections is a bit offputting. I've looked at some of the WCH RISC-V chips and been impressed (both by the chips and by the company when I contacted them about a device programmer problem)... also they came with the best-configured Eclipse variant I've ever seen.

But none of these have any sort of low-level monitor guaranteed to trap and handle exceptions sensibly.

What I'd really like to see is something possibly based on the RISC-V and definitely based on a straightforward toolchain, with enough balls to run Linux (plus of course FreeRTOS etc.) but sufficiently well-understood to be usable as bare metal, and with an on-die FPGA to either handle the sort of comms jobs at which the RP2040 excels or to be able to handle low-power supervisory jobs (like the 8051 on the MilkV Duo) including crash reporting.

MarkMLl