<re_irc>
<swedishhat> Is that jack line out or line in? If it's meant for audio out, it looks like you could pwm GP18 and GP19 to put "simulated" sine waves on those pins
<re_irc>
<matejcik> some time ago sometime here talked about running nightly cargo with stable rustc (in order to get "-Z build-std=core")
<re_irc>
i tried it back then and it seemed to work ... but now I can't do it anymore? rustc complains that "-Z unstable-options" is only accepted by the nightly compiler. Any idea why cargo would pass that option? I didn't specify it, my invocation is this:
<re_irc>
<matejcik> (i'm on nixos with rust overlay, so maybe that could have something to do with it?)
<re_irc>
<matejcik> the "-Z unstable-options" is there because cargo adds "--outdir" to build options when I enable "-Z build-std=core". it goes away if I don't specify build-std=core. even with nightly cargo.
<re_irc>
<matejcik> ~~the "-Z unstable-options" is there because cargo adds "--outdir" to build options when I enable "-Z build-std=core". it goes away if I don't specify build-std=core. even with nightly cargo.~~
<re_irc>
scratch that it's not --outdir, that is there anyway and works fine without unstable-options
<re_irc>
<matejcik> scratch that it's not --outdir, that is there anyway and works fine without unstable-options
<re_irc>
<matejcik> it seems that it's because build-std=core inserts a "noprelude" link. which is unstable.
<re_irc>
now i'm wondering whether this ever worked.
starblue has quit [Ping timeout: 248 seconds]
starblue has joined #rust-embedded
explore has quit [Quit: Connection closed for inactivity]
<re_irc>
<adamgreig> sorry, just dealing with some spam in another channel, one sec...
<re_irc>
<adamgreig> ok, let's start!
<re_irc>
<adamgreig> announcements first; critical-section 1.0 is released as part of the wg HAL team 🎉 and cortex-m 0.7.6 is also released adding a critical-section implementation (though its interrupt::free is the same as before to avoid breaking)
<re_irc>
<adamgreig> I haven't had much time to go through emails from the week but I think that's it for announcements, did anyone have anything else?
<re_irc>
<James Munns> If anyone is starting a commercial rust project, I'd love to chat with you about mnemOS :)
<re_irc>
<James Munns> (tl;dr: looking for a company as an early adopter to sponsor dev, and work on it along side a commercial project, instead of developing in a vacuum)
<re_irc>
<James Munns> * dev and/or contract me to work on OS + the actual project),
<re_irc>
<James Munns> (end hashtag ad)
<re_irc>
<adamgreig> 👍️
<re_irc>
<adamgreig> cool, anything for embedded HAL this week?
<re_irc>
<adamgreig> the new i2c PR and the split nb PR are still drafts, but it looks like dirbaio isn't around atm to discuss them, don't think there's been particular updates since last week anyway?
<re_irc>
<therealprof> I think there was a bit of discussion but I didn't watch too closely (sorry).
<re_irc>
<eldruin> not from my side. I adapted an spi driver to the new SpiDevice interface and it went very smoothly. the hal impl part was merged into stm32f4xx-hal.
<re_irc>
<adamgreig> nice, I guess hopefully push forward on those two and then we're very close to e-h 1.0
<re_irc>
<eldruin> we can bikeshed a name for the crate where ExclusiveDevice could go
<re_irc>
<eldruin> and/or think about what could go in there
<re_irc>
<adamgreig> so there's ExclusiveDevice, either blocking or blocking+async versions, there's maybe RefCell based bus sharing...
<re_irc>
<adamgreig> I'm not sure what the mutex/cs it refers to is, like a mutex-based bus sharing?
<re_irc>
<eldruin> yes
<re_irc>
<adamgreig> in chibios for example it has an optional mutex you can acquire to share the bus, but it has pre-empted multithreading so you don't necessarily deadlock
<re_irc>
<adamgreig> and then maybe it could contain some adapters for e.g. async to blocking or something?
<re_irc>
<eldruin> maybe, yes
<re_irc>
<adamgreig> I guess they don't all need to live in the same crate, though
<re_irc>
<eldruin> it kind of becomes a big bag of stuff
<re_irc>
<eldruin> exactly
<re_irc>
<adamgreig> so could have embedded-hal-bus and embedded-hal-adaptors or something
<re_irc>
<eldruin> also possible
<re_irc>
<emilgardis> what would be the plan for hosting the source code for those crates, same workspace as e-h?
<re_irc>
<emilgardis> (I don't like how it ended up with svd2rust 😄)
<re_irc>
<eldruin> yeah I think we can keep it like e-h-async
<re_irc>
<emilgardis> * 😄, scattered repos)
<re_irc>
<adamgreig> yea, having it all in embedded-hal repo seems fine
<re_irc>
<eldruin> they are all quite related so I think it is easier that way
<re_irc>
<jannic> One small disadvantage would be that it becomes difficult to assign good git tags.
<re_irc>
<adamgreig> yea, we do have that issue a but in the cortex-m repo - it also makes the github releases a bit confusing
<re_irc>
<adamgreig> but on balance it doesn't seem too bad and definitely saves a lot of faff having a ton of repos
<re_irc>
<emilgardis> (not to mention desync issues)
<re_irc>
<adamgreig> I'd just keep the v1.0 tags for embedded-hal, then have prefixed tags like e-h-shared-1.0 or whatever for other crates
<re_irc>
<adamgreig> even if you just keep the github releases only for the main embedded-hal crate it still works fine
<re_irc>
<emilgardis> actually though, could go the way cargo, clippy etc has done it now, subtrees
<re_irc>
<eldruin> Ok I think I like having a e-h-bus crate for the exclusive device and refcell and whatever bus/device related and after that we can think of another crate for adaptors and whatever, but -bus would get us going
<re_irc>
<emilgardis> +(instead of submodules)
<re_irc>
<eldruin> adamgreig: yeah that is what I did for e-h-async
<re_irc>
<adamgreig> I haven't had a chance to look at the impl yet, sorry, will try and do later tonight
<re_irc>
<adamgreig> the other related point is if we cut a new bare-metal release that re-exports the c-s types and calls itself deprecated
<re_irc>
<adamgreig> I think "yes" but maybe we can do it in a few weeks once some things have swapped to using critical-section and we've had a better feel for it
<re_irc>
<adamgreig> I think that's about all I had then, anyone else have anything to discuss?
<cr1901>
I'm trying to convert msp430 to use critical_section today
<cr1901>
does that count as news?
<cr1901>
(Oh right, bridge still dead?)
<re_irc>
<adamgreig> ok, let's finish a bit early today then! thanks everyone 👋
<cr1901>
agg: Bridge still dead :(
<agg>
ugh :(((
<agg>
why does it still work for some users... i'm sort of out of good ideas to fix it
<agg>
(for everyone in matrix we're discussing how the bridge is half dead)
<agg>
I think I'll delete my homeserver entirely and restart it, it seems to be a homeserver problem
<cr1901>
I could come to Matrix for meetings, but I can't partition my bandwidth across multiple clients
<cr1901>
continuously* anyway
codes03 has joined #rust-embedded
<cr1901>
agg: While you're here... what was the rationale for not providing interrupt::free as a wrapper over critical_section::with?
<cr1901>
in the cortex-m crate*
<agg>
I just left to drive home actually but the idea is operating without interrupts is a thing someone might want to do separately to being in a critical section
<re_irc>
<dirbaio> 👋
* cr1901
nods
<re_irc>
<dirbaio> sorry had some unexpected issues and couldn't attend the meeting :|
<re_irc>
<dirbaio> but yeah, no updates from me on the i2c stuff
<re_irc>
<dirbaio> and on the "split nb" PR, is it just waiting on me to remove the "-can" crate, or was there stuff left to discuss?
<re_irc>
<dirbaio> * crate (so it can go back to its original repo),