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 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.
> performance lower than a Pi 1