Should I do a giant threadzilla over the course of multiple days/weeks that explains all the stuff that makes a huge difference for #embedded systems projects, a bunch of the stuff they don't teach you in university?

It should be a book, but maybe starting with tweets is okay. To be clear, this is comes from a "table of contents" that I wrote with @baldassarifr, @HBehrens, and a bunch of other really intelligent people.

The full list is here: gist.github.com/jamesmunns/337…

I'll use the numbers we used there, and explain a bit more about each topic.

Here's a rant (opinion?) that I'll turn in to a blog post soon.

I think Rust should have a third ABI, not repr(C) or repr(Rust), and it should be used to slowly phase out the C ABI for a better one. Want to hear more of my unreasonable thoughts about ABIs? Read on. First off: we should look at languages like Swift, Zig, Python, maybe even Go or C++, and find a better set of primitives to work with. I think there is a common set of features that wouldn't have everything, but would prevent falling back to the nuts and bolts of C.

So here's an opinion thread that should probably be a blog post:

If you're building an embedded system: you probably DON'T need an RTOS. In fact, I think using one is usually an anti-pattern. At least, when using #embedded @rustlang.

Yes, even for hard real-time systems.

1/N One of the first things I see people asking when moving from C to @rustembedded is "what RTOS can I use in Rust"?

I think this is the XY problem: people ask/reach for an RTOS because that was the only thing that made sense for any reasonably complex system in C!

Why?

2/N