ChanServ changed the topic of #rust-embedded to: Welcome to the Rust Embedded IRC channel! Bridged to and logged at, code of conduct at
sneakernet[m] has joined #rust-embedded
<sneakernet[m]> power, atomics, scheduling)
<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
feerless[m] has quit [Quit: Idle timeout reached: 172800s]
bomb has joined #rust-embedded
cr1901_ has joined #rust-embedded
cr1901 has quit [Ping timeout: 246 seconds]
nadir has joined #rust-embedded
nadir has quit [Client Quit]
AlexChen[m] has joined #rust-embedded
<AlexChen[m]> <diondokter> "Are you the person that left the..." <- hello
thejpster[m] has quit [Quit: Idle timeout reached: 172800s]
bomb_ has joined #rust-embedded
bomb has quit [Ping timeout: 260 seconds]
bomb_ is now known as bomb
<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".
ryan-summers[m] has joined #rust-embedded
<ryan-summers[m]> > <> 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.
<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?
<JamesMunns[m]> idk if that has a name, but you have enough requirements I'd probably just write my own quickly instead :D
<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"?
<JamesMunns[m]> so more "least recently added" rather than "least recently used"?
chrysn[m] has joined #rust-embedded
<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).
<chrysn[m]> Yeah, implementing it on my own is a viable route, just didn't want to build yet another if it existed :-)
<JamesMunns[m]> you said you DON'T want touching it to move it to the front of the list
cr1901__ has joined #rust-embedded
cr1901_ has quit [Ping timeout: 240 seconds]
starblue has quit [Ping timeout: 255 seconds]
starblue has joined #rust-embedded
sarath08071994[m has joined #rust-embedded
<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 <>)
<sarath08071994[m> This the make file c code compilation
<sarath08071994[m> For rust hello world code compilation how to configure config.toml ?
<sarath08071994[m> I have done this configuration but I am getting linker issue
<sarath08071994[m> Can anyone please help me with this
<JamesMunns[m]> (misc note: matrix dot org is having some problems at the moment, in case you are seeing issues:
<vollbrecht[m]> It seams the Matrix Server have an outage today, so maybe take a while till they recover and churn through the backlog 🔥
thejpster[m] has joined #rust-embedded
<thejpster[m]> I wrote a quick shell script for trying a bunch of different target-cpu and target-feature options:
<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.
<thejpster[m]> that text is what I propose for the thumb target docs
<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?
<ryan-summers[m]> Awesome, thanks. Was looking for just that
gdamjan[m]1 has joined #rust-embedded
<gdamjan[m]1> is the embedded tag/keyword used consistently on ?
AtleoS has quit [Ping timeout: 240 seconds]
mameluc[m] has joined #rust-embedded
<mameluc[m]> <gdamjan[m]1> "is the embedded tag/keyword used..." <- I think no_std is more reliable
<gdamjan[m]1> ah right. good one
<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
<gdamjan[m]1> I'll be giving quick introduction to some people about rust-embedded, wanted to point them in the right direction
<gdamjan[m]1> problem is, doesn't have either :/
<JamesMunns[m]> is usually my first place to look
<JamesMunns[m]> but yeah, it would be good to open PRs to different crates to add the "embedded" tag
cr1901__ is now known as cr1901
<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"
diondokter[m] has joined #rust-embedded
<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
<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".
<diondokter[m]> Writing a web-server on top of embedded-linux is way less embedded than the previous two examples I gave :P
<diondokter[m]> Indeed
<thejpster[m]> kernel people usually want to know about syscalls, and liballoc. Microcontroller people usually want to know about #[interru[t
<thejpster[m]> s/#/#\/, s/interru[t/interrupt/
<thejpster[m]> s/#/`#/, s/interru[t/interrupt]` and defmt and probe-rs./
<thejpster[m]> there's some overlap, but it's definitely a different training course.
corecode has quit [Ping timeout: 260 seconds]
sourcebox[m] has joined #rust-embedded
<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.
<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
<sourcebox[m]> I switched to the master branch via `patch.crates-io'. Works so far,
<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
<ryan-summers[m]> * OS class back in college, and
<sourcebox[m]> Problem is though that I have to keep local forks of some class drivers because they are still on older versions.
<ryan-summers[m]> Yeah that's why I don't like kicking out breaking semver changes too often. The stack is super fragmented
<ryan-summers[m]> Are those authors just not around anymore? We could try getting them moved over to rust-embedded-community as well
<ryan-summers[m]> I maintain usbd-serial, would be happy to move more driver crates in there as well if we need to
<sourcebox[m]> The ones i'm using are usbd-midi and usbd-audio.
<sourcebox[m]> usbd-midi was last updated 3 years ago and there are several forks around.
<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
<ryan-summers[m]> The author might respond too, idk. Doesn't seem like anyone's PRd the usb-device updates over yet
<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:
<thejpster[m]> I now understand the +dsp target feature.
<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.
<thejpster[m]> almost exactly like that
<thejpster[m]> this is arcane forbidden knowledge that should only come on minidisc
<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
cr1901_ has joined #rust-embedded
cr1901 has quit [Ping timeout: 268 seconds]
majors has quit [Quit: ZNC 1.7.5+deb4 -]
majors has joined #rust-embedded
danielb[m] has quit [Quit: Idle timeout reached: 172800s]
burrbull[m] has quit [Quit: Idle timeout reached: 172800s]
bomb has quit [Quit: 💣]
enaut[m] has quit [Quit: Idle timeout reached: 172800s]
ruabmbua[m] has quit [Quit: Idle timeout reached: 172800s]
mabez[m] has quit [Quit: Idle timeout reached: 172800s]
majors has quit [Quit: ZNC 1.7.5+deb4 -]
majors has joined #rust-embedded
majors has quit [Client Quit]
majors has joined #rust-embedded
dngrs[m] has quit [Quit: Idle timeout reached: 172800s]
liebman[m] has quit [Quit: Idle timeout reached: 172800s]
WSalmon has quit [Quit: - Chat comfortably. Anywhere.]
WSalmon has joined #rust-embedded
corecode has joined #rust-embedded
corecode has quit [Quit: ZNC -]
M9names[m] has quit [Quit: Idle timeout reached: 172800s]
corecode has joined #rust-embedded
JomerDev[m] has quit [Quit: Idle timeout reached: 172800s]