<re_irc>
<@firefrommoonlight:matrix.org> You need to configure the interrupt etc in the RTC periph, unmask and maybe set NVIC priority, and clear the interrupt flag in the ISR as jam said
tokomak has joined #rust-embedded
derefnull has joined #rust-embedded
starblue has quit [Ping timeout: 256 seconds]
starblue has joined #rust-embedded
fabic has joined #rust-embedded
fabic has quit [Remote host closed the connection]
fabic has joined #rust-embedded
PyroPeter has quit [Ping timeout: 260 seconds]
Foxyloxy has quit [*.net *.split]
Foxyloxy has joined #rust-embedded
PyroPeter has joined #rust-embedded
emerent has quit [Read error: Connection reset by peer]
<re_irc>
<@luojia65:matrix.org> We are working on embedded Rust support for W806 chip, a general purpose microcontroller from Beijing Lianshengde Micro-electronics Ltd :)
cr1901 has joined #rust-embedded
cr1901 has quit [Quit: Leaving.]
<re_irc>
<@lachlansneff:matrix.org> adamgreig: You used jlcpcb for a 0.8mm pitch bga right?
<re_irc>
<@lachlansneff:matrix.org> What size vias did you use? 0.4mm?
troth has quit [Ping timeout: 250 seconds]
troth has joined #rust-embedded
<re_irc>
<@korken89:matrix.org> lachlansneff:matrix.org: I have done that, you can check out the project and setting here: https://github.com/korken89/ovio_core
<re_irc>
<@thejpster:matrix.org> Can I nominate you to add our collective thanks to that thread?
fabic has quit [Ping timeout: 240 seconds]
<re_irc>
<@lachlansneff:matrix.org> Is it terribly bad to run the output of one regular into the input of another one? I need both 12V and 5V regulated power, and it's easier for me to get a 12V to 5V regulator than a 24V to 5V one.
<re_irc>
<@lachlansneff:matrix.org> They're switching regulators, so efficiency is still pretty good
<re_irc>
<@jordens:matrix.org> Not bad at all. That's a common approach.
<re_irc>
<@lachlansneff:matrix.org> Ah, good to hear
<re_irc>
<@henrik_alser:matrix.org> Lachlan Sneff: As long as the first reg can handle the combined load you’re good
<re_irc>
<@therealprof:matrix.org> lachlansneff:matrix.org: It's even common to combine a switching regulator with a linear one to reduce ripple without totally killing efficiency.
troth has joined #rust-embedded
<re_irc>
<@ryan-summers:matrix.org> I found a bug in the STM32H7 ethernet registers, but I'm unsure where to apply the patch. https://github.com/stm32-rs/stm32-rs/tree/master/peripherals/eth seems to be a common tree for the ETH registers, but there's some registers in the MAC there that don't seem to be in the H7
<re_irc>
<@ryan-summers:matrix.org> cc adamgreig do you know where I should put the patch? Would it just go in `devices` somewhere?
<re_irc>
<@ryan-summers:matrix.org> Ah, it looks like the `device/<device>.yml` file points to the associated other YAML to pull in which points out where the other ETH patches are, think I've got this
<re_irc>
<@thezoq2:matrix.org> Is there any usb-pd support in some crate somewhere? For example to use the PD chip present in this https://github.com/Jana-Marie/OtterPill
<re_irc>
<@jamesmunns:matrix.org> thezoq2: I never wrote a driver for that, but I do have some of those boards :p
<re_irc>
<@jamesmunns:matrix.org> not sure if that helps, but if you need a second set of eyes, happy to chat
<re_irc>
<@jamesmunns:matrix.org> lachlansneff:matrix.org: It's also somewhat common to see LDOs chained to DC/DCs, with the DC/DCs doing the big stepdown (say 24v+ to 5V), and an LDO doing a smaller stepdown (say 5v to 3v3 or 1v8), especially when you need a "cleaner" rail.
<re_irc>
<@jamesmunns:matrix.org> But for 12 to 5, DC/DC is still probably the right answer
troth has quit [Ping timeout: 240 seconds]
<re_irc>
<@jamesmunns:matrix.org> unless you don't care about efficiency and heat
<re_irc>
<@lachlansneff:matrix.org> I don't really care about efficiency or heat that much tbh
<re_irc>
<@lachlansneff:matrix.org> We're already chaining 5V from the main board to 5V to 3.3V LDOs on the smaller boards actually
<re_irc>
<@jamesmunns:matrix.org> then it mostly comes down to size/cost I would think
<re_irc>
<@jamesmunns:matrix.org> but they make inductors and dc/dcs pretty small these days :D
troth has joined #rust-embedded
<re_irc>
<@jamesmunns:matrix.org> also probably depends on how much power you actually need
<re_irc>
<@lachlansneff:matrix.org> I found some murata DC-DCs that don't require a special pcb layout, so I'll probably go for those
<re_irc>
<@jamesmunns:matrix.org> less than 100mA it's probably "lmao whatever"
<re_irc>
<@lachlansneff:matrix.org> A couple of amps on the 12V rail and an amp or two on 5V
<re_irc>
<@ryan-summers:matrix.org> I've seen some DC/DCs that incorporate the inductor on top of the package to reduce size and complexity as well
<re_irc>
<@jamesmunns:matrix.org> ohhh, I've seen some of those lately, they're neat
<re_irc>
<@lachlansneff:matrix.org> Yeah, it's those
<re_irc>
<@jamesmunns:matrix.org> actually, I think Lachlan is the one that showed me those lol
<re_irc>
<@lachlansneff:matrix.org> Still expensive, but cost isn't a huge issue since we're only running a few of them
<re_irc>
<@ryan-summers:matrix.org> Might also be the same thing I'm thinking of :P
<re_irc>
<@lachlansneff:matrix.org> I think there are two types
<re_irc>
<@lachlansneff:matrix.org> There's the small ICs with the inductor in the package that go up to about 100mA and larger ones with the inductor on the package that look like they go up to 70W or so
<re_irc>
<@jamesmunns:matrix.org> You mentioned amplifiers, you might (note: I'm not an RF person) need to keep the power/noise isolated from your RF signals
<re_irc>
<@jamesmunns:matrix.org> like, I wouldn't want a big ringy DC/DC next to a PA/LNA
<re_irc>
<@lachlansneff:matrix.org> Yeah, they're on different boards
<re_irc>
<@lachlansneff:matrix.org> RF shielding is a good idea though
<re_irc>
<@jamesmunns:matrix.org> I have an LED under my DC/DC, and it lights itself with no power connected (just a few mm from the dc/dc)
<re_irc>
<@jamesmunns:matrix.org> :D
<re_irc>
<@jamesmunns:matrix.org> (very ghosty light, but still visible)
<re_irc>
<@lachlansneff:matrix.org> Wouldn't want an MCU near that haha
<re_irc>
<@bobmcwhirter:matrix.org> joule thief!
<re_irc>
<@jamesmunns:matrix.org> to be fair, it's basically sitting UNDER the inductor, and it's a stupid efficient white LED
<re_irc>
<@ryan-summers:matrix.org> Anything RF needs to be in some kind of shield with copper VIAs closing the faraday cage through the board and a solid ground underneath
<re_irc>
<@ryan-summers:matrix.org> Or be very careful. Source: Working on a wireless implant
<re_irc>
<@lachlansneff:matrix.org> There's no actual RF, just some LNAs
<re_irc>
<@jamesmunns:matrix.org> it's important to respect the "low noise" part of the LNA :D
<re_irc>
<@jamesmunns:matrix.org> otherwise you just amplify the noise :p
<re_irc>
<@jamesmunns:matrix.org> "huh, why do I have this weird 300khz ringing in my output?"
SomeWeirdAnon has joined #rust-embedded
<re_irc>
<@jamesmunns:matrix.org> (whatcha LNA'ing that's not RF?)
<re_irc>
<@lachlansneff:matrix.org> thermocouples
<re_irc>
<@lachlansneff:matrix.org> Though we're using off the shelf ICs that read them, so we don't have to worry a ton about it
<re_irc>
<@jamesmunns:matrix.org> gotcha
<re_irc>
<@jamesmunns:matrix.org> (I've only seen them in the context of integrated PA/LNAs for RF)
<re_irc>
<@jamesmunns:matrix.org> or I guess maybe standalone LNAs for GPS?
<re_irc>
<@jamesmunns:matrix.org> Anyway, super interested to see what you build :D
<re_irc>
<@lachlansneff:matrix.org> Me too!
<re_irc>
<@lachlansneff:matrix.org> I'm curious to see if it'll work
<re_irc>
<@lachlansneff:matrix.org> It's still the liquid rocketry stuff
<re_irc>
<@bobmcwhirter:matrix.org> is this for your rocketry?
<re_irc>
<@lachlansneff:matrix.org> Yeah, the rocketry club at PSU
<re_irc>
<@lachlansneff:matrix.org> I was working on an avionics package for model rockets before but it felt redundant to do that and do the avionics/electronics for a liquid rocket engine at the same time
<re_irc>
<@adamgreig:matrix.org> room hi all, meeting time again! agenda is https://hackmd.io/weeZMhFRRkaLaDvdovY1RQ, please add anything you'd like to discuss and we'll kick off in 5min
<re_irc>
<@lachlansneff:matrix.org> btw the links in the embedded-hal last week's minutes section are broken
<re_irc>
<@lachlansneff:matrix.org> Should be "pulls" not "pull"
<re_irc>
<@adamgreig:matrix.org> thanks
<re_irc>
<@lachlansneff:matrix.org> Actually, the pull thing is right, not sure why they're not working for me
<re_irc>
<@adamgreig:matrix.org> I think it's the colon
<re_irc>
<@adamgreig:matrix.org> there we go
<re_irc>
<@adamgreig:matrix.org> ok, let's get started!
<re_irc>
<@adamgreig:matrix.org> quite a few people volunteered to help out, but since then nothing happened on that front
<re_irc>
<@adamgreig:matrix.org> but it's been brought up again recently and lots of people really do want to see cross continue to be maintained and developed
<re_irc>
<@adamgreig:matrix.org> my proposal atm is we make a new org and move cross to it, out of the wg
<re_irc>
<@adamgreig:matrix.org> I don't think we've done this before but it seems like the tools team could probably vote to do so; currently it doesn't get very much attention at all from wg members, and it's no longer really used for embedded development as far as I know
<re_irc>
<@adamgreig:matrix.org> it seems very popular for cross compiling different linux/bsd/windows builds, with a lot of users using it for that
<re_irc>
<@therealprof:matrix.org> Hm, maybe we should have a chat with the Rust foundation.
<re_irc>
<@adamgreig:matrix.org> keeping it in the tools team hasn't worked so far, and making a new embedded wg team just for it seems a bit superfluous
<re_irc>
<@emilgardis:matrix.org> I would like to see cross still being under the rust-embedded umbrella, but supported by another org
<re_irc>
<@eldruin:matrix.org> I use it a lot to run tests from macos
<re_irc>
<@adamgreig:matrix.org> eldruin: as in, no_std embedded tests? in a linux x86_64 docker?
<re_irc>
<@emilgardis:matrix.org> I was hoping that with the announcement some team would notice and think/discuss about helping out
<re_irc>
<@adamgreig:matrix.org> emilgardis: how do you think that would look? a new github org that owns the repo, but wg members are owners of that org and owners on crates.io?
<re_irc>
<@adamgreig:matrix.org> or do you mean under the rust-lang umbrella rather than rust-embedded specifically?
<re_irc>
<@adamgreig:matrix.org> yes if one of the rust-lang teams popped up and offered to take it over that would have been neat but alas 😅
<re_irc>
<@adamgreig:matrix.org> emilgardis: what would be the purpose of keeping it under rust-embedded control?
<re_irc>
<@eldruin:matrix.org> adamgreig: tests with std for no_std drivers but on a linux x84_64 docker since I always add examples for a raspberry pi. anyway not meaning to distract
<re_irc>
<@adamgreig:matrix.org> I haven't really used cross at all so I am interested in hearing what embedded-related stuff people are using it for
<re_irc>
<@therealprof:matrix.org> adamgreig: Just making sure that the actual users don't feel blindsighted if we decide to hand over control.
<re_irc>
<@emilgardis:matrix.org> adamgreig: only reason for me is that we're already established, I don't want cross to get in a place where changes are done in non-accordance of what should probably be expected
<re_irc>
<@emilgardis:matrix.org> * one of the reasons
<re_irc>
<@adamgreig:matrix.org> yep, that's a fair reason
<re_irc>
<@richarddodd:matrix.org> I guess it's a lot of work to support? Having to spin up VMs to test things
<re_irc>
<@richarddodd:matrix.org> Is that why the maintenance burden is high?
<re_irc>
<@adamgreig:matrix.org> in practice I'd expect all the current maintainers/tools teams members (who want to) would become owners in the new org and so continue to be able to maintain
<re_irc>
<@adamgreig:matrix.org> the advantage would be that it's then also easy and practical to add new maintainers who can get on with writing and reviewing code
<re_irc>
<@adamgreig:matrix.org> and could more easily be granted publish access and so forth
<re_irc>
<@adamgreig:matrix.org> richarddodd: I think mostly it's just that not many people have much time, the CI mostly automates the VM part? I'm not entirely sure
<re_irc>
<@eldruin:matrix.org> we can also add people as maintainers of the repo without them being members of the org, though
<re_irc>
<@emilgardis:matrix.org> using the CI for testing is definitely what we have done
<re_irc>
<@adamgreig:matrix.org> yea, it is possible to add new maintainers to the current repo without needing a new org, for sure
<re_irc>
<@therealprof:matrix.org> eldruin:matrix.org: We've done that in the past on few occasions, but it's a bit of a pain...
<re_irc>
<@adamgreig:matrix.org> there are some questions about whether those maintainers are in any way "wg members" or should be, I guess
<re_irc>
<@emilgardis:matrix.org> I don't think they should be, but I can also see why they maybe should, depends on the approach
<re_irc>
<@thejpster:matrix.org> cross has 167 open issues and 29 open pull requests
<re_irc>
<@thejpster:matrix.org> So it certainly seems like it gets some attention
<re_irc>
<@adamgreig:matrix.org> so far inside the wg cross hasn't had a huge amount of maintainer time, and needing new maintainers to join a wg team to contribute seems a high burden for a crate that's not obviously embedded related, which is why I was considering a new org, but if it remains in some sense controlled by the wg then I don't know if it still makes sense
<re_irc>
<@adamgreig:matrix.org> but it is a pretty good argument that we don't want to just abandon all existing users by handing over to some new maintainers
<re_irc>
<@therealprof:matrix.org> thejpster:matrix.org: Absolutely, just not from the EWG. 😅
<re_irc>
<@thejpster:matrix.org> Fair. Can't say I've ever needed it. Or used it at all tbf.
<re_irc>
<@adamgreig:matrix.org> I guess we could a) new org, for now all the existing maintainers stay maintainers on the new org, but we add new maintainers from the volunteers, optionally with the org somehow staying under "wg control", whatever that means
<re_irc>
<@adamgreig:matrix.org> or b) keep repo as-is, but add a bunch of people as individual maintainers to that repo's settings, no new team or org
<re_irc>
<@adamgreig:matrix.org> there's also the issue of access to azure, dockerhub, and crates.io, but one way or another I think basically whoever's maintaining it needs to get that access
<re_irc>
<@emilgardis:matrix.org> I want to move over to GHA and GHCR, that would solve one issue
<re_irc>
<@emilgardis:matrix.org> did you get help with adding a real person to crates.io?
<re_irc>
<@adamgreig:matrix.org> I think it's a bit unfair to ask for new volunteers to do lots of writing code and reviewing and stuff but never plan to give them publish access or have them be some second tier of maintainer because they're not in the wg
<re_irc>
<@adamgreig:matrix.org> I've not had a response to my email yet
<re_irc>
<@therealprof:matrix.org> I think it's also used by the Rust project itself so I'd like to hear their opinion about it.
<re_irc>
<@richarddodd:matrix.org> You could let them do everything except rewriting history and publishing to crates io
<re_irc>
<@therealprof:matrix.org> Maybe the infra team would be interested or has an idea.
<re_irc>
<@richarddodd:matrix.org> I think that's actually quite a nice way to let 'untrusted' people run a repo
<re_irc>
<@emilgardis:matrix.org> infra has next meeting in a week, maybe just putting the question on zulip t-infra is a good start for that
<re_irc>
<@adamgreig:matrix.org> what would the question be, whether they're interested in taking over maintenance?
<re_irc>
<@thejpster:matrix.org> Or "we have a thing that's popular but no people to maintain it - do you have any suggestions?"
<re_irc>
<@therealprof:matrix.org> Yes, or have an idea with regards to creating a new team.
<re_irc>
<@thejpster:matrix.org> I like to avoid X/Y problems, in general
<re_irc>
<@adamgreig:matrix.org> sounds good, emilgardis would you be able to put the question on zulip?
<re_irc>
<@emilgardis:matrix.org> I can
<re_irc>
<@adamgreig:matrix.org> thanks!
<re_irc>
<@adamgreig:matrix.org> I will also advertise here that we made #cross-rs:matrix.org for cross maintenance/development discussions, to hopefully give current and new maintainers somewhere to plan out what to do
<re_irc>
<@adamgreig:matrix.org> ok, let's see if the infra team have any ideas and also wait for crates.io to get back to me about ownership of the crate, is there anything else cross-related that needs sorting out now?
<re_irc>
<@adamgreig:matrix.org> cool, thanks everyone, let's move on for now, any further thoughts welcome on the issue thread or in #cross-rs:matrix.org
<re_irc>
<@emilgardis:matrix.org> I think it's fine, but I also kinda like the idea of keeping the enum, but using `#[serde(untagged)]` been meaning to write on the issue but never got to it
<re_irc>
<@adamgreig:matrix.org> yea, I don't mind too much, `untagged` might be the best of both worlds basically
<re_irc>
<@adamgreig:matrix.org> but probably would look pretty similar to the struct approach after serde, maybe one is easier to write code for/match?
<re_irc>
<@adamgreig:matrix.org> I think it's ok to discuss on the issue thread there
<re_irc>
<@adamgreig:matrix.org> it sure removes a lot of traits 👀 but possibly is also a sign that these traits need some thought before 1.0 anyway, especially given our time issues with Delay?
<re_irc>
<@adamgreig:matrix.org> quiet on the HAL front today
<re_irc>
<@adamgreig:matrix.org> any other open HAL PRs someone would like to discuss?
<re_irc>
<@eldruin:matrix.org> `Time` is a difficult topic
<re_irc>
<@therealprof:matrix.org> No kidding. 😉
<re_irc>
<@eldruin:matrix.org> merging this might make the 1.0 version unattractive for a really long time
<re_irc>
<@eldruin:matrix.org> so I ask myself it it would be better to postpone to 2.0
<re_irc>
<@adamgreig:matrix.org> or, best case, leave a lot of people using both together, I guess
<re_irc>
<@adamgreig:matrix.org> and unlike Delay we probably can't afford to leave a very basic version in 1.0 and add a better version in 1.1?
<re_irc>
<@eldruin:matrix.org> I think the only alternative would be to remove them altogether
<re_irc>
<@adamgreig:matrix.org> I guess it depends how quickly we think we might solve all time issues forever
<re_irc>
<@eldruin:matrix.org> hmmm
<re_irc>
<@adamgreig:matrix.org> and then add the perfect Delay and also Capture, Pwm, Timer, Watchdog
<re_irc>
<@eldruin:matrix.org> we could split the traits into parts that need time and parts that do not
<re_irc>
<@eldruin:matrix.org> but sounds messy
<re_irc>
<@adamgreig:matrix.org> yea, and for many of them the time concepts are pretty key, right
<re_irc>
<@eldruin:matrix.org> yeah, agreed on the question being how long we think it is going to take
<re_irc>
<@eldruin:matrix.org> taking the past into account, pretty long
<re_irc>
<@eldruin:matrix.org> `fugit` seems promising though
<re_irc>
<@adamgreig:matrix.org> given the current setup requires some totally unbound Time trait, is anyone even using these for generic drivers?
<re_irc>
<@eldruin:matrix.org> I think some driver of mine might need delay
<re_irc>
<@burrbull:matrix.org> the problem of `fugit` it requires Timer frequency to be known at compile time as constant
<re_irc>
<@eldruin:matrix.org> but not `Time` stuff
<re_irc>
<@jacobrosenthal:matrix.org> delay gets borrowed on init to wait for devices to startup after reset
<re_irc>
<@jacobrosenthal:matrix.org> thats what I see most
<re_irc>
<@jacobrosenthal:matrix.org> (vs hardcoding asm where the driver cant know what the clock rate is)
<re_irc>
<@adamgreig:matrix.org> yea, certainly Delay is v common (but we already have the new basic DelayUs)
<re_irc>
<@adamgreig:matrix.org> but Capture, Pwm, Timer, Watchdog?
<re_irc>
<@eldruin:matrix.org> burrbull:matrix.org: ah, so changing a timer is not supported? or do you just destroy and recreate?
<re_irc>
<@eldruin:matrix.org> I wanted to implement `Pwm` and saw that I could not due to `Time` a long time ago.
<re_irc>
<@adamgreig:matrix.org> the Duration type's tick frequency is a const generic parameter
<re_irc>
<@adamgreig:matrix.org> so yea I guess it doesn't easily support dynamically changing clock frequencies without destroying the old duration objects
<re_irc>
<@adamgreig:matrix.org> eldruin:matrix.org: yea, I wonder if this is common and it's therefore not widely used, in which case removing them won't make 1.0 unattractive anyway
<re_irc>
<@adamgreig:matrix.org> but no drivers found
<re_irc>
<@eldruin:matrix.org> there is still the app users, for who the traits offer cross-hal consistency and may use the traits for function argument types and stuff like that
derefnull has left #rust-embedded [Leaving]
<re_irc>
<@adamgreig:matrix.org> true, we don't really see that code in searches
<re_irc>
<@eldruin:matrix.org> HALs could add the traits locally again though, but that leads to fragmentation quickly
<re_irc>
<@emilgardis:matrix.org> I have a point regarding asking infra about suggestions for cross, I don't think they might be the correct team to ask, done some digging, don't think they use cross. I can ask but feels wrong
<re_irc>
<@adamgreig:matrix.org> yea
<re_irc>
<@adamgreig:matrix.org> emilgardis:matrix.org: ah, thanks for checking! does anyone know which team does use cross? therealprof?
<re_irc>
<@adamgreig:matrix.org> ugh, I guess we could release 1.0 without these traits and add them back in 1.1 with either a good new Time type or just as they currently are if we can't think of anything better, but it kinda sucks
<re_irc>
<@thejpster:matrix.org> Sure - 1.0 simply says "we won't take these away from you without thinking about"
<re_irc>
<@thejpster:matrix.org> Adding new things is fine
<re_irc>
<@adamgreig:matrix.org> yea, but deleting a bunch of currently-used traits in 0.2 from 1.0 will still be annoying to people, at least HAL implementors
<re_irc>
<@eldruin:matrix.org> an argument might be that removing them and readding eventually would push 2.0 much further away into the future
agg has quit [*.net *.split]
Lumpio- has quit [*.net *.split]
<re_irc>
<@adamgreig:matrix.org> hopefully it's already far in the future :P
<re_irc>
<@burrbull:matrix.org> ideally never
<re_irc>
<@newam:matrix.org> eldruin:matrix.org: If we leave them as is we have fragmentation as people move to traits with more concrete time types (e.g. embedded-time), and if we remove them we have fragmentation from local implementations for things not covered by other traits (16-bit timers). I don't think there is a solution that doesn't result in a lot of fragmentation.
<re_irc>
<@thejpster:matrix.org> And if everyone comes on here and says "hey, I want these traits back for these reasons", we can get a 1.1 out of the door with all the extra help we have.
<re_irc>
<@adamgreig:matrix.org> heh, if we're lucky enough for them to find their way here to complain
<re_irc>
<@adamgreig:matrix.org> it would be interesting to see what happens without them, I guess
<re_irc>
<@adamgreig:matrix.org> it's easy enough to add them back, and it's very hard to take them out later
<re_irc>
<@thejpster:matrix.org> If a trait falls down in the woods, and nobody notices ... does it really matter what your project does?
<re_irc>
<@adamgreig:matrix.org> a wise old idiom indeed
<re_irc>
<@adamgreig:matrix.org> in any event we're out of time for this week, so I guess let's keep pondering what our ideal time trait/type might look like..
<re_irc>
<@adamgreig:matrix.org> thanks everyone for attending!
<re_irc>
<@emilgardis:matrix.org> there was a wg-governence where I feel like the question would fit the best, but it's been dispanded 😅
agg has joined #rust-embedded
<re_irc>
<@emilgardis:matrix.org> ill ask around
Lumpio- has joined #rust-embedded
<re_irc>
<@therealprof:matrix.org> adamgreig: I thought it was used by the main project but seems not (at least not obviously).
<re_irc>
<@svenstaro:matrix.org> emilgardis and adamgreig so the cross thing is rolling but is blocked on the rust infra team answering at this point?
<re_irc>
<@emilgardis:matrix.org> no, not blocked. We have an idea of what to do, but it needs to go through a vote in the end. I've been having more time (and motivation 😅) to do some reviewing, so if you need something, just ping me in github or on the new #cross-rs:matrix.org room
SomeWeirdAnon has quit []
emerent_ has joined #rust-embedded
emerent has quit [Killed (erbium.libera.chat (Nickname regained by services))]
emerent_ is now known as emerent
cr1901 has joined #rust-embedded
<cr1901>
agg: Whoops, looks like I forgot to send a msg before I left this morning. I had a prior engagement so couldn't attend the meeting. I imagine I was sorely missed :)