<cr1901>
Yuhan Lin: Btw, the macro names are fine, go ahead and add the tests.
<cr1901>
But I'm gonna look at it more after I wake up
bpye has quit [Ping timeout: 260 seconds]
bpye8 has joined #rust-embedded
<re_irc>
<TimSmall> Any thoughts on when would be a good time to switch a library crate to 2021 edition? I assume that is going to effectively mandate >= v1.56, so it would make sense already if it used some feature which required 1.56 or newer anyway, but otherwise it would be best to leave it at edition 2018 (if not too onerous). Does that sounds reasonable?
<re_irc>
<xiretza> sure, 2021 edition is basically just like any other language feature - if you need it, you need to bump the MSRV, if you want to support older rustc, you can't use it.
Guest2 has joined #rust-embedded
<re_irc>
<ryan-summers> Unless you have a specific reason to lock yourself to a particular Rust release, I would say most users are fine with upgrading their Rust version - the only use case I see for version pinning is if you have to formally validate Rust
<re_irc>
<ryan-summers> E.g. in safety critical systems to conform with standards etc. where the validation cost is significant
<re_irc>
<korken89> TimSmall: All libraries I maintain have the guarantee "latest stable"
<re_irc>
<korken89> I don't want the burden to figure out which compiler version to fix for
<re_irc>
<TimSmall> Thanks everyone for thoughts on this. I'm thinking that since the 2018 to 2021 edition change is a one-liner, I'll leave it at 2018 for the time being, and just say it's tested on the latest version (it's a pretty simple library to read a temperature+humidity sensor), and may work on older versions.
<re_irc>
<Sergio Gasquez> 3
Guest2 has quit [Ping timeout: 256 seconds]
Guest2 has joined #rust-embedded
<re_irc>
<Eivind Bergem> I've been playing around with "usbd-serial" and encountered some issues. Looking at github, it appears that both "usb-device" and "usbd-serial" haven't seen any activity for a while. I just wanted to write a small example for a no_std readline library I'm working on, so I was hoping for something that just worked out-of-the-box. Are there any other efforts besides "usb-device" to bring USB support to embedded Rust...
<re_irc>
... in the works?
<re_irc>
<ryan-summers> usb-device and usbd-serial work quite well and I use them regularly
<re_irc>
<ryan-summers> There are a few issues at times, but I'd still say they're the best options
<re_irc>
<ryan-summers> Although I agree that there hasn't been much activity in the repos for a while. That's a comment for Lumpio− in regards to maintenance
<re_irc>
<ryan-summers> FYI - would be open to moving crates to the R-E-C if there's limited bandwidth to maintain
<re_irc>
<ryan-summers> But also, feel free to throw your issues here and we can see if we can help
<re_irc>
<ryan-summers> I just recently had to fix some enumeration issues on Windows
<re_irc>
<Eivind Bergem> My problem is that writing to a serial device before reading – this only happens for the first write after connecting a terminal – results in garbage in the following read. I'm willing to try to debug and contribute a fix, but I got a little discouraged seeing unmerged PR's from last year.
<re_irc>
<ryan-summers> The owner of those crates is active here, so I'm sure we can get it resolved if you have a fix to contribute :)
<re_irc>
<Eivind Bergem> That's great! I guess I'll start debugging then :) On that note, in gdb I find that most variables are "<optimized out>" for my embedded Rust code. I found an outstanding issue in "rustc", but it was stalled due to some LLVM issues. Do you know of any workarounds, or do I have to make do with print-debugging?
<re_irc>
<ryan-summers> Usually if you're hitting that, the best bet is to ramp down optimization settings IME
<re_irc>
<ryan-summers> Although usb-device and usbd-serial can be problematic when optimization is ramped down. Personally, in the past, I've used RTT-logging to debug USB issues
<re_irc>
<ryan-summers> Since RTT gives you the throughput and responsiveness necessary to continue supporting the USB stack
<re_irc>
<allexoll> Does anybody have pointers on how to track down where core::fmt is used from? it's eating about 15-20% of my flash and i'm unsure where it comes from.
<re_irc>
<ryan-summers> I think the current wisdom is that core::fmt bloat comes from panic handling, and you need to use panic-immediate-abort to get rid of it
<re_irc>
<ryan-summers> If you're using serde-json etc. then obviously you'll likely have some string format bloat from the serialization tools as well.
<re_irc>
<adamgreig> you might also need -Zbuild-std to rebuild core to remove panics from core, too
<re_irc>
<adamgreig> bear in mind even indexing an array can lead to a panic being included in the code if the compiler can't prove it won't always succeed
<re_irc>
<Eivind Bergem> ryan-summers: Switched from 'z' to 's' and now I get a lot fewer "<optimized out>". Thanks!
<Lumpio->
tbh I just want to rewrite usb-device once we have async
<Lumpio->
But at any rate if you have issues we're glad to help out to debug them - there's a Matrix room at #usb-rs:matrix.org for USB related stuff
<Lumpio->
But yeah I won't deny I personally got a bit tired of maintaining these crates, since they need a rewrite/redesign, fwiw they were my first real Rust project and I know a lot more nowadays
starblue1 has quit [Ping timeout: 250 seconds]
starblue1 has joined #rust-embedded
sheb_ has quit [Quit: Leaving]
<re_irc>
<disasm> Eivind Bergem: It could also be a bug in one of the driver crates and I'm one of the authors of these. I'd recommend joining the USB chat room and working on an example to reproduce the issue.
<re_irc>
<disasm> Heh, I should write a manual on USB debugging. Too bad I hate writing texts in non-Rust languages.
<re_irc>
<luojia65> Can anyone review this pull request? :))
<re_irc>
<disasm> luojia65: LGTM, although I can't approve from my phone. Clippy should highlight all the missing places if I recall correctly.
<re_irc>
<disasm> Also changelog entry is missing :)
Guest2 has quit [Quit: Client closed]
Guest2 has joined #rust-embedded
Guest2 has quit [Quit: Client closed]
cr1901 has quit [Remote host closed the connection]
cr1901 has joined #rust-embedded
cr1901 has quit [Remote host closed the connection]
cr1901 has joined #rust-embedded
cr1901 has quit [Remote host closed the connection]
cr1901 has joined #rust-embedded
<re_irc>
<adamgreig> room meeting time again! agenda's https://hackmd.io/huGxzPaQSs-yM2GlC4rxEA, please add anything you have to announce or would like to discuss and we'll start in 5 min :)
<re_irc>
<adamgreig> ok, let's start! not too much new from last week I don't think...
<re_irc>
<adamgreig> mostly of interest to HAL authors I expect
<re_irc>
<adamgreig> and cortex-m-rt added naked to the list of acceptable attributes for pre_init; hopefully (constrained) naked functions will be stabilised sometime soon which will make pre_init a fair bit more useful
<re_irc>
<adamgreig> no update on a cortex-m alpha or use of critical-section
<re_irc>
<adamgreig> we discussed reorganising the awesome-embedded-rust list a little last week, there's an open issue to track it https://github.com/rust-embedded/awesome-embedded-rust/issues/367 if anyone's interested in taking a shot, otherwise we'll get to it eventually 😅
<re_irc>
<adamgreig> and there's also a proposal for updating the svd2rust API for accessing registers that are in an array which might be of some interest, https://github.com/rust-embedded/svd2rust/issues/578
<re_irc>
<therealprof> I've been pinged about that but didn't have time to review.
<re_irc>
<adamgreig> the concept seems good but I haven't looked over the implementation pr yet
<re_irc>
<adamgreig> finally async digital::wait was merged into embedded-hal, but no progress on the managedcs/spi device traits stuff afaik
<re_irc>
<adamgreig> that's all I had on the agenda, happy to discuss any of those or any of the other embedded-hal stuff that's open
<re_irc>
<therealprof> I've seen some discussion about fugit wandering by. Anyone would like to provide an update?
<re_irc>
<adamgreig> for anything in particular? i think at the moment it's basically seeing adoption by various HALs and end-user projects, but so far hasn't needed to interact with anything in rust-embedded afaik
<re_irc>
<adamgreig> it might turn out to be a nice solution for embedded-hal time uses, or it might be that we abstract over something fugit-shaped in it, I guess
<re_irc>
<adamgreig> (personally I have found it very pleasant to use in some application code too)
<re_irc>
<therealprof> Yeah, I've seen some discussion in the context of e-h in my mailbox...
<re_irc>
<adamgreig> I guess that's less specifically for fugit and more generally about what bounds e-h puts on the Time traits, it might become irrelevant if https://github.com/rust-embedded/embedded-hal/pull/324 is merged
<re_irc>
<eldruin> yeah indeed
<re_irc>
<eldruin> I think the e-h pwm traits have seem some recent hal adoption
<re_irc>
<eldruin> but I think 324 is the better way for now
<re_irc>
<sh3rm4n> It seems to me, that unconstrained associated types are a problem in general for e-h, when one implementation should be used for applications, hal and driver crates 🤔
<re_irc>
<eldruin> exactly
<re_irc>
<therealprof> Agreed.
<re_irc>
<eldruin> let's merge 324 then if it is technically fine then if ryankurte also gives his ok
<re_irc>
<therealprof> eldruin: It sounded like you had objections?
<re_irc>
<sh3rm4n> I'd say let's follow through with #324 remove all type related traits and look for other instances of unconstrained types.
<re_irc>
Maybe it might be useful to introduce a embedded-time-with-fugit-hal crate, which is independet from the embedded-hal crate itself. This might prove that fugit design holds up for the usecase of e-h (I have not looked into it, so I have no idea.)
<re_irc>
<eldruin> I have to check. IIRC I thought removing so much functionality is worrisome but it seems HALs will rather support 0.2 and 1.x for a while, and then we can remove them and add them once we figure something out
<re_irc>
<burrbull> sh3rm4n: See fugit-timer
<re_irc>
<burrbull> Could we calculate dependets which use those traits?
<re_irc>
<eldruin> I think #324 adresses all of them, just the title has not been updated
<re_irc>
<eldruin> Somebody did that in the PR
<re_irc>
<burrbull> I mean drivers, not hals
<re_irc>
<eldruin> ah, yeah we could check on that as well
<re_irc>
<sh3rm4n> So as the source graph queries for drivers time out, I guess no driver is using these traits 😂
<re_irc>
<burrbull> I think it's because we declare time (frequency) types in the hals before. So drivers could not use them properly.
<re_irc>
<adamgreig> I guess worst case at least they could be added back as-is in 1.1 if it really turns out they were useful and important
<re_irc>
<adamgreig> but it does seem like we could hopefully come up with something more useful
<re_irc>
<adamgreig> anything else in e-h we should look at now?
<re_irc>
<eldruin> not from my side
<re_irc>
<burrbull> maybe new alpha?
<re_irc>
<adamgreig> oh, perhaps also new 0.2 to release the backported CAN traits?
<re_irc>
<eldruin> yeah we can make a new alpha release, there have been some changes
<re_irc>
<eldruin> adamgreig: uh, thanks. yes we should do that
<re_irc>
<eldruin> I'll make a PR tomorrow
<re_irc>
<adamgreig> thanks!
<re_irc>
<adamgreig> hopefully then the hals can migrate from embedded-can
<re_irc>
<eldruin> yeah that would be good
<re_irc>
<ryankurte> probably worth sorting out matching l-e-h releases too, will try get to that today
<re_irc>
<eldruin> yeah we wanted to make one for alpha.6 haha
<re_irc>
<eldruin> maybe we can release alpha.7 tomorrow and then we only need to do one l-e-h release
<re_irc>
<ryankurte> better still i think to not leave folks on that behind so immediately
<re_irc>
<eldruin> did you have a chance to look into the spi error variants?
<re_irc>
<ryankurte> not past an unfruitful search for docs
<re_irc>
<eldruin> yeah the docs are pretty difficult to figure out
<re_irc>
<ryankurte> not sure it’s critical for now tho, can always improve the matching in later releases
<re_irc>
<eldruin> yeah, sure
<re_irc>
<eldruin> it's just the kind of thing that gets postponed and I thought when adding them would be a fitting time, but yeah
<re_irc>
<eldruin> actually it would be valuable feedback if we would find out that there is no way to map good error variants on l-e-h
<re_irc>
<eldruin> * l-e-h, only on MCU hals
<re_irc>
<eldruin> but I think some minimal mapping must be hiding there somewhere
<re_irc>
<ryankurte> it was super easy for I2C, much less obvious how it should work for serial or SPI. i think there's an open issue if anyone else has ideas