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
<whitequark[cis]> found the biologist
<whitequark[cis]> i 100% approve but it sounds like it would be incomprehensible to most engineers
starblue has quit [Ping timeout: 252 seconds]
starblue has joined #rust-embedded
bomb has joined #rust-embedded
bomb has quit [Remote host closed the connection]
bomb has joined #rust-embedded
<feerless[m]> I have this multimeter that has two fuses, neither are installed. How can I figure out which one goes where. There are no labels in the slots for the fuses.
mabez[m] has quit [Quit: Idle timeout reached: 172800s]
Mark[m] has quit [Quit: Idle timeout reached: 172800s]
xiretza[cis] has quit [Quit: Idle timeout reached: 172800s]
oneDragon[m] has quit [Quit: Idle timeout reached: 172800s]
sarath08071994[m has quit [Quit: Idle timeout reached: 172800s]
bomb has quit [Quit: 💣]
paulyoung[m] has quit [Quit: Idle timeout reached: 172800s]
<thejpster[m]> I installed the Cortex-M QuickStart the other day and it gave me cortex-m 0.6 and cmrt 0.6. These then bring in r0. We should probably update it.
<thejpster[m]> It also has cortex-debug config, but probe-rs extension works better.
ruabmbua[m] has joined #rust-embedded
<ruabmbua[m]> hey, I have been absent with my embedded rust activities for a while. Has anyone a good resource what the status is on all the new different embedded-hal crates? I started to play around with a rp2040 this time, and I noticed that the hal includes several different embedded hal related crates. (even multiple different versions). I assume this is just a transition period to embedded hal 1.0?
<JamesMunns[m]> It might support multiple ehal versions for compatibility, it shouldn't harm your code size, and only minority affect compile times.
<JamesMunns[m]> (welcome back!)
<AdamHott[m]> I support James' motion, welcome back!
bomb has joined #rust-embedded
bomb has quit [Remote host closed the connection]
bomb has joined #rust-embedded
<ruabmbua[m]> Thanks, I just was a bit confused where to actually find the serial traits I want
adamgreig[m] has quit [Quit: Idle timeout reached: 172800s]
bomb has quit [Quit: 💣]
starblue has quit [Ping timeout: 252 seconds]
<Ecco> Question: can probe-rs be used to retrieve ITM samples?
<Ecco> Apparently it supports configuring the TPIU and getting SWO frames
<Ecco> (looking at the code)
<Ecco> but I don't see any tutorial
danielb[m] has joined #rust-embedded
<danielb[m]> Who's the current maintainer of embedded-hal-bus? There's this question: https://github.com/almindor/mipidsi/issues/129 regarding SPI ExclusiveDevice, whether ExclusiveDevice not setting a definite initial value should be considered a bug?
vollbrecht[m] has joined #rust-embedded
<vollbrecht[m]> <danielb[m]> "Who's the current maintainer..." <- isnt it directly part of the e-hal crate
<danielb[m]> there are ... layers to this question :D why does esp-hal pull the pin down, why does embedded-hal-bus not force the pin high?
<danielb[m]> anyway I just wanted to throw this in because I don't feel this to be a display-interface issue, and I'm unsure how to approach it
<vollbrecht[m]> i think this is a good point for the next meating. Maybe add the issue as a point on https://github.com/rust-embedded/wg/discussions/747
<vollbrecht[m]> so we can discuss it on the next meeting
<vollbrecht[m]> s/meating/meeting/
<danielb[m]> thanks, added
burrbull[m] has joined #rust-embedded
<burrbull[m]> <ruabmbua[m]> "Thanks, I just was a bit..." <- see embedded-io crate
enaut[m] has joined #rust-embedded
<enaut[m]> <ruabmbua[m]> "Thanks, I just was a bit..." <- I also found that using cargo doc --open can help a ton... you can search all documentation + dependencies regarding the current project
<ruabmbua[m]> yeah, unfortunately it does not help with crates I do not depend on yet ^^
starblue has joined #rust-embedded
ithinuel[m] has quit [Quit: Idle timeout reached: 172800s]
dngrs[m] has joined #rust-embedded
<JamesMunns[m]> you have to tell it how
<JamesMunns[m]> specifically the critical section feature, I think
<JamesMunns[m]> you can only "software emulate" with a critical section basically
mabez[m] has joined #rust-embedded
<mabez[m]> there is also assume single core if you target is single core
<dngrs[m]> <JamesMunns[m]> "you have to tell it how" <- shouldn't this be enough?... (full message at <https://catircservices.org/_matrix/media/v3/download/catircservices.org/OvmHVsLwSwSJlcRkiFWXqOnZ>)
<dngrs[m]> (sprocket board btw)
<JamesMunns[m]> I think portable atomic has a critical section flag, not sure tho
<dngrs[m]> JamesMunns[m]: that fixed it, thx!
<dngrs[m]> bit meh that I had to massage a transitive dependency, but, eh, works
<JamesMunns[m]> Yeah, it's a bit like embassy time and providing an impl sort of indirectly
M9names[m] has joined #rust-embedded
<M9names[m]> I don't think there are any better solutions though? The current situation is better than portable-atomic containing every impl and having a dependency on every crate required to do so.
<M9names[m]> Same with critical-section, embassy-time.
<JamesMunns[m]> Yep, wasn't criticizing. It's the worst approach except all the others
AtleoS has quit [Ping timeout: 245 seconds]
AtleoS has joined #rust-embedded
<dngrs[m]> <M9names[m]> "I don't think there are any..." <- > <@9names:matrix.org> I don't think there are any better solutions though? The current situation is better than portable-atomic containing every impl and having a dependency on every crate required to do so.
<dngrs[m]> > Same with critical-section, embassy-time.
<dngrs[m]> my issue is with `static-cell`, not `portable-atomic`; in order for `static-cell` to build I need to add the p-a crate as dependency. I'd prefer a feature flag in `static-cell` I guess
<dngrs[m]> * my issue is with `static-cell`, not `portable-atomic`; in order for `static-cell` to build I need to add the p-a crate (with the correct feature flag) as dependency. I'd prefer a feature flag in `static-cell` I guess
<dngrs[m]> It could probably be solved with better docs. I did read [those](https://docs.rs/static_cell/latest/static_cell/) before asking here but they didn't sufficiently enlighten me.
<dirbaio[m]> lol thatś outdated
<dirbaio[m]> it doesn´t use atomic-polyfill anymore
<dngrs[m]> I mean that's not fatal since atomic-polyfill redirects to portable-atomic
<dngrs[m]> but they say I should theck the [c-s README](https://github.com/rust-embedded/critical-section) and that really didn't help (me)
<dngrs[m]> since it only mentions cortex-m
<dngrs[m]> s/it/that/, s//`/, s//`/
<JamesMunns[m]> If you're using a sprocket it might have way out of date Cortex m deps
<JamesMunns[m]> From back in the a-p days
<dngrs[m]> it's a fresh project (generated with [`cargo embassy`](https://github.com/AdinAck/cargo-embassy))
<dngrs[m]> (added static_cell myself)
starblue has quit [Ping timeout: 268 seconds]
<JomerDev[m]> Alright, I've now spent multiple days trying to find a solution for this weird off by one error and I am at the end of my wits. I'm trying to emulate an eeprom with one rp2040 and test that with a second rp2040. I have 16 address pins and 8 data pins. My test board has just a loop which increments the address from 0 to 32 and requests a value (with an output enable pin). The "eeprom" currently just answers with the address that
<JomerDev[m]> was requested. But for some reason even if I let the test only run at 1 MHz (and the "eeprom" as fast as possible) I always get the address from last cycle back, not the current one. It's like the data is stuck in a buffer somewhere for one cycle. But I just can't figure out why it is reliably always one cycle behind, even if I modify the test clock to be a lot slower than I would need. Both rp2040 are also overclocked to 250MHz,
<JomerDev[m]> so should have definitely enough time
<JomerDev[m]> The code is here: https://github.com/JomerDev/mc68008-debugger it's the eeprom and eeprom_test folders
liebman[m] has joined #rust-embedded
<liebman[m]> I'm seeing an issue with the second I2C device (I2C1) in async mode - on a write_read operation it hangs after the write, never clocking for the read - same code on I2C0 works fine.
<liebman[m]> * I'm seeing an issue with the second I2C device (I2C1) in async mode - on a write_read operation it hangs after the write, never clocking for the read - same code on I2C0 works fine. (chip: esp32s3)
<JomerDev[m]> s/16/15/
<liebman[m]> * <del>I'm seeing an issue with the second I2C device (I2C1) in async mode - on a write\_read operation it hangs after the write, never clocking for the read - same code on I2C0 works fine. (chip: esp32s3)</del> wrong channel
starblue has joined #rust-embedded
<JomerDev[m]> <JomerDev[m]> "Alright, I've now spent multiple..." <- (I'd be really grateful if somebody can take a look and maybe even find something, I'm pretty much out of ideas of what else to check)
<JamesMunns[m]> JomerDev[m]: Do you have a hand written isr, or using built in async things?
<JomerDev[m]> Using pio on both sides. For the fifo read/write I tried both via DMA, async wait_push/wait_pull and blocking push/pull without effect
<JamesMunns[m]> JamesMunns[m]: 250 cycles per clock is too short to do async response imo, could work with isr
<JamesMunns[m]> JamesMunns[m]: Could be useful to use other gpio as indicators of state, and watch with a logic analyzer as a simple cycle measurement tracer
<JamesMunns[m]> JamesMunns[m]: Even just for triggering pio start, it could need to be isr directly triggering pio
<JomerDev[m]> I know of a project (in C++) which does very similar things, there the rp2040 is overclocked to 200MHz and running handwritten assembler in one core, the project archives < 100ns from output enable to answer
<JomerDev[m]> JamesMunns[m]: Ah sorry, ISR meaning what in that context? I was thinking of the Input Shift Register in the pio
<JomerDev[m]> Doh, interrupts
<JamesMunns[m]> Yeah I think if you're busy polling or reasonably direct interrupt service routine (ISR) functions. Not sure if you're using async with or without interrupt executors to fire.
<JamesMunns[m]> I'd expect a hundred or more cycles to context switch.
<JamesMunns[m]> * (ISR) functions you could hit 1mhz pretty well. Not
AtleoS has quit [Ping timeout: 260 seconds]
<JomerDev[m]> The actual loop is currently... (full message at <https://catircservices.org/_matrix/media/v3/download/catircservices.org/jWeDdkyKTzYKsVsgQxOAJbVd>)
<JomerDev[m]> JamesMunns[m]: > <@jamesmunns:beeper.com> If you're doing... (full message at <https://catircservices.org/_matrix/media/v3/download/catircservices.org/BjrcPVgjxcDQtogyCpIkWaHy>)
<vollbrecht[m]> how many registers does the rp need to save on a context switch into a ISR?
<JamesMunns[m]> vollbrecht[m]: Cortex m has a pretty low guaranteed ist response delay. Like <20 cycles including stacking iirc
<JamesMunns[m]> s/ist/isr/
<JomerDev[m]> I've now changed it so only the wait for anything in the fifo check is async. I'm also no longer overclocking the tester, meaning the "eeprom" rp2040 is twice as fast. And I still have the exact same issue of the response being off by one value
<JomerDev[m]> You were right James Munns I've now changed it to run without async at all and check if the fifo is empty before pulling and that apparently did the trick?!? I have no idea how it took me this long to make it work
<JamesMunns[m]> Yeah, rule of thumb, I wouldn't want to have anything more latency critical than a few hundred or a thousand CPU cycles
<JamesMunns[m]> (there are ways to make it work, but like in general without explicit care)
<JamesMunns[m]> (for async)
<JamesMunns[m]> Maybe the not empty trick was the important part tho!
<JomerDev[m]> The thing that kept confusing me was that when I didn't use async the values got even less in time than with async. But the reason turned out to be that calling just StateMachineRx.pull isn't a blocking call but just returns whatever is in the fifo at that point, which were mostly zero values
<M9names[m]> i mean, i know i've said this a few times already, but you should really look at the code you're using when it doesn't behave how you expect.... (full message at <https://catircservices.org/_matrix/media/v3/download/catircservices.org/dJgelvPEDllInDXbxvMVHzFv>)
<M9names[m]> and then the pac docs would have told you what they do:
<JomerDev[m]> True. But I always thought it was just not fast enough, which is why I worked out how to overclock the chip, run everything from RAM and how to give the core priority. Only after I did all these things and found it to be still too slow I thought there has to be something weird going on