Earlier quoted context omitted.
Side note, but someone linked a great talk by OS researcher Timothy Roscoe the other day about a) the increasing heterogeneity of our computing devices, b) Linux's inability to really support same, and consequently c) Linux being used on the device, because the device has to "run Linux", but in increasingly smaller and more walled-off spaces, leaving board management which you'd normally think of as an "OS task" to d…
Yet Windows ran 16-bit, 32-bit and 64-bit code on the same core for years. Huh. Really folks. It doesn't take new research or exotic OS design ideas, to do something that has been common practice for a decade. Let's quit pretending linux is driving any innovation. It's followed behind in OS design, often by years.
The $8 Linux Computer
91–100 of 166 posts
Re: The $8 Linux Computer
#92I don't get it. We've had fully functional ARM based Linux boards in this form factor for a few years now, such as the Nano Pie Duo. So it's $15... https://wiki.friendlyelec.com/wiki/index.php/NanoPi_Duo
The interesting thing about this is that it's a RISC-V machine, at least for me. A few years ago RISC-V dev boards were much more expensive than their ARM counterparts, nowadays they still are but are getting closer in price parity.
I think they are positioned to be the new low-cost esp32 variant.
Re: The $8 Linux Computer
#93Earlier quoted context omitted.
Zigbee? My man, ESP32 boards get you 802.11 WiFi for like $5 these days. Zigbee is the kind of protocol designed for even simpler, more power efficient microcontrollers. Think closer to a $1 microcontroller instead. There is a reason we have lol WiFi light bulbs. The uC that powers the smarts are really cheap these days.
AFAICT your home-grade wireless router / AP will start having trouble when you have dozens of Wi-Fi devices actively working in your home. ZigBee is somehow more resilient. It's also much lower energy, more comparable to Bluetooth, but much longer range: the sweet spot for smaller battery-powered devices. OTOH I remember that ZigBee is somehow more buttoned-up than BT and even wi-fi, so it's not commonly seen on like…
Re: The $8 Linux Computer
#94Earlier quoted context omitted.
Wooha, thats kind of awesome. Does this mean you could make your own zigbee sensors or whatever?
I would think that Zephyr would be better suited for this. Linux is great for many things, but it can also be overkill.
Re: The $8 Linux Computer
#95Soon enough, it will be the even smaller $1 Linux computer.
And then, the even smaller $0.10 Linux computer.
In the future, even toilet paper will be running Linux.
Re: The $8 Linux Computer
#96Earlier quoted context omitted.
Zigbee? My man, ESP32 boards get you 802.11 WiFi for like $5 these days. Zigbee is the kind of protocol designed for even simpler, more power efficient microcontrollers. Think closer to a $1 microcontroller instead. There is a reason we have lol WiFi light bulbs. The uC that powers the smarts are really cheap these days.
AFAICT your home-grade wireless router / AP will start having trouble when you have dozens of Wi-Fi devices actively working in your home. ZigBee is somehow more resilient. It's also much lower energy, more comparable to Bluetooth, but much longer range: the sweet spot for smaller battery-powered devices. OTOH I remember that ZigBee is somehow more buttoned-up than BT and even wi-fi, so it's not commonly seen on like…
Re: The $8 Linux Computer
#97Show me one with an integrated serial adapter and I'll buy it. I know how to generally program things via UART, but really would prefer not having to bother with it. It's not a great development experience. Pine64 keep making these silly little mistakes limiting their products' appeal.
Re: The $8 Linux Computer
#98Earlier quoted context omitted.
Wooha, thats kind of awesome. Does this mean you could make your own zigbee sensors or whatever?
I would think that Zephyr would be better suited for this. Linux is great for many things, but it can also be overkill.
Re: The $8 Linux Computer
#99Earlier quoted context omitted.
AFAICT your home-grade wireless router / AP will start having trouble when you have dozens of Wi-Fi devices actively working in your home. ZigBee is somehow more resilient. It's also much lower energy, more comparable to Bluetooth, but much longer range: the sweet spot for smaller battery-powered devices. OTOH I remember that ZigBee is somehow more buttoned-up than BT and even wi-fi, so it's not commonly seen on like…
I think zigbee is more "resilient" because it piggybacks off all the other zigbee devices via mesh instead of each device talking to the central router.
Re: The $8 Linux Computer
#100Earlier quoted context omitted.
The difference is that with RTOSes you typically link the application together with the OS, whereas with Linux you can dynamically load applications at run-time.
This is a big deal to me. What's stopping normal microcontroller platforms like Zephyr from providing dynamic loading of programs? It'd be great for iteration to have a solid OS that cares about networking and updates and a an application layer you can move fast and break things with without risking soft-bricking your device. I'm currently finding this with interpreted platforms like Espruino and Micropython, but don…
https://docs.micropython.org/en/latest/zephyr/quickref.html
Very weird seeing the Zephyr booting message I've seen so many times followed by the micropython repl startup message I've seen so many times.
Hard to think of a good app for that topology. In the sense that I could stick circuitpython or micropython on a ESP32, or zephyr on a ESP32, so an app running both would get me ... ?
Conceptually, the *python people "could in theory" give up on porting to infinite number of new boards and focus really hard on working under Zephyr, and let Zephyr worry about porting to infinite number of new boards.
The idea of upgrading my MicroPython under Zephyr under MCUboot under Eclipse hawkBit over the wifi is pretty intriguing sounding challenge.
I have not dug into this technology stack other than recreationally. I'm a little unclear how interop works beyond the existing example of passing simple hardware pins thru. For example if MicroPython had a library that interop directly with the Zephyr RTOS features, that would be quite handy. Another thing I notice is the interop in the docs is simple pin pass thru, hard to even imagine how Zephyr's wide variety of networking stacks would pass thru for Python to use. It looks like there is nothing developed at this point where the uC could run a RTOS thread to "do stuff" while a MicroPython thread handled a wifi UI or UI in general or handled the non-RTOS tasks, although that would be cool.