KevinPFleming[m] has quit [Quit: Idle timeout reached: 172800s]
jfsimon has joined #rust-embedded
jfsimon has quit [Remote host closed the connection]
jfsimon has joined #rust-embedded
jfsimon has quit [Remote host closed the connection]
jfsimon has joined #rust-embedded
jfsimon has quit [Remote host closed the connection]
jfsimon has joined #rust-embedded
jfsimon has quit [Remote host closed the connection]
jfsimon has joined #rust-embedded
ska has quit [Ping timeout: 240 seconds]
elpiel[m] has joined #rust-embedded
<elpiel[m]>
<rukai[m]> Hi, I hope this is an appropriate place to post this, but I've been working on a rust crate to work around missing webusb support in some browsers by sending data over the FIDO protocol https://github.com/rukai/not-webusb-rs
<elpiel[m]>
I'll definitely follow the project and check the code!
<rukai[m]>
An extension would be a pretty good solution for Firefox users to access webusb.
<rukai[m]>
I trust Firefox users to be able to install chrome if needed. My main motivation was safari's lack of webusb, since it's a default browser the user may be less able to install another browser.
sroemer has joined #rust-embedded
sroemer has quit [Changing host]
sroemer has joined #rust-embedded
HumanG331 has joined #rust-embedded
sroemer has quit [Quit: WeeChat 4.5.2]
<thejpster[m]>
how do people feel about setting GPIO pins through a shared, immutable, reference, when the hardware has a Write-1-to-Set and a Write-1-to-Clear register for each port?
<thejpster[m]>
it feels like using an atomic integer (with all the races that load/store can introduce), but ... I'm not telling the compiler the special things the compiler is told about atomic integers. The compiler just sees some volatile writes to MMIO space.
<JamesMunns[m]>
I think it's fine, depending on what guarantees you make at the API level.
<JamesMunns[m]>
like, if you're very clear "this is never exclusive", especially if you make the handles `Clone` (or even `Copy`), it's fine
<JamesMunns[m]>
"the special things the compiler is told about atomic integers" is just "UnsafeCell"
<JamesMunns[m]>
"the special things the compiler is told about atomic integers" is just "UnsafeCell"
<thejpster[m]>
and when the mutable state isn't a compiler allocated object but MMIO peripheral register, I don't even need that?
<JamesMunns[m]>
There's probably questions of provenance, but I don't think there would be particular issues with cloning/sharing a wrapper that performs volatile single cycle ops
<JamesMunns[m]>
like, "where do you get the first handle that contains a `*mut Whatever`" is a question to answer, but once you have that, you're off to the races afaik.
<JamesMunns[m]>
Just don't (ever) make it a reference to something, you can have aliasing pointers all day
<JamesMunns[m]>
(err, don't make a reference to the thing the pointer points to)
<JamesMunns[m]>
Holistically it maybe gets a little funky depending on what guarantees you make on other parts of the gpio register, like, if someone is holding an &mut and the state of the gpio changes because someone else used a shared handle to toggle
<JamesMunns[m]>
but, that's more about "what you guarantee in your hal peripheral"
<JamesMunns[m]>
you should not give the user access to anything that can change, like an &mut of a register. you should to a single cycle read, and return that, and let them do a single cycle write (like most pacs allow)
ska has joined #rust-embedded
<thejpster[m]>
today is just one of those days.
<thejpster[m]>
I'm masking and unmasking an interrupt on cortex-m. I'm masking the interrupt in its own interrupt routine, and unmasking it later from idle.
<thejpster[m]>
Unmasking it causes it to run, even though the peripheral that drives the interrupt doesn't have anything to do.
jfsimon has quit [Quit: Leaving]
jfsimon has joined #rust-embedded
<thejpster[m]>
ugh, I must have a bad setup. Even the old version of the program doesn't work.
<firefrommoonligh>
<thejpster[m]> how do people feel about setting GPIO pins through a shared, immutable, reference, when the hardware has a Write-1-to-Set and a Write-1-to-Clear register for each port?
<firefrommoonligh>
So, then you might call StatusLed::Fix::turn_on() or w/e in code
<firefrommoonligh>
s//`/, s/::/./, s//`/
<firefrommoonligh>
As you point out, the difference in these two approaches is that the former requires locks, while the latter doesn't. Internally, they both set BSRR as in your example
<thejpster[m]>
An associated function is the third option, but I don’t want to lose the ability to change which pin is being used by changing how the resources are being defined.
<thejpster[m]>
But if you can set a pin with a function (as your example, or as Arduino does) then there should be no problem setting a pin with a & ref
<firefrommoonligh>
I think I understand now... interesting. Everything I've been doing for setting (And most or all of what I've seen in rust) requires &mut. I think you could make a convincing argument that you don't need a mutable reference. It depends on the semantics of what you mean by &mut, as I think the normal definition doesn't apply to hardware abstractions.
<firefrommoonligh>
Traditionally, I think the assumption here means "mutable variable means mutable hardware state", but it doesn't have to be that way.
<dngrs[m]>
I'd like to see the threat model for Mozilla's security stance on WebUSB because afaik they haven't published it, because I am having a hard time coming up with one. I guess once you link USB capabilities and assume RCE one could e.g. write a keylogger? I guess? But that needs RCE, and at that point you can probably also just load the system USB libraries that will be in place anyway
<JamesMunns[m]>
<firefrommoonligh> Digging a little more into jpster's insight: I think the expectation when you pass something as immutable is that *state can't change*. I consider, (Maybe controversially) rust's explicit control over mutability, (notably mutable refs as fn params) to be its strongest quality. (I have a headache...
<JamesMunns[m]>
You can with anything that has inner mutability: `&Mutex`, `&AtomicU32`, I think it's just expectation management.
<JamesMunns[m]>
IMO using "shared reference" for `&` and "exclusive reference" for `&mut` is much more clear than immutable/mutable referances.
<firefrommoonligh>
Try; inner mutability is another gray area
<firefrommoonligh>
*true
<JamesMunns[m]>
I don't think there is "objectively correct" here, just "expectation management". Just document your API and be consistent with it :)
<firefrommoonligh>
Thoughts on jpster's case of a p variable (e.g. stored in RTIC, a mutex etc) that changes GPIO state? Should it require the ref to be &mut to set its state?
<firefrommoonligh>
s/p/persistent/
<firefrommoonligh>
Yea same! I can see either perspective, and had to think this through before that "use &mut" conclusion
<firefrommoonligh>
It's not trivial
RoyBuitenhuis[m] has quit [Quit: Idle timeout reached: 172800s]
<dngrs[m]>
yeah I've seen the first page and found it way too vague - I guess their assumption is "people will just click accept, even for things they shouldn't" - which could easily be solved by putting WebUSB behind some toggle only available in `about:config`, for example. Or by adding a timer like they do with extension installers. Etc. Oh well 🤷
Pete[m]1 has joined #rust-embedded
<Pete[m]1>
Yeah, the WebUSB position is a pain, since I'm a FF user 99% of the time, but we needed something same for ZMK Studio. Ended up needing to do a Tauri app anyways, but is still annoying.
<Pete[m]1>
s/same/sane/, s/ /*/, s/,/*,/
<jason-kairos[m]>
is there a rust debug printing library for adding units to custom debug printers?
<jason-kairos[m]>
eg. if the units are ohms instead of `1200.0` it prints `1.2kΩ`
<jason-kairos[m]>
I figure engineering notation and real-world units are so common that somebody must have done this already.
<jason-kairos[m]>
This looks promising. Don't know if it prints, but it does know what kiloohms and milliohms are.
<davidmpye[m]>
I'm pondering a flash storage question - I have an access controller based on a picoW whose job is to download a database of 32byte RFID card hashes and store them on local storage (in case network is down) and search them when a card is presented. From time to time a new database will be generated, and the controller needs to check in with the server and download new version if applicable and overwrite the old one. I don't
<davidmpye[m]>
think either queue or the key store in sequential-storage are a perfect fit for this, as the update needs to be fairly quick, rather than an individual push for each hash? I suppose you could use the queue and peek to search, and then just empty it and start pushing new hashes in, but it sounds slow and I wonder whether just preparing and writing flash pages might be fastest? Id welcome any thoughts
<diondokter[m]>
<davidmpye[m]> I'm pondering a flash storage question - I have an access controller based on a picoW whose job is to download a database of 32byte RFID card hashes and store them on local storage (in case network is down) and search them when a card is presented. From time to time a new database will be generated,...
<diondokter[m]>
Also check out EKV, it might be closer to what you're looking for
<diondokter[m]>
But just taking a page and storing a repr C struct there can work too. Depends on your needs and how often you update
<JamesMunns[m]>
<dirbaio[m]> > <@davidmpye:matrix.org> I'm pondering a flash storage question - I have an access controller based on a picoW whose job is to download a database of 32byte RFID card hashes and store them on local storage (in case network is down) and search them when a card is presented. From time to time a new...
<JamesMunns[m]>
It's funny that this is 100% the use case ekv was invented for lol
cr1901 has quit [Read error: Connection reset by peer]
cr1901 has joined #rust-embedded
cr1901 has quit [Read error: Connection reset by peer]
cr1901 has joined #rust-embedded
cr1901 has quit [Read error: Connection reset by peer]
cr1901 has joined #rust-embedded
cr1901_ has joined #rust-embedded
cr1901 has quit [Ping timeout: 260 seconds]
<davidmpye[m]>
<diondokter[m]> But just taking a page and storing a repr C struct there can work too. Depends on your needs and how often you update
<davidmpye[m]>
Weekly at most, I suspect. It only needs an update when a new user is added and we don't have many 😊
<diondokter[m]>
davidmpye[m]: Then it turns out the product is a huge hit and because of that the product breaks 😉
danielb[m] has quit [Quit: Idle timeout reached: 172800s]
<davidmpye[m]>
Heh, it's a hack space access control system. We should be so lucky
timokrgr[m] has quit [Quit: Idle timeout reached: 172800s]
Noah[m] has quit [Quit: Idle timeout reached: 172800s]