Ultibo – Bare-Metal Pascal for Raspberry Pi(ultibo.org)
ultibo.org
Ultibo – Bare-Metal Pascal for Raspberry Pi
https://ultibo.org/make/
9 comments
Awesome! Next steps: ChatGPT in a voice interface, and a Turbo Boost button.
Or combine it with that engine noise generator that uses a full physical simulation:
https://youtu.be/RKT-sKtR970
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.
https://youtu.be/RKT-sKtR970
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.
thats really cool
FYI:
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
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
This is a blunder, of course.
But the serious docs are there: https://www.freepascal.org/docs.html (And I haven't forgotten Pascal since 1980s anyway...)
But the serious docs are there: https://www.freepascal.org/docs.html (And I haven't forgotten Pascal since 1980s anyway...)
[deleted]
If you could only buy a Raspberry Pi these days... rpilocator.com exists, but RPi4's and/or Model B's barely (if ever) show up.
Any pico support planned?
Wow this seems super fun and awesome for adults and kids alike
TLDR: Ultibo is a bare-metal environment written completely in Free Pascal. Because it supports multi-threading you can see it as Unikernel Operating System. You develop your bare-metal program in Lazarus IDE in Free Pascal and use Ultibo as (unikernel) library for your application. After compilation you get the Raspberry Pi image file which you put on your SD-card and run the program on RPI - baremetal. It has support for USB, Ethernet, FAT, NTFS, ...
I knew holding on to my Pascal textbook since the 80s would come in handy one day. :)
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.
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.
It doesn't necessarily mean assembly, just the absence of a separate operating system. It looks like Ultibo is mostly written in Pascal, with a small amount of inline assembly to initialize the hardware, etc.
https://github.com/ultibohub/Core/blob/master/source/rtl/ult...
https://github.com/ultibohub/Core/blob/master/source/rtl/ult...
But if interpreted it wouldn't be bare metal, no?
I think the line there is blurry. If someone said "bare metal Smalltalk" I'd probably assume they were referring to a Smalltalk VM running directly on the hardware.
Bare metal Java exists, because Java-oriented CPUs were and are a thing.
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
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
Yes, I'm familiar with that. Why do you ask?
Who said it’s interpreted?
Pascal is totally fine for bare metal programming. (Modula-2 would be better, but anyway.)
Early versions of macOS [1] were written in Pascal.
[1]: https://en.wikipedia.org/wiki/Category:Pascal_(programming_l...
Early versions of macOS [1] were written in Pascal.
[1]: https://en.wikipedia.org/wiki/Category:Pascal_(programming_l...
Programming in PASCAL by Grogono ?
I still have mine.
[deleted]
So Bare-metal is excellent for smaller boards, like ESP32, Teensy 4.1, or the tiny microcontrollers like AVR DD / ATMega, PIC, and STM32F4 or STM32G0. So are lightweight OSes like FreeRTOS. There's also Arduino (set of libraries), which is somewhere between a proper OS and bare metal.
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.
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.
Funny story, I found a game I wrote in Turbo Pascal from 1988 so I decided to run it a couple of years ago in a DOSBox. whenever I ran it, it just ended immediately so I assumed it was broke, I eventually tried it in a VM running DOS at about a hundredth the normal CPU speed speed and I saw the system draw the screen, play the demo game, time out and end all in about five seconds.
The RPi is derided for it's ability to keep up with even soft real time tasks because of the matching "huge"ness of the software stack people commonly associate with it (full Linux). I welcome alternate stabs at software stacks that aim for a KISS attitude to let it compete with an Arduino when it comes to signal twiddling, etc.
I personally recall the GPIO benchmarks you're talking about, and I seem to remember it being related to the CPU itself and nothing to do with Linux.
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.
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.
It's more that the GPIO interface on Linux is very heavy weight as it's a sysfs interface to perform any signal transitions, and exposes only a lowest common denominator of function composibility. That eats a ton of cycles.
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.
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.
> and each cycle on an RPi at 900Mhz is 1.1ns
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.
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.
The sentence just prior I stated that it was dozens of CPU cycles to access GPIO blocks. Your citation is consistent with my statements.
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.
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.
The FAQ says it runs on pretty much all RPI's.
So you can also use it on an old Raspberry Pi you might have laying around.
It doesn't have to be a RPi 4.
RP2 is quad-core, 900MHz and 1000000kB of RAM, a behemoth compared to the single-core 20 MHz and 2kB of RAM chips (ATMega328p aka Arduino Uno, which actually runs at 16MHz) I was comparing it to in the embedded world.
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.
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.
RPi2 is pokey enough that you really feel the limitations of the platform when you put Linux on it. Sure, you can run the kernel, but you are going to want to stop short of, say, any web browser that can function well on today’s web. Even a RPi4 isn’t a good daily driver for web browsing.
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.
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.
> 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".
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.
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'm looking through the Wiki, and calling Ultibo "bare metal" seems like a misnomer.
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.
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.
"operating system" is not super well defined term, and the distinction is definitely bit blurry when it comes to unikernels like this.
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.
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.
I don't see Ultibo calling itself a "bare metal" environment anywhere on the site, really. It's pretty clear that it kind of provides an operating system. The title of the link seems to have been editorialized by the submitter.
The wiki starts with:
> 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.
https://ultibo.org/wiki/Main_Page#What_is_Ultibo.3F
> 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.
https://ultibo.org/wiki/Main_Page#What_is_Ultibo.3F
sounds like they made an OS without noticing that they did that :D
I came to this post because the video posted at the beginning of this thread is mine. I saw a big spike in video views the other day and it took me a bit of digging to find out where the extra traffic had come from.
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.
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.
> Compare this to Linux
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.
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.
The reason I mentioned linux is because that is what runs on a Pi normally and hence that is what people tend to compare Ultibo to. In my opinion that is not a sensible comparison, so we probably agree there as you are comparing it to FreeRTOS.
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.
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.
I believe as per this link they actually support VideoCore IV and the associated libraries (not ported to Pascal though) and that allows access to the camera module as well:
https://forums.raspberrypi.com/viewtopic.php?t=193560
https://forums.raspberrypi.com/viewtopic.php?t=193560
[deleted](1)
https://youtu.be/iH9lp-Nms-o