IronOS VS embassy

So apparently the Pinecil is a BLE-enabled soldering iron with a 108 MHz RISC-V processor running a custom real-time operating system [0]. The author wanted to access the UART logs, so they repurposed a Raspberry Pi Pico (a dual-core microcontroller system running a real-time OS) for the task.

That's a staggering amount of hardware, sortware and computing power devoted to decoding one of the simplest and oldest serial protocols from a device whose sole purpose is to essentially melt tin. Maybe I'm out of touch, but I think I'll stick to my thermostat-controlled Weller soldering station and FTDI UART converters. I apologize if this post comes across as snarky, my point is that these are solved problems and have been for half a century.

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

I got a TS101 and wanted to switch to IronOS straight away as it seems like an improvement to stock firmware. On the website it says that TS101s are supported, but there is no file for it. I figured it must be the TS100 .hex file, but flashing it just gives me an error (a .NOT file). Is the TS101 really supported and how do I flash the firmware in that case?

but the pinecil can also use IronOS https://github.com/Ralim/IronOS

Look at this ticket in Ralim's IronOS, all 4 people same issue and all they had to do was clean their Cartridges with IPA 90-99% Alcohol. https://github.com/Ralim/IronOS/issues/1601

I'm very happy with the Pinecil. The $25 price is very reasonable for a reliable soldering iron that is open source hardware[1] and runs on free and open source firmware.[2]

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

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

Also, I'm not sure what exactly is happening with the OS on the irons, because I thought the pinecils shipped with IronOS but it may be an old or cut down version because when I loaded the latest https://github.com/Ralim/IronOS on my pinecils I just ordered two weeks ago, I definitely got a ton of options I didn't have before.

thanks. looked that up. for the curious: https://embassy.dev/

Running the Embassy RP2040 USB CDC ACM serial example takes about 5 seconds on a Pico.

https://github.com/embassy-rs/embassy/blob/main/examples/rp/...

Async solves different problems, you can, for instance, have just a single-threaded CPU and still have a nice API if you have async-await. It might not be so cool at a higher level as Go's approach of channels and threads, but it's cool in embedded, read this:

https://github.com/embassy-rs/embassy?tab=readme-ov-file#rus...

"Rust's async/await allows for unprecedently easy and efficient multitasking in embedded systems. Tasks get transformed at compile time into state machines that get run cooperatively. It requires no dynamic memory allocation, and runs on a single stack, so no per-task stack size tuning is required. It obsoletes the need for a traditional RTOS with kernel context switching, and is faster and smaller than one!"

I'm just toying with Raspberry Pi Pico and it's pretty nice.

Go and Rust have different use cases, the async-await is nice at a low level.

I have not yet dipped by toes in the Rust waters, but reading about the embassy project is actually what piqued my curiosity about using C++ coroutines in embedded. Are you familiar with the project or have you found it lacking?

I think I get the basics (shoutout to the Rust Embedded Working Group!), and I've started looking for the stack I'd be using. I think Embassy is really amazing, as well as the work of the ESP team -- hats off.

> }

And this is how to do it using embassy, which is an async framework for embedded in rust:

https://github.com/embassy-rs/embassy/blob/main/examples/rp/...

> not good for embedded

embassy begs to differ

https://embassy.dev/

async/await is really just a syntax for building state machines in a way that resembles regular code. It's compiled down to the same code that you would write by hand anyway (early on it had some bloat in state size but I think it's all fixed now).

And embedded has a lot of state machines!

You can run multiple executors at different interrupt priority levels (with multiple tasks per executor), which allows tasks on the higher priority executor to interrupt other tasks. Here's an example https://github.com/embassy-rs/embassy/blob/main/examples/nrf...