Interesting concept for Baremetal Pi
fixmax
Posts: 91
Hi folks,
I found a new site, that looks pretty promising. It is a new compiler that will let you do baremetal programming on the Pi.
https://ultibo.org/
It looks like it just started, but I did try it, and it basically booted up in under a second - with the LCD. I have a Pi touchscreen with it, and ran a simple "Hello World".
video of quick bootup --> https://youtu.be/hoTmHsxDiPE
Although its still new, and they are working on adding stuff, I wonder if this wouldn't be a good fit with a Propeller? You literally would have a cheap LCD, access to more I/O, USB, Ethernet (maybe even Wifi with new Pi3).
Anyone think this might be a good combo? I'm not super enthused about programming in Pascal (?), but it seems easy enough. Any thoughts?
PS: Doing some more research on this. An example of potential is here: (basically 8MHZ off a GPIO)
wiki.freepascal.org/Lazarus_on_Raspberry_Pi#5._PiGpio_Low-level_native_pascal_unit_.28GPIO_control_instead_of_wiringPi_c_library.29
I found a new site, that looks pretty promising. It is a new compiler that will let you do baremetal programming on the Pi.
https://ultibo.org/
It looks like it just started, but I did try it, and it basically booted up in under a second - with the LCD. I have a Pi touchscreen with it, and ran a simple "Hello World".
video of quick bootup --> https://youtu.be/hoTmHsxDiPE
Although its still new, and they are working on adding stuff, I wonder if this wouldn't be a good fit with a Propeller? You literally would have a cheap LCD, access to more I/O, USB, Ethernet (maybe even Wifi with new Pi3).
Anyone think this might be a good combo? I'm not super enthused about programming in Pascal (?), but it seems easy enough. Any thoughts?
PS: Doing some more research on this. An example of potential is here: (basically 8MHZ off a GPIO)
wiki.freepascal.org/Lazarus_on_Raspberry_Pi#5._PiGpio_Low-level_native_pascal_unit_.28GPIO_control_instead_of_wiringPi_c_library.29
Comments
States this
Ultibo requires a customised build of both Free Pascal and Lazarus, however you can install our build of Lazarus without affecting your existing installation because the paths have been changed to avoid any conflict.
- & seems to have a smaller min footprint than Project Oberon. (~ 200k+ mentioned)
Such sub-1MB starting points, do make a strong case for a SPI Flash memory, which Rasp Pi currently lacks. (but P2 will include)
Spin has many elements in common with Pascal, but I think there is no Pascal for P1 **?
There are Pascal compilers on other small MCUs like 8051 and AVR, and there is an Oberon compiler for ARM and Risc V
Longer term, if this Ultibo were to add a code generator for P2, that could get interesting.
It will come down to how small that min-footprint can be and how much you can pack into the 512k of P2 & how well P2 finally manages XIP hardware.
How they manage remote Debug is unclear ?
** A search finds an old/retired thread & further links, not clear how '2016 Active' many of these are ?
http://forums.parallax.com/discussion/113091/ultimate-list-of-propeller-languages
https://ultibo.org/forum/viewforum.php?f=4
and the mid-Feb release mentions
Add more outline and structure to device support for common devices like GPIO, UART, PWM and DMA.
Forums show Pi users are having to fight Linux somewhat to control UART etc, so I wonder how this runs-up at Serial control ?
( & how fast Pi3 can run Serial ?)
The Pi hardware has quite high values for SPI and UART potential (hardware theory) speeds, and certainly could co-operate well with P2 (and be useful for P2 testing)
It's not so bad LOL . Pascal was developed in the late 1960's . I started to play with Pascal back in 1985 or so
Also, you should be able to use the Free TMS components in Lazarus.
Our little New-Year gift for Pascal developers
On this last day of the year, we'd like to introduce a first version of a little New Year's gift for you, Pascal developers. If you are, like us, excited about Internet of Things, embedded software development, DIY projects, controlling electronics from your code, ... we have for you a first version of our new free & open-source bundle of hardware access components for Raspberry Pi. You can download full source code from here
http://www.tmssoftware.com/site/blog.asp?post=322
Now, Free Pascal and Lazarus are pretty impressive in that so many operating systems and platforms are supported.
It's not clear to me why one would want to throw out cross-platform support and go "bare metal" with a unique custom OS.
If your 'check one option' does not include what you actually want, you can see the results in the many postings in the forums - take a look.
Many find it not so easy, and a number of kernel rebuilds have resulted, from needing fixes to the issues....
Seems even in 2016, it is still something of a moving target.
It can't be size can it? How many people really need to scratch around saving bytes on machines with a gig of RAM?
It can't be execution speed. Removing the OS does not magically make your code run faster.
Perhaps it's speed of bit banging and other direct I/O interfacing. I could imagine that is so. If you only have one thread running. But is your alternative OS really that much more efficient at scheduling networking, or multiple tasks and so on. Perhaps it is.
Boot time might be a big win though. If that is an issue for anyone.
Oddly enough some nerdy guys around here have a similar idea. But they want to keep the Linux kernel, pared down to the minimum required for an application. Get that loaded and booted as fast as possible. They want to throw out all the usual services and user land stuff you find on a Linux machine. Instead have the kernel immediately start node.js and run Javascript apps.
After that I get to open and configure serial from my code, pretty much like any other system.
Guess I'm lucky in not wanting to do anything weird with the UART.
Somewhat reminiscent of what Wirth did with the Oberon OS/Compiler by putting it on a FPGA.
It will be, for those wanting to run a Pi deeply embedded.
Pi 3 data is still like hens teeth, but Pi 2 numbers & registers suggest a 250M/4N baud granularity, and a Max of 250M/16 = 15.625 MBd, but I've found only mention that up to 4 Mbd is supported on newest patches, and then only 1~1.5Mbd is reliable.
Given the ARM clock speeds here, it seems surprising that the Baud ceiling is so far below what the hardware can in theory support.
That is the appeal of bare metal, & I see a mid Feb Ultibo build has the register maps for all UART access, but I cannot see examples testing the speed yet.
Possibly the P3 has higher HW Baud numbers - certainly be interesting to see what that does to sustainable baud rates ?
Maybe an Oberon -> FreePascal translator is needed here ?
Seems this may be closer... ?
https://lists.inf.ethz.ch/pipermail/oberon/2014/007728.html
Addit: I also find this (not Project Oberon, but a byte-code Oberon-2 compiler for Pi)
https://spivey.oriel.ox.ac.uk/corner/Oxford_Oberon-2_compiler
https://spivey.oriel.ox.ac.uk/corner/Installing_OBC_release_2.9#Raspberry_Pi_under_Raspbian
Funny you mention that - its the first thing I thought about.
I'm thinking a tail wagging the dog deal here. Multiple Props into the 40 pin header - bit banging serial on whatever/however many pins you needed, tying it all together with the Pi with the multithreading, multicore, access to the Pi LCD, other GPIO, I2C, SPI, USB, SD Card, Wifi, Ethernet, Pi Camera (what!?).
This "forth-like" language is written in free pascal. https://github.com/sabren/b4
Ok, Peter and Sal. Your new task is ready for you...
Of course a few extras would be nice as well, like this board could carry a real-time clock chip seeing as the Pi does not have one.
Since the release of the PI Zero at around US $5, I am tempted to use it as an add-on board to a propeller just only to be able to use the huge RAM and SD card for high speed data storage/logging.
I am waiting for some IO bit-bang performance review to see if it can be really used for this purpose. (and of course also waiting to see the board available at the corner store).
It's not a Propeller but it makes a good add for one. What with it's storage, memory, networking, USB, camera. HDMI...
The Pi Zero makes very cheap Prop Plug, with smarts!
A Pi 2 can bit bang about million reads or writes per second or respond to 8000 interrupts per second. In Javascript!!
I guess the Zero is half that perhaps.
Also the ultibo IDE can be run on the Pi itself. They have tutorial how to compile it on the Raspbian. The compiler outputs kernel7.img file (or kernel.img for RPi 0/1). Simply rename kernel7.img to kernel7_.img and copy the compiled krenel7.img to /boot, then reboot and you are in Ultibo environment. If your Ultibo code can rename kernel*.img and restart (the Ultibo is capable of this) you can switch then to the Raspbian again
As I am Lazarus/fpc programmer this is a good environment for me
I have this heavily SIDCog inspired, low level programmed in pascal and a lot of asm RPi SID player here https://github.com/pik33/Retromachine-SID-player - so I will learn Ultibo converting the player to this environment.
My tests with Chrome/Chromium:
Chrome 53.0.2785.143 @win8 - works
Chromium 51.0 on Raspbian/RPi3 - works
37 seems to be obsolete
RPi with realtime cores with interrupts disabled - this is fascinating
Real-time cores on the Pi with interrupts disabled is certainly an interesting idea.
I suspect one can do it in a stock Raspian Linux installation. Bind your code to a core. Give it a higher priority than anything else if need be. Let it rip.
For example : http://www.glennklockwood.com/hpc-howtos/process-affinity.html
Of course serious high speed, high precision bit banging of GPIO pins will still be "fluffy" because of the caches between your program and memory. I suspect that for small programs and data sets that can be eliminated as well.
No, I have not tried any of this. So I may be totally wrong.
If it does work as expected that would be cool. Real time cores for the timing critical stuff and perhaps just one core running good old Linux to take care of everything else.
There are 3 problems. (1) (solved in the link) - assign a process to a core, (2) remove all other processes from this core and tell the scheduler not to assign any other processes to this core (3) - switch off interrupts.
I don't know if 2 and 3 can be done in standard linux environment. Making the process high priority still doesn't protect it from preempt by the scheduler.
Another thing: Ultibo program starts instantly. You don't need to wait 30 seconds to start the system, then to start your program.
Yet another thing: all your program is compiled to kernel7.img which then is often less than 1 MB.
Pascal.. this is my programming language of choice when not in Propeller environment - I use Spin/PASM there... and yes, I can read/write C but I don't like C at all....
Spin was easy to learn for me as Pascal user, the most prominent difference was indentation instead of begin..end.
You raise some good points.
As I said I have never tried this but some kind of reasoning tells me that:
If one binds a process to a core and gives it a higher priority than all else then it's never going to be preempted, why would it be? The kernel knows that process is a high priority and that it has other cores to juggle lower priority things on.
Similarly for interrupts. So they should never get in the way either.
I think that addresses your points 2) and 3)
This calls for some experimentation...
Boot time can be an issue sometimes.
Well, if you need all the luxury that a Linux system offers then that all has to be loaded and started. Certainly you can cut down a lot of that if you don't need it.
I'm not inclined to worry about my program being 1MB or 10 or a 100. We have a gigantic free space on SD cards and the memory of the Pi is huge.
Spin was easy to learn for me as a C user, the most prominent difference was indentation instead of {..}.
I think that part of the appeal of Ultibo is the community around it.