07:38 <frostie314159[m]> Hi, are there any plans to introduce asynchronous or synchronous hals for timers? Or do they already exist and I didn't find them?

07:49 <haobogu[m]> https://docs.embassy.dev/embassy-time/git/default/index.html

07:49 <frostie314159[m]> Thanks!

07:49 <haobogu[m]> Does embassy_time meet your requirement?

07:50 <frostie314159[m]> Somewhat. I was looking for something entirely executor independent, like a Timer or Ticker trait.

11:09 <ivmarkov[m]> <frostie314159[m]> "Somewhat. I was looking for..." <- `embassy-time` is executor independent, when you enable its `generic-queue` feature, but of course it still requires an alarm driver implementation in the HAL. Or alternatively, you can use the `Delay` trait from `embassy_hal_async` and live with the viral nature of the induced generic type.

11:11 <frostie314159[m]> Ok, that sounds good, maybe I'll make a PR, which adds a second Ticker trait.

11:15 <JamesMunns[m]> you mean some type that pings at a recurring interval? (embassy time does just have a Ticker type: https://docs.rs/embassy-time/latest/embassy_time/struct.Ticker.html)

11:16 <frostie314159[m]> Yes, just like that, however as an embedded_hal_async trait.

11:17 <JamesMunns[m]> just wondering - what would you want the trait to do? like, exactly the same behavior?

11:19 <frostie314159[m]> Yes, I want to be able to use tokio or async-std tickers natively, through a trait, since parts of my code run either in an embedded environment with embassy and a host environment with another async runtime.

11:19 <JamesMunns[m]> Interesting! thanks for the context :)

11:20 <frostie314159[m]> I'm building parts of a generic WiFi Stack and some of the lower parts can run either on the host or the embedded device.

11:21 <JamesMunns[m]> fwiw, the reason (IMO) that there aren't any common timer traits (other than Delay), is that it turns out lots of people want to use timers in *slightly* different ways, or timers are just different in enough ways (resolution, range), or require "system level" support (like having an interrupt or two), that it's hard to capture all of that in a single "trait"

11:23 <JamesMunns[m]> embassy-time hits a fair chunk of that (at least for async users, and users that are okay with dedicating 1 or 2 interrupts), but even then it uses some sort of tricky ways of making it happen, not just a trait.

11:23 <JamesMunns[m]> That being said, I think you could abstract over `embassy-time` and `tokio::time` pretty reasonably with traits as you said. You will probably want to have that trait inside your project, or make it a separate crate to "prove it out" before you PR it to embassy or e-h-async.

11:23 <JamesMunns[m]> * embassy-time hits a fair chunk of common use cases (at least for async users, and users that are okay with dedicating 1 or 2 interrupts), but even then it uses some sort of tricky ways of making it happen, not just a trait.

11:23 <JamesMunns[m]> That being said, I think you could abstract over `embassy-time` and `tokio::time` pretty reasonably with traits as you said. You will probably want to have that trait inside your project, or make it a separate crate to "prove it out" before you PR it to embassy or e-h-async.

11:26 <frostie314159[m]> I agree. This is probably an interesting topic to explore. That being said, the trait wouldn't require that many methods. I can only imagine three: tick reset reset_after. These should be possible on every timer implementation and are all you could possibly need.

11:30 <frostie314159[m]> And yes I know, that last sentence sounds a bit like: "Who's ever gonna need more than 4GB of RAM".

11:30 <frostie314159[m]> * of RAM". But for a simplistic ticker, that should be all that's necessary.

11:30 <JamesMunns[m]> :)

11:31 <JamesMunns[m]> people have so many uses for timers! and timers are so weird! But if you make something cool and useful definitely share it! but it is something we've been trying to find the sweet spot(s) for, for about 5-6 years now.

11:32 <frostie314159[m]> I'll definitely give it a shot

11:32 <JamesMunns[m]> It's certainly a domain that invites a lot of "why don't you just" questions :D

11:32 <frostie314159[m]> I can imagine that :)

11:37 <frostie314159[m]> Another issue, which arises is the question on future trait bounds. Should the function look like this: `

11:37 <frostie314159[m]> fn tick(&mut self) -> impl Future + Send + Sync + 'static

11:37 <frostie314159[m]> `?

11:43 <enaut[m]> I tried to get a TFT screen working that uses SPI. There is a driver for the display: https://docs.rs/st7735-lcd/latest/st7735_lcd/index.html but I simply cannot get any examples to compile... my current state is: https://gist.github.com/enaut/855c4acbcdde320f549a7a130e8393ae Would anyone be so nice as to tell me how I can solve the error - how do I get something that implements SpiDevice?

11:45 <dirbaio[m]> create a https://docs.rs/embedded-hal-bus/latest/embedded_hal_bus/spi/struct.ExclusiveDevice.html

11:45 <dirbaio[m]> with the bus and the CS pin

11:52 <enaut[m]> dirbaio: I see on to the challenge. Thanks for the valuable hint.

15:06 <enaut[m]> Mhm sometimes I really doubt my sanity... Why does:... (full message at <https://catircservices.org/_matrix/media/v3/download/catircservices.org/xVJTgJmiQxKKXmqvBJvpUpAq>)

15:11 <barnabyw[m]> active low LED? what happens if both loops have set_low?

15:26 <enaut[m]> No way... thank you barnabyw - but why on earth does the onboard LED light up when pulled low? But OK now I know…

15:31 <burrbull[m]> enaut[m]: Ask WeAct

15:45 <NickStevens[m]> <enaut[m]> "No way... thank you barnabyw..." <- Not sure if this is the reason for your board, but a lot of times LEDs are set to activate when pulled low because the microcontroller can sink more current than it's able to source.

15:59 <enaut[m]> That that might be an interesting option for future projects.

16:22 <barnabyw[m]> ha ha that’s one of the reasons “blink an LED” is embedded hello world rather than “light up an LED” 😁 confirms that your clocks are set up okay, and works regardless of the LED being active high or active low

17:09 <JamesMunns[m]> <barnabyw[m]> "ha ha that’s one of the reasons..." <- and also why you use like a 25%/75% blink instead of 50%/50%, so you can confirm which level is "on" and which is "off"!

17:10 <JamesMunns[m]> enaut ⚡️ a term to learn here is "active high" or "active low" - if the LED turns on when the voltage is low, it is usually called "active low". You see this very often, in fact I'd say I see "active low" more often than I see "active high"! Especially for things like chip selects or interrupt pins.

18:16 <barnabyw[m]> it’s often indicated by an overline (bar over the pin symbol)