Shop OBEX P1 Docs P2 Docs Learn Events
Interesting concept for Baremetal Pi — Parallax Forums

Interesting concept for Baremetal Pi

fixmaxfixmax Posts: 91
edited 2016-03-01 03:35 in Propeller 1
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
«1

Comments

  • jmgjmg Posts: 15,140
    edited 2016-03-01 03:43
    Interesting, broadly similar to Project Oberon (monochrome), but with less inbuilt GUI

    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)
    fixmax wrote: »
    Hi folks,
    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?

    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
  • jmgjmg Posts: 15,140
    I see revisions are here
    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)
  • re:Anyone think this might be a good combo? I'm not super enthused about programming in Pascal (?), but it seems easy enough. Any thoughts?

    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

  • Heater.Heater. Posts: 21,230
    edited 2016-03-01 06:19
    I'm not sure why anyone would be "fighting Linux" to control the UART. Just check one configuration option in raspi-config and then use it with your favourite tool or programming language. Easy.
  • Heater.Heater. Posts: 21,230
    Pascal is indeed horrible. I'm constantly reminded of that as we have a big lot of Pascal in our product.

    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.

  • jmgjmg Posts: 15,140
    Heater. wrote: »
    I'm not sure why anyone would be "fighting Linux" to control the UART. Just check one configuration option in raspi-config and then use it with your favourite tool or programming language. Easy.
    Depends on how you define control.
    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.


  • jmgjmg Posts: 15,140
    Heater. wrote: »
    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.
    Maybe simple fundamentals like Speed and Size have something to do with it ?

  • Heater.Heater. Posts: 21,230
    I thought about that...

    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.

  • Heater.Heater. Posts: 21,230
    There is only one option in raspi-config. Let Linux use the UART as a console port or not. If not then applications can use it instead.

    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.
  • Interesting idea. Get away from the complex Linux bloatware and go old school like the personal computers of the 80's. Coupled with a decent compiled language and you got a interesting hobby computer so to speak.

    Somewhat reminiscent of what Wirth did with the Oberon OS/Compiler by putting it on a FPGA.



  • jmgjmg Posts: 15,140
    Heater. wrote: »
    Boot time might be a big win though. If that is an issue for anyone.

    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 ?

  • jmgjmg Posts: 15,140
    edited 2016-03-01 21:46
    rod1963 wrote: »
    Interesting idea. Get away from the complex Linux bloatware and go old school like the personal computers of the 80's. Coupled with a decent compiled language and you got a interesting hobby computer so to speak.

    Somewhat reminiscent of what Wirth did with the Oberon OS/Compiler by putting it on a FPGA.
    Yes, someone could maybe port Project Oberon to Bare RaspPi using this Ultibo ?
    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
  • How about a bare metal Forth on the Raspi3? Just sayin'
  • fixmaxfixmax Posts: 91
    edited 2016-03-02 21:19
    mindrobots wrote: »
    How about a bare metal Forth on the Raspi3? Just sayin'

    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...

  • Heater.Heater. Posts: 21,230
    What would be neat is a bare minimum Propeller board, a Pi Hat, that connects to the Pi UART and provides a VGA text only terminal display, VT100 compatible. Then we can use that to log into the Pi and work with it directly if we only have a VGA monitor lying around.

    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.

  • I really never liked the R PI.

    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).
  • Heater.Heater. Posts: 21,230
    Oooo, what's wrong with the lovely Pi?

    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.
  • pik33pik33 Posts: 2,347
    edited 2016-10-02 08:52
    Ultibo allows to free one or more RPi cores from multitasking and interrupts leaving the rest for its core system (eg interrupts, usb control, filesystems etc) . Then you have full realtime on Pi. You can program the ARM core in asm - the Lazarus supports it - so you can treat this as a prop core having 1.2 GHz clock and some hundreds MB of RAM. :) Having then bitbanging capability on GPIO you can connect... for example the Propeller :) to it

    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.
  • TorTor Posts: 2,010
    My browser won't let me see that ultibo site, it complains about ssl mismatch.
  • pik33pik33 Posts: 2,347
    https://ultibo.org/ - I can open and see it. Firefox/Windows 8
  • TorTor Posts: 2,010
    No go with chromium: Chrome/37.0.2062.120
  • kwinnkwinn Posts: 8,697
    Firefox/Win10 works.
  • pik33pik33 Posts: 2,347
    37 ???

    My tests with Chrome/Chromium:

    Chrome 53.0.2785.143 @win8 - works
    Chromium 51.0 on Raspbian/RPi3 - works

    37 seems to be obsolete
  • Heater.Heater. Posts: 21,230
    Chrome 53 on Win 10. No problem with that site. Except that it's a Pascal thing :)
  • pik33pik33 Posts: 2,347
    Pascal is not far from Spin. And you have asm in fpc/Lazarus.

    RPi with realtime cores with interrupts disabled - this is fascinating :)
  • Heater.Heater. Posts: 21,230
    Pascal is far enough from Spin. To my mind the source you have to write is ugly. The syntax is inconsistent. The type checking drives you nuts. We have a huge lot of Pascal at work. I start to not like going to work if I'm ever asked to work on it. But hey, that's just me.

    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.


  • Thank you for bouncing this... very interesting news for me!
  • pik33pik33 Posts: 2,347
    Bind your code to a core. Give it a higher priority than anything else if need be. Let it rip.

    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.

  • Heater.Heater. Posts: 21,230
    pik33,

    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 {..}.

    :)


  • KeithEKeithE Posts: 957
    edited 2016-10-02 19:47
    You can find videos demonstrating fast ~3-4 second Pi boot times on youtube - typically people use buildroot to build their custom systems.

    I think that part of the appeal of Ultibo is the community around it.
Sign In or Register to comment.