<re_irc> <@j​amesmunns:m​atrix.org> Now with actual docs and examples: https://docs.rs/choreographer/
starblue has joined #rust-embedded
starblue3 has quit [Ping timeout: 265 seconds]
Wetmelon has quit [Ping timeout: 244 seconds]
fabic has quit [Ping timeout: 258 seconds]
hifi_ has joined #rust-embedded
re_irc_ has joined #rust-embedded
emerent_ has joined #rust-embedded
emerent has quit [Killed (mercury.libera.chat (Nickname regained by services))]
starblue1 has joined #rust-embedded
starblue has quit [*.net *.split]
hifi has quit [*.net *.split]
GenTooMan has quit [*.net *.split]
re_irc has quit [*.net *.split]
GenTooMan has joined #rust-embedded
<re_irc_> <@e​vils.devils:m​atrix.org> braincode: to clarify, that was on an esp8266 and stm32f103
<re_irc_> <@e​vils.devils:m​atrix.org> and i did switch to platformio before never touching that stuff again xD
<re_irc_> <@e​vils.devils:m​atrix.org> that's to say, arduino the software, not the hardware
hifi_ is now known as hifi
fabic has joined #rust-embedded
<re_irc_> <@b​urrbull:m​atrix.org> Now we have 3 different ways in stm32 hals to work with rcc:
<re_irc_> <@b​urrbull:m​atrix.org> - in `f1/f7` peripheral inits require APB structs `let mut gpiob = p.GPIOB.split(&mut rcc.apb2);`, that we can take with `RCC.constrain()`.
<re_irc_> <@b​urrbull:m​atrix.org> - in `g0` they require `&mut RCC`: `let gpioa = dp.GPIOA.split(&mut rcc);`.
<re_irc_> <@b​urrbull:m​atrix.org> - in `f4` and some other just `let gpiob = device.GPIOB.split();` and `unsafe { let rcc = &(*RCC::ptr()); }` in sources.
<re_irc_> <@b​urrbull:m​atrix.org> We need to do something with this difference.
fabic has quit [Ping timeout: 258 seconds]
<re_irc_> <@s​ympatron:m​atrix.org> riskable: I think it's an interesting approach. Took me a few minutes to understand - it probably needs more comments.
<re_irc_> <@s​ympatron:m​atrix.org> Maybe it would need less macro magic if there was a way to turn a struct into valid rust code. Don't know if there is one.
<re_irc_> <@k​orken89:m​atrix.org> braincode: Correct, the syntax is fine, but the codegen is core specific today.
<re_irc_> <@f​loere:m​atrix.org> floere: Hello Everyone,
SomeWeirdAnon has joined #rust-embedded
SomeWeirdAnon has quit [Client Quit]
SomeWeirdAnon has joined #rust-embedded
crabbedhaloablut has quit [Remote host closed the connection]
crabbedhaloablut has joined #rust-embedded
<re_irc_> <@d​aja_2:m​atrix.org> Hi everyone, I am a bit confused about timers in the nrf52840 crate. What does it mean that it is hardcoded at 1 Mhz?
<re_irc_> <@d​aja_2:m​atrix.org> Does it mean periodic timers always have 1 000 000 cycles per second? That we can't do prescalers?
<re_irc_> <@d​aja_2:m​atrix.org> What happenens when we do some_periodic_timer.start(some_value)?
<re_irc_> <@j​amesmunns:m​atrix.org> So, there's two things, the prescaler, which is "how fast the timer ticks", and the count value, which is "how many ticks before the timer is done"
<re_irc_> <@j​amesmunns:m​atrix.org> At the moment - we do hardcode the prescaler to generate 1us ticks
<re_irc_> <@d​aja_2:m​atrix.org> Thanx! It is also written "The timer will **always** be hardcoded to a frequency of 1 MHz and 32 bits accuracy." So it's a conditional always, that accepts prescaling?
<re_irc_> <@d​aja_2:m​atrix.org> And when you do .start(max_value), this max value corresponds to us ticks right now, correct?
<re_irc_> <@j​amesmunns:m​atrix.org> yep!
<re_irc_> <@j​amesmunns:m​atrix.org> that's just a limitation of our current driver impl though. You could implement a more general interface, just no-one has yet.
fabic has joined #rust-embedded
<re_irc_> <@d​aja_2:m​atrix.org> jamesmunns: I think it's enough for a rough implementation, I will switch to rtic when it's time like all the cool embedders 😀
<re_irc_> <@t​herealprof:m​atrix.org> Ai Maiga (dajamante): Do I sense another of your excellent projects coming up? 😀
<re_irc_> <@d​aja_2:m​atrix.org> therealprof: It will be a Ferrous excellent (I hope!!!) project !
<re_irc_> <@t​herealprof:m​atrix.org> ... and I was hoping for a spoiler. 😅
<re_irc_> <@t​halesfragoso:m​atrix.org> burrbull: Some of it is causing by the lacking of bit banding too
<re_irc_> <@t​halesfragoso:m​atrix.org> But we can always go with CSes or try the weird volatile atomics
<re_irc_> <@d​irbaio:m​atrix.org> `cursed_atomics`
<re_irc_> <@j​amesmunns:m​atrix.org> Wouldn't volatile atomics just be called `radioactive`?
<re_irc_> <@d​irbaio:m​atrix.org> `chernobyl`
<re_irc_> <@t​halesfragoso:m​atrix.org> jamesmunns: Nice name for the crate
<re_irc_> <@j​amesmunns:m​atrix.org> Still free, if someone has something to publish right now :D
<re_irc_> <@d​irbaio:m​atrix.org> a decent crate name that's not been squatted, what's this
<re_irc_> <@t​halesfragoso:m​atrix.org> Don't give people ideas, someone still needs to write that crate
<re_irc_> <@b​radleyharden:m​atrix.org> floere, I think you're going to need to ask more targeted questions. That's a decent sized code dump. You might also see if your specific chip has its own Matrix channel
<re_irc_> <@d​irbaio:m​atrix.org> #stm32-rs:matrix.org
<re_irc_> <@f​loere:m​atrix.org> bradleyharden: Ok, I'll do that.
<re_irc_> <@f​loere:m​atrix.org> dirbaio: Thanks!
<re_irc_> <@d​aja_2:m​atrix.org> therealprof: I guess there will be many spoilers with coming questions!
<re_irc_> <@r​yan-summers:m​atrix.org> floere: I recently did USB-CDC implementation with RTIC, but the project is unfortunately closed-source. I remember that some of the USB structures had some rather complex ownership semantics, such that I had to end up storing some of the USB control structures in global static muts instead of RTIC...
<re_irc_> ... resources.
<re_irc_> <@r​yan-summers:m​atrix.org> I ended up storing the USB serial and UsbBusAllocator structures in static mut options in the `init()` function so they never went out of scope
<re_irc_> <@r​yan-summers:m​atrix.org> That is, if you're using the `usb_device` crate
<re_irc_> <@r​yan-summers:m​atrix.org> It's a very similar style to what `shared-bus` does to keep shared I2c/SPI buses around so you can freely reference them
<re_irc_> <@r​yan-summers:m​atrix.org> But yeah, ask a more pointed question if you need more information. I don't have time to review your source code, sorry
fabic has quit [Ping timeout: 250 seconds]
<re_irc_> <@f​loere:m​atrix.org> ryan-summers: Thank you for the tips. share-bus is something I didn't know about yet, and will need soon enough for I2C.
<re_irc_> <@f​loere:m​atrix.org> And I'll target my questions better from now on.
<re_irc_> <@r​yan-summers:m​atrix.org> For I2C, I believe `shared-bus` should support RTIC. I don't believe it does for SPI if you use the resource in multiple prios though
<re_irc_> <@f​loere:m​atrix.org> ryan-summers: Good to know. Fortunately, I only need I2C for this project.
<re_irc_> <@r​yan-summers:m​atrix.org> shared-bus-rtic would enable you to use SPI if you ever needed it. I'm trying to deprecate `shared-bus-rtic`, but there's some issues with the e-h traits around SPI preventing it for now
fabic has joined #rust-embedded
<re_irc_> <@a​rbitrix:m​atrix.org> ryan-summers: ryan-summers: `shared-bus-rtic` has been a lifesaver for me (SPI). What would replace the deprecated version?
<re_irc_> <@r​yan-summers:m​atrix.org> Ideally, `shared-bus` alone would. Like I said though, there's limitations of the embedded-hal which keep `shared-bus-rtic` relevant
<re_irc_> <@r​yan-summers:m​atrix.org> Notably, shared-bus can't guarantee that CSn isn't shared between multiple contexts. However, shared-bus-rtic can safely assume that as long as the CSn signal is stored in the same resource (and hence RTIC prevents preemption of it)
<re_irc_> <@r​yan-summers:m​atrix.org> If e-h SPI traits were updated to include CSn ownership in some way, that problem would disappear
<re_irc_> <@a​rbitrix:m​atrix.org> ryan-summers: Ok, gotcha. I have seen some work on CSn ownership in e-h I think... Incidentally I have tried to add support for SPI mode switching to shared-bus-rtic but I discovered that e-h doesn't have traits for the configuration changes. (I have one SPI device that wants mode 2 and one that wants mode 1 or...
<re_irc_> ... 3.)
<re_irc_> <@e​ldruin:m​atrix.org> You can jump into the discussion around managed CS at https://github.com/rust-embedded/embedded-hal/pull/245
<re_irc_> <@r​yan-summers:m​atrix.org> SPI mode is generally out-of-scope for the SPI e-h changes, and most drivers just assume the user configures it correctly
<re_irc_> <@r​yan-summers:m​atrix.org> I personally don't have an issue with that impl. I think forcing mode on people would do more harm than good
<re_irc_> <@a​rbitrix:m​atrix.org> ryan-summers: unfortunately the shared-bus (or a wrapper) is where these mode changes implement cleanly
<re_irc_> <@r​yan-summers:m​atrix.org> ... Is your device changing SPI modes?
<re_irc_> <@r​yan-summers:m​atrix.org> E.g. changing from one device to another?
fabic has quit [Ping timeout: 250 seconds]
<re_irc_> <@r​yan-summers:m​atrix.org> That's a pretty rare hardware impl
<re_irc_> <@a​rbitrix:m​atrix.org> It is an Arduino-like board with an ethernet module on the SPI bus (Mode 0 or 3) and also has an I/O module on the SPI bus (Mode 2)
<re_irc_> <@r​yan-summers:m​atrix.org> I wouldn't try to solve that generically. Just copy shared-bus-rtic and modify it for your specific SPI impl. That's such a rare use case that I don't think it's worth publishing as a crate or architecting the environment around
<re_irc_> <@a​rbitrix:m​atrix.org> In Arduino land this is done with https://www.arduino.cc/en/Tutorial/SPITransaction
<re_irc_> <@r​yan-summers:m​atrix.org> I've never seen a professional hardware design that put multiple SPI devices with different mode configs on the same bus - that seems more like a maker impl
<re_irc_> <@r​yan-summers:m​atrix.org> (or a really constrainted device)
<re_irc_> <@r​yan-summers:m​atrix.org> Both cases can be handled with very application-specific code that doesn't need to be distributed to the wider rust ecosystem impo
<re_irc_> <@a​rbitrix:m​atrix.org> ryan-summers: Agreed and that is what I started to do... until I discovered that my I/O module also works when spoken to in Mode 3 (instead of 2)... and then I went back to your s-b-r 🙏
<re_irc_> <@f​irefrommoonlight:m​atrix.org> > But we can always go with CSes or try the weird volatile atomics
<re_irc_> <@f​irefrommoonlight:m​atrix.org> I've been passing `&mut dp.RCC` to the peripheral constructors that need it to enable and reset peripheral clocks; ie it has no owning struct
<re_irc_> <@a​rbitrix:m​atrix.org> ryan-summers: Congrats, today is your first. This is a hybrid. It is a PLC. I agree it is a questionable design choice in this case but sometimes one doesn't have a choice.
<re_irc_> <@r​yan-summers:m​atrix.org> That's what the caveat statement afterwards was referencing towards. Sometimes your hand is forced
<re_irc_> <@a​rbitrix:m​atrix.org> arbitrix: https://facts-engineering.github.io/modules/P1AM-100/P1AM-100.html
<re_irc_> <@d​irbaio:m​atrix.org> per-peripheral ownership is broken anyway :P
<re_irc_> <@r​yan-summers:m​atrix.org> Yeah, something like shared-bus needs to be the default imo
<re_irc_> <@r​yan-summers:m​atrix.org> But I don't think it's flushed out enough at this point
<re_irc_> <@a​rbitrix:m​atrix.org> Well... I am stoked that I can do this project in Rust with all the great crates that ARE available. They may not be perfect yet, but they so beat writing C++.
<re_irc_> <@a​rbitrix:m​atrix.org> dirbaio: I think RTIC nicely hides that for me 😀
<re_irc_> <@d​irbaio:m​atrix.org> I mean the per-pac peripheral
<re_irc_> <@d​irbaio:m​atrix.org> for example, having to pass &mut RCC to enable pins or uarts or whatever
<re_irc_> <@d​irbaio:m​atrix.org> or having to .split() GPIOA into individual pins
<re_irc_> <@t​halesfragoso:m​atrix.org> dirbaio: I think this a bit orthogonal
<re_irc_> <@t​halesfragoso:m​atrix.org> firefrommoonlight: If you have bit banding or something similar, then you can make it more ergonomic and not ask for it, that's why the api is diffey
<re_irc_> <@d​irbaio:m​atrix.org> but
<re_irc_> <@d​irbaio:m​atrix.org> the fact that you need to write to GPIO regs and RCC regs to setup an UART is an implementation detail of the hardware
<re_irc_> <@d​irbaio:m​atrix.org> the user just wants an UART on PA7/PA8, they don't care about registers
<re_irc_> <@t​halesfragoso:m​atrix.org> Agreed, but some people don't like hiding CSes
<re_irc_> <@d​irbaio:m​atrix.org> these hardware impementation details are exactly what a Hardware *Abstraction* Layer should abstract
<re_irc_> <@t​halesfragoso:m​atrix.org> I don't really care, especially in setup code
fabic has joined #rust-embedded
<re_irc_> <@t​halesfragoso:m​atrix.org> But I'm not everybody .-.
<re_irc_> <@r​yan-summers:m​atrix.org> I agree with thalesfragoso here.
<re_irc_> <@r​yan-summers:m​atrix.org> As long as it gets me a working interface, I couldn't care less what the API looks like. I hid it away in the setup routines and never touch it again
<re_irc_> <@r​yan-summers:m​atrix.org> Sure it's a chip implementation detail, but in every embedded project, I'm carefully analyzing exactly how the chip works anyways
<re_irc_> <@d​irbaio:m​atrix.org> you might not mind it, but that doesn't mean it's a good API
<re_irc_> <@d​irbaio:m​atrix.org> like
<re_irc_> <@t​halesfragoso:m​atrix.org> I will happily just document that the thing using a a CS and be done with it
<re_irc_> <@r​yan-summers:m​atrix.org> If the HAL forces me to do that, it actually is somewhat self-documenting. Now I _know_ the RCC is somehow involved in GPIO usage
<re_irc_> <@r​yan-summers:m​atrix.org> It can save you from foot-gunning yourself
<re_irc_> <@d​irbaio:m​atrix.org> IMO a HAL should start with "what should the ideal API look like?", then from there work out how to get the hardware to do that
<re_irc_> <@d​irbaio:m​atrix.org> the `&mut RCC` is backwards
<re_irc_> <@d​irbaio:m​atrix.org> starts with the hardware and works backwards from it
<re_irc_> <@t​halesfragoso:m​atrix.org> dirbaio: This one I also don't mind, but indeed, people usually complain
<re_irc_> <@r​yan-summers:m​atrix.org> I think it helps show exactly what you're enabling etc. Otherwise, drivers may be silently enabling things behind abstraction layers without you noticing, which can impact power consumption
<re_irc_> <@t​halesfragoso:m​atrix.org> So if I can get rid of it, I will
<re_irc_> <@r​yan-summers:m​atrix.org> But different strokes for different folks
<re_irc_> <@d​irbaio:m​atrix.org> or GPIOA.split()
<re_irc_> <@d​irbaio:m​atrix.org> why can't the singletons already come split? 🤷‍♂️
<re_irc_> <@d​irbaio:m​atrix.org> there's no reason you do *not* want them split
<re_irc_> <@t​halesfragoso:m​atrix.org> Because you need to enable the clocks
<re_irc_> <@d​irbaio:m​atrix.org> then pre-enable them in init :D
<re_irc_> <@t​halesfragoso:m​atrix.org> Which ones ? You will consume more energy
<re_irc_> <@t​halesfragoso:m​atrix.org> If you enable all of them
<re_irc_> <@d​irbaio:m​atrix.org> if you care about power you'll want to enable/disable them dynamically, which the .split() api doesn't allow either
<re_irc_> <@t​halesfragoso:m​atrix.org> You can have a config in init them, but them users my forgot and defeats a bit RAII
<re_irc_> <@t​halesfragoso:m​atrix.org> But again, that's just a bug and might be easy fixable, so it might be worth it
<re_irc_> <@t​halesfragoso:m​atrix.org> You can also make it easy to disable/enable clocks, so enabling all in init isn't that bad
<re_irc_> <@t​halesfragoso:m​atrix.org> If you document it then it's fine IMO
<re_irc_> <@d​irbaio:m​atrix.org> such api would have to be unsafe, if it doesn't enforce that all the GPIO pin singletons are destroyed when disabling
<re_irc_> <@t​halesfragoso:m​atrix.org> Why unsafe ? There isn't really unsoundness
<re_irc_> <@t​halesfragoso:m​atrix.org> No memory will be harmed, hehe
<re_irc_> <@t​halesfragoso:m​atrix.org> But I get where you're coming from
<re_irc_> <@d​irbaio:m​atrix.org> well currently lots of apis do "if it won't work even if not unsound, it's unsafe"
<re_irc_> <@d​irbaio:m​atrix.org> ahem svd2rust
<re_irc_> <@d​irbaio:m​atrix.org> agreed that's not ideal, rcc enable/disable would be safe then
<re_irc_> <@t​halesfragoso:m​atrix.org> Sometimes documenting is better than making it unsafe
<re_irc_> <@t​halesfragoso:m​atrix.org> But I agreed a lot of current APIs do that
<re_irc_> <@f​irefrommoonlight:m​atrix.org> thalesfragoso: That would be great. I'll look into this more. Could do it on the variants that support it (most?)
<re_irc_> <@f​irefrommoonlight:m​atrix.org> Is [this f3xx-hal PR](https://github.com/stm32-rs/stm32f3xx-hal/issues/37) a good place to start?
<re_irc_> <@f​irefrommoonlight:m​atrix.org> ryan-summers: I'm with you on priorities. But, if you have a choice (breaking-change concerns aside), prefer the nicer API
<re_irc_> <@f​irefrommoonlight:m​atrix.org> ryan-summers: This is a good point and gives me pause on diving into hiding the `&mut dp.RCC`. Alternatively, you could argue that you should expect a peripheral clock to be enabled when you initialize a peripheral. (Assuming no other side effects with RCC)
<re_irc_> <@r​yan-summers:m​atrix.org> I personally like the strict ownership of the RCC peripheral. It shows a lot about how the chip is being modified. So you know that if anything is being enabled, the RCC has to be passed in
<re_irc_> <@f​irefrommoonlight:m​atrix.org> Hmm. That's currently how I have it. I'll give this some pause and thought.
<re_irc_> <@f​irefrommoonlight:m​atrix.org> I even have a note in the Readme on Contributing to prefer this approach, but my intent on that was more about avoiding race conditions on RCC
<re_irc_> <@f​irefrommoonlight:m​atrix.org> I'm currently leaning towards your arguments about the value of keeping the rcc pass in for explicitness
<re_irc_> <@f​irefrommoonlight:m​atrix.org> and consistency / expectations
<re_irc_> <@d​irbaio:m​atrix.org> ryan-summers: but do most users care?
<re_irc_> <@d​irbaio:m​atrix.org> many users don't even *know* what RCC is
<re_irc_> <@d​irbaio:m​atrix.org> that's why they're using a HAL
<re_irc_> <@r​yan-summers:m​atrix.org> In embedded, power is generally a really important consideration. If they don't know about it, I think there's a strong argument that this helps them be aware of it
<re_irc_> <@d​irbaio:m​atrix.org> and if you do care, you're one control+click away to check what the HAL does
<re_irc_> <@r​yan-summers:m​atrix.org> And your preference would be to manipulate the RCC in the init functions directly through the register addresses?
<re_irc_> <@r​yan-summers:m​atrix.org> It does give a cleaner API
<re_irc_> <@d​irbaio:m​atrix.org> and both with and without `&mut RCC` you can't *customize* what the HAL does to RCC
<re_irc_> <@d​irbaio:m​atrix.org> > directly through the register addresses
<re_irc_> <@d​irbaio:m​atrix.org> well, my opinion is PACs shouldn't have owned singletons :P
<re_irc_> <@d​irbaio:m​atrix.org> 50% of the time they're *okay*, 50% of the time the HAL has to actively work around them
<re_irc_> <@f​irefrommoonlight:m​atrix.org> I think we're hitting an issue of use cases. I'm more with Ryan on this one
<re_irc_> <@f​irefrommoonlight:m​atrix.org> ie Power is absolutely important for battery powered devices, and you should expect your user to know what RCC is
<re_irc_> <@f​irefrommoonlight:m​atrix.org> But that's not true of everyone. Ie if you're only building plugin devices, or are just tinkering
<re_irc_> <@f​irefrommoonlight:m​atrix.org> And I think it's a big trap (In design in general) to design for too broad or unspecific an audience
<re_irc_> <@f​irefrommoonlight:m​atrix.org> Ie I can make deliberate design decisions saying my HAL etc is for users with a baseline of technical knowledge
<re_irc_> <@f​irefrommoonlight:m​atrix.org> With the benefit of a more tightly-controlled scope and requirements
<re_irc_> <@f​irefrommoonlight:m​atrix.org> And a cost of not being a good fit for some users
<re_irc_> <@a​rbitrix:m​atrix.org> dirbaio: That depends on the user, no? Some users want a low-level HAL that's as close to the hardware as possible, others would prefer a higher level HAL/runtime that abstracts away the low-level details, generally at the expense of some niche use cases.
fabic has quit [Ping timeout: 252 seconds]
<re_irc_> <@f​irefrommoonlight:m​atrix.org> My intent on HAL is following the recipes described in RMs for an ergonomic, explicit API, without sacrificing funcionality
<re_irc_> <@f​irefrommoonlight:m​atrix.org> I think even if you're not using a 3rd-party HAL, it's good practice to have a HAL layer in your own code bases instead of using PAC directly in your code logic
<re_irc_> <@f​irefrommoonlight:m​atrix.org> Ie either use or write a HAL
<re_irc_> <@f​irefrommoonlight:m​atrix.org> Ie, HAL is not just for new users, re "many users don't even know what RCC is
<re_irc_> <@f​irefrommoonlight:m​atrix.org> that's why they're using a HAL"
<re_irc_> <@d​irbaio:m​atrix.org> my point is not "my hal is for noob users only"
<re_irc_> <@d​irbaio:m​atrix.org> my point is `&mut rcc` adds no value
<re_irc_> <@d​irbaio:m​atrix.org> because if you're a noob user you don't want to know about it
<re_irc_> <@d​irbaio:m​atrix.org> if you're an advanced user you already know about it
<re_irc_> <@d​irbaio:m​atrix.org> and the `&mut rcc` or `.split()` etc don't allow you to do anything you couldn't otherwise
<re_irc_> <@d​irbaio:m​atrix.org> it's just API noise
<re_irc_> <@d​irbaio:m​atrix.org> on both HALs with and without, you can use GPIO just fine, you can use UART just fine, etc
<re_irc_> <@d​irbaio:m​atrix.org> on both if you care aobut power you have to go and manually muck with RCC with unsafe to disable stuff
<re_irc_> <@r​yan-summers:m​atrix.org> I would definitely not muck with the RCC and use unsafe code to manage it.
<re_irc_> <@r​yan-summers:m​atrix.org> I think that's a gross overstatement
<re_irc_> <@x​norman:m​atrix.org> I'm trying to interface with a quad spi flash chip `IS25LP064A` with stm32h7xx_hal
<re_irc_> <@x​norman:m​atrix.org> The flash chip I'm using requires I setup quadspi in 1 line spi mode, which i think i can figure out, but then the HAL for qspi simply provides an address and then data for read and write, but the chip i'm using requires instructions before addressing, and not all operations even require an address so I'm a...
<re_irc_> ... little confused about the interface.
<re_irc_> <@x​norman:m​atrix.org> Is the operation that I'm trying to do simply not supported by the HAL or am I missing something?
<re_irc_> <@r​yan-summers:m​atrix.org> Your assessment is correct and the docs on the HAL state this. The QSPI driver in the H7 HAL is only for indirect operation (e.g. 4-wire SPI for SPI-like transfers)
<re_irc_> <@d​irbaio:m​atrix.org> ryan-summers: you can't disable eg GPIOA with the current stm32-rs hals
<re_irc_> <@r​yan-summers:m​atrix.org> Memory mapped flash via QSPI isn't implemented
<re_irc_> <@r​yan-summers:m​atrix.org> Yeah, I also don't disable GPIOs that I'm using
<re_irc_> <@f​irefrommoonlight:m​atrix.org> I hear you on the API noise bit. I'm still considering it
<re_irc_> <@f​irefrommoonlight:m​atrix.org> OK, stm32 question I've been trying to figure out for a while re power and clocks: If you're in stop mode, is there any benefit to manually turning off peripheral clocks, or is the 'gating' the RM talks about in Stop enough?
<re_irc_> <@x​norman:m​atrix.org> yeah, i see that indirect mode is the only thing available for QSPI, but for instance, STM's documentation about qspi indirect mode says: "In Indirect mode, all operations are performed through the QUADSPI register where both read and write operations are available and managed by software. The Quad-SPI interface...
<re_irc_> ... behaves like a classical SPI interface. "
<re_irc_> <@x​norman:m​atrix.org> so, i just don't quite get where this address comes into the interface
<re_irc_> <@f​irefrommoonlight:m​atrix.org> (in Sleep, I can see manually turning off periph clocks to save power if you don't want to Stop)
<re_irc_> <@f​irefrommoonlight:m​atrix.org> Alex Norman: You may have to check the RM on this
<re_irc_> <@x​norman:m​atrix.org> okay, the RM shows an instruction phase for indirect mode but I see that the hal is coded to have no instruction phase so I guess it won't do what I'm looking to do
<re_irc_> <@r​yan-summers:m​atrix.org> Alex Norman: Address in the HAL API is the read/write register address of the SPI transaction. It may be a baked in assumption to the HAL API
fabic has joined #rust-embedded
<re_irc_> <@x​norman:m​atrix.org> understood, thanks ryan-summers firefrommoonlight
<re_irc_> <@b​urrbull:m​atrix.org> dirbaio: Absolutely awful idea
<re_irc_> <@d​irbaio:m​atrix.org> it's nice to explain your reasoning when you criticize an idea
fabic has quit [Ping timeout: 258 seconds]
<cr1901> dirbaio: FWIW, this was a good idea you had: https://github.com/cr1901/i2c-server/compare/error-refactor
SomeWeirdAnon has quit []
tokomak has joined #rust-embedded