In the decade-and-a-bit since the first Raspberry Pi was launched we’ve seen an explosion of affordable single-board computers (SBCs), but as the prices creep up alongside user expectation and bloat, [Christopher Barnatt] asks where the industry will go next.
The Pi started with an unbeatable offer, $35 got you something similar to the desktop PC you’d had a decade earlier — able to run a Linux desktop on your TV from an SD card. Over the years the boards have become faster and more numerous, but the prices for ARM boards are now only nominally as affordable as they were in 2012, and meanwhile the lower end of x86 computing is now firmly in the same space. He demonstrates how much slower the 2023 Raspberry Pi OS distribution is on an original Pi compared to one of the early pre-Raspbian distros, and identifies in that a gap forming between users. From that he sees those people wanting a desktop heading towards the x86 machines, and the bare-metal makers at the lower end heading for the more powerful microcontrollers which simply weren’t so available a decade ago.
We have to admit that we agree with him, as the days when a new Raspberry Pi board was a special step forward rather than just another fast SBC are now probably behind us. In that we think the Pi people are probably also looking beyond their flagship product, as the hugely successful lunches of the RP2040 and the industrial-focused Compute Module 4 have shown.
What do you think about the SBC market? Tell us in the comments.
I’d like for someone to take the H3droid project to the next level, bump it up a few Android versions from 4.x. There are TV boxes with the Allwinner H3 running versions as new as 7 while H3droid is languishing on 4.4 and seems to be moribund if not totally dead.
Meanwhile, companies that have made SBCs with an H3 chip (like OrangePi) won’t release newer versions of Android for them. I have an OrangePi Plus 2E and have yet to find something useful to do with it. I designed and 3D printed a case for it, that’s on Thingiverse. Getting a simple DLNA server going on it would be a useful function for it.
Why the insistence on it running Android? You could run regular Linux on it instead, serving your DLNA needs. See e.g. Armbian
I second that. Android makes some sense on mobile and touch screen based media consumption devices, but would be a terrible choice for anything embedded. Aside not having FOSS drivers, it promotes a monoculture in which one should use only one very low performance language for writing everything, and using the NDK is a lot more difficult than developing native on other platforms. Please, keep Android out of the embedded world.
Distros such as Armbian and DietPI already support a plethora of embedded boards, and they’re much much more open and easy to develop for compared to Android.
Dietpi is a bash script, a software installer which does not support any of embedded boards. Please keep comparing Dietpi with Armbian. They download Armbian/Raspbian image and re-brand it to Dietpi.
According to software license, they can do that, if it’s armbian.
I have dietpi on rock3a (I like it more) and armbian on radxaE25
– Option 1: Stock Debian ARM https://wiki.debian.org/InstallingDebianOn/Allwinner with Kodi
– Option 2: OpenWRT https://openwrt.org/toh/xunlong/orange_pi_plus + miniDLNA
This board (and others from OrangePi) is supported on Armbian. For a long time I had a lowly OPi Zero as “server”, doing the chores of Pihole, OpenHAB, and an RTL-TCP instance. I even used it as poor-man’s NAS for a while with OMV6, but lack of SATA/USB3 and GbE meant slow transfers. Even with all that, the system ran surprisingly good.
Minidlna is easily installable via armbian-config -> Softy.
https://www.armbian.com/orange-pi-plus-2e/
Put dietpi on it.
Find a useful project there.
You can start with Armbian, where Dietpi gets everything that is important and skip all their amateur security hazardous bloatware and proceed with https://www.digitalocean.com/community/tutorials
and also learn few things on the way.
https://www.friendlyelec.com/ has many SBC’s that are almost always in stock unlike RPI.
Combined with and OS image from https://dietpi.com/, you will be wondering why do I even bother with RPI
People use raspis for the same reason people use arduino, it’s not the best (neither for your bang nor for your buck) but it’s the most well-known, and has the largest “community”.
IMHO FreindyElec is too expensive and too close to China. DietPi is pretty good though, if you can find hardware to run it that you can trust, buy, and afford.
friendlyelec has many SBC that you can always get. Combined with OS image from dietpi.com can’t be beat.
OS is provided by Armbian. Dietpi does exactly nothing here. Its a BASH script that installs software and breaks security while doing that.
I’m not sure the Pi bubble will really burst any time soon, even though there are some nice competitors out there now – The price is right (baring the scalpers) and the long term availability, support and community are just so good it would be like trying to create another FOSS OS alongside the GNU Linux and BSD stuff. A massive investment to get even close to that quality level, and you have to maintain that investment for a long time with many great and hopefully unique features to actually attract folks to build the community. As most other SBC vendors give you one custom image that is usually years out of date at time of release and no support at all, often with little documentation as well…
And I don’t think we will see x86 really sticking around at the low end desktop, or even at all really – it tends to loose out in power efficiency to the Arm (etc) rivals, and that is becoming ever more important and more ‘desktop’ style use is being done on phones and tablets these days anyway – so the software for that light desktop user on Arm is improving.
despite my rant about the software engineers below, the competition to the raspi is *FAR* worse in the software field. I bought one rockchip based device. Never again. Never. I’m surprised it even managed to boot linux. It was an early one (I don’t remember which one) but it was hyped. It got ewasted without ever running a project on it. Even the orange pi…..Got one of those because of the PCIe breakout, only to find the software was hard coded for one device type. (I don’t remember which). I mean, really? We have a bus that’s enumerable by design, and yet we hard code things for it? You’ve got to be kidding me! Yes its open source, and yes, I could go and fix it….or I could buy a low power x86 running linux with full PCIe functionality and get straight to my project rather than fixing someone else’s. Until the competitors can match the software if the pi, they’re garbage, only useful to people willing to customize the software to their application and fix all the BS related to getting their application working.
We need to learn, software is not “A necessary evil” at a hardware company, but instead, “Software makes the hardware”. Very few hardware companies think this way, which is why I avoid working for them, and avoid products from them whenever possible (since the user experience will be so awful)
I got a rock pi, which is actually more powerful than a pi 4. It has the same mounting holes as a raspberry pi, but the CPU is in a different spot, so all the raspberry pi cases don’t work for it. Case compatibility is something I didn’t think about.
Case compatibility is one of those really key things you have to wonder why way more RPi alternative companies don’t think more about; after all, if it’s meant to be an actual RPi alternative then you need to be able to drop it in to the same hardware infrastructure that you *already have* for RPis…
On any desktop (or for that matter “laptop”) scenario x86 is a necessity, most of the important software one runs (that is the very things one has the computer for like CAD, image editors, office packages…), especially if legacy software might only be available (even when open-source because self-compling is typically a dependency hell) as pre-compiled x86 binaries. A computer than can’t natively run x86 binaries in your Linux (or dreaded Windows) OS is no use for desktop scenarios. Only in embedded applications where you’re developng all the software for yourself that will be run on the system, or working entirely with the kinds of Linux system tools and python libraries which are available pre-compiled for ARM or don’t need compiling at all, can one use ARM. The only way around this would be ARM with fully reliable superfast x86 emulation, so good that software running couldn’t tell the difference as to whether it was on x86 or ARM, so good and fast you could fire up a VM of a typical x86 setup and OS even if the underlying hardware is ARM and have it run as fast as if it could run natively. Without that kind of absolutely perfect emulation x86 remains king for desktop use.
long term availability is a funny attribute to claim for a product that has been out of stock for 18 consecutive months.
i know you did research a decade ago and categorically refuse to look into it today but the low-end x86 power efficiency is better than rpi today. you are right that a lot of ARM chips are a lot more efficient, but the rpi is an especially poor performer as ARMs go. basically, in the last decade x86 has gotten a lot more power efficient, and ARM in general has increased performance without giving up efficiency, but rpi has only become more performant without becoming more efficient. it’s a fine choice to make but let’s acknowledge what it is. okay, let everyone except Foldi-One acknowledge what it is. you don’t have to, if you don’t want to!
since rpi stopped filling it (18 months of out of stock!!), there is a niche for a well-supported (for noobs) and high-availability (for noobs) ARM board that is going unfilled. and no one is stepping up to fill it! i’m not sure what it means but i suspect it means that the niche really isn’t that valuable to end users for reasons that this article really spelled out pretty well.
as an aside, i wonder what the demand for rpis from companies that put them inside of their products looks like. i know i have one of those devices, a helium crypto miner (not an endorsement!). i wonder what kind of devices make up the majority of the rpi demand.
Stock is still or has been bad for everything, and they are not and never really were properly out of stock, just the new batches for hobby users tended to sell out quickly and get scalped alot. But the Pi’s continue to be made, and sold in vast numbers even through that dip – actually available at all at a time many things were not. Just because there was a wobble with supply and demand that has left us hobby users struggling to get one at MSRP at times doesn’t mean the availably was particularly poor, as we couldn’t get anything else much worth having either! With very roughly the same number of Pi’s was made in those pandemic years and now as the ones before – they actually rode the chip shortage better than any other similarly small producer I know of…
And yes the Pi isn’t good as Arm chips go on power use, it never has been, it is just the one that is generally available, with working and supported software. And so actually in practice works out rather well on power use, while being relatively affordable, as it is just working properly more often than not… But that statement was about Risk/Arm in general over x86 not Pi specific.
Though with how impossible it tends to be to actually get x86 stuff to get to their lower idle states – you know the ones that maybe can push the system draw lower than the Pi’s max power draw the Pi does still stands up well in many situations… As the real rivials for low idle power in the x86 world tend to be orders of magnitude more expensive, and less flexible coming packaged in some device on a PCB form factor vastly less versatile, usually have no GPIO etc – the steamdeck for example is great, and even being sold with what has to be terrible margins its still rather expensive in comparison and for most Pi users surrounded in e-waste…
low power x86 is cheaper than high power x86. the brand name is celery. you don’t need to make stuff up. the real world exists all around you, and is different than it was a decade ago.
Never said it wasn’t cheaper than high power on the same architecture, so what that comment has any relation to mine I have no idea… But its still not even top spec most expensive Pi4 cheap, or at least I’ve never seen anywhere even remotely close, the nearest SBC are at least double the Pi4 even in its most expensive config… And most of them don’t even have major performance gains (even in potential assuming you deal with the thermal limits and required active cooling and don’t bother to factor any extra cost in) to excuse that, though some do. Infact with the price of the ‘best’ SBC I can find that is x86 the steamdeck is the obvious choice price wise, being nearly identically priced and vastly more performant…
Also that ‘brand name is celery’ seems to mean nothing, so are you making stuff up as you accuse me? As far as I can tell there are no brands or even search results by that name related to anything other than the edible plant and some task scheduling…
Perhaps, long term unavailability is a more apt term…
I’ve been looking for over 4 years and have not found one single SBC that provides anywhere near the features and performance of a $35US Pi3B+. The $35US 1G Pi4 is even more powerful.
The $45US and higher market is a different story but that $35US price that they’ve held has so far been untouchable by everyone.
All I need to know about Raspberry Pi is that they’ve been cozying up to surveillance cops, and mocking and blocking on social media people who question that.
That kind of corporate behavior earns a big “No thanks” from me.
“Cozying up to surveillance cops”, in plural, when they….hired an *ex*-cop and didn’t even hire him for the purposes of doing surveillance? Mehhhhh. Talk about making a mountain out of a mole hill.
I think they’re upset that an ex-cop is able to find another job, which is strange because it means one less police officer on the street.
Don’t forget their behavior when it came to VSCode (rather than VSCodium” and preinstalling Microsoft’s key into RPiOS so you would always be phoning home to Microsoft.
Bearing in mind the way that Microsoft already exploits Education and students, and the point of RPis having been to democratise Linux learning in Education – i.e. to get away from Microsoft!
If you’re going to compare prices, you need to do so apples to apples. There has been a cumulative inflation rate of 32.1% since 2012! That means your $75 (today) raspi 8GB model cost $56.75 in 2012 dollars. Thats really not a huge price increase, especially for a 64 bit processor and 8x the ram.
For slower….yeah, its the plague of software engineers. We need more code, so programmers make “easier” (slower) languages, write code more poorly, while users demand more features that take more processing power. That all adds up to a slower experience despite faster computers. I heard the mantra when I first started my career “Computers will get faster, so we don’t need to worry”. Funny how our single thread performance hasn’t really followed that mantra so well, and at the same time “multithreaded programming is hard so don’t do it” was the second mantra those same engineers followed. (and still do). “Easier” languages attempt to abstract some of the problems with multithreaded programming away, but generally fail since you still have to design for multithreading, not follow the third mantra I heard bandied about. “Make it work, then make it fast”. That worked for 1990’s programmers and before, but then SIMD and multicore became the dominant force in chip design, which causes that last mantra to fail spectacularly. So either today’s programmers who are actually good need to figure out a way to “make it easy” for everyone else, or we’re going to have slow code that doesn’t take advantage of modern processors, and user experience will continue to degrade until a good programmer can get in there and fix the trash slowing things down.
In short, the slowdown isn’t the fault of the hardware at all, and at $75, the 8GB model is still a bargain. Throw blame not at the hardware, or the price, send it where it belongs, the software engineers.
It’s not just software’s fault. The Pi’s USB 2.0 peripheral is horribly inefficient and depends on high rate CPU interrupts to function. Something that should take 5% CPU often takes 50%. At least the Pi 4’s USB 3.0 ports’ 2.0 channels are handled by the external chip and connected through pci-e.
I would like to think that there is enough blame to pass around when it when it comes to performance “degradation”. And I would like to think that it’s neither the hardware nor software engineering discipline that is to blame, but the industry and business trends that have guided the current designs.
SBC performance is just a reflection of what is happening in the industry as a whole.
What I think is insightful about your comment is “users demand[ing] more features” but not just more features, but to be delivered at a quicker pace. (Something I was reminded of recently when a client thought that “ChatGPT could do produce software faster” than I could. Insert eye roll here.) The pressures on both software and hardware engineering to produce more and more features at an ever increasing rate has caused both disciplines to focus on what is demanded by users, businesses and, if I may be so bold, society’s dependence on technology as a whole.
(I am aware that the trends are way more nuanced than I’m about to describe, but hopefully it’ll still illustrate the same point)
The hardware industry realized that time-to-market could be shortened by developing simpler, single cores and using them multiple times on the same chip due to the ever increasing transistor density, instead of focusing on single thread performance.
And software industry realized that time-to-market could be shortened by developing in languages that required less understanding of the underlying hardware and could reduce the likelihood of software from crashing an entire system due to a memory core dump by causing programming exceptions instead.
With single core performance improvements being shelved in favor of multi-core design and languages that were separate from the underlying hardware, there was a shift away from multi-threaded programming to multi-process programming. But the problem hasn’t changed and isn’t any easier, it’s just been shifted. Instead of dealing with variable mutexes in memory, we have to deal with contention at the system boundary layer in APIs and databases.
More multi-process development, more cores were needed. And thus the cycle perpetuates.
We could debate this chicken-or-egg problem. Or argue back and forth on the merits of typed vs implied/non-typed languages. But really it’s the collaboration between hardware and software engineers where technology really succeeds.
In the end, if we want technologists to be valued for the work they do, we need to do a better job of educating all of our users and society that there are hard problems that require training, skill and patience to solve.
I would like to think that there is enough blame to pass around when it when it comes to performance “degradation”. And I would like to think that it’s neither the hardware nor software engineering discipline that is to blame, but the industry and business trends that have guided the current designs.
SBC performance is just a reflection of what is happening in the industry as a whole.
What I think is insightful about your comment is “users demand[ing] more features” but not just more features, but to be delivered at a quicker pace. (Something I was reminded of recently when a client thought that “ChatGPT could do produce software faster” than I could. Insert eye roll here.) The pressures on both software and hardware engineering to produce more and more features at an ever increasing rate has caused both disciplines to focus on what is demanded by users, businesses and, if I may be so bold, society’s dependence on technology as a whole.
(I am aware that the trends are way more nuanced than I’m about to describe, but hopefully it’ll still illustrate the same point)
The hardware industry realized that time-to-market could be shortened by developing simpler, single cores and using them multiple times on the same chip due to the ever increasing transistor density, instead of focusing on single thread performance.
And software industry realized that time-to-market could be shortened by developing in languages that required less understanding of the underlying hardware and could reduce the likelihood of software from crashing an entire system due to a memory core dump by causing programming exceptions instead.
With single core performance improvements being shelved in favor of multi-core design and languages that were separate from the underlying hardware, there was a shift away from multi-threaded programming to multi-process programming. But the problem hasn’t changed and isn’t any easier, it’s just been shifted. Instead of dealing with variable mutexes in memory, we have to deal with contention at the system boundary layer in APIs and databases.
More multi-process development, more cores were needed. And thus the cycle perpetuates.
We could debate this chicken-or-egg problem. Or argue back and forth on the merits of typed vs implied/non-typed languages. But really it’s the collaboration between hardware and software engineers where technology really succeeds.
In the end, if we want technologists to be valued for the work they do, we need to do a better job of educating all of our users and society that there are hard problems that require training, skill and patience to solve.
I think it is funny that everyone is thinking that the pi is going away and the cause is that they are selling all they can make. I think that we have found out that there is a market for inexpensive SBC of many types. I would love an arm sbc with an m.2 nvme slot so I can put sata controller on it and run a good sized NAS on it. Or even one with a 1x pcie slot on it for the same task.
I would also like to see a pi zero with wired network connection. maybe even with POE.
The other thing is the bloat of Linux has very little to do with the pi. The bloat is pretty much restricted to desktop linux. I was pretty happy with how small you can get a bash interface Linux up and running.
right now we have a ton of options. Yes if you want cheap desktop you can get a number of cheap and powerful SSF and other pc of of Ebay and even amazon and Newegg. One of those with some TLC will make a great desktop for you. If you want to hack with it add a pico or ESP32 and you have a pc with extended IO.
If you want an even smaller form factor or lower power use get a Pi like board. If you want something even smaller get a zero like board. And if what you want to do does not require an entire Linux system then get a Pico, ESP32, or an Arduino like board.
The board I want to be more available is the zero-w or better yet a zero with ethernet.
But the thing is that we now have options, lots of options, and that is a good thing.
I would love to try and get a pico with HDMI or VGA out to run an PC or CP/M emulator. Think of all the old software you could get running on a very minimalist computer.
Or maybe a nice TRS80 Model 100/200 or Cambridge z88 replacement. Of course an ESP32 would work as well.
As I said good times to be into making.
Here is a Arm SBC with m.2. https://www.khadas.com/product-page/vim4
I bought it so I could do native compilations of large projects to static binaries. Notably it is painful as hell to compile something like Node.Js, I think period, but I wanted a static binary which was even worse. On a Pi it was taking 20+ hours, with 8 cores and 8GB of Ram it is slightly less awful.
But with a fan and with the price, I would have probably been better off figuring out how to cross-compile on my gen10 intel NUC.
The Khadas OOWOW bootloader thing is quite interesting. Swapping between distributions is very easy.
Yeah is at $200 I would look at a cheap atom ITX or sff x86.
There’s a ESP32 board made for running a really old x86 emulation or things like a Altair 8080 cpm emulator. Olimex ESP32-SBC-FabGL is the name, I saw it on cnx-software the other day. It has PS/2 keyboard and mouse ports and VGA out.
I’d be tempted to get one to play with, but I don’t have anything that plugs into those ports anymore!
Quartz64 from Pine64 have PCIe/m.2 (and gigabit ethernet) – they have 3 models for around 60-80 Euro and I have no idea how well it is supported but they seem to have active community.
Rock3a, you can put in a nvme to 5x sata adapter,’relatively’ cheap board
rock5b is more powerful, but it hangs/reboots for me in my use case
I think the SBCs should evolve to have more memory. Then we can run macOS for the M1 and have our cheap ‘hackintoshes’ again. :)
Right now, I think the big problem for Raspberry Pi is that the shortages have taken a toll on their possible future users. Right now most of the supply is going to established small and medium companies that have designed in the boards, but the next round of such companies have been forced to either abandon their plans or turn to some other product because they can’t get enough Pis at a reasonable price. Similarly, a couple of year’s worth of individual makers have been stymied by the lack of product, and some of those makers would have eventually grown into small companies or created projects that posted online and replicated by a bunch of other makers.
Raspberry Pi first needs to catch up, and then take measures to assure people that these kinds of shortages won’t happen in the future. And given their original mission of aiding educational use, they particularly have to find a way to assure availability for individuals. This may involve designing their own chips, as they did with the RP2040, rather than continued dependence on Broadcom. A big problem with Broadcom is that they’re not in the business of making general purpose SoCs; the ones they make for Raspberry Pi are the only ones they make and they don’t sell them to anybody else. (It’s impossible to manufacture a full-on Pi clone; Broadcom won’t sell you the chips.) Broadcom’s main business is more specialized SoCs for things like routers and set-top boxes, likely at much higher prices than it charges for the Raspberry Pi chips.
One reason that the RP2040 is so readily available, at least so far, is that it’s uninteresting to a lot of the big volume users of microcontrollers. The chip has no code security features (it can’t because the code is stored off-chip, but I suspect they would have been left out even if the chip had its own flash) so most of the big volume users will never adopt it; the RP2040 will never show up in a car or a medical device. It’s only suitable for open source devices. It’s also produced on an old 40nm process node that there isn’t a lot of competition for — though TSMC has announced plans to sunset it so the next generation Pi microcontroller may have to move to something a bit more modern. If it’s ever affected by shortages, it’s far more likely to happen because of availability of QSPI flash than of the microcontroller itself.
If a future Raspberry Pi moves to a different processor, either an internal design or by partnering with another chip maker (Allwinner and Rockchip are the most obvious, and other companies like MediaTek could also be considered), they will have a lot of software work to do. One big appeal of the Pi is that their OS pretty much Just Works, something that the makers of other SBCs based on those other chips can’t claim. If they choose an outside partner they would face the free rider problem; whoever else is making SBCs using the same chips would also benefit, and would likely be able to undercut the price of a Pi because they’re not spending money on software development. Then again, that might not matter; commercial producers might prefer to buy from a known quality source. Adafruit sells a lot of stuff even though cheaper clones are available — and legal, since Adafruit products are open source hardware, you just can’t use the trademark.
Problem with that argument about the shortages is that you haven’t noticed the other SBC also didn’t have much stock if any at the height of the chip shortage – the chip shortage smashed everyone to some extent. But so many SBC out there maybe there were some good ones I didn’t notice that managed to ride the shortage out, as it doesn’t matter if you kept in stock the crap nobody wants even when they are desperate for a SBC…
And with how awful the Car’s onboard system security is in most cases a RP2040 is bound to turn up in them, often, in the end as they are actually available, really really versatile, and cheaper than most rivals… Just give it a while for the new product to pick it as the cheapest option. Lacking some features for some of the big volume user is perhaps a valid point, but on the whole the 2040 can do almost everything quite well with fast core for a micro and the PIO, it just hasn’t been around that long yet.
There’s also speculation that due to prioritising business clients over being a charitable, Education-focused not-for-profit entity, the RPiF will find it increasingly difficult to benefit from that Broadcom relationship in the same way (i.e. price goes up)…
i think you raise an interesting point about the possibility of being undercut if they used a more widely-available chip than the broadcom garbage they use today. it’s interesting because they already are kind of exploring that territory with the pico. the rp2040 is a unique chip but the pico board itself is, from an end user perspective, competing very closely with the stm32-based ‘blue pill’ sort of boards. roughly, i can buy a pico for $4 or a blue pill for $3. i’m not sure how everyone else feels about it but to me the pico is the clear winner. i would far rather have the reputable pico than the “everyone knows the manufacturer put the wrong resistor value in it but they’re still selling it that way 5 years later” blue pill. given that context, the price difference doesn’t exist to me.
i personally hope that the blue pill disappears from our hacker culture as more people adapt to the pico ecosystem. to that end, i am gonna again promote my alternative to the official raspberry sdk http://galexander.org/rp2040 (i hate all embedded SDKs, it’s nothing personal), for actual bare metal programming.
anyways, if the pico succeeds, then i think it would show raspberry that by making a quality product they can compete even in an apples-to-apples field with the kind of offerings that show up discounted on ebay, full of caveats. i mean, it’s possible some knockoff could use proper components and make a quality product and still undercut them but it doesn’t seem to be the way of things.
There are already Asian Pico clones that you can buy from companies on AliExpress for less than the price of an official Pico; the shipping cost gets you back around parity if you only want one, but they’re well ahead on a larger purchase like 10 or 100. Some of them have nice features like additional flash and a USB-C connector in place of the Micro-B. (It’s still only a USB 1.1 port.) You can even get them with different colors of circuit board, including purple and pink. All legal; the Pico design files are open source and available for download from the Raspberry Pi site. Many of the clones lack the castellated edges, so shop carefully if that matters to you.
There are also some smaller form factor designs, the most common of which is called RP2040-Zero by a number of sellers.
Other than the typical “more cpu” and “more ram” requirements, in SBCs / SoCs I strongly miss 2 things:
– PRU/PIO: Programmable realtime units (ie: TI-SITARA) and the PIO on the RP2040.
– HW pin routing/multiplexing: Cases like the strange SP7021 allowing you to assign ANY function to ANY pin from the DTS.
More and more SoCs include a companion multipurpose ARM cpu that helps with some tasks, etc but lack of specific programmable IO hw and pin routing capabilities makes it very difficult to interface external hw, specially when this hw doesn’t use the standard ways like i2c,spi, uart, usb, etc.
IMHO these 2 features would make a dream maker SBC and for sure a very versatile industrial system.
yeah! the GPIO on the ‘big’ rpi boards is nice but linux is a poor fit for that kind of low-level interface. they should just throw an rp2040 on the board with their next pi offering so that the IO can be off-loaded to something that is more well-suited to the real time requirements.
otoh, i am basically living that world simply by having an rp2040 hanging off a usb port on an x86 nuc. :) in some sense, there’s no point in doing it because it’s already basically here (and i love it!)
Check the new beaglebone: https://beagleboard.org/play
It comes with “Dual-core PRU subsystem @ 333MHz”… no less than 2 processors dedicated for GPIO running at 333Mhz and sharing the RAM with the cores running linux. You could implement ridiculously fast protocols on that stuff and get rid of the usb.
It costs nearly $100. And for all that money you’re only getting a quad core A53 at 1.4 GHz and 2 GB RAM; its main processor can’t match the performance of a (theoretically) $45 Raspberry Pi 4. Not really in the same class as the Raspberry Pi. The onboard features like the separate Arm Cortex M4F controller and the programmable I/O will make it appealing for some specific applications, but it’s not likely to sell in huge quantities.
The best thing about the BeagleBoard products is that they are 100% open source, hardware and software, and do not contain any components (including the TI SoC) that are not available for others to buy. That matters for some applications. But they haven’t been competitive for a long time when measured by price vs performance.
What’s next? Instead of something ‘new’, just get the boards in ‘stock’ at normal price levels!!! I have three robot kits that I’d like to add a RPI-4 to for example. Yes I could scavenge from those that I have, or run with a PICO-W, but rather just pick the RPI-4 to handle, for example, video input for tracking and object identification tasks that may come up.
Future wise, I don’t see the RPIs going away. They are very useful devices with good software support. Haven’t found one thing ‘missing’ with PI OS that I ‘wished’ was there. Now, as a hardware upgrade, I’d like the USB 3.0 sockets to be able to handle more power for direct plugin of SSDs/HDDs or other devices — without having to add a USB 3.0 powered hub to handle the job. That is about the only complaint I have with the RPI-4 now. With USB 3.0, gigabyte ethernet, swimming in memory, Wi-fi, fast CPU, plenty of I/O, plenty of comm options to interface with, and lots of hats for anything else… Can easily interface to the PICO for those real-time needs and a few analogs as needed… What’s not to like? The HDMI interface is secondary to me as most of my projects run ‘headless’. Nice it is there though if one needs a GUI of some sort. Again what’s not to like?
Could make sense to focus predominantly on putting out as many CM4 as possible but also taking a leaf out of Waveshare’s book and producing carrier boards that convert the CM4 to the RPi3B+ and RPi4B+ form factors – BUT with USB3, rather than USB2 in the USB-A ports and USB-C instead of μUSB for power input…
Seems like a good idea there. Make a ‘carrier’ board like the RPI-4 form factor, and just use any of the CM4 optional boards that meet our needs. Only downside is it would require buying ‘two’ components instead of one, but it ‘would’ be more flexible. Hmmmm.
Why would it “require” you to order both the CM4 and such an adapter carrier board? You just order the adapter if you specifically want to use a CM4 in a case originally designed for a RPi3B+ or a RPi4B+, if you don’t want to use a CM4 in such a case then use a different carrier board?
The key advantage a Pi has over microcontrolelr boards is that it can easily run a (fairly) normal Linux OS, so you can interact with it comfortably in real-time via terminal or GUi when developing/debugging and can have normal file systems, a ready made networking stack and the ability to use most of the tools (so long as not pre-compiled x86-dependant) you can on a normal linux system.
The advantage of the Pi over x86 (usually a more convenient architecture for most things) systems is a smaller size and easier to power (just 5V on USB). Plus clearly documented IO pinouts. Packing a cheap desktop PC in to robot chassis or handheld device isn’t practical, a Pi will fit there though.
Until there’s another SBC which by defualt runs a full linux OS with GUI and terminal options and is small and easier to power (except some of the Pi 4 versions perhaps) with clearly explained IO which the OS can easily make use of (C BCM2835 library, Python PiGPIO…) the Pi will have a unique place.
Remember the raspberry pis are based on the single source broadcom CPUs that is not necessarily mainstream, which contributes to low availability and weird software problems like the closed source graphic or wifi drivers. The original pi was designed because Broadcom had a canceled project and millions of CPUs that they couldn’t otherwise use so they were happy to see them used in the Pis.
Didn’t know about the broadcom’s cancelled project, is there any additional information about this?
Wasn’t it meant to be a STB for TVs?
https://forums.raspberrypi.com/viewtopic.php?t=119338
BCM2835 was an EOL design that was being used in some arguably neg-growth Symbian and ROKU products, so Broadcom was motivated to extract final profits before shutting it down. Eben worked for Broadcom so he was familiar with it, and negotiated a good supply contract.
please remove BLOBS !
that is important
+1
Absolutely! We need to be able to run FLOSS firmware (especially boot) on the RPis
I’d like that, I really would. FOSS coupled with similar hardware really appeals.
But I don’t think it is that crucial for the Pi, or really most computing in general. Better for almost all users to have functional, stable, performant hardware that passes all the regulatory stuff globally so you can actually buy one easily than avoid all blobs. Much as I hate ’em it just isn’t a big enough issue for most people to be worth the expense to make possible, and there are a few products out there that can be run blob free for when it really matters. Assuming you can put up with hardware that is glacial in pace even compared against much much cheaper hardware with the odd blob.
If you want that, you need to support people that do that.
What next for a sbc?
64-bit VM Intel MCS BASIC-52 stand-alone OS built to Boeing hardware engineers’ software standards?
No software module longer than ones page of code;.
Well, you asked for comments, and this is simply where I am coming from —
1 – I have no interest whatsoever on running a linux desktop on an SBC like the Raspi
2 – I use these sorts of things for little headless, maybe you would say dedicated controllers
3 – Quality detailed documentation is perhaps more important than anything since I often
jump to bare metal coding for many embedded projects
4 – Low price is important, more features not nearly so much
I am perfectly happy if the card has no video, I would gladly trade that for say eMMC on the card.
For a linux desktop, I run whatever the latest x86 hardware is. Contemplating ARM in that arena is an entirely different topic.
I’m so tired of x86. It’s had a 45 year run, which is a testament to how much a badly-designed architecture can succeed, but it’s time to put it out to grass.
I hate the x86 architecture, but I don’t hack on it. I hack with it — I am using it now to run my browser and it runs my compilers and tools. So it provides me cheap and fast tools to do things I want to do.
All my hacking though is done on ARM hardware (using the editors and compilers that run on my x86 desktop). I really just don’t care what the hardware is that runs those compilers and editors. I just want them to be stable and reasonably fast. I don’t want to monkey with the linux distro (in fact I don’t really care what the distro is — I just want it to get out of my way so I can get to my editor, and compiler and such). If x86 gets displaced by ARM someday in that arena, that would be fine, but I’m not losing any sleep over it.
This. On a desktop computer the processor architecture doesn’t really matter to most of us; you’re not likely to use it in a way where you interact with the architecture directly enough to care. What matters is that you can get a computer that suits your needs, that you can hook up the peripherals you need, and that software to do the things you want to do is available.
On a microcontroller or an SBC, the architecture matters more. You are far more likely to use those things in ways where you interact with it directly, such as writing device control code or hand-optimized loops for some specific situation where speed matters.
You can run the Raspberry Pi or Arduino (relevant for the Pico) tools on any desktop or laptop computer that supports them, whether it be a Windows box, a Mac, a Linux system, or even a Raspberry Pi 400 (though not the new Arduino IDE yet). The experience is pretty much the same (aside from speed) no matter what you use.
Tired of it? Not me. With the compilers and tools, cross compilers and tools, editors, and more tools, browsers and applications… Well, the point is you don’t even notice you have an x86 that you are working on. So what’s there to ‘hate’? It works, fast, does the job very well. From a user stand-point, x86 is no big deal. Basically agree with ‘Sever Tire Damage’.
It’s our grandpa’s CPU. No longer the cool kid on the block.
Got it…. Much like the ‘language’ darlings of today. Just because language ‘a’ is 40 years old, it must be bad, but because ‘r’ is only a couple years old it’s wonderful and it becomes the new cool kid on the block :) … for a while… Yep. Understood!
“Just because language ‘a’ is 40 years old”… Yes, but the problem with Pascal is that it got some ill-considered early extensions courtesy of UCSD and Borland, and was then gradually bloated to become every bit as unwieldy as the “4GLs” that were popular in the late 80s.
Now it might be that you weren’t actually thinking of Pascal there, but it’s a good example of a language which was designed with a modicum of type checking etc. But the “cool features grafted on” problem affects just about every older language: I’ve spoken to COBOL users who hold it up as a paragon of a well-implemented language because it now supports objects and block-structured flow control.
Whatever our taste in language, we have to learn not from implementations such as Go, Dart and- of course- Python which are basically “more of the same”, but from things like Rust which take the approach that only stuff which is actually /needed/ should be in the core language.
And just as stuff grafted onto a language is bad, we really do need to ask ourselves whether all the frills added to ARM are really the best way of going about things. And the community needs to stop itself from adding things to RISC-V simply to keep up with ARM. In principle at least both of those were clean-slate designs, unlike the 8086 where Intel was doing its best to rush something out while at the same time contending with the iAPX architecture baggage.
– onboard eMMC, in addition to the sdcard. eMMC needs to be bootable, obviously
– barrel jack for power, with some reasonable input range ( say, 5V to 15V, with matching current )
– connectors for external things ( usb, hdmi, etc ) arranged on the same side of the board , to simplify connections and installation inside things.
– m.2/nvme or sata connections on some models would be a plus.
– two ethernet interfaces
The fully replaceable memory is a benefit versus emmc, though I am tempted to say it’d be better if it were still one of the larger memory card types that may last longer than microsd despite the space savings. PCIE for the m.2 and adapters would be nice for certain applications where you’d currently use a different device like a nuc, but even sata may be pushing it. A variable input voltage range would be nice, maybe via POE. Putting connectors on the same side doesn’t seem worth much effort, cost, or size imo. Instead of two ethernet interfaces, for the performance range of a pi I think you may be better off with vlan tagging and a vlan aware switch, especially if they went the POE route.
Raspberry Pi are nice for experimenting. And I run a small print server on an old pi1 that turns a usb printer into a network printer. For anything more, I want decent storage, Either add m.2 or sata or pcie, Don’t care. Just not sdcard (or usb) only. That’s why I got a used miniPC instead.
orange and banana pi are better than rasp with EMMC onboard…. And lower price!!!!
Isn’t that the point of the RPI? I use mine mostly for ‘projects’. Not for ‘desktops’. Buy a miniPC or full blown workstation in the desktop/server/workstation category. Don’t make the RPI out to be something it is not.
it seems that raspberry 4 has not yet EMMC onboard as banana orange ans other clones have yet… Raspberry will not be a real SBC until it will continue using SDcard for system, which is dramaticaly a mistake… Why clones integrate EMMC but Raspberry not??? it’s not a problem of price…
For some applications I boot from an external SSD. In fact I have two systems right now that are just sitting there running off on Samsung T5 and a T7 (500GB version). Granted a EMMC would be more than a bit more compact….
The key advantage a Pi has over microcontrolelr boards is that it can easily run a (fairly) normal Linux OS, so you can interact with it comfortably in real-time via terminal or GUi when developing/debugging and can have normal file systems, a ready made networking stack and the ability to use most of the tools (so long as not pre-compiled x86-dependant) you can on a normal linux system.
The advantage of the Pi over x86 (usually a more convenient architecture for most things) systems is a smaller size and easier to power (just 5V on USB). Plus clearly documented IO pinouts. Packing a cheap desktop PC in to robot chassis or handheld device isn’t practical, a Pi will fit there though.
Until there’s another SBC which by defualt runs a full linux OS with GUI and terminal options and is small and easier to power (except some of the Pi 4 versions perhaps) with clearly explained IO which the OS can easily make use of (C BCM2835 library, Python PiGPIO…) the Pi will have a unique place.
One is not better than the other — they are just different project scales. We have ARM microcontrollers on one hand (like the pico or STM32 blue pill) and we have bigger ARM sbc that are capable of running linux. Apples and oranges. Each has its pros and cons and appropriate use cases.
If you want anything resembling real time scheduling and fast access to IO, you don’t want to be running linux (I hear the howls and screams already). But if you have appropriate drivers and need a high performance network stack, building on top of linux is often a perfect choice.
Well I think the RPI has always be the most versatile SBC due to the ecosystem and peripherials. In combination with the ability to run from batteries, I don’t see a reason to ‘limit’ it to special features like NPU, CPU performance boost or dedicated busses like PCIe slots, … . IMHO this would limit it to very specific usecases because it makes other usercases less practical. For example I use it as companion computer on drones / UAVs where weight and power consumption are essential parameters ;-)
I am waiting to build a new product platform around an SBC with at least 2-channels (left & right) of quality analog input. That is at least 48 kHz sampling, 4 ms or less latency, with an integrated preamp for each channel. Many have no mic inputs at all. Still others have 2-channel input hardware, but they only populate a single input for a microphone. I haven’t found any with an integrated preamp. The closest I can get to that is a 40-pin hat that is reasonably inexpensive, but clunky from software standpoint, and awkward for packaging into an enclosure.
I just want a SBC that’s compatible with most if not all the rpi nonsense on the market because I see a cool kit and then am upset when a pizero costs more than the entire kit.
I’ve been in the x86 hardware space for a decade and in the ARM hardware space for not quite a decade. My take is that anything ARM based struggles to shed its embedded roots to be a more general purpose computing platform.
In these comments, people repeatedly bring up ‘software’ as a major issue with ARM SBCs. But why is that STILL such a problem? After working in both realms, my perspective is that it boils down to the PC being more than just a collection of hardware interfaces, it a set of firmware and software interfaces too. The embedded world have been VERY resistant to adopting a comprehensive set of standards that would better enable multiple independent groups to share responsibility for the ecosystem.
The one place I have not been able to get away from SBCs are those that focus on image capture tasks. And those often need Pis because the state of the software for the capture interfaces for these SBCs are so bad. Want to build a decent DIY IP camera? While there is the ESP32 cam, right off the bad you will sacrifice frame rate and resolution. Everything with a CSI-2 interface suffers from affordability problems. Everything price competitive with Pi Zeros and Pi 3s use ancient camera interfaces and aren’t well supported by the distros needed for the rest of the software stack.
Because of the shortages, I’m trying to go a Pi free route with my future projects because we’ve seen just how devastating such a shortage can be. But other than using something like a NUC with a USB webcam, I don’t see anything that could be really considered a viable Pi alternative for high-ish performance camera based projects.
I am not so attached to x86 vs ARM (or even RISC-V…) but I would really like to see someone producing something with Debian support and a similar-sized board to the RPi Zero W 2, for $20ish. To me that’s the sweet spot for small projects, I’d like a full OS for networking, NTP, cron, etc. Obviously an SBC that can drive a monitor and run a desktop OS needs to be bigger and stronger (and thus more expensive), but for little headless servers the Zero is great and I haven’t really seen a good alternative yet.
I just want one thing from Raspberry Pi: inventory.
👍
Many comments call for features (like SATA, PRU or eMMC) which competition offers for many years. Apparently RPi competitors are not competing good enough because even now with RPi being unobtainable for over a year there is no real transition happening. I can understand big volume players are not willing to redesign their products but hobbyists? So apparently what we need is better competition that learns from RPi and Arduino success stories (bring better software and documentation support).
People are lazy and/or lack skills. There are lots of cookie cutter projects for the Rpi. Working with the other boards requires more in depth knowledge. The flip side of this is that “being on the bandwagon” allows you to be lazy (Larry Wall called laziness one of the virtues of a programmer).
On a lot of these boards, its *really* hard to get this stuff working on a distro that will also support the other software. Until embedded developers understand and adopt a mindset more like what exsists in the PC hardware world, this will continue to be a problem.
I’d like to see more viable variety. It’s kind of famous how the other fruit Pis just really almost aren’t worth their weight in fresh topsoil, but I especially worry about the knock-on effects of the Pico’s popularity… how that affects things like the Arduino. I’d also like to see a cheap but powerful desktop-oriented board, which is something the Pi really doesn’t do well on its own.
Honestly, my personal philosophy is that the Pi is very much a solution in search of a problem, and outside of running a MAME cabinet I’ve encountered IIRC maybe one use case for it ever (and I don’t remember what that was!) where I couldn’t instantly think of a better option — and convenience doesn’t count.
But far more my concern is for what the Pi and the RP2040 are potentially choking out of their respective ecosystems as far as alternatives and the like.
Normally I’m very much a collaboration-over-competition kinda guy, sure, but I grew up on a small farm in the waning days of the Back-To-The-Land movement, and I don’t need a hassled sprig in my mouth to tell you that reliance on a single cultivar is bad news, sooner or later. Ask any Irishman — the Potato Famine would’ve been quite a bit lesser for it, if they hadn’t almost all been growing the same exact kind of potato!
The popularity of the Pico may finally put the AVR to rest; it has been getting mass adoption on a scale that none of the other Arm-based Arduino products have. But it’s not hurting the Arduino ecosystem; lots of people are using the Arduino IDE to program the Pico, and there is an official Arduino board with an RP2040 processor.
That’s what most concerns me.
Other relevant examples would be cable television and electric power service providers within the US, and the government-subsidized and in certain ways -mandated strangleholds they place within their territories.
Mind you, I live in North Carolina, the state where, in 2008, Duke Energy literally bought the dang state by way of the governor’s election to facilitate a merger with Progress Energy. The result was Duke Energy Progress — the largest electric utility company IN THE COUNTRY and by a /quite/ considerable margin at the time — along with a lot of false promises (lower rates, better regulation, etc etc etc) that were broken almost before the deal was done, they went down so fast. No, really, we kind of openly talk about it around here, and I’m in a small town (~10k people or so) that’s an hour’s drive from absolutely anywhere of any possible meaning or relevance to society — as in, not only have you never heard of where I live, basically guaranteed, but you’d have to drive at least an hour to get somewhere you /might/ have heard of, maybe.
Duke is absolutely shameless in their profiteering here, and to say that they’re hated amongst the general public isn’t diplomatic, it’s obsequious to the point of moderate obscenity. We get along like NATO would with an actively nuclear-armed DPRK.
As much as I hate to admit it, like I said — competition has its place and its virtues within that place.
Long live the AVR… and may the other fruit Pis get their $@*(&$#!! together at some point. There simply /must/ be more than one.
Slightly off topic but isn’t that a misnomer about the IPF? Sure, those growing the same cultivars were decimated but not even most Irish potato farms were? The greater problem was the English hoarding grain and shipping it to England for themselves, then burning the roofs of the buildings from which the destitute Irish labourers had been evicted to prevent them from being able to squat. Hence why “famine” has come to be known more as a euphemism for genocide… Even as a famous work of satire, Jonathan Swift’s “A Modest Proposal” was quite eye opening in that regard.
You’re missing the forest for the trees. The historical allegory wasn’t the point.
If you want to nit-pick through such things, however — fine, see one of my more recent comments, immediately above, regarding public utility companies. Same poo, different sewer.
I don’t think it’s unreasonable to consider the convenience of a service being supported well enough you can just install and update it out of the repo’s, which rules out some of the less common platforms. So that being said, if you want to run a few off the shelf, potentially high level services on a networked device at the same price point, size, and power consumption, what are you going to use that’s not very similar to a Pi?
Say you want a basic web server, a vpn to your home lan, and/or maybe other less-intensive services like streaming or interfacing with hardware sensors or controls or even accelerators. Maybe a print server, maybe some smart home / digital assistant stuff. Just all the random things you might want to do, but don’t need a dedicated server for, potentially including some python project you found that seems neat even if there’s a million dependencies.
If you want to use the cloud for most of that, you lose the benefits of being local, and any hardware interfaces. If you want a more performant local server, you might be able to run more demanding services but the pi-like sbc’s do have an edge in minor extensibility, and you’ll need more power, money, or space otherwise.
When I said I’d legit never found a use case for the Pi outside of MAME I wasn’t kidding. Because it has a proper OS, even with an RTOS kernel, it will be far, far slower than a true microcontroller — Linux’s “everything is a file” paradigm is great and all, but it’s not built for speed, to say the least. In fact, it’s /so/ slow that it’s really not suitable for most microcontroller-based tasks; you need an ARM uC or an AVR or somesuch for that, something you can program bare-metal. The BeagleBone Black gets around that with the PIO stuff that the Pi Pico kind of cheat-copied, sure, but the bigger Pi boards just don’t have that.
It’s really not practical to use the Pi as a desktop system, either, because it’s missing too much (proper power management, for example, and anything even /vaguely/ resembling BIOS let alone UEFI) — and by the time you compensate for that, you’ve got such a three-eyed, green-skinned, betentacled monstrosity of technology that it’s more warts than it is toad. That’s not a bag on the side of a decent machine, that’s not a kludge, that’s the tech equivalent of what happens when H.R. Giger and H.P. Lovecraft get a room together. (Ewww.) It’s /well/ into the realm of things where TheLexiKitty just pulls out the giant Nerf Gatling, cocks it noisily, and yells “NO!”.
Building a Cyberdeck? If you actually NEED enough of a buttload of processing power to hang an “oversized load” sign on its caboose, use a NUC board. Otherwise, something like a Compute Stick clone/compat or an eBay/Amazon issue “Windows 10 Mini PC” is more what you should be looking at… or, if you’re willing to compromise on computing power enough to drop your power draw absolutely through the /floor/, look at something like a Wyse C-Series thin client, or (at most) an HP T610 Plus “flexible client”. Modern processors are /stupid/ powerful. Heck, a close friend of mine has done video editing on a Celeron N4000 based system just to prove a point. (It’s actually reasonably doable if your needs are limited and you’re willing to hate yourself a little.)
Something more like an industrial PLC? Get a microcontroller. Pis are too slow.
Cheap desktop? NUC, “Windows 10 Mini PC”/etc, or rehab’d thin client, per above… or, heck, skin a laptop and make it dance for you.
Retrocomputing? If you can’t be bothered with real hardware because it’s too inconvenient or juuust too haaaaaaaaaaaaaard (ugh /rolleyes ) — get a dang emulator and shaddup. I’m sorry, but the whole /point/ of retrocomputing is to experience it like it once was. Start adding on modern power supply connectors and HDMI and all that, and you instantly lose the spirit of it. I have the same problem with ESP32s — and especially RasPis — strapped to the back of eg Commodore 64s as “wireless modems”. For freak’s sakes, that one friggin chip has more power in it than the C64 could ever /dream/ of. Get that mess out of my sight — and if you’re one of those horrible, horrible people who strips a perfectly fine vintage microcomputer of its guts, rather than learning how to troubleshoot, just coz it didn’t boot the first time you pulled it out of your grandmother’s attic… you are a disgrace to your own species, and may whatever gods you pray to have mercy on your eternal soul, because I will not, and if we ever meet, I will absolutely lecture you clear to oblivion and back again, /twice/, at volumes and pitches you thought only smoke alarms and back-alley cats were capable of, on the crimes you have committed against humanity, against history, and against technology, /and/ /you/ */will/* /deserve/ /it/. May your Minecraft dog get blown up by three Creepers at once, and may every Steam purchase and microtransaction you ever made get burnt in front of you by a Nigerian scammer. Git rekt.
*Ahem.* Sorry, that one’s a bit of a soapbox for me. You… er… /may/ have noticed.
Portable computing of any kind, however haphazardly assembled? Again, reeducated thin client, Compute Stick knockoff, skin’d laptop. Honestly, probably the laptop choice is best. Fun fact, if it’s got an eDP screen — there are exactly two connectors for that, and as long as you use a display with the same exact connector you will be fine. For a long time my main system was a Lenovo laptop of some sort that a neighbor gave me because something baseball-sized and -shaped absolutely /obliterated/ the screen. It was originally a 15in multimedia-oriented budget laptop. I bodged on (badly) the 11.6in screen from an Acer C720 Chromebook and it was FINE. eDP is eDP is eDP is eDP is eDP. The screens are 1000% fungible, have fun.
Literally the ONLY use for a Pi I’ve ever seen that was genuinely legit is as a MAME cabinet’s guts — and then only because of the support things like Porta Pi Arcade provide. Stuff it inside a repro OG GameBoy case, with a compatible backlit screen, for ultimate hyucks… or build a real arcade cabinet, heck, I won’t judge… not /that/. But the only reason this actually works out is because of the software side.
Hardware-wise, the Pi is absolutely 100 000 %+ a solution in search of a problem to justify it. If you’re not using it for a MAME cabinet, I positively guarantee you’re whacking it in somewhere because of convenience. You have it on hand, it’s the 11th hour, and you just want your contraption to dang well /work/ already. It’s the same Arduino vs 555 argument all over again. If you have some sort of super critical deadline you’re up against, sure, I get it — but for the love of all that is sacred and good in the world, after that’s over and done with, rip that mess out and do it /right/. (…and if you can’t be bothered, shame on you. My maternal grandfather used to say, “Everything worth doing is worth doing well.” and he was absolutely right.) Expediency is fine, but not in a permanent sense.
Montgomery Scott himself put it best. “Use the right tool for the right job!” As far as I’m concerned, that tool is almost NEVER a Raspberry Pi.
…oh, and for the record, I’ve never actually built a MAME cabinet, either. I’m not enough fun at parties for that kind of thing.
I can agree with some of what you said; I wouldn’t choose a Pi instead of various individual formats of better computer – although I might be willing to use one for the fact that it is a lot more generalized than most of the “better” alternatives. For a lot of the alternative small computers, you either pay more or end up with a unique device because you bought it used and the model hasn’t been made in years, and any time you have much trouble with it you might as well start from scratch again.
I can definitely agree that small form factor true desktops are more suitable for certain things; some of the NUC’s can even run a full size GPU with an adapter. But a lot of those sorts of device aren’t fanless and may or may not be something I’d feel comfortable neglecting like the Pi’s. I should look at what thin clients are like nowadays, but the last time I looked they didn’t look like they would wipe out the pi niche.
In the vein of arduino vs 555, or logic versus lookup table, if using a pi will meet all the requirements without issues, and will free you up to make all sorts of later changes while still being able to keep things simple, don’t be too eager to move to a more specialized format. The big ways to use a pi that I find hard to argue against at the moment are the “I need a computer to interface with a bit of hardware without reinventing the wheel; I can’t use an old laptop or nuc that was lying around, so I need something cheap with at most a cheap accessory to do whatever I wanted” edge device and the “I would run these services on a potato if it had an ethernet jack; I am never going to look at it again once it’s plugged in” micro-server. Maybe also “Just give me something cheap and effective that can be replaced or reprogrammed quickly when it inevitably has a problem” beater. Or “I need to do some random thing you might not have heard of that normally requires dedicated hardware, but apparently there’s 450 projects doing that exact thing using a pi and a couple bucks worth of components.”
In the case of the first three scenarios…
Thin client or MiniPC with an FT232H breakout, or — if you can do what you need on a sufficiently obsolete processor — the old LPT1-as-GPIO trick. (Best not to expect this to work on anything newer than Pent2/Pent3 era machines, especially laptops). I’m told that there’s also ways to do this with OpenWRT and a crappy router, but I never learned how that actually works.
In the “potato server” case in particular, an ESP8266 or ESP32 configured as a webserver, running off a one-cell power bank and a 3v3 switcher regulator also comes to mind.
In the lattermost case… if you can achievably reinvent that wheel, I support doing so simply for the sake of technodiversity. Example: one of my many on-again-off-again projects is an electric typewriter using a reciept-style printer and a keyboard from two sadly very destroyed, entirely different vintage microcomputers (Adrian Black is NOT kidding about NiCDs, kids). I could throw a Pi or Arduino at it, sure, but my “programming language” is 7400- and CD4000-series glue logic, so I’m doing it up Eighties-style. Why? Because I can, and because it fits my very bizarre idea of what ‘fun’ supposedly means.
Interesting perspective. I can respect it; I just tend to find it hard to motivate myself to do things the “right” way if the results-versus-effort doesn’t work out. If hypothetically the “right” way to address voltage drop making my headlights dim is to redo the wiring harness, clean contacts, and generally upgrade things to increase the capacity, I’m probably going to just piggyback a relay to bypass the whole circuit. Or get led headlights if there happened to be a good option. The interesting problems are the ones like your typewriter; the main reason I’d consider something more advanced than the basic stuff that lasts decades is if I wanted more features like maybe automatic weather reports in the morning.
I like SBCs, but the market never felt like it Matured and atm is rather mixed.
Many alternatives exist, yes. But almost none have Operating Systems that isn’t in some stage of early development. If i want to integrate a proper SBC system in a project on the quick: There are few that actually cover all the basics needed. It seems that everyone can make a SBC these days hardware-wise, but software-wise there is a serious case of neglect and making it the problem of users under the guise of being “Community-driven”, which turns out not a lot of people want to bother with and i will admit: myself included.
The Raspberry Pi is far more mature and one can just pick one up and shoot off, but we are dealing with the reality that they are close to unobtainable in some regions with lead-times from 4 months up to a bloody year depending on which store you ask!
The pi had one thing really going for it, the the masses. It is often said that the pi has great software support, and hat is somewhat true, but its the masses that made it get there.
The problem with all these other SBC’s is that they tend to be eastern hardware companynies. Designing and manufacturing a board takes a few months. The software can take years.
On top of that, they want to maximize profits (obviously) and software is overhead, so they end up just relying on whatever bsp the soc vendor gave them. And that’s where the deathblow comes in.
You end up with old/ancient kernels, blobs without upgrades, blobbed bootloaders etc.
The community worked hard on liberating all winner socs and AFAIK the results are pretty good. AFAIK rockchip is doing a lot of it themselves even. This is what distros like armbian need to turn these crap boards into great boards.
In short, if there is no series mainline effort, forget about it. If there is no armbian builds, forget about it. With those two in place though, software ‘support’ is probably on par with the pi.
As for docs, that’s where you get your masses helping you. People doing a project, documenting it. That remains a powerful thing. Even if the how to is probably applicable to 99% of the other sbcs.
@Hackaday what on Earth is going on?! Yesterday there were over 70 comments beneath this article. Today there are just 14 (15 if this one gets published – and remains published)!
Interestingly they now appear again. As of writing this comment, the count currently stands at 80 (including this comment).
I’m very curious to see the results of this partnership between Sony and RPi: https://www.engadget.com/sony-investment-will-put-ai-chips-inside-raspberry-pi-boards-083503462.html
I’m not. Sony is famous for overcharging for features nobody asked for.
And closed $ource.
Suggested new upgrade for the Rasberry Pi. Either take the 6 A/d inputs and expand the number of bits per sample from 10 to at least 16, bot 24 would be preferable. And make the sample rate go up to 192Ksps. Now the Pi could be used as a high fidality sound recorder. 6 channels would allow for Dolby 5.1 encoding.
Or add more high fidality analog inputs. Oops.
eBay is flooded with netbooks and laptops and mini PCs. I have no o
interest in trying to use an SBC as a PC when I could get something better for half the price.
Instead I think SBCs should focus entirely on embedded controls, signage, home automation, and that kind of stuff. First order of business should be builtin battery backup and real time clocks.
Keep the SD card and don’t bother with the eMMC stuff. SD cards are cheap and most importantly easy to swap out and debug.
And ditch HDMI now that USB-C exists. Maybe even ditch USB-A, there’s a ton of wasted space that could be saved if they went to all USB. Keep 3.5mm though, as these get used for media a lot and are mostly used in stationary applications.
Aside from that, just focus on firmware. The stock OS needs to be SD card friendly out of the box. Get rid of any nonsense that spams logs, include an official way to run as a kiosk that won’t destroy the SD card, make sure all the cool machine learning stuff is in the standard repos.
Better yet, just ditch normal Linux, and port some of the Linux userland features and Systemd to Android. They already run so much better than Linux on low power devices. I’d be perfectly happy if Android took over servers and embedded too, everything just works.
A few buttons and a small display wouldn’t hurt either. I’d much rather have a tiny 1″ LCD for status display and doing setup than a faster processor or more RAM or some other upgrade that only makes sense if you’re trying to compete with desktops.
Port systemd to Android?
(Gag!)
If I lunch on a RP2040 and a Compute Module 4, will I be full?