|
Kevin bless the ARM Cortex A family.
As soon as you're using one, you basically need to run linux or android.
Particularly if it does HDMI and has a GPU.
I've been combing through ZephyrOS's compatibility, and there's nothing useful.
Even if there was, nothing would support HDMI and a GPU.
ZephyrOS+LVGL+Arm Cortex A53+Mali GPU would be a winning team.
Instant boot. Nice, modern looking UI. Very little DDR3 ram required, and the whole thing could fit on hundred megabits of flash or so for even the most involved applications.
It's what I want. I know how to wire the hardware now. Those SBC thingies are actually easy to wire up. The trick is messing with BGA (so I'd just leave it to the professionals)
The problem is the software. ZephyrOS doesn't support it, and LVGL doesn't support OpenGL 2D acceleration, though I could probably implement that. The issue is no driver level support for the HDMI facilities of these chips. I wouldn't know where to begin.
I need a friggin team. This needs an open source project. But yeah. Far be it from me to think I can get any traction on something like that without an initial offering to show people.
And getting from here to there? It may as well be the moon. I probably won't live long enough if I had to do it on my own. I don't have enough man years left in me.
Why isn't there something - if not this - some kind of parallel out there? The use cases are endless. The predictability of such a package compared to something linux or android based - there's no comparison. The former is more predictable, real time, more testable, and has less boot time (almost none) and far less resource requirements.
It would make building smart machines so much less expensive, both to build and maintain an ongoing product. They would be less "crashy" - they would be less impossible to flowchart, if you needed to do that.
These damned things can run webkit, sure, but what if you don't need all that, don't want it, and don't want to pay for it?
This is a software problem, ultimately. That's what kills me. It's solvable. I just can't do it myself. 
To err is human. Fortune favors the monsters.
|
|
|
|
|
If someone has built an Android smartphone or tablet around it (or one of its close cousins), then there is an appropriate hardware abstraction layer for Linux out there for it. I would look for companies that produce development boards for such devices and see if the software for the development board is downloadable in source code form, possibly after registration.
You probably (certainly?) won't be able to use the code in a commercial product, but at least it'll get you running.
Your Google-fu for this sort of thing is probably better than mine.
Freedom is the freedom to say that two plus two make four. If that is granted, all else follows.
-- 6079 Smith W.
|
|
|
|
|
So far the only "source" I found was for the linux images, but rather than source, it's a collection of binary blobs and scripts.
I'm not sure if the source code for say, the Orange Pi Zero 2 is available at all, despite these being supposedly open source.
To err is human. Fortune favors the monsters.
|
|
|
|
|
It might have a bit of a heavy footprint, but would RiscOS fit the bill?
|
|
|
|
|
I doubt it. I mean, getting an RTOS running on an ARM Cortex A53 is one thing. Getting it running on the H3 SBC that the ARM Cortex A53 is embedded in is another story.
I can pretty much guarantee RISC OS doesn't support an AllWinner H3 or an H616. At least not the peripherals on it, like HDMI
To err is human. Fortune favors the monsters.
|
|
|
|
|
I missed the start of this, but I sense from the wording this may be part of an ongoing "question"...
How much processing oomph is needed?
If it is not too much, is the RP2040 chip enough? (As featured in the Raspberry Pico and various Adafruit boards, etc.)
It has a couple of Arm cores, some RAM, some Flash and a bank of PIO - this last bit is the interesting bit: in my head it's like a little bit of FPGA, but in any case you can program it (in a C-like language) to off-load intensive operations from the CPUs.
The crux here being that folks have programmed the PIO to drive HDMI displays and so forth...
TBH, I've never used the PIO to drive HDMI, but I have used the RP2040 in a number of projects and it's been surprisingly good. I've only ever used the C-SDK, but there's support for various embedded-Python dialects too, they tell me.
The C-SDK also includes ports of LWIP (for Ethernet stuff) and TinyUSB (for USB host or device stuff) amongst other libs.
I've not used LWIP on this (have used it on other boards in the past; worked well but its API is quite unlike BSD-sockets!) but I have used the TinyUSB a fair bit and was surprised by how well it worked (mainly because I found, and still find, the API confusing and was surprised when my prototype actually worked at all!)
Also, cheap as chips* (*or other item idiomatically identified as low in cost by your respective cultures.)
|
|
|
|
|
PIO can't handle this.
Nothing Arduino capable can drive a 40 pin dot clk display, AFAIK.
To err is human. Fortune favors the monsters.
|
|
|
|
|
|
I'm not bitbanging HDMI. Bitbanging something doesn't even count. You can bitbang just about anything in theory, but that doesn't mean it's "supporting" it. You're basically hacking at that point, and using up CPU cycles to do something that should be done in hardware and *is* done in hardware on an SBC.
The RP2040 cannot drive a 24-bit color 40 pin dot clk display. It just can't. And doing it by bitbanging HDMI and using up all my cycles on that is not realistic.
It calls for hardware that's actually meant for it.
The RP2040 is not.
And PIO cannot be used to program against most Arm Cortex A based SBCs. There are not even board entries for them.
To err is human. Fortune favors the monsters.
|
|
|
|
|
I agree that avoiding Linux would be very elegant. But I fail to grok why Linux is a showstopper. Crashy Linux? Really?
There are also people talking about Yocto Linux. "Highly customizable" say the fanbois, "But dodgy AF toolchains" say others. Me, I am deploying on 64 core monsters, so all this is just speculation, and curiosity.
"If we don't change direction, we'll end up where we're going"
|
|
|
|
|
If you're thinking embedded: The machine runs a single fixed set of functions. You don't load arbitrary new executables at run time into an embedded system. Like any specific Linux executable, it utilizes a tiny little speck of the total Linux offering.
An IoT runtime such as Zephyr is split into tiny functional fragments, and only those fragments actually referenced by the embedded code is linked into the image for the embedded system. The OS footprint may be surprisingly small.
A Linux system is prepared for additional new executables being loaded at run time. It must include all the functionality that these executables might request. In a standard Linux system, the unused code may reside on disk, but most embedded systems have no disk. So all the code that might be requested at some future time must be loaded to flash or to RAM from an external source at every restart (and then the external source must be available!).
Linux, at least some distros, are quite configurable. Yet the flash/RAM footprint is very much higher than for dedicated embedded OSes. Maybe the configurability does not include removal of any OS reference to e.g. disk or memory management system - smaller embedded CPUs may be without a MMS. You might say that this careful shaving of standard Linux to leave only what your specific embedded functionality needs is exactly what those providers of special embedded OSes (such as Zephyr) has done for you. (Note: I do not know whether Zephyr is based on pieces of Linux code or completely independent.) They may have shaved off some core code needed for drivers hardly ever used by embedded systems - the UI is typically based on pushbuttons and dials, LED indicators and small b/w (no gray!) low resolution LCD panels. Drivers are typically tailor written - the general driver architecture much too general to fit in.
HDMI is not a typical UI device in embedded systems! You may write a HDMI driver (assuming that required hardware is available), but I suspect that Linux HDMI drivers lean heavily on the standard driver architecture, assuming that a lot of functionality is handled by standard code.
ARM started out as embedded CPUs, and the smaller models are still used for that purpose. AArch64 is certainly not aimed at the embedded market. Running Linux on a 64-bit ARM is fully possible, and has been running on countless ARM based machines for years. They are not embedded systems, but general Linux machines. If that is your kind of system, maybe with a few gigabytes of RAM and many gigabytes of disk, then go for Linux, and you will have lots of drives for all sorts of peripherals.
My impression is that the OP leans much more towards the embedded side, and a full Linux is like shooting sparrows with cannonballs.
|
|
|
|
|
Any full fledged OS is going to be harder to guarantee and verify than an RTOS.
When I say "crashy" it's relative. In this case relative to an RTOS, linux is much more likely to fail in unpredictable ways.
To err is human. Fortune favors the monsters.
|
|
|
|
|
honey the codewitch wrote: Particularly if it does HDMI and has a GPU.
I've been combing through ZephyrOS's compatibility, and there's nothing useful.
I thought that you were the one writing such drivers. Maybe I got it wrong. 
|
|
|
|
|
I've built more esoteric tool chains in the past, and I've been looking out for a cost-effective entry into the space for a long time.
How much do you want for wiring up 2 sample boards and shipping them to Belgium?
|
|
|
|
|
Maybe shipping and materials, but I am so far from developing a board file yet that I'd advise you not to hold your breath waiting. 
To err is human. Fortune favors the monsters.
|
|
|
|
|
The offer stands, and it won't expire any time soon.
I like the occasional challenge, and work very independently / won't bug you.
Also happy to sign whatever makes you feel comfortable, should that be a factor.
I could work with just a BOM, mind you, but it would need to include the basic stuff like power supply specifics, since I'm decent at bread board prototyping, but historically terrible at hooking them up to a power supply.
Smoke is typically an issue.
|
|
|
|
|
I deliberately chose chips that come on banana pi and orange pi boards so that I could use those to prototype firmware, and so that I had a baseline design.
For example, my H3 chip setup can be prototyped on with a Banana Pi BPI-P2 Zero
My H616 setup can be used with the Orange Pi Zero 2 board.
Only thing is, these boards have more peripherals, like wifi and bluetooth, than will be on any final product. But that's fine, it's just a matter of not using the equipment that won't be there.
I hope I made sense.
To err is human. Fortune favors the monsters.
|
|
|
|
|
Yes, thanks, that both makes sense and is very helpful. 👌
I'm off in a couple of days and then I'll look into it.
I might come back with some follow up questions if I can't figure out the specific versions.
|
|
|
|
|
Wordle 674 4/6
⬛⬛⬛⬛⬛
⬛⬛🟨⬛🟨
⬛🟨🟩⬛⬛
🟩🟩🟩🟩🟩
|
|
|
|
|
Wordle 674 3/6
⬜🟨🟨⬜⬜
🟩⬜🟨🟩🟨
🟩🟩🟩🟩🟩
|
|
|
|
|
Wordle 674 3/6*
⬜⬜🟨⬜⬜
⬜🟩🟩🟨⬜
🟩🟩🟩🟩🟩
"I have no idea what I did, but I'm taking full credit for it." - ThisOldTony
"Common sense is so rare these days, it should be classified as a super power" - Random T-shirt
AntiTwitter: @DalekDave is now a follower!
|
|
|
|
|
Wordle 674 4/6
⬜⬜⬜⬜⬜
⬜🟩🟨⬜⬜
⬜🟩⬜🟨🟨
🟩🟩🟩🟩🟩
In a closed society where everybody's guilty, the only crime is getting caught. In a world of thieves, the only final sin is stupidity. - Hunter S Thompson - RIP
|
|
|
|
|
Wordle 674 3/6
⬜⬜🟨🟨⬜
⬜🟨⬜🟩⬜
🟩🟩🟩🟩🟩
Software rusts. Simon Stephenson, ca 1994. So does this signature. me, 2012
|
|
|
|
|
Wordle 674 4/6
⬜⬜🟨⬜⬜
⬜⬜⬜⬜🟩
⬜⬜⬜🟨🟨
🟩🟩🟩🟩🟩
|
|
|
|
|
Wordle 674 3/6*
🟨⬜🟨⬜🟨
🟩🟩🟩🟩⬜
🟩🟩🟩🟩🟩
Happiness will never come to those who fail to appreciate what they already have. -Anon
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
