03:21 <gussius[m]> Hi All, I get a linker error when I define an #[exception] for Systick in a submodule of my project. The specific error is a duplicate symbol error. I presume that the default linker script (whereever that is) sets up the Systick exception if there is none defined in the root module. Any thoughts?

04:27 <PeterHansen[m]> I just migrated my [patch.crates-io] from embassy at 8a811cf (~July 9) to the one latest nrf-softdevice wants (ce66276) and it appears to be breaking something fundamental. I have a task which is calling sig.signal() and that's now blocking... and kills the entire executor, and in fact appears to stall everything including a high priority executor, so presumably is locking a critical section indefinitely somehow. Anyone

04:27 <PeterHansen[m]> else using latest nrf-softdevice and maybe saw similar issues?

05:05 <PeterHansen[m]> Whoa, looks like it's probably nightly-2023-08-19 at fault, compared to nightly-2023-06-28 which was working fine. Even when I reverted nrf-softdevice and embassy back to my earlier ones but left the rust version at 08-19 it was failing. Changing that back to 06-28 makes it work again. I'll have to wait till the morning to try leaving it at 06-28 but updating nrf-softdevice and embassy again, to make sure that combo works,

05:05 <PeterHansen[m]> as I'm almost falling out of my chair after a long evening troubleshooting this.

05:13 <PeterHansen[m]> 08-01 works, 08-15 fails (and so does 09-20)

05:24 <PeterHansen[m]> 08-08 works, 08-11 fails, 08-10 fails, 08-09 fails, and 08-08 still works after. I note there's a somewhat large change in code size across that transition, with my text size dropping from 202004 to 200580 (release mode). May be a hint that something major got changed in 08-09 nightly.

05:33 <PeterHansen[m]> Okay, I can't stop kicking a problem like this, so have also confirmed latest nrf-softdevice and its favored embassy version do in fact work fine with my code, provided I'm not using nightly beyond 08-08. And now going to bed...

06:37 <xiretza[cis]> if you have the time, please do a `cargo bisect-rustc`: https://github.com/rust-lang/cargo-bisect-rustc

09:00 <ryan-summers[m]> <dirbaio[m]> "setting up a bot to randomly..." <- thejpster: As a fellow R-E-C guy, feel free to ping me randomly. I try to take time out of my working day for open-sourced stuff, although I do get randomly busy. I would be perfectly fine with a bot randomly assigning me, as long a sit's not excessive

09:01 <ryan-summers[m]> <ninjasource[m]> "Hi guys, has anyone here used..." <- I wrote the QSPI driver for the STM32H7 HAL originally just as a 4-channel SPI, but it supports memory mapping external flash too. I don't know if it's been implemented yet, but this is very possible

09:37 <diondokter[m]> Wait, I'm trying to get `defmt` timestamps in my logs.

09:37 <diondokter[m]> I thought the only thing I had to do was to add the `defmt::timestamp!` macro.

09:37 <diondokter[m]> But I still get no timestamps and I get a warning from probe-run `WARN `defmt::timestamp!` implementation was found, but timestamp is not part of the log format; consider adding the timestamp `{t}` argument to the log format`

09:37 <diondokter[m]> * Wait, I'm trying to get `defmt` timestamps in my logs.

09:37 <diondokter[m]> I thought the only thing I had to do was to add the `defmt::timestamp!` macro.

09:37 <diondokter[m]> But I still get no timestamps and I get a warning from probe-run `WARN ```defmt::timestamp!`implementation was found, but timestamp is not part of the log format; consider adding the timestamp`{t}` argument to the log format```

09:37 <diondokter[m]> * Wait, I'm trying to get `defmt` timestamps in my logs.... (full message at <https://catircservices.org/_matrix/media/v3/download/catircservices.org/uaNkqMbVnNQnOMgDJdNcbuhD>)

09:38 <diondokter[m]> How or where do I set the log format?

09:40 <diondokter[m]> Oh, this is new apparently? https://github.com/knurling-rs/probe-run/pull/416

09:54 <diondokter[m]> Ok, this is all extremely inconvenient. Downgrading to 0.3.9 did the trick 😇

10:03 <thejpster[m]> would you mind opening a ticket for that? I can't immediately work out what is going wrong there.

10:54 <diondokter[m]> <thejpster[m]> "would you mind opening a..." <- There's already an open ticket for it: https://github.com/knurling-rs/probe-run/issues/421

13:13 <Farooq> There is another idea which is hanging for long in my mind. I am thinking of an e-paper pocket device for browsing web. But I don't think an MCU can handle the Web.

13:13 <Farooq> The thing is that, most ebook readers are not pocket ones. They are at least 6 inch

13:14 <Lumpio-> fwiw my phone is bigger than that

13:14 <Farooq> Well my phone is not. I do not like big phones. plus your phone is probably tall and fits in your pocket but ebook readers are more square like

13:15 <Lumpio-> Offload handling the entire web to the cloud

13:15 <Lumpio-> And have it render a "reading mode" page for your e-paper reader

13:16 <Lumpio-> Using a desktop website as-is on such a tiny screen would probably be a bit unusable anyways so some reformatting would be required anyways

13:16 <Darius> Farooq: my kobo can browse the web but the experience isn't fantastic

13:16 <Darius> works well enough for static stuff like wikipedia though

13:17 <Farooq> I've got a BOOX Leaf with Android and octa core qualcomm and works fantastic for web

13:18 <Farooq> I sometimes connect BT keyboard and do stuff on it with Termux. I wish there was a colour version. But a super cheap epaper tiny device could be interesting. With open firmware of course. Otherwise there are already several of these but with no good software support.

14:24 <PeterHansen[m]> <xiretza[cis]> "if you have the time, please..." <- I'm guessing that would require a test which can automatically identify whether there's a failure or not. If so, I'm not sure how feasible it would be to run this with code that only fails on actual embedded hardware (with cortex-m4 and embassy-nrf) and not with e.g. embassy-std on the host.

14:27 <dirbaio[m]> you can supply a custom script https://rust-lang.github.io/cargo-bisect-rustc/tutorial.html#testing-with-a-script

14:27 <dirbaio[m]> if you can't script it you can tell it to prompt you https://rust-lang.github.io/cargo-bisect-rustc/tutorial.html#testing-interactively

14:33 <PeterHansen[m]> Pretty sure I won't have time to invest in doing that in the near future, but checking dates on major things listed in the 1.73.0 release notes, and the dates of the merge, it looks like possibly it was either of these:... (full message at <https://catircservices.org/_matrix/media/v3/download/catircservices.org/qNABnQcwgOPIiOIKIeUIoiqR>)

14:35 <PeterHansen[m]> "abi_thiscall" appears maybe to be Windows only, so if true it can't be that.

14:36 <PeterHansen[m]> And given the noticeable size change in the generated code, the idea it could be related to an LLVM change makes sense to me.

14:36 <PeterHansen[m]> Unless it gets in my face again, I'm afraid I'll have to leave it for at least a week or two as I'm under some time pressure to get some stuff released.

14:46 <mburton[m]> Hey folks, I'm interested in helping to get the linux-embeddedd-hal crate rev'd up to depend on embedded-hal rc1. I noticed [this](https://github.com/rust-embedded/linux-embedded-hal/pull/94) PR up to update to alpha.11, is the plan to cut a alpha release of linux-embedded-hal off of that, or continue w/ another uprev to get to rc1? Whats the best place to look for remaining tasks?

14:56 <dirbaio[m]> (not a l-e-h maintainer myself but) probably the best is to skip alpha.11 and go for rc.1

14:59 <davidtwco[m]> 👋hello embedded people, co-lead of the rust compiler team here: the compiler team are doing a review of all the targets we support to make sure they comply with the project's target tier policy and that we've got target maintainers for every target - lots of our targets predate the policy and were missing all the relevant documentation. many of our targets are of specific interest to embedded folks, so if there are any targets

14:59 <davidtwco[m]> that you are interested in, please help us out - [#116004](https://github.com/rust-lang/rust/pull/116004) - thanks!

15:02 <eldruin[m]> <mburton[m]> "Hey folks, I'm interested in..." <- rc.1 is mostly alpha.11 without serial traits so my plan would be to accept that PR once CI is fixed and then migrate to rc.1. Then do a new l-e-h release since migrating to rc.1 is probably quick to do

15:07 <mburton[m]> <eldruin[m]> "rc.1 is mostly alpha.11 without..." <- Makes sense! After the migration to rc.1 does that warrant tagging l-e-h 0.4.0, or are there other tasks that are planned? (like updating to gpiocdev etc.)

15:08 <eldruin[m]> yes, there are some pending tasks like updating nix, spidev, maybe i2cdev, etc.

15:10 <eldruin[m]> ideally we could implement embedded-io on serialport-rs and document in l-e-h that they can use serialport-rs directly

15:11 <eldruin[m]> that way we do not depend on e-io in l-e-h. but it is not like we can release l-e-h 1.0 soon due to the dependencies

15:12 <eldruin[m]> then there is the open question about switching the gpiocdev implementation. Maybe it would be for the best but someone needs to actually do the work and test that it works

15:29 <fuse117[m]> what is the general approach to troubleshooting errors like the following.... (full message at <https://catircservices.org/_matrix/media/v3/download/catircservices.org/dTfMlYMfSXRdDhsWWkTHPdiZ>)

15:38 <mburton[m]> <eldruin[m]> "that way we do not depend on e-..." <- Sounds good, I'll make some time to catch up on some of these dependency updates. Would it be reasonable to cut `l-e-h-alpha.4` w/ the update to rc.1?

15:56 <sirhcel[m]> <eldruin[m]> "ideally we could implement..." <- Adding opt-in support for embedded-io is on my list for serialport-rs. With an early adopter willing to do some testing, this could land in a couple of days.

16:19 <thejpster[m]> > what is the general approach to troubleshooting errors like the following.... (full message at <https://catircservices.org/_matrix/media/v3/download/catircservices.org/ZBBoWizjMScDxDBjyaEnkafU>)

16:19 <thejpster[m]> 4. Check you aren't using a chip where some ROM bootable disables the CoreSight module for security purposes. You could try attaching with the CPU held in reset.

17:08 <fuse117[m]> <thejpster[m]> "> what is the general approach..." <- > <@thejpster:matrix.org> > what is the general approach to troubleshooting errors like the following.... (full message at <https://catircservices.org/_matrix/media/v3/download/catircservices.org/AzOUweSyUUDTrZvJZuHSAxPQ>)

17:34 <thejpster[m]> I understand a little bit about the nrf9160 and I can’t immediately work out how that would be the case

18:20 <eldruin[m]> <mburton[m]> "Sounds good, I'll make some time..." <- Yes, once we have done the updates we should make a new release

18:24 <diondokter[m]> Oh yeah, probe rs on the nrf9160 sucks

18:24 <diondokter[m]> I don't know why though

20:49 <GrantM11235[m]> RIP to my stm32f103, I accidentally gave 12 volts to one of the gpio pins 😔

20:50 <adamgreig[m]> Oof

21:07 <firefrommoonligh> Did you get teh magic smoke?

21:10 <GrantM11235[m]> No. I only shorted it very briefly. I was hoping that it only caused a glitch or something, but I power cycled it and it still won't respond to the debug probe

21:29 <dalepsmith[m]> Yeah, they give you the silent treatment if they feel like they are being abused. And are completely unrepentant! They will never talk to you again

21:30 <dalepsmith[m]> No amount of coaxing will work. Not even mint ice cream.

21:45 <GrantM11235[m]> IT'S ALIVE! I had to cannibalize a bluepill