<re_irc>
<@9names:matrix.org> josfemova:matrix.org: I've got a QuickFeather, been meaning to start a HAL for it but haven't found the time yet. It's EOL but the "SparkFun Thing Plus" is the spiritual successor for that board.
<re_irc>
<@9names:matrix.org> Qomu is still available, but with only and RGB LED and 4 pins broken out there's not a lot to even build support for.
<re_irc>
<@9names:matrix.org> In my opinion, very niche.
cr1901_ is now known as cr1901
<re_irc>
<@9names:matrix.org> thejpster:matrix.org: There's also BL602 though the number of active contributors was ~3/month at it's peak and is approximately 0/month at the moment.
<re_irc>
<@9names:matrix.org> Lot's of other things to work on, and reverse engineering the hardware as you go makes developing a HAL painfully slow.
<cr1901>
gauteh: I have one, but... it's not usable for your use case (or mine yet, for that matter): gauteh
procton__ has quit [Read error: Connection reset by peer]
procton_ has joined #rust-embedded
PyroPeter has quit [Ping timeout: 250 seconds]
PyroPeter has joined #rust-embedded
gsalazar has joined #rust-embedded
<re_irc>
<@gauteh:matrix.org> irc_libera_cr1901:psion.agg.io: thanks, not sure how well the algorithm would perform on the data. its filtered accelerometer data.
gsalazar_ has joined #rust-embedded
cr1901 has quit [Remote host closed the connection]
cr1901 has joined #rust-embedded
gsalazar has quit [Ping timeout: 256 seconds]
<re_irc>
<@barafael:matrix.org> If i make or use a blocking embedded-hal driver today, it's great. What's the story in the future regarding asynchronous usage? I assume the drivers which already exist will have to be reworked? Will it be async/await, RTIC, RTOS, agnostic? Any plans? Just curious :)
<re_irc>
<@ryan-summers:matrix.org> Consider the fact that an async driver would require that anyone using use an async runtime, which not everyone may want to do.
<Lumpio->
...yes!
<Lumpio->
err
<Lumpio->
...yet!
<re_irc>
<@ryan-summers:matrix.org> I imagine adding a wrapper around a blocking driver to make it async would work as well, although i2c/spi/uart comms would still be blocking
<re_irc>
<@jamesmunns:beeper.com> Honestly the hardest part requires you to have stable static storage, either provided by your runtime, a global allocator, a slab allocator (like byte-slab or heapless pool), or something else special like bbqueue
<re_irc>
<@ryan-summers:matrix.org> But who knows, async may become just "the way it's done" in the future. I'd certainly love it
<Lumpio->
Hopefully async will be the default one day
<re_irc>
<@ryan-summers:matrix.org> But there's a lot of safety critical industries that don't want to bring in more complexity like async, even if it makes programming easier, just because it can be harder to verify
<re_irc>
<@dirbaio:matrix.org> you can "convert" an async driver to a blocking driver by essentially doing `loop { future.poll() }`, no async runtime needed
<re_irc>
<@jamesmunns:beeper.com> And the likelihood of everyone wanting the same thing is hard. I like embedded-dma for abstracting over that, but I think someone had objections to that?
<re_irc>
<@jamesmunns:beeper.com> dirbaio:matrix.org: If the driver doesn't rely on any other signals to make progress :p
<Lumpio->
I still want to write async usb-device one day
<Lumpio->
One day...
<Lumpio->
There's things that could be so much nicer that way.
<re_irc>
<@dirbaio:matrix.org> irc_libera_lumpio-:psion.agg.io: embassy has an async wrapper for usb-device
<re_irc>
<@dirbaio:matrix.org> jamesmunns:beeper.com: what signals? the Future trait explicitly allows polling in a loop like that
gsalazar_ has quit [Quit: Leaving]
gsalazar has joined #rust-embedded
<re_irc>
<@jamesmunns:beeper.com> In some of my cassette stuff, you need to poll OTHER futures to have thing show up, like one task that sends messages over a queue to another
<re_irc>
<@jamesmunns:beeper.com> but I guess that wouldn't be common for most hw drivers.
<re_irc>
<@jamesmunns:beeper.com> (that's more for my network stack stuff)
<re_irc>
<@jamesmunns:beeper.com> I think the futures crate might even have a `block_on` method these days?
<re_irc>
<@tmplt:matrix.org> adamgreig: thanks for the `itm` crate ownership. I forgot to communicate its dependency on an unreleased cortex-m rev.: https://github.com/rust-embedded/cortex-m/issues/368. Sorry about that.
<re_irc>
<@tmplt:matrix.org> Regarding the v0.3-breaking release TBD: the `itm` fork also replaces `itm-decode` by making it a binary-only crate. It's currently at v0.6.1, so I will bump `itm` and `itm-decode` to 0.7.0 when I'm able to publish.
<re_irc>
<@dirbaio:matrix.org> jamesmunns:beeper.com: then just poll-loop `join(fut1, fut2, fut3..)`
<re_irc>
<@adamgreig:matrix.org> even if we release a 0.8-alpha you won't be able to use it because everything else (rtic, PACs, HALs,...) will be on 0.7 and can't have both
<re_irc>
<@9names:matrix.org> oh no
<re_irc>
<@adamgreig:matrix.org> Maybe we can do a new cute hack
<re_irc>
<@dirbaio:matrix.org> semver-hack the singletons? :P
<re_irc>
<@adamgreig:matrix.org> Considering it
<re_irc>
<@jamesmunns:beeper.com> Is there a write-up explaining why the singletons are going away? I've been out of the loop on that decision
<re_irc>
<@adamgreig:matrix.org> I would say they're not going anywhere yet, but consensus is building on the idea that they should move to HALs instead of PACs
<re_irc>
<@adamgreig:matrix.org> Having them in PACs (and/or cortex-m's sort-of-PAC) causes so many issues, not least the "whole ecosystem must use identical versions" thing
<re_irc>
<@adamgreig:matrix.org> Not sure of any write-up yet though... one would exist before we do anything
<re_irc>
<@jamesmunns:beeper.com> Gotcha, if there's an issue thread, I could catch up on that too.
<re_irc>
<@adamgreig:matrix.org> adamgreig: This would just be finding a cute hack to let a new 0.8alpha of cortex-m interoperate with 0.7 so that an application could use both at once, for example by having 0.8 use 0.7's type definitions and forward take() to it
<re_irc>
<@adamgreig:matrix.org> Only works where types are textually the same but I believe that's currently more or less the case (tbc...)
<re_irc>
<@tmplt:matrix.org> adamgreig: Except if the source of the ITM packets are raw bytes, which is usually the case.
<re_irc>
<@adamgreig:matrix.org> Huh, does itm-decode the desktop application depend on cortex-m 0.8?
<re_irc>
<@adamgreig:matrix.org> That is much easier admittedly
<re_irc>
<@tmplt:matrix.org> Yes, and `itm` itself because it needs the serde functionality that was recently added.
<re_irc>
<@adamgreig:matrix.org> Might be the first non-embedded dependent, hm
<re_irc>
<@adamgreig:matrix.org> Anyway that does simplify a 0.8 alpha a lot for this specific use-case
<re_irc>
<@dirbaio:matrix.org> first non-embedded non-accidental dependent 🤣
<re_irc>
<@tmplt:matrix.org> `cargo-rtic-scope` is another that uses std/serde-`cortex-m` host-side
<re_irc>
<@dirbaio:matrix.org> is cortex-m on non-embedded even supported?
<re_irc>
<@dirbaio:matrix.org> I recently found it it doesn't build for android cdylibs (was accidentally using it, it causes some linker error)
<re_irc>
<@jamesmunns:beeper.com> I think it compiles on desktop targets, but cfgs everything away
<re_irc>
<@jamesmunns:beeper.com> Mostly for docs support, IIRC
<re_irc>
<@dirbaio:matrix.org> hm, fun
<re_irc>
<@tmplt:matrix.org> I only use some conventient structures host-side. `itm::LocalTimestampOptions` and `scb::VectActive` specifically.
rardiol has joined #rust-embedded
gsalazar has quit [Ping timeout: 252 seconds]
<re_irc>
<@tholmie:matrix.org> in `cortex-m`, I see that the `ptr()` function to get the pointer to the register block has the comment "to be deprecated in 0.7", but it's already 0.7 and it isn't deprecated... was this just missed or is it no longer the plan?
crabbedhaloablut has quit [Quit: No Ping reply in 180 seconds.]