ChanServ changed the topic of #rust-embedded to: Welcome to the Rust Embedded IRC channel! Bridged to #rust-embedded:matrix.org and logged at https://libera.irclog.whitequark.org/rust-embedded, code of conduct at https://www.rust-lang.org/conduct.html
<re_irc> <@gorazdko:matrix.org> Hi, does anybody know if its possible to write unit tests within different modules inside a single crate?
<re_irc> There's no support for this according to https://github.com/knurling-rs/defmt/issues/607
<re_irc> How do you guys do it?
<re_irc> <@dirbaio:matrix.org> if you're OK with running them on the host instead of the target, separate crate
<re_irc> <@dirbaio:matrix.org> otherwise... I think it's not really possible, no
<re_irc> <@dirbaio:matrix.org> are you sure defmt doesn't allow it?
<re_irc> <@dirbaio:matrix.org> that PR seems to imply it does
<re_irc> <@dirbaio:matrix.org> have you tried? what error do you get?
<re_irc> <@gorazdko:matrix.org> That issue is just a proposal. I have to provide path to the module in cargo.toml. So everything else is ignored.
<re_irc> [lib]
<re_irc> harness = false
<re_irc> path = "src/lib/mod.rs"
<re_irc> <@dirbaio:matrix.org> ah!
<re_irc> <@dirbaio:matrix.org> then probably not, yes..
fabic has joined #rust-embedded
Foxyloxy has quit [Remote host closed the connection]
Foxyloxy has joined #rust-embedded
fabic has quit [Ping timeout: 248 seconds]
fabic has joined #rust-embedded
dc740 has quit [Remote host closed the connection]
starblue has quit [Ping timeout: 248 seconds]
starblue has joined #rust-embedded
lehmrob has joined #rust-embedded
lehmrob has quit [Ping timeout: 246 seconds]
cr1901_ has joined #rust-embedded
cr1901 has quit [Ping timeout: 246 seconds]
fabic has quit [Ping timeout: 255 seconds]
lehmrob has joined #rust-embedded
<re_irc> <@2:0x2c.org> would it make any sense to use embassy on a system with a RTOS?
<re_irc> <@chrysn:matrix.org> : I'd think so. I haven't managed _yet_, but that may be because my directions are split between that and building a simple executor from the signalling primitives which the RTOS I'm using ships.
<re_irc> <@lulf_:matrix.org> In the same way there is embassy executor-specific bits for std, arm, riscv etc., you probably need a similar shim for the RTOS. The HALs probably don't make sense assuming the RTOS has some special way to access peripherals.
<re_irc> <@lulf_:matrix.org> (or just implement std in the rtos :P)
<re_irc> <@chrysn:matrix.org> : I think that's no particularly desirable direction. It leads to std implementations that are vastly incomplete (like wasm32-unknown-unknown's), and often unsuitable for embedded systems (eg. using seconds-and-nanoseconds types for durations).
dc740 has joined #rust-embedded
Rahix has quit [Quit: ZNC - https://znc.in]
fabic has joined #rust-embedded
Rahix has joined #rust-embedded
fooker has quit [Quit: WeeChat 3.7.1]
fooker has joined #rust-embedded
starblue has quit [Ping timeout: 248 seconds]
starblue has joined #rust-embedded
rardiol has joined #rust-embedded
lehmrob has quit [Remote host closed the connection]
lehmrob has joined #rust-embedded
IlPalazzo-ojiisa has joined #rust-embedded
bjc` has joined #rust-embedded
bjc has quit [Ping timeout: 255 seconds]
<re_irc> <@andresv:matrix.org> question about smlang: https://github.com/korken89/smlang-rs/blob/master/examples/guard_custom_error.rs
<re_irc> I wanted to create a SM where there is an event like "PrepareFwUpdate" and in quard some hardware is prepared and a struct needed for FW updated is then passed to a state like "StateWaitImageData(FlashAccess)".
<re_irc> "guard" and "action" can take in data from an event and action itself cannot fail.
<re_irc> It seems it is impossible to do so, because guard cannot actually prepare this "FlashAccess" - well it can but it cannot give it to "action".
<re_irc> Maybe there is a different pattern to overcome this issue.
<re_irc> <@ryan-summers:matrix.org> I do all of my failable-actions in "guard", and make "action" empty
<re_irc> <@ryan-summers:matrix.org> It's an unfortunate reality, but it works well
<re_irc> <@ryan-summers:matrix.org> I think you can omit "action" entirely and just use "guard" as "fallible-action"
<re_irc> <@andresv:matrix.org> : so you are doing fallible stuff in a "guard" and add its result to "Context" as "Option<SomeFallibleThing>" or something and then in a state "StateUseThatFallibleThing" you just do
<re_irc> if let Some(thing) = self.my_fallible_thing {
<re_irc> thing.work();
<re_irc> }
<re_irc> <@ryan-summers:matrix.org> That's one way you could do it. I don't have the exact use case as you, so I don't actually construct an object to use later
lehmrob has quit [Ping timeout: 248 seconds]
lehmrob has joined #rust-embedded
lehmrob has quit [Ping timeout: 255 seconds]
dc740 has quit [Remote host closed the connection]
rardiol has quit [Ping timeout: 248 seconds]
rardiol has joined #rust-embedded
<re_irc> <@sourcebox:matrix.org> : Is it possible to get support for ADC oversampling without too much hassle? I'm not sure if this is handled differently across the series, on L4 it's just a few bits to configure.
<re_irc> <@tmgross:matrix.org> Where would MDIO and/or MII traits go in embedded-hal? I brought up the idea here https://github.com/rust-embedded/embedded-hal/issues/425 but figure maybe I could get going on at least the MDIO traits
<re_irc> <@tmgross:matrix.org> Not sure whether a separate embedded-hal-net crate would be a good idea
<re_irc> <@tmgross:matrix.org> Or if MDIO would belong in embedded-hal-bus
dc740 has joined #rust-embedded
<re_irc> <@therealprof:matrix.org> : There's not really much to tratify in MII, it's simply a communication interface (available in different flavours for different speeds).
<re_irc> <@dirbaio:matrix.org> also what's the advantage of a "MII trait" vs an "Ethernet device trait" like what smoltcp has?
<re_irc> <@therealprof:matrix.org> We could indeed include MDIO but I think at the time when @mindtree brought that up, we weren't exactly convinced it was common enough to include in embedded-hal.
<re_irc> <@therealprof:matrix.org> : That was kind of what I was alluding, too. Since MII is really just a physical interface for Ethernet frames, it's not quite clear what the MII trait would abstract over.
<re_irc> <@therealprof:matrix.org> * alluding to.
rardiol has quit [Ping timeout: 248 seconds]
<re_irc> <@adamgreig:matrix.org> @room meeting time again! agenda is https://hackmd.io/hE7dX0pUSn-9JkEwDPwgtw, please add anything you'd like to announce or discuss and we'll kick off in about 5 min
<re_irc> <@adamgreig:matrix.org> ok, let's start! I don't have any big announcements but I believe rust 1.68 is out on thursday and will support stable on no_std :o
<re_irc> <@adamgreig:matrix.org> any other announcements?
<re_irc> <@newam:matrix.org> There's a "core::net" on nightly now: https://doc.rust-lang.org/nightly/core/net/index.html
<re_irc> <@jannic:matrix.org> stable alloc
<re_irc> <@therealprof:matrix.org> : Finally a way to make use of all the RAM. 😄
<re_irc> <@adamgreig:matrix.org> and indeed, already has a PR open to support embedded-alloc on 1.68 https://github.com/rust-embedded/embedded-alloc/pull/64
<re_irc> <@jannic:matrix.org> Yes, finally OOM on no_std!
<re_irc> <@romancardenas:matrix.org> Does that mean that no_std will now be able to use boxes etc?
<re_irc> <@adamgreig:matrix.org> it already can on nightly, but now you'll be able to on stable as well, yea
<re_irc> <@therealprof:matrix.org> : Yes.
<re_irc> <@romancardenas:matrix.org> Sound great!
<re_irc> <@adamgreig:matrix.org> you do need an allocator, and to use the "alloc" crate, so for many users they'll still want to be alloc-free
<re_irc> <@adamgreig:matrix.org> (i.e. with just no_std and core, you'll still not have Box or Vec, but it will become possible to use them with "alloc" on stable, which wasn't the case until now)
<re_irc> <@adamgreig:matrix.org> since is here, shall we jump to the instra topic on the agenda? , wanna go through your points?
<re_irc> <@nastevens:matrix.org> Sure thing. I mainly wanted to apologize for my absence and see if there was anything pressing that anyone needed from the infrastructure.
lehmrob has joined #rust-embedded
<re_irc> <@nastevens:matrix.org> And the other topic from a few weeks back was if we want to spread out the bus factor for infrastructure - currently it is just me and
<re_irc> <@adamgreig:matrix.org> the main upcoming thing is a desire to change the main landing page (rust-embedded.org) to either be, or redirect to, showcase.rust-embedded.org (which we'll update to make a more appropriate landing page)
<re_irc> <@adamgreig:matrix.org> in principle updating the team mailing lists is probably wise but in practice I don't think they really get any use, and I don't know if it's still possible/worth the effort to get them hosted by rust-lang
<re_irc> <@adamgreig:matrix.org> does ryan have the same access as you, for things like domain renewals etc?
<re_irc> <@nastevens:matrix.org> He has everything except billing access since that would give him access to my credit card info. But he could transfer the domain to a different registrar if it came to that.
<re_irc> <@adamgreig:matrix.org> ah cool, yea that would do if it came to it
<re_irc> <@adamgreig:matrix.org> I'm happy enough to have two people with access, and we very very rarely need to make any changes anyway, so maybe it's OK as-is? I also wouldn't mind having one more person on the access list (and can volunteer for it if need be)
fabic has quit [Ping timeout: 252 seconds]
<re_irc> <@adamgreig:matrix.org> since the concept of changing the home page redirect came up, I mainly wanted to make sure you were still around and able to do things if needed :P I guess it would still be good to get the infra repo PRs merged so its master branch reflects the latest deployed config
<re_irc> <@nastevens:matrix.org> Yup definitely can pick stuff up as needed. I agree on getting the PRs merged and will put that on my list.
<re_irc> <@nastevens:matrix.org> The change for the main page should be pretty straightforward too, so any time we're ready to do it I can take care of it
<re_irc> <@adamgreig:matrix.org> great, thanks!
<re_irc> <@nastevens:matrix.org> And unless someone wants it, I can get access to the AWS account
<re_irc> <@nastevens:matrix.org> I think you've proven yourself trustworthy 😉
<re_irc> <@adamgreig:matrix.org> cool, I guess that means if we do later find ourselves updating the team mailing lists more frequently at least I can take care of it
<re_irc> <@adamgreig:matrix.org> anything else you wanted to talk about on infra?
<re_irc> <@nastevens:matrix.org> Nope. Always feel free to email or message me too when there's the need
<re_irc> <@adamgreig:matrix.org> got it, thanks!
<re_irc> <@adamgreig:matrix.org> my normal email address is my aws one, btw
<re_irc> <@adamgreig:matrix.org> OK, moving on to resources, has a PR up with some proposed updates to the showcase to make it more suitable for a homepage, https://github.com/rust-embedded/showcase/pull/33
<re_irc> <@adamgreig:matrix.org> feedback very welcome! and start thinking about what projects you might submit to the showcase too
<re_irc> <@adamgreig:matrix.org> I don't think he's around atm though so let's move on to embedded HAL; last week we merged the defmt support for nb, do you reckon go ahead with a 1.1 (1.0.1?) release?
<re_irc> <@dirbaio:matrix.org> sure
<re_irc> <@eldruin:matrix.org> I'm around but there is not much to add
<re_irc> <@eldruin:matrix.org> let's do 1.1
<re_irc> <@dirbaio:matrix.org> opening PR now
<re_irc> <@eldruin:matrix.org> I wanted to do some cleanup before the release, that's why I haven't moved forward there
<re_irc> <@therealprof:matrix.org> 1.1?
<re_irc> <@adamgreig:matrix.org> "nb" v1.1
<re_irc> <@therealprof:matrix.org> Phew... I thought I missed something exciting. 😄
<re_irc> <@dirbaio:matrix.org> is this still needed nowadays? https://github.com/rust-embedded/nb/blob/master/src/lib.rs#L191
<re_irc> <@eldruin:matrix.org> It is a non-default feature but it is a bit weird to add it, including a new unstable dependency in a patch release
lehmrob has quit [Quit: Konversation terminated!]
<re_irc> <@dirbaio:matrix.org> or shall I remove it?
<re_irc> <@eldruin:matrix.org> no, please remove it
<re_irc> <@eldruin:matrix.org> also the remark in the cargo.toml
<re_irc> <@eldruin:matrix.org> thanks!
<re_irc> <@dirbaio:matrix.org> yepyep
<re_irc> <@adamgreig:matrix.org> yea, it used to be a thing but now docs.rs always sets --extern-html-root-url which always overrides anything you set anyway
<re_irc> <@adamgreig:matrix.org> (and for local builds it's also fine by default now...)
<re_irc> <@dirbaio:matrix.org> https://github.com/rust-embedded/nb/pull/40
rardiol has joined #rust-embedded
<re_irc> <@adamgreig:matrix.org> cool! anything else from embedded-hal?
<re_irc> <@eldruin:matrix.org> : will review, merge and release tomorrow
<re_irc> <@dirbaio:matrix.org> it's 5 lines 😅
<re_irc> <@therealprof:matrix.org> : Wrong year.
<re_irc> <@dirbaio:matrix.org> : omg, thanks
<re_irc> <@therealprof:matrix.org> The things that can go wrong in 5 lines. 😉
<re_irc> <@dirbaio:matrix.org> that's what I get for speaking 🙊
<re_irc> <@adamgreig:matrix.org> hah, wow
<re_irc> <@dirbaio:matrix.org> fixed
<re_irc> <@therealprof:matrix.org> Merged.
<re_irc> Caused by:
<re_irc> <@dirbaio:matrix.org> error: failed to publish to registry at https://crates.io
<re_irc> the remote server responded with an error: invalid upload request: invalid value: string "defmt-0.3", expected a valid feature name containing only letters, numbers, '-', '+', or '_' at line 1 column 182
<re_irc> <@dirbaio:matrix.org> RIP
<re_irc> <@adamgreig:matrix.org> "Feature names may include characters from the Unicode XID standard (which includes most letters), and additionally allows starting with _ or digits 0 through 9, and after the first character may also contain -, +, or .."
<re_irc> <@adamgreig:matrix.org> "Note: crates.io imposes additional constraints on feature name syntax that they must only be ASCII alphanumeric characters or _, -, or +."
<re_irc> <@eldruin:matrix.org> I wondered if the name was fine but supposed I was out of date
<re_irc> <@adamgreig:matrix.org> it _is_ fine for cargo. but not for crates.io???
<re_irc> <@dirbaio:matrix.org> yeah, wtf
<re_irc> <@thejpster:matrix.org> I wish dry-run actually asked the server
<re_irc> <@eldruin:matrix.org> 0.3 is much better understandable than defmt-0-3
<re_irc> <@dirbaio:matrix.org> "defmt-03"? "defmt-0-3"? "defmt-0p3"? "defmt-0-dot-3"?
<re_irc> <@dirbaio:matrix.org> "defmt-zero-point-three"
<re_irc> <@newam:matrix.org> : I would choose the first, but all of them are readable IMO
<re_irc> <@jannic:matrix.org> Just base64 encode the feature name...
* re_irc @eldruin:matrix.org sorry, gotta go, thanks everybody!
<re_irc> <@adamgreig:matrix.org> i think defmt-0-3 is clearer vs a hypothetical v3.0
<re_irc> <@dirbaio:matrix.org> https://github.com/rust-embedded/nb/pull/41
<re_irc> <@adamgreig:matrix.org> 😅
<re_irc> <@adamgreig:matrix.org> that's it for the agenda I had, anything else anyone wants to discuss?
<re_irc> <@therealprof:matrix.org> E-h 1.0 when? (You got me all excited now!)
<re_irc> <@dirbaio:matrix.org> there's https://github.com/rust-embedded/embedded-hal/pull/432
<re_irc> <@dirbaio:matrix.org> was discussed last week, no one seems to have objections
<re_irc> <@dirbaio:matrix.org> just waiting for approvals
<re_irc> <@therealprof:matrix.org> Approved.
<re_irc> <@dirbaio:matrix.org> shall we wait for or merge? it's been there for almost 3months
<re_irc> <@therealprof:matrix.org> I've already merged it.
<re_irc> <@newam:matrix.org> The bors fuse has been lit, you have 1 minute to decide before CI completes
<re_irc> <@dirbaio:matrix.org> ah okay
<re_irc> <@dirbaio:matrix.org> and then
<re_irc> <@dirbaio:matrix.org> according to https://github.com/rust-embedded/embedded-hal/issues/177
<re_irc> <@dirbaio:matrix.org> the only other thing is the i2c bus/device split
<re_irc> <@dirbaio:matrix.org> weird error from bors https://github.com/rust-embedded/nb/pull/41
<re_irc> <@dirbaio:matrix.org> there's some dark force out there that doesn't want this "nb" release or something
<re_irc> <@adamgreig:matrix.org> I think the error is github saying bors can't merge its commit into master until clippy_check passes on it? idgi
<re_irc> <@adamgreig:matrix.org> probably just cross fingers and retry
<re_irc> <@dirbaio:matrix.org> : yes, though there were some discussions in here after I opened that
<re_irc> <@dirbaio:matrix.org> that suggested design improvements, and I haven't updated it
<re_irc> <@adamgreig:matrix.org> https://github.com/rust-embedded/embedded-hal/pull/430 is probably also ready for approval?
<re_irc> <@adamgreig:matrix.org> (pwm pin)
<re_irc> <@dirbaio:matrix.org> don't even remember what those were, will have to do some archeology
<re_irc> <@adamgreig:matrix.org> * duty cycle)
<re_irc> <@dirbaio:matrix.org> oh yeah PWM
<re_irc> <@therealprof:matrix.org> Can you fix the conflict?
<re_irc> <@dirbaio:matrix.org> done
<re_irc> <@adamgreig:matrix.org> cool, that's all for today then, thanks everyone!
<re_irc> <@adamgreig:matrix.org> hopefully nb 1.1 can be released soon :P
<re_irc> <@therealprof:matrix.org> Maybe wait for or for a final blessing.
<re_irc> <@dirbaio:matrix.org> okay, now bors HANGED on the nb PR
<re_irc> <@dirbaio:matrix.org> merge commit is green since 10min ago... and no merge
<re_irc> <@dirbaio:matrix.org> even bors is telling us to deprecate "nb" and tell people to use "async" :P
<re_irc> <@adamgreig:matrix.org> oh, advance notice that I won't be able to run the meetings on 11/18/25th April, if is able then maybe he can do some, otherwise you'll have to talk among yourselves :P
<re_irc> <@adamgreig:matrix.org> as i will be in utc+8 🛫
<re_irc> <@adamgreig:matrix.org> aww, so I'll be away for the release of 1.69 on 4/20 lol
<re_irc> <@sourcebox:matrix.org> So now time for real discussion? 😃
<re_irc> <@dirbaio:matrix.org> https://app.bors.tech/repositories/41636
<re_irc> <@dirbaio:matrix.org> Batch 306623 Waiting to run
<re_irc> <@dirbaio:matrix.org> 🤷
<re_irc> <@therealprof:matrix.org> : Bring it.
<re_irc> <@dirbaio:matrix.org> and I don't have permissions to force-merge, or temporarily remove the branch protection or anything
<re_irc> <@sourcebox:matrix.org> Someone drafted this: https://github.com/rust-embedded/embedded-hal/pull/436
<re_irc> <@sourcebox:matrix.org> So basically the need to read and write pins simultaneously is something that is required by others then me.
<re_irc> <@therealprof:matrix.org> : Same. The usual pecularities of bors...
<re_irc> <@dirbaio:matrix.org> computer says no "nb" release
<re_irc> <@sourcebox:matrix.org> : That's the AI they installed in the last days.
bjc` is now known as bjc
<re_irc> <@newam:matrix.org> Maybe it's just trying to "WouldBlock"
<re_irc> <@sourcebox:matrix.org> "WoodBlock"
<re_irc> <@sourcebox:matrix.org> Similar to embedded-hal, what prevents cortex-m to have a 1.0 release?
<re_irc> <@sourcebox:matrix.org> I'm a bit confused what's going on with this crate because crates.io lists a 0.7.7 release, but the master on GitHub shows 0.7.4 in Cargo.toml. And there has been this inline-asm feature that isn't available on master anymore.
<re_irc> <@dirbaio:matrix.org> releases come from the 0.7.x branch
<re_irc> <@sourcebox:matrix.org> Wasn't it also the case that the crate can only be used once in a project because of the linker symbols exposed?
<re_irc> <@dirbaio:matrix.org> master already has breaking changes, so it'll be released as 0.8. it hasn't been updated in Cargo.toml yet
<re_irc> <@dirbaio:matrix.org> : that's cortex-m-rt
<re_irc> <@sourcebox:matrix.org> Ok, that's good to know.
<re_irc> <@dirbaio:matrix.org> I think you can mix cortex-m versions
<re_irc> <@dirbaio:matrix.org> ah, no, it has this sabotage, like the PACs https://github.com/rust-embedded/cortex-m/blob/v0.7.x/src/peripheral/mod.rs#L156-L159
<re_irc> <@sourcebox:matrix.org> One of the reasons I did not publish my cortex-m-systick crate on crates.io is to avoid any possible breakage with upcoming versions.
<re_irc> <@sourcebox:matrix.org> Other than the fact that I'm generally not satisfied with having that crate itself because I see it living somewhat in the desert.
<re_irc> <@9names:matrix.org> Slept right through the meeting 😴
<re_irc> Wanted to announce that Noxime and I have blinky firmwares running on rv32e with a custom rustc built with the not-yet-upstream LLVM patches.
<re_irc> His is more interesting as it's targetting ch32v003 - mine is the LP core on bl808. Will be interesting to see what we can squeeze into 2KB RAM and 16KB flash.
<re_irc> <@sourcebox:matrix.org> That's nice to hear. I had a brief chat with Noxime on Discord about that.
<re_irc> <@sourcebox:matrix.org> : Do you work on the Ox64 board?
<re_irc> <@9names:matrix.org> Don't know what you mean. I have an Ox64, I use it for my tests. I have mostly worked on scraping register details out of their SDK.
<re_irc> <@sourcebox:matrix.org> Sorry, I meant if you used that board for your testing.
<re_irc> <@sourcebox:matrix.org> I'm generally interested in that board because of the vector unit on the 64-bit core. Question is more what has still to be done to make it work effectively.
<re_irc> <@9names:matrix.org> It's a pre-1.0 vector extension, you'll need to roll your own intrinsics or build your algo in C/ASM with the t-head toolchain and custom extension flags
<re_irc> <@sourcebox:matrix.org> In other words a good amount of work.
<re_irc> <@9names:matrix.org> Everything is a lot of work. Sometimes you just forgot you're standing on someone else's shoulders
<re_irc> <@sourcebox:matrix.org> That's true. Maybe it will get easier with portable simd in the future.
IlPalazzo-ojiisa has quit [Remote host closed the connection]
rardiol has quit [Quit: https://quassel-irc.org - Chat comfortably. Anywhere.]
<re_irc> <@firefrommoonlight:matrix.org> : https://0ver.org/