VoCore – Coin-sized Linux Computer
vocore.io
vocore.io
While it's not useless, it's also so underpowered, you might as well stick to the ESP32 family. MIPS 24k is not great, even if you run the smallest linux distro ever. It's essentially WRT54G tech from 2002.
As with all hardware like this, it's the ecosystem that makes or breaks it, not the product on its own. That said, it's survived this long so it must be a good fit for some people out there.
> performance lower than a Pi 1
Having the proper Linux full-sized TCP stack, however slow it is, is probably more robust in more corner-cases (and possibly has more features, like TCP_CORK, that could lead to better performance anyway).
Honestly? I think a microcomputer of 1980s or 1990s level is still important for hobbyists. Rasp. Pi is taking the bulk of it but Rasp. Pi still uses too much power for a lot of tasks IMO.
BeagleBone is good to play with in my experience (1/2 the power usage of Rasp. Pi, and more realtime features like PRUs or even Cortex M4 cores on the more recent ones). So that actually matches my use cases more.
But finding even smaller chips that are proper full sized microprocessors, with a proper application environment / user-mode and applications is still intriguing to me.
----------
You're right. This is very similar to ESP32 on a specs perspective. But... "Proper Linux" is a huge difference and well worth the... what? $15 difference?
But if you do things at scale, every single penny counts. Yes, penny.
And one thing about the embedded Linux aspect - yes, this is a path for Linux hackers to get into embedded, and perfectly valid.
BUT. ESP32 also has many things going for it. Other operating systems, for example, equally fun and friendly to code for, as Linux. FreeRTOS is fun. So many other things, too .. endless great bits of community software components that can be picked and placed into your project, which will absolutely allow you to build a great product.
The point is, if you can do Linux, you can do the ESP32 ecosystem too.
They are approximately relevant to each other.
Disclaimer: I have done multiple projects in both realms, for many, many years (minix-list) and am quite comfortable with the cyclomatic complexity of writing code for either Linux or ESP32. They are, to me, flat. YMMV.
Knowing how to code and design at the 10,000 unit level is important. At this level, paying $3 per oscillator module for 2% higher reliability is more important than paying for a $0.50 XTAL and trying to save $2.50 per SKU.
Because the bulk of the costs are development, and because you are likely building a reputation as an elite artisan selling highly custom goods for a niche audience.
The $20,000 difference of a $2.50 module with slightly better reliability is absolutely the right choice to make.
You're paying for what functionality you can attain.. in the ESP32 case, its mighty limited - but as all embedded devs know, challenge accepted - and in the Linux case its mighty complex/hefty and you have to pay to play, in the BOM costs anyway ..
Either way, the 'reliability' factor is misguided, in my opinion. This is not at all why you choose either path.
Both platforms are functionally equivalent. The only difference is capacity.
I'm talking about oscillators and XTALs in this sentence. Not about Linux.
Anyone making relatively small run items (10,000 or less SKUs) knows what I'm talking about. Saving every penny is counterproductive at this level of production. The main goal is to cut development costs actually.
$2 more on the BOM? Whatever, did that save $10,000 on tooling and software? Definitely worth it. I'm bringing up oscillators and XTALs because XTAL is notoriously difficult to debug with standard lab tools. Its a physical device that changes with just 2pf and might only be running a few microwatts, so you need very low capacitance test equipment to directly debug XTAL issues.
Different tools and methodologies exist at different levels of production. That's all I'm saying. You do _NOT_ pinch every penny at this level, you just buy the more reliable Oscillator-module and avoid XTAL testing all together (saving a ton of money on development tools and development time).
For what use cases, though?
I find having a full Linux stack with all its complexity introduces a lot more corner cases to test, while something like lwIP [1] if you need TCP and an 'application' running under either FreeRTOS or similar, the timer tick ISR, or a bare while(1) loop can be enormously less complicated, more reliable, and enormously smaller/lower power.
It's possible to solve a lot of problems with literally 6 orders of magnitude less RAM, and about that much reduction in power usage/increase in battery life.
I get that overkill is underrated, if you can throw $50 at a problem or $20 and make it easier to use than a $2 microcontroller that doesn't really matter if you place any value on your time, but it's just wasteful.
Sure, maybe you create a JavaScript system inside of some ESP32 interpreter and allow code extensions.
But is it really easier than saying: I got a mkfifo and daemon in this device at /custom/LEDs that controls the color output of my doohickey?
So that is a completely bogus argument.
You know that OSes and extendable, multi-process systems were around in the 80s right? On 640kB of RAM and 20MHz processors right?
-----------
Anyway, my point is that code-extensibility is absolutely a thing. Some devices do deserve 3rd party code. I admit, none of my projects right now, though I'm hobby level. But I can _imagine_ a use of a standard OS with extendable 3rd party code modules where an API with the hardware would be helpful.
If you wanna implement Forth, VxWorks, custom Javascript or whatever... there's plenty of valid solutions. But you know what else is a perfectly fine, and probably the easiest, solution?
Straight Linux.
Maybe FreeDOS or Dr. DOS as well.
Excluding really small machines that didn't do well with multitasking, I used a 486 DX2 50MHz with 8MiB of RAM (this was a Packard-Bell) to my day-to-day work until around 2002, this includes running browsers that supported JavaScript. It could even decode and play MP3s if that's the only thing it was dedicated to doing.
After that I upgraded to an HP Visualize C3000 (400MHz, 512MiB RAM) desktop running HP-UX and an HP Pavilion 6350 (475MHz, 128MiB RAM) laptop running Linux. Both of these supported a GUI much better than the 50MHz, and also could run more intensive JavaScript workloads.
I have a few screenshots [0] from the HP Pavilion, you can see it's running several browsers and decoding an MP3 at the same time.
[0] https://rkeene.org/personal/screenshot/Image_fvwm2-06Jul02-3...
People used to run Java J2ME of all things on phones with 512 KiB of RAM.
Proper Linux is only worth the difference if you can actually fit the OS and your application in the available RAM (good luck) and the part has mainstream kernel support and available documentation. Otherwise you are buying into a literally throwaway platform that will become a useless piece of e-junk the moment the vendor stops updating their copy of Linux with patched in various binary blobs necessary to make the thing work.
The VoCore website only links to binaries, no source code (only some patch files) for their kernels and OpenWRT builds (GPL?), the wifi driver Github has "This feed enable using MTK/Ralink official wifi driver for the latest linux kernel 4.14/openwrt." in the description - current mainline is at 6.5.3 ...
Their OpenWRT binaries are also ancient - the latest they offer for download is 19.07.03 which is 3 years old. Not great, given what this is meant to be used for. I guess security is not high on their priority list.
Also the amount of chinglish on the website ("note: normally, we upgrade or fix brick are using Firmware. Flash Image is a clone of the full flash, for professional usage only. ") doesn't exactly bode well for good quality English documentation availability.
Ship an ancient, outdated Linux or Android image, no or incomplete sources, poor or no English documentation - and good luck to anyone trying to make such board work.
The hardware could be the best in the world - but this poor ecosystem support is the bane of most Chinese SBC and the reason why almost everyone uses Raspberry Pi, despite it certainly not being neither the cheapest, most powerful or having lowest power consumption.
> Proper Linux is only worth the difference if you can actually fit the OS and your application in the available RAM (good luck)
This says it has 128MB RAM. This is more than sufficient to run the very latest Linux and several useful applications. You just can't install systemd.
128MB is plenty. Throw down Busybox and cut some corners, run uClib rather than glibc, etc. etc. You'll be surprised what fits in there.
My 256MB Linux VPS was Apache + Bash, full scale Linux. There's plenty of room there. 128MB is small for a "mainstream" Linux / Ubuntu install, but 128MB isn't even "Linux from Scratch" levels of size.
Linux from Scratch is probably like 32MB or so RAM needed. And that's still "kit" Linux (IE: a prebaked "kit" where the OSS community already made a bunch of optimizations for you, but no application-specific optimization decisions yet), not even going into difficult levels of optimization yet.
> The hardware could be the best in the world - but this poor ecosystem support is the bane of most Chinese SBC and the reason why almost everyone uses Raspberry Pi, despite it certainly not being neither the cheapest, most powerful or having lowest power consumption.
EDIT: I think you have a fine point on this front. I know that MIPS chips are still available from some manufacturers (like Microchip's PIC-line), and I think they're Linux compatible. That might be a better way to go. But this ~128MB "sized" Linux instance seems perfectly usable to me. Good softare/Linux support would be preferred of course.
thinking everyone uses raspberry pis (while mostly true in hobby) ignores a very large segment of very real and very active embedded dev getting to the point MPUs are at cost in design bumps etc
Is it because the MIPS has MMU?
I guess, "MIPS has a good enough MMU" is the better answer. Or perhaps, because MIPS has enough security features to match Linux's multiuser assumptions (virtual memory, kernel vs user mode, etc. etc.). And finally, because the OSS community has ported Linux to MIPS32 already, albeit decades ago but that code still works today.
There are weird Linux ports that are so customized I'm not sure if you can call it Linux anymore. I'm pretty sure I saw someone forcibly run Linux on a Cortex M0+ for example. So its not "proper" Linux due to the high amount of custom code they wrote and likely incompatibility with the greater Linux community. Its a wishy-washy definition because I've seen a lot of really weird crap in the embedded world, and I am not comfortable drawing hard lines anywhere.
And where most other Kickstarters abandon their projects once they released it, moving on to something different, this guy on the other hand still provides updates (new hardware, updated drivers, etc.), to a point where even big companies could really learn from.
Sure, the VoCore might not compete with a fancy ASUS router or FritzBox, but that was never the intended target.
Make a small dongle that plugs into an ethernet jack and sets up an wifi access point that is run over a VPN. e.g. I could give one to my friend and any device they connect would connect to my VPN.
a) Is that possible?
b) Would that get around Nintendo Switch NAT issues?
The last time this chip came up I got the idea, but I'm not sure how doable it is.
Edit: I forgot that a stretch goal would be to change the setup. You could have the VoCore connect to a wifi network, and then plug the USB side into a device (nintendo switch doc or computer) to emulate a USB ethernet adapter, but of course send the traffic over wifi through the VPN.
Edit: I should also mention that it’s very doable to DIY this using OpenWRT, and some compatible SBC that has WiFi and Ethernet.
You don’t want something crazy underpowered like VoCore for this.
I am tempted to still use VoCore since it appears to run OpenWRT out of the box and I'm really only aiming to support a single device. Hmm..
Just here to second the recommendation. I'm in no way affiliated, I've just happily used several generations of their routers for this exact purpose.
EDIT: Wanted to point out that their newest and most powerful travel router with (upcoming—in the latest v23 release candidate[3]) support from mainline OpenWRT is the Beryl AX (GL-MT3000)[4].
[1]: https://openwrt.org/toh/gl.inet/gl-mt1300_v1
[2]: https://openwrt.org/toh/hwdata/gl.inet/start
[3]: https://firmware-selector.openwrt.org/?version=23.05.0-rc3&t...
Depends on the game. Animal Crossing is particularly bad in that regard - say you have two kids and they want to be able to play with one remote friend each as the host, it's impossible: it will not work without the hosting Switch being completely exposed to the Internet, and there can only be one "catch all" device configured on your router at the same time.
I get that Nintendo doesn't wish to run a STUN/TURN setup but JFC, that's penny pinching on the wrong end.
https://octavosystems.com/2019/04/12/osd335x-c-sip-dead-bug/
Professionals choose chips/modules based on an entirely different set of needs/requirements and wouldn't use this module for say, a new embedded product.
It's cool, but kind of sits between 2 niches....
That being said does anyone know where I can find a smaller and waterproof display?? I was thinking to tinker with building something like the Beeline navigation - https://beeline.co - but without all the propriatary software.
Of course will need a bigger brain than a VoCore to power that
https://www.cnx-software.com/2023/06/13/compulab-ucm-imx93-m...
The chip here probably draws 50mA.
The WiFi draws 200mA, while wired Ethernet probably draws like 100mA.
There are specifically low powered communications like Bluetooth, ZigBee, or the new SPE Ethernet standards. But they are niche and more expensive to work with.
So you're pretty much paying for lower power (and lower performance) on a rather consistent basis.
Legacy ISA. I'll wait for RISC-V version.
Amazes me how techies jump on whatever hotness bandwagons without a second thought.
Debian (largest Linux distribution) just removed mipsel from official ports. Other mips variants will eventually follow the same fate, as well as the rest of legacy ISAs.
It is no longer sensible to choose anything else than RISC-V on a new design.
That is a bit hyperbolic.
Whilst I share your enthusiasm for Risc-V it is not the only game in town
(spoiler: RISC-V! RISC-V! RISC-V!!!1111)