Great idea that will never happen!
-
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. :mad:
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.)
-
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. :mad:
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"
-
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. :mad:
To err is human. Fortune favors the monsters.
-
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. :mad:
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
-
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.
-
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"
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.
-
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 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.
-
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.
The RP2040 boards are not an Arduino though (albeit there do exist tools to utilise the RP2040 from the Arduino IDE and etc.) and the PIO module is much more than just another bank of GPIO. It totally can drive HDMI (well DVI) - GitHub - Wren6991/PicoDVI: Bitbanged DVI on the RP2040 Microcontroller[^] though the more usual way to get video out of one is to drive VGA since the dot clock is a lot slower: GitHub - raspberrypi/pico-playground[^] see the "scanvideo" section there.
-
The RP2040 boards are not an Arduino though (albeit there do exist tools to utilise the RP2040 from the Arduino IDE and etc.) and the PIO module is much more than just another bank of GPIO. It totally can drive HDMI (well DVI) - GitHub - Wren6991/PicoDVI: Bitbanged DVI on the RP2040 Microcontroller[^] though the more usual way to get video out of one is to drive VGA since the dot clock is a lot slower: GitHub - raspberrypi/pico-playground[^] see the "scanvideo" section there.
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.
-
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.
-
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.
-
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.