Ultibo – Bare-Metal Pascal for Raspberry Pi
ultibo.org
ultibo.org
That would be pretty sweet! I’m guessing with the ECU sensors you could feed in the data to a simulation of a different engine to get really authentic different engine noises.
Main link [1] -> Object Pascal Tutorial [2] -> "There is currently no text in this page. You can search for this page title in other pages, or search the related logs, but you do not have permission to create this page."
[1] https://ultibo.org/make/ [2] https://wiki.freepascal.org/Object_Pascal_Tutorial
But the serious docs are there: https://www.freepascal.org/docs.html (And I haven't forgotten Pascal since 1980s anyway...)
In all seriousness though, I would like to understand this a bit better as I have not heard of this project before. Is Ultibo actually written in assembler, and then when you compile your Pascal program the assembler boot modules along with the compiled program code are merged together? To me, bare-metal means assembler, or if you're really hardcore, binary.
https://github.com/ultibohub/Core/blob/master/source/rtl/ult...
Have you realized that every smart card you have, like a bank card, or a SIM card in your phone, runs Java code inside, using such a Java-optimized CPU? https://en.wikipedia.org/wiki/Java_Card
Early versions of macOS [1] were written in Pascal.
[1]: https://en.wikipedia.org/wiki/Category:Pascal_(programming_l...
Rasp. Pi however is extremely powerful, far more powerful than any computer we had in the 90s or early 00s. The idea of running RP4 "bare metal" is rather weird to me. RP4 has so much processor power on it that a proper OS seems like a no-brainer.
-----------
Looking at Ultibo, it seems like it has a threading library (https://ultibo.org/wiki/Unit_Threads), so that makes it an OS in my eyes (at least as much of an OS as FreeRTOS).
Hmm, I think from a marketing perspective, they should discuss how Ultibo builds compare against minimal-Linux builds? It'd be great to compare Ultibo-Hello World vs Alpine Linux-Hello World (Alpine being the smallest Linux I'm aware of). Maybe have a comparison vs Ubuntu for good measure as well.
Its not very hard to go into "Realtime" priority and force your processes to use up 100% of the CPU's power in Linux. If you need the _WHOLE_ CPU, then you can forcibly grab it as long as you're root.
Like, yeah, twiddling a GPIO line is more expensive than you'd think on an RPi. It's in the dozens of cycles range. But if you look at it in terms of wall time, single cycle access on an Arduino is 62.5ns, and each cycle on an RPi at 900Mhz is 1.1ns, so they're in the same ballpark if you have bare metal access.
Its not the CPU's clock that matters here.
https://codeandlife.com/2012/07/03/benchmarking-raspberry-pi...
With 14MHz best-case from the Rasp. Pi, its clear that the GPIO clocks are simply at a slower rate than the CPU.
Also, with C, you can achieve the highest possible GPIO rate on the Rasp. Pi. No need to go into an alternative OS.
And BTW, the problem isn't slow clocking from the GPIO. It runs at about half CPU clock depending on the RPi model, which doesn't account for the latency you're seeing. It's actually spending most of the time simply propagating unchached accesses across the fabric, taking a long time for the same reason that an uncached read from DRAM takes a lot of cycles.
But at the end of the day, my whole argument was that the hardware is capable of about equivalent to an Arduino in terms of wiggling lines. However, from Linux you can't consistently meet deadlines without writing a kernel module because of the IPIs the kernel uses internally for bookkeeping. At that point you're comparing the developer UX between writing a kernel module with that of an Arduino sketch, and there's a pretty clear winner for productivity. That's why I welcome alternative software stacks.
My point stands: Raspberry Pi is huge. Even old models like RP2 give you 6-orders-of-magnitude more RAM and 2-orders-of-magnitude more Compute power. Its just not the kind of processor I think of that needs to be run "bare-metal", or even "something more efficient than Linux needs to be installed on here".
Its interesting that Ultibo is aiming for the Rasp. Pi. I'm curious what kinds of use cases people will find for it.
Part of the magic of these bare metal language environments is that you run against your own limits before you reach the limits of the hardware, especially in a hobby coding context. Linux makes it much easier to outstrip the CPU and RAM available in RPis.
People do run RTOS'es on these size of processors, mainly for latency control but you still want beefier processors / RAM. An RPi4 (normally) is cheaper than some Arduino / MCU kits.
Also, RTOS'es can be easier to build and keep stable for years which helps with embedded projects where you don't want to update your linux kernel and drivers every 6 months.
Baremetal makes less sense though. Well other than for hobbyist reasons IMHO since you tend to need lots of drivers to make them functional which isn't true for many MCUs. I'd guess this is a hobby project for the fun/joy/masochism of running baremetal.
I see threads, filesystems, networking (Ethernet) and even graphics drivers here. I dare say that Ultibo is more feature complete than an OS like FreeRTOS.
Its a weird marketing choice. Maybe Ultibo's developers aren't very familiar with the language of embedded programs, but I'd call Ultibo a Pascal oriented Operating System for the Raspberry Pi. Just my personal opinion on this matter.
To me maybe useful distinction is if the thing is able to function by itself, so is it a system by itself, or does it need additional pieces to become a whole system. Going by this categorization for example Linux is not an operating system by itself because you also need userland to function.
That being said, wikipedia does categorize unikernels as "library operating systems" https://en.wikipedia.org/wiki/Operating_system#Library
But if we accept that unikernels are operating systems, then the obvious question is what set services push something from library/framework to operating system. Is a disk/file-system driver an operating system? Its not like DOS did provide much more than that afterall.
> What is Ultibo?
> Ultibo core is a full featured environment for embedded or bare metal (without an operating system) development on Raspberry Pi (all models except Pico). It is not an operating system itself but provides many of the same services as an OS such as memory management, threading, networking and file systems.
It's an interesting discussion about whether Ultibo is an OS or not. It's one I've had with a friend of mine. My contention is that it is not an OS. Here's my reasoning:
Ultibo is made up of two things: a. An IDE (based on the Lazarus IDE for Free Pascal) together with an integrated Pascal compiler (FPC). b. A set of libraries which implement all of the features described in the wiki. These are all implemented as Pascal "units".
Neither of these things are an OS. Ultibo's libraries (units) have a lot of the capabilities that an Operating System has and so you could, if you wanted to, build an operating system with it. But the thing you are installing is not an OS. And any application built with it would be missing a key capability: the ability to load and execute multiple processes, as that is not currently possible.
Furthermore, none of the features are always present. You only get the things you compile in to your application. So if you don't include the filesystem unit, not only can the application not access files but the filesystem as a whole literally does not exist to the application. That is quite different to an OS.
Accessing hardware can only be done if you compile in the device driver for the hardware (and if there isn't one, you have to write it first). There are no services sitting underneath your application that are always present just in case you want to use them. Compare this to Linux, where as long as a device driver is loaded any application can use it and it is always present just in case.
Lastly Ultibo does not provide any services to load and execute multiple applications. There is some work in progress to allow dynamic libraries to be loaded which might open the door to that kind of thing but again it wouldn't make the thing you are building an OS unless you actually build an OS with it.
Why do they call it bare metal? The key differentiation here is that when you write an Ultibo application, you are creating a kernel which will be booted instead of the traditional Linux kernel. That kernel will be a single purpose application. It has direct access to all of the hardware, warts and all. In effect, all of the memory and memory mapped hardware ports are in user space, so if you want to write to a random memory location you can. There are no protections that an OS typically offers to wall off units of execution.
I can certainly see that some would still think it's an OS even after all of the above (my friend does). After looking at a wikipedia page on what the definition of an OS is, we found "library operating system" which kinda covers it if you ignore the cloud bit. But it is not an OS in the traditional sense, to me at least. It is not "another linux" which is how I saw someone on a Pi forum describe it. In the end, how people want to classify it doesn't matter, but if the developers called it an OS they would have failed get the point across about what it is. One could argue they failed anyway, given this discussion ;-)
What's it used for and do you really need bare metal access to a Pi given its power? One of the big advantages is boot time. An Ultibo application boots in less than 2 seconds. This instant on capability is extremely useful for many single purpose embedded devices. The filesystem is designed to allow it to be just switched off without needing to flush any write cache so it's safe in that respect (you must design apps accordingly of course). The other thing is Ultibo has full VC4 support as per my cluster stuff above, and so an HDMI screen with accelerated graphics is supported out of the box. That is way beyond the average microcontroller and that opens op a broad range of uses.
It's hard to use all of the power of the most powerful Pi's with a single purpose kernel, not least because there is nothing else running sucking up the resources other than your application. That just means you can do a lot of stuff on even the lower powered Pi's which makes devices cheaper to build. My cluster runs on a Pi3b+ and uses maybe 25% of one core and not much of the other three.
My cluster uses OpenVG rather than OpenGL ES, but both are supported by Ultibo. I only needed 2d graphics and OpenVG is kinda easier to get going with.
Sadly I think the use of Pascal holds Ultibo back a bit. It doesn't bother me as its a tool to get the job done, but many people see Pascal as a "dead" language and that puts them off. Ultibo is extremely powerful though and the developers have put a lot of effort into making it very stable and feature rich. Remember the Pi's hardware is almost completely undocumented due to the agreements with broadcom, so a very large proportion of Ultibo has been built as a reverse engineering exercise. That's super impressive to me. I built a wifi device driver for it, again via reverse engineering, and it took me a month to do it more or less full time.
If you want to see a hello world application, here's one: https://github.com/ultibohub/Examples/blob/master/01-HelloWo...
That uses the framebuffer for the console, which enables basic text output.
Therein lies your mistake.
I'm not comparing Ultibo to Linux. I'm comparing it to FreeRTOS. https://www.freertos.org/
An "Embedded Operating System" has far fewer features than you believe. Ultibo has more features than FreeRTOS, so its weird to call Ultibo just a set of libraries or a programming environment (like Arduino). Since Ultibo can replace FreeRTOS, its an OS.
This whole discussion is, I think, one of the reasons why Ultibo has failed to get any traction in terms of users, despite the clever stuff you can do with it (not the only reason though as audience reach is probably a bigger one). There are only just over 1,100 members on the forum, which is kinda sad considering the effort that must have gone into producing it and the length of time it has been around (about 7 years now I think).
Perhaps you are correct and they should have marketed it as an Embedded OS for Pi. It might have made more sense to people that way, rather than describing it as a bare metal development platform.