<re_irc>
<@ryankurte:matrix.org> grantm11235:matrix.org: is this not a classic `impl <T: ChipSelect> Write for T where <T as Chipselect>::Inner: Write`?
<re_irc>
<@grantm11235:matrix.org> rustc is unconvinced by that. If your function only takes `T: Chipselect + Write` you can't use `T::Inner` as `Write`
<re_irc>
<@grantm11235:matrix.org> Even though as far as I can tell, with the blanket impl the only way to have `T: Chipselect + Write` is if `T::Inner: Write`
<re_irc>
<@grantm11235:matrix.org> I suppose that a future version of rustc could allow you to impl `Chipselect` and `Write` on your own as long as `Inner` does not impl `Write`
<re_irc>
<@grantm11235:matrix.org> There isn't actually a conflict in that case, but I guess rustc doesn't know that yet
<cr1901>
>If your function only takes `T: Chipselect + Write` you can't use `T::Inner` as `Write`
<cr1901>
You have a playground snippet I could look at? I can't visualize the recursion
<re_irc>
<@grantm11235:matrix.org> Basically I want to be able to do `impl<T> !Write for T where T: Chipselect, T::Inner: !Write`
troth has quit [Ping timeout: 260 seconds]
<re_irc>
<@grantm11235:matrix.org> That doesn't currently work because negative trait bounds are unsupported
troth has joined #rust-embedded
emerent has quit [Remote host closed the connection]
emerent has joined #rust-embedded
starblue has quit [Ping timeout: 256 seconds]
starblue has joined #rust-embedded
fabic has joined #rust-embedded
fabic has quit [Ping timeout: 264 seconds]
PyroPeter has quit [Ping timeout: 265 seconds]
PyroPeter has joined #rust-embedded
<re_irc>
<@charles:typ3.tech> https://docs.rs/embedded-hal/1.0.0-alpha.5/embedded_hal/pwm/blocking/trait.Pwm.html doesn't map well to the BL602, which allows setting/getting the period per channel. the PwmPin thing doesn't map great either since there are only 5 PWM channels to be shared by around 25 pins. is there any particular recommendation for modelling the BL602's setup using the existing traits, or am I just kind of out of luck...
<re_irc>
... (currently)?
<cr1901>
embedded HAL traits try their best, but they don't map to all possible embedded use cases :(
<cr1901>
(No I'm not still bitter that interrupt driven applications w/o an event loop are pessimized, why do you ask?)
<re_irc>
<@luojia65:matrix.org> Cargo fmt is okay, the image i posted just now may be misleading
mxshift has joined #rust-embedded
mxshift has left #rust-embedded [#rust-embedded]
<re_irc>
<@alex:matrix.sempto.net> Does anybody happen to know something that implements software UART. Maybe on STM32 if possible?
<re_irc>
<@newam:matrix.org> software UART as in bit banging pins?
<re_irc>
<@alex:matrix.sempto.net> Yeah
<re_irc>
<@alex:matrix.sempto.net> Ideally with timers and without busy waiting. But I'll take anything at this point
<re_irc>
<@alex:matrix.sempto.net> I'm all out of hardware UARTs on my current project. Normally I would just get a bigger chip but there are no chips to be had
<re_irc>
<@sajattack:matrix.org> unfortunately, UART is the weakest link of bitbang-hal
<re_irc>
<@sajattack:matrix.org> due to it's clockless nature
<re_irc>
<@sajattack:matrix.org> I haven't found a good way to get strict enough timing across multiple mcu platforms
<re_irc>
<@alex:matrix.sempto.net> It is a good starting point, thanks!
<re_irc>
<@newam:matrix.org> sajattack:matrix.org: At thing point I am starting to think there isn't one.
<re_irc>
<@newam:matrix.org> The whole time problem is so prevalent I am starting to think that the only solutions to a diverse set of platforms is a diverse set of solutions :/
<re_irc>
<@firefrommoonlight:matrix.org> charles:typ3.tech: What specifically is going on, and where are you running into problems?
<re_irc>
<@gauteh:matrix.org> if you use `write` and want to set multiple bits, you chain `field1().op().field2().op2()`
<re_irc>
<@dirbaio:matrix.org> interrupt registers are often "write 1 to clear" or "write 0 to clear"
<re_irc>
<@dirbaio:matrix.org> so you do a single write, and hte hardware processes it as an atomic read-modify-write internally
<re_irc>
<@dirbaio:matrix.org> i'm not sure if ther'es a cleaner way
<re_irc>
<@dirbaio:matrix.org> maybe if you're lucky the "reset vlaue" of all chips is already 1, so you just need the .clear_bit()
<re_irc>
<@gauteh:matrix.org> if the default reset value is 0xFFFF_FFFF should be ok with just write to that field
<re_irc>
<@dirbaio:matrix.org> usually the reset value of flags is 0 heh
<re_irc>
<@gauteh:matrix.org> so `reg.modify(|r, w| w.field().clear_bit())` would often work
<re_irc>
<@firefrommoonlight:matrix.org> Just the register table to see if it's "write only", "atomic writes" etc
<re_irc>
<@firefrommoonlight:matrix.org> *Sorry I should probably look this up; don't remember offhand
<re_irc>
<@firefrommoonlight:matrix.org> Gotcha
<re_irc>
<@firefrommoonlight:matrix.org> Some interrupts don't need to clear a flag
<re_irc>
<@firefrommoonlight:matrix.org> RTC you also *set* the bit
<re_irc>
<@alex:matrix.sempto.net> I'm trying to understand what happens when you use clear_bit() or set_bit() when writing to a register with a PAC.
<re_irc>
<@alex:matrix.sempto.net> From my understanding it does not do a rmw. So if I clear a single bit in a register it will set all the other bits to 1, right?
<re_irc>
<@alex:matrix.sempto.net> gauteh:matrix.org: My concern is with clearing the interrupt flags.
<re_irc>
<@alex:matrix.sempto.net> gauteh:matrix.org: reset to their default values?
<re_irc>
<@alex:matrix.sempto.net> If clear_bit() sets the interrupt flag to 0 and the other bits to 0 as well (reset values) won't this also clear all the other interrupts?
<re_irc>
<@alex:matrix.sempto.net> But then I might clobber an incoming interrupt
<re_irc>
<@alex:matrix.sempto.net> If it arrives during rmw
<re_irc>
<@alex:matrix.sempto.net> In my case (stm32) it is write 0 to clear, 1s are ignored.
<re_irc>
<@alex:matrix.sempto.net> So basically I need to write all 1s except the bit I want to clear
<re_irc>
<@alex:matrix.sempto.net> But it seems like a race condition waiting to happen
<re_irc>
<@alex:matrix.sempto.net> I mean, writing the pattern manually with bits() would solve it as well.
<re_irc>
<@alex:matrix.sempto.net> It is just... unelegant...
<re_irc>
<@alex:matrix.sempto.net> And HAL using a modify is concerning as well...
<re_irc>
<@alex:matrix.sempto.net> gauteh:matrix.org: Probably not. With modify you read the register, clear the bit, then write it back. If an interrupt comes in before you write it back it is lost
<re_irc>
<@alex:matrix.sempto.net> If i just write the whole register with all 1s with bits() (except the bits I want to clear) it is just a single write.
<re_irc>
<@alex:matrix.sempto.net> The 1s are ignored, the 0s clear the interrupt bits.
<re_irc>
<@alex:matrix.sempto.net> The datasheet in question: file:///tmp/mozilla_alex0/rm0041-stm32f100xx-advanced-armbased-32bit-mcus-stmicroelectronics.pdf
<re_irc>
<@alex:matrix.sempto.net> page 442
<re_irc>
<@alex:matrix.sempto.net> And the meaning of rc_w0 is "Software can read as well as clear this bit by writing 0. Writing ‘1’ has
<re_irc>
<@alex:matrix.sempto.net> no effect on the bit value."
<re_irc>
<@gauteh:matrix.org> I don't see how you can guard against new interrupts happening in the mean-time without using a critical-section or disabling interrupts.
<re_irc>
<@firefrommoonlight:matrix.org> Fortunately, mistakes here aren't subtle - they manifest in your ISR firing repeatedly!
<re_irc>
<@alex:matrix.sempto.net> Maybe therealprof or thezoq2as stm32f1xx-hal mantainers can look into it. The potential race condition is concerning.
<re_irc>
<@firefrommoonlight:matrix.org> I just learned something re what rc_w0 means
<re_irc>
<@firefrommoonlight:matrix.org> Going to fix that in my code too
<re_irc>
<@gauteh:matrix.org> Maybe there's a way to get the regspec struct initialized from a value (rather than register), then you can clear the bit on that and pass it to w.bits()
<re_irc>
<@firefrommoonlight:matrix.org> It looks like `rc` is the same concept, meaning write 1 to atomically perform the action
fabic has joined #rust-embedded
<re_irc>
<@jamesmunns:beeper.com> Has anyone messed with the new WSL USB support for things like probe-rs/probe-run yet?
<re_irc>
<@firefrommoonlight:matrix.org> - ISR2, of higher priority fires, completes
<re_irc>
<@firefrommoonlight:matrix.org> - ISR1 clears its flag, continue as normal.
<re_irc>
<@firefrommoonlight:matrix.org> - ISR 1 reads its flag status (SR, ICSR etc)
<re_irc>
<@firefrommoonlight:matrix.org> Since ISR1 can't preempt itself, you shouldn't run into weird behavior. Is that correct, or is there a trap somewhere?
<re_irc>
<@firefrommoonlight:matrix.org> Knowing the process is atomic, ie you don't need to read, I agree it's better to just do the `write`, and I plan to change my code bases to do this
<re_irc>
<@firefrommoonlight:matrix.org> I guess the trap would be if the higher pri ISR modifies the same status register, the lower pri one wouldn't set itcorrectly
<re_irc>
<@ubik:matrix.org> I was wondering if there was something ready-made in `stm32f4xx-hal`
<re_irc>
<@firefrommoonlight:matrix.org> Doesn't look like it. PR, and its maintainers here
<re_irc>
<@firefrommoonlight:matrix.org> I'd get rid of the setting-as-hertz API too, since the way STM32 clocks SPI, the precision set when configuring the periph itself is in factors of 2
<re_irc>
<@firefrommoonlight:matrix.org> So it's easy to have the speed be way off from what you expected, with no indication
<re_irc>
<@firefrommoonlight:matrix.org> (If you want precise freqs, you need to change it upstream in RCC)
<re_irc>
<@ubik:matrix.org> hm... the sd card stops responding when I switch freq
<re_irc>
<@ubik:matrix.org> even if I keep the same
<re_irc>
<@wucke13:matrix.org> How do I interprete this error message:
<re_irc>
<@wucke13:matrix.org> ```rust
<re_irc>
<@wucke13:matrix.org> error[E0277]: the trait bound `Adc<ADC0>: OneShot<Adc<ADC0>, u16, _>` is not satisfied
<re_irc>
<@ubik:matrix.org> silly me, using `.write(...)` instead of `.modify(...)` 🤦
<re_irc>
<@charles:typ3.tech> firefrommoonlight:matrix.org: BL602 allows controlling each of the five channels' periods individually but the Pwm trait does not. PwmPin doesn't map well either, since a channel may be used by multiple pins at once (and also doesn't allow controlling the period at all).
<re_irc>
<@charles:typ3.tech> I'm not having any problems *using* an implementation, I'm having this problem while *making* one. I think my solution is going to be to implement the Pwm trait and then also have some specific functions for the BL602's "special" capabilities
<re_irc>
<@grantm11235:matrix.org> Can you implement the `Pwm` trait separately for each of the 5 channels?
<re_irc>
<@therealprof:matrix.org> gauteh:matrix.org: I'm still not sure what the problem is supposed to be. RMW is certainly more correct than just using `write()`, even if the reset value would be taken into account since it is all zeros (so any clearing of the interrupt flag would clear all other conditions as well). If anything this could make use of bitbanding instead of RMW to just clear a single bit.
<re_irc>
<@gauteh:matrix.org> So the issue wan't really mine (nor does it affect me), so I am just asking out of curiosity: the fix in libopencm3: I'm not sure that doesn't work on bytes rather than bits either? secondly, i don't think just writing rather than rmw actually fixes any issues. but there is a difference to doing rmw and constructing say `0b111111011111`, and writing that. the `1`'s won't have any effect in this case.
<re_irc>
<@adamgreig:matrix.org> the svd file can in theory say "these bits are rc_w1" and in principle svd2rust could be taught to therefore default them to 1 or something like that
<re_irc>
<@gauteh:matrix.org> adamgreig: Oh, that's good to know about. Didn't think about that situation.
<re_irc>
<@grantm11235:matrix.org> That register has two different meanings depending on whether you are reading or writing it, so I don't think it really makes sense to RMW it
<re_irc>
<@gauteh:matrix.org> What is the best way to clear or set a single bit using svd/pac's without using `modify`?
<re_irc>
<@gauteh:matrix.org> I guess the smallest type in rust is a byte, and it seems like at least AVR has instructions for setting single bits, presumably arm too. Is it possible to write rust-code that works on bits and not bytes?
<re_irc>
<@grantm11235:matrix.org> You don't want to set or clear a single bit in this case, you want to write the whole register to all ones except for the flag that you are clearing
<re_irc>
<@gauteh:matrix.org> Yes, that's what happens, but that's not necessary. At least on platforms where `FIELD |= 1` sometimes compiles to only set a bit in C
<re_irc>
<@charles:typ3.tech> grantm11235:matrix.org: Hmm perhaps, and make the `Channel` associated type be `()`. Might do that actually
<re_irc>
<@ubik:matrix.org> Dammit. I have some code which works perfectly with SPI2 and fails with SPI1
<re_irc>
<@newam:matrix.org> Probably one of those :P
<re_irc>
<@ubik:matrix.org> You SPI1 may be underpowered?
<re_irc>
<@ubik:matrix.org> And resets?
<re_irc>
<@newam:matrix.org> For some MCUs you can turn off power islands, I don't think any STM32 products have that.
<re_irc>
<@newam:matrix.org> For resets, SPI1/SPI2 have separate resets in RCC, if one of them is held in reset that can do weird things.
<re_irc>
<@newam:matrix.org> I used to do silicon validation for work, I spent 50% of my time with customers on clocking/resets/power, that's why I always bring it up.
<re_irc>
<@firefrommoonlight:matrix.org> Re the write vs modify for clearing interrupt flags - I'm actually not sure. Some periphs like RTC and `ifcr` registers that are explicitly atomic writes
<re_irc>
<@firefrommoonlight:matrix.org> Same with DMA
<re_irc>
<@firefrommoonlight:matrix.org> While timer, exti etc that we were discussing, it's not so clear. Thoughts?
<re_irc>
<@adamgreig:matrix.org> what do you mean, explicitly atomic writes?
<re_irc>
<@firefrommoonlight:matrix.org> So, obviously if there's an IFCR, which is write only, you do write, and it's atomic. Done
<re_irc>
<@firefrommoonlight:matrix.org> What do we do about the others?
<re_irc>
<@firefrommoonlight:matrix.org> (As I said earlier, I don't think the trap for modify is real, but to be pure...)
<re_irc>
<@dirbaio:matrix.org> using .modify there is almost always a race condition yep
<re_irc>
<@firefrommoonlight:matrix.org> Sweet. Switching to `write` in my code bases
<re_irc>
<@dirbaio:matrix.org> and wrapping it in `interrupt::free` does *not* help, it can stil lrace
<re_irc>
<@whitequark:matrix.org> it makes more sense if you consider how the write looks like from *peripheral's* point of view
<re_irc>
<@adamgreig:matrix.org> i think all the peripherals support an "atomic" clearing of a single interrupt flag, it's just some are rc_w0 and some are rc_w1 and the latter doesn't play as nicely with the current svd2rust setup of mostly writing 0s/reset values
<re_irc>
<@firefrommoonlight:matrix.org> for ones with `IFCR`, `ICR` etc, I've had it as `write` all along
<re_irc>
<@adamgreig:matrix.org> otherwise there's not really a difference between a separate status and clear register where you write 1s to clear, and a combined read-for-status, write-0-to-clear where 1s are ignored
<re_irc>
<@firefrommoonlight:matrix.org> For timers and exti, where you use the status reg (ie the same one you read from), I made the same mistake the linked issues were about
<re_irc>
<@adamgreig:matrix.org> right, yea. I guess it's confusing especially because `modify` will often appear to work, since it will read a 1 from the other fields and write it back, leaving them unchanged
<re_irc>
<@adamgreig:matrix.org> whereas `write` would always write 0s to those fields, clearing them
<re_irc>
<@firefrommoonlight:matrix.org> The bulletted list I posted about is my thoughts on what would actually happen if it gets interrupted
<re_irc>
<@adamgreig:matrix.org> I'm not really sure what you're describing with the bullet list
<re_irc>
<@adamgreig:matrix.org> the interrupt priorities isn't hugely relevant is it?
<re_irc>
<@adamgreig:matrix.org> the bits get set by the peripheral
<re_irc>
<@adamgreig:matrix.org> (i.e. before the isr runs)
emerent has quit [Ping timeout: 268 seconds]
emerent has joined #rust-embedded
<re_irc>
<@adamgreig:matrix.org> your top-prio isr could read from the reg and get a 0 for the other flag, set the bit it's interested to to 1 to clear it, then the peripheral sets the other flag to 1 because the event has happened, and your isr then writes back its value with a 0, clearing that flag
<re_irc>
<@firefrommoonlight:matrix.org> ISR 1 reads its flag status (SR, ICSR etc)
<re_irc>
<@firefrommoonlight:matrix.org> ISR2, of higher priority fires, completes
<re_irc>
<@firefrommoonlight:matrix.org> Since ISR1 can't preempt itself, you shouldn't run into weird behavior.
<re_irc>
<@firefrommoonlight:matrix.org> ISR1 clears its flag, continue as normal.
<re_irc>
<@firefrommoonlight:matrix.org> Ah - good point
<re_irc>
<@adamgreig:matrix.org> sadly, none of the ST SVDs use modifiedWriteValues _anywhere_, which means even if/once svd2rust supports them, it will be an uphill fight to make the PACs right
<re_irc>
<@firefrommoonlight:matrix.org> That *is* a trap
<re_irc>
<@adamgreig:matrix.org> that trap is what dirbaio meant by "wrapping it in interrupt:free does not help" I believe
<re_irc>
<@firefrommoonlight:matrix.org> (Thankfully, this is a non-issue for many periphs, which have separate regs to read and clear status flags, eg `IFCR`, `ICR`)
<re_irc>
<@adamgreig:matrix.org> separate register doesn't really make any difference, it's just whether it's rc_w1 or rc_w0
<re_irc>
<@adamgreig:matrix.org> you can imagine as though read and write just happen to different registers even if the address is the same, the peripheral just decides what to do
<re_irc>
<@adamgreig:matrix.org> in a situation where you read a status register and write back 1s to clear any set flags, modify() would also be quite confusing, but at least write() would be easy and work just like the separate flag-clear registers
<re_irc>
<@grantm11235:matrix.org> Does svd2rust support having a separate read-only and write-only register at the same address?
<re_irc>
<@adamgreig:matrix.org> sure, it supports having completely different registers at the same address
<re_irc>
<@grantm11235:matrix.org> Because that is really what it is, imo
<re_irc>
<@adamgreig:matrix.org> I don't think that's what it is really
<re_irc>
<@adamgreig:matrix.org> wellllll I guess it might be nice to not have modify()?
<re_irc>
<@adamgreig:matrix.org> but what it is is the svd modifiedWriteValues attribute for each field
<re_irc>
<@grantm11235:matrix.org> It is a status register when you read from it, and a flag reset register when you write to it
<re_irc>
<@adamgreig:matrix.org> some fields are, but not necessarily all of them
<re_irc>
<@firefrommoonlight:matrix.org> Of note: Let's look at a timer, like TIM3. There's going to be only 1 ISR that uses it, so nothing should race with its SR
<re_irc>
<@adamgreig:matrix.org> like in the RTC where the bits are a mix of rc_r0, r-only, rw, etc
<re_irc>
<@firefrommoonlight:matrix.org> It doesn't matter if another timer's ISR etc interrupts it
<re_irc>
<@adamgreig:matrix.org> firefrommoonlight: that one timer has multiple events that can set flags in the sr independently, like ug, cc1, oc, etc
<re_irc>
<@adamgreig:matrix.org> your isr can do a modify and race those events happening
<re_irc>
<@firefrommoonlight:matrix.org> Ah good pt
<re_irc>
<@adamgreig:matrix.org> some timers have multiple isrs _too_, like tim1 has break and update and trigger ISRs, though tim3 usually is just one global isr
<re_irc>
<@adamgreig:matrix.org> but the problem is the same, the flag bits are set by the peripheral without a care to the current execution context/priority/critical section/etc
<re_irc>
<@firefrommoonlight:matrix.org> Another good pt
<re_irc>
<@adamgreig:matrix.org> SVD can encode all this per-field in order that tools like svd2rust could generate much less footgunny APIs, probably including just not having modify() at all on registers with rc_w* fields? that's arguable I guess, though
<re_irc>
<@adamgreig:matrix.org> but in any event it would be able to default rc_w0 fields to 1 and rc_w1 fields to 0
<re_irc>
<@firefrommoonlight:matrix.org> This feels like a socratic dialog where I'm simplicio, and everyone reading is learning
<re_irc>
<@adamgreig:matrix.org> which is all you need to never accidentally race/clear something you didn't mean to
<re_irc>
<@adamgreig:matrix.org> whereas what we have now with either `modify()` or `write()` can lead to some great subtle footguns, for sure
<re_irc>
<@adamgreig:matrix.org> just... none of the stm32 svds are so marked
<re_irc>
<@firefrommoonlight:matrix.org> Thankfully, I don't think I've hit those footguns, by chance
<re_irc>
<@adamgreig:matrix.org> (and in the easy cases where you have a separate clear-flag register with rc_w1 it's basically a non-issue)
<re_irc>
<@adamgreig:matrix.org> as to why half the flags are rc_w0 in the status register and the other half are rc_w1 in a separate flag-clear register, ~~god~~ST only knows
<re_irc>
<@firefrommoonlight:matrix.org> EXTI seems especially vulnerable, since each one is used by multiple ports, and some (Eg ones 5+) are shared even among the same port
<re_irc>
<@adamgreig:matrix.org> I reckon either synopsys's fault or maybe warring tribes within ST?
<re_irc>
<@firefrommoonlight:matrix.org> Timer is the one that comes to mind that clears with 0, and doesn't have an IFCR
<re_irc>
<@adamgreig:matrix.org> yea indeed, and very commonly used for interrupts too
<re_irc>
<@adamgreig:matrix.org> I wonder if we should just cheat and set the resetValue to 0xFFFF_FFFF for any register that's entirely rc_w0 fields like the timer SRs
<re_irc>
<@adamgreig:matrix.org> it means write() would only affect the fields you specifically indicate
<re_irc>
<@adamgreig:matrix.org> instead of affecting mostly the fields you don't specify, heh
<re_irc>
<@grantm11235:matrix.org> Or do what dirbaio did and get rid of reset values entirely
<re_irc>
<@adamgreig:matrix.org> oh, yea, I mean if we were going to do that I'd also like for write() to not start at the reset value, but that's what we have write_with_zero for in svd2rust
<re_irc>
<@adamgreig:matrix.org> and it wouldn't help in this case at all
<re_irc>
<@adamgreig:matrix.org> does embassy's pacs respect modifiedWriteValues or do anything for rc_w0 fields?
<re_irc>
<@adamgreig:matrix.org> (i.e. what happens if you want to clear a single field in something like a stm32 timer sr?)
<re_irc>
<@dirbaio:matrix.org> no, and the yamls don't even have it because the svd's don't have it.
<re_irc>
<@therealprof:matrix.org> grantm11235:matrix.org: How do you mean? Writes with certain bits are overloaded for such registers but other than that it's just the same as with just a regular register; you really don't want to change unrelated bits.
<re_irc>
<@dirbaio:matrix.org> write defaults to all zeros
<re_irc>
<@adamgreig:matrix.org> my kingdom for perfect svds, as usual
<re_irc>
<@grantm11235:matrix.org> therealprof:matrix.org: I'll take your word for it, I am not familiar with the exact registers that we are talking about. I was (incorrectly) assuming that all the bits in the register were flag status/flag reset bits
<re_irc>
<@adamgreig:matrix.org> often they are, and in that case at least disabling modify() probably makes sense
<re_irc>
<@adamgreig:matrix.org> but they're not always, really it should be a per-field thing
<re_irc>
<@adamgreig:matrix.org> I guess the C people just got used to writing `TIM3->SR = ~(TIM3_SR_UIF);` or whatever
<re_irc>
<@therealprof:matrix.org> gauteh:matrix.org: Most registers in ARM MCUs can be written with 32bit aligned addresses only. Sometimes it is permissible to do 8bit or 16bit reads or writes to those 32bit aligned addresses and they could have different behaviour. Bit access is only available for some MCUs which support bit banding.
<re_irc>
<@therealprof:matrix.org> grantm11235:matrix.org: What adamgreig said. However it's also not guaranteed that all bits are hardware driven (i.e. they don't ignore software sets to bits), some peripherals also allow changing whether a status bis is hardware or software controlled via other registers.
<re_irc>
<@ubik:matrix.org> ubik:matrix.org: Interesting... if I use the SPI1 pin set in GPIOB (instead of GPIOA), it works fine
<re_irc>
<@grantm11235:matrix.org> therealprof:matrix.org: So the `modifiedWriteValues` would need to be different depending on the state of the hardware? Can SVDs support that?
<re_irc>
<@therealprof:matrix.org> dirbaio:matrix.org: In that particular case the reset value is also all zeros so even using that wouldn't help.
<re_irc>
<@therealprof:matrix.org> I don't really see what a one does all implementation would look like. There might be situations where you really want to clear all status flags and others where you only want to clear a single bit.
troth has quit [Ping timeout: 260 seconds]
<cr1901>
Is Yatekii on the Matrix side of the bridge?
<re_irc>
<@therealprof:matrix.org> Yatekii is now Noah
<cr1901>
Ahhh no problem. Was just wondering if a crate like "mspdebug-driver" would be acceptable to put under the probe-rs workspace
troth has joined #rust-embedded
<re_irc>
<@yatekii:matrix.org> cr1901: yes i am :)
<re_irc>
<@yatekii:matrix.org> irc_libera_cr1901:psion.agg.io: yes it would be very welcome :)
<cr1901>
yatekii: I'll look into this into the coming weeks, then. Are you around for a few questions?
<cr1901>
Well, let me provide first-order approx context: "mspdebug" is essentially "probe-rs for msp430 world, in C"
<cr1901>
I can't take out the parts of mspdebug I want and put them into a library for probe-rs because of licensing
<cr1901>
In other words, instead of linking in a library, you talk to another process across stdout/in
<cr1901>
My overarching q is "how do I get this functionality into probe-rs, so at least the framework for msp430 probe-rs Rust drivers is set for later?"
<re_irc>
<@windfisch42:matrix.org> heya! I am attempting to write an embedded USB host framework similar to usb-device, just for hosts. I am aware that with usb-host by bjc, previous work on this exists, but this seems to do only blocking I/O (stalling the uC while waiting for replies from the usb device), so I decided to play around with async/await a bit...
<re_irc>
<@windfisch42:matrix.org> In the end, I sort-of built my own tiny async executor which only handles the relevant bits, slightly abusing the Future api to fit my needs. It looks rather promising to me, even though I wonder how one could cleanly expose that API for driver authors. In the next weeks, I would love to get some more input on my attempt.
<re_irc>
<@newam:matrix.org> Embassy (https://matrix.to/#/#embassy-rs:matrix.org) has traits for async peripherals, they may have some good reference material for USB async things.