07:20 <GuineaWheek[m]> i found out the hard way that if you take a pointer of a static/const field and reference it in copy_nonoverlapping even through a u32 conversion the compiler may elide the read to whatever you defined the constant/static field to be

07:20 <GuineaWheek[m]> i was using sections to define fields i would init to as [0xff; _] in flash so i could overwrite them at runtime as pseudo-efuses

07:21 <GuineaWheek[m]> wish there was a dynamically sized version of read_volatile

07:30 <Lumpio-> Making one by using a loop probably results in very similar code

08:21 <Socke> how do I correctly use the esp32 ADC? in the IDF documentation I read that the internal reference is about 1100 mV. but in my experiments, the ADC raw output peaked at 3839 on roughly 850 mV. is my esp broken? Am I doing something wrong? I would assume I could at least get 4095 out of the ADC

08:25 <Socke> I am applying the voltage directly to the pin from my lab PSU and double-checking it with a DMM. there is also a small capacitor (few nF) directly attached to the pin. once I max out the ADC, the reading is stable at 3839

08:26 <Socke> wtf. I restarted the ESP and now I am getting correct values o.O

08:26 <Socke> "correct" in the sense that it now maxes out at 4095

08:32 <Socke> is there a rate limit to read_raw()? I have the following procedure to slightly reduce noise: read 16 samples in a loop, then average over those. If I log all the "sub-samples" using info!(), then I can correctly read 4095. If I comment out the logging, I only get 3839 o.O

08:34 <Socke> interesting. If I replace the info!() call with a small 10ms sleep, I also get the correct 4095

08:34 <Socke> so there certainly is a limit...

08:35 <ryan-summers[m]> Check what read_raw() is actually doing. It very well might just be reading the ADC result register, which is not sufficient to guarantee a sample is acquired

08:36 <ryan-summers[m]> For an ADC, you need to respect the sample & hold setup time and then the acquisition time before the result is placed in the output regs. You also generally have to initiate the conversion. Is `read_raw()` doing all of that properly?

08:42 <Socke> it get's even weirder. if I log the sub samples array AFTER collection, I get correct results. but when I don't log it AFTER collection, I get broken results. is this some kind of miscompilation? o.O

08:43 <Socke> I just checked the binary repr of 3839: looks like there is one bit flipped: 0b111011111111

08:43 <ryan-summers[m]> I would say it's much more likely to be the different delays imposed when you introduce logging personally.

08:43 <Socke> ryan-summers[m]: there is zero timing difference during sample collection

08:44 <ryan-summers[m]> I'm just saying, the number of times its a compiler bug vs an implementation bug has been near 99% implementation from past experience, so try digging there first

08:44 <ryan-summers[m]> It sounds to me like the ADC timing requirements aren't being respected

08:45 <Socke> this is the code: https://pastebin.com/JFg96QCf

08:46 <Socke> all 3 measures (sleep, logging each sub-sample individually, logging whole array) solve the problem

08:46 <ryan-summers[m]> The ESP examples don't use read_raw, so why are you? https://github.com/esp-rs/esp-idf-hal/blob/master/examples/adc.rs

08:47 <Socke> this whole code is being run in a loop with a thread::sleep(1s) call

08:47 <Socke> ryan-summers[m]: I haven't found that example, will check it out. I used read_raw since read() returned some "garbage" value (probably converted to mV)

08:48 <Socke> okay, example is weird: they're using ADC2 on esp32, but I read that ADC2 on esp32 does not work while wifi is on...

08:57 <Socke> ryan-summers[m]: I would btw expect that the esp idf does all the required timing, especially in oneshot mode

09:00 <Socke> okay, I set calibration to true in the adc config and now the samples come out fine even without any extra sleeping or logging

09:06 <ryan-summers[m]> Glad to hear you got it working. Might be worth opening a Github issue around this. If the calibration is that necessary, maybe it should be the default state

09:06 <Socke> okay, this drives me crazy. this is not repeatable -.-

09:06 <Socke> I'll try a different esp

09:07 <ryan-summers[m]> Is your PSU reliably hooked up? Is it possible there is some kind of intermittent connection (i.e. broken jumper wire, marginal contact, etc)?

09:16 <Socke> PSU is fine, already checked all the connections

09:16 <Socke> I guess if the PSU/connection would be the issue, I would see more random readings and not just consistently one bit being 0

09:21 <Socke> I switched to read(): that gives me reliable values that are actually accurate to +-3mV. maybe I'll use that API instead

09:23 <Socke> it's stupid because I want to attach a voltage divider to the input in order to measure slightly higher voltages... so doing the calculations myself would probably be a little more accurate. but on the other hand read() hopefully solves all the nonlinearity issues as well

09:23 <Socke> and since read_raw() seems to be broken for me, I have no choice anyways

09:33 <Socke> okay, tried another esp32c3. same behaviour with read_raw. I think that function is just broken currently

09:36 <Socke> which is surprising, since the code for read() just calls read_raw() and then raw_to_cal() o.O

09:54 <ryan-summers[m]> Definitely open a GH issue. It might be related to timing where it sometimes works and sometimes doesn't, but the read function happens to have timing tha tworks

09:54 <ryan-summers[m]> s/tha/that/, s/tworks/works/

10:00 <Socke> will do

11:18 <zeenix[m]> How do you folks usually get around serde traits not being implemented for alloc types?

11:18 <JamesMunns[m]> zeenix[m]: they are, if you enable the alloc feature of serde

11:19 <zeenix[m]> ah :)

11:19 <ryan-summers[m]> If you have other issues not related to that, you can always do a custom serde impl using newtypes / wrappers

11:19 <JamesMunns[m]> (postcard also has an alloc feature, for the record)

11:31 <zeenix[m]> James Munns: nice! I can then drop my custom schema impl

11:32 <zeenix[m]> <ryan-summers[m]> "If you have other issues not..." <- yeah, just that Deserialize isn't always easy/simple to impl

11:34 <zeenix[m]> James Munns: couldn't be too lucky :)... (full message at <https://catircservices.org/_matrix/media/v3/download/catircservices.org/geHaSWtMNMTIysFzfTJkasHx>)

11:36 <zeenix[m]> seems postcard is missing #[cfg(target_has_atomic = "ptr")]

11:36 <zeenix[m]> according to: https://doc.rust-lang.org/stable/alloc/sync/index.html

13:55 <flippette[m]> Hi, I have some buttons wired to GPIO pins on a Pi Pico, and I want to use an interrupt to read button presses and update an atomic variable. From the docs I think I'm supposed to use IO_IRQ_BANK0 from rp2040-pac, but how can I get more information about the pin that triggered the interrupt?

13:57 <JamesMunns[m]> flippette[m]: Here's how the embassy ISR handler works for that: https://github.com/embassy-rs/embassy/blob/03b8e36532427377aa01ea7dedaa97a9540e7d26/embassy-rp/src/gpio.rs#L212-L243

14:19 <zeenix[m]> James Munns: finally figured out why my events were not getting received on the host side 😢 https://github.com/jamesmunns/postcard-rpc/blob/main/source/postcard-rpc/src/host_client/raw_nusb.rs#L19

14:20 <JamesMunns[m]> zeenix[m]: https://github.com/jamesmunns/postcard-rpc/blob/main/source/postcard-rpc/src/host_client/raw_nusb.rs#L12

14:20 <JamesMunns[m]> We're your ERRORS larger than that as well?

14:22 <zeenix[m]> James Munns: errors?

14:22 <JamesMunns[m]> zeenix[m]: Ohh I get it

14:22 <zeenix[m]> James Munns: it's whole message that's larger than that in serialized format

14:22 <JamesMunns[m]> zeenix[m]: The ok response WAS being sent, but the host dropped it

14:22 <JamesMunns[m]> JamesMunns[m]: Before you were troubleshooting never getting an error message

14:24 <zeenix[m]> James Munns: oh I'm not sure if this related to the "endpoint silently dropped" issue I'm also having (haven't checked yet) but right now I'm looking at event being successfully sent from the firmware but not getting received on the other side. It works if the size is lower than 1k

14:24 <JamesMunns[m]> Yep, that is expected then, I didn't realize how large the message actually was

14:25 <GeorgesP[m]> Hello, I am writing a no_std no_alloc (using heapless) protocol client driver based on embedded-io-async::Read+Write, but the server along responding to requests can also asynchronously send some notification (JSON RPC based). So the client need to be continuously read() for some data from the TCPStream. The target for the crate is to be used on embassy, but I would prefer not depending on embassy directly so I can also have a

14:25 <GeorgesP[m]> tokio implementation on host. My first solution was to use tokio::io::split() to separate the Sender and the Receiver (because many embassy hal provide it too) so I can have a ClientRx in a task doing continuous read().await, but it require a lot of heapless::spsc::Queue to transmit information between ClientRx and ClientTx... Is there a way to share a single Client resource without depending on embassy or other executor, and

14:25 <GeorgesP[m]> staying no-alloc ? Thx

14:46 <Socke> not sure if that is what you want but you could try wrapping your TcpStream in an Arc

14:48 <Socke> (you need to find a no-alloc Arc though...)

14:57 <GeorgesP[m]> I saw heapless::pool::Arc but it is for arm_llsc and x86, and my final target will be ESP32S3...

15:12 <zeenix[m]> James Munns: "endpoint methods just hanging on the host-side and not getting received on the firmware" issue seems unrelated so far in my testing.

15:41 <GeorgesP[m]> embassy-net ::tcp::TcpSocket is using core::cell::RefCell... Maybe I should get inspired... (Sorry to expose my skill issue here, I am still learning)

19:54 <diondokter[m]> Hey all! Could use some input here.... (full message at <https://catircservices.org/_matrix/media/v3/download/catircservices.org/NUXDarXryJzwOTlqqeiEYLje>)

19:55 <diondokter[m]> It's funny because the implementation is trivial. The naming, omg, so much harder!

19:56 <diondokter[m]> * Hey all! Could use some input here.... (full message at <https://catircservices.org/_matrix/media/v3/download/catircservices.org/OWyHNduIlTGgySoZbYBNEJxs>)

19:56 <K900> That just sounds wrong?

19:56 <K900> Like, how would you distinguish 1,2,3 and 1,2,4

19:56 <K900> * and 1,2,[3 skipped]4

19:57 <diondokter[m]> I agree, but you know... It's what his hardware speaks.

19:57 <diondokter[m]> I believe it's mostly for the last parameter

19:57 <diondokter[m]> And if it's really cursed it could see it from the int vs string types

19:57 <diondokter[m]> * last parameter(s)

19:57 <K900> Well maybe they just need to change the command schema then

19:57 <K900> So instead of (one, two, three, four) it's just (one, two, four)

19:59 <diondokter[m]> Well yeah, but the builder is itself a builder pattern. So that'd be annoying at least

20:00 <diondokter[m]> Although, maybe it's doable with the builder itself. Of course it doesn't have to be all a one liner

20:00 <K900> I'm not sure what the API looks like tbh so it's hard for me to tell

20:01 <diondokter[m]> https://github.com/diondokter/at-commands/issues/11

20:01 <diondokter[m]> He posts an example

20:02 <K900> Oh wait

20:02 <K900> I thought you had hardcoded schemas

20:03 <K900> For commands

20:03 <diondokter[m]> Really depends on the hardware you're talking to

20:03 <K900> And I think the example might only make sense for _trailing_ commas?

20:03 <diondokter[m]> I think so yeah

20:03 <K900> diondokter[m]: Yeah but I was thinking of type level serde kind of stuff

20:03 <K900> But this is not that

20:04 <diondokter[m]> Ah, I think you're thinking about the atat crate

20:04 <K900> Yep

20:04 <K900> That's the one

20:04 <K900> And now I realize it's not the same one

20:04 <K900> I wonder if you can just have a method to strip trailing commas

20:05 <diondokter[m]> Yeah, that's way more elaborate. Idk what's better. but it's good to have the choice

20:05 <K900> And have that cover the use case

20:05 <diondokter[m]> Sure, but that'd feel wrong haha

20:06 <K900> I actually kinda like it

20:07 <K900> Because it's really (presumably) a property of the dialect

20:07 <K900> At least I'd like to think it is until someone finds a sufficiently cursed device

20:07 <diondokter[m]> Maybe? Idk... It's good to mention in the issue at least for consideration

20:10 <dirbaio[m]> `with_optional_string_parameter` -> `with_optionaler_string_parameter`

20:10 <dirbaio[m]> leaves room for future with_optionalest_string_parameter :D

20:10 <diondokter[m]> dirbaio[m]: :P

20:10 <diondokter[m]> Yes, room for api evolution!

20:15 <diondokter[m]> Hmmm, this is thoroughly meh, but I get to be lazy and not have make a new release for the crate:... (full message at <https://catircservices.org/_matrix/media/v3/download/catircservices.org/hqepBwjxHlNGwodFqgnfkdOS>)

20:15 <diondokter[m]> * Hmmm, this is thoroughly meh, but I get to be lazy and not have make a new release for the crate:... (full message at <https://catircservices.org/_matrix/media/v3/download/catircservices.org/DKkvtQLaaynvaWqtRAZpNbdW>)

20:27 <Dherse[m]> Hello friends, anybody's got any idea why an STM32 would hang at any memory write after enabling the D-Cache?

20:29 <diondokter[m]> Dherse[m]: ***Any*** memory write?

20:29 <FreeKill[m]> Don't you need to configure the mpu sections if you have the d cache enabled?

21:04 <balbi[m]> <diondokter[m]> "Hmmm, this is thoroughly meh..." <- > <@diondokter:matrix.org> Hmmm, this is thoroughly meh, but I get to be lazy and not have make a new release for the crate:... (full message at <https://catircservices.org/_matrix/media/v3/download/catircservices.org/AYOSGdNbLbcHvVxzFbZBZGCe>)

21:05 <Dherse[m]> <FreeKill[m]> "Don't you need to configure..." <- Trust me, I am trying to :sob:

21:09 <Dherse[m]> Okay, I managed to configure my MPU enough that it doesn't instantly hang, but I'm hitting the following problem: instead it hangs as soon as I try a DMA operation