What does HackerNews think of IronOS?

[1] Schematics: https://wiki.pine64.org/wiki/Pinecil:_How_to_Repair#Schemati...

[2] IronOS: https://github.com/Ralim/IronOS

An OS is nice because you can have multiple real-time tasks with different priority levels, so that you can, for example, update the screen without worrying that it will screw up the PID control loop maintaining the iron's temperature.

You don't need a screen, but a screen is nice because you can see what temperature the iron is set to and what temperature it's measuring. This makes it easier to set the temperature. Also IronOS lets you set the cutoff voltage so you don't kill your batteries by draining them down to zero, and it has an option to correct inaccurate temperature readings from the tip by calibrating the tip.

PID temperature control is nice, not only because the iron is ready for use much more quickly, consumes much less energy (making battery power practical), and weighs less, but also because it allows you to solder things to big copper pours without overheating your iron all the time, which means you burn components and lift traces a lot less often. This is especially nice if a heat-damaged component might not fail until after the circuit board is on orbit, which makes it impractical to replace, or until it's in use in a life-critical application, which makes replacement the least of your worries. But you don't need it.

A 32-bit processor is nice because it means you can use 32-bit math for everything instead of constantly worrying about overflow. Also, you can address the entire 128 KiB of Flash without shitty memory segmentation headaches when you're writing the firmware. 128 KiB of Flash is nice because it's easy for even a single person to write more than 64 KiB of code, even with RV32C's superior code compactness and without using libraries — though, to be fair, an alternative way to get 128 KiB or 256 KiB of code space is to make your code space word-addressed instead of byte-addressed, and then make your instructions 16 bits or 32 bits long. Generally this requires a Harvard architecture, which is common in microcontrollers but not ideal.

None of these nice things requires or even benefits from a division instruction (though in practice they probably do need interrupt handling and illegal-instruction traps, which could be used to emulate division if it were really necessary). So I always thought it was kind of goofy that the M multiply-instruction extension, crucial to DSP work, was saddled with this white elephant of hardware division support. I'm glad to see that's fixed as far as it can be with Zmmul.

The GD32VF103 used in the Pinecil doesn't have memory protection, so IronOS https://github.com/Ralim/IronOS might not be the kind of operating system you're thinking it is. It doesn't have, for example, a filesystem, a command prompt, a GUI, a task list UI, or a networking stack. I don't even think tasks are created and destroyed at runtime; all the running tasks are compiled into the OS image.

Having an OS and a 32-bit microcontroller in your soldering iron might be a terrible idea: for example, it could include malware that displays advertisements or disables your soldering iron if you haven't paid your monthly subscription. The Pinecil solves this problem by being 100% free software, so that even if the IronOS maintainers try to pull something like that, you have the freedom to fork their code and remove the malware.

You still have the problems that the iron can have more complicated malfunctions and is harder to repair than an iron that is just a resistor that plugs into the wall. But I think the advantages of tighter control more than make up for that.

But if you really need to, you can solder your circuits by heating up a chunk of brass in the flame of your gas stove, then pressing it to the circuit board before it cools off. I've done it. But I'd rather not.