02:32 <therealprof[m]> <adinack[m]> "i have never used this platform..." <- I noticed the PRs, thanks for that, but I'm currently on business travel across the continents... I'll have a quick look now but not promises... Please ping me again in 8 days or so if no one else takes care of them in the meantime.

02:34 <adinack[m]> therealprof[m]: thank you, no rush, i just wanted to get my foot into this chat, enjoy the continents

02:50 <therealprof[m]> All good, I do need a reminder every now and then to not miss anything in the excessive GH spam.

02:50 <therealprof[m]> I left some comments.

04:10 <adinack[m]> thank you!

04:22 <vrakaslabs[m]> Alright, I've got a barebones Ethernet driver working on the Teensy 4.1: https://github.com/Timvrakas/rt1062-eth-rs

04:22 <vrakaslabs[m]> Is there any documentation on how to integrate new hardware with existing network stacks? I presume smoltcp is what I should be targeting?

04:24 <vrakaslabs[m]> * Alright, I've got a barebones Ethernet driver working on the Teensy 4.1: https://github.com/Timvrakas/rt1062-eth-rs/blob/master/src/main.rs

04:24 <vrakaslabs[m]> Is there any documentation on how to integrate new hardware with existing network stacks? I presume smoltcp is what I should be targeting?

06:35 <vrakaslabs[m]> <vrakaslabs[m]> "Alright, I've got a barebones..." <- At this point think I'm mostly unclear what an MVP setup of smoltcp looks like. I'm used to lwip with FreeRTOS, and in that setup I would aim for an ICMP demo as the proof of concept.

06:37 <vrakaslabs[m]> vrakaslabs[m]: For ICMP reply to work do I need need to call `iface.poll()` in a loop?

06:48 <vrakaslabs[m]> <vrakaslabs[m]> "For ICMP reply to work do I need..." <- Also I'm unclear if/how smoltcp handles interrupts from the Ethernet hardware, and what the timing looks like for RxTokens. Where in the process does the system wait until a packet is RXd?

06:49 <vrakaslabs[m]> vrakaslabs[m]: (I am very new to Rust, but I've written Ethernet drivers before, in C/++)

07:11 <vrakaslabs[m]> * ````fn... (full message at <https://catircservices.org/_matrix/media/v3/download/catircservices.org/MOySySdGjRzddiQordnRAJqd>)

07:12 <vrakaslabs[m]> * ````... (full message at <https://catircservices.org/_matrix/media/v3/download/catircservices.org/TmKywLfhqxGDRdHDPySEPdkS>)

08:46 <dirbaio[m]> <vrakaslabs[m]> "```fn consume<R, F>(mut self, f:..." <- > Is this meant to be blocking? That seems like it would prevent the poll() from returning,... (full message at <https://catircservices.org/_matrix/media/v3/download/catircservices.org/goqrONOzxEmoWqzLhAGZyvCc>)

08:48 <dirbaio[m]> dirbaio[m]: > Also I'm unclear if/how smoltcp handles interrupts from the Ethernet hardware,... (full message at <https://catircservices.org/_matrix/media/v3/download/catircservices.org/kWDDXdDoNSCUVRFLASSswgaE>)

08:50 <dirbaio[m]> dirbaio[m]: this is for raw smoltcp, which is more low-level, everything's based on manual polling so that it's agnostic to execution model (interrupts, tasks..)

08:52 <dirbaio[m]> dirbaio[m]: you might want to check out [embassy-net](https://crates.io/crates/embassy-net) for a higher-level alternative. it wraps `smoltcp` with `async`, so it's more similar to what you'd expect from a network stack in a C RTOS.

08:53 <dirbaio[m]> dirbaio[m]: so you spawn a backgournd task that handles the network stack, then you can await sending/receiving data on sockets from multiple of your tasks

08:54 <dirbaio[m]> > Also I'm unclear if/how smoltcp handles interrupts from the Ethernet hardware,... (full message at <https://catircservices.org/_matrix/media/v3/download/catircservices.org/YQOucCrMGHwOvrYRMGKOgNYC>)

16:57 <GeorgesP[m]> Hi, using serde-json-core, how to deserialize a JSON with an array of elements with different types like this one : "{["a string", 4]}" ? I use heapless::Vec for the array, but if I use enum to manage the different types, then serde-json-core expect b'"' or b'{' and return Error:: ExpectedSomeValue ... (no_std question)

18:16 <JamesMunns[m]> To support this, you would need something like serde json's Value type, and it would probably require a heap (in the general case). serde json core specifically doesn't support that.

18:24 <GeorgesP[m]> Is there a way with heapless or some alloc on stack ? (Would prefer get heap free)

20:45 <JamesMunns[m]> Not easily, the main issue is that a value can contain another value, so you have a recursive type.

20:45 <JamesMunns[m]> There are some different hacks you could use like limiting it to "a list of up to 20 items that can each be a number or a string of up to 10 characters", that could work with heapless, but there's not a general way to solve this afaik.

21:20 <vrakaslabs[m]> <dirbaio[m]> "so you spawn a backgournd task..." <- Thanks for the help, I’ll take a look tonight!

22:18 <ignormies[m]> Hey guys, I'm trying to switch my (stm32f411) program from `rtt_target` to `defmt` for my logging, but I'm encountering a weird issue.... (full message at <https://catircservices.org/_matrix/media/v3/download/catircservices.org/gHqDkEGjDQsOQgptPUldxOmV>)

22:38 <ignormies[m]> (I should clarify that `cargo run` resolves to `probe-run --chip STM32F411CEUx <my target>`)

23:32 <M9names[m]> Does your embed.toml specify that the RTT is defmt encoded?

23:39 <ignormies[m]> I'm not 100% sure -- this is what my `Embed.toml` looks like:... (full message at <https://catircservices.org/_matrix/media/v3/download/catircservices.org/GCoSvBkJdLabJMApCXlVEuDU>)

23:44 <Noah[m]> ignormies[m]: > <@ignormies:matrix.org> I'm not 100% sure -- this is what my `Embed.toml` looks like:... (full message at <https://catircservices.org/_matrix/media/v3/download/catircservices.org/bYLJYQrShSrkCvnsPDzUYKdK>)

23:45 <Noah[m]> channels = [{ up = 0, up_mode = "BlockIfFull", format = "Defmt" }] should do the trick

23:48 <ignormies[m]> Ah! Ok adding a channel with format = "Defmt" works! Thanks so much!