<re_irc>
<@ubik:matrix.org> Question: do you guys do hardware debouncing with a cap at all? Or do you just use the internal pull-up/pull-down and debounce in software?
<re_irc>
<@xiretza:xiretza.xyz> depends on space and budget I guess, if you can afford to put a resistor, cap and schmitt trigger on every button, do it
<re_irc>
<@ubik:matrix.org> Schmitt trigger might be a bit too space-consuming, but a cap and resistor, why not
<re_irc>
<@ubik:matrix.org> But I was wondering whether I can just add a cap, since there is already the internal pull-up?
<re_irc>
<@xiretza:xiretza.xyz> you need the resistor between the button and the cap, otherwise pressing the button will just immediately short the cap and you won't get much debouncing unless it has a huge capacitance (to the point where the resistance of the button becomes enough to limit the discharge)
troth has quit [Ping timeout: 260 seconds]
troth has joined #rust-embedded
<re_irc>
<@eldruin:matrix.org> adamgreig: inconsistent data is indeed possible if used like you said. One difference would be in communication/computation cost: reading 1 register + conversion vs 8 registers + conversion but I guess you can always hit a wraparound except you are only interested in the year (but in that case the efficiency case is indeed negligible).
_whitelogger has joined #rust-embedded
<re_irc>
<@eldruin:matrix.org> Normally when I write a driver I follow the principle that through the driver it should be possible to do anything that is possible interacting directly with the hardware as to avoid making a case _against_ using the driver. That is where `rtcc` comes from. However, I see your point, and I think I could offer only get/set datetime methods in `Rtcc` and offer the others directly in the drivers
fabic has quit [Ping timeout: 250 seconds]
<re_irc>
<@eldruin:matrix.org> w.r.t. downstream breakage I think we would be fine, since it would only make sense to have one `Rtcc` trait in scope, the one coming from the HAL impl or from an external peripheral driver
<re_irc>
<@ryan-summers:matrix.org> Is there a `heapless::String`-equivalent that can be constructed with a provided [u8] slice as the underlying memory buffer?
<re_irc>
<@ryan-summers:matrix.org> E.g. using user-provided byte slices instead of const-generics
<re_irc>
<@ryan-summers:matrix.org> ```rust
<re_irc>
<@ryan-summers:matrix.org> let mut buffer = [0u8; 128]'
<re_irc>
<@ryan-summers:matrix.org> let mut string = String::from(&mut buffer);
<re_irc>
<@ryan-summers:matrix.org> Something like
<re_irc>
<@korken89:matrix.org> Not that I'm aware of, but would be a nice addition if you feel like PRing it :) The same for Vec with user provided byte slice
<re_irc>
<@ryan-summers:matrix.org> I might take a look at it. I'm writing some libraries that are making some string length assumptions, and it seems like using smoltcp's approach of letting the user pass in storage is the easiest way to manage it
<re_irc>
<@ryan-summers:matrix.org> Then you don't need to worry about a billion const-generic arguments on your type
<re_irc>
<@ryan-summers:matrix.org> AFAICT it'd be a new `BufferedString` type though, since the const generic argument would fall off, which has the downside of having to copy a lot of the `String` impl over
<re_irc>
<@jamesmunns:beeper.com> I actually based that on wq's Managed type
<re_irc>
<@jamesmunns:beeper.com> But in my use case I never have to mutate the borrowed item, it's mostly for deserialization
<re_irc>
<@jamesmunns:beeper.com> I'm also now realizing that type is silly, because it's always the size of the heapless string
<re_irc>
<@jamesmunns:beeper.com> But, I plan to replace it with my byte-slab pool allocator, so it would be even closer to what Ryan is asking for, since byte-slab only gives out [u8; N] blocks
<re_irc>
<@ryan-summers:matrix.org> Yeah, I don't care about lifetimes because my use case is only for transient in-scope operations. I never want to hand around the string as a serious return value
<re_irc>
<@ryan-summers:matrix.org> E.g. mutate a u8 slice into a "string" for string-formatting purposes, and then the user now has a formatted string in the buffer they provided once complete
<re_irc>
<@ryan-summers:matrix.org> Although your points about ownership may be valid, since I don't know if you can return a shorter slice ref to the input slice
<re_irc>
<@thejpster:matrix.org> Do we have any good examples covering the many different ways there are of using a Device HAL peripheral in an interrupt?
<re_irc>
<@thejpster:matrix.org> I can think of 1. a `static Mutex<Rc<Option<THING>>>`, 2. an unsafe `static mut Option<THING>`, 3. rtic, 4. unsafe `core::ptr::volatile_read(THING_REGISTER_ADDRESS)`
<cr1901>
5. Mutex<OnceCell<>>?
fabic has quit [Ping timeout: 268 seconds]
rardiol has joined #rust-embedded
<re_irc>
<@thejpster:matrix.org> the matklad one, or the unstable one in std?
<re_irc>
<@ryan-summers:matrix.org> Has anyone dealt with suspendable iteration in Rust yet? We essentially created an iterator that stores state in an array of indices, and you can re-create the iterator with the state at some point in the future to resume iteration where you left off
<re_irc>
<@ryan-summers:matrix.org> I'm curious if there's already pre-existing traits around this type of behavior
<re_irc>
<@ryan-summers:matrix.org> We needed the iterator to actually deconstruct between iterations because it was borrowing underlying data that was used elsewhere in other contexts
<cr1901>
thejpster: the matklad one
<re_irc>
<@ryan-summers:matrix.org> tl;dr - we want to do
<re_irc>
<@ryan-summers:matrix.org> for item in settings.into_iter(&mut state) {
<re_irc>
<@ryan-summers:matrix.org> if process(item).is_err() { break; }
<re_irc>
<@xiretza:xiretza.xyz> can't you just store the state in `settings`? also, it's not really `into_` if it doesn't consume `settings`
fabic has joined #rust-embedded
<re_irc>
<@ryan-summers:matrix.org> True, the API violates the `IntoIterator` trait as well. The problem we have is that `settings` is a user-defined struct that we're writing a proc-macro around
<re_irc>
<@ryan-summers:matrix.org> I guess the proc-macro could add the state to the structure
<re_irc>
<@ryan-summers:matrix.org> But the state size isn't necessarily known at compile time either
fabic has quit [Ping timeout: 250 seconds]
nexgen has joined #rust-embedded
nexgen has quit [Read error: Connection reset by peer]
nexgen has joined #rust-embedded
nexgen has quit [Read error: Connection reset by peer]
nexgen has joined #rust-embedded
nexgen has quit [Remote host closed the connection]
<re_irc>
<@dngrs:matrix.org> I mean it's not *pretty* but it works 🤷
loki_val has quit [Remote host closed the connection]
crabbedhaloablut has joined #rust-embedded
<re_irc>
<@firefrommoonlight:matrix.org> thejpster:matrix.org: https://www.anyleaf.org/blog/writing-embedded-firmware-using-rust - "Avoiding race conditions" section, mostly towards the bottom. Unsurprisingly, it's your list, - the volatile reads (Which are discussed earlier in the article), and + Async