03:47 <euphemism[m]> Hey there, quick(ish) question. I am new to the embedded world due to my aversion to C/C++. I figured I would two-birds-one-stone this with my desire to learn Rust. I have a USB device that is both CDC and UAC1. I want to build a USB host using an RP2040 that can receive both the audio stream and serial data from this device.

03:47 <euphemism[m]> Discovered tinyUSB, but as far as I can tell it does not support USB audio in the host stack. I found this C library that does: https://github.com/cherry-embedded/CherryUSB/ and my question is if anyone thinks it would be possible to use bindgen to enable use of this library from a Rust codebase.

03:47 <euphemism[m]> Got this up and running on a Pico really easily, and is currently what I'm working with: https://github.com/rp-rs/rp2040-project-template

03:53 <adamgreig[m]> not easy, it looks like their host stack requires some sort of operating system that has threads and allocation

03:53 <adamgreig[m]> certainly possible, but you'd need to be running some sort of RTOS that provides threads, which is not common in embedded rust as people tend to use async (or a framework like rtic which provides hardware threads but won't work with this, I don't think)

03:53 <adamgreig[m]> USB host mode is generally harder and rarer, so you're off to a difficult start to begin with :P

03:55 <adamgreig[m]> probably the best bet is to use something like FreeRTOS, use CherryUSB in C inside it with its provided FreeRTOS OS bindings, and then write the rest of your program in Rust using the FreeRTOS rust support (maybe https://github.com/lobaro/FreeRTOS-rust )

04:00 <adamgreig[m]> also USB audio is probably the hardest part of USB, heh

04:00 <euphemism[m]> adamgreig[m]: So it would seem..

04:03 <euphemism[m]> Okay. I will start looking into that. Thank you, adamgreig.

04:58 <M9names[m]> might be worth asking on the cherryusb github whether adamgreig's intuition is correct WRT needing an RTOS.

04:58 <M9names[m]> no-one is going to know that USB stack better than the author

13:54 <adamgreig[m]> the readme says the host stack requires the OSAL, and the OSAL requires functions for creating a thread, so it seems likely

14:29 <waveguide[m]> I think cherryusb was a rip off of the zephyr usb stack?

14:30 <waveguide[m]> * usb stack? or maybe that was some other usb stack, someone ripped off someone at some point

14:32 <waveguide[m]> * <del>I think, * usb stack? or maybe that was some other usb stack, someone ripped off someone at some point</del> Just forget that, no idea what I'm talking about

15:52 <waveguide[m]> Are there any example hal drivers for where a peripheral has something where a tx and rx handles (multiple!) may be created from a base peripheral wrapper

15:54 <waveguide[m]> e.g. struct BaseIp { ptr: BasePtr } struct Tx<N> { b: BaseIP } impl BaseIp { fn tx<N>(&mut self) { Tx { self } }, I guess I sort of need a ref count like shared object in this case? Rc<> or Arc<> or whatever, but that also seems kind of insane... in the end its a pointer to the address of the IP block I'm sharing

15:55 <waveguide[m]> * e.g.... (full message at <https://catircservices.org/_matrix/media/v3/download/catircservices.org/hMotgfHcpZOQvnAkebBSqHHP>)

15:55 <waveguide[m]> * e.g.... (full message at <https://catircservices.org/_matrix/media/v3/download/catircservices.org/lMKQdoxbYqGVRpZVvOQiHyWA>)

15:57 <waveguide[m]> The peripheral in this case is nxp's sai peripheral, which depending on the IP block instance may have N many channels, both tx and rx being optional... with each one sharing some base IP block configuration but also having their own fifo and data pin

15:57 <waveguide[m]> but at minimum there's 1 tx and rx per IP instance

15:58 <waveguide[m]> the way the mcux hal code deals with this is by assuming every instance has 4 channels and its up the author to deal with all the possibly erroneous configurations...

15:59 <waveguide[m]> * e.g.... (full message at <https://catircservices.org/_matrix/media/v3/download/catircservices.org/MPkEVkMdoOEenGcSprwocqil>)

15:59 <waveguide[m]> * e.g.... (full message at <https://catircservices.org/_matrix/media/v3/download/catircservices.org/fcaxdmEqjyBsFTaZisoKLWJs>)

15:59 <waveguide[m]> s/a//

16:04 <diondokter[m]> Sounds similar to split uarts where one peripheral is split into a tx and an rx part

16:04 <waveguide[m]> Kind of, in this case though each tx and rx is optional

16:05 <waveguide[m]> Like maybe sai0 only transmits and sai1 only receives, or maybe sai0 transmits on some subset of the 4 channels

16:06 <waveguide[m]> Or maybe sai0 connected to a codec uses a single tx and rx pair 

16:08 <diondokter[m]> Sure, but how you share it is the same principle.

16:08 <diondokter[m]> For example here in the Embassy code: https://github.com/embassy-rs/embassy/blob/6ff91851b162d311e11277dae91443868db05cfd/embassy-nrf/src/uarte.rs#L184

16:08 <diondokter[m]> It clones the peripheral because both parts only touch registers that don't overlap.

16:09 <waveguide[m]> Ok that might be what I need to look at

16:09 <waveguide[m]> It does seem to keep a ref count?

16:09 <waveguide[m]> I can have a bitmap instead to mark channels in use

16:09 <diondokter[m]> That's for the drop I think. Embassy turns off the peripheral once it's dropped

17:36 <TimHilt[m]1> Hi there! I’m just learning Rust with the goal of writing an audio-application for the Orange Pi Zero LTS (http://www.orangepi.org/html/hardWare/computerAndMicrocontrollers/details/Orange-Pi-Zero-LTS.html).

17:36 <TimHilt[m]1> The application should also include a few push-buttons and an SPI enabled device. I’m currently looking for a crate that I can use with this particular hardware. Do you think https://github.com/rust-embedded/linux-embedded-hal would be a good fit? I’m looking for something that’s not too low level because I fear I might be overwhelmed with too many things not working / not compiling

20:16 <dirbaio[m]> Tim Hilt: yep that should work on the pi zero

20:16 <dirbaio[m]> you might have to adjust the device tree for SPI stuff, not sure

20:19 <dirbaio[m]> beware wifi support on that board is a giant mess and super unstable tho 🙃

20:21 <dirbaio[m]> (or was in ~2020 at least, when I worked with it)

20:23 <TimHilt[m]1> Alright, I’m excited to see how it goes. Never worked with Orange Pi’s before 😅

20:23 <dirbaio[m]> what's the reason for picking it? cost?

20:23 <TimHilt[m]1> Cost, availability and audio capabilities. There’s a dedicated io-shield for 3€ that hosts a line-out port

20:24 <TimHilt[m]1> If I have questions along the way - would this channel be a good place to ask?

20:25 <dirbaio[m]> yup!

20:27 <TimHilt[m]1> Great! Thanks. I’ll open source everything I’ll do anyways. :)

20:29 <dirbaio[m]> how many are you going to build? I have a box of 200 of them I can sell you for cheap 🤣

20:30 <dirbaio[m]> (used though, and the previous version based on the H2+ instead of the H3...)

20:30 <M9names[m]> <dirbaio[m]> "beware wifi support on that..." <- Xr819, yeah? Good times.

20:30 <M9names[m]> https://github.com/fifteenhex/xradio

20:31 <TimHilt[m]1> Haha only one :D it’s supposed to be a child’s audio-player with Spotify integration. The songs start playing by reading an nfc tag

20:31 <dirbaio[m]> lol

20:31 <dirbaio[m]> okay 😂

20:31 <TimHilt[m]1> 9names: uhoh

20:32 <dirbaio[m]> yeah, only use that board if you're going to use it with ethernet

20:32 <TimHilt[m]1> dirbaio: this already exists (at least in Germany, no idea about global scope) and it’s named the „Tonie box“. Every nfc tag costs around 16€

20:33 <TimHilt[m]1> dirbaio[m]: I guess then the orange pi is out. Ethernet won’t be an option

20:44 <TimHilt[m]1> Any recommendations at around the same price point? I guess the obvious contender would be the raspberry pi but unfortunately that thing is much too pricey atm

20:45 <dirbaio[m]> pi zero w maybe

20:48 <euphemism[m]> <waveguide[m]> "I think cherryusb was a rip..." <- What’s this about?