<JamesMunns[m]>
Wow those are some trait bounds :D
ivche_ has joined #rust-embedded
ivche has quit [Ping timeout: 252 seconds]
ivche_ is now known as ivche
pcs38 has joined #rust-embedded
<PhilMarkgraf[m]>
<JamesMunns[m]> "Wow those are some trait bounds..." <- Yeah, it takes a lot of code to say "act like a number"...
<PhilMarkgraf[m]>
<PhilMarkgraf[m]> "Not your problem, I'm sure..." <- P.S. the compiler bug is fixed on nightly... crossing fingers that it will be in the 1.87.0 release mid-May.
<danielb[m]>
<PhilMarkgraf[m]> "P.S. the compiler bug is fixed..." <- it will not
<Ralph[m]>
one thing i missed: why was heapless 0.9 released if the plan seems to be to release 1.0 soon? doesn't that cause too much ecosystem churn if there are two breaking releases close to each other?
<SosthneGudon[m]>
<Ralph[m]> "one thing i missed: why was..." <- Because there were a lot of contributions pending a release and that 1.0 was blocked by some future dependencies reaching 1.0 I think github.com/rust-embedded/heapless/issues/535
<SosthneGudon[m]>
But wait, there were some more breaking changes that probably should have been included as part of a 0.9.0 release: https://github.com/rust-embedded/heapless/issues/494, not all of them were included
<SosthneGudon[m]>
I didn't initially make PR for them because I thought the next release would have been a 1.8.1
<SosthneGudon[m]>
s/1/0/
<JamesMunns[m]>
Looks like due to a rustsec advisory, postcard is indirectly going to cause some cargo-deny errors.
<JamesMunns[m]>
As a heads up, this is going to cause me to pull the 2.0 trigger for postcard to remove heapless (and as many other deps as possible) from the public API, feel free to link here if you have any issues caused by the rustsec advisory: https://github.com/jamesmunns/postcard/issues/223
<JamesMunns[m]>
Likely eta this weekend, reminder this will not be a breaking WIRE change, only a breaking LIBRARY change. 2.x and 1.x will have full compatibility "over the wire".
<JamesMunns[m]>
If you have a library that has postcard as a public dep/feature, please ping me if you want help upgrading.
Lumpio- has quit [Ping timeout: 244 seconds]
ouilemur has quit [Quit: WeeChat 4.6.1]
newam[m] has joined #rust-embedded
<newam[m]>
reitermarkus: work is still busy for me, but please reach out if you need reviews on heapless PRs to move forward on 0.9.1, I woke up to 100ish emails from GitHub, only skimmed them so far.
<newam[m]>
Should we yank 0.9.0 until we get the generics fixed? I'm thinking it could save people a lot of time.
Lumpio- has joined #rust-embedded
<dirbaio[m]>
I don't think the LenType issue is fixable
<dirbaio[m]>
well, that pr is effectively removing it almost completely
<dirbaio[m]>
it will no longer do the "pick smallest len type possible", the user has to pick it explicitly
<dirbaio[m]>
like, if you do that you might as well remove DefaultLenType
<dirbaio[m]>
because it's useless now
<dirbaio[m]>
if you use a fixed size then you can also use a fixed len type, you don't need DefaultLenType
<dirbaio[m]>
and if you use a generic size then DefaultLenType doesn't work
<SosthneGudon[m]>
We can add a second allias (VecOpt) that has that has the DefaultLenType behaviour opt-in for users who need the couple of bytes saved.
<newam[m]>
<Ralph[m]> "one thing i missed: why was..." <- 1.0 is still an unknown amount of time in the future, it's on the scale of months.
<newam[m]>
People have been asking for a release before then.
<SosthneGudon[m]>
I made my PR minimal and so things could be added back later to fix the issue ASAP. I'm not sure what's the best path forward, It's clear to me that DefaultLenType indeed can't be the default behaviour, but I don't think that means all the LenType stuff has to go. It can stay opt-in.
<dirbaio[m]>
yeah just leave LenType in, defaulting to usize
<dirbaio[m]>
but I'd remove DefaultLenType, ZeroLenType
<newam[m]>
Unless somebody disagrees I'm going to yank 0.9 until these issues are fixed.
<newam[m]>
* yank 0.9.0 until
<dirbaio[m]>
there's no reason you'd want to write `Vec<Foo, 5, DefaultLenType<5>>` instead of `Vec<Foo, 5, u8>`
<dirbaio[m]>
and about the type alias `VecOpt<Foo, 5>`, i'm not sure if it's worth it
<SosthneGudon[m]>
It can be an alias. But it means it can also be maintained in another library that just provides the DefaultLenType and a bunch of aliases with it
<SosthneGudon[m]>
Makes sense to remove it from heapless
<dirbaio[m]>
heapless 0.9 has gone way up in complexity with the views and lentype, adding yet more type aliases complicates it even more
<SosthneGudon[m]>
Should I remove the default for Idx = usize in SortedLinkedList so that the order of generics is the same as 0.8.0 (to remove the need for updating it downstream?).
<dirbaio[m]>
it'd make sense if you write `Vec<Foo, N>` and someone else instantiates it with `N=0`, but the auto-lentype-optimization doesn't work for generic N
<SosthneGudon[m]>
newam[m]: Thanks!
<dirbaio[m]>
so the only use case is writing `Vec<Foo, 0, ZeroLenType>` explicitly
<hjeldin__[m]>
custom board following stm's usb specs (...mostly)
<dirbaio[m]>
hse is really 8mhz?
<hjeldin__[m]>
yep, everything else (i2c, spi, even sdmmc which shares the usb's 48mhz clock) works fine
<dirbaio[m]>
btw with these settings you're running sysclk at 40mhz, not the max of 80mhz. this shouldn't be the cause of it not working tho
<dirbaio[m]>
hjeldin__[m]: it's possible for hse to be "wrong" and everything still appear work, just too fast or too slow
<dirbaio[m]>
except usb which needs to be exactly 48mhz
<dirbaio[m]>
* still appear to work, just
<hjeldin__[m]>
it's time to bring out the oscilloscope then 😄
<dirbaio[m]>
you can try blinking a led at 1hz and eyeball if it's really 1hz
<dirbaio[m]>
the fact that linux thinks it's "low-speed" is a bit suspicious. maybe you're missing resistors on dp/dm or have them swapped? i'm not very familiar with the low-level details of usb
Amit[m] has joined #rust-embedded
<Amit[m]>
Hello all, a bit of promotion here: a call for talks is up for TockWorld (annual Tock conference) to be held the day after RustConf in Seattle. It would be a great venue to also share non-Tock work or ideas in low-level and embedded Rust: https://world.tockos.org/tockworld8/cfp
<dirbaio[m]>
> low-speed and full-speed operation are mutually exclusive, and are determined at the time of device attachment (if DP is pulled high -> FS, if DM is high -> LS).
<dirbaio[m]>
maybe yeah
<JamesMunns[m]>
Lemme know if you have a bsky account or post you want me to share, or I can copy/paste that into a post :D
<Amit[m]>
Amit[m]: The audience will at least include of bunch of practitioners who write very embedded Rust at major companies (MS, Google, AMD, Amazon, etc) as well as many more of us mere mortals
<dirbaio[m]>
hjeldin__[m]: don't trust the timestamp because that'll also be equally wrong. do the messages *look* like they're coming at once a second?
<dirbaio[m]>
check whether dp/dm are swapped and the pulls are correct
<hjeldin__[m]>
according to the specs for the l4, dp should already have a pullup provided by the chip and it cannot work as a low-speed device. let me check if dp is actually pulled up tho
Socke has quit [Ping timeout: 252 seconds]
MartinSivk[m] has joined #rust-embedded
<MartinSivk[m]>
Folks, how does the release process work for embedded hal async? There is a patch that adds support for async Input and Output pins. That helps with port extenders. It was merged some time ago. When will it become available via crates.io?
<dirbaio[m]>
send a PR updating the changelog and bumping the version number in Cargo.toml and I'll release it
Socke has joined #rust-embedded
<Ralph[m]>
dirbaio[m]: why are these central repos not using something like [cargo-release](https://crates.io/crates/cargo-release) which would take care of these things? it feels cumbersome and error prone to do these manually?
<dirbaio[m]>
send a PR setting up cargo-release then :D
<dirbaio[m]>
in a more serious note: this is an open source project run by the community
<dirbaio[m]>
the answer to "why isn't X done" is usually "because nobody has done X yet"
<dirbaio[m]>
so if you want to get X done the best way is to send a PR
<Ralph[m]>
whether or not `cargo-release` should be used is something to be decided by those with the power to actually release - there's no point in providing a PR for that if you (not you specifically; the group of people with the necessary rights) do not wish to use that tooling.
<Ralph[m]>
i'm fully aware of how open source works - i regularly contribute in various repos (and try to open source things which i can) and am very grateful for all the awesome open source projects out there!
<dirbaio[m]>
yeah
<dirbaio[m]>
I had alredy seen cargo-release before and think it could help with the release process, it's just I haven't had time to sit down and study how to set it up and use it
<adamgreig[m]>
we already have a gross macro to do this in cortex-m-rt but it would be neat to not have to use it
<adamgreig[m]>
and, thanks to everyone who has already responded to the membership update in https://github.com/rust-embedded/wg/issues/832, I'll try and ping the stragglers soon, if that's you please check the issue :P
<adamgreig[m]>
that's it from me, so onto the agenda!
<cr1901>
It's not a fun macro to read that's for sure
<adamgreig[m]>
rmsyn: are you around? do you want to say anything about the sd/mmc trait?
<adamgreig[m]>
cr1901: I think it's even less fun for the compiler to parse, it's O(2^n) I think?
<adamgreig[m]>
for n cfg statements
<cr1901>
Eep.
<adamgreig[m]>
go for it
rmsyn[m] has joined #rust-embedded
<rmsyn[m]>
adamgreig[m]: I'm around, I can talk about
<rmsyn[m]>
so, I've been working on a SD/MMC driver, and having a e-h trait to abstract common peripheral operations would be helpful
<rmsyn[m]>
mabez did an initial review of the PR I opened, and I'm still going over the points raised there
<rmsyn[m]>
roughly, I think adding the SD/MMC traits would make it easier to write a wider range of drivers, and also allow embedded-sdmmc-rs to expand beyond the SPI driver while still using e-h traits
<JamesMunns[m]>
Is there a plan to work on the traits outside of e-hal first?
<JamesMunns[m]>
like make a separate crate, hack on it for a bit, then merge the result into e-hal?
<JamesMunns[m]>
(or am I out of the loop and we're already at the upstreaming part?)
<rmsyn[m]>
yeah, I've been working on the traits for the HAL-level stuff inside jh71xx-hal, and @mabez recommended getting the traits working on at least one other platform. I'll try some experiments on another platform HAL
<rmsyn[m]>
for driver-level traits, I'm working on stuff inside sdmmc-driver
lanre[m] has joined #rust-embedded
<lanre[m]>
Sup nerds. Popping in just to say y'all are doing important work. Thank you
<JamesMunns[m]>
yeah, it seems reasonable to make a standalone crate for it, so you don't have to wait on approvals, but then merge to e-hal when it's "done"?
jannic[m] has joined #rust-embedded
<jannic[m]>
It would be nice to have a proof-of-concept port of embedded-sdmmc-rs to the proposed interface. Do you think that would be much work? Or maybe it's already available in some fork?
<cr1901>
You could also in principle implement these traits for an alternate SPI driver outside of e-hal?
<rmsyn[m]>
jannic[m]: I can try that, for sure. I've looked at `embedded-sdmmc-rs`, but don't know exactly how much work it would be to do a rework with the proposed traits
<thejpster[m]>
I think the general rule for traits is that they should exist first, and have implementations, before they get considered for official working group status
<thejpster[m]>
rmsyn[m]: If embedded-sdmmc-rs isn't amenable to being changed to use the traits ... then who *would* use the traits?
<rmsyn[m]>
JamesMunns[m]: right, I mostly wanted to get some initial feedback, and show my intention to give back to the e-h project
<rmsyn[m]>
thejpster[m]: I have every intention of doing the work to integrate the traits into `embedded-sdmmc-rs`, was merely stating I don't know off the top how much work that will be
<thejpster[m]>
oh, fair!
<adamgreig[m]>
cool, I think that's some good feedback there then :)
<adamgreig[m]>
next up, newam did you want to talk about the hash32 1.0 release at all?
<newam[m]>
Yeah! We're close to a hash32 1.0.0 release, any feedback before that release happens would be appreciated!
<therealprof[m]>
adamgreig[m]: E.g. but also if you have multiple types whether there's a lot of monomorphisation bloat...
<JamesMunns[m]>
The idea would be to have this list as a discussion point, mainly to chat with compiler folks at the all hands
<JamesMunns[m]>
(but also maybe plugging it as a "hey if you are looking to fund effective change, we the embedded wg specifically think these issues would have good ecosystem impact")
<JamesMunns[m]>
So not so much like "we need drivers/libraries for X", but more "async stack usage is problematic", "panic bloat causes impactful flash usage", etc.
<JamesMunns[m]>
I mostly want any links or notes folks have, I plan to write this up into a larger blog post/report
<JamesMunns[m]>
so if you have some favorite issues/prs you have bookmarked, please brain dump them there for me and I will do my best to get eyes on them :)
<thejpster[m]>
customers are always asking me "How can I check whether this function is free from panics"
<jannic[m]>
Would that include questions like how volatile mmio access should be done correctly? (Which as far as I can tell doesn't cause any current issues, so it's not really a papercut in the stricter sense.)
<JamesMunns[m]>
I'm happy to take larger improvement ideas like that too! I do plan to triage them a bit to better explain "what is the impact of fixing this, and how much work is it going to be/how far is it from being solved"
<therealprof[m]>
thejpster[m]: Is `no-panic` no_std?
<adamgreig[m]>
where are you taking them?
<JamesMunns[m]>
I'm not sure yet. I think having a written collection is useful, who we talk to about it is probably dependent on the issues themselves
<adamgreig[m]>
ah yea sorry, I meant "where are you soliciting submissions" rather than "who will you present them to"
<JamesMunns[m]>
last year we were able to pull Amanieu in to talk about mmio stuff, so having a "shopping list" of topics we could talk to folks about is probably helpful, and we can point them to the blog post as background context
<JamesMunns[m]>
ah!
<jannic[m]>
therealprof[m]: "The attribute is useless in code built with panic = "abort". Code must be built with panic = "unwind" (the default) in order for any panics to be detected."
<JamesMunns[m]>
I can go ahead and make a tracking issue now if you think that's better
<adamgreig[m]>
my linker script point was: right now application crates must specify compiler flags to include a linker script, which is a nuisance for every embedded project because they all need linker scripts, even though 95% are probably just using defmt.x and link.x from one of our -rt crates, so it would be nice if a crate could tell the linker to include a linker script from it directly, albeit there are probably some scary second order
<adamgreig[m]>
problems I haven't considered. it's been discussed before in the wg, I'm sure
<adamgreig[m]>
ok, let's wrap up with some issue triage thanks to jannic
<jannic[m]>
Yes, unfortunately it's not obviously why this was opened :-)
<jannic[m]>
Not a big issue, but if it's no longer needed, please close it.
<adamgreig[m]>
for https://github.com/rust-embedded/svdtools/pull/243 I think it could be merged, but it's probably one for burrbull who now maintains that crate (but I think didn't at the time it was opened)
<jannic[m]>
I successfully rebased it, fixed the trivial merge conflict, and the tests still worked.
burrbull[m] has joined #rust-embedded
<burrbull[m]>
adamgreig: Are you ready for stm32-rs release?
<JamesMunns[m]>
adamgreig[m]: thank you as always!
m5zs7k has quit [Ping timeout: 268 seconds]
m5zs7k has joined #rust-embedded
thalesfragoso[m] has quit [Quit: Idle timeout reached: 172800s]
pcs38 has quit [Quit: leaving]
BentoMon has quit [Ping timeout: 260 seconds]
ouilemur has joined #rust-embedded
kit[m] has joined #rust-embedded
<kit[m]>
As a beginner question - I'm playing around with the itsybitsy_m4 crate, and I'm struggling to format my strings - is there a slick way to glue together the print!/println! macro to a write function? Or is my best bet to follow https://stackoverflow.com/questions/50200268/how-can-i-use-the-format-macro-in-a-no-std-environment and write my own format_args writer to the pipe I'm aiming for?
M9names[m] has quit [Quit: Idle timeout reached: 172800s]
<dirbaio[m]>
implement the `core::fmt::Write` trait for your thing
<dirbaio[m]>
then you can `write!(&mut thing, "lol {} {:?}", 42, some_struct);`
<dirbaio[m]>
it'll do the formatting and write the results to the thing
<dirbaio[m]>
depending on what you want to do, there's things that already implement Write out there so you don't have to make your own. heapless::String for example, if you want to format to a string to do something with the string afterwards.
<kit[m]>
okay, which I think is the thrust of the stackoverflow answer I was pointing to there