baremetal graphics library

I wrote this code several years ago for WinCE (PocketPC/PPC Phone). It's written in ARMv5 assembly language (will run in RPi0) and I have a portable C version. I needed to write this to develop the Dance Dance Revolution game for Konami. It has primitives for lines/circles/rectangles/stretchblt and supports translucency. All of the code was designed to run on RGB565 surfaces, but also supports RGBA.

I've ported it to compile on the RPi and was considering documenting it and releasing it as open source. Here's a short video demo of it running on a SPI LCD (ili9341 240x320) using my LCD code:

https://youtu.be/8VoxaDIMALA

It doesn't have any external dependencies and seemed like a good fit for bare metal projects. If this looks useful, please let me know and I'll clean it up and release it.

This would be useful for the Circle C++ stuff?
I don't think rst has done TFT SPI LCDs yet?

I had have been looking at your code, especially the method of accelerating the fps by only drawing the changes.
Mostly goes over my head, trying to figure out someone else's code can be hard.
Usually I have to write my own version and then compare it to understand how other's code works.

We have bunch of graphics stuff now in Ultibo, but your stuff would make for more fps on SPI TFT LCDs.
I have not even looked at Garry's LCD code for the ILI9340/HX8357 to see if it is diffed.
Hmm, ok looks just like framebuffer dump to me.
https://github.com/ultibohub/Core/tree/ ... bo/drivers
Any suggestions for making these drivers better/faster would be appreciated.

Not sure if it will make much difference to the HDMI stuff as this is not stuck with slow SPI.
And pik33 seems to really know what he is doing with DMA assisted graphics, unlike me
https://ultibo.org/forum/viewtopic.php? ... c&start=60

Now if only someone could figure out VC4 accelerated graphics on baremetal
Still it is amazing that even I can make 4K screenshots on Pi's without even having a 4K monitor
And we will soon have a Window Manager.

Once you have graphics with a Windowing Manager can it still be called baremetal?

Thanks for the detailed response. I'll clean up the code and release it shortly. These functions can be a useful addition to the Ultibo graphics because of the support for transparency and translucent blending. This would be useful for HDMI framebuffer apps as well as SPI connected LCDs. The code is quite fast for having to manipulate all of the pixels directly without the use of NEON instructions (Raspberry Pi Zero).

I don't agree with the use of Pascal for bare metal programming, but I suppose it makes some people's job a little easier.

I had a look at the Ultibo code for talking to the SPI LCD. It probably won't hurt the performance too much compared to the fbtft C code, but it definitely is not optimal. I haven't yet released the heart of my LCD code which compares frames and only writes the changes. This would improve performance in almost any situation. The problem with the Linux framebuffer way of dealing with these LCD's (fbtft) is that it relies on the paged memory fault mechanism to know what pixels changed. This slows down access to the framebuffer memory (every access causes a fault and the driver adds the address to a 'dirty' list) and is a very coarse way of knowing which pixels changed. It doesn't fit well with the locality of how pixels are modified because memory is laid out linearly, but modified in a different pattern. Here's a real world example for the 240x320 LCD:

If a program/game is tile/sprite based and a single 16x16 sprite or tile is changed, this would touch at least 2-3 pages of memory (240 pixels x 2 bytes per pixel x 16 lines = 7680 bytes). This would cause the driver to write 8192 bytes to the LCD (2 x 4K pages). In my dirty-tile arrangement, if that change was lined up on a tile boundary, it would cause a 16x16 tile to be marked as dirty (512 bytes would be written to the LCD - 1/16th the amount of fbtft). Depending on the application, this can have a drastic affect on refresh rate.

I'll release all of this code shortly and report back here. For anyone wanting to try it sooner, let me know and I'll share it in its current form for you to beta test.

I released it as open source:

https://github.com/bitbank2/bbgfx

The imaging code that it uses to load png/jpeg/gif/bmp files is still closed source. I'll open source this in the near future.

That was quick release.

I don't agree with the use of Pascal for bare metal programming, but I suppose it makes some people's job a little easier.

Well bare metal should be assembler only anyway

For me it is about making it a lot easier and quicker, which I get with Ultibo.
Plus I get quality code(er, as in not mine ) underneath my layer.
And Laz/FPC library will/can/could be used to extend things, again not my code

Doing assembly is not easy and if I have to learn/do it, not quick and not portable or good.
Learning baremetal is about learning the guts of the SoC.
Using baremetal is about making apps smaller and throwing away the Linux with all it's issues and legacy.

Baremetal means no OS, but what I seem to end up doing is making a specific purpose OS for each project.
Never really expected the graphics to advance so fast as I was mostly doing headless IoT networked stuff.

I've sort of gone full circle, back to coding single apps on an IDE, only difference is the app goes on a SD card and the Pi boots it and it is not programmed into the on chip flash of a SoC.
That's called embedded programming so I guess it is really embedded coding not baremetal.

Is it an RTOS? Well it's not really real time and not really an OS, but it could be.
FreeRTOS without the need to do RT or OS, QNX, EmbOS, ThreadX, VxWorks, uLinux, iTRON, uiTRON?
Not really any of those either, it's too easy to use

Arduino for grownup SBC's, that's about as close as I can get.
Like Linux, it is evolving and there are now quite few ways to do graphics with it.

I have been using fcl-image for image conversion, probably not the fastest but it works.
Some others have ported bitmap, OpenJPEG, APNG etc.
There is even a chance of getting the jpeg stuff on the VC4 working, OMXjpeg?

If a program/game is tile/sprite based and a single 16x16 sprite or tile is changed

There looks to be a Tile engine in the VC4 page 46
Used in the mouse pointer examples? and I have tested it up to 64x64pixels with transparency.

Not sure if it is just one tile only, but there is other tile stuff in the VC4.
Figuring out how it works for baremetal, that might take some time?
pik33 is DMAing his sprites, but I am sure there is stuff in the VC4 that should make this much easier.
google time?

Im actually happy to see that there is still a taste of Pascal vs C going on. I dont think one could argue C won, the argument might be why. Happy to see that there is still some Pascal life around, not that I like it any better or worse, I might like it better with some changes just like I would like C better with some changes but in either case can mostly avoid them.

Both languages were not THE languages by themselves but were dominant languages that broke us out of assembly only for baremetal work, back when baremetal was much more common, or the OS was much thinner (BIOS/DOS for example), etc. We could have a debate, would rather not, about DOS being an operating system (note it is not dead still very much alive in products you touch lets say daily to weekly, that may be dropping to monthly or annually depends on what you do and where you go and what you buy, etc). And so then are DOS programs bare metal or are they not, as some folks remember there was still a fair amount of direct hardware access DOS helped with some common aspects, file systems, but others you were on your own, printer, video, etc. as the name implies it helped with disks...Pascal then C then C++ were major players and the Assembly language vs Pascal vs C was a battle for a while.

So if you can get it to work which has been clearly demonstrated, Pascal is IMO one of the two preferred languages for baremetal, has the right history, design, etc (the other being C). I also believe that if you squint just right when someone gives you a large library of solutions and you are just making api calls, is that really bare metal? Arduino is a good example of this, or any of the libraries from microcontroller chip vendors (not saying the Arduino environment is from a chip vendor, it isnt, is just a similar solution or a fluke or natural progression). Another debate I would rather not have...Just wanted to also comment on Pascal as a baremetal language.

I want no debate either, I'm not qualified for it.
After learning so many languages in the last 5 years or so since Pi's came out, what was one more.
To me it is just a tool to get the job done.
Whatever language makes my job easier for designing and making equipment is what I use.

Just like "baremetal" removed the need for me to manage both the Linux OS plus the app.
I am not a CS grad or have any official training in coding except 6 months of Z80 in TAFE 30+ years ago.
I don't count my Hour of Code Certificate

What I am saying is " wow, graphics on baremetal"
With more than one choice of methods/libraries/units or language etc.
And it looks like Pascal is ahead and leading C and the rest of pack at the moment.
Mostly due to the efforts of one person.

Someone just got 250,000 lines of code running on Ultibo on QEMU.
That is some baremetal ap, not just messing about with assembler to flash an LED.
Going to be interesting like Docker is.

Who is working on Micropython for baremetal Pi's?
JS baremetal? Luajit? Rust, GO.....
Once someone shows the way, others go "duh !, that makes sense"

Just like dwelch67 and HH and a few others got off the path and into unexplored baremetal jungle.
Now others are following in 4 wheel drives and trailers. Soon there will be a motor way.

Who is working on Micropython for baremetal Pi's?
JS baremetal? Luajit? Rust, GO.....

There is also https://github.com/espruino , runs quite nice on esp8266
Btw when thinking baremetal micropython/lua/espruino it could even run on VC4 without turning ARM core and SDRAM on at all. Just SD card and 256KB of SRAM/L2 cache (based on https://github.com/christinaa/rpi-open-firmware)

The advantage with Pi's is they are fast, cheap, low cost with lots of memory.
Pretty sure we will have lots of languages running baremetal on Pi's, now that there is a few around to show the way.
Ultibo OS in a set top box, once VC4 stuff sorted?

To me I don't see why people prefer one language over another when the differences just seem to be variations in punctuation
Flame wars for white space and semicolons?

In the embedded market space there was no language war that was a PC thing. C dominates embedded because it was usually the only choice as the vendors only provided that. It was many years before you could even get a C++ compiler from vendors. Green Hills, Segger, Keil, IAR systems, Hi-Tech and Intel and a few others were the main tool providers. Some cpu manufacturers would leverage GCC but the support was always hit and miss.

Ultibo has a place on the Pi as you said off the back of one person and a heck of a lot of hard work. That work might be able to be translated onto other microcontrollers (I don't know .. ask Ultibo).

Traditionally Pascal was not even an option for embedded work. I have software credits on freepascal and worked with both the base object code and RTL for the OS2, Windows, DOS and DPMI systems and I dropped it because of commercial reality. It was no small feat to add a new O/S or machine to FreePascal and I would never reach payback on time invested.

What has also changed is compiler technology and now with many active LLVM developments in future you will probably be able to choose a great deal more languages for embedded development. I have already seen a great many LLVM projects that target the Pi off all sorts of languages such as Rust, Forth, Go, CLang, C# and a pile of others.

A search on something like "llvm cross compile arm baremetal" will throw up all sorts of work.

So you have many more choice today and going forward that simply were not even remote options going back.

There is one area all these compiler developments have not really pushed. If I want to turn C code into silicon in an FPGA, ASIC or SOC there is usually always a clear path to do so provided by vendors. Usually it involves converting the C code into VHDL or Verilog and turning that into hardware. That is something that you simply can not do with other languages currently and will act to a barrier to some.

now with many active LLVM developments

Even the VC4 is getting LLVM support

That work might be able to be translated onto other microcontrollers (I don't know .. ask Ultibo).

I did, he's very busy, got a lot on his plate just doing Pi's
But the QEMU version is coming along nicely, already running on the Cloud.
Could you be enticed back?

Look at the embedded FPC stuff.
http://wiki.freepascal.org/TARGET_Embedded
Pretty much any 32bit micro could be a target.
Just like micropython, Lua, JS is going down to MC's.

It pretty much all starts with one person.