01:06 <cr1901> Where is Peripherals::take?

01:06 <cr1901> Ahhh, it requires the critical-section feature

02:58 <re_irc> <ignormies> burrbull: I'm probably going to just be reimplementing the logic of the crate myself (with "blocking::spi::Write") for my own use-case specific purposes (there's not much in there after all).

02:58 <re_irc> But I don't understand how the stm32f1 example (https://github.com/smart-leds-rs/smart-leds-samples/blob/master/stm32f1-examples/examples/stm32f1_ws2812_spi_blink.rs) _ever_ worked if "ws2812-spi-rs" always uses "FullDuplex". Is it just a borked example?

03:15 <re_irc> <ignormies> I guess it's because it _always_ ".read()"s after ".send()"ing? But that still doesn't explain why I get "Overrun" errors whenever I use the example...

16:18 <re_irc> <nihal.pasham> question: are there any good crates for parsing "config files" (like toml files) in a no_std environment?

16:28 <re_irc> <newam> nihal.pasham: Serde works in no_std, and there are .ini parsers for that which most config files follow.

16:28 <re_irc> <newam> -for that which most config files follow.

16:32 <re_irc> <nihal.pasham> yeah, hoping to save some time and pick an existing one. "ini parsers" - would you recommend any crate in particular

16:32 <re_irc> <newam> Have not tried ini serde implementations myself

16:47 <re_irc> <nihal.pasham> Thanks, I'll take a look at available uni parsers. Guess it's either this or roll your own parser using something like nom

16:47 <re_irc> <nihal.pasham> * "nom"

18:39 <re_irc> <GrantM11235> burrbull: Without "#[macro_export]", you can only do "pub(crate) use" 😭

18:40 <re_irc> <GrantM11235> > error[E0364]: "spi_transaction_helper" is only public within the crate, and cannot be re-exported outside

18:40 <re_irc> > --> src/spi.rs:108:9

18:40 <re_irc> > 108 | pub use spi_transaction_helper as transaction_helper;

18:40 <re_irc> > |

18:40 <re_irc> ... long message truncated: https://psion.agg.io/_matrix/media/r0/download/psion.agg.io/44c8a952452142e6a2e07130641a196fd9f7783387a85109ce5a72bafa8ee74c (7 lines)

18:56 <re_irc> <alvela> Anyone have any suggestions for how to manage ownership of a variable which needs use by both application and driver code?

18:56 <re_irc> There's a delay variable used by this LCD driver I'm hacking on and it takes ownership of it, preventing me from using it directly in application code

18:57 <re_irc> <alvela> I considered passing it as a mut reference to all the functions which need it (not the most elegant) but am prevented from doing so due to a function which uses the delay adhering to a trait

18:58 <re_irc> <newam> if your delay variable can be expressed as an integer and you're on a platform with atomic that can work

19:00 <re_irc> <newam> * atomics

19:01 <re_irc> <alvela> Mind elaborating on what you mean by atomics? For more context, the delay I'm using is "cortex_m::delay::Delay" and the library uses "embedded_hal::blocking::delay::DelayMs"

19:02 <re_irc> <newam> Are you trying to pass around a mutable struct that implements delay ("cortex_m::delay::Delay") or the duration the delay consumes ("embedded_hal::blocking::delay::DelayMs")?

19:02 <re_irc> <alvela> The struct itself

19:02 <re_irc> <alvela> My initial question is on good software patterns. Can change on either side of app/library if there's a better approach

19:03 <re_irc> <newam> Ahhh, yeah that's more difficult :S

19:03 <re_irc> Generally I rely on the RTOS to provide a delay function.

19:03 <re_irc> <alvela> Maybe it's time I finally work on some RTIC stuff haha

19:03 <re_irc> <alvela> I was just mostly annoyed that I can't use the delay after initializing the driver

19:04 <re_irc> <GrantM11235> Can you just create a new delay struct?

19:04 <re_irc> <alvela> I don't believe so, the delay takes ownership of the system timer

19:05 <re_irc> <newam> There's also this if you want a quick hack: https://docs.rs/cortex-m/0.7.6/cortex_m/asm/fn.delay.html

19:06 <re_irc> <GrantM11235> That doesn't implement the delay trait though

19:07 <re_irc> <newam> No, but you could make a new type that does implement delay with that function as the backend

19:08 <re_irc> <GrantM11235> You could also create a newtype for the cortex-m delay struct that impls the delay traits for "&mut MyNewType" as well

19:08 <re_irc> <newam> https://docs.rs/cortex-m/0.7.6/src/cortex_m/delay.rs.html#40-64

19:08 <re_irc> Wouldn't work for concurrent delays without extra logic though

19:09 <re_irc> <newam> since it modifies the systick registers each time it gets called

19:10 <re_irc> <alvela> Will consider these approaches, thanks! I think I may hold off on changing anything until I get a better picture of what's most "ergonomic" when working with an RTOS

19:10 <re_irc> <GrantM11235> This would be super easy with embassy btw

19:10 <re_irc> <newam> https://arewertosyet.com/

19:10 <re_irc> ^ shameless plug

19:11 <re_irc> <newam> https://psion.agg.io/_matrix/media/r0/download/matrix.org/mAsSpdzkFTANNjzjbcHgftdU/image.png

19:12 <re_irc> <alvela> I've been off and on following James' MnemOS dev on twitter. Cool to see all the work different folks are doing in this space

19:14 <re_irc> <GrantM11235> Does your display driver _need_ to take ownership of a delay struct? The display driver that I used only needed to borrow the delay struct during initialization. You could try patching your display driver to do the same

19:16 <re_irc> <alvela> Fair point. I hadn't considered that. Only one way to find out 🤷

19:16 <re_irc> I know it does for init for sure, but there's some delays after data transfers (to I2C backpack) sprinkled in

19:18 <re_irc> <alvela> Only my third or so foray into reading datasheets, so it's been pretty easy to get lost....esp w/ the extra i2c backpack in the mix

19:39 <re_irc> <adamgreig> newam: man, the "issues" badge goes green if there's 0 open? that's the first time i've seen it :D