As usual, looks good on papier but no ecosystem and the current stack that it comes with is dead on arrival.
Boards need to come with mainstream distro support or with an ecosystem (or both), otherwise it will just die. And with internet connected devices, you can't set-and-forget, so it needs to have live support.
Edit: a RockPi S (same SoC) can be had for $35 and a touch LCD for $11... Granted, it doesn't come with the same integration and headers, and doesn't have a microphone by default, and no RISC-V MCU. But the point of integration is a useful product that stays useful, and it doesn't if there is no ecosystem.
As for 'adding' mainstream support, it takes quite some effort and active ownership. Out of the many rockchip boards and add-ons this is the set that made it to some level of standard inclusion: http://ftp.debian.org/debian/dists/stable/main/installer-arm...
Assuming it's small enough for your needs, a used Intel NUC can get you loads more mileage than pretty much any ARM SoC at an equivalent price.
Currently available on eBay:
* $49.95 for an i5-5300U at 2.3GHz, 4GB of RAM, and 128GB of SSD storage
* $89.00 for an i3-7100U at 2.4GHz, 8GB of RAM, and 256GB of SSD storage
* $135.00 for an i7-5557U at 3.1GHz, 16GB of RAM, and 256GB of SSD storage
...all loaded with ample driver support, extensive connectivity options, and bog-standard x86-64 instructions.
Obviously, there will always be use cases that call for a tiny ARM SoC and nothing else, but plenty of the applications for which people will buy an ARM SoC (e.g., Kodi/Jellyfin/Plex/Emby media centers, RetroArch gaming machines, Minecraft servers, streaming servers, web servers, network filtering, seedboxes, etc.) are better served by a used Intel NUC.
Wait, NUCs are that cheap? I would appreciate a link so that I can get my hands on one. I don't use eBay often and filtering feels terrible on their site.
Not a NUC, or your parent poster, but I picked up a Dell Wyse 7020 thin client for ~$35 + shipping from a recycled electronics vendor in Pennsylvania. EPC here in the USA is an electronics liquidator / off-business-lease seller.
Of course, I'm still trying to figure out exactly how to upgrade it and if it will replace my trusty RPi4, but I prefer fanless designs where possible, especially for 24/7 usage.
It can also help to search for specific business computer models on eBay, as small vendors doing electronics liquidation may just read the model number on the unit, take a picture, and fling it up on the store page in the "priced to sell" price bracket.
https://www.servethehome.com/tag/tinyminimicro/ has a list of small servers they have reviewed, so that can help with getting an idea of a computer's capabilities, upgrade paths, or gotchas (e.g. not supporting more than 8 GB of RAM or something).
It's not too bad. I usually filter by US only, used but not for parts, then it has pretty decent search syntax like "Intel NUC (i5,i7) -parts" and you can keep adding "-unwanted_terms" to get the query down to something more selective.
Some of the low price NUC like things found on eBay are missing things like a 19vdc 4.5A external power supply, so expect that unless it's clearly called out in the auction.
I purchased a few ARM boards in the past and won't do it again. All became e-waste.
Rockchip notably, great hardware on paper. Try developing something that needs hardware acceleration and it's a paper weight.
It's a common cycle of broken promises to provide drivers by manufactures, rinse and repeat. The exception being raspberry pi or expressif. Depending on the application.
I've had the same experience with non Raspberry Pi boards. They've become useless thanks to endlessly broken software and zero support. My rpi's have been useful for years and are still getting regular updates.
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.
Yup. It's RPi or nothing. It's the software that makes these valuable, not hardware specs. If I wanted to sell an ARM board I'd make it as Pi compatible as possible.
They’re less popular in the hobby world, but the Freescale/NXP i.MX6 family has absolutely fabulous mainline Linux support. There’s still a Freescale tree, but for most functionality you don’t need it. A few years back a client of mine needed some other functionality that wasn’t available in the version that Freescale forked for their tree and they wanted me to come in and assess what it would take to backport the driver they needed or basically make our own fork that forward-ported whatever Freescale mojo was needed.
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.
I’m still trying to get a Rock 5B to boot from NVMe. By all appearances they included a USB Type-C port that doesn’t work, so the system never pulls sufficient power not to boot loop. Apparently even after a firmware update.
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.
If You have not tried what the other reply-post suggests (dumb brick), I have a 5V 4A dumb brick I can loan for a quick test. Seattle area. It has worked on quite a few boards here. Or purchase one from where-ever, they are really useful outside of SBCs (though they are usually 5.3V and 4.xA, so watch out with sensitive parts).
Sounds like a USB power supply that doesn't do any power negotiation and just gives as much current over 5V as it can handle. Those things typically top out at 2.4A so not really sure where you'd get one that could do much more.
You need to get a dumb brick for that Rock 5B. Looks like you got one of the ones with a bad firmware. When it negotiates the power drops out. There're tons of forum posts.
You're actually answering your own question here ;-)
Because a SoC with limited CPU-core resources can't do everything in software, the chip contains many system components (hence System-on-Chip or System-on-a-Chip) that handle things the CPU cores then no longer need to do.
Think protocol handling or memory; instead of spending many clock cycles on handling the USB bus, you can leave that to the USB controller and only deal with what is actually relevant to your USB device. Same with the VOP (Video Output Processor) block, instead of spending many clock cycles on putting the right bits in the frame buffer you tell the VOP that you'd like the background to be orange and then only spend time setting the right bits for black text (for example). So instead of having to deal with many millions of bits, you only have to deal with less than 1% of them because every bit you don't set becomes orange. For other things like I2C, I2S, DMA, networking, cryptography, SD-IO, GPIO, PWM etc. the same applies. Instead of constantly spending time setting the right bit at the right time many times each second, you just tell a dedicated block on the SoC to do a thing in a certain pattern and it will do it for you, consuming on CPU core resources.
This also allows slow CPU cores that wouldn't be able to decode video in real time to offload the entire decoding to a video decoder block, and then tell the GPU part of the SoC that you're drawing a green rectangle somewhere and that's where it has to put the decoded video frames. Why would one do all of this? Because it's cheap and power-efficient, and that's how you make a big pile of money.
I have no idea how accurate or up-to-date this PDF is, but it should at least give you some idea as to what a SoC can do without bogging down the CPU cores: https://dl.radxa.com/rockpis/docs/hw/datasheets/Rockchip%20R... Check chapter 9 for example, all of those boxes are things you don't have to spend CPU cycles on. If you did use the CPU, it would be super slow.
I think that's only for ARM's own GPU IP, not for the VOP (it's more of a LCD driver than an actual GPU -- I'd compare the VOP to say, GameBoy-color level of graphics capabilities, which is cool but not even close to a bare-bones VESA or UEFI framebuffer).
What should we run it on if we want to deploy it on mobile systems with limited access to network and extremely restricted power budgets?
For a hobby project I'm trying to find a solution - Power budget for multiple is sub 200w. Need to run inference on a lower resolution video stream (or multiple, that be nice) to do object detection. Cost is a factor because I need to have multiple angles to determine where in relation to a mobile platform the target object is. I'm looking at the Coral.ai board because RPi like boards lack the ability to do ML tasks at reasonable FPS and NVidia seems to have abandoned the lower cost side of the market since the Jetson Nanos seem to be less and less available. (Not that Coral.ai boards are available at all...)
Check out the Luxonis Oak products. I use an Oak-1 Lite to do real time 2 stage object detection and recognition (~23FPS at 1080P inference on device with two custom yolov5n models). With a bit of python and a Pi (or a Rock64 or similar) you can get it up and running in a day. They also have a decent community and are actively developing the API/SDK and hardware.
Thanks, I've got one of their depth cameras that's been ok. I didn't realize they'd expanded their line so much. Glad to hear about the API/SDK improving, last time I mucked with it a year or so ago it seemed like it was underdeveloped.
Going to have to dig into the sensors they use - had passable luck with non ML tasks using dirt cheap camera modules from laptops running at low resolutions right up until I started moving the cameras at all and then it became a blurry mess because they were so small their exposure times were high. (I'm trying to also avoid having to put a bunch of illumination near the cameras so it doesn't entirely look like a biblically accurate angel)
Well, you can control the camera ISP and they use very decent IMX modules, so it really shouldn't an issue like it was with the cheapos, as long as you can do the coding to your needs.
They have a home grown AI accelerator along with free Deep learning SDK.
Also offer a pretty easy online tool (free again) to use called TI Edge AI studio. They are using extending the existing AI solutions that come from the higher performance parts like TDA4 and AM68A parts. Pretty good considering a lot of these manufactures are just buying other AI Ip that isn’t performing great and investing in their own engineering.
Looks nice. Honestly I am just kind of playing around right now and the Luxonis products are the only ones that seem to have any kind of active development, support, and usable (for me) hardware in the hobbyist (<$200) price range.
nVidia's platform is just a huge mess. I tried to get their SDK running and their own documentation was out-of-date, missing necessary links, and sometimes blatantly wrong. I wasn't going to dump $400+ into that ecosystem.
Google gives up on hardware consistently and has the worst support of any existing software company (effectively zero) and has bungled the AI hand every change they get.
ARM NPUs I am not going to bother with. I can't even get video encoder acceleration working on a non-Pi ARM SoC except for the Rock64 and that is like 6 years old and was missing that functionality for 4 of them.
Intel only cares about its corporate partners and doesn't give a crap about hobbyists in regards to A.I. But their VPU was (is) decent and Oak guaranteed supply for at least until 2025 or thereabouts and built a useable API so we don't have to mess with OpenVINO.
It's all a mess right now but I can't say that competition is bad. It will be nice if we dispense with all the bespoke platforms and agree on some common architecture for edge devices, but I won't hold my breath.
To give one example, Raspberry Pi are often used to control 3D printers and attached webcams, and there are ML systems that supervise the webcam feed for evidence of a print failure. Being able to run these systems on the SBC would be an advantage, but that's typically not realistic today.
It would probably not run on this potato directly, but on an accelerator (be it in-SoC or a separate thing like a Google Coral). The management and control of a Coral needs to happen on a CPU somewhere, but the actual work doesn't involve the CPU much, if at all.
So if you have a thing that has all the data and all the work done on an engine elsewhere and you just need to have a SoC to turn the thing on and off and get the data in and out, that's where a potato-SoC could work. Of course, the potato would need good distro support with up-to-date kernel, drivers, python, libraries etc. and if you're connecting it to the network, best make sure it's also getting patched consistently.
So, as far as ML Potatoes go, that's about it. It is a totally valid question by the way, even if asked in jest.
It's the same situation as all the bitcoin miners from years ago. They mined on the GPU, so the CPU didn't matter as much as how many PCIe slots the motherboard had. The CPU is purely there to drive the operating system and enable the network to communicate with the GPU.
If you aren't using the CPU for anything other than the PCIe slot to enable a Nvidia card for ML, then a very cheap potato makes a lot of sense.
> As usual, looks good on papier but no ecosystem and the current stack that it comes with is dead on arrival.
There is no standard Arm ecosystem to boot on which is the real issue - every board needs a custom kernel and booting.
I blame Arm for never cooking up a PC like spec that defines hardware configuration, firmware and booting. This is why x86 is going to stick around for a while - its dead simple to bootstrap a random x86 machine (well, almost).
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.
For one, you have to provide one specifically for your board to boot at all. There is no "common" one that'll get you to a shell on any board.
The main issue is that most SoC vendors just dump a heavily hacked up Linux kernel source intended for Android on you, along with binary blobs (firmware, android hal services, etc.). The drivers aren't in the kernel per se, just enough of a stub for the proprietary blobs to talk to the hardware.
So if the goal is to run a standard Linux distro on the board, you're pretty screwed unless you have the time and resources (or a community) to reverse engineer the android bsp into drivers for the mainline kernel.
The thing that makes the RPi great is that there's actually an entity paying for this development to happen, along with the community. It's certainly far from the fastest ARM board, but even the decade old RPi 1 still gets kernel updates.
I blame Arm for never cooking up a PC like spec that defines hardware configuration, firmware and booting.
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.
My usual question for small cheap boards is: what will happen to OS support in 3 years? Is it using regular distro or is this a custom fork which will likely be never updated? The website says:
> The UNIHIKER comes with a Linux operating system based on Debian and various built-in features, which will be upgraded from time to time.
... don't expect OS upgrades here. If you want to play with it for a while then put it away forever, go ahead and do it; but if you want to build something long-term, better find a different board.
Why does it need continuous, perpetual support? Most devices like this get built, software installed, and never updated again. When is the last time you updated the ECU software in your car? I built a small arcade cabinet using an old raspberry pi 2b. Once I built it I've never needed to upgrade anything on it. It works fine and plays all the old games. I have backups of the SD card in case anything craps out.
Few years ago, you built your arcade cabinet, and decided to put some nice launcher like RetroPie. It works fine for a few years, and then your friends tell you about Pico8 support.. nice, it is supported by RetroPie release! not nice: retropie requires ubuntu 18.04 or later.. let's hope your device supports it.
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..
If there's a vulnerability in any of the software or firmware that connects and interfaces with anything over a network, there's the possibility of something worming it's way in or out of 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.
No matter how elegant you seem to be, you'll always be running like half a dozen versions in the wild.
For any large deployment that kind of work will be on your shoulders anyways. Stuffing in security updates or whatever to that isn't crazy
Unless you're saying you want multichannel overlapping upgrade schedules where you have some NxM cadence matrix to test and support (as in ssh x+/-{1,2,3} AND your software x+/-{1,2,3} etc).
I've had to make and manage automated test rigs for those types of deployment as well.
That's an entire room full of whatever machines your deploying and a full time job.
Anyways, this stuff is hard for the out in the wild devices. Putting security updates in a monolithic release package is really the easier way to go and at that point it's on you.
In most cases, yes, in all cases, no. There's a lot of variants of "enumerate all devices on a private network if you visit a malicious webpage" exploits.
Connections are only part of the danger. Browsers need to access the internet and they can have security bugs. Also, people download files and the programs that process them have bugs. People download programs and those can be dangerous.
For the kernel, it is important that it protect against dangerous programs running on the system to keep them isolated.
Because as an industry, we are bad at our jobs. The network facing software has critical security vulnerabilities. Even security folks accept that as the way of the world.
At the point the software is released it has (hopefully) no known security vulnerabilities, which is a reasonably secure situation to be in.
However, eventually some of them will become known, and that is not safe.
There are plenty of reasons not to want your IOT bulb to be insecure that are unrelated to people mining crypto.
A pwned IOT lightbulb can be used to help DDOS sites. It can relay DDOS traffic, eating your own bandwidth. It can be constantly probing the other devices on your network looking for vulnerabilities, until it pwns something else and is able to slurp down your passwords and credit card numbers.
Are you seriously suggesting that having an actively malicious computing device inside your home network is no big deal?
If it has a camera, it can be used to steal your security keys if it can see the power LED on your device (or potentially even just if something connected to your device has a power LED).
But a "critical security vulnerability " depends on the use. My daily driver? Yes, I want all of the security updates. A raspberry pi for playing arcade games that I occasionally scp a ROM over to? I really don't care if someone hacks in.
We, as an industry, are bad about pushing "every device that is on the internet needs to be as up to date as possible all the time" when it reality there is a lot of unimportant stuff on the internet.
It's like locks. I wouldn't secure my house with a bike lock, but it's fine for my bike. My bike is less full of important stuff.
At best, that means you're externalizing the costs, i.e. now your device is part of a botnet and becomes a problem for other people. But of course that assumes that it doesn't become a problem for you as well; a compromised device on your network is a great launching point for local attacks and a way to send illegal traffic out through your internet connection.
Ah yeah, I need to stop working at random notice, because some CVE bros have to immediately update all my things to hedge the risk of organized crime targeting my $0 value data like I'm that casino.
Meanwhile in reality, no one gives a f about the rPi you use for your Guinea pig feeder.
The "security" industry is unfortunately full of corpo-authoritarians. Once they realised a lot of the population can be forced to do anything if they can be convinced it's for "security", they've been doubling down on that.
Well, a common thing with open computing resources these days is cryptominers. Sure, you don't care about updates, until someone puts a miner on it and you have to go in and try to fix it. It wouldn't matter that your single device doesn't have enough processing power when there are tens of thousands of similarly vulnerable devices to hijack.
Because that is the nature of these SBCs. They aren't some generic queryable platform running UEFI. Instead you have a bespoke OS fork for each individual board. This means that vendors need to give a lot of attention to the software because there isn't a foundation or company taking care of all SBCs at once. The device becomes obsolete very quickly if you can't install recent software. SBC performance hasn't increased much. There are still plenty of boards with A53 cores that have been used for more than a decade.
First, this advertises this as a PC which have longer lifetime and higher security requirements than embedded.
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.
All software have many dependencies (IMO for very wrong reason), if you can find a way to build a static system where nothing need to be updated good for you, but I doubt that this is the majority of use-case.
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.
It's dead on arrival; currently runs Debian 10 with custom patches and binary blobs. It's an RK3308 so not entirely impossible to run on a normal distro, but you'd have to bring your own firmware and device tree etc.
This is designed as an embeddable component for learning, prototyping, and OEMs. A lot of people here are just sniffily dismissing it as 'DOA' when what they mean is 'I would not want to maintain this.'
No, it's DOA. Embeddable components need support too. As do OEMs and prototyping scenarios.
It is presented as a viable commercial product, but it actually is an old SoC with no ecosystem. If anything, it teaches people not to use this type of thing.
The only way it would not be e-waste is if it had a future, and it doesn't and that's why it's bad. At this price point there are so many community and commercial alternatives that do have an ecosystem and support it's just pointless and most likely an attempt to dump overstocked Rockchip parts. Even an ancient i.MX 6 is a better choice.
Dude, Debian 10 goes out of support in a year. Debian 12 already released.
It's 4 years out of date at release, why would you want that for "learning and prototyping", let alone start a OEM device with soon unsupported software versions.
In my opinion the vendor supplied OS distros are to be taken as just a starting point, nothing to rely on more than the time needed for the port of one of the well established distros (Armbian, DietPI, stock, etc) to appear for a given board, which often happens quite fast when driver blobs and lack of documentation don't get in the way (the RK3308 used here is well supported along the WiFi chip). My usual approach when looking for a board is to check first if there's some support from the above distros, or wait.
It may seem odd, but it's just the same reasoning we're used to in the PC world translated to the embedded world: whoever would expect Gigabyte, Asus, etc. to create and supply the Linux distribution that runs on their PC mainboard?
If you want to play with it for a while then put it away forever, go ahead and do it; but if you want to build something long-term, better find a different board.
I think it depends on what you want to do with it.
If you're building something that won't access the network, or will be isolated to the LAN, then it's fine.
Not everything needs or wants to be connected to the internet.
depends on whether you care about vulnerabilities or not, I suppose. Presumably that lighting controller talks to something. If it talks to a local network only and it's impossible for external traffic to reach it, maybe not such a big deal. If that's not true it might be significant. That's also true of all IoT junk anyhow, it's all running some linux variant under the hood and security / updating is rarely a major concern.
This is actually one of the reasons I like bluetooth/zigbee/z-wave/IR/etc. so much - it puts a significant barrier to attacking devices even if they don't get patches. Of course, you still should pay attention to security and update them if possible because local and/or proxied attacks are still a thing, but it's much less likely to get hit.
Slightly unrelated, but I wonder what is a preferred OS for similar boards: a buildroot or yocto -based system vs a full-blown Debian-based distribution with desktop and package managers?
When I looked into (now deprecated) Jetson Nano I was surprised to find out there was no straightforward and documented way to build your own system and cross-compile for it. Is that because for many people using SBCs means doing everything on the target (e.g. compiling software), or am I missing something?
I just get the kernel and grab the stock Debian userspace for the architecture. Vendors like to do horrible stuff to their sample distros.
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.
It's not just small cheap boards. It's small expensive computers, too: I was burned just like this with the Sony VAIO 720P and the PlanetComputers Gemini PDA. Awesome hardware, pretty good drivers for the current kernel/distro, and then ... nothing.
Holy crap, I totally missed that requirement. This product now goes straight in my do-not-buy list.
Yes, one could install a Windows VM, set up a passthrough USB port and do everything from there, but seriously, what's the logic behind requiring Windows for a board that runs only Linux?
Image burning is certainly more involved than your run of the mill cross-platform Electron app. It likely uses lower-level system calls that might not even be possible in most cross-platform frameworks. Additionally, the screenshots make clear mention of a driver, something that would certainly be different depending on the OS.
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.
> 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.
Just because you did it doesn't mean everyone knows how to do it. And that was my entire point.
The ESP32s belong to a completely different category of processors, they are microcontrollers optimized first and foremost for cost and power efficiency rather than raw performance or the ability to run Linux. The Rockchip SoC used here, on the other hand, is more akin to what you would find in a cheap Android tablet or set-top box: it has Cortex-A cores, a proper GPU and can use far more memory than the mere hundreds of kilobytes of SRAM built into ESP32 chips. Of course it also requires far more external components and draws significantly more power when running at full speed, so it's in no way a drop-in replacement for microcontrollers in products where Linux is not a hard requirement but BOM cost and battery life are.
> 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).
Various hibernation modes are great, but 300ma@5v sometimes feels too hungry for the amount of computation in there. I bet things would be better if it wasn’t 45nm ‘pitch’. They are great chips, but require more power than you might expect if you’re doing something network-heavy or, god forbid, using the camera. Unfortunately there’s no competitive alternatives for the hobbyist.
they are very different, esp32 is an advanced microcontroller (with wifi/bt) and is comparable to an arduino on steroids, whereas this board uses cortex a35 and is more comparable to a raspberry
esp32 has 520 Kb of ram, while this board has 512 Mb!
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.
I'm pretty sure that was a game/gimmick and part of the conference badge challenge. But maybe not. Regardless it is a security conference after all and I'd totally expect people to be playing around like that. I don't think it would have been seen as malicious.
"The built-in IoT service on UNIHIKER allows
users to store data through the MQTT protocol
and provides real-time data access via web
browser."
That reads as "comes with integrated backdoor you may not want." It may or may not be any good from a security standpoint, but it's a risk.
> This is designed as an embeddable component for learning, prototyping, and OEMs.
It's trying to be a lot of things at once. It has connectors on all four sides and no screw holes for mounting, which is a headache when you need to build it into something. That layout started with Arduino, continued into Raspberry Pi, and continues to be a headache. It's fine for desktop prototyping, not good for deployment.
Note how vague the site gets when they talk about applications.
>Note how vague the site gets when they talk about applications.
It's a DFRobot product. I used to work for a company that distributed DFRobot products in the US, and this is broadly consistent with their corporate philosophy. Their designers crank out thousands of products to keep ahead of other Shenzen companies who are fast-following them. (Notably Seeedstudio) You can view their full catalog here, and it's quite the sight to see: https://www.dfrobot.com/category-48.html
They generally take the OEM reference design, put it on a pcb, and add connectors. The API will be minimal. Compatibility is a joke. (For instance, they make no effort to avoid I2C address collisions-- how could they, when most of them are hard-coded by the device vendor, and they only make the PCB? You have to be careful when stacking several different Arduino shields, since they'll very often be talking on the same pins. There will be no warning of this on the product page, of course, so the end user must carefully examine the board schematic. Etc etc etc.)
When I was working with them, I had the impression there were maybe three people who spoke English at the company, and they spent most of their time writing product pages. Email support was hopeless, and their forums were the usual mess.
DFRobot products are best thought of as a convenient way to get a sensor or microprocessor without having to design and reflow your PCB. If you don't like reading manufacturer datasheets, then you won't like DFRobot. They're not legos, and they're far from the kind of integrated product family you'd expect from a US company.
The unihiker.com webpage has a California startup website aesthetic, so you might expect a small company built to support this one board, but DFRobot literally has dozens of SBCs just like this: https://www.dfrobot.com/category-184.html I would be surprised if they even have one person dedicated to this product. An easy guess is they're already moving on to the next board launch, with yet another small ARM chip from another vendor.
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!
Looks like a neat board, I could see making expansion modules that plug into the bottom and running like a IR blaster or other stuff off the SPI/UART bus.
I wish the RAM could be a bit more, at least 1G or 2G, so I can have a database on there without having to ship my data to the cloud. Then the system can really run isolated as much as possible, for security and privacy.
SQLite would still be a good option. It's incredibly lightweight, and if you set the database to WAL mode it also works well for a database file accessed by multiple applications on the same device.
This. Back in the day when we lacked RAM, especially on *nix based systems, it's absolutely normal to use the disk/flash as pseudo-RAM. This was just...a normal part of computing at the time, heh.
Of course, applications would respond shit slow this way, but in the case of a DB it'd be more than fine, no?
Yes, I understand the content of the database is supposed to be on disk. But for the database to function and do its thing, it needs space in RAM. Like page swap and cache.
So, like all other "raspberry pi killers" this is running a patched kernel released by some company in Shenzhen with no plan to upstream changes or get them into the main kernel tree.
Looks like it's based around the Rockchip RK3308 so it's likely not that bad. I'm sure this ships with some old patched vendor kernel but the SoC is already supported in mainline.
I've not gone through the other components but this probably doesn't take too much time to get to full mainline linux support.
Used Lenovo think center I bought off eBay has, Intel 7th gen with vPro, 8GB ram, 256GB nvme, all of that for 76$ including shipping, pi can even beat that price.
I'm incredibly curious what the experience of trying to write code with ChatGPT is like, if you have no prior knowledge. Obviously, it's impossible for me (and most others reading this) to un-know everything and approach it with fresh eyes. Are there any good real-time videos of non-programmers using ChatGPT to write code? (seems like the best way to understand what it's like)
I am an engineer, but not a software engineer. I write python sometimes to help me do engineer-y things in my domain but I am absolutely not very fluent, just enough to get by. chatGPT often transforms a frustrating multi-hour stack overflow session into a 5 minute query.
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.
Honestly for tasks it’s able to do easily ChatGPT code is probably more maintainable because it’s more well-commented, formatted etc. than code a human would write if they’re just trying to quickly hack something together
Sometimes I think “you can tell this part of my code was generated by ChatGPT because it’s actually good, unlike the rest of it”
Of course it’s likely to make subtle mistakes that are hard to debug if you ask it to do anything complicated because it can’t test its own code (well, I’ve heard something about a code interpreter in the Plus version but I don’t know how well that works)
Similar situation here. I usually can hack something together in python, but end up spending a couple hours reading stack overflow posts, and often meeting with co-workers to debug my code. Chat-GPT can often write simple code for me and honestly saves some time.
It’s pretty good depending on what you are doing. With Python and JS/TS, the last checkpoint for training datasets really matters. These api’s for no reason at all to me, rot incredibly fast, so the code it generates was valid in September 2020, but now it is almost completely incompatible.
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.
I'm helping another fella who's new to coding, he's using GPT to make some code. Most of what it produces won't even compile. Building for sensors on an ESP32 platform. BUT! GPT will get a good way there, a main with some sub-routines, stuff like that. I don't think it's good enough to teach.
If you can already code, then GPT can ramp you up on a new project faster, or accelerate and existing project
I am wondering why people seem to think it's so great for this. It's fine for I guess boiler plate code construction but totally falls over when I give it e.g. complicated Rust borrow checker problems. And if you tell it a mistake it's made, it just buries itself deeper branching off into spirals of more and more incorrent solutions.
To me, it's like a junior developer I have to coach constantly.
I don't know Rust well and was having trouble the finding the docs I needed, so I asked AI for help. Google Bard, I think. It had real difficulty producing code that ran and worked.
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's hell, I have been trying it for a couple.months, and you can't really get anything of note built. it's buggy AF, and gets stuck in loops and can't debug itself.
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.
Sort of like using Google translate for a language you don't speak a word of I'd imagine. "I just said what the computer said to say and now the computer/waiter is mad at me"
I'm sorry this is off topic, but I love the homepage design. Have too many rPIs to justify buying this, but something about a nice, light, internet blue, simplistic design really makes me happy. Too many sites with their dark mode BS trying to be super serious and deep toned today.
I love to see one of these come with the ability to fit into a gang box on the wall... to use in a place where one would usually have light switches, etc.
This is a good idea. You don't want to have a full-on Linux distro controlling your lights. You want something you can set up and forget.
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.
The “documentation” page is a joke. I cannot eve find if the touch screen is resistive or capacitive. I see no schematics, making bring up if your own OS in it unlikely. I see no data sheets either. Just another piece of e-trash waiting to end up on a landfill..
Most people seem concerned about software, ecosystem and community. After my experience with Raspberry Pi, my top concern is investing in a platform that may leave me hanging for supply reasons.
This seems like a somewhat related place to ask this: Does anyone know where I can get a 3" round screen?
I have a Star Wars clock from the 1970s that has a ton of empty space in the base. I want to put a small computer in it and replace the 3" clock face with a round screen, so it can show the time and maybe some fun Star Wars animations.
But I just don't know how to find a 3" round screen without buying 1000 of them from China.
How do I get just one 3" screen that I can attach to a Raspberry Pi or equivalent linux computer?
I think Waveshare has some. I've been messing with their 1.28 in round ones and I like it. Just be aware that they will use SPI (think Arduino level) for the connection, not something video oriented like HDMI. Thus they can be used on a Raspberry Pi with a custom driver, but you won't be getting 60fps.
Our (Pi compatible) HyperPixel Round is just shy of 3” if you count the thick, black border around the edges. Actual screen is 2.1” but diameter is 71.8mm.
I desperately want something similar, a small touchscreen Linux board that's thin/slim without any annoying headers etc so I can make a digital badge.
I've literally found nothing that fits the bill, they're either thick tft lcds, lack touch or have stupid peripherals. I just need to make a digital badge but I feel like I'll have to build it from scratch myself.
How is it phone screens are <1mm much of the time but the only boards with a screen I can find are >3mm thick (often like >10mm). What happened to miniaturisation...
Unrelated but trying the HN wisdom here: any suggestion for a cheap touchscreen with a CPU attached and a battery that can be used as a control panel for Home Assistant? Yeah, probably some Android tablet but something that actually works well for this job and costs as less as possible? I cannot power it properly where I want to put it so it needs battery and then I can charge it as needed. Suggestions?
Oh, nice! maybe not as central controller (that would be still better on a bigger screen) but for each room control it could work very well! Thanks for the idea!
I just got a couple of ESP32-S3 devices direct from China (AliExpress), one with a 5" TFT screen and the other with a 7".
I don't know what home assistant is, but these will run C++ or MicroPython just fine. My application is an industrial controller and they are really nice. Dirt cheap at around $30 each shipped (arrived in just over 2 weeks) to USA.
[edit] They have very little I/O since the display is driven in parallel mode and that takes up most of the EPS32 pins. There's a SPI connector and a couple other pins that could probably be redirected for I2C. I haven't gotten around to to checking that. I did use one of the available pins for serial input to read a GPS module and that was trivial to setup though.
I use an stm32f103 as an io extender for my esp32-a1s, they cost about 2$ per board and the chip programmer cost about 10$. I use I2C to communicate between the esp32 and the stm32.
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.
Yeah, I decided to use an "Arduino" 10MT "PLC" board as my I/O extender since it comes with optically isolated inputs, 4-20mA analog input and a 24VDC power input, all of which I can use. At the improbable price of $22.75!
Does it even need to be a current version? If it's only used to access the web interface of a local device that you trust, I've wondered if you couldn't get away with an even older device/OS/browser. The only problem I can think of is if ex. HA ships an update that uses newer browser features, and even that wouldn't be a problem if you did the dashboard custom.
You'd be able to strap something together with a Pimoroni Hyperpixel and a raspberry pi with a lipo hat, if that was a direction you wanted to go in. It's a very nice little screen. No idea about how power efficient it is, though.
I mean, You are spot on -- A cheap android tablet sounds like the fastest/best/most aesthetically pleasing option. Otherwise Waveshare screen + some PI board is the "easy hacker-aesthetic way"
True that. They do have a phone-size e-reader device which is great, but obviously is subject to the limitations of e-ink. I suggest reaching out to them, they're very responsive on Twitter and @lovyan3 has developed a universal graphics library for the ESP32 stack and works closely with them.
This seems like a purported industrial HMI(human-machine interface) unit, a kind of a Pi that are one-off customized to fit on front faces of giant beige metal boxes of all kinds. And there seems to be trend of HMI devices from Chinese market. I wonder who's buying these and for what...
Ha. I just bought two ESP32-based ones: with a 5" & a 7" TFT display cuz I wanted to try both.
My application was an HMI (using LGVL) for a device I'm building to order, but I've since decided that I don't need touch input and thus can use a much smaller display.
The devices however, are cheap and really nice for the $30 price tag. Having such capable, easy to use hardware at such a low price point opens up markets that couldn't feasibly be served before. There are a lot of people who need one-offs or very small quantities of devices that can't withstand a 5- or 6-figure development cost. When that cost drops to low four-figures because you can use the Arduino ecosystem, then the cash flows.
Sell the stuff you are not using. It is ok to leave one thing that you wish to tinker with in the future, but it is not advised. While we're at it, a clean up of files on your computer is also way overdue. I should not mention hundreds of opened tabs in your browser.
The STM32F4 is a Cortex-M4 microcontroller. You have direct access to optimally do whatever you want with the CubeIDE and GCC libraries.
This is a platform, if the things you want to do are possible with the entire stack of Debian, the pre-existing touchscreen menus, the PinPong Python libraries, etc. then sure, use this...but that's a lot of wasted efficiency and a very large dependency.
The STM32F4, for example, can be configured to enter deep sleep and run for a long time on a battery. This likely cannot.
I’ve become very cynical of these types of tiny computer products. These computers are like puppies that tech nerds will gush over and buy impulsively, do a couple small things with, then never use again.
It seems like the smaller it is, the crazier people get.
Ugh, u may not like the following but the devices you are using to get on the internet, are used to collect a treasure trove of information, to conduct information warfare.
And regardless of whatever your bullshit political specrum is.... this is a platform for stalking, propaganda, tracking and killing Human Beings.
Period.
Street Cred: I have common sense.
There is only one outcome: Defense spending, Military Death.
Boards need to come with mainstream distro support or with an ecosystem (or both), otherwise it will just die. And with internet connected devices, you can't set-and-forget, so it needs to have live support.
Edit: a RockPi S (same SoC) can be had for $35 and a touch LCD for $11... Granted, it doesn't come with the same integration and headers, and doesn't have a microphone by default, and no RISC-V MCU. But the point of integration is a useful product that stays useful, and it doesn't if there is no ecosystem.
As for 'adding' mainstream support, it takes quite some effort and active ownership. Out of the many rockchip boards and add-ons this is the set that made it to some level of standard inclusion: http://ftp.debian.org/debian/dists/stable/main/installer-arm...