<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...)
rom4ik1 has quit [Quit: Ping timeout (120 seconds)]
rom4ik1 has joined #rust-embedded
kenny1 has quit [Ping timeout: 276 seconds]
kenny has joined #rust-embedded
kenny has quit [Ping timeout: 264 seconds]
kenny has joined #rust-embedded
kenny has quit [Ping timeout: 265 seconds]
kenny has joined #rust-embedded
sugoi has joined #rust-embedded
sugoi1 has joined #rust-embedded
sugoi has quit [Ping timeout: 246 seconds]
sugoi has joined #rust-embedded
sugoi1 has quit [Ping timeout: 245 seconds]
ivmarkov[m] has joined #rust-embedded
<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.
<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
<ivmarkov[m]>
s/is/are/
sugoi1 has joined #rust-embedded
sugoi has quit [Ping timeout: 265 seconds]
sugoi1 is now known as sugoi
<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?
<ivmarkov[m]>
<M762spr[m]> "thanks for the info. hmm, not..." <- Why is this a deal breaker? The stock esp32 is still in production.
<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)
<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.
<ivmarkov[m]>
s/versiobs/versions/
<ivmarkov[m]>
ivmarkov[m]: (Let alone the hardware stuff you probably want to sink into the esp32 sink)
lulf[m] has joined #rust-embedded
<lulf[m]>
ivmarkov[m]: Android and iOS does support LE audio
<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.
<ivmarkov[m]>
ivmarkov[m]: But nice tio hear that it is developing
<ivmarkov[m]>
s/saure/sure/
<ivmarkov[m]>
s/tio/to/
<lulf[m]>
ivmarkov[m]: Yeah, my 2010 car also does not support it :D
<diondokter[m]>
lulf[m]: Oohhh 2010 car gang!
<ivmarkov[m]>
lulf[m]: My two cars (2010 and 2012) neither. Guess it is time to update the cars with newer ones? :D
<lulf[m]>
ivmarkov[m]: I guess so, but it just won't stop working (knock on wood)
<ivmarkov[m]>
lulf[m]: Mine break, but I love them. Esp. the dirty diesel A6 biturbo.
<ivmarkov[m]>
ivmarkov[m]: So I post-pone updating. also cars are a bad investment. In fact, not investment at all of course.
<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)
<lulf[m]>
* support it, but they recommend nrf53)
<ivmarkov[m]>
lulf[m]: I see. Well, judging by the replies in that Espressif issue, no LE audio with esp32* anytime soon.
<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)
<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
<ivmarkov[m]>
ivmarkov[m]: Ah, I was wrong. The h4 does it! Did not even realize, such a thing exists!
vollbrecht[m] has joined #rust-embedded
<vollbrecht[m]>
ivmarkov[m]: from press material it seams the esp32-h4 is the target will introduce LE audio
<vollbrecht[m]>
* the target that will introduce
<vollbrecht[m]>
vollbrecht[m]: though its funny in a way since the h4 is i think not that powerfull compared to the c6 ...
<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...
<vollbrecht[m]>
ivmarkov[m]: it has thread . just no wifi.
<ivmarkov[m]>
vollbrecht[m]: and it is brand new (04.2024) i doubt it is supported - even by the esp idf - yet
<vollbrecht[m]>
ivmarkov[m]: but its a dual core
<vollbrecht[m]>
* dual core just with lower clock speeds
<ivmarkov[m]>
vollbrecht[m]: You are right. So in fact more powerful than c6 except clock speeds
<vollbrecht[m]>
ivmarkov[m]: yeah h4 isn't even listen in the public compatibility list, we will first get the c5 :D
<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)
<ivmarkov[m]>
ivmarkov[m]: And with ESP-IDF at the bottom of the stack :(
K900 has quit [Quit: Idle timeout reached: 172800s]
mameluc[m] has quit [Quit: Idle timeout reached: 172800s]
starblue1 has quit [Ping timeout: 265 seconds]
starblue1 has joined #rust-embedded
sugoi has joined #rust-embedded
sugoi has quit [Ping timeout: 265 seconds]
Beregond[m] has quit [Quit: Idle timeout reached: 172800s]
MathiasKoch[m] has quit [Quit: Idle timeout reached: 172800s]
dinkelhacker_ has joined #rust-embedded
diondokter[m] has quit [Quit: Bridge terminating on SIGTERM]
ryan-summers[m] has quit [Quit: Bridge terminating on SIGTERM]
_catircservices1 has quit [Quit: Bridge terminating on SIGTERM]
thalesfragoso[m] has quit [Quit: Bridge terminating on SIGTERM]
i509vcb[m] has quit [Quit: Bridge terminating on SIGTERM]
jonored[m] has quit [Quit: Bridge terminating on SIGTERM]
thejpster[m]1 has quit [Quit: Bridge terminating on SIGTERM]
Henk[m] has quit [Quit: Bridge terminating on SIGTERM]
ivmarkov[m] has quit [Quit: Bridge terminating on SIGTERM]
lulf[m] has quit [Quit: Bridge terminating on SIGTERM]
rmsyn[m] has quit [Quit: Bridge terminating on SIGTERM]
therealprof[m] has quit [Quit: Bridge terminating on SIGTERM]
romancardenas[m] has quit [Quit: Bridge terminating on SIGTERM]
AlexandrosLiarok has quit [Quit: Bridge terminating on SIGTERM]
dirbaio[m] has quit [Quit: Bridge terminating on SIGTERM]
alex[m]123 has quit [Quit: Bridge terminating on SIGTERM]
jannic[m] has quit [Quit: Bridge terminating on SIGTERM]
andar1an[m]1 has quit [Quit: Bridge terminating on SIGTERM]
korken89[m] has quit [Quit: Bridge terminating on SIGTERM]
JamesMunns[m] has quit [Quit: Bridge terminating on SIGTERM]
bartmassey[m] has quit [Quit: Bridge terminating on SIGTERM]
vollbrecht[m] has quit [Quit: Bridge terminating on SIGTERM]
M762spr[m] has quit [Quit: Bridge terminating on SIGTERM]
sourcebox[m] has quit [Quit: Bridge terminating on SIGTERM]
_catircservices has joined #rust-embedded
sugoi has joined #rust-embedded
sugoi has quit [Ping timeout: 264 seconds]
thejpster[m] has joined #rust-embedded
<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.
<thejpster[m]>
A bit more opinionated than just using libcore.
<thejpster[m]>
The thread and process APIs can just return an error like on WASM.
mabez[m] has joined #rust-embedded
<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
<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
<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
<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)
Kaspar[m] has joined #rust-embedded
<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?
<Kaspar[m]>
s/playint/playing/, s//`/, s/./`./
<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
<mabez[m]>
* a primitive type :D
ivmarkov[m] has joined #rust-embedded
<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.
<ivmarkov[m]>
s//`/, s//`/, s/vandor/vendor/
<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.
<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
<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?
<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
<JamesMunns[m]>
lemme send you a DM, talked to them at RustConf :)
<Kaspar[m]>
JamesMunns[m]: any time! 🙂
sugoi has joined #rust-embedded
sugoi has quit [Ping timeout: 248 seconds]
sugoi has joined #rust-embedded
M762spr[m] has joined #rust-embedded
<M762spr[m]>
ah ok. Thanks for going over all that while I was sleeping! 😁
<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.
<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 😅
<M762spr[m]>
<M762spr[m]> "ah ok. Thanks for going over all..." <- oh! I have a handful of pico chips I suppose I could use 🤔
AtleoS has quit [Ping timeout: 264 seconds]
AtleoS has joined #rust-embedded
sugoi has quit [Ping timeout: 245 seconds]
sugoi has joined #rust-embedded
s1syph0s[m] has joined #rust-embedded
<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?
<JamesMunns[m]>
cortex-m is like a pac for the common parts that every cortex-m core has
<JamesMunns[m]>
that includes the NVIC, which controls interrupts
<s1syph0s[m]>
ahh i see
<s1syph0s[m]>
is NVIC the same as an interrupt vector table or is it another component?
<JamesMunns[m]>
NVIC is the interrupt controller, it dispatches to the vector table functions when they occur
<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
<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.
<JamesMunns[m]>
though you can directly disable them from the cortex-m crate, as well.
<s1syph0s[m]>
thanks for the answers!
<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`
sugoi has quit [Ping timeout: 245 seconds]
<JamesMunns[m]>
<Kaspar[m]> "Still no idea why this is an..." <- What are you linking with?