jamesmunns

Shipped to the customer, we don't offer leased/managed hardware or VM instances.

My materials probably took 4-6 hours to write the first draft (I did most of it over two evenings, maybe one more just skimming the questions to figure out what things to talk about for each question), probably 2-3 hours or so to edit, then probably another hours over an evening just skimming it too many times before I hit submit. My materials were 16 pages or so, some of that was the original document (which has been linked in this comment section).

It's a fair bit of writing to ask for, but for a mostly remote and prose-driven company, you do a lot of long-form writing in the day to day work. The public RFDs and github issues/comments/commits give a good flavor for this.

As others have said, lots of my work is open source, and I have public writings and talks, so finding those were much easier for me than it might be for someone with only closed source works.

There's no single "embassy" crate, but all the components (HALs, executor, usb, net, etc.) are all on crates up and have been for a long time.

It's worth noting that the support for ESP32 in Rust is official [0], and there are multiple full time engineers at Espressif working on developing and maintaining it.

[0]: https://github.com/esp-rs/esp-hal/

It's really not so different! In embassy, DMA transfers and interrupts become things that you can .await on, the process is basically:

  * The software starts a transaction, or triggers some event (like putting data in the fifo)
  * The software task yields
  * When the "fifo empty" interrupt or "dma transfer done interrupt" occurs, it wakes the task to resume
  * the software task checks if it is done, and either reloads/restarts if there's more to do, or returns "done"

It's really not different than event driven state machines you would have written before, it's just "in-band" of the language now, and async/await gives you syntax to do it.

Even if you don't know Rust, I'd suggest poking around at some of the examples here:

https://github.com/embassy-rs/embassy/tree/main/examples

And if you want, look into the code behind it.

Speaking as someone familiar with C and Rust (not so much Go!), although there's a parallel here to Rust's Traits, this actually is much closer to dyn Trait in Rust, which uses vtables and runtime polymorphism, rather than "regular" Traits in Rust, which are monomorphized versions of similar interface constraints, much closer to C++'s templates (or concepts, I'm hand waving here).

This isn't necessarily a negative, sometimes you actually prefer vtables and runtime polymorphism for various reasons like flexibility, or code size reasons. Just wanted to add some flavor for folks that aren't as familiar with Rust, that this isn't exactly how things usually work, as "regular" Trait usage is much more common than dyn Trait usage, which you have to explicitly opt-in to.

As others have mentioned, ~all of the embassy HALs support nearly 1:1 parity of blocking interfaces for drivers next to the async ones. You really can avoid async entirely while still using embassy hals. The ecosystem is not tightly integrated/locked in.

Even data structure libraries, like embassy-sync, all have `try_` methods, which would allow for polling usage outside of async.

There's no mandate to use async - and helping folks that DO see value in it (which is a LOT of folks), isn't "splitting the ecosystem" - it's people doing things the way they like to do it. Embassy still works very hard to support folks who DON'T want to use async, to avoid duplicated work. There's nothing stopping you from preferring to write and maintain your own HALs, I know you have been for a while! But it's not something that people necessarily have to do, even if they aren't interested or don't prefer async!

If you haven't seen it, Mara Bos' "Rust Atomics and Locks"[0] is an excellent book on this topic, even if you aren't particularly interested in Rust.

[0]: https://marabos.nl/atomics/

In safety industries, particularly aviation, "alarm fatigue" is a really big deal. You recognize that pilots have limited situational bandwidth, and you REALLY don't want to be bugging them about things you can avoid. I worked in collision avoidance systems (TAS/TCASI/TCASII), and spent nearly a whole year just working on figuring out when and how we could avoid warning pilots in cases where "we're not sure exactly what is going on, so tell the pilot just in case" could potentially annoy pilots in cases like take off and landing (where they have important OTHER things to be doing!)

It's a fun balance between "possibly don't warn the pilot about something they should know about", and "don't warn them if they are busy doing something important".

More devices should have a "squelch" switch!

Nordic's nRF family is the major other vendor I've seen doing this, almost all peripheral can be on any pin. It's definitely a big help for designing boards.

SEEKING WORK | Remote | Rust and Embedded Systems

Location: Berlin, DE

Remote: Yes

Willing to relocate: No

Technologies and tools: Rust, Embedded Systems (Cortex-M, RISC-V), Desktop/server apps/tools, async/await

Website: https://onevariable.com

Email: [email protected]

GitHub: https://github.com/jamesmunns

Hey, I'm James! I have my company (OneVariable), and have 7+ years of embedded Rust experience, and 10+ years of embedded experience. I've been helping teams start using Rust, or scale up their use of Rust, through advising, training, and development assistance, as well as "Senior as a service" to help teams that are ramping up but still need help with questions around embedded/rust. Happy to help customers in EU and NA time zones.

Let me know if you need any help getting big computers talking to smaller computers!

Kobzol is an absolutely wonderful person to work with. I also work in the Rust project, and any time I've interacted with him, he's been great.

You definitely can, I designed a 206x85cm standing banner for my last trade show as one of the first "production" things I built in Typst:

https://typst.app/project/r1YNDcKpoF1sVXHf5n4VKB

Plus you can share the rendered and preview form of the project with a single link, which is pretty neat.

Thank you for sharing, I'd never seen this before. It's an incredibly good read (and relevant for me) so far.

Thanks for Sublime Text! It's been my daily driver for over 15 years :). 10 of those developing Rust, and making heavy use of the Rust Analyzer/LSP plugin infra.

I also want to thank you for having such a reasonable licensing model, I'm launching my own desktop app in the next week or so, and I plan to have a very similar model to Sublime (free to use with nags, license is good for any personal usage, inclusive of updates for X period of time).

For 3, if you haven't seen snapshot tests, like those using the insta crate, it makes it very easy to detect when values change like this in tests/ci.

This is entirely incorrect, Ferrocene manages a specification of a subset of the language here: https://public-docs.ferrocene.dev/main/specification/index.h..., including things like a traceability matrix that links the specification to the implementation and the verification: https://public-docs.ferrocene.dev/main/qualification/traceab...

For each release of Ferrocene, this is kept up to date, and the same as C or C++, what is specified and stable can be relied upon, and implementation details are implementation details, the same as it would be if you switched from LLVM w/ SolidSands' SuperTest suite to IAR or GreenHills' toolchains which may have varying impl details but still maintain conformance with the specification.

The majority of safety critical teams will snapshot a single toolchain for the entire development lifecycle (sometimes updating if necessary, very rarely), but Ferrocene is releasing updates that are approaching the full Rust cadence (IIRC they've discussed going to every other release, so once every 12 weeks vs Rust's 6 week cadence), with all of the verification required to ensure the specification is still complete, and all tests are passing.

There's still work to specify and test more/all of the core/alloc/std library components, as well as third party crates, but from a toolchain perspective, it is much closer than you are giving them credit for. Unlike many proprietary C/C++ toolchains or verification suites, the majority of safety justification artifacts are publicly browseable here: https://public-docs.ferrocene.dev/main/index.html.

(I am a former founder of Ferrous Systems, and one of the people that pushed for the Ferrocene project to happen, but haven't worked there for a couple years and have no monetary stake in them anymore - I think they are just still doing the right thing, and doing it well.)

I bridged my bluesky account, if you're on mastodon and want to talk to me here, you're welcome to. Not sure if you need to opt-in on the mastodon side to be bridged to bluesky.

@[email protected]

I think you can opt-in here? https://fed.brid.gy/bsky/jamesmunns.com/followers

You don't generally need to license Arm chips unless you are designing your own chips for sale, like STM32 or Raspberry Pi do. This is something very few companies do, relative to those who just build things from existing chips.

If you're just building something with an existing Arm microcontrollers. The vendor (Like STMicro) has already licensed the Arm design and sold it to you.

In general in Rust, lifetimes enforce that references to a thing do not outlive the thing itself.

Even in unsafe code, it is possible to tie the lifetime of the allocations to the lifetime of the thing handing out the allocations, meaning that if you ever attempt to "escape" the scope, e.g. storing a shorter lifetime allocation in a longer lifetime allocation, that outer item can now only live as long as the shorter lifetime (even though it derives from the longer lifetime allocator). Any violation of this becomes a compile time error.

For example, within a function, you can have a Vec of references to local items, and although the Vec is an allocation, and COULD live forever/as long as necessary (allocations have 'static lifetime), that Vec MUST be dropped at or before when the references it contains would become invalid.

Tock-OS, Oxid-OS (the safety version of Tock-OS, like freertos/safertos), and Hubris (from Oxide Computers) are the main three RTOSs, Embassy and RTIC are common frameworks (but not classic RTOSs) used for scheduling and resource management on bare metal systems. There are some more niche or non-public ones as well.

For more classic OSs (not real time), Redox is the main one, as well as a lot of research/experimental/teaching ones, including the Blog OS from this guide/submission.

Phil's writing on OS development is always a wonderful read.

Additionally, recursion and function pointers (including dynamic dispatch) are the other two "normal" language features that can defeat static stack analysis. There are techniques for working around this (bounded annotations, languages with strong types can narrow potential dispatch options), but it's a little harder.

> Embassy has it's own HALs which makes it better at async and has also nicer ergonomic IMO

Worth noting, you don't HAVE to use the embassy HALs with the embassy executor. However, AFAIK, the only mainstream non-embassy HALs that supports async is the ESP32 HALs.

There's no technical lock in, it's just that everyone I've seen implementing async support (outside ESP32) tends to do it within the Embassy project today. That may change over time.

The usual solution, including in safety critical systems, is to give the judge of the halting problem a stopwatch and a gun.

For example in an embedded system: a watchdog timer that you don't service during the execution of some context. If you fail to complete your task within the time, the kernel or entire system is rebooted.

For example in a VM-like system, you give the code some amount of "fuel" or "budget", if it exceeds that budget, the process/tasklet/whatever is terminated by the VM.

It's not a general solution to the halting problem, but a practical one.

Yep. Sometimes it's "known issues are avoidable issues", and other times it's "hey I wish we didn't spend xx% of our time avoiding (incl. spending time auditing syntax) or doing mitigations for the same limitations/issues over and over and over again".

The wheels do turn, just slowly.

Having worked in both kinds personally, it's different.

You spend more time on less topics: the variety of work is much lower, which some people love, and some people are frustrated by. There is often much less "drastic innovation", or when there is, it takes much longer than you might be used to in other industries. Favor is given to proven, predictable technologies and choices, even if that leaves some opportunities on the table.

That being said, it's something I often miss. The ability to have such solid confidence on the things you've built, and the ability to drop into nearly any piece of the system and have everything be consistent and predictable is a quality in itself. It makes debugging (often VERY rare) issues much more tractable, both at a higher systems level, as well as digging deeper into the code itself.

Having worked in a couple of safety critical companies, there are things you definitely HAVE to do, but some companies do it better than others.

Some companies have process and development practices down pat: things go smoothly, and meeting the qualification process objectives is easy, because the work has been done right the whole way.

Other companies have less established or less consistent process. They generally meet the process objectives and deliver a working product, but the development process is often more of a struggle, and there is often a lot of "cleaning up" of missed pieces at the end of the release process.

This is just to say: companies and products in the safety critical space don't necessarily have some intrinsic quality, just a higher minimum bar.