Circle - C++ bare metal environment (with USB)

[patrick_h]

@fanoush

It's just Classic ...

[patrick_h]

and @Nakame and @rst ...

I don't post here as often as I post on hackaday. There is an example of Circle multi-core with IPIs in my source at https://github.com/phorton1/circle-prh/ ... kernel.cpp ... I celebrated it at https://hackaday.io/project/165696-rpi- ... multi-core ..

The example 4-track recorder is no more ... it was based on UGUI and I'm no longer using that. Nonetheless, the above std_kernel.cpp supports multi-core, with interrupts and USB running on core0, the UI and audio subsystems running on separate cores, with the audio subsystem using IPI's. That leaves one core free for, uhm, who knows?

I need to make another UI/Audio example ... perhaps the recorder again, but really I should move directly to the Looper (actual code) that I'm trying to write, but now ... thanks to rsts updates to Circle ... I'm in a quandry about the windowing system I'm writing which doesn't look nearly as nice as the littlevgl system (that was not available when I first started working with Circle).

Ahh ... so much code and so little time!

[rst]

@patrick_h

Thank you! To be honest, I was a little bit afraid by myself, if a bare metal RPi 4 support is possible. But now it seems to work.

It's great, what you are doing with the RPi using Circle. My goal for Circle is to build something like a framework, which allows developing (embedded-like) bare metal applications using C++ with less effort and to provide the infrastructure and drivers for it.

I'm not sure, if an operating system with a shell and/or a general purpose windowing system is a thing, which is needed to provide this. To have this is a great thing, but it has disadvantages. It increases the size of the system. Circle should remain relatively small to be understandable. One can build very small GPIO applications using Circle or bigger ones. That helped me very much to get Circle running on the RPi 4, because I was able to let everything out, which was not trusted, to get something to work. I added other components later.

And, Circle is definitively not planned for that many applications, as you wrote. I know my limits. Therefore I do not know, if it is right to compare the successful application you wrote earlier in your life, with Circle.

Circle uses some singleton objects, that's right. I know, that this may cause problems, when the system gets bigger. But at the point, where I decided to use these singletons, it made sense to use them. Because the system was small, had nearly no features and it was a long way to get something running at all. At this stage I used singletons for classes, which were expected to have only one instance. Without these singletons you would have to pass many additional object pointers to most of the class constructors.

I suppose, the µGUI library is currently not able to provide more than one GUI in the system at the moment. LittlevGL is able to provide more than one GUI in version 6, but unfortunately I had not much time, when porting the Circle LittlevGL support from version 5. That's why the one GUI limit remained for the moment.

But because Circle is relatively small, this can be changed, if there is some gain from it. I understand your problems with the CScreenDevice and CTouchScreen classes. They're not designed to provide a unified interface. This has also historic reasons.

If you are working with different displays and touch screens, you will wish to have a common interface. We can work to provide this in Circle. If you want to send a pull request with the changes you have done, I will be glad to check your modifications.

rst

[Gavinmc42]

Ultibo has working BT, I have had it talking to Microbits, other have done more.
Yep crypto is needed for SSH/WiFi.

Been lots of progress since I last looked at Circle.
The most important is Pi4 and Aarch64
Well done.

I have been playing with Kostas' Lil interpreter as there is a FPC version as well as a C version
http://runtimeterror.com/tech/lil/

Been trying to turn that into a OpenVG accelerated scripted shell.
Lil is inspired by TCL and I thought a TK GUI based on OpenVG might be nice.
It is quite easy to make OpenVG rects(Windows), even rounded rects.
Thought about using them as an object based Windowing system.
But my object coding skills are near non-existent.

Then I got distracted by Gentoo64, OpenGL and Pi4's.

Have you looked at Nano-X?
http://microwindows.org/

Someone has NanoVG working on Pi4, not sure how to put that over the top of the Mesa OpenGL for Pi4 baremetal acceleration.

Tim's Shadertoy demo woke me up to Shaders, they seem to talk directly to the hardware.
Could a GUI be done via shaders?
Would have to break out the GLSL compiler but the source is in the Mesa code.

[Gavinmc42]

I just had to google GLSL GUI
https://github.com/turbalman/GLSL-GUI
Barking up the wrong tree?
Seen some amazing stuff with shaders.

Baremetal shader demos = Demoscene?

Why are so many GUI's build on top of libraries like GLFW, GLX, GLU, GLUT etc may as well just use X11 yuk.

[rst]

Been lots of progress since I last looked at Circle.
The most important is Pi4 and Aarch64
Well done.

Thanks.

I'm not a GUI expert, so probably not the right one for discussions about. But I guess, often it's a question of taste, which GUI to use.

[Gavinmc42]

But I guess, often it's a question of taste, which GUI to use.

So many GUI libs to pick from too, but the dependencies are crazy.
Then you have to spend learning how they work.
I have come to the conclusion making my own is more fun and educational.
I can spend the time figuring out how one of many GUI's work or learn how to make one from scratch.

Anyway most GUI's are X11 based which is useless for baremetal.
And then most are some sort of clone of a 2D rectangular windowing system that just pushes pixels/lines and rects around.
Actually it is a reoccurring issue for me ever since I used Pygame back in 2012 as my first embedded Pi GUI.

My currently idea is a scripted UI with hardware acceleration that is language agnostic.
So C. C+, Rust, Go, Free Pascal etc can use it without much change in coding.
Just wish I had the time and skills to do it, ideas are easy, the hard work is actually doing it.

So I usually just wait for someone like you to do the hard work first

[rst]

My currently idea is a scripted UI with hardware acceleration that is language agnostic.
So C. C+, Rust, Go, Free Pascal etc can use it without much change in coding.
Just wish I had the time and skills to do it, ideas are easy, the hard work is actually doing it.

So I usually just wait for someone like you to do the hard work first

Maybe a good idea, but as I wrote, I do not know enough about GUI (libraries) to rate this. If you have many ideas, there must be something you can apply your hard work to. Focus is essential.

[Gavinmc42]

I finally bite the bullet and grabbed your code.
Reason? Because I saw your libgraphics stuff
Is that OpenVG working?
GUI time.
I have made my simple OpenVG GUI's in Ultibo and Go/Raspbian.
Time to try C++ baremetal and then perhaps Rust.

After looking at all your files and samples etc what you have done is way harder than a simple GUI.
With AJ Starkes lib it only took me 1hr to port my Ultibo OpenVG GUI to Go/Raspbian.
Well just the G part, the UI part needs the hardwork

Read through all the posts and figured out how to compile on my Gentoo64 Pi4.
kernel8.img building worked, still need to test it but at least it compiled fast.

I assume this message is because I need an arm 32bit cross compiler on my aarch64 Pi4?

Code: Select all

./makeall clean
g++: error: unrecognized command line option ‘-marm’

Very strange but ARM don't seem to have an aarch64 or armhf compiler that runs on aarch64.
What, don't people develop on Pi's? x86 is so last decade.

I wonder if you could use VSC or Codeblocks as your IDE?
Geany is ok if I'm only doing one file, a bunch of includes can get is confused.

What do you guys use for editing/IDEs.
While I use Lazarus for Ultibo, it can be a pain. I break the Windows/Linux/Raspbian Lazarus' all the time.
It would be nice if there was a IDE that can handle C, C++, Rust, GO, FPC and Ponyc.
That way baremetal apps can be coded in a choice of languages.
Perhaps time to look at Geany's source code?

[LdB]

https://github.com/abhiTronix/raspberry ... toolchains

[rst]

I finally bite the bullet and grabbed your code.
Reason? Because I saw your libgraphics stuff
Is that OpenVG working?

Yes, it's working, but only on RPi 1-3. There is currently no accelerated graphics support in Circle for RPi 4. I had enough to do to get USB and Ethernet running on the RPi 4, so I didn't had a real look at the accelerated graphics. I only tried the old VC4 support, but it does not work on the RPi 4. Not sure, if there is enough information available to get accelerated graphics running with VC6.

After looking at all your files and samples etc what you have done is way harder than a simple GUI.
With AJ Starkes lib it only took me 1hr to port my Ultibo OpenVG GUI to Go/Raspbian.
Well just the G part, the UI part needs the hardwork

This libgraphics project has a focus on text processing with OpenVG. I did this for somebody, who wanted to use accelerated graphics for his GUI and I got information from AJ Starkes project to implement this. But in the end he decided to stay with "un-accelerated" graphics, because an OpenVG needs special handling and he did not want to spent all the effort to port his existing GUI to OpenVG, which was understandable to me. But the libgraphics project is rudimentary and I had not the time to complete this so far.

I assume this message is because I need an arm 32bit cross compiler on my aarch64 Pi4?

Code: Select all

./makeall clean
g++: error: unrecognized command line option ‘-marm’

Very strange but ARM don't seem to have an aarch64 or armhf compiler that runs on aarch64.
What, don't people develop on Pi's? x86 is so last decade.

I do, but on x86_64. Unfortunately I cannot help you to find a 32-bit compiler for your platform because of this. But it's likely that you need a special compiler for this. Ah, I think, LdB has found one.

I wonder if you could use VSC or Codeblocks as your IDE?
Geany is ok if I'm only doing one file, a bunch of includes can get is confused.

What do you guys use for editing/IDEs.
While I use Lazarus for Ultibo, it can be a pain. I break the Windows/Linux/Raspbian Lazarus' all the time.
It would be nice if there was a IDE that can handle C, C++, Rust, GO, FPC and Ponyc.
That way baremetal apps can be coded in a choice of languages.
Perhaps time to look at Geany's source code?

I'm using "kate" from KDE for editing and a terminal window for compiling and "git" commands. But I could post a Geany project file for Circle, which I prepared earlier, if you want to have a look on it.

[Gavinmc42]

There is currently no accelerated graphics support in Circle for RPi 4

Yep I did not think this would be the case yet.
I do have hope it can be figured out, perhaps by analysing the Mesa DRI/DRM layers.
That should in theory allow OpenGL and OpenGLES3.0 to work.
A new VC6 manual would help too.
I am hoping the VG control list stuff is still in the VC6, but I'm not sure if that is ThreadX RTOS based or hardware?

libgraphics project is rudimentary

That might just be enough, the biggest issue will be me getting up to speed on C++

Hmm, just thought of YAFL that might work in bare metal D.
https://github.com/noctarius/dlang-arm-bare-metal
It is bit less painful to learn than C++
No one has done it yet on Pi's?
I have coded some D in Raspbian, last year.
Maybe after learning so many language since 2012 one more was no struggle?

Aarch64 cross compilers I expect will start popping up all over now.
Just need to get more 4GB Pi4's out there.
One reason I want a Pi4B4 is the last time I compiled the RISC-V GCC toolset on a 3B+ it took 13hrs.
Now ejolson has the 32bit RISC-V GCC compiling in 1hr on a 4B4

Kate looks interesting, but go the Oberon method and build the editor into the OS?
Self hosting OS's is tricky, it is also a security hole.

I need to spend more time with git too.
Not enough hours in the day.

[rst]

There is currently no accelerated graphics support in Circle for RPi 4

Yep I did not think this would be the case yet.
I do have hope it can be figured out, perhaps by analysing the Mesa DRI/DRM layers.
That should in theory allow OpenGL and OpenGLES3.0 to work.
A new VC6 manual would help too.
I am hoping the VG control list stuff is still in the VC6, but I'm not sure if that is ThreadX RTOS based or hardware?

I have currently no idea, how to get this running. I only know the VC4 userland code, but this has not been ported to VC6, how it seems. The sample programs report that they are not running on RPi 4, if started on Raspbian.

Hmm, just thought of YAFL that might work in bare metal D.
https://github.com/noctarius/dlang-arm-bare-metal
It is bit less painful to learn than C++

Circle does not use very sophisticated C++ code (e.g. no templates, no C++ exceptions). You need some knowledge about classes, but the remaining code is very C-like.

Kate looks interesting, but go the Oberon method and build the editor into the OS?

No plans on that.

[Gavinmc42]

I have been doing lots of Pi4 OpenGL coding and noticed some things.
Everything seems to go via the Mesa drivers but there is more than one mode.
Every now again some code just seems to ignore the x11 system and go full screen.
I am looking for a Wayland OS so I can test that without x11.

Someone says "Classes" I just think Pascal "Units"
I really don't want to know about classes I just want to use them to make apps.
Anyway these Pi's still have plenty of stuff to keep me busy.
I still need to do OpenGLES on the VC4 Pi's, that's the last thing on my VC4 to learn list.
I might explore the Shaders by they look more fun on the VC6.

Non stop learning with Pi's and the benefit of getting old is I get to learn it over again when I forget

[rst]

Someone says "Classes" I just think Pascal "Units"
I really don't want to know about classes I just want to use them to make apps.

I think C++ classes are not equivalent to Pascal units and there are classes in (Object) Pascal too. But without a basic understanding of classes, it's probably difficult to write Circle applications. I don't think that it's difficult to understand classes and it's a common programming concept today. But if you don't want to know about classes, Circle is probably not the right choice for you.

[Gavinmc42]

Arduino is C++, but I use them to make apps.
There is a difference between using tools and being able to write them.
I see myself more as a baremetal tool user than a tool maker.
That's why some of my ideas are ease of user based, not maker.
It's like driving a car, not making one every time I need to go to the shops

At what point does "baremetal" become usable by an app maker?
Can it still be called "baremetal"?
From reading the forum you have now got Circle++ to a level that people can use for their apps.
You deserve a medal.

Sure, I might have to learn "classes", just like I had to learn "units".
I'm trying to get my head around "actors" that PonyC uses.
Bit of bleeding edge learning pain for the early adopters
I'm not scared of learning, just the opposite.

[rst]

@Gavinmc42 In my opinion it's a fact, that one cannot use Circle without a basic understanding of classes. That I wanted to express. I didn't want to question your wish to learn.

EDIT: "with" -> "without"

[MikeDB]

I've tried installing the suggested toolset from the ARM site https://developer.arm.com/tools-and-sof ... /downloads and selecting the gcc-arm-8.3-2019.03-x86_64-aarch64-elf.tar.xz link. Downloaded a 300Mbyte tar file but when extracted I don't seem to have an actual GCC executable, not do I get the installation notes it says should be included. Any suggestions what I'm doing wrong ?

Thanks

[rst]

@MikeDB This .tar.xz file, which I downloaded earlier, is 68,4 MB big, the extracted .tar file 396,4 MB. The executables are in the bin/ subdirectory after extracting. The toolchain needs no further installation. I don't think, you are doing anything wrong. Maybe a problem with the mirror?

BTW. I'm still using the version 8.2-2019.01 (gcc-arm-8.2-2019.01-x86_64-aarch64-elf.tar.xz) from this website for testing Circle, which can be found at the bottom of the download page. But the one, you have chosen, should work too.

[MikeDB]

I've downloaded the Windows version for now and that seems to work. Must be something my Linux machine doesn't like

[MikeDB]

But I've hit a dead end actually setting up Circle on Windows as everything seems geared to Linux - and it does say "Building is normally done on PC Linux."

Has anybody got Circle running using Windows ? I searched but couldn't find any info on doing so.

[rst]

Has anybody got Circle running using Windows ? I searched but couldn't find any info on doing so.

I tried this a long time ago, normally I am working on Linux only. Beside the toolchain you need a Windows version of "make", GNU make 4.0 or higher is best. I don't know, if this is available as binary somewhere on the net.

Then you have to configure the Circle build system by creating a file Config.mk in Circle root. You have to set your toolchain PREFIX (path and prefix of toolchain commands) there and the RASPPI version, you what to use. This is described in the main README.md file.

After doing this, you should be able to build the main Circle library, like this:

Code: Select all

cd lib
make

If this works, you can go to a sample directory with a simple sample like sample/04-timer and do "make" there. Then you should have the first executable kernel image in this directory.

For more complex samples you have to build the other libraries (e.g. in lib/usb). There is a script for doing this automatically (makeall), but this is only running on Linux. So you would have to adapt it.

There should also the possibility to use the "Windows Subsystem for Linux" (WSL), but I newer tried it.

[MikeDB]

Has anybody got Circle running using Windows ? I searched but couldn't find any info on doing so.

I tried this a long time ago, normally I am working on Linux only.

Thanks I'll have one more attempt at making the ARM toolchain work on my Linux machine but it is an odd-ball used for a specific purpose and if not fixable without messing up it's main use I'll give your suggestions on Windows a go.

One other thought - as I'm trying to run two cores on Linux and two bare metal, can I build Circle on the Pi4 itself using the Geany and associated toolchain that comes on the Pi ? I realise the cores will clash over peripherals and memory usage - I'm aiming for Ethernet, USB & HDMI as Linux only and everything on the 40 pin extender as bare metal.

[rst]

One other thought - as I'm trying to run two cores on Linux and two bare metal, can I build Circle on the Pi4 itself using the Geany and associated toolchain that comes on the Pi ?

Yes, you should be able to build Circle with the GCC standard compiler on Raspbian. You have to set an empty prefix in Config.mk:

Code: Select all

PREFIX =
RASPPI = 4

I realise the cores will clash over peripherals and memory usage - I'm aiming for Ethernet, USB & HDMI as Linux only and everything on the 40 pin extender as bare metal.

Interesting idea and maybe doable. But I guess, you have to write a Linux kernel driver to do this. I don't think, Circle will be a big help to realize such a model.

[Gavinmc42]

I'm aiming for Ethernet, USB & HDMI as Linux only and everything on the 40 pin extender as bare metal.

Run a RTOS on a baremetal Arm core for GPIO while Linux on the other core handles the comms?
I think some guys are trying something like that.

WiFi is almost impossible to do baremetal so far, assign one Arm core with Linux to handle that?