User avatar
Gavinmc42
Posts: 1440
Joined: Wed Aug 28, 2013 3:31 am

Re: What are situations to use bare metal when python is so much easier?

Tue Aug 29, 2017 6:21 am

Could not find any Python on Pascal stuff except some old stuff, but I did find something interesting.
http://www.paxcompiler.com/
Now gone commercial
https://www.apexdatasolutions.net/products

I don't know why I would do Python on FPC, Lua makes more sense to me..
That Apex Muse is interesting, addressing the data on IoT issue, but they even talk JVM, CLR, throwing lots of stuff into the pot and mixing it up.
Big data does need something better than just Python, hence SciPy, iPython.
I guess if you throw enough cpu cycles at things they can interpret any script language or all of them ;)

Totally off the track now, time to mention Pink Fluffy Unicorns?
I'm dancing on Rainbows.
Raspberries are not Apples or Oranges

hippy
Posts: 2177
Joined: Fri Sep 09, 2011 10:34 pm
Location: UK

Re: What are situations to use bare metal when python is so much easier?

Tue Aug 29, 2017 9:15 am

LdB wrote:
Tue Aug 29, 2017 3:36 am
hippy wrote:
Mon Aug 28, 2017 7:11 pm
I personally wouldn't call any bootable Python useful on a Pi until it had a screen display, was taking input from a USB keyboard, was able to access and use a file system on SD card, and could communicate with the outside world through a network stack. That has to come and there will be a good deal of effort in achieving that.
So long as you realize most of that will have to be baremetal and that is the point for this to move on you need people who can baremetal. You aren't going to be able to leverage python code and programmers.
Yes, I realise that. Developing or porting Python requires very few Python skills and those with Python skills won't find those useful in helping with that.

I don't mind what gets ported; my personal preference would be to port Python 2.7 but I could live with whatever was provided. MicroPython is most often suggested as the preferred route because it seems more designed to be ported and run without an OS. Having the whole gambit ported would be the ideal solution; 2.7, 3.4, MicroPython and then the Python user could pick and choose what they want to use.

Whatever is done, the big challenge is finding the people to do it. Generally those who want to use a bootable Python aren't interested in doing the porting or don't have the skills and those who could do the porting don't have much interest in using Python. The MicroPython team appear to have almost no interest in porting it to a Pi.

That leaves us with few people moving it along, of which Stefan, as I said, seems most determined at present. Those of us who want a bootable Python can only hope he succeeds and his efforts gain traction, or some other champion turns up to push porting forward.

The reason I like Python is that I find it easy to use and develop with, but best of all it's great for cross-platform coding. Generally the same code runs on anything which supports Python; Windows, Linux, Mac, PC, Pi. There is no need for any tools beyond an editor, no compilers, virtual environments, or figuring out how they should be configured. Develop on anything, run on anything. Just copy the source and the target 'compiles' and runs the code.

The advantage of bootable Python is that deploying an application platform means only having to deal with that and not anything beyond Python.

User avatar
Gavinmc42
Posts: 1440
Joined: Wed Aug 28, 2013 3:31 am

Re: What are situations to use bare metal when python is so much easier?

Tue Aug 29, 2017 10:25 am

I think it was Bela who ported Micropython to piCore
https://forum.micropython.org/viewtopic.php?t=918
I need to get a few more Zero's but I think piCore with Micropython would make a reasonable small Robot OS.
A baremetal version won't have the camera and wifi stuff I will need.
I'm dancing on Rainbows.
Raspberries are not Apples or Oranges

hippy
Posts: 2177
Joined: Fri Sep 09, 2011 10:34 pm
Location: UK

Re: What are situations to use bare metal when python is so much easier?

Tue Aug 29, 2017 11:34 am

Gavinmc42 wrote:
Tue Aug 29, 2017 10:25 am
I think it was Bela who ported Micropython to piCore
https://forum.micropython.org/viewtopic.php?t=918
I need to get a few more Zero's but I think piCore with Micropython would make a reasonable small Robot OS.
I have instructions for installing MicroPython on a Pi under Raspbian and would guess it is similar for PiCore, or any other Linux for that matter -

viewtopic.php?f=32&t=191744
Gavinmc42 wrote:
Tue Aug 29, 2017 10:25 am
A baremetal version won't have the camera and wifi stuff I will need.
That is the bigger challenge; the stuff beyond the Python interpreter itself, libraries, modules, packages and the bare metal code needed between them and the hardware.

Having the interpreter booting is only the first step, not being able to interact with the outside world is somewhat limiting. Having an easy way to get Python programs over to the board to run them will also be something which is beneficial.

Supporting a framebuffer and access to GPIO would probably be useful and usable but access to WiFi, Bluetooth, Ethernet, storage would be even better, a GUI framework would also help.

We have moved away from the OP's questions towards porting MicroPython. Hopefully that might one day become a topic and venture in its own right.

StevoD
Posts: 8
Joined: Tue Aug 29, 2017 11:37 am

Re: What are situations to use bare metal when python is so much easier?

Tue Aug 29, 2017 11:48 am

LdB wrote:
Mon Aug 28, 2017 5:40 am
It can't be fully baremetalled until they release the full details of the VC4. However plenty of us have shimmed the released VCOS system and got EGL running which is about as close as we can get at the moment.
Whoa, hang on a minute. Forget about micro python, If you really have that much working with no OS is there any chance you might share it with the rest of us.

I looked at your repo on git but theres nothing to do with hw accel stuff anywhere.

LdB
Posts: 551
Joined: Wed Dec 07, 2016 2:29 pm

Re: What are situations to use bare metal when python is so much easier?

Tue Aug 29, 2017 12:18 pm

Took me 4 hrs to get it micropython running on my standard compiler tools and I am at about 6hrs so far on their stupid make file system. This is like the classic case of not only everything that is wrong with make files but then to top it off they heavily mix in python scripts in to the build process.

It's bad enough you have to install cygwin, install python, install gnumake and then python scripts are doing version control .. seriously could they come up with any more stupid ideas for a build system. I guess I should be happy they didn't make me install a database program or some other exotic program because they wanted to record the version numbers.

LdB
Posts: 551
Joined: Wed Dec 07, 2016 2:29 pm

Re: What are situations to use bare metal when python is so much easier?

Tue Aug 29, 2017 12:32 pm

StevoD wrote:
Tue Aug 29, 2017 11:48 am
I looked at your repo on git but theres nothing to do with hw accel stuff anywhere.
My repo is just my play public stuff and sometimes the work to extract it from the commercial toolchains isn't worth the effort unless people on the forum where interested. They were all done in response to specific requests on this forum. Now I can put up a simple EGL example but you will have to work out how you keep the vcos system running I will just deadloop it on the sample as all my context switchers I use are commercial and I can't release. To be able to use the system beyond my sample you either need 1 core take it over or use a thread or context switcher to keep it running. That is why I haven't bothered because there is a much more complex part to making a usable EGL system than the vcos.

Ultibo has a public release switcher running so that is why it made more sense on that system but when I looked at doing it my pascal is too rusty. There are probably suitable free C switchers out there but frankly I don't have hours to waste crawling thru them all to find a good one.

StevoD
Posts: 8
Joined: Tue Aug 29, 2017 11:37 am

Re: What are situations to use bare metal when python is so much easier?

Tue Aug 29, 2017 12:56 pm

LdB wrote:
Tue Aug 29, 2017 12:32 pm
Now I can put up a simple EGL example but you will have to work out how you keep the vcos system running I will just deadloop it on the sample as all my context switchers I use are commercial and I can't release.
Any example would be cool, if you look around here a bit youll see people have been trying to get this to work for like 5 years now.

Just something that works as a start point would help everyone.

If the tools are commercial then you could post the urls for them so people can look them up and find out more info.

User avatar
Gavinmc42
Posts: 1440
Joined: Wed Aug 28, 2013 3:31 am

Re: What are situations to use bare metal when python is so much easier?

Wed Aug 30, 2017 2:31 am

Off topic, but I think Peter Lemon has gone further with baremetal graphics than anyone.
https://github.com/PeterLemon/Raspberry ... ontrolList

I am pretty sure that his control list code is portable to Ultibo and I am slowly trying the VG stuff.
But my coding skills are minimal at this level, you really do need to read and understand the registers, manual and missing info..
https://ultibo.org/forum/viewtopic.php?f=15&t=659

EGL is another layer above this but below OpenVG etc. I don't think it is possible to baremetal EGL without knowing the lower level stuff.
One way Ultibo (Garry) is looking at is just linking to the C based library files.
https://ultibo.org/forum/viewtopic.php?f=16&t=449
I think this is how JPEG-2000 is being ported?
https://ultibo.org/forum/viewtopic.php? ... hilit=jpeg

Hardware JPEG? Possible for baremetal?
https://ultibo.org/forum/viewtopic.php?f=15&t=672
a bit on LdB's VCOS here.
viewtopic.php?f=72&t=187867
I go back to posts like these to see if I understand a bit more months later :oops:

VCOS by someone clueless :oops:
https://ultibo.org/forum/viewtopic.php? ... +VC4#p4753

Python is much, much easier, as long as it is ready made/installed.

I use baremetal as a way to learn CS at a lower level than just using libraries.
I use Ultibo because it is FPC based and Pascal has native support for all the capabilities I want to learn.
Plus I can run Laz/FPC on any PC/Windows or Linux so my Pascal skills don't go to waste.
And I don't have to put up with all that GCC C make with dependencies sh..

I did choose Ultibo because any other way is just too hard.
I'm dancing on Rainbows.
Raspberries are not Apples or Oranges

LdB
Posts: 551
Joined: Wed Dec 07, 2016 2:29 pm

Re: What are situations to use bare metal when python is so much easier?

Wed Aug 30, 2017 11:05 am

I will do an EGL post later when code is up, you don't need to really know the lower stuff with EGL because it is a standard on its own. The complication is unless you have played with OpenGL 3.0 or above it will probably do your head in as it's nothing like normal graphics. Even if you have done old OpenGL which had things like glBegin and glEnd it doesn't prepare you for it. There is little on the internet on windows/linux that directly deals with OpenGL 3.0+ or EGL1.5+ without being on a framework such as GLEW or MESA. Then you add the complication that nothing really displays without at least two shaders it gets out of the league of most.

So the problem isn't just baremetal CPU work, they then have to have experience playing around with modern OpenGL or EGL without a framework. You do not want to be trying to wait for someone to port the frameworks to baremetal because it isn't going to happen.

For those on Windows I would suggest they at least working thru the setup of modern OpenGL/EGL inside the simplest framework glew and get to at least tutorial 6 here. Note the first paragraph :-)
http://www.mbsoftworks.sk/index.php?pag ... s&series=1

Now it all looks pretty easy when its done in a framework now lets show you what it looks like done raw code
https://github.com/LdB-ECM/OpenGL/blob/ ... der/Main.c
Look at whats involved just to set the OpenGL3.3 up in the function "SetupOpenGL3v3" and that is the bare minimum function pointers I need.
That code itself is simplistic because I have haxxed using old legacy shaders, I haven't properly uploaded and executed my own shaders which needs even more functions.

If anyone thinks that just getting the VCOS up is going to suddenly make the EGL work you have a BIG surprise coming. Just dealing with the EGL system without the frameworks is a level of complication up from getting the VCOS up.

The only advantage I probably have had is because I had done raw access with OpenGL 3.3 on windows I know what I am up against and how it all works.

LdB
Posts: 551
Joined: Wed Dec 07, 2016 2:29 pm

Re: What are situations to use bare metal when python is so much easier?

Wed Aug 30, 2017 11:27 am

Hey guess what .. 190K firmware to get ">>>" on screen, now if I only knew how to use python :-)
https://ibb.co/dnuEGk

hippy
Posts: 2177
Joined: Fri Sep 09, 2011 10:34 pm
Location: UK

Re: What are situations to use bare metal when python is so much easier?

Wed Aug 30, 2017 1:37 pm

LdB wrote:
Wed Aug 30, 2017 11:27 am
Hey guess what .. 190K firmware to get ">>>" on screen, now if I only knew how to use python :-)
If you have an input device the next thing would be typing: print("Well Done!")

Without, I'm not entirely sure how one proceeds.

LdB
Posts: 551
Joined: Wed Dec 07, 2016 2:29 pm

Re: What are situations to use bare metal when python is so much easier?

Wed Aug 30, 2017 1:47 pm

Why is it I get the feeling the next thing I have to do is get the USB online :-)

There is a couple of issues with alignment of the bytecode emitter as well .. sigh

So the console version of this is what you want?
https://www.youtube.com/watch?v=5LbgyDmRu9s

hippy
Posts: 2177
Joined: Fri Sep 09, 2011 10:34 pm
Location: UK

Re: What are situations to use bare metal when python is so much easier?

Wed Aug 30, 2017 5:25 pm

Yes, 'the same as PyBoard but using a Pi' is a good place to start.

UART input and output is probably easiest to start with, possibly teeing output to the screen console as well as you have that. One could hack getchar() or whatever passes for that to get some commands into it as if typed for testing.

The micro:bit also uses MicroPython but, at least using the Mu editor/IDE, does things slightly differently in addition to having a serial REPL console. AIUI that takes a pre-compiled MicroPython '.hex', appends the program source to that, throws the whole lot at the micro:bit where it boots, reads the source and executes it.

I think I would actually prefer that. Something which allows Python code / files to be appended to a MicroPython kernel.img, copied to SD card, then taken to the Pi, booted, runs. Not sure how one gets error feedback etc and there are many other issues I've never really thought about; how to support multiple source files, modules, packages.

It might be worth starting a new thread so others interested and more experienced might be able to join in and provide better answers than I can.

Many thanks for the effort you have put in.

StevoD
Posts: 8
Joined: Tue Aug 29, 2017 11:37 am

Re: What are situations to use bare metal when python is so much easier?

Thu Aug 31, 2017 11:08 am

LdB wrote:
Wed Aug 30, 2017 11:05 am
I will do an EGL post later when code is up, you don't need to really know the lower stuff with EGL because it is a standard on its own. The complication is unless you have played with OpenGL 3.0 or above it will probably do your head in as it's nothing like normal graphics.

So the problem isn't just baremetal CPU work, they then have to have experience playing around with modern OpenGL or EGL without a framework. You do not want to be trying to wait for someone to port the frameworks to baremetal because it isn't going to happen.
Sorry but I don't get what you are saying.

Rpi only does GLESv2 so if you have made EGL work then we should be able to make GLES work too, nothing to do with OpenGL 3.0 or above.

LdB
Posts: 551
Joined: Wed Dec 07, 2016 2:29 pm

Re: What are situations to use bare metal when python is so much easier?

Thu Aug 31, 2017 2:43 pm

You need to do some more reading
https://en.wikipedia.org/wiki/OpenGL_ES
OpenGL for Embedded Systems (OpenGL ES or GLES) is a subset of the OpenGL computer graphics rendering application programming interface (API)
OpenGL ES 2.0 was publicly released in March 2007. It is based roughly on OpenGL 2.0, but it eliminates most of the fixed-function rendering pipeline in favor of a programmable one in a move similar to transition from OpenGL 3.0 to 3.1
Perhaps rethink about what you said in that last statement. So you also know for future reference GLESv3 = OpenGL 4.3 and GLESv1 - 1.1 = OpenGL 1.5. So are we clear GLES and OpenGL are the same thing just different version numbers and I am not sure anyone could argue any different. GCC an MSVC differ slightly on names, version numbers and minor stuff but both are still C compilers :-)

I will often just refer to them as EGL because they have a common API
https://en.wikipedia.org/wiki/EGL_(API)
Technically the OpenVG part of the specification isn't common because Windows, IOS, Linux etc have there own equivalents. It isn't used much in the industry and so usually if you see common term EGL people are meaning the common GLES/OPENGL API (It is covered in acronym in that wiki entry). In the linux world I get confused because they define EGL as "Embedded-System Graphics Library" something that is meaningless to me. Perhaps you can tell me what it is in linux and if it is the same thing. I have seen several things on this forum about EGL which had made we wonder if there is something different in the linux world because they were blatantly wrong in the windows world. So perhaps EGL has multiple meanings. My use of the acronym comes with a version 1.2, 1.5 etc which would be unsaid but implied.

In my programming world outside the Pi I have no OpenVG and EGL = GLES = OPENGL the only thing that changes is the version number and a couple of the names for the same thing. As per above I don't know if that is universal, I have seen some funny statements on the forum. However you now get the context I make the statement and it's true enough in my world and akin to whether I am on a GCC compiler, MSC or some other C compiler.

Now as I was saying if you understand OpenGL 3.1 then you understand GLESv2 but actually anything from GLESv1.5 (beta) actually has more similarities than differences. The non accelerated framebuffer and OpenVG is much like the normal windows device context (HDC). So you have this accelerated render context that gets place onto a more classical framebuffer.

Now to be honest it's actualy hard to say GLESv2 is actually not OpenGL 3.1 because there is only a limited set of mandatory functions that OpenGL 3.1 must have and GLESv2 will have all of them. In some ways it's just a naming convention that one is expected to be on an embedded device like a phone and the other on a graphics card.

As I said it would be wise to play with OpenGL3.1+ if you intend to do GLESv2 so you understand it and it's easier on a PC than on an embedded device mainly in the debugging enviroment and documentation and code on the internet. Once you do that you might understand a bit more about what Peter Lemon is doing here and his vertex and fragment shaders are right down the bottom of the code, a feature you should now recognize and covered in tutorial 3.
https://github.com/PeterLemon/Raspberry ... ernel8.asm

It is one of those programming tasks that you learn more by playing with code than trying to read books, and there is no substitute for doing.

StevoD
Posts: 8
Joined: Tue Aug 29, 2017 11:37 am

Re: What are situations to use bare metal when python is so much easier?

Fri Sep 01, 2017 10:28 am

LdB wrote:
Thu Aug 31, 2017 2:43 pm
Perhaps rethink about what you said in that last statement. So you also know for future reference GLESv3 = OpenGL 4.3 and GLESv1 - 1.1 = OpenGL 1.5. So are we clear GLES and OpenGL are the same thing just different version numbers and I am not sure anyone could argue any different
It doesn't matter how you spin the version numbers, there is a stack of code out there that works with GLESv2 on the pi and could be used baremetal if someone could get the GLES interface working.

You are the only person who says they have done this so what do you have working, what have you ported, what tools are you using and can we see it?

LdB
Posts: 551
Joined: Wed Dec 07, 2016 2:29 pm

Re: What are situations to use bare metal when python is so much easier?

Fri Sep 01, 2017 1:39 pm

Rubbish I am not the only one doing it I suspect you just don't know what to search for because of lack of understanding background.
http://jaystation2.maisonikkoku.com/2017/01/
You should be able to find them now because you can search for the right thing. I follow a couple that come from a windows background like me.

What most of us are doing is using the VC4 OpenGL port in the MESA platform as a reference
https://cgit.freedesktop.org/mesa/mesa/ ... vc4_draw.c

This is always an interesting site to ferret around in, the MESA directory is really good (Hint: look at who he works for)
https://github.com/anholt

Anyhow I will have first sample up in the next day or two, I will get more done as and when I can.

User avatar
Paeryn
Posts: 1612
Joined: Wed Nov 23, 2011 1:10 am
Location: Sheffield, England

Re: What are situations to use bare metal when python is so much easier?

Fri Sep 01, 2017 4:54 pm

LdB wrote:
Thu Aug 31, 2017 2:43 pm
I will often just refer to them as EGL because they have a common API
https://en.wikipedia.org/wiki/EGL_(API)
Technically the OpenVG part of the specification isn't common because Windows, IOS, Linux etc have there own equivalents. It isn't used much in the industry and so usually if you see common term EGL people are meaning the common GLES/OPENGL API (It is covered in acronym in that wiki entry). In the linux world I get confused because they define EGL as "Embedded-System Graphics Library" something that is meaningless to me. Perhaps you can tell me what it is in linux and if it is the same thing. I have seen several things on this forum about EGL which had made we wonder if there is something different in the linux world because they were blatantly wrong in the windows world. So perhaps EGL has multiple meanings. My use of the acronym comes with a version 1.2, 1.5 etc which would be unsaid but implied.

In my programming world outside the Pi I have no OpenVG and EGL = GLES = OPENGL the only thing that changes is the version number and a couple of the names for the same thing. As per above I don't know if that is universal, I have seen some funny statements on the forum. However you now get the context I make the statement and it's true enough in my world and akin to whether I am on a GCC compiler, MSC or some other C compiler.
Using the name EGL when you really mean either OpenGL or OpenGLES can be confusing as EGL is the Khronos Native Platform Graphics Interface. It deals with the interface between the Khronos rendering APIs and the native windowing system. If you mean OpenGL then say OpenGL.
She who travels light — forgot something.

LdB
Posts: 551
Joined: Wed Dec 07, 2016 2:29 pm

Re: What are situations to use bare metal when python is so much easier?

Fri Sep 01, 2017 7:20 pm

I am sort of developing that but a lot of this stuff is historic and habit. OpenVG wasn't originally part of the specification and it doesn't exist when we program on windows and the Khronos API is much narrower. I mean it doesn't really matter what the specs say because 90% of the stuff won't be there. I know you will know that but I am pretty sure that many of those commenting don't even realize that, just from what they have said so far.

When you are starting out you will be sitting on the mandatory functions because you won't know how to provide software backup functions. So the limited set you will be on will be common to any of the specs.

I know just from posting exchanges Paeryn that you are highly technical and probably formally trained in this area. I am old and most of this stuff like the GL pipeline didn't exist in my student days. So I have picked all this GL stuff up by actually just doing it. So you know the problem that comes with that, my terminology can sometimes not quite be right. So I have no issues with you picking me up.

User avatar
Paeryn
Posts: 1612
Joined: Wed Nov 23, 2011 1:10 am
Location: Sheffield, England

Re: What are situations to use bare metal when python is so much easier?

Fri Sep 01, 2017 8:20 pm

I learnt GL back when it was IrisGL 20+ years ago (OpenGL had been released at the time but not long). I was taught it a bit but had learnt a lot of it before then in my spare time by playing with it, as I have with most of the programming languages I use. I have a very inquisitive and logical mind and like to learn!

I can be a bit of a pedant at times (and not always right with it) and sometimes I may appear a bit harsh in my words, I think I may have been in my previous post, sorry if I was.
She who travels light — forgot something.

BrewHo
Posts: 3
Joined: Sat Sep 02, 2017 2:56 am

Re: What are situations to use bare metal when python is so much easier?

Sat Sep 02, 2017 3:18 am

helpme wrote:
Wed Aug 23, 2017 11:54 pm
jamesh wrote:
Wed Aug 23, 2017 3:06 pm
helpme wrote:
Wed Aug 23, 2017 12:51 pm


You can run python on Raspberry Pi, yet this is a forum for discussing baremetal programming on Raspberry Pi.
What is your actual question? Why do baremetal at all?
Hi LdB and jamesh,

I guess the question is not well phrased. If there is a problem that can be solved by using python, it makes zero sense to use bare metal. I should have asked "What are things that bare metal can do that python cannot on Rpi? What are some applications that are best suited to be done by bare metal instead of python on Rpi?"

I am ignorant about using bare metal on Rpi. I am asking to get a sense if it is worth acquiring knowledge in Rpi bare metal.
Think of it this way: one application that is much better suited for bare metal than Python is Raspbian.

Some of us like to play where the software meets the silicon. Bare metal is where that happens. Python is a good tool for what it does, but it doesn't do that.

And it's nice to have the build platform and the execution target platform be the same device. It's a pain to build on one device and move code to a different device, which is why the Pi is more attractive than microcontrollers for some things.

User avatar
Gavinmc42
Posts: 1440
Joined: Wed Aug 28, 2013 3:31 am

Re: What are situations to use bare metal when python is so much easier?

Sat Sep 02, 2017 5:30 am

Some links to stuff I had not seen before, thanks.

I don't see a point in reinventing OpenGL/ES or EGL, yet.
For me it is about having unused hardware sitting there when I am doing baremetal.
Not that my idea of baremetal (Ultibo) is that bare any more.

A single line in the manual got me hooked, hardware AA- Anti Aliasing.
The Ultibo graphics console is easy to use as long as you stick to vertical and horizontal lines/shapes.
Using Peter L's control list code for the VC4 VG hardware to draw diagonal lines/edges etc would be handy as the software methods are a little slow.
His code was the first sign I found that baremetal accelerated graphics was even possible.

I don't really get the Vertex/shader stuff yet and the JPEG hardware block looks like it is connected with some propriety software.
I probably only understand a few dozen pages in the Videocore manual and that was only in the last few months.

There is still a Scaler block which could be useful for baremetal. Imagine a GUI, UI that scales to the display.
Sure it could be scaled in software but things like this could benefit from hardware scaling.
https://ultibo.org/forum/viewtopic.php? ... dows#p4966
There does not seem to be much around on the Scaler hardware even in the Android code.

If I was just making one product then a bitmaped UI would be fine but a VG based is even better.
SVG code I actually understand, very similar to HP-GL, Gerber and NC G-code which I have used for decades .
How JPEG works is a little bit like magic to me. But just using a library won't teach me anything except how to use the library.
Using the hardware is a way to learn at a more basic level. Understanding JPEG leads to MJPEG and other video compression methods.

A lot of Eric's effort is going into OpenGL and DRM's, how much is usable for the simple 2D UI's I would like to do first?
It is mostly tied to X11 anyway so is it relevant?

I won't learn any of this using Python etc.
Mind you, understanding more about using the VCOS could really come in handy :lol:
Does VCOS need libraries ie .so, .ko etc? That could be a pain for baremetal.
I'm dancing on Rainbows.
Raspberries are not Apples or Oranges

StevoD
Posts: 8
Joined: Tue Aug 29, 2017 11:37 am

Re: What are situations to use bare metal when python is so much easier?

Sat Sep 02, 2017 9:56 am

LdB wrote:
Fri Sep 01, 2017 1:39 pm
What most of us are doing is using the VC4 OpenGL port in the MESA platform as a reference
Yeah I get it now, I thought you said you were doing EGL and VCOS but you are really just doing direct access to the V3D like everyone else.

That stuff is cool but it doesn't give you OpenGL, unless you end up porting a lot of the Mesa library.

Thanks anyway.

LdB
Posts: 551
Joined: Wed Dec 07, 2016 2:29 pm

Re: What are situations to use bare metal when python is so much easier?

Sat Sep 02, 2017 4:43 pm

Yes but you need that for frame animation because it links to the VC4 threads. There is also other dynamic resources that get passed to the VC4 from things like media players. What I ultimately want to do is be able to play mpeg and avi the normal opengl implementations. Mapping what functions are implemented is always the start point and working out which ones I will need to provide. OpenGL/GLES whichever you want to call it covers static frames, text, fonts, video and stuff we haven't even talked about like the GLFW extensions.

Now why GLFW is interesting is because
1.) It carries it own thread library called TinyCThread (In baremetal where we have no OS ... so attractive)
2.) It only uses OpenGL 3.2 core functions so is highly like to work on the PI
3.) It supports another interesting spec (https://www.khronos.org/registry/vulkan/) which means we might be able to use vulkan shaders on the Pi

So again we can cross code from windows to the Pi and try that
http://blog.biicode.com/raspberry-pi-cr ... index.html

You can see the result ... so now we have another pile of public source code we know works.
https://github.com/glfw/glfw
However you will also note the last comment that the default renderer is too slow and so they were going to switch to the GLESv2 renderer. Now I don't know if anyone has done GLFW with the GLESv2 renderer that is on my todo list.

The problem is OpenGL is a vast specification and this is just stuff I have looked at. There are probably at least 3 or 4 more other ways into baremetal video acceleration and they all need to be looked at.

Return to “Bare metal”

Who is online

Users browsing this forum: No registered users and 7 guests