00:00 <whitequark[cis]> found the biologist

00:00 <whitequark[cis]> i 100% approve but it sounds like it would be incomprehensible to most engineers

04:24 <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.

07:26 <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.

07:27 <thejpster[m]> It also has cortex-debug config, but probe-rs extension works better.

07:29 <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?

11:08 <JamesMunns[m]> It might support multiple ehal versions for compatibility, it shouldn't harm your code size, and only minority affect compile times.

11:08 <JamesMunns[m]> (welcome back!)

11:10 <AdamHott[m]> I support James' motion, welcome back!

14:37 <ruabmbua[m]> Thanks, I just was a bit confused where to actually find the serial traits I want

18:03 <Ecco> Question: can probe-rs be used to retrieve ITM samples?

18:03 <Ecco> Apparently it supports configuring the TPIU and getting SWO frames

18:04 <Ecco> (looking at the code)

18:04 <Ecco> but I don't see any tutorial

18:22 <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?

18:39 <vollbrecht[m]> <danielb[m]> "Who's the current maintainer..." <- isnt it directly part of the e-hal crate

18:40 <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?

18:40 <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

18:41 <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

18:41 <vollbrecht[m]> so we can discuss it on the next meeting

18:43 <vollbrecht[m]> s/meating/meeting/

18:48 <danielb[m]> thanks, added

19:02 <burrbull[m]> <ruabmbua[m]> "Thanks, I just was a bit..." <- see embedded-io crate

19:07 <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

19:07 <ruabmbua[m]> yeah, unfortunately it does not help with crates I do not depend on yet ^^

19:24 <JamesMunns[m]> you have to tell it how

19:24 <JamesMunns[m]> specifically the critical section feature, I think

19:24 <JamesMunns[m]> you can only "software emulate" with a critical section basically

19:26 <mabez[m]> there is also assume single core if you target is single core

19:31 <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>)

19:31 <dngrs[m]> (sprocket board btw)

19:34 <JamesMunns[m]> I think portable atomic has a critical section flag, not sure tho

19:34 <dngrs[m]> JamesMunns[m]: that fixed it, thx!

19:35 <dngrs[m]> bit meh that I had to massage a transitive dependency, but, eh, works

19:51 <JamesMunns[m]> Yeah, it's a bit like embassy time and providing an impl sort of indirectly

20:03 <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.

20:03 <M9names[m]> Same with critical-section, embassy-time.

20:14 <JamesMunns[m]> Yep, wasn't criticizing. It's the worst approach except all the others

20:30 <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.

20:30 <dngrs[m]> > Same with critical-section, embassy-time.

20:30 <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

20:30 <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

20:31 <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.

20:32 <dirbaio[m]> lol thatś outdated

20:32 <dirbaio[m]> it doesn´t use atomic-polyfill anymore

20:33 <dngrs[m]> I mean that's not fatal since atomic-polyfill redirects to portable-atomic

20:33 <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)

20:33 <dngrs[m]> since it only mentions cortex-m

20:34 <dngrs[m]> s/it/that/, s//`/, s//`/

20:39 <JamesMunns[m]> If you're using a sprocket it might have way out of date Cortex m deps

20:39 <JamesMunns[m]> From back in the a-p days

20:40 <dngrs[m]> it's a fresh project (generated with [`cargo embassy`](https://github.com/AdinAck/cargo-embassy))

20:40 <dngrs[m]> (added static_cell myself)

20:54 <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

20:54 <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,

20:54 <JomerDev[m]> so should have definitely enough time

20:54 <JomerDev[m]> The code is here: https://github.com/JomerDev/mc68008-debugger it's the eeprom and eeprom_test folders

20:56 <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.

20:56 <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)

20:56 <JomerDev[m]> s/16/15/

20:56 <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

21:29 <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)

21:31 <JamesMunns[m]> JomerDev[m]: Do you have a hand written isr, or using built in async things?

21:32 <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

21:32 <JamesMunns[m]> JamesMunns[m]: 250 cycles per clock is too short to do async response imo, could work with isr

21:33 <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

21:34 <JamesMunns[m]> JamesMunns[m]: Even just for triggering pio start, it could need to be isr directly triggering pio

21:35 <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

21:36 <JomerDev[m]> JamesMunns[m]: Ah sorry, ISR meaning what in that context? I was thinking of the Input Shift Register in the pio

21:37 <JomerDev[m]> Doh, interrupts

21:37 <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.

21:37 <JamesMunns[m]> I'd expect a hundred or more cycles to context switch.

21:37 <JamesMunns[m]> * (ISR) functions you could hit 1mhz pretty well. Not

21:39 <JamesMunns[m]> If you're doing... (full message at <https://catircservices.org/_matrix/media/v3/download/catircservices.org/DfXDPsmNWJTHrKmkVnzHNvKN>)

21:39 <JomerDev[m]> The actual loop is currently... (full message at <https://catircservices.org/_matrix/media/v3/download/catircservices.org/jWeDdkyKTzYKsVsgQxOAJbVd>)

21:40 <JomerDev[m]> JamesMunns[m]: > <@jamesmunns:beeper.com> If you're doing... (full message at <https://catircservices.org/_matrix/media/v3/download/catircservices.org/BjrcPVgjxcDQtogyCpIkWaHy>)

21:41 <vollbrecht[m]> how many registers does the rp need to save on a context switch into a ISR?

21:42 <JamesMunns[m]> vollbrecht[m]: Cortex m has a pretty low guaranteed ist response delay. Like <20 cycles including stacking iirc

21:42 <JamesMunns[m]> s/ist/isr/

21:50 <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

21:54 <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

22:38 <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

22:38 <JamesMunns[m]> (there are ways to make it work, but like in general without explicit care)

22:39 <JamesMunns[m]> (for async)

22:40 <JamesMunns[m]> Maybe the not empty trick was the important part tho!

22:40 <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

23:14 <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>)

23:15 <M9names[m]> and then the pac docs would have told you what they do:

23:29 <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