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!
It has literally split the ecosystem I’m not sure why people think it hasn’t. There’s basically embassy then everything else. Embassy has been quite successful in large part because its primary author took the time to make it good.
If you look at espressif and how they support rust they have to offer both blocking and non blocking options, they also offer using rust on their freertos and C library setup. It’s quite an undertaking to do all of this.
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".
But alarms drive engagement. Also, display a company logo and complete product name™
More seriously, I have a garmin watch that displays notifications for things, but they automatically disappear and you cannot figure out what they were.
I think being overwhelmed by alarms should be matched with the confidence that you can find the alarm if you accidentally dismiss it or something important comes up.
Chemical companies could allow vendors to sponsor various alarms in their plants: "the Flowserve(tm) High-Level alarm on T102 is active!"..."the Flowserve(tm) High-Level alarm on T102 is active!". Then there could be a contractual minimum for the number of times that ad needs to be served to operators and engineers, otherwise the chemical plant would need to refund Flowserve for the unused ad campaign credits. Lowering the threshold of the high-level alarm would optimize ad revenue!
Uhm, my recent washing machine purchase involved actively looking for not needing an app. They did try hard though, for example by offering 3 more years of warranty when you install the app.
Either the cost or repair/replacement during those extra 3 years is really low or your data is really valuable. Adds flavor to the challenge in designing it to last just long enough to leave warranty.
Data is probably not the only advantage they get from the app. For example, you are more likely to purchase other appliances from the same vendor so that you can have them all in the same app.
My washing machine doesn't beep when it is done. My dryer does. So I some times don't time the emptying of the washing machine and have to wait a couple of minutes and the dryer annoyingly beeps when done.
How about an alarm with a mute button. Then everyone can be happy.
That's why the first thing I do on my new phone is disable the Google app.
It does absolutely nothing useful for me, but never sleeps, eats resources and shows you advertisements.
I also hate the mobile apps that designed to be always on, always listening or nagging.
So, I have the policy: if the app is only useful occasionally and it is active but I didn't start it - I disable it. And I'll enable an app when I need it, not whenever it wants me to use it.
I consider any notification for something I did not explicitly sign up for an ad. So if I get a notification like "use Gemini" or "heres a tip:", that's an ad.
Unfortunately that makes, like, half the default notifications on Android ads. But you can disable all of it.
Which one contributes more to alarm fatigue, spoken announcements like "bank angle" or beeps and buzzes like the autopilot disengage theme tune? Why is the latter so prominent?
If it's something that happens often (like on every trip or most days), a spoken announcement is more tiresome. If it happens rarely, the beep-encoded one is way more tiresome and can reduce situation awareness.
Curious if there's research - I'm sure there's tons, I just don't know that literature - but personally, in my experience as a professional aviator and as a spacecraft operator, the fatiguing alarms are the ones that are triggered in normal situations. If you start blinking red and squawking at me when I'm doing something nominal, you are training me to ignore you.
Autopilot disengage is heard every single flight and is completely benign... unless neither pilot was expecting it in which case it is very effective at getting our attention.
Squelch is a dial that changes a threshold below which analog radio signals are silenced so you can ignore noise. The dial allows you to dig into the noise when you want or be more conservative and only pass strong signals through.
Not quite. More like signal-to-noise-ratio gate. In radio transmissions, there is white noise when no active signal is received. Radios mute themselves when there is white noise, as to not annoy the user. On 2 way radios this is very important otherwise the radio will be hissing at you most of the time.
The squelch setting determines the threshold of signal to noise allowed through. If the incoming transmission signal strength is really bad, the radio might not unmute itself. So you turn down the squelch, which might completely open the radio bringing in white noise, but you can then receive the transmission.
Isn't they exactly what a noise gate does? You set a level of loudness below which it mutes all sound. If sounds levels go above that then it plays whatever sounds goes above it.
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.
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!
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).
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!
reply