corecode[m] has quit [Quit: Idle timeout reached: 172800s]
Vicente[m] has quit [Quit: Idle timeout reached: 172800s]
takkaryx[m] has quit [Quit: Idle timeout reached: 172800s]
nadja has quit [Ping timeout: 252 seconds]
nadja has joined #rust-embedded
robtsuk[m] has quit [Quit: Idle timeout reached: 172800s]
Makarov91 has quit [Ping timeout: 256 seconds]
<bartmassey[m]>
<Jonathan[m]> "I seem to have been mentioned..." <- I just did a search and got nothing. Don't remember, I'm afraid.
M9names[m] has joined #rust-embedded
<M9names[m]>
<Jonathan[m]> "I seem to have been mentioned..." <- were you mentioned specifically or just pinged when the whole room was for the weekly meeting?
<bartmassey[m]>
<therealprof[m]> "bartmassey: How would you like..." <- Feel free to file issues! I think there is a lot I could still clean up, but do appreciate the help.
<bartmassey[m]>
bartmassey[m]: I plan to try out an automated link-checker to at least make sure all the links are live
<bartmassey[m]>
<therealprof[m]> "I think they're talking about..." <- Yeah, the main MCU is always nRF52833, but all the ones I have have the nRF52820 debugger
<Jonathan[m]>
<M9names[m]> "were you mentioned specifically..." <- might have been it. Thanks :)
<JamesMunns[m]>
<ejpcmac[m]> "And people doing Rust for..." <- Yep, this is a pretty common "on ramp" for folks using Rust in embedded :D
<ryan-summers[m]>
How have other HALs managed the e-h transition? Do people support both, or have any just gone the route of "Just do 1.0"? There's a lot of abandoned crates out there unfortunately still using the 0.2 versions
<ryan-summers[m]>
I think embassy is currently doing support for both
diondokter[m] has joined #rust-embedded
<diondokter[m]>
<ryan-summers[m]> "How have other HALs managed..." <- Yeah I think it's stilly pretty valuable to have your HAL support the 0.2 version
<diondokter[m]>
s/stilly/still/
<ryan-summers[m]>
Yeah as much as I want to just force everyone to 1.0, there's definitely crates that will just never get updated. Unsure how to deal with that
<diondokter[m]>
Well, at some point it becomes niche enough or complicated enough to remove support.
<diondokter[m]>
At least there's no reason to write new things with eh02. So it is truly legacy
<diondokter[m]>
I believe there are adapter crates too right?
<vollbrecht[m]>
<ryan-summers[m]> "How have other HALs managed..." <- in esp-idf-hal we supported 1.0 through all alpha versions up to the release version, but kept 0.2. It's not a big cost to do so. And the benefits are still huge for most users.
<vollbrecht[m]>
The downsite is that especially new users are often totally overwhelmed with version mismatch between 0.2 and 1.0 drivers...
<vollbrecht[m]>
but well that's just the problem with trait interfaces in general and its plumming
<vollbrecht[m]>
so in that regard its a lose / ö
<vollbrecht[m]>
s/ö/lose situation/
<vollbrecht[m]>
either make it that this version mismatches can't happen for new users by not supporting 0.2 -> thats make it less usefull for new users that still needs just a 0.2 driver to work
<vollbrecht[m]>
or expose them to the exposed complexity of version mismatch right at the beginning -> makes new users also more frustrated then they need to be
<vollbrecht[m]>
s/exposed//
<vollbrecht[m]>
* or expose them to the complexity of version mismatch right at the beginning to support as much as possible -> makes new users also more frustrated then they need to be
<jessebraham[m]>
<dirbaio[m]> "recommendation is for HALs to..." <- Has there been any discussion as to how long we will recommend this? Just curious
<jessebraham[m]>
There's obviously no real maintenance burden in keeping the old impls, but also I like deleting code 😁
<dirbaio[m]>
there hasn't. it's a good q yep
<dirbaio[m]>
I guess it's up to each individual hal maintainer to decide
<jessebraham[m]>
I mean the 1.0.0 release is still relatively fresh (at least in embedded-hal time 😁) so I didn't expect there to have been haha. We're using the 1.0.0 traits by default now at least, just to encourage people to use them too
<dirbaio[m]>
but personally i'd just keep it for a long time. until the probability of someone finding an eh0.2 driver is <1%
<dirbaio[m]>
which sounds like it's going to be MANY years
<dirbaio[m]>
but still the ease of use is probably worth the little extra code
<dirbaio[m]>
people struggle often with traits trying to glue one hal with one driver
<jessebraham[m]>
I completely agree, but I do worry that without pressure drivers won't get updated to use the new traits
<JamesMunns[m]>
Might be worth doing some impl sessions on meetings to identify and PR drivers that can be update
<JamesMunns[m]>
or solicit replacements if maintainers aren't active anymore (and update the awesome list or the cooler parametric search to prefer the new ones)
<ryan-summers[m]>
One issue I've found is that there's often just abandoned personal repos that people still use and there's no longer any maintainer with permissions
<dirbaio[m]>
there is a looooooooot of drivers tho
<JamesMunns[m]>
in most cases it isn't challenging to switch over, but it's busywork
<JamesMunns[m]>
I'd imagine having a session where 8 of us are chugging through could probably do some damage pretty quickly :p
<ryan-summers[m]>
I've encountered quite a few that have had PRs for e-h 1.0 traits for months with no response :/
<JamesMunns[m]>
IMO: adding those forks to r-e-c is reasonable
<dirbaio[m]>
and "picka random driver, update it" is a bit hard if you don't have the hardware. I wouldn't feel ok PRing something I haven't tested in hardware
<ryan-summers[m]>
Yeah but you still don't have crates-io publish perms
<JamesMunns[m]>
yep, I'd be suggesting new crates
<ryan-summers[m]>
I mean its a step forward, but doesn't 100% solve the issue of people using old stuff unintentionally. But yeah, you can always fork and repub
lulf[m] has joined #rust-embedded
<lulf[m]>
driver-ng :)
<lulf[m]>
* $driver-ng :)
<ryan-summers[m]>
That being said, we'd probably need to keep expanding r-e-c 😅
<dirbaio[m]>
actually-maintained-$driver
Makarov54 has quit [Ping timeout: 256 seconds]
andar1an[m] has quit [Quit: Idle timeout reached: 172800s]
JomerDev[m] has quit [Quit: Idle timeout reached: 172800s]
jxsl has quit [Remote host closed the connection]
<balbi[m]>
Hi folks,
<balbi[m]>
in the context of cortex-m devices, is there any different between `compare_exchange()` and `compare_exchange_weak()`?
Vicente[m] has joined #rust-embedded
<Vicente[m]>
embassy_net::tcp::client::TcpClient needs a no_std_net::SocketAddr for connect. embassy_net::dns::DnsSocket gives a smoltcp::Address. So I'm a bit lost trying to convert those address. Any idea on how to do it?
<dirbaio[m]>
why are you using the embedded-nal TcpClient?
<dirbaio[m]>
do you actually need embedded-nal?
<Vicente[m]>
I think I saw it on embassy examples
<Vicente[m]>
So what TcpClient must I use?
<dirbaio[m]>
that uses embedded-nal, which is a crate with traits that abstract network stacks.
<dirbaio[m]>
similar to embedded-hal but for networking
<dirbaio[m]>
if you don't need it it's much simpler to use TcpSocket directly
<dirbaio[m]>
in that case the connect() method takes the same IP address type
<dirbaio[m]>
and you don't have to convert anything