* 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"

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.

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.

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!

Comments URL: https://news.ycombinator.com/item?id=45758701

Points: 7

# Comments: 0

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

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!

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: contact@onevariable.com

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!

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.

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 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.)

@jamesmunns.com@bsky.brid.gy

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

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.

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.

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.

Comments URL: https://news.ycombinator.com/item?id=41321504

Points: 6

# Comments: 0