Unihiker, an $80 single-board PC with 2.8“ touchscreen, quad-core ARM Cortex-A35

I think I too was drawn in by the performance claims made by those other manufacturers. I realized though that raspberry pi are very powerful computers. We just take the scale of modern computing for granted and our software is the real problem.

To be totally fair to the up-and-coming boards, the Pi was pretty poorly supported on day 1 and the community did (and still does) a lot of heavy lifting. I’m still waiting for a contender, but I don’t have the time or energy to devote to another SBC.

Despite being a super prolific maintainer of Pi-stuff and related projects I haven’t had a single SBC manufacturer reach out to me and say “hey what do you need to support this?” They just don’t seem to care beyond shoving product out the door and hoping for the best.

As it turned out, I spent a couple of hours messing around a bit with some device tree configuration to make it work with the peripherals on their custom carrier and a bit of `make menuconfig`… and it booted right up on Linus’ tree.

ARM isn't to blame; it's that no one company was big enough to set the standard (and let others clone it) for ARM systems unlike what IBM did with the x86/PC, which is not surprising given how diverse ARM's cores are.

The original ARM chips, as in the Archimedes era, obviously ran in things that broadly resembled the other desktop computing platforms of the era.

They had to solve the same problems: deciding which device to boot from, how to initialize the attached grab-bag of peripherals. They also had a long series of models with varying capabilities and integration.

So they must have something comparable to a BIOS/EFI/Open Firmware-- a standardized hardware enumeration and bringup process.

Somehow that disappeared when ARM moved away from RISC OS "desktop computers" and went into the microcontroller world. Why?

I figured it probably either had to do with licensing, or an assumption that an embedded ARM core in some random device would only ever be used with a particular bag of peripherals, so there was no need to rely on conventions.

$30-150 AUD

The only concern I have is power consumption being orders of magnitude higher than modern SoCs

Will this device be able to load any web page in one or two decades? It would likely be slow, but the impossibility would be a pure software limitation.

Because there are no schematics or data sheets posted on that page. Good luck bring up anything else on it…

For something intermittently used like a game box that might not matter. For IoT-focused hardware that is connected to the internet continuously by design where, say, a malformed TCP packet could cause a buffer overflow in the network stack that wiggles it's way into root code execution by chaining through a bunch of unpatched vulnerabilities on a "never updated again" system? That's a problem.

Few years ago, you built a weather station. Sadly, the weather backend you had was discontinued. You found a great new one, and it even comes with SDK and sample code! Sadly, the SDK requires python 3.8 or later. Does your device support it?

Few years ago, you built the home automation server. But recently, you got the set of remotely-controllable disco balls for each room which use FOOBAR protocol. Good news: Linux kernel supports FOOBAR protocol since 5.14. Bad news: your device kernel is much older.

Few years ago, you built the smart controller. You don't want to manage your infra, so you decided to go with AWS IOT, it is super each if you only have a few devices. But AWS announced they are dropping AWS IOT.. does your OS support newer system?

There are definitely cases when you set up the device once and never have to touch it again, but there are also a lot of networked things out there, and you often want to control them..

Second, embedded systems have reliability requirements. Something will not work and will need support and updating to fix. The big advantage of normal distribution is that somebody has probably already fixed it.

Third, devices get repurposed. My five year old Raspberry Pi has had multiple jobs, and when it is done running Home Assistant, I'll find some other use. Plus, with normal distribution, I can easily install the packages I need.

But we got of TVs that are now useless because originally they just needed to "display a simple web page" but:

* no new TLS support, near-everything dropped old TLS

* sites that did not, use CA that's not on the device's list

I’ve also tried Yocto and Buildroot and frankly they’re not that great. Yocto’s build system is so complicated it could take months to fit all your custom layers together to get a working image. Every vendor of every layer has their own conventions and you have to manage patch sets on top of patch sets to get some things working. Buildroot works better but still has a rigid vision for what an embedded Linux system looks like and how it fits together.

The beauty of Linux is that once you get to libc the interface is identical no matter what board you’re using so there’s no reason to build everything from source. And if you want something like Yocto you’d be better off building rpm or deb packages from a basic layer and then using eg multistrap to build a root filesystem.

You simply assumed there is "no excuse" because you couldn't think of one, but you weren't in the room when the decision was made, and don't know the reasonings behind it. My blurb above could certainly have been one of several reasons brought up.

You can choose not to agree with the decision, that's fine, but you're attributing a whole lot of malice to what is ultimately a decision they made based on factors which you are not privy to.

It didn't exactly spark joy, which these side project tinker tools should, in my opinion.

Lugubrious, heh.

Well, slightly worse, as A35's are smaller and lower power than the A53's in something like the pi zero-2, but also slower. The devices slight clock advantage probably doesn't make up the difference.

So, its probably a great embedded system, but it should be running something lighter weight than a normal linux distro. Otherwise it becomes like all these gas station pumps, point of sale terminals that all seem to take 10+ seconds to do things that older devices didn't lag and pause with.

> they are microcontrollers optimized first and foremost for cost and power efficiency

ESP32 is only optimized for cost. Other wireless MCU are significantly lower power... they are just more expensive (and tend to have worse docs then ESP32).

Oh, is that what those round things are. From the picture it looks like they're big pins.

That's a very accurate description of DFRobot. I like their products though. My philosophy for my freelance gigs is that if I have to custom-design hardware, I'm doing something wrong. Hardware development has become a sucker's game. So companies like DFRobot that basically give me "a function on a PCB" get my money. That $10 product can save me days of work!

Of course, applications would respond shit slow this way, but in the case of a DB it'd be more than fine, no?

I also wonder if they'd even know what to ask.

If you can already code, then GPT can ramp you up on a new project faster, or accelerate and existing project

I was raised with (80s/90s); never break the public api unless you have to and make a migration path if you do; now it is ‘let’s definitely break the public api, with any minor version change and just waste everyone’s life fixing it, we don’t care’. And gpt doesn’t know this. It usually does make up code that’s close to correct and relatively easy to fix though, but you need to know how to read the docs and not panic that actually everything is spitting errors.

If you ask it for C, Java or vanilla js it fares better but there you suffer from the memory window; now with 16k tokens, we are seeing massive improvements. The api deprecation (read; we just throw away or change without warning) issue remains and is a huge issue; I cannot even see how they would properly fix that in LLMs. They are going to have outdated versions in their search space; how do they know to ignore them? And next to that there are the hallucinations.

To me, it's like a junior developer I have to coach constantly.

The result is definitely not something you'd want to maintain and probably has built in inefficiencies and edge cases I don't know about but it did it's job, which was to do the thing I wanted it to do so I can go on with my work.

The problem was that there were breaking API changes across versions of the library, but it was just using probabilities of method names being correct, and it didn't ask me or tell me which version of the library it was targeting, so it was just a mismash of incompatible code.

But the code LOOKED good and the AI was confident it was a good answer. Overall, it felt like wasted time sifting through confidently-wrong answers.

it works ok as a starting point of " I have no freaking clue how to approach this" to "ahh I can see how that will work" and then you go write your own code with the lead.

You will feel a world of pain when there is some bug, and it will take you 8 hours to figure out the issues so that you can turn your lights on. The simplier, the better for these kinds of applications.

More like an Android tablet than a phone.

If you get a old iPhone and buy a replacement battery still more than likely be cheaper than buying a Rpi + screen + lipo-hat + battery.

I do my development in VSCode using platformio with the Arduino framework and FreeRTOS. It is really convenient to have the same os and framework used for all the MCUs of a project. That's why I use the 2$ stm32 instead of a 1$ stm8.