02:44 <sneakernet[m]> power, atomics, scheduling)

02:44 <sneakernet[m]> <diondokter> "Are you the person that left the..." <- what I've seen of embassy I like, but your video assumes that embassy has poly-filled the hardware abstraction - which you suggest "testing" to validate. if embassy doesn't claim to support your target, "testing" is a crapshoot as to what functionalities embassy actually provides - maybe the code is functional, but doesn't provide hardware level behaviors of embassy (low

07:01 <AlexChen[m]> <diondokter> "Are you the person that left the..." <- hello

09:20 <JamesMunns[m]> I'd probably write my own based on a vec or a `[Option<T>; N]`, maybe with your own trait to calculate an arbitrary "score" where "lowest score loses".

09:20 <ryan-summers[m]> > <@chrysn:matrix.org> I'm looking for a data structure similar to an LRU, but where order is still maintained based on a partially ordered property of the members. Best illustrated by the use case: I can keep (say) 8 concurrent connections, and if a new one comes in I want to drop the old, but incomplete connections should be dropped first, then unauthenticated connections, then connections.

09:20 <ryan-summers[m]> * WOouldn't this just be a standard list-like-structure (i.e. a Vec or something) where you did a custom `Ord` implementation or similar to figure out if something should get dropped?

09:21 <JamesMunns[m]> idk if that has a name, but you have enough requirements I'd probably just write my own quickly instead :D

09:24 <JamesMunns[m]> hmm, do you want them to be kept in *insertion* order, or *score* order, or "doesn't matter as long as they get evicted by score"?

09:32 <JamesMunns[m]> so more "least recently added" rather than "least recently used"?

09:32 <chrysn[m]> It is just a list structure yes, somewhere between a heapless Vec and an array (depending on whether you put in T or Option<T>). The LRU part ensures that it is sorted (commonly using linked indices).

09:32 <chrysn[m]> Yeah, implementing it on my own is a viable route, just didn't want to build yet another if it existed :-)

09:32 <JamesMunns[m]> you said you DON'T want touching it to move it to the front of the list

10:12 <sarath08071994[m> Hi, I am working on the hello world cross compilation for the quectel AG35 board which is running Linux os.... (full message at <https://catircservices.org/_matrix/media/v3/download/catircservices.org/fvxsLlDicYOLwcxhoLFjurIl>)

10:12 <sarath08071994[m> This the make file c code compilation

10:14 <sarath08071994[m> For rust hello world code compilation how to configure config.toml ?

10:22 <sarath08071994[m> I have done this configuration but I am getting linker issue

10:23 <sarath08071994[m> Can anyone please help me with this

10:43 <JamesMunns[m]> (misc note: matrix dot org is having some problems at the moment, in case you are seeing issues: https://status.matrix.org/)

10:45 <vollbrecht[m]> It seams the Matrix Server have an outage today, so maybe take a while till they recover and churn through the backlog 🔥

11:50 <thejpster[m]> I wrote a quick shell script for trying a bunch of different target-cpu and target-feature options: https://github.com/jonathanpallant/armtesting/tree/main/armtesting

11:50 <thejpster[m]> TL;DR: The defaults are now a little better, but I still can't turn off FPU support once `cortex-m33` (and friends) has turned it on.

11:51 <thejpster[m]> that text is what I propose for the thumb target docs

12:24 <ryan-summers[m]> General question: I want to use an async library in a project where I don't have access to async support (it's nested through callbacks exposed on other libraries, where the callbacks aren't runin async contexts). Is there any mechanism to loop on a single async task until it completes?

12:27 <dirbaio[m]> https://docs.embassy.dev/embassy-futures/git/default/fn.block_on.html

12:28 <ryan-summers[m]> Awesome, thanks. Was looking for just that

13:01 <gdamjan[m]1> is the embedded tag/keyword used consistently on crates.io ?

14:17 <mameluc[m]> <gdamjan[m]1> "is the embedded tag/keyword used..." <- I think no_std is more reliable

14:17 <gdamjan[m]1> ah right. good one

14:18 <mameluc[m]> gdamjan[m]1: depends on what you search for. Some driver crate probably writes about embedded while for example serde works on no_std but probably doesn't care if it is embedded or not

14:18 <mameluc[m]> https://crates.io/categories/no-std

14:19 <gdamjan[m]1> I'll be giving quick introduction to some people about rust-embedded, wanted to point them in the right direction

14:19 <gdamjan[m]1> problem is, https://crates.io/crates/embedded-hal doesn't have either :/

14:19 <JamesMunns[m]> https://github.com/rust-embedded/awesome-embedded-rust is usually my first place to look

14:20 <JamesMunns[m]> but yeah, it would be good to open PRs to different crates to add the "embedded" tag

15:46 <thejpster[m]> I'm starting to have the conversation at work about how "embedded" is actually two things in a trenchcoat: "microcontrollers" and "kernel-level development"

15:47 <diondokter[m]> Yep, the difference between using a microcontroller and say developing your own kernel for x86 isn't all that big. Only the hardware changes, but your activities not really

15:48 <thejpster[m]> there's "I need to hit the registers myself", then "I have an OS kernel, or I am in the OS kernel, but I don't have libstd", and then there's "I'm making a ticket vending machine, it runs Android".

15:48 <diondokter[m]> Writing a web-server on top of embedded-linux is way less embedded than the previous two examples I gave :P

15:48 <diondokter[m]> Indeed

15:49 <thejpster[m]> kernel people usually want to know about syscalls, and liballoc. Microcontroller people usually want to know about #[interru[t

15:49 <thejpster[m]> s/#/#\/, s/interru[t/interrupt/

15:49 <thejpster[m]> s/#/`#/, s/interru[t/interrupt]` and defmt and probe-rs./

15:50 <thejpster[m]> there's some overlap, but it's definitely a different training course.

16:15 <sourcebox[m]> Are there any plans for a new release of the usb-device crate in the near future? I ran into the issue of having a too large config descriptor.

16:18 <ryan-summers[m]> sourcebox[m]: I can kick out a release, been planning to for a while. Let me look if there's any pending breaking changes left

16:19 <sourcebox[m]> I switched to the master branch via `patch.crates-io'. Works so far,

16:20 <ryan-summers[m]> <diondokter[m]> "Yep, the difference between..." <- We actually wrote an OS for an embedded ARM device in QEMU for my OS class, and it was basically exactly what I do in my day job for embedded, just with different software requirements

16:20 <ryan-summers[m]> * OS class back in college, and

16:20 <sourcebox[m]> Problem is though that I have to keep local forks of some class drivers because they are still on older versions.

16:20 <ryan-summers[m]> Yeah that's why I don't like kicking out breaking semver changes too often. The stack is super fragmented

16:21 <ryan-summers[m]> Are those authors just not around anymore? We could try getting them moved over to rust-embedded-community as well

16:21 <ryan-summers[m]> I maintain usbd-serial, would be happy to move more driver crates in there as well if we need to

16:22 <sourcebox[m]> The ones i'm using are usbd-midi and usbd-audio.

16:23 <sourcebox[m]> usbd-midi was last updated 3 years ago and there are several forks around.

16:24 <ryan-summers[m]> It has an MIT license, so we can probably copy it over to rust-embedded-community, but wouldn't have access to publishing under the same name

16:25 <ryan-summers[m]> The author might respond too, idk. Doesn't seem like anyone's PRd the usb-device updates over yet

16:25 <sourcebox[m]> There has to be some work to be done on it. Several people already did something, but I guess it can't be merged into one. Have a look here: https://github.com/btrepp/usbd-midi/network

17:05 <thejpster[m]> I now understand the +dsp target feature.

17:07 <thejpster[m]> It emits thinks like UQADD8, a saturating add (like let x = some_u8.saturating_add(some_other_u8)). It's on by default for M4 and M7 because the DSP support is mandatory, it's on by default for M33 but DSP support is optional.

17:07 <thejpster[m]> I updated https://hackmd.io/@thejpster/H1iTNJSRT

17:14 <thejpster[m]> almost exactly like that

17:14 <thejpster[m]> this is arcane forbidden knowledge that should only come on minidisc

17:34 <sourcebox[m]> <ryan-summers[m]> "The author might respond too..." <- There was already some request for transferring the ownership. Maybe you can ask the author again if he's willing to do it. See https://github.com/btrepp/usbd-midi/issues/9