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.
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... "Proper Linux" is a huge difference and well worth the... "
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.
I literally ran a Linux VPS for years on 256MB of RAM.
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.
i replaced a 200 mhz 512k ram mips mpu with one of these same chips to great effect and at reduced cost.
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
> 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.
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.
That's significantly more powerful than workstations I used for a long time, where I ran Linux, Solaris, HP-UX, DOS, OS/2, and Windows.
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.
I've literally run Javascript on smaller processors than that on college projects. Smaller scale Javascript (probably not the latest DOM or EMCAscript), but... yeah. Its not actually that large of a language. Especially older versions. It helps that I did this back in 2008 as part of my college education when processors were smaller (and Javascript was smaller), but Javascript goes back to the early 90s in practice. There's surely some version applicable for this use case.
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?
Think scales of magnitude. For a one-/few- off project, okay, you might not notice the difference of a hundred bucks.
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.
Hobbyists and even professionals are looking at 1000 SKUs to maybe 10,000 SKU projects.
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.
Higher reliability? Sorry, that is a fallacy .. you're not paying for reliability at scale in either the ESP32 or Embedded Linux scales.
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.
> 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.
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).
Words like "MMU" are... poorly defined. Cortex M0+ has an MMU, but its nowhere near what is needed to run Linux.
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.
This guy is amazing. This started out as a Kickstarter, for something like 25€, and for that price point, it was unbeatable. Especially if size was important. Heck, even at the current price point it's not too shabby (if size matters).
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.
So, something I've really wanted to do, but don't have the chops for is this:
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.
Sounds like you are looking for a travel router. GLinet makes some good ones. I have one of these: https://a.co/d/gbWTmjS
I use it to connect to hotel WiFi then provide its own WiFi (or Ethernet) connection to my devices. It can connect to vpn to route the traffic like you mention.
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.
Many of the gl.inet routers can run vanilla OpenWRT out of the box—the linked router above (Beryl) included[1]. Be mindful that not every one of their routers can as some run unsupported chipsets that require a custom build, but many do. Can always check for support on the OpenWRT page for gl.inet routers[2].
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].
Your challenge will be throughput, without hardware acceleration every packet needs to be handled by the CPU and you're going to pretty quickly bump up against throughput limits. Travel routers will generally offer hardware acceleration and have everything ready to go in one package, so great news - the thing you're looking for exists today!
The ESP32 chips have the ability to drive both Ethernet and Wifi. There is some onboard hardware accelerated encryption also. So in that case you could make the physical device easily enough. VPN can often do proxy-arp so that the NAT issue would not appear. Whether it would give you enough performance, unknown.
I've been doing just that with a Raspberry Pi Zero W and a USB ethernet adapter. The eth adapter is set to dhcp, and the wifi sets a hotspot. The wireguard adapter is routed/from to wifi with firewall rules. I even tested the Pi plugged to a powerbank and it still works.
For those wanting to do similar things, I found https://www.thinq.ai/RPi_Ethernet_USB_OpenWRT.html to be a pretty good page on how to do usb over ethernet in both directions with open wrt, which was a big chunk of the mystery for me.
> b) Would that get around Nintendo Switch NAT issues?
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.
Interesting. I did not know that about Animal Crossing. It sounds like that's because the last person is remote? I'd ideally be trying to resolve that quirk by using VPN (plus proxy-arp?) to put all the switches on the same VPN despite being geographically distant.
I dunno about a dongle, but yes that's fundamentally reasonable sounding. I would do it by taking a Raspberry Pi equivalent and setting it up with automatic Ethernet configuration, wireguard for the VPN, and hostapd+dnsmasq for the WiFi. I've never actually done the step of bridging the Wi-Fi access point to a VPN, but I can't imagine that it's terribly hard.
A USB powered Linux device with a USB-Ethernet gadget driver and Wi-Fi hardware should be possible, but that can’t be powered by a power-over-laptop-Ethernet-jack if that’s what you’re after; Ethernet is either isolated or well filtered and can’t provide current.
IIRC Facebook used to provide a small wifi router that you’d plug into your home network and it would connect itself to the office VPN, then just provided office wifi at home. Sounds fairly similar to what you’re suggesting.
Unless you really, really needed to minimize the footprint, I would pick an RPi Zero any day for having reasonable software support. I have a Lichee Pi in a drawer somewhere, I could never even get it to boot...
The other thing folks haven't mentioned is that things like the esp32 have support from thr Arduino IDE and a bunch of other software stacks that make it way easier, and significantly lower the barrier of entry to use these things for non-professionals.
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.
I like that they offer a bunch of different displays with it.
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
A better approach would be a solution based on an Allwinner V3S or S3, since they have DRAM embedded in them. For example, the Lichee Pi Zero [1] is 45mmx25mm (instead of ~25mm^2 for the VoCore) but with a USB and a microSD slot on the PCB.
The thing that pisses me off at this level is how much power interfaces draw.
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.
That's a good observation – it aligns with why we have vintage personal computers that have comparatively large battery lives on relatively low-powered power sources. The TRS-80 Model 100 had 20 hours of active use on 4 AAs, the eMate had up to 28 hours on 4 AAs as well. I imagine the difference is due to both limited displays, lack of networking beyond serial and POTS modems, etc.
>... which means literally decades of development tools and support.
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.
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.