<re_irc>
<thebutlah> how realistic is it to use embassy with the esp32c3? I don't see support for the esp32/c3 in embassy. Am I able to implement the necessary traits in a piecemeal fashion or will I need to implement the whole api first before I can do anything?
<re_irc>
Please note that my platform will not support std, only core and alloc.
<re_irc>
In other words, if I have peripherals from the esp-hal ecosystem, can I just take a particular peripheral and implement a trait from embassy on it, and then I get to use that peripheral with embassy? For example, serial.
crabbedhaloablut has quit [Ping timeout: 268 seconds]
crabbedhaloablut has joined #rust-embedded
cr1901 has quit [Ping timeout: 255 seconds]
cr1901 has joined #rust-embedded
crabbedhaloablut has quit [Remote host closed the connection]
crabbedhaloablut has joined #rust-embedded
dc740 has joined #rust-embedded
crabbedhaloablut has quit [Remote host closed the connection]
crabbedhaloablut has joined #rust-embedded
dc740 has quit [Ping timeout: 244 seconds]
dc740 has joined #rust-embedded
crabbedhaloablut has quit [Remote host closed the connection]
crabbedhaloablut has joined #rust-embedded
crabbedhaloablut has quit [Remote host closed the connection]
crabbedhaloablut has joined #rust-embedded
msh has quit [Ping timeout: 248 seconds]
bjc has joined #rust-embedded
dc740 has quit [Ping timeout: 268 seconds]
causal has quit [Quit: WeeChat 3.6]
brazuca has joined #rust-embedded
brazuca has quit [Ping timeout: 252 seconds]
dc740 has joined #rust-embedded
brazuca has joined #rust-embedded
Foxyloxy has quit [Remote host closed the connection]
Foxyloxy has joined #rust-embedded
dc740 has quit [Ping timeout: 252 seconds]
<re_irc>
<omar_u8> Im using GDB+OpenOCD+Cortex-Debug in my setup and it recently went out of whack after doing a VSCode update. GDB Server quitting unexpectedly. Anybody experiencing something similar?
<re_irc>
<ryan-summers> Would highly recommend getting away from OpenOCD and using probe-rs. I found it to be a lot more stable personally
<re_irc>
<omar_u8> ryan-summers: Is the debug extension available for VSCode?
<re_irc>
<omar_u8> ryan-summers: 😔 I guess I'll give it another shot. I recall I not being able to get the extension to work. I might have have to settle with basic command line for debig.
<re_irc>
<omar_u8> * debug.
<re_irc>
<ryan-summers> I use gdb command line a lot, but honestly, Rust generally saves me from writing most of the bugs I used to use GDB for
<re_irc>
<ryan-summers> I mainly use it for probing at register configs etc. set by HALs
<re_irc>
<ryan-summers> Not sure if the VScode extension helps w/ that yet
<re_irc>
<explodingwaffle101> omar_u8: fyi- it seems to work well for me once you get all the json files set up
<re_irc>
<explodingwaffle101> wrt registers- i use it for that all the time, v helpful (did you know that some peripherals can get side effects if you read out of their registers with a debugger? very fun)
<re_irc>
<omar_u8> explodingwaffle101: Wasnt aware of that, but good to know.
<re_irc>
<explodingwaffle101> haha yeah. i had a watcher on the data register of the rp2040's xip peripheral, which was reading out of the fifo whenever i hit a breakpoint. obviously not great (though i feel like that's sort of bad peripheral design? i don't know how debuggers work though)
<re_irc>
<James Munns> Is that different than general "side-effectful read" of peripheral IO?
<re_irc>
<James Munns> but yeah, the usual culprits for that are status flags ("clear on read"), and FIFOs ("pop on read"). Always Fun™️
<re_irc>
<explodingwaffle101> James Munns: it's not, but for some reason i guess i thought debug stuff had a way around that. guess life isn't so easy
bjc has quit [Remote host closed the connection]
<re_irc>
<adamgreig> hi room , meeting time again! agenda is https://hackmd.io/YiewxjLwSZ6QG0yvbP105w, please add anything you'd like to announce or discuss and we'll start in 5min :)
dc740 has joined #rust-embedded
<re_irc>
<adamgreig> ok, let's start! some announcements first...
<re_irc>
<adamgreig> critical-section 1.1 is out, with a built-in "std" impl but no other change
<re_irc>
<adamgreig> svd2rust 0.25.1 is out with a new option to expand cluster elements to fill each array slot, allowing arrays of clusters to be created without extra padding between them
<re_irc>
<adamgreig> and embedded-hal-bus 0.1.0-alpha.0 is out to test the new helper structs for embedded-hal 1.0
<re_irc>
<adamgreig> that's it for my announcements, anyone else have anything?
<cr1901>
agg: To relay to Matrix side
<agg>
cr1901: could you try changing your nick to like cr1901_ or something and see if it helps? not a long term solution but it might work
<cr1901>
critical-section caused some unexpected size bloat/breakage in msp430 land
cr1901 is now known as cr1901_
<cr1901_>
better?
<re_irc>
<adamgreig> yea, that worked!
<cr1901_>
let's not waste time on this, I just want to relay the important stuff
<cr1901_>
Ahhh okay excellent.
<re_irc>
<dkhayes117> There's the WG twitter account last Friday of the month project showcase. In case anyone missed it.
<cr1901_>
So news... critical-section caused some unexpected size bloat/breakage in msp430 land, and my attempts to add features to workaround the suboptimal codegen are also broken lol. I'm actively looking into it
<re_irc>
<adamgreig> cr1901_: what sort of problem?
<cr1901_>
Basically, if a critical_section:free() has a branch in it, rustc will generate LLVM to reenable interrupts on both sides of the branch rather than using a single interrupt enable sequence when the branches converge
<re_irc>
<adamgreig> wow, that's weird... and it didn't for the previous interrupt::free?
<cr1901_>
Yes, because interrupt::free was in the same crate without extern. It's very weird
<cr1901_>
Basically, 3 possible scenarios:
<cr1901_>
1. interrupt::free in same crate... no problem
<cr1901_>
2. interrupt::free in different crate, but imported with a use statement... bad codegen unless I use #[inline] or #[inline(always)]
<cr1901_>
3. interrupt::free in different crate with an extern- what critical-section does... bad codegen, and #[inline]/#[inline(always)] no effect
<cr1901_>
#[inline(never)] is honored, which is a workaround I'm using that... has broken AT2XT at the very least
<cr1901_>
I'm not sure what to do about this. I wonder if it's possible for ppl in Cortex-M land to verify that their critical-sections are being duplicated
<cr1901_>
err, sorry
<cr1901_>
their interrupt-enable snippets*
<cr1901_>
I can provide an MCVE and also try myself soon
<re_irc>
<newam> is this rustc generating bad IR or LLVM compiling poorly?
<cr1901_>
bad IR
<re_irc>
<eldruin> weekly meeting?
<cr1901_>
At the very least, the bad code shows up in the .ll file
<re_irc>
<adamgreig> I just did a quick check on cortex-m and it only includes the "cpsie i" once
<cr1901_>
Hmmm... interesting... adamgreig, mind putting up your code after the meeting so I can play w/ it?
<cr1901_>
Tyvm
<re_irc>
<adamgreig> #![no_std]
<re_irc>
#![no_main]
<re_irc>
use panic_halt as _;
<re_irc>
use stm32ral::{gpio, read_reg, write_reg};
<cr1901_>
Cool, I will see what I can do w/ that. Also to be explicit... "the critical section contains a branch" might be necessary but not sufficient.
<re_irc>
<adamgreig> ah yea indeed
<re_irc>
<adamgreig> might be worth trying to turn the msp430 failure case into a cortex m example and see how it copes there too then
<re_irc>
<eldruin> I adapted an i2c driver and linux-e-h to it and it worked well
<re_irc>
<adamgreig> it sounds like on the linux side the new api doesn't exactly fit with the kernel api very well?
<re_irc>
<adamgreig> maybe not a problem as such though
<re_irc>
<eldruin> yeah I added some notes about it there but it can be made to work and uphold the contract
<re_irc>
<eldruin> (which we currently do not at l-e-h)
<re_irc>
<eldruin> * l-e-h wrt restarts)
<re_irc>
<adamgreig> so overall you're happy with the new traits despite the slight mismatch with the linux api?
<re_irc>
<eldruin> yeah they seem fine
<re_irc>
<eldruin> I have not tested it in hardware yet, though
<re_irc>
<eldruin> not sure if any surprises would arise since we are not actually using i2c devices as provided by the kernel and we are using the bus directly
<re_irc>
<adamgreig> how does the kernel handle sharing the bus if you don't use its devices?
<re_irc>
<eldruin> even with devices I do not think it cares
<re_irc>
<eldruin> even if you have a device, you can change the address
<re_irc>
<adamgreig> does it do anything to stop concurrent accesses stepping on each other?
<re_irc>
<eldruin> there is a bit userspace/kernelspace interface there anyway and the kernel takes it from there
<re_irc>
<adamgreig> or once one process opens the bus can no one else access it?
<re_irc>
<eldruin> I do not know how it does it
<re_irc>
<eldruin> adamgreig: possible
<re_irc>
<eldruin> opening can fail, that would fit
<re_irc>
<eldruin> maybe with devices looser sharing is allowed but I do not know how it works
<re_irc>
<eldruin> It could be that the kernel just has its big internal queue and whatever userspace does is just filling it up
<re_irc>
<adamgreig> sounds like a recipe for concurrency disaster :P
<re_irc>
<adamgreig> anyway cool, thanks for testing it out!
<re_irc>
<adamgreig> for splitting "nb" and "can", I think the main remaining question was whether to have "embedded-can" as a separate repo or a folder in the "embedded-hal" repo, any thoughts?
<re_irc>
<eldruin> haha, like I said, it did not look under the hood, I am just guessing
<re_irc>
<eldruin> I think we discussed reviving the original repo and publishing a new version with the latest adaptions
<re_irc>
<eldruin> whether in a separate repo or inside embedded-hal, idk
<re_irc>
<adamgreig> we're reviving the original crate, but is there any point reviving the repo?
<re_irc>
<eldruin> issues?
<re_irc>
<eldruin> if there are none or if they are not interesting, I am fine with either
<re_irc>
<adamgreig> I think most of the relevant design discussion happened on embedded-hal in the end
<re_irc>
<eldruin> it would be fine with me to have an embedded-can subfolder with the crate
<re_irc>
<adamgreig> cool
<re_irc>
<adamgreig> anything else from embedded-hal?
<re_irc>
<eldruin> nothing from me
<re_irc>
<eldruin> ah, I also updated the migration guide and added some content, but I still need to add more
<re_irc>
<adamgreig> 1.0 draws ever closer :D
<re_irc>
<eldruin> indeed!
<re_irc>
<adamgreig> given the ongoing msp430 issues I think let's keep holding off on a new bare-metal for right now, and possibly we want to get svd2rust updated before that happens too
<re_irc>
<adamgreig> (that is: a bare-metal patch release(?) that re-exports the critical-section types and also calls itself deprecated and suggests to use c-s directly instead)
<re_irc>
<adamgreig> the other related thing is that cortex-m's "singleton!()" macro is no longer really cortex-m specific, so it _could_ go in its own crate or even in critical-section, but design-wise the just-released https://crates.io/crates/static_cell might be better anyway
<re_irc>
<adamgreig> (and performs essentially the same role)
<re_irc>
<dirbaio> 👋 hi, sorry late again
<re_irc>
<adamgreig> the only thing I had left on the agenda is thinking about cortex-m 0.8, and whether it wants any bigger changes besides merging the outstanding PRs around debug stuff. I still wanted to transition to having it use a PAC but haven't made any progress recently
<re_irc>
<adamgreig> otherwise 0.8 is a few relatively minor breaking changes in exchange for another huge upheaval of the whole cortex-m ecosystem and/or another cursed semver hack, which doesn't hugely appeal
<re_irc>
<adamgreig> (well and the interrupt::free soundness fix I suppose)
<re_irc>
<newam> adamgreig: as in express the CPU peripherals in SVD?
<re_irc>
<adamgreig> yea
<re_irc>
<adamgreig> right now the c-m peripheral access is very ad-hoc and different for different peripherals
<re_irc>
<adamgreig> there's room for debate over what sort of PAC it should be and how exclusive access should be managed etc, but the general idea is to have a PAC and a HAL that uses it to provide high-level methods
<re_irc>
<adamgreig> and finally something to provide the inline asm/cpu register access stuff
<re_irc>
<adamgreig> cool, let's call it there for today then, thanks everyone! 👋
<re_irc>
<adamgreig> dirbaio, what do you think of deprecating or removing singleton!() from c-m for next breaking release and suggesting static_cell instead?
<re_irc>
<dirbaio> adamgreig: no strong opinion from me either way... I've always found the "singleton!" syntax too magic, but OTOH I'd say static_cell is not a full replacement for it because it's more verbose
<re_irc>
<dirbaio> you can build the "singleton!" macro on top of StaticCell too
<re_irc>
<dirbaio> so maybe the question is "do we keep or remove singleton! in cortex-m?", and if it's "remove" then just let people write/use whatever
<re_irc>
<dirbaio> since with critical-section it's now easier to write these utils in a portable way
dc740 has quit [Ping timeout: 252 seconds]
brazuca has quit [Quit: Client closed]
GenTooMan has quit [Ping timeout: 244 seconds]
GenTooMan has joined #rust-embedded
<re_irc>
<wannes_> hi, apologies if this is not the right room but I wanted to check whether the following is user error or not. I'm using "alloc-cortex-m" v0.4.2 and am regularly getting "panic" caused by the "borrow_mut()" call in the "alloc" function, possibly indicating the heap has already been borrowed but I can't work out how that would have happened
dc740 has joined #rust-embedded
<re_irc>
<Noah> hey, does anyone know
<re_irc>
a) if I can detect that I am in an integration test
<re_irc>
or b) how I can make integration tests use defined rustflags in the .cargo/config?
<re_irc>
<Noah> * ".cargo/config"?
causal has joined #rust-embedded
<re_irc>
<nikomatsakis> Question for folks. I've been thinking about examples where Rust is used to build a complex framework that's almost a DSL. Bevy and Rocket are two examples, Salsa is another that's dear to my heart, you could maybe count Diesel. All of these have in common that they model one domain, to some extent, using a healthy does of procedural macros and some clever use of Rust traits. Each of them would benefit from more...
<re_irc>
... control over error messages, as well as more complex trait mechanisms like GATs/TAITs. I'm wondering if there are similar projects in the Embedded space -- I guess that the Embassy runtime could count.
<re_irc>
<Noah> nikomatsakis: maybe rtic :) I guess there is lesser known ones as well (e.g smlang)