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.LdB wrote: ↑Tue Aug 29, 2017 3:36 amSo 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.hippy wrote: ↑Mon Aug 28, 2017 7:11 pmI 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.
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 -
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.
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.
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.
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.
Sorry but I don't get what you are saying.LdB wrote: ↑Wed Aug 30, 2017 11:05 amI 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.
OpenGL for Embedded Systems (OpenGL ES or GLES) is a subset of the OpenGL computer graphics rendering application programming interface (API)
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 compilersOpenGL 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
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.LdB wrote: ↑Thu Aug 31, 2017 2:43 pmPerhaps 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
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.LdB wrote: ↑Thu Aug 31, 2017 2:43 pmI will often just refer to them as EGL because they have a common 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.
Think of it this way: one application that is much better suited for bare metal than Python is Raspbian.helpme wrote: ↑Wed Aug 23, 2017 11:54 pmHi 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.
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.
Users browsing this forum: No registered users and 3 guests