<chrysn[m]>
Big praise to the probe-rs project -- not just for the infrastructure this provides, but for a level and speed of responsiveness even on initially controversial pull requests. This is a pleasure to work with.
ouilemur has quit [Quit: WeeChat 4.6.1]
dkm is now known as lmorhet_
lmorhet_ is now known as dkm
danielb[m] has joined #rust-embedded
<danielb[m]>
<chrysn[m]> "Big praise to the probe-rs..." <- I remember you might have had a different experience trying to contribute to one of my early rust yoloware 🙈
<chrysn[m]>
Looking through my mail history, I don't even remember what I used Slots for, and things there went just as quick from the mail timestamps :-)
<chrysn[m]>
Oooh, that was for my covid "I gotta do something to stay connected to my board game folks" project 😍
ouilemur has joined #rust-embedded
<JamesMunns[m]>
<danielb[m]> "I remember you might have had..." <- oh is "yoloware" catching on now? 🤣
<danielb[m]>
JamesMunns[m]: I told you I'm stealing the term
<danielb[m]>
it's the best word describing that crate
<JamesMunns[m]>
I guess I could just nickname the "IUNR" variant to "yoloware"
<danielb[m]>
I've never been diagnosed with dyslexia, I read a lot, and I consider myself decent at the skill, but looking at IUNR all my brain sees is "urinal"
<JamesMunns[m]>
better than "CUMR", I guess
<JamesMunns[m]>
(also: if anyone here would use a scale like that, let me know, I'm somewhat serious about writing it up, I think it could be useful for "setting expectations")
<danielb[m]>
I'm just unsure about the amount of variations, and what even "complete, open for PRs" would mean
<JamesMunns[m]>
i'd probably say "complete" means "it does what it says it does", which might not include "all it could possibly do". "open for PRs" means you might still take extensions, improvements, etc.
<JamesMunns[m]>
likewise, something might be incomplete, but if it works enough/you aren't interested in it anymore, "not open for PRs" means "don't even open a PR, I don't care"
<JamesMunns[m]>
I should probably just write up all 16 variants and see if I can find an example for each :D
<danielb[m]>
i'd be fine with marking my stuff with a 4-line list of ❌/✅, but I would be very sad if I'd have to decode the 4-letter words multiple times a day :) on the other hand, if people abandon something for whatever reason, you can never be sure this sort of signaling will be up to date
<danielb[m]>
rustsec's "unmaintained" advisories are annoying but at least those handle this part without the maintainer actively having to spend effort, I think
<chrysn[m]>
if we'd want to be serious here, we'd probably use the maintenance status field of cargo.toml, with actively-developed and as-is and experimental etc. but who can resist the charm of a letter code, especially when it brings the memories of the Geek Code of old?
<JamesMunns[m]>
Yeah, I was trying to come up with something simpler, but a 1D scale (like TRLs) didn't seem to cover everything I wanted
pcs38 has quit [Remote host closed the connection]
sroemer has quit [Quit: WeeChat 4.4.3]
RobinMueller[m] has quit [Quit: Idle timeout reached: 172800s]
pcs38 has joined #rust-embedded
newam[m] has quit [Quit: Idle timeout reached: 172800s]
Noah[m] has joined #rust-embedded
<Noah[m]>
I want readiness for probe-rs targets
bartmassey[m] has quit [Quit: Idle timeout reached: 172800s]
dirbaio[m] has joined #rust-embedded
<dirbaio[m]>
readiness?
<dirbaio[m]>
ah as in "how polished is it"
esden[cis] has quit [Quit: Idle timeout reached: 172800s]
<Noah[m]>
dirbaio[m]: correct :) like a flag as in "used daily", "never tested" etc would already help
Divya[m] has quit [Quit: Idle timeout reached: 172800s]
<danielb[m]>
assume "never tested" until the moment you try it
<Noah[m]>
Eh, would be nice to have sth to track and give users some confidence when they run into issues.
<Noah[m]>
You know like "expect trouble" and then running into trouble is a much better experience than expecting it to work and running into trouble
<danielb[m]>
everything is a fair dice roll in my experience...
<dirbaio[m]>
not sure what it'd accomplish. if you read "this is experimental" but you need it you're going to try it anyway
i509vcb[m] has quit [Quit: Idle timeout reached: 172800s]
jannic[m] has quit [Quit: Idle timeout reached: 172800s]
diondokter[m] has joined #rust-embedded
<diondokter[m]>
Some expectation management. I think that's it.
<diondokter[m]>
Would be nice to have a place to put some more info in. For example, the debug sequences for the imxrt6xx assume that one of the external flash pins is hooked up to a specific pin on the MCU. This works for the evk board, but might not on custom boards. Afaik there's no way to find that out if you don't read the sequences
<danielb[m]>
probe-rs is generally not great at handling custom hardware :/
kevlan[m] has joined #rust-embedded
<kevlan[m]>
Having just gone down the flash-algorithm rabbit hole, I need to do a write-up somewhere on it. I think I can put together a pretty straightforward set of steps for anyone bringing up a QSPI/XSPI flash on an STM32 now.
<kevlan[m]>
It helps a lot that I was able to use the embassy xspi driver in the flash-algo so I didn't actually have to write much code. It was basically just entering the hardware settings for it.
<danielb[m]>
<kevlan[m]> "Having just gone down the flash..." <- if you do, would you write a probe-rs website docu page about this?
<kevlan[m]>
Yeah, I can definitely contribute it to the probe-rs docs.
<danielb[m]>
that would be awesome
zeenix[m] has quit [Quit: Idle timeout reached: 172800s]