logoalt Hacker News

tatjamlast Friday at 6:48 PM5 repliesview on HN

Writing embedded code with an async-aware programming language is wonderful (see Rust's embassy), but wonder how competitive this is when you need to push large quantities of data through a micro controller, I presume this is not suitable for real-time stuff?


Replies

carverautolast Friday at 7:03 PM

We're streaming RSTP camera feeds through WASM plugins and host-bridge adapters, no problem. I was surprised how well it worked TBH.

https://code.carverauto.dev/carverauto/serviceradar/src/bran...

nasretdinovlast Friday at 6:55 PM

You can disable GC in tinygo, so if you allocate all the necessary buffers beforehand it can have good performance with real-time characteristics. If you _need_ dynamic memory allocation then no, because you need GC it can't provide realtime guarantees.

show 1 reply
clktmrlast Friday at 7:34 PM

I've written a fair amount of code for EmbeddedGo. Garbage Collector is not an issue if you avoid heap allocations in your main loop. But if you're CPU bound a goroutine might block others from running for quite some time. If your platform supports async preemption, you might be able to patch the goroutine scheduler with realtime capabilities.

soypatyesterday at 2:01 AM

It is more performant than rust but less performant than Zig when not doing GC heavy stuff. https://github.com/tinygo-org/tinybench

randusernamelast Friday at 7:55 PM

Can you elaborate on this and how it would be different from signaling on interrupts and DMA?

Hardware-level async makes sense to me. I can scope it. I can read the data sheet.

Software async in contrast seems difficult to characterize and reason about so I've been intimidated.

show 1 reply