cinemaSundays has quit [Quit: Connection closed for inactivity]
starblue has quit [Ping timeout: 248 seconds]
starblue has joined #rust-embedded
cr1901 has quit [Ping timeout: 268 seconds]
cr1901 has joined #rust-embedded
Socke has joined #rust-embedded
t-moe[m] has quit [Quit: Idle timeout reached: 172800s]
MathiasKoch[m] has quit [Quit: Idle timeout reached: 172800s]
AlexandrosLiarok has joined #rust-embedded
<AlexandrosLiarok>
is anyone aware of any heapless priority queue that may also remove elements in O(logn) time?
<AlexandrosLiarok>
s/in O(logn) time//
<AlexandrosLiarok>
Actually may be a XY problem. I want to maintain a queue of items while also maintaining a sorted version of them
<AlexandrosLiarok>
I need to be able to index both by queue position and also by sorted position.
<AlexandrosLiarok>
Both will host max 16 elements so I guess I could re-sort on insertion/removal.
<AlexandrosLiarok>
ah it seems sort_unstable does not need alloc
<dirbaio[m]>
for removal you don't need to re-sort, it's already guaranteed sorted
<JamesMunns[m]>
The only downside, don't forget that removals will require a memcpy, depending on how large your items are
<JamesMunns[m]>
(or memmove, I guess)
<dirbaio[m]>
and for insertion you can do an O(n) search to find where to insert it, then insert it there (moving elements after it to the right, also O(n))
<dirbaio[m]>
will be faster than re-sorting (which is O(n log n))
<dirbaio[m]>
and smaller code (I imagine the full sort algorithm in core will use quite a bit of flash)
<AlexandrosLiarok>
I guess I could probably just insert-sort on insertions
<AlexandrosLiarok>
or find and shift
<dirbaio[m]>
there's algos that allow doing insert/remove in O(log n) instead of O(n) but if N=16 I wouldn't bother
<AlexandrosLiarok>
yea will probably be faster to just do this linearly in most cases
<JamesMunns[m]>
binary search is also available on no-std, it gives you pretty much exactly where you need to insert
<JamesMunns[m]>
buuuut yeah for N=16, probably fair to just do a manual search lol
RoyBuitenhuis[m] has quit [Quit: Idle timeout reached: 172800s]
<i509vcb[m]>
Hmm seems like all of the traits in embedded-hal assume that things happen immediately, but this kind of is an issue for my wip firmware that uses postcard to act as an IO expander where there is some amount of latency to ask for things like the pin's input state.
<thejpster[m]>
<i509vcb[m]> "Actually quite a coincidence..." <- That’s actually by design. You’ll never guess what the Architecture Reference Manual is called.
<thejpster[m]>
i509vcb[m]: Not immediately, but they block until the job is done.
<thejpster[m]>
You might want embedded-hal-async instead.
<i509vcb[m]>
embedded-hal-async only has Wait, which means you can only listen for events. Not ask what the current state is.
<i509vcb[m]>
Of course adding new async traits isn't an issue, but rather the annoyance is going to be the ripple throughout dependent crates where everything breaks because you can't do something like: T: embedded_hal::InputPin or embedded_hal_async::InputPin
<i509vcb[m]>
s//`/, s/InputPin/AsyncInputPin`/
danielb[m] has joined #rust-embedded
<danielb[m]>
that sounds an awful lot like a GPIO expander, just the user would be your PC, not an MCU :D
<danielb[m]>
yeah async GPIO would make sense for gpio expanders
dsvsdveg[m] has quit [Quit: Idle timeout reached: 172800s]
swork[m] has quit [Quit: Idle timeout reached: 172800s]
<JamesMunns[m]>
I wonder how well crates like that have a problem when you need to start considering cancellation safety. Like, designing code that can be cancelled and can't be cancelled has a different style to it.
<JamesMunns[m]>
Like deasserting a chip select if you are cancelled in a driver op
<JamesMunns[m]>
It's common enough to be expected in async, and you'd have a drop impl that sets it on drop, but you'd much more rarely do that in blocking code. Maybe at error points if you have early returns
<diondokter[m]>
Yeah, well Rust already doesn't really give good tools to do that in async fn's anyways, even without crates like these
<JamesMunns[m]>
You can make really thin structs with a drop imple
<JamesMunns[m]>
s/imple/impl/
<JamesMunns[m]>
I'm not sure how much more succinct of a syntax you could put on it tbh
<diondokter[m]>
The poor man's defer yeah
<diondokter[m]>
And it must be blocking
<diondokter[m]>
No async drop yet
<JamesMunns[m]>
Yeah that's very fair
<JamesMunns[m]>
Easier to paper over on std
<i509vcb[m]>
Or use a crate like scopeguard
<JamesMunns[m]>
Still blocking tho it seems?
<i509vcb[m]>
hmm yeah scopeguard would block
<i509vcb[m]>
And "you dropped it wrong" isn't the nicest from an api perspective
<JamesMunns[m]>
The other workaround is setting some kind of "dirty" flag on the parent struct to clean up on next action. It's more work for sure tho.
<i509vcb[m]>
* it wrong" panic isn't the
<danielb[m]>
JamesMunns[m]: that can make some things somewhat forget-safe, too
hjeldin__[m] has joined #rust-embedded
<hjeldin__[m]>
hey all, i'm trying to use embassy-usb-dfu with an stm32l4, when i include it in my cargo deps and build i get cannot find function __basepri_r in module crate::asm::inline. these are my enabled features: ["defmt", "dfu", "cortex-m"]. looking at the issues on the repository i found mentions of selecting the right target when compiling, but it's already thumbv7m-none-eabi
<hjeldin__[m]>
* hey all, i'm trying to use embassy-usb-dfu with an stm32l4, when i include it in my cargo deps and build i get `cannot find function __basepri_r in module crate::asm::inline`. these are my enabled features: \["defmt", "dfu", "cortex-m"\]. looking at the issues on the repository i found mentions of selecting the right target when compiling, but it's already thumbv7m-none-eabi.
<hjeldin__[m]>
this is my other dep: `cortex-m = { version = "0.7.7", features = ["critical-section-single-core", "inline-asm"]}` (i tried also removing 'inline-asm')
<dirbaio[m]>
Can you share your Cargo.toml, and .cargo/config.toml, and the cargo command you're running and the full output?
<LiamKinne[m]>
Does anyone here have experience with Windows USB WCID? I'm trying to get it working with the usb-device crate and can't seem to get the host to request the descriptor string.
<dirbaio[m]>
wtf
<dirbaio[m]>
Can't see anything wrong
<dirbaio[m]>
Try building with rust installed from rustup instead of from Nix
<hjeldin__[m]>
that might be a challenge on nixos
<dirbaio[m]>
I've seen nix cause nonsense errors like this
<dirbaio[m]>
Surely nixos gives you a writable home where you can put an executable and add it to PATH...?
<dirbaio[m]>
I'd suggest trying it even if it's an unholy nix sin, so you can rule in/out nix as the source of the issue
<hjeldin__[m]>
well...only if it's statically linked i can, yeah 🤣
<hjeldin__[m]>
hold on, i have an ubuntu vm, let me check there
<dirbaio[m]>
try adding resolver = "2" to [package]
<dirbaio[m]>
(or switch to edition 2021, resolver=2 is default there)
<dirbaio[m]>
the old resolver merges feature flags between dependencies and build-dependencies, which can cause building embedded-specific stuff for x86
<dirbaio[m]>
the error you're getting is because it's trying to build cortex-m for c86