Top Single-Board Computers Introduced this Year(eetimes.com)
eetimes.com
Top Single-Board Computers Introduced this Year
https://www.eetimes.com/document.asp?doc_id=1332763&_mc=RSS_EET_EDT&utm_source=dlvr.it&utm_medium=twitter
11 comments
This really needs a ranking for upstream support. I mean, just a basic keyword check yields 2, 4, 5, 6, and 8 have a Mali GPU so hopeless unless you want to run a supercomputer with the equivalent functionality of a time-sharing terminal system destined for the landfill in a near future.
It would be soo important to have a way to enable people to learn stuff like low-level graphics programming on real hardware designs. One of the big failures of the GPL, we have all the software on top of the stack but little on the bottom.
It would be soo important to have a way to enable people to learn stuff like low-level graphics programming on real hardware designs. One of the big failures of the GPL, we have all the software on top of the stack but little on the bottom.
> have a Mali GPU so hopeless
At least for our use cases, a Mali GPU works OK.
It drives 2 external displays with GLES 3.1 on Linux, one of the displays has 4K resolution.
At least for our use cases, a Mali GPU works OK.
It drives 2 external displays with GLES 3.1 on Linux, one of the displays has 4K resolution.
> learn ... low-level graphics programming on real hardware designs
Why not program an NES game? You can develop against any number of cycle-accurate emulators, and then test your completed program on any random $10 "Famiclone" device that has an SD card slot. (The only annoying part to using the NES to learn graphics programming is the time you waste wrapping your brain around the "mappers" concept, because it has no applicability to any other system.)
Alternatively, for around $30, you can get an original Nintendo DS + an R4i flash-cart, which is a pretty extensive and interesting graphics platform to target: it has tile-mode graphics, bitmap-mode graphics, sprites with hardware scaling/rotation/shearing, and a fixed-function 3D pipeline with UV mapping and lighting, all able to be active as different hardware-composited layers of the framebuffer—but all still directly addressed using pokes to MMIO registers, rather than there being any hardware abstraction layer. Pretty great for learning graphics, honestly.
Why not program an NES game? You can develop against any number of cycle-accurate emulators, and then test your completed program on any random $10 "Famiclone" device that has an SD card slot. (The only annoying part to using the NES to learn graphics programming is the time you waste wrapping your brain around the "mappers" concept, because it has no applicability to any other system.)
Alternatively, for around $30, you can get an original Nintendo DS + an R4i flash-cart, which is a pretty extensive and interesting graphics platform to target: it has tile-mode graphics, bitmap-mode graphics, sprites with hardware scaling/rotation/shearing, and a fixed-function 3D pipeline with UV mapping and lighting, all able to be active as different hardware-composited layers of the framebuffer—but all still directly addressed using pokes to MMIO registers, rather than there being any hardware abstraction layer. Pretty great for learning graphics, honestly.
Because the PPU and other such sprite-based hardware bares no resemblance to a modern graphical pipeline?
It'd be more educational to just provide a framebuffer connected to a displayport controller and teach people software rendering.
It'd be more educational to just provide a framebuffer connected to a displayport controller and teach people software rendering.
> (The only annoying part to using the NES to learn graphics programming is the time you waste wrapping your brain around the "mappers" concept, because it has no applicability to any other system.)
A number of other gaming systems used similar mapping systems. And it's not so far conceptually from EMS on real-mode x86.
A number of other gaming systems used similar mapping systems. And it's not so far conceptually from EMS on real-mode x86.
NES Mappers aren't quite the same thing as regular memory bank-switching, or even the same as MMU programmability. They were a whole lot weirder.
Mappers, in the context of NES programming, are regions of on-cart ROM or WRAM that were wired up through various custom ASICs (the eponymous "mapper" chips) to do things like, for example, have contiguous looping reads to the same 64-byte address sequence (so, one 8x8 tile's worth of nametable data) produce as output a sequence of animated frames, by having the ASIC switch which physical page is backing that region of the address space once per VBLANK, entirely transparently to the CPU and asynchronously to running code (i.e. not driven by a maskable interrupt.)
In other words, each cartridge essentially cobbled together its own MMU by throwing together random chips which could respond in completely arbitrary ways to specific masked read-lines from the address bus; and many of these chips did very domain-specific things to very small regions of memory, rather than being general-purpose (there have been more than 100 different mapper chips put into NES cartridges, some used by only one released game.) As far as I know, no other system has ever done anything quite so weird as that at a hardware level.
Mappers, in the context of NES programming, are regions of on-cart ROM or WRAM that were wired up through various custom ASICs (the eponymous "mapper" chips) to do things like, for example, have contiguous looping reads to the same 64-byte address sequence (so, one 8x8 tile's worth of nametable data) produce as output a sequence of animated frames, by having the ASIC switch which physical page is backing that region of the address space once per VBLANK, entirely transparently to the CPU and asynchronously to running code (i.e. not driven by a maskable interrupt.)
In other words, each cartridge essentially cobbled together its own MMU by throwing together random chips which could respond in completely arbitrary ways to specific masked read-lines from the address bus; and many of these chips did very domain-specific things to very small regions of memory, rather than being general-purpose (there have been more than 100 different mapper chips put into NES cartridges, some used by only one released game.) As far as I know, no other system has ever done anything quite so weird as that at a hardware level.
One 8x8 tile takes 16 bytes of nametable data, not 64.
There are a couple hundred mappers and variants, but the 4 most common ones (thinking of cnrom, unrom, mmc1, mmc3) cover 90-something percent of all cartridges out there, and don't have the address increment that you're describing. Most of them just cover bank switching, or (like MMC3) add some IRQ stuff under certain conditions. There are cartridges with extra copy protection, extra audio channels, etc. As you said, the ASICs do basically arbitrary things, but it's not like you have to learn one of the really esoteric mappers.
The most common mapper behaviors are comparable to bank-switching on other systems.
I'd say that the SNES gives NES a run for its money, in terms of weirdness. The ASICs in many of the cartridges there included whole processor cores.
There are a couple hundred mappers and variants, but the 4 most common ones (thinking of cnrom, unrom, mmc1, mmc3) cover 90-something percent of all cartridges out there, and don't have the address increment that you're describing. Most of them just cover bank switching, or (like MMC3) add some IRQ stuff under certain conditions. There are cartridges with extra copy protection, extra audio channels, etc. As you said, the ASICs do basically arbitrary things, but it's not like you have to learn one of the really esoteric mappers.
The most common mapper behaviors are comparable to bank-switching on other systems.
I'd say that the SNES gives NES a run for its money, in terms of weirdness. The ASICs in many of the cartridges there included whole processor cores.
> it's not like you have to learn one of the really esoteric mappers
True. I guess I have console-manufacturer-coloured glasses on†; I was more thinking about what you'd have to know to be able to reimplement the NES mapper architecture yourself, such as in an emulator.
Though, also, if you want to do NES demoscene stuff, you're gonna want to understand the more esoteric mappers. And that's usually what amateur graphics programmers inevitably want to do when learning their first platform—use every feature to get a cool demo—which in the NES can result in a heavy focus on abusing mappers, which ends up not really giving you useful portable insight for anything else. (Except, maybe, for pixel shaders!)
† ala Raymond Chen's "kernel-colores glasses" — https://blogs.msdn.microsoft.com/oldnewthing/20110512-00/?p=...
True. I guess I have console-manufacturer-coloured glasses on†; I was more thinking about what you'd have to know to be able to reimplement the NES mapper architecture yourself, such as in an emulator.
Though, also, if you want to do NES demoscene stuff, you're gonna want to understand the more esoteric mappers. And that's usually what amateur graphics programmers inevitably want to do when learning their first platform—use every feature to get a cool demo—which in the NES can result in a heavy focus on abusing mappers, which ends up not really giving you useful portable insight for anything else. (Except, maybe, for pixel shaders!)
† ala Raymond Chen's "kernel-colores glasses" — https://blogs.msdn.microsoft.com/oldnewthing/20110512-00/?p=...
The way I implemented it was with a "memory" class that provides the memory map intrinsic to the system itself. When I load the ROM, I identify the mapper specified in the iNES header. There's a mapper class that basically provides the NROM variants, and classes derived from that (one per mapper family) to implement the ASICs.
I have toy-emulator-colored glasses ;-) I've got a few mappers written, but never tried to tackle MMC3 or MMC5, just because the CPU code isn't well-situated to handle most interrupts properly right now. It's been a while since I've thought about that part of the code, but I think that the mappers might be aware of the current PPU cycle (or could be easily wired to be) to support some kind of frame-dependent addressing.
I have toy-emulator-colored glasses ;-) I've got a few mappers written, but never tried to tackle MMC3 or MMC5, just because the CPU code isn't well-situated to handle most interrupts properly right now. It's been a while since I've thought about that part of the code, but I think that the mappers might be aware of the current PPU cycle (or could be easily wired to be) to support some kind of frame-dependent addressing.
It definitely upped the gamesmanship required for cloners of cartridges, and it made the system somewhat future proof.
The BBC Micro:bit has nothing to do with Sparkfun, they're just one of many resellers.
http://microbit.org/resellers/
Premier Farnell is the manufacturer
https://en.wikipedia.org/wiki/Premier_Farnell
http://microbit.org/resellers/
Premier Farnell is the manufacturer
https://en.wikipedia.org/wiki/Premier_Farnell
NanoPi NEO at $9.99 should really be on the list too. It’s very similar to the OrangePi mentioned, but IMHO more stable.
That looks cool. I like th smaller form-factor and RJ45 100Mbps port.
I need one now. Thanks!
I need one now. Thanks!
I use the Neo2 for a seedbox/VPN. $14.99 with gbe
The 'print' link on the page is broken, but for those who still want to read the descriptions in one go, this one works:
https://www.eetimes.com/document.asp?doc_id=1332763&print=ye...
https://www.eetimes.com/document.asp?doc_id=1332763&print=ye...
Is there a name for this dark pattern?
carousel of sadness
I'm definitely going to use this in my future endeavours.
Multiple names. Number 5 will blow your mind.
Tab closer
Slideshow
Can any of them be used without binary blobs?
Basically, no. There simply is no such thing as an open GPU. It's a shame too, because I'm at a point in my life when I'd really like to embrace a completely open hardware platform as my primary desktop, even if it isn't all that powerful by modern standards.
All MCUs are basically micro PCs that have SRAM, flash memory and run internal, binary code, so no, it is not possible. It is, however, possible to have everything open source from bootloader and up, if you don't need advanced graphics or power saving features.
The micro:bit.
If you don’t need graphics, sure.
I'm not seeing the BeagleBone Pocket / PocketBeagle on that list. I don't have any skin in the game, and this seems like a glaring omission.
Also no Jetson TX2, which seems an odd omission given its ridiculous FLOPS/Watt. It was announced in March.
Which of these are readily available for around the price listed?
Also, can anybody vouch for the Espressobin? 3 gigabit ports, usb3, and SATA. Nice.
Also, can anybody vouch for the Espressobin? 3 gigabit ports, usb3, and SATA. Nice.
The hardware is nice. The mini PCIe appears to be temperamental depending on which board you've used and there's little to no support from the vendor - they seem to have released everything, then disappeared.
All of them AFAIK. Even the Zero W can (finally) be had with relative ease, I just ordered one from SparkFun and Adafruit also has 'em in stock. Been wanting to make one into a security camera but they have been hard to get until just recently.
I think it depends on what is meant by "readily available". It's hard to do something like buy more than a couple Zero-W's at $10 apiece, unless things have changed very recently. In the past, I've seen people wanting to use a few dozen in a project having trouble finding that many for uninflated prices.
Yeah I abandoned a kickstarter roll out because I discovered I couldn't buy 1000 ... My guess is that they're losing a little on each one
I can't see why they would though. I don't think the RPF has the resources to sell so many units at a loss. I suspect it's probably just barely breaking even on both. The Wifi chipset the Zero W uses costs exactly $5 in quantity according to Digikey; the board layout is slightly different but otherwise the bill of materials is the same so that's the main cost difference. They're probably making some profits off of the accessories like the case or the camera (especially the camera, which is pretty expensive and I expect fairly popular).
Microcenter will sell you a single W for $5.
If you buy more than one, it is over $10 each and increases based on quantity.
Of course, I am lured in every time I am near and have a few Ws, and definitely spend more than $5.
If you buy more than one, it is over $10 each and increases based on quantity.
Of course, I am lured in every time I am near and have a few Ws, and definitely spend more than $5.
Very true. It's definitely hard to get more than a couple still. But they aren't perpetually sold out anymore, at least. That is definitely an improvement in the availability that has occurred in the past couple months, so maybe their supply is finally settling down.
$49USD ESPRESSOBin board with 1GB DDR3
$79USD ESPRESSObin board with 2GB DDR3
https://www.amazon.com/ESPRESSObin-SBUD102-Single-Computer-N...
see more:
* http://wiki.espressobin.net/tiki-index.php
* http://wiki.espressobin.net/tiki-index.php?page=Package+Pric...
$79USD ESPRESSObin board with 2GB DDR3
https://www.amazon.com/ESPRESSObin-SBUD102-Single-Computer-N...
see more:
* http://wiki.espressobin.net/tiki-index.php
* http://wiki.espressobin.net/tiki-index.php?page=Package+Pric...
* SATA I or SATA II or SATA III ?
Probably "SATA 3.0"
based on this: https://www.marvell.com/docs/embedded-processors/assets/marv...
"The Marvell® ARMADA® 3700 SoC family incorporates rich high-speed I/Os including USB 3.0, SATA 3.0, Gigabit Ethernet (1 GbE) and 2.5 GbE (NBASE-T) off ering two confi gurations: 88F3720 for dual-core and 88F3710 for single-core, both confi gurations have industrial temperature grade support. In addition, these devices feature a wide set of security and data acceleration engines suitable for innovative networking, storage, and computing applications. The ARMADA 3700 supports advanced power management technologies for switching the CPU cores, as well as per-core dynamic voltage and frequency scaling. This solution off ers a signifi cant reduction in power consumption under diff erent workloads and delivers an optimal Performance-per-Watt in the embedded markets."
based on this: https://www.marvell.com/docs/embedded-processors/assets/marv...
"The Marvell® ARMADA® 3700 SoC family incorporates rich high-speed I/Os including USB 3.0, SATA 3.0, Gigabit Ethernet (1 GbE) and 2.5 GbE (NBASE-T) off ering two confi gurations: 88F3720 for dual-core and 88F3710 for single-core, both confi gurations have industrial temperature grade support. In addition, these devices feature a wide set of security and data acceleration engines suitable for innovative networking, storage, and computing applications. The ARMADA 3700 supports advanced power management technologies for switching the CPU cores, as well as per-core dynamic voltage and frequency scaling. This solution off ers a signifi cant reduction in power consumption under diff erent workloads and delivers an optimal Performance-per-Watt in the embedded markets."
Every time I load a page on this website, Safari asks me “This form is not secure. Are you sure you want to submit it?” in a modal.
Very annoying.
Very annoying.
The same thing is happening in Firefox.
Not with uMatrix.
Maybe some sort of ad network dark pattern?
Maybe some sort of ad network dark pattern?
Yep. I believe the idea is to trick the browser into believing that you're interacting with the third-party site so that they get first-party treatment with respect to cookies and such.
I'm not sure if it's still true, but at one point, submitting a form (even via JavaScript) counted and let the site store cookies.
I'm not sure if it's still true, but at one point, submitting a form (even via JavaScript) counted and let the site store cookies.
Not with adblock + noscript.
Probably a naughty tracking script.
Probably a naughty tracking script.
It's also worth considering Xilinx Zync (FPGA with an ARM Cortex A9 in the package) boards. EG Digilent's: http://store.digilentinc.com/fpga-programmable-logic/by-tech...
Not cheap without the 50% educational discount, but very powerful for some workloads. Then again if you have one of those workloads you probably are already using an FPGA...
Not cheap without the 50% educational discount, but very powerful for some workloads. Then again if you have one of those workloads you probably are already using an FPGA...
Not introduced this year, but I'd add Odroid C2 to your list for consideration.
and the MC1, which is a XU4 married to a SATA bridge.
From my POV, the Top 10 was disappointing and boring. AFAIC, there's no SBC competing with the XU4 in terms of perf/$. I'd hope to see something even better than the XU4 or C2.
From my POV, the Top 10 was disappointing and boring. AFAIC, there's no SBC competing with the XU4 in terms of perf/$. I'd hope to see something even better than the XU4 or C2.
Have you seen the Khadas VIM2 Basic? iirc it's $75 somewhere (there recently was a $50 deal; maybe there will be another). It has 8 1.5GHz Cortex-A53s, so in theory it's 2.5X as fast as a Raspberry Pi 3 (4 1.2GHz Cortex-A53s) for CPU-bound tasks with sufficient parallelism. YMMV.
Thank you Scott for the pointer - here I thought I knew them all. This clearly belongs in the above list.
I'm particularly interested in the 3 GB RAM but the description is ambiguous, still I'll check it out.
I'm particularly interested in the 3 GB RAM but the description is ambiguous, still I'll check it out.
(Reply as I can't edit my comment anymore).
I missed the bottom: Basic @ $90 = 2 GiB, Pro @ $120 = 3 GiB.
That price is high and I was specifically talking about !/$ so this unfortunately doesn't really change the landscape.
I missed the bottom: Basic @ $90 = 2 GiB, Pro @ $120 = 3 GiB.
That price is high and I was specifically talking about !/$ so this unfortunately doesn't really change the landscape.
Aside from the pi, does the software stack work on any of these boards? Forgive me if I'm on outdated info but last I checked:
Espressobin hard crashes over 1G ram, was that fixed?
Tinker board software released / OS stability usage? I'm guessing no graphics still?
HiKey seems to have lots of Linaro support, no idea on actual usage.
Heard good things above ROCK64 but heard software was very poor initially, not sure if that fixed.
The rest sound doomed to old kernels and the dustbin. Speaking from experience of working with SBCs for the past 5 years and testing tens if not hundreds of platforms.
Espressobin hard crashes over 1G ram, was that fixed?
Tinker board software released / OS stability usage? I'm guessing no graphics still?
HiKey seems to have lots of Linaro support, no idea on actual usage.
Heard good things above ROCK64 but heard software was very poor initially, not sure if that fixed.
The rest sound doomed to old kernels and the dustbin. Speaking from experience of working with SBCs for the past 5 years and testing tens if not hundreds of platforms.
For a lot of them it seems that the more they vary from a Pi the harder it becomes to maintain a decent OS foundation. The Orange Pis and Pine64 boards are fairly well supported by Armbian (provided you are willing to live on the bleeding edge if you are running more recent chips like the Allwinner H5) but as you go further afield you have to be very comfortable doing OS builds yourself and a lot of the board features that look cool are only supported by an ancient and buggy vendor OS release.
Always check forums for the boards and your target OS to see what OS you can expect to run with any stability and do not assume it will ever get any better or be updated beyond where it is right now...
Always check forums for the boards and your target OS to see what OS you can expect to run with any stability and do not assume it will ever get any better or be updated beyond where it is right now...
Thanks for this warning, I didn’t realise software support was such an issue.
There is no mention of any Single-Board Computers which have Intel x86-64 CPUs. What are the most popular Intel CPU based Single-board computers?
I would say UP[1]. The base board (up or up core) are Quad-core atom and the up squared has a Quad-core Pentium version available.
1: http://www.up-board.org
1: http://www.up-board.org
Thanks for the information.
Firefox is dinging me about data being sent insecurely. Probably some tracker on the site, but I'm not a web dev.
How are they measuring top?
I feel like there are really too many to judge. I for one am a fan of the ODROID C2 and HC1.
I feel like there are really too many to judge. I for one am a fan of the ODROID C2 and HC1.
If anyone knows of a board designed to work with power-over-ethernet, let me know.
There are a lot of simple PoE splitters out there that can split your PoE line into standard RJ45 data and a DC barrel connector of various flavours.
There's the Craneboard but it's a bit dated now and never had much of a community around it.
http://processors.wiki.ti.com/index.php/CraneBoard
http://processors.wiki.ti.com/index.php/CraneBoard
Orange pi zero has links you can place in to power it over the ethernet socket, not true PoE but it does work.
1. Raspberry Pi Zero W -- $10
2. Asus Tinker Board -- $54.99
3. Marvell Espressobin -- $79.99
4. 96Boards HiKey 960 -- $239.99
5. PINE64 Rock64 -- $24.95
6. Orange Pi R1 -- $13.90
7. MYIR MYS-6ULX -- $24.80
8. LeMaker Banana Pi Pro -- $47.99
9. LattePanda -- $209
10. Sparkfun BBC micro:bit -- $17.50