<re_irc>
<Alex Norman> before I dive further and switch over to nightly, am I correct that rust still requires nightly to use no_std and a custom global alloc? looks like the only thing I need nightly for is logging/panicking on allocation fail?
<re_irc>
<James Munns> Alex Norman: yes (in practice)
<re_irc>
<Alex Norman> okay.. i guess it is what it is.. thought/hoped I'd be able to stay with stable but maybe going to nightly isn't such a big deal.. just have to let my collaborators know to change over
starblue1 has quit [Read error: Connection reset by peer]
starblue1 has joined #rust-embedded
emerent has quit [Ping timeout: 250 seconds]
emerent has joined #rust-embedded
fabic has joined #rust-embedded
Ekho has quit [Quit: CORE ERROR, SYSTEM HALTED.]
Ekho has joined #rust-embedded
fabic has quit [Ping timeout: 256 seconds]
fabic has joined #rust-embedded
Guest2 has joined #rust-embedded
<re_irc>
<gauteh> Has anyone had any issues with nvim+rust-analyzer (coc) on embedded projects where rust-analyzer doesn't find Some/Ok/Result/Option in scope? super-annoying..
fabic has quit [Ping timeout: 268 seconds]
<re_irc>
Is there a way to disable cargo feature unification at the workspace level?
<re_irc>
<@azerupi> Hi all!
<re_irc>
I have a repository containing multiple firmwares and some libraries for them. I'm using workspaces to avoid having to go into each sub-directory to build. But there seems to be a lot of friction. The first problem is that workspaces can only have one target specified. So you can't mix target agnostic libraries with target specific firmwares. This problem I managed to solve by having two workspaces. The second problem is that...
<re_irc>
... cargo unifies features at the workspace level. So when you have two firmwares using the same HAL library with different configurations it blows up.
<re_irc>
<@azerupi> Interestingly you can't run "cargo build" but "cargo build -p firmware1" works fine
<re_irc>
<K900> Why do you need those to be workspaces at all then?
<re_irc>
<K900> You won't be able to reuse artifacts between targets in that kind of setup anyway
<re_irc>
<@azerupi> It was for convenience to avoid having to "cd" into each sub-dir and have to modify CI scripts whenever a firmware is added
<re_irc>
<danielzfranklin> It's a technique for having a cargo subcommand that runs arbitrary code. So you can set up `cargo xtask build` to cd into every project and build it
fabic has joined #rust-embedded
<re_irc>
<@azerupi> Interesting, I'll take a look! Thanks
<re_irc>
<danielzfranklin> This line is the key to making it work, in case you miss it
<re_irc>
<ryan-summers> Generally, I've found it most helpful to just store everything in UTC and then potentially store what TZ the device is in for conversion on a PC when analyzing / downloading data
<re_irc>
<ryan-summers> Not always feasible, but def the easiest option if you have to have TZs
<re_irc>
<dirbaio> solid advice, been doing that until now
<re_irc>
<dirbaio> but now I need the device to do "pin code 1234 is valid mon-fri 9am-5pm *local time*"
<re_irc>
<dirbaio> +:( :(
<re_irc>
<dirbaio> fully offline
<re_irc>
<ryan-summers> Just beware that any timezone implementation you roll will very likely eventually become invalid. There's a number of good talks about this
<re_irc>
<ryan-summers> E.g. if the EU chooses to end daylight saving stime eventually
<re_irc>
<ryan-summers> Legislation changes timezones dynamically, so code will always eventually be wrong
<re_irc>
<dirbaio> yeah
<re_irc>
<ryan-summers> The "fully offline" part is hard. Do you _ever_ have a chance to sync to a server?
<re_irc>
<ryan-summers> You could essentially just regularly update from some server and then cache locally until the next update
<re_irc>
<dirbaio> the device gets PIN codes and stuff in a "config" downloaded dynamically from the server
<re_irc>
<ryan-summers> I'd store the latest time as reported by the server and use that + offset or something?
<re_irc>
<ryan-summers> Or use server time to resync an RTC
<re_irc>
<dirbaio> what I want to avoid is the device being off-by-1-hour if it's offline during a DST change
<re_irc>
<ryan-summers> Yeah was just contemplating that
<Shell>
you can have the server tell you when DST is, theoretically.
<re_irc>
<danielzfranklin> Do you need to make your own timezone db just for your location and download it from the server?
<re_irc>
<dirbaio> yeah, a device has one fixed timezone configured at install time
<re_irc>
<dirbaio> so I don't want the device to have data for all world's timezones :D
<re_irc>
<dirbaio> so perhaps do unrolling like chrono-tz, but for a "sane" period like 5 years?
<re_irc>
<dirbaio> then send that from the server in the config
<re_irc>
<ryan-summers> If you can guarantee that the device pings the server once per DST changeover, you can store the time at which DST starts/ends as well
<re_irc>
<ryan-summers> And then have the server tell you the next DST crossover
<re_irc>
<dirbaio> yeah, that'd be like the "unrolling" with just 1 entry (next dst change)
<re_irc>
<danielzfranklin> dirbaio: I don't think you can know that far in advance when this will change. IIRC it sometimes changes with like a week's notice
<re_irc>
<ryan-summers> I'd just personally lean towards offloading that from firmware by any means possible because updating the server will always be way easier than fixing firmware on all the devices
<re_irc>
<dirbaio> danielzfranklin: hehe well in that case it'll be wrong until the device gets online, there's no way around that
<re_irc>
<danielzfranklin> I just meant you can't make it for five years in the future and save it as a static file, your server needs to fetch it semi-dynamtically
<re_irc>
<dirbaio> ah yeah, true
<re_irc>
<danielzfranklin> * your server
<re_irc>
<dirbaio> the server would have to dynamically unroll from the current tzdb when generating the config
<re_irc>
<dirbaio> blerugh :D
<re_irc>
<ryan-summers> I think all paths point towards the server having to be the driver behind this
<re_irc>
<ryan-summers> TZs are too dynamic otherwise
<re_irc>
<dirbaio> yeah
<re_irc>
<dirbaio> kinda shame it'll be very usecase-specific
<re_irc>
<dirbaio> not sure how an embedded-friendly reusable timezone crate would look like
<re_irc>
<ryan-summers> I honestly avoid anything time related like the plague
<re_irc>
<ryan-summers> Even adding N seconds to an RTC timestamp is super non-trivial
<re_irc>
<danielzfranklin> Wait a second, can you just use a public ntp server?
<re_irc>
<ryan-summers> So i report it as RTC timestamp + N second offset to the server
<re_irc>
<ryan-summers> Because you have to deal with leap years etc. if you want to increment any RTC time
<re_irc>
<dirbaio> danielzfranklin: ntp just gives you precise UTC time doesn't it? you're supposed to convert that to local time yourself
<re_irc>
<danielzfranklin> Yeah that was stupid of me
<re_irc>
<dirbaio> I already have the devices syncing UTC time from my server (custom protocl, not NTP)
<re_irc>
<dirbaio> with crap precision due to low-power super high latency BLE yay
<re_irc>
<dirbaio> ryan-summers: oooof :D
<re_irc>
<dirbaio> I was planning to use chrono for that, hopefully it's not too bloated :D
<re_irc>
<ryan-summers> Does your device/chip not have an RTC you can use?
<re_irc>
<dirbaio> I'm using the nRF's RTC which is more like stm32's LPTIM, it just counts up at 32768hz
<re_irc>
<dirbaio> it's not like stm32's RTC which is "Y/M/D H:M:S"
<re_irc>
<ryan-summers> Oh god, so it's not an RTC at all
<re_irc>
<dirbaio> they call it RTC 🤷
<re_irc>
<dirbaio> yeah 😂
<re_irc>
<ryan-summers> It's more like a timestamp unit
<re_irc>
<ryan-summers> Any hardware mods allowed? Adding an external RTC wouldn't be a bad idea to help out with the design here, but obviously requires more thought
<re_irc>
<dirbaio> hardware already shipped :P
<re_irc>
<ryan-summers> Figured, that's pretty common
<re_irc>
<dirbaio> either way I'm not a fan of adding hardware to avoid having to do stuff in firmware...
<re_irc>
<ryan-summers> Changing requirements? ;)
<re_irc>
<dirbaio> no, I knew we'd want this from day zero, but I figured I can do that in firmware
<re_irc>
<dirbaio> essentially, I currently got the UTC unix timestamp (in 32768hz ticks), and want "Y/M/D H:M:S" from that, in local time
<re_irc>
<ryan-summers> Oh, that's not a fun time
<re_irc>
<dirbaio> hehehe :'(
<re_irc>
<dirbaio> I hope chrono is not too bloated... combined with the custom trimmed down timezone. chrono-tz is definitely out
<Shell>
if you have access to an IP network, many DHCP servers can provide timezone info, btw. :)
<Shell>
that appears to be the standard protocol for sharing timezone info over a network.
<re_irc>
<dirbaio> relying on the user's crap ISP router to do that correctly seems like nightmares 😂
<Shell>
quite possibly, it depends on the environment the device runs in.
<re_irc>
<dirbaio> it's a consumer product, has to run on _any_ network
<re_irc>
<dirbaio> I've already had lots of fun adding "fixes" to smoltcp to tolerate broken networks and DHCPs...
* Shell
nodnod.
<re_irc>
<dirbaio> adding chrono to convert "utc unix time -> utc Y/M/D H:M:S" increases firmware size by only +4kb!! :D
<re_irc>
<dirbaio> timezones shouldn't add much more if I unroll on server, it's just a lookup then adding the offset
<re_irc>
<dirbaio> so... yay I guess?
<re_irc>
<danielzfranklin> I've spent a while trying to debug a segfault and I've narrowed it down to only occurring when I debug an integration test via rust-analyzer in a workspace set up like the ferrous systems sample (integration test is of a library that is no-std but can run on my laptop, there's a separate workspace called "cross" that only runs on the target).
<re_irc>
Stop reason: signal SIGSEGV: invalid address (fault address: 0x8)
<re_irc>
If I put a panic at the top of the only library function the test calls, segfault. If I instead comment out the call, no segfault.
<re_irc>
The call stack is also interesting because (I think) no user code has run yet
<re_irc>
<danielzfranklin> +(unit tests work fine)
<re_irc>
<danielzfranklin> I'm interested in if other people are using vscode's debug button in this configuration. If it's probably my mistake I'll keep trying to debug, but if this just isn't supported I don't want to spend a huge amount of time on it.
<re_irc>
<adamgreig> room hi everyone, meeting time again! agenda is https://hackmd.io/G5Kr_cXbTealW4JRGZZ9Lg, please add anything you'd like to announce or discuss and we'll start in 5 min :)
<re_irc>
<dirbaio> 👀
<re_irc>
<adamgreig> OK, let's start! I don't have any announcements for this week, anyone got anything?
<re_irc>
tldr: Rust+Embassy is faster+smaller than C+FreeRTOS :D
<re_irc>
<adamgreig> yea, very cool! fun to win a size contest with C too
<re_irc>
<adamgreig> I don't have any updates on the cortex-m front: I still think it would be interesting to try critical-section for 0.8 and will try it out at some point, and we should probably cut a 0.8 alpha soon too to start testing the new itm stuff. no idea yet on how to make 0.8 less painful a release than 0.7, though.
<re_irc>
<TheSirC> I was wondering if now was the time for questions or if another time might be more appropriate...
<re_irc>
<eldruin> dirbaio: nice! maybe something for the newsletter diondokter ?
<re_irc>
if it gets adopted as "the" way to abstract over critical sections it seems appropriate it has a more official home at the WG
<re_irc>
<dirbaio> oh yeah, wrt critical-section: i'm happy to transfer it to the WG if that's deemed useful
<re_irc>
<adamgreig> TheSirC: if you could hold off until after the meeting, we'll be done within 50 minutes
<re_irc>
<adamgreig> thanks, I think that would be good if we adopt it inside cortex-m/bare-metal
<re_irc>
<adamgreig> not sure if it should be used directly by c-m or abstractly via bare-metal or what though, yet...
<re_irc>
<adamgreig> leaning towards directly in c-m I think
<re_irc>
<dirbaio> perhaps discuss and document the assumptions it has
<re_irc>
<dirbaio> what's exactly the definitions of "program", "thread", "critical section" etc
<re_irc>
<adamgreig> yea
<re_irc>
<dirbaio> for exmaple the "thread = irq number" vs "thread = irq priority level" discussion from a while ago etc
<re_irc>
<adamgreig> those definitions need to be shared by basically everything in its orbit including other wg crates
<re_irc>
<adamgreig> I expect it will tie into things like why we currently mark "enable_interrupt" as unsafe
<re_irc>
<adamgreig> but we clearly need to solve the problem with cortex-m assuming you can always just stop the world to safely share access
<re_irc>
<dirbaio> and also related: definition of Send/Sync
<re_irc>
<dirbaio> multicore etc :P
<re_irc>
<adamgreig> so no biggie :P
<re_irc>
<adamgreig> we have various bits of that floating around, but putting them together would be nice
<re_irc>
<adamgreig> ideally in a way that doesn't suddenly declare rtic or embassy or something to be unsound, lol
<re_irc>
<adamgreig> "you're not allowed to write rust programs any more actually"
<re_irc>
<adamgreig> hmm, not sure what the best starting point is for that but I might at least collate the various things that have been written in the past and annoy you dirbaio some time
<re_irc>
<dirbaio> sounds good!
<re_irc>
<adamgreig> thanks!
<re_irc>
<adamgreig> onto resources, we talked last week about updating the awesome-embedded-rust list with a more prominent section on commonly used shared crates for traits etc
<re_irc>
<adamgreig> the embedded-* stuff like hal, dma, nal, graphics, time?, etc
<re_irc>
<adamgreig> so it's an open task if anyone wants to volunteer for it!
<re_irc>
<adamgreig> in general there might be other opportunities to tidy up the list now it's got a lot of crates on it
<re_irc>
<ythgl> is this just reorging links under a new section?
<re_irc>
<eldruin> yeah, lots of vertical lists
<re_irc>
<adamgreig> at the moment embedded-dma, embedded-time, fugit aren't on the list at all, and we have "component abstraction crates" which includes both "accelerometer" and "radio" alongside "embedded-nal" and "embedded-graphics"
<re_irc>
<dirbaio> embedded-storage
<re_irc>
<therealprof> If we want to stay an "awesome" list we can't go overboard deviating from the official structure though.
<re_irc>
<ythgl> would volunteer, but feel I would be bugging more familiar people too much to be helpful
<re_irc>
<eldruin> oops yeah we should add those
<re_irc>
<adamgreig> therealprof: sure, but I think we get to choose how to be an awesome list, right? in any event we can reorganise the sections to help people navigate it
<re_irc>
<eldruin> maybe we can do things like put all hal impls for the same stm32 family in the same line
cr1901_ has joined #rust-embedded
<re_irc>
<therealprof> Uhm, funny enough I just checked and we're not even listed on the awesome list list. 😀
<re_irc>
<dirbaio> so, what's the goal of the CS stuff?
<re_irc>
<dirbaio> it seems to me most of the discusison has centered around the CS pin itself
<re_irc>
<dirbaio> but the original problem that started the discussion is allowing drivers to share SPI buses
<re_irc>
<Lachlan Sneff> Add an ‘acquire_cs’ function to shared-bus?
<re_irc>
<allexoll> has that issue not been solved with I2C?
<re_irc>
<dirbaio> and if the goal is "allow drivers to share a bus" then IMO the solution is to add traits for "SPI device" and "SPI bus", which is what my proposal does https://github.com/rust-embedded/embedded-hal/pull/351
<re_irc>
<dirbaio> drivers get an instance of a "SPI device", which they can use to "lock" the bus then rx/tx data to it
<re_irc>
<adamgreig> how do the drivers control their CS in that case?
<re_irc>
<adamgreig> especially in multi-device scenarios the CS is unlikely to be controlled by the SPI peripheral
<re_irc>
<adamgreig> (whereas at least with one device on the bus some people may use SPI-peripheral-controlled-CS)
<re_irc>
<Lachlan Sneff> The idea would be to use shared-bus to share the SPI bus type?
<re_irc>
<dirbaio> plan is for the "SPI device" impls to lower CS at start of transaction, raise at end of transaction
<re_irc>
<dirbaio> Lachlan Sneff: shared-bus would impl the "device" traits, HALs would impl the "bus" traits
<re_irc>
<dirbaio> with this I'd even say we _don't_ want ManagedCS, even
<re_irc>
<adamgreig> so the HAL would provide a struct that impls SPI-device and the HAL is responsible for having the user provide a CS pin when it constructs that struct and then driving it
<re_irc>
<dirbaio> what if the user wants to tie CS low in the PCB, to save a GPIO pin?
<re_irc>
<adamgreig> and the driver just gets given its "impl SPIDevice" and runs transactions?
<re_irc>
<dirbaio> adamgreig: HAL crates just impl the Bus traits
<re_irc>
<dirbaio> then there's crates implementing "bus sharing", like shared-bus. those would take a bus and share it
<re_irc>
<dirbaio> * make it "shareable", ie allowing having multiple Devices on the same Bus
<re_irc>
<dirbaio> "bus sharing" crates is what would impl the Device trait
<re_irc>
<dirbaio> * traits
<re_irc>
<dirbaio> perhaps embedded-hal itself could have a dumb "bus to device" adapter if you don't want to actually share the bus
<re_irc>
<adamgreig> shouldn't it, otherwise everyone needs to use shared-bus or some other 3rd party crate?
<re_irc>
<adamgreig> probably a lot of use cases (and especially a lot of first use cases) are going to be one device on the bus, so it'd be nice if that was relatively low friction
<re_irc>
<dirbaio> sounds good yup
<re_irc>
<adamgreig> how will those 3rd party non-hal crates implement the CS driving? OutputPin?
<re_irc>
<dirbaio> OutputPin yep
<re_irc>
<dirbaio> or maybe HALs could impl both Bus and Device, to eg take advantage of hardware-CS
<re_irc>
<dirbaio> hardware-CS is a giant mess though
<re_irc>
<therealprof> Sure is.
<re_irc>
<adamgreig> I don't know that there's much point to using hardware cs except when acting as a peripheral
<re_irc>
<adamgreig> but nevertheless HALs seem well placed to implement Device if it's simple enough?
<re_irc>
<dirbaio> e310x-hal already impls this "bus vs device", with builtin sharing
<re_irc>
<dirbaio> well, bus sharing is not that trivial
<re_irc>
<dirbaio> there's tradeoffs
<re_irc>
<dirbaio> how do you do the mutex?
<re_irc>
- critical section
<re_irc>
- RefCell-like, panic/err if already taken
<re_irc>
- async, make the task yield until the other releases it
<re_irc>
- no mutex at all, no sharing
<re_irc>
<dirbaio> how do you do the mutex?
<re_irc>
- critical section
<re_irc>
- async, make the task yield until the other releases it
<re_irc>
- RefCell-like, panic/err if already taken
<re_irc>
<adamgreig> I see, so have e-h provide the no-sharing approach built-in, but let other crates provide alternates that enable sharing, with the HALs just impling Bus?
<re_irc>
<dirbaio> that's the best IMO yep
<re_irc>
<dirbaio> so HALs don't have to impl every flavor of locking
<cr1901>
Only tangentially related, but I wish hals mandated being able to pass a periph ref back to the user in case they need it in an interrupt handler
<cr1901>
I've no idea how to enforce that tho, so I guess I'll just add it to the crates I need it for/open issues to discuss
<re_irc>
<dirbaio> i2c has kinda the same problem btw
<re_irc>
<dirbaio> there's no problem with CS
<re_irc>
<adamgreig> but the sharing's the same, huh
<re_irc>
<dirbaio> but there's still the problem of sharing a bus that has multiple devices between all the drivers
<re_irc>
<almindor> we could abstract the locking mechanism itself so the user can choose, preferably with a HAL-default for simplicity
<re_irc>
<therealprof> Whatever works and makes people happy is fine with me.
<re_irc>
<dirbaio> eldruin: so does the "Bus vs Device" idea sound good to you?
<re_irc>
<almindor> the general principle worked well in e310-hal we just kinda forced the locking
<re_irc>
<almindor> i didn't see it impact performance in any way
<re_irc>
<dirbaio> for example, if I port one HAL, one driver, and shared-bus, and it all works out, would you be happy merging that?
<re_irc>
<dirbaio> almindor: how do you do the locking? critical sections?
<re_irc>
<eldruin> The idea sounds good, but all use cases need to be covered. one problem I highlighted in the PR is what to do if deasserting CS fails while this is done in "drop"
<re_irc>
<ryankurte> i still think the need for "drop()" is a bit of a footgun compared to the closure option
<re_irc>
<dirbaio> yeah, I agree with your comments in the PR, the closure approach is better
<re_irc>
<ryankurte> you lose the inherent ordering which is always a pain with mutexen
<re_irc>
<almindor> CS error handling is difficult to abstract about because it depends on HW vs SW handling. HW de-asserts aren't even visible to the OS in some cases
<re_irc>
<almindor> I'd panic in the detectable cases and call it a day
<re_irc>
<dirbaio> almindor: you mean in like, Linux?
<re_irc>
<dirbaio> +like the RPI?
<re_irc>
<almindor> heh, no sorry about the nomenclature I meant "the running process" :D
<re_irc>
<almindor> e.g. if I use hw managed CS on the e310 I don't really get to see the de-asserts
<re_irc>
<ryankurte> dirbaio: that's fine imo, everything async is a bit cursed pending async traits
<re_irc>
<dirbaio> ah.. well in that case you can assume it won't fail, since it's all on-chip, isn't it?
<re_irc>
<almindor> yeah, and I mean what can you detect as a CS de-assert failure exactly tbh? 90% of pin operations are infallible
<re_irc>
<ryankurte> almindor: yeah, vs. over a USB->SPI guy or with manually toggled pins where you very much could
<re_irc>
<dirbaio> fallible gpio is if you're using eg an i2c gpio expander
<re_irc>
<dirbaio> or a ftdi over usb
<re_irc>
<dirbaio> or similar
<re_irc>
<ryankurte> (this feels like a rehash of the "everything should be fallible" argument which, we've already covered imo)
<re_irc>
<dirbaio> so
<re_irc>
<ryankurte> * "(everything | nothing)
<re_irc>
<dirbaio> if shared-bus had a Device impl that toggles CS, a user could instantiate it with a faillble OutputPin
<re_irc>
<dirbaio> in that case it makes sense that it can propagate the error up, instead of panicking
<re_irc>
<dirbaio> if shared-bus had a Device impl that toggles CS, a user could instantiate it with a faillble OutputPin from, say, a usb ftdi thingy
<re_irc>
<almindor> sure, we already return the error here tho, so it should just work? (tm)
<re_irc>
<dirbaio> yeah, it does Just Work with the closure version
<re_irc>
<dirbaio> the problem was in #351 I proposed making Drop auto-deassert CS, and you can't return an error from Drop
<re_irc>
<dirbaio> so the closure version is better, we'll do that
<re_irc>
<dirbaio> :D
<re_irc>
<dirbaio> so, not sure if anyone wants to add anything
<re_irc>
<dirbaio> I'll change it to closure, then try to get impls up and running, hopefully it works out :D
<re_irc>
<dirbaio> IMO if InputPin has "is_high, is_low" it makes sense for Wait to have "wait_for_high, wait_for_low"
<re_irc>
<dirbaio> it's all a bit bikesheddy
<re_irc>
<dirbaio> there's really no pros/cons for "wait_for_high, wait_for_low" vs "wait_for_state" other than consistency maybe
<re_irc>
<adamgreig> maybe InputPin should have is_state and default implementations of is_high and is_low in terms of it... :/
<re_irc>
<adamgreig> and then same for wait_for_*
<re_irc>
<adamgreig> I don't think it matters too much though...
<re_irc>
<adamgreig> we do already have the PinState enum
<re_irc>
<adamgreig> and set_high/set_low/set_state for OutputPin
<re_irc>
<dirbaio> "is_state(State) -> bool"? or "get_state() -> State"? :D
<re_irc>
<ryankurte> i do love a good default implementation
<re_irc>
<adamgreig> hah, uh, idk...
<re_irc>
<dirbaio> you can't have default impls with today's GAT-async traits
<re_irc>
<adamgreig> you can in the non-async traits at least :P
<re_irc>
<adamgreig> probably just "state() -> State" is the most idiomatic
<re_irc>
<adamgreig> cf "set_state(State)" for OutputPin
<re_irc>
<adamgreig> keep is_high()->bool and is_low()->bool and provide default impls in terms of state() where possible?
<re_irc>
<ryankurte> dirbaio: see previous: everything is expected to be ugly till async trait
<re_irc>
<adamgreig> and then wait_for_high(), wait_for_low(), wait_for_state(State), the first two again default in terms of third?
<re_irc>
<dirbaio> oof
<re_irc>
<adamgreig> does that end up sucking for async :/
<re_irc>
<dirbaio> no, but I really don't see the advantage
<re_irc>
<adamgreig> in keeping all three?
<re_irc>
<dirbaio> if your i2c device irq pin is active low you'll do "wait_for_low()"
<re_irc>
<adamgreig> same reason we have set_high(), set_low(), set_state() in OutputPin
<re_irc>
<eldruin> I don't think a couple missing default impls are too bad for async right now
<re_irc>
<dirbaio> I've never needed "wait_for_state()" to be honest
<re_irc>
<dirbaio> IMO "wait_for_high, wait_for_low" is the most consistent with _today's_ InputPin
<re_irc>
<adamgreig> I'd defo keep wait_for_high/wait_for_low since they are probably the nicest and most commonly used api, and if someone does really need to choose between them at runtime it's not like that's hard to do
<re_irc>
<dirbaio> if we think "state"-oriented APIs are better then we could open an issue/pr to discuss that, then refactor _all_ traits to that, not just async "digital::Wait" ...
<re_irc>
<adamgreig> I guess we could always add wait_for_state with a default impl that calls either wait_for_high or wait_for_low, lol
<re_irc>
<dirbaio> yeah
<re_irc>
<dirbaio> so IMO the "state vs high/low" discussion shouldn't be blocking for merging "Wait"
<re_irc>
<dirbaio> especially since the cost of breaking the async crate will stay low for quite a while
<re_irc>
<adamgreig> 👍️
<re_irc>
<adamgreig> we're super over time for this meeting, so I think let's wrap it up here
<re_irc>
<chemicstry> hey, has anyone compared the performance of RTT (from probe-rs) and ITM (SWO) logging performance? I was always using the ITM logging for my STM32 projects, because it was way faster than semihosting, so wondering how RTT compares. Does it have any additional features?
<re_irc>
<dirbaio> RTT is super fast if you have a fast probe
<re_irc>
<dirbaio> and you can do host->target channels which I think you can't do with ITM
<re_irc>
<ryan-summers> It depends on how you're using ITM. If you're using ITM as a tracer, there's no CPU overhead at all
<re_irc>
<ryan-summers> E.g. for profiling
<re_irc>
<ryan-summers> Logging is interesting. I imagine the only real difference is that for ITM, you write to the ITM fifo regs, but for RTT you just write to RAM, so it depends on the memory buses of the chip?
<re_irc>
<ryan-summers> But you still have to do the same formatting for each. I doubt there's a significant difference, since I believe the ITM has its own hardware buffer
<re_irc>
<ryan-summers> I imagine the string formatting is likely going to dwarf the actual writes to ITM/RTT
<re_irc>
<ryan-summers> Also, RTT requires a RAM buffer as far as I understand it?
<re_irc>
<chemicstry> I see, I'm developing on a board with st-link v2, which is quite slow with flashing, but if it's the same speed for RTT, then it should be still plenty for debug logs
<re_irc>
<ryan-summers> Both RTT and ITM throughput depend directly on the speed of the probe
<re_irc>
<ryan-summers> RTT will silently drop overflowing data if the probe doesn't read it fast enough though
<re_irc>
<dirbaio> you can configure it to block instead
<re_irc>
<ryan-summers> I tend to use RTT out of simplicity as well, I think the tooling is better (e.g. support from probe-run)
<re_irc>
<chemicstry> I was using ITM, because it was supported by openocd and cortex-debug vscode extension. But now I'm experimenting with the probe-rs-debug, which what I assume is intended to replace openocd + cortex-debug?
<re_irc>
<thejpster> don't forget probe-run does defmt, which generally avoids sending strings and sends unique string IDs over the RTT transport instead. Much faster.
<re_irc>
<thejpster> the formatting happens on your host PC inside the probe-run binary
<re_irc>
<ryan-summers> probe-rs is a massive step up imo from openocd
<re_irc>
<ryan-summers> And yeah, probe-run + probe-rs + RTT is a very common use case
<re_irc>
<ryan-summers> - defmt for lots of folk
<re_irc>
<chemicstry> I was hesitant to use probe-rs because it was missing debugging stuff, but with probe-rs-debug it looks really nice
<re_irc>
<ryan-summers> probe-rs has support for a GDB server too
<re_irc>
<ryan-summers> Plus I think it has a VSCode debug plugin?
<re_irc>
<dirbaio> wohoo I got the timezone stuff working :D
<re_irc>
<dirbaio> with just 4.5kb of bloat
<re_irc>
<dirbaio> plus horrible code in the server to calculate the "unrolled" timezone data for 5 years
<re_irc>
<danielzfranklin> ryan-summers: When I last looked it didn't support break on line number, so I don't think it's ready yet?
<re_irc>
<dirbaio> it does support breakpoints now