01:39 <re_irc> <@f​irefrommoonlight:m​atrix.org> Is there a good approach to I2C PU resistors on battery-powered devices?

01:40 <re_irc> <@f​irefrommoonlight:m​atrix.org> maybe internal, and disable during low-power modes?

01:40 <re_irc> <@f​irefrommoonlight:m​atrix.org> I guess they should only use current when fighting against being pulled low though

01:41 <re_irc> <@k​evlan:m​atrix.org> The pu on i2c only consumes current when the bus is low. With nothing pulling the bus down there is no current flowing though them.

01:41 <re_irc> <@f​irefrommoonlight:m​atrix.org> Thank you. I'll leave them be and look elsewhere

01:42 <re_irc> <@k​evlan:m​atrix.org> If the bus is active a lot using a higher resistance value can reduce the active current consumption but that can only be done if there is not much capacitance on the bus

01:42 <re_irc> <@f​irefrommoonlight:m​atrix.org> Thank you. I might be able to use a higher resistance, but these are used so intermittently, the problem likely lies elsewhere

01:43 <re_irc> <@f​irefrommoonlight:m​atrix.org> I'd forgotten to put the display (epaper) in a low-power mode explicitly, figuring it would just not use much power when not refreshing, but that was probably a bad assumption

01:43 <re_irc> <@f​irefrommoonlight:m​atrix.org> Or something else entirely

07:07 <re_irc> <@t​herealprof:m​atrix.org> kevlan: Or can reduce the speed.

07:09 <re_irc> <@t​herealprof:m​atrix.org> With some hardware implementations one might also be tempted to tweak the timings but to get the fall/rise times into specified numbers but that is very shady. 😉

15:20 <re_irc> <@b​urrbull:m​atrix.org> This is experiment. Enabling `ehal1` feature replaces all 0.2 traits with 1.0 ones.

15:20 <re_irc> <@b​urrbull:m​atrix.org> https://github.com/stm32-rs/stm32f4xx-hal/pull/338

15:20 <re_irc> <@b​urrbull:m​atrix.org> Can somebody test this? eldruin ?

16:42 <re_irc> <@a​llexoll:m​atrix.org> is there an easy way to have larger than 16-aligned elements with `aligned`

17:14 <re_irc> <@r​yan-summers:m​atrix.org> Does rust allow you to attach docs written somewhere else to a specific struct? I want a derive macro to essentially attach documentation to structure members, but don't know if it's possible

17:52 <re_irc> <@s​ajattack:m​atrix.org> ryan-summers: the keyword you're looking for is intra-doc links I believe

17:53 <re_irc> <@r​yan-summers:m​atrix.org> I don't want to "link" back to it, I want the docs to be directly tied to the member

17:53 <re_irc> <@r​yan-summers:m​atrix.org> E.g. not a reference link, but actually the default docs for the structure member

17:53 <re_irc> <@r​yan-summers:m​atrix.org> Similar to

17:53 <re_irc> <@r​yan-summers:m​atrix.org> struct Foo {

17:53 <re_irc> <@r​yan-summers:m​atrix.org> }

17:53 <re_irc> <@r​yan-summers:m​atrix.org> pub bar: u32;

17:53 <re_irc> <@r​yan-summers:m​atrix.org> /// <proc-macro generated documentation>

17:54 <re_irc> <@r​yan-summers:m​atrix.org> Or even docs on the Foo struct as well

17:58 <re_irc> <@d​irbaio:m​atrix.org> proc macros can emit docs with ``#[doc]

17:59 <re_irc> <@d​irbaio:m​atrix.org> but I think derive macros can only emit new things, not edit the struct itself

17:59 <re_irc> <@d​irbaio:m​atrix.org> you can definitely do this with an attribute macro

19:34 <re_irc> <@m​arcat:m​atrix.org> Hey, I'm advocating for using gitlab CI instead of heavily scripted-bloated jenkins for both software and hw-in-the-loop things. Do you know any public project using a gitlab instance with hw that I could show as a proof it is possible? I think I've seen people talking about setting up similar setup here.

20:08 <re_irc> <@e​ldruin:m​atrix.org> burrbull: Hey, at first sight the code looks fine to me

20:09 <re_irc> <@e​ldruin:m​atrix.org> however, you can support both e-h versions at the same time by simply importing embedded-hal 1.0 again under a different name

20:09 <re_irc> <@e​ldruin:m​atrix.org> Here is the procedure described: https://github.com/rust-embedded/embedded-hal#adding-support-for-an-embedded-hal--alpha-version-in-a-hal-implementation

20:11 <re_irc> <@e​ldruin:m​atrix.org> I think once we land a few pending PRs we can make a new alpha release since there have been so many changes since the last one.

20:11 <re_irc> <@e​ldruin:m​atrix.org> then you can depend on a released, albeit alpha, version instead of git master, which will break at some point

20:14 <re_irc> <@e​ldruin:m​atrix.org> do you need help testing this on the hardware or do you mean just reviewing it?

20:21 <re_irc> <@f​irefrommoonlight:m​atrix.org> When do you expect to release 1.0?

20:31 <re_irc> <@e​ldruin:m​atrix.org> We have no fixed timeline. As long as big breaking changes keep coming, it would be better to hold the release

20:32 <re_irc> <@e​ldruin:m​atrix.org> a split between major versions of e-h in the ecosystem is painful, although less due to the trick linked above, so it should not be done lightly

20:32 <re_irc> <@l​achlansneff:m​atrix.org> I raised standardizing `Read`, `Write`, `AsyncRead`, and `AsyncWrite` in `core` with the t-libs WG. https://rust-lang.zulipchat.com/#narrow/stream/219381-t-libs/topic/Read.2C.20Write.2C.20AsyncRead.2C.20and.20AsyncWrite.20in.20core

20:33 <re_irc> <@e​ldruin:m​atrix.org> good, thanks for driving that

20:34 <re_irc> <@e​ldruin:m​atrix.org> the `futures` module would have no implications in e-h 1.0 though, as it would be unstable a.k.a. we can break it anytime

20:34 <re_irc> <@l​achlansneff:m​atrix.org> Yeah, `futures` is likely to be in 1.1 or something later than 1.0

23:43 <re_irc> <@9​names:m​atrix.org> eldruin: A new alpha would be nice, I would like to migrate bl602-hal away from alpha4

23:47 <re_irc> <@t​halesfragoso:m​atrix.org> 9names: Now that you talked about it, I recently ordered one, waiting on shipping, how things going ? I even saw a PoC with wifi

23:47 <re_irc> <@t​halesfragoso:m​atrix.org> But with malloc and some weird task stuff

23:48 <re_irc> <@t​halesfragoso:m​atrix.org> task switching stuff*

23:49 <re_irc> <@9​names:m​atrix.org> The wifi blob expects an RTOS, so tasks and alloc are necessary

23:50 <re_irc> <@t​halesfragoso:m​atrix.org> Yeah, I would hope that didn't use that much of RTOS in wifi

23:50 <re_irc> <@t​halesfragoso:m​atrix.org> But it always like this