Hacker News Reader

"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.

Mostly I agree but mind you:

> 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.

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.

[1]: https://www.nongnu.org/lwip/2_1_x/index.html

Anything where your users could build a codebase of their own and extend your functionality.

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?

You certainly aren't going to run any Javascript on an ancient 580 MHz MIPS CPU with 128MB of RAM.

So that is a completely bogus argument.

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?

Straight Linux.

Maybe FreeDOS or Dr. DOS as well.

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.

[0] https://rkeene.org/personal/screenshot/Image_fvwm2-06Jul02-3...

People run Javascript on microcontrollers and you think such an overpowered (compared to microcontrollers) processor can't do it?

People used to run Java J2ME of all things on phones with 512 KiB of RAM.

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).

Just wondering what you meant by proper Linux.

Is it because the MIPS has MMU?

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.