SomeWeirdAnon has quit []
fabic has joined #rust-embedded
<re_irc> <@f​irefrommoonlight:m​> Is there a good approach to I2C PU resistors on battery-powered devices?
<re_irc> <@f​irefrommoonlight:m​> maybe internal, and disable during low-power modes?
<re_irc> <@f​irefrommoonlight:m​> I guess they should only use current when fighting against being pulled low though
<re_irc> <@k​evlan:m​> 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.
<re_irc> <@f​irefrommoonlight:m​> Thank you. I'll leave them be and look elsewhere
<re_irc> <@k​evlan:m​> 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
<re_irc> <@f​irefrommoonlight:m​> Thank you. I might be able to use a higher resistance, but these are used so intermittently, the problem likely lies elsewhere
<re_irc> <@f​irefrommoonlight:m​> 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
<re_irc> <@f​irefrommoonlight:m​> Or something else entirely
starblue2 has joined #rust-embedded
starblue1 has quit [Ping timeout: 252 seconds]
aquijoule__ has joined #rust-embedded
aquijoule_ has quit [Ping timeout: 246 seconds]
cr1901 has quit [Ping timeout: 256 seconds]
fabic has quit [Ping timeout: 272 seconds]
<re_irc> <@t​herealprof:m​> kevlan: Or can reduce the speed.
<re_irc> <@t​herealprof:m​> 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. 😉
neceve has joined #rust-embedded
dreamcat4 has quit [Quit: Connection closed for inactivity]
fabic has joined #rust-embedded
cr1901 has joined #rust-embedded
<re_irc> <@b​urrbull:m​> This is experiment. Enabling `ehal1` feature replaces all 0.2 traits with 1.0 ones.
<re_irc> <@b​urrbull:m​>
<re_irc> <@b​urrbull:m​> Can somebody test this? eldruin ?
dreamcat4 has joined #rust-embedded
crabbedhaloablut has quit [Remote host closed the connection]
crabbedhaloablut has joined #rust-embedded
dirbaio2 has quit [Quit: WeeChat 1.4]
<re_irc> <@a​llexoll:m​> is there an easy way to have larger than 16-aligned elements with `aligned`
fabic has quit [Ping timeout: 272 seconds]
<re_irc> <@r​yan-summers:m​> 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
SomeWeirdAnon has joined #rust-embedded
<re_irc> <@s​ajattack:m​> ryan-summers: the keyword you're looking for is intra-doc links I believe
<re_irc> <@r​yan-summers:m​> I don't want to "link" back to it, I want the docs to be directly tied to the member
<re_irc> <@r​yan-summers:m​> E.g. not a reference link, but actually the default docs for the structure member
<re_irc> <@r​yan-summers:m​> Similar to
<re_irc> <@r​yan-summers:m​> struct Foo {
<re_irc> <@r​yan-summers:m​> }
<re_irc> <@r​yan-summers:m​> pub bar: u32;
<re_irc> <@r​yan-summers:m​> /// <proc-macro generated documentation>
<re_irc> <@r​yan-summers:m​> Or even docs on the Foo struct as well
<re_irc> <@d​irbaio:m​> proc macros can emit docs with ``#[doc]
<re_irc> <@d​irbaio:m​> but I think derive macros can only emit new things, not edit the struct itself
<re_irc> <@d​irbaio:m​> you can definitely do this with an attribute macro
SomeWeirdAnon has quit []
neceve has quit [Ping timeout: 252 seconds]
<re_irc> <@m​arcat:m​> 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.
neceve has joined #rust-embedded
<re_irc> <@e​ldruin:m​> burrbull: Hey, at first sight the code looks fine to me
<re_irc> <@e​ldruin:m​> however, you can support both e-h versions at the same time by simply importing embedded-hal 1.0 again under a different name
<re_irc> <@e​ldruin:m​> 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.
<re_irc> <@e​ldruin:m​> then you can depend on a released, albeit alpha, version instead of git master, which will break at some point
<re_irc> <@e​ldruin:m​> do you need help testing this on the hardware or do you mean just reviewing it?
<re_irc> <@f​irefrommoonlight:m​> When do you expect to release 1.0?
<re_irc> <@e​ldruin:m​> We have no fixed timeline. As long as big breaking changes keep coming, it would be better to hold the release
<re_irc> <@e​ldruin:m​> 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
<re_irc> <@l​achlansneff:m​> I raised standardizing `Read`, `Write`, `AsyncRead`, and `AsyncWrite` in `core` with the t-libs WG.
<re_irc> <@e​ldruin:m​> good, thanks for driving that
<re_irc> <@e​ldruin:m​> 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
<re_irc> <@l​achlansneff:m​> Yeah, `futures` is likely to be in 1.1 or something later than 1.0
neceve has quit [Ping timeout: 252 seconds]
<re_irc> <@9​names:m​> eldruin: A new alpha would be nice, I would like to migrate bl602-hal away from alpha4
<re_irc> <@t​halesfragoso:m​> 9names: Now that you talked about it, I recently ordered one, waiting on shipping, how things going ? I even saw a PoC with wifi
<re_irc> <@t​halesfragoso:m​> But with malloc and some weird task stuff
<re_irc> <@t​halesfragoso:m​> task switching stuff*
<re_irc> <@9​names:m​> The wifi blob expects an RTOS, so tasks and alloc are necessary
<re_irc> <@t​halesfragoso:m​> Yeah, I would hope that didn't use that much of RTOS in wifi
<re_irc> <@t​halesfragoso:m​> But it always like this