Compare Single Board Computers
sbc.compare
sbc.compare
Before getting into benchmarks I would actually look which hardware capabilities a specific SoC supports first (eDP, HDMI or LVDS, USB ports, i2c, GPIO pins etc). Then I would check whether the manufacturer actually maintains mainline Linux kernel drivers or keeps an up-to-date downstream kernel. I look at their frequency for updates. For media systems having HW acceleration is crucial. Most ARM vendors do a crappy job of providing good open source drivers for this.
Similarly I go and check their Yocto BSPs. If I don't like their organization, that's going to affect my final decision. If it is a power-sensitive project, then the special modes and extra driver support for various sleeping modes come into play.
(Most of the time Intel just wins with those criteria because ARM ecosystem is a mess of proprietary blobs. However there are manufacturers like NXP and MediaTek who do release passable drivers and when power consumption is important they get selected or if the product is very price-sensitvie)
This website looks alright maybe for hobbyists for pure CPU loads with very well cooled systems. I don't find it very useful without the actual engineering details, adding those would massively benefit the website.
I wrote a blog post about why I made the site at https://bret.dk/introducing-sbc-compare/ if anyone's interested, but to TL;DR it, I didn't set out to create a site like this, it was a side quest after creating the automation and database to support my reviews, which do indeed focus on the hobbyist trying to explore Raspberry Pi SBCs and their many alternatives.
I have full specifications and hardware capabilities hidden behind a feature flag at the moment as I'm working my way through adding all of that data (currently at 80 SBCs in the database, and I'm only adding those I own and have run tests on) so there should be something similar to what you're asking for soon. Thanks again!
If you fit the envelope, the Beaglebone Black has been out forever. It's not fast. It's doesn't have super modern interfaces (Displayport, PCI-E). It's not super tiny.
However, it is solid. It actually runs in the 500mA USB envelope and doesn't need a heat sink. It has eMMC so you don't have to fiddle with garbage uSD cards. It is incredibly well documented thanks to TI. It has a useful number of I/O pins (unlike the measly amount on the RPi). It has tons of the kind of basic hardware interfaces that you need to interface to things. The real time processors on it can often substitute for FPGAs. There are industrial versions for $10 more than the standard $50. And the software follows bog-standard mainline Debian rather than being some weird, undocumented, bodged-up thing that needs to boot from the GPU.
Pricing is quite different from supplier to supplier. Usually around 50 - 100 € Here are a couple suppliers for NXP boards:
Toradex (Switzerland): https://www.toradex.com/
Phytec (Germany / India): https://www.phytec.com/products/
Variscite (Taiwan): https://variscite.com/
Intel boards usually cost around 100 € - 150 €
I for one learned way too late that an ESP32 (whichever model really), despite being massively more complicated, will typically have a much smaller quiescent current in deep sleep than a 555 timer - even the CMOS implementation.
I've already found my board, but this is not my last battery-powered project.
Example: Raspberry Pi 4 vs Raspberry Pi 5 (https://sbc.compare/9-raspberry-pi-4-2gb/14-raspberry-pi-5-4...). Architecture is ARM. But it's repeated for each column, which makes the reader have to look carefully at each cell to see whether it really is different.
This is a pet peeve, particularly when a company's "compare versions" page lists dozens of identical dimensions across the product line, making finding the differences into a dreary where's-Waldo game.
Just in the Orange Pi lineup, there are so many different models and so little structured information about them, that the best source still seems to be the google sheet that I created in 2017 and has been continously updated by various community members over the years [0]. And that's all one manufacturer!
Things like which type and how many video outs, USB ports, if it has onboard flash, DSI/CSI, pinout compatibility... are so much more important and so much harder to get than performance numbers, which usually boil down to the SoC plus a small margin for thermal and power design of the board.
If this site were open source (and time + knowledge of stack permitting), I'd take a stab at adding a way to include that info as well, maybe even through crowd-sourcing.
[0] https://docs.google.com/spreadsheets/d/14QDXdMR1a1kc0gpRpTzI...
As soon as I have all of that data in there (I think I'm at around 30-40% so far, the initial batch of testing has been a slog, data entry for this took a back seat) I'll be enabling that option and it will all be there to view on comparison pages, and search for to help find/compare on a deeper level.
It's a really cool site, I'll defenitely be keeping an eye on it and if you ever go the crowdsourcing route, hopefully also contribute.
And I'm sorry for being yet another lazy HN commenter who didn't read far enough down the thread before opening their mouth (keyboard?) :)
One of the hardest things is settling on specific tests, and ensuring tests are run in an extremely standardized environment. I do my best, but a test lab I am not.
It's good to have a quick way to get relative comparisons, even if imperfect.
VL805 USB chip in RPi 4 and 5 has known bugs since 2020 which are still not fixed.
https://www.armbian.com/download/
Things may differ a bit in the educational field because of the vast community the RPi can count on, but Linux is Linux, I don't see why a school shouldn't use a different platform and make the solution of problems, if any, part of the learning process.
This include firmware and drivers for Wi-Fi/Bluetooth module on the board, proper DTS and/or schematics to understand which power rails go to where, maybe even silicon bugs.
Bootstrapping the OS image is one of the simplest part I'd say.
You're correct that they aren't really comparable. But a lot of the time a RPI is a monumental overkill of biblical proportions for what is needed.
(Or I'm too stupid to use it.)
btw: https://geizhals.eu/?cat=mbarm - but also no search by PCIe there
https://www.amazon.com/MeLE-Mini-Quieter-4C-Astrophotography...
very impressive N100 device. i run EndeavourOS with KDE/plasma on mine. i swapped out to a faster and more efficient single sided 4TB nvme.
it's fanless and idles at ~4.5W according to the USB-C cable's lcd power readout.
I'm currently in talks with a few of the vendors to start filling the database with missing boards from their ranges so we should have more data available in the coming weeks. There should be 2 BeagleBoard (Eco Green and PocketBeagle 2) arriving tomorrow/Tuesday to expand their range on the site!
Directly engaging with vendors for donations is somewhat fraught with concerns of its own, as ideally you are doing blind purchases so that vendors can’t give you known-good units, but rather are giving you units that the vendor doesn’t already know are going to be subject to enhanced scrutiny.
Maybe get in touch with the OpenWRT folks to see if you can test the OpenWRT One? I believe they’re using a modified BananaPi design.
https://openwrt.org/toh/openwrt/one
> OpenWrt One is based on the MediaTek Filogic 820 SoC and has WiFi 6, dual-band, 3×3/2×2, 1x 2.5Gbit WAN, 1x 1Gbit LAN, 1GB DDR4 RAM, 256 MiB NAND, 16 MiB NOR (for recovery), M.2 SSD, USB-C Serial console and USB 2.0. Power Over Ethernet (POE): an IEEE 802.3af/at compliant device can power the device via the RJ-45 2.5 Gbps WAN connector.
https://docs.banana-pi.org/en/OpenWRT-One/BananaPi_OpenWRT-O...
> OpenWrt One uses Mediatek’s MT7981B SoC with a dual-arm Cortex-a53 core at 1.3 GHz, 1 GB DDR4 RAM and 256 MiB SPI NAND storage. It also integrates 16 MiB of additional protected storage as a system backup, dual storage hardware to ensure that the onboard system is unbrickable, and finally integrated M.2. 2230/2242 NVMe PCIe 2 X1 ports can be used to add external storage. And with a battery holder for an internal clock, OpenWrt One offers a USB 2.0 Type-A and a mikroBUS expansion port to provide more interfaces to a host of technical possibilities
> OpenWrt One is the first board design with OpenWrt opensource communtity.and designed in collaboration with Banana Pi that will also handle manufacturing and distribution of the router board. The OpenWrt One/AP-24.XY router should provide a source of income for the project, for example, to cover the cost of hosting and OpenWrt conferences, with Banana Pi selling the board through their distribution network, and for every device sold, donating to the Software Freedom Conservancy (SDC) with the funds earmarked for OpenWrt.
[0] Techlore on YouTube interviewed the operator of such a service in the video linked below. I won’t name the company as this is not a review or endorsement (pun intended), as I have not used their service, nor can I speak to their operations, but the interview is a decent explainer of the service itself from the point of view of an operator of such a service, and other competitors in that field are also named.
On the samples from vendors front, yeah, that's definitely a concern, though in the years I've been working with manufacturers and had samples from them, I'm fairly confident that no "golden sample" binning is going on as I've had quite a few shockers, hah! Not to say that it couldn't/wouldn't happen, I wouldn't want to introduce that doubt. Perhaps, like my review website, I should add a quick note/indicator of whether a board was obtained directly from a vendor, or if it was purchased.
That’s pretty good of you to mention, as I didn’t notice the footer when I visited to see if you already had tested the OpenWRT One before posting my suggestion to test it. Perhaps you could mention that you would make a best effort to test hardware suggested by donors, if you haven’t already done so on the site? I approve of you asking for donations openly, as your time and efforts are worth something to you and to visitors, and if you communicate that it’s a two-way street, with some incentives to donors in that they can help suggest what you spend their donations on, I think that your transparency and good faith are more likely to be rewarded with more and larger donations that a simple “buy me a coffee” pitch might otherwise attract.
> Perhaps, like my review website, I should add a quick note/indicator of whether a board was obtained directly from a vendor, or if it was purchased.
I think such a disclaimer/disclosure would assuage (m)any concerns most folks would have on that front!
You seem to have a good grasp on what you’re doing here. Do you share/open source your testing methodology and/or code run to derive your data?
Edit: I see now that you have some of your testing methodology posted. I would suggest gathering as much room temp data during testing as possible, and maybe even re-running the test suite at variable temperatures as much as possible if you can, so you can plot performance over time with different cooling setups in different ambient temperature conditions, as many folks use SBCs in (semi) permanent indoor and outdoor installs in less-than-ideal environments and enclosures, usually with little to no cooling.
If you were to share your complete test scripts, temp probe/jig setup, etc., other users could reality-test their own hardware against other devices in an apples-to-apples way.
I don't know if I'd release everything as is, there's a lot of hard coded nonsense that I'd need to filter out and after testing 80 boards, I have a bunch of improvements I want to make. Opening up the test scripts to others isn't/wasn't a high priority item, as I didn't even plan on making this site initially :D
Room temperature data is also nice, but I'll need to draw a line somewhere, on average these tests take around 3-4 hours to run, and with 80 boards right now, best case scenario is 10 straight days of testing (in reality, more with setup and.. life). I could use data on the most popular boards and only do a handful, but I probably have to limit the scope at this point and clearly state the testing conditions and how it may differ in your real world setup.
I can definitely do more to expand on the testing process though, and I can look at sharing the exact commands that are run with my automation so that users can at least mimic the benchmark runs if not the full automation. I really appreciate the responses and feedback, though, so thank you!
Making a carrier board for the Mu is definitely not for beginners though. It's got loads of high speed I/O lines. Even actual engineers find high speed PCB design daunting. Also, the functions of those HSIO lines are hardcoded into the firmware. You need special BIOS builds for a board with PCIe or USB 3. Change too much stuff and you're going to have to ask the manufacturer to support your configuration.
That's why there's "Compute Module" SoM with minimal functionality. It is made for professional designs.
But if you want to produce low volume product or you're 100% fulfilled with Raspberry Pi, there's nothing "unprofessional" about it. PCB is PCB.
Meanwhile mcu are… tricky.
For an example I wanted to measure co2 level. It took me about a week to write it in raspberry pi zero w2. It captures data, stores it in sqlite, then every so often transfers to Postgres.
To do the same in esp32 took a couple months ( including storage and updates)
For example, how does it handle wifi going down? Does it recover gracefully? Does it manage to save the data during downtime and reupload it all afterwards?
How does it handle updates through wifi? OTA updates are important for 10 devices deployed, but is not easy.
esp-idf has answers for all those questions. You can hook up an SD card to buffer measurements when the network is down, reconnecting is usually as simple as a loop that tries to reconnect if you're not currently connected, and OTA updates are a solved problem with many different strategies to choose from.
That’s because you haven’t done it. There’s a lot more code to write in embedded case and lots of pitfalls to fall into.
>OTA updates are a solved problem with many different strategies to choose from.
No. Just no. Esp32 provides nice libraries to do update but acquisition/logic/code to use that is up to you. You still have to write a lot of code around the libraries and more importantly — debug and think of how to use it.
For example — let’s say you pushed an update that crashes early in boot (or other points). No problem, you’ve designed an AB update system so you just roll back to A.
Not so fast because A partition will try to update back to the botched update after roll back. Causing device to go into a update/crash loop and killing the esp32 in the process (flash has a limited number of erase cycles)
So you say “ok I’ll just store the update number in flash and only update 3x times before blacklisting”.
Well congrats now you gotta go write more code! And this time you get to have fun with nvs library which is great but not trivial. And once again if you make a bug you’ll face either a dead and recoverable device or dead for real device.
>reconnecting is usually as simple as a loop that tries to reconnect if you're not currently connected
Oh god no. Take a look here: https://docs.espressif.com/projects/esp-idf/en/stable/esp32s...
Specifically this part:
>Generally, it is easy to write code in "sunny-day" scenarios, such as WIFI_EVENT_STA_START and WIFI_EVENT_STA_CONNECTED. The hard part is to write routines in "rainy-day" scenarios, such as WIFI_EVENT_STA_DISCONNECTED. Good handling of "rainy-day" scenarios is fundamental to robust Wi-Fi applications.
How well does your code handle “I’m connected to Wi-Fi but don’t have an IP?” Or it has an ip but can’t hit your server? Or it can’t hit dns? There’s a bunch of errors and transitionary state that just sucks.
Meanwhile you mention “just buffer the data in SD card”. Once again, write a pile of code, and then put a layer on top of it to store your data. This is a more straight forward problem but adding data to SQLite file and then sending it out is just so much easier.
And then you have to work with time. “Just buffering data” also requires keeping track of time because now you can’t use receive time as your capture time. Now you gotta write more code to synchronize the time on esp32 to your server which is a solved problem on Linux.
I haven't done _this particular_ project, doesn't mean I'm not confident in working on embedded systems. So yes, I still stand by my statement that I would much rather do this sort of project in an embedded environment.
Your pessimistic "no. just no." style of writing doesn't convince me. Every problem you listed is an engineering problem you have to consider no matter what platform you're on, and none of this theoretical project is novel. There are solid approaches to each problem, whether it's in an embedded context or something like Linux.
I'm just saying that _I_ personally would prefer to handle it in an embedded context.
Microcontrollers are super cheap and have incredibly low latency so they are great for when you need to do something like pulse an output pin with sub millisecond accuracy, but have very very little compute compared to a real CPU and can’t run normal software.
Otherwise, there are dual NVMe HATs for the Raspberry Pi 5 but you'll be splitting a single PCIe Gen 2 lane across both drives (unless you go for the much more expensive HATs that have a Gen 3 PCIe switch on them to then share a single Gen 3 lane across them!)
If this is the worst modern website you've seen, you're very lucky.