01:20 <M762spr[m]> Are there any bluetooth A2DP/AVRCP projects in rust? I was just thinking about rebooting an old project and replacing the bluetooth audio module with either a STM23WB or ESP32 variant, but on a quick search I didn't see any examples (or bluetooth examples at all...)

04:46 <ivmarkov[m]> <M762spr[m]> "Are there any bluetooth A2DP/..." <- A2dp and avrcp works as long as you use the stock ESP32 chip (not the later s or c variants), _and_ the `esp-idf-*` crates.

04:48 <ivmarkov[m]> ivmarkov[m]: There is no good examples in the `esp-idf-svc` repository yet, you need to extract the a2dp/avrcp and i2s processing code from e.g. here: https://github.com/ivmarkov/fiat-a2dp

04:48 <ivmarkov[m]> s/is/are/

05:25 <M762spr[m]> <ivmarkov[m]> "There is no good examples in the..." <- thanks for the info. hmm, not being one of the newer chips is a bit of a deal breaker though. Is it just something that hasn't been developed yet?

06:22 <thejpster[m]1> -Csoft-float is for the chop: https://github.com/rust-lang/compiler-team/issues/779

08:53 <ivmarkov[m]> <M762spr[m]> "thanks for the info. hmm, not..." <- Why is this a deal breaker? The stock esp32 is still in production.

08:54 <ivmarkov[m]> ivmarkov[m]: The other chips simply don't have the full BT stack. Only BLE. The stock esp32 has both, but does not have the more recent BLE versions (BLE5 and problably the latest versiobs of BLE4.x)

08:54 <ivmarkov[m]> ivmarkov[m]: You can't do audio with BLE. The audio over BLE standard is brand new, and I don't think anybody supports it yet. Including Espressif themselves.

08:55 <ivmarkov[m]> s/versiobs/versions/

08:55 <ivmarkov[m]> ivmarkov[m]: (Let alone the hardware stuff you probably want to sink into the esp32 sink)

08:56 <lulf[m]> ivmarkov[m]: Android and iOS does support LE audio

08:57 <ivmarkov[m]> lulf[m]: Nice! But I'm saure other than that, my BT devices don't. As in my Denon, the TVs, Google Home Gen 2 etc. etc.

08:57 <ivmarkov[m]> ivmarkov[m]: But nice tio hear that it is developing

08:57 <ivmarkov[m]> s/saure/sure/

08:57 <ivmarkov[m]> s/tio/to/

08:58 <lulf[m]> ivmarkov[m]: Yeah, my 2010 car also does not support it :D

08:58 <diondokter[m]> lulf[m]: Oohhh 2010 car gang!

08:58 <ivmarkov[m]> lulf[m]: My two cars (2010 and 2012) neither. Guess it is time to update the cars with newer ones? :D

08:59 <ivmarkov[m]> ivmarkov[m]: https://github.com/espressif/esp-idf/issues/12277 - this is the status quo for Espressif. No audio on BLE.

08:59 <lulf[m]> ivmarkov[m]: I guess so, but it just won't stop working (knock on wood)

08:59 <ivmarkov[m]> lulf[m]: Mine break, but I love them. Esp. the dirty diesel A6 biturbo.

09:00 <ivmarkov[m]> ivmarkov[m]: So I post-pone updating. also cars are a bad investment. In fact, not investment at all of course.

09:00 <lulf[m]> ivmarkov[m]: But iirc LE audio has been out since 2020, so I think it should be fairly common soon-ish (hard to predict really, but things like nrf52 does support it)

09:01 <lulf[m]> * support it, but they recommend nrf53)

09:01 <ivmarkov[m]> lulf[m]: I see. Well, judging by the replies in that Espressif issue, no LE audio with esp32* anytime soon.

09:01 <ivmarkov[m]> ivmarkov[m]: (the c6 is the newest chip, except p4 which is still in pre-rpduction, and does not have a radio anyway)

09:02 <lulf[m]> ivmarkov[m]: Yeah, I dunno how much is hardware-dependent or not. I think the 'foundation' is that the controller must support isochronous channels

09:02 <ivmarkov[m]> ivmarkov[m]: Ah, I was wrong. The h4 does it! Did not even realize, such a thing exists!

09:02 <vollbrecht[m]> ivmarkov[m]: from press material it seams the esp32-h4 is the target will introduce LE audio

09:02 <vollbrecht[m]> * the target that will introduce

09:04 <vollbrecht[m]> vollbrecht[m]: though its funny in a way since the h4 is i think not that powerfull compared to the c6 ...

09:04 <ivmarkov[m]> vollbrecht[m]: it does not have a wifi/thread radio either, so you need to couple it with another mcu, or with ethernet adaptor...

09:04 <vollbrecht[m]> ivmarkov[m]: it has thread . just no wifi.

09:05 <ivmarkov[m]> vollbrecht[m]: and it is brand new (04.2024) i doubt it is supported - even by the esp idf - yet

09:05 <vollbrecht[m]> ivmarkov[m]: but its a dual core

09:05 <vollbrecht[m]> * dual core just with lower clock speeds

09:05 <ivmarkov[m]> vollbrecht[m]: You are right. So in fact more powerful than c6 except clock speeds

09:06 <vollbrecht[m]> ivmarkov[m]: yeah h4 isn't even listen in the public compatibility list, we will first get the c5 :D

09:07 <ivmarkov[m]> vollbrecht[m]: Anyway, to summarize the topic for the poster - realistically, and as of now, I still think his only chance of audio over BT (and in fact, he explicitly asked for a2dp, not just any BT audio) is the stock esp32 (that is, with Espressif MCUs)

09:07 <ivmarkov[m]> ivmarkov[m]: And with ESP-IDF at the bottom of the stack :(

13:49 <thejpster[m]> Question: why isn’t there a libstd for newlib? It could set up an allocator using malloc (and sbrk), and send println to file descriptor to 1.

13:50 <thejpster[m]> A bit more opinionated than just using libcore.

13:50 <thejpster[m]> The thread and process APIs can just return an error like on WASM.

13:51 <mabez[m]> thejpster[m]: That's exactly what the esp-idf std impl does, the problem is that most hal vendors don't implement enough of newlib to actually build std on top of it

13:51 <mabez[m]> Even in esp-idf, which had pretty good coverage still needed additional features added to fully support (the parts that's possible to support) the standard library

13:52 <mabez[m]> On top of that, for every C toolchain, you'll have various typedefs that won't be uniform across all platforms, so it becomes very hard create a newlib generic target

13:54 <mabez[m]> You might be interested in ivmarkov's PR that added esp-idf support (based on newlib) to see what goes into it: https://github.com/rust-lang/rust/pull/87666. Note that this doesn't include the libc changes (which actually we still don't have fully correct, but it's being worked on)

13:55 <Kaspar[m]> Hey all! I'm playint with the rpi-pico2. I can flash the embassy examples just fine, but somehow my own .elf are rejected by picotool with ERROR: 'path/to/foo.elf' failed validation - Unrecognized ABI. they are compiled for the right target ... anyone here that has seen this before?

13:55 <Kaspar[m]> s/playint/playing/, s//`/, s/./`./

13:55 <mabez[m]> TL;DR: it's completely possible, just a maintenance nightmare because of various C toolchain design choices, like the fact that no one can agree on the size of a primitive :D

13:56 <mabez[m]> * a primitive type :D

13:56 <ivmarkov[m]> ESP-IDF's newlib-based impl is really libstd + FreeRTOS's Posix Thread API (OK, actually ESP-IDF's home-grown one, but that does not matter) + LwIP's BSD Sockets API. Whether it would be possible to model only the "newlib" aspect in a vendor-independent way... not sure, for the same reason Mabez outlined... Even some pure "libstd" notions, like various handle types seem to vary from vendor to vandor w.r.t. size.

13:56 <ivmarkov[m]> s//`/, s//`/, s/vandor/vendor/

13:56 <ivmarkov[m]> * ESP-IDF's newlib-based impl is really libstd + FreeRTOS's Posix Thread API (OK, actually ESP-IDF's home-grown one, but that does not matter) + LwIP's BSD Sockets API. Whether it would be possible to model only the "newlib" aspect in a vendor-independent way... not sure, for the same reason Mabez outlined... Even some pure "newlib" notions, like various handle types seem to vary from vendor to vendor w.r.t. size.

13:56 <ivmarkov[m]> s/libstd/`newlib`/, s/libstd/newlib/, s/vandor/vendor/

14:05 <JamesMunns[m]> Btw, the survey has now closed! I have the results, we'll need some time to go through a lot of the free responses

14:36 <Kaspar[m]> <Kaspar[m]> "Hey all! I'm playint with the..." <- So I tracked this through the picotool sources. Somehow one cargo built binary has the OS/ABI field set to `UNIX - GNU', whereas the other is `GNU - System V`. Fixing that bit in the .elf makes picotool flash my binary ... But why could there be a difference?

14:36 <JamesMunns[m]> btw Kaspar, remind me to point you at the OxidOS people, they mentioned having some interest in doing "embassy on top of an RTOS", and I know y'all have been hacking on that

14:37 <JamesMunns[m]> lemme send you a DM, talked to them at RustConf :)

14:38 <Kaspar[m]> JamesMunns[m]: any time! 🙂

16:50 <M762spr[m]> ah ok. Thanks for going over all that while I was sleeping! 😁

16:50 <M762spr[m]> I really appreciate the explanation I don't use esp32 that much and didn't realize that they did away with the full bluetooth implementation. Come to think of it, the stm32wb must only have BLE too, I've only messed with the WL ones.

16:50 <M762spr[m]> I may try with the vanilla esp32, I think I have a few old dev boards from the arduino days laying around if they haven't all been salvaged for wled projects 😅

17:07 <M762spr[m]> <M762spr[m]> "ah ok. Thanks for going over all..." <- oh! I have a handful of pico chips I suppose I could use 🤔

19:24 <s1syph0s[m]> Hey, I'm currently learning about interrupts through the nrf52840 hal (and pac) crate, and I'm trying to look for a method to disable interrupt. i can only find it in the cortex_m crate, and i'm now pretty confused with the roles of these crates. from the discovery book, i've learnt about the pac, hal, and bsp terminology, to which one does cortex_m belong? and why can't disable interrupt be found in pac?

19:25 <JamesMunns[m]> cortex-m is like a pac for the common parts that every cortex-m core has

19:25 <JamesMunns[m]> that includes the NVIC, which controls interrupts

19:28 <s1syph0s[m]> ahh i see

19:28 <s1syph0s[m]> is NVIC the same as an interrupt vector table or is it another component?

19:30 <JamesMunns[m]> NVIC is the interrupt controller, it dispatches to the vector table functions when they occur

19:30 <JamesMunns[m]> (NVIC -> Nested Vectored Interrupt Controller)

19:31 <JamesMunns[m]> Since all cortex m chips have roughly the same interrupt controller (there are slight differences between M0/M0+, M3, M4, M7, etc), we put that in one crate so all the pacs didn't have to repeat the same code

19:32 <JamesMunns[m]> in most cases, you'd probably use the critical-section crate to disable interrupts, as that is also portable to different architectures and chips.

19:33 <JamesMunns[m]> though you can directly disable them from the cortex-m crate, as well.

19:34 <s1syph0s[m]> thanks for the answers!

20:56 <Kaspar[m]> <Kaspar[m]> "So I tracked this through the..." <- Still no idea why this is an issue, maybe picotool is just too strict. Anyhow, this one-liner fixes an elf for picotool consumption using just shell and xxd: `echo 00000007: 00 | xxd -r -c 1 - file.elf`

21:08 <JamesMunns[m]> <Kaspar[m]> "Still no idea why this is an..." <- What are you linking with?