Foxyloxy has quit [Read error: Connection reset by peer]
Lumpio- has quit [Ping timeout: 272 seconds]
Lumpio- has joined #rust-embedded
sroemer has joined #rust-embedded
ska has quit [Ping timeout: 252 seconds]
JamesMunns[m] has quit [Quit: Idle timeout reached: 172800s]
<Ralph[m]>
just wondering: is the `.x` extension for linker scripts an official thing or just used in rust circles? i couldn't find anything about it. there's no mention of file names / extensions here: https://sourceware.org/binutils/docs/ld/Scripts.html
<Pete[m]1>
Design related question: Coming from the Zephyr world, drivers there use a clear split of "config vs data" structures, so that anything that can be placed into ROM and save RAM can do so... I'm wondering how folks generally approach that for rust code? Pass around/use the mutable thing, and that has a ref to some static struct holding your config?
<Pete[m]1>
* holding your "config, * config"?
i509vcb[m] has joined #rust-embedded
<i509vcb[m]>
If you can stuff your config types into a `const` it will end up in flash
<i509vcb[m]>
And don't need to modify it during use
<Pete[m]1>
AFAIK, const ends up creating duplicates of the data under the hood, static is what I really want in Rust land?
<Pete[m]1>
I know that's the technical way to ensure an item is (linker/target dependent) placed into ROM, I mean how to design your types to effectively leverage that cleanly.
<i509vcb[m]>
So static can sometimes end up in ram
<i509vcb[m]>
But only if there is interior mutability
<Pete[m]1>
Good to know, thanks.
<i509vcb[m]>
If you need to ensure it's in flash you could annotate the definition with a specific link section
<i509vcb[m]>
Although if your config is used as a owned value and not borrowed when it will probably end up being copied to the stack when used
<i509vcb[m]>
s/when/then/
<i509vcb[m]>
An immutable reference can point to flash.
<Pete[m]1>
Yeah, that makes sense, my intention would be to pass non-mut refs to that data everywhere to avoid that.
<i509vcb[m]>
Speaking of that, I recall some embassy hals don't always use borrowed configs?
<i509vcb[m]>
You are doing 5V pull ups. Is your IO 3.3V?
<i509vcb[m]>
Which is allowed if the pins you chose are 5V tolerant
<mrpashapg[m]>
i509vcb[m]: No, everything works with 5V - both the DS1307 RTC module (which worked perfectly and successfully drove my EEPROM) and the EEPROM itself which connects at 5V
<mrpashapg[m]>
i509vcb[m]: Yes, they're all 5V
<i509vcb[m]>
I'd question your pull ups if removing those fixes it
<i509vcb[m]>
Loose connection on breadboard.
<i509vcb[m]>
s/./?/
<i509vcb[m]>
You sure you didn't enable any on board pull ups on the controller?
chrysn[m] has joined #rust-embedded
<chrysn[m]>
Working towards the stabilization of embedded-io, I started refactoring the windowed-infinity crate (a write implementation that sends bytes from a certain offset into a given buffer slice, and discards the rest), and one output of the refactoring would have been called embedded-io-adapters.
<chrysn[m]>
I was about to check whether there was a crate that already did some of that, and found that there is even a crate of that name :-D
<chrysn[m]>
Just that it doesn't adapt to *all* the crates I need adapting to (eg. not to core::fmt::Write) -- dirbaio, would PRs extending this to core::fmt::Write and the cryptographic hash Digest crates be welcome there?
<chrysn[m]>
(Or that's probably more a question to the team; I just saw your name stand out as crate owner.)
<dirbaio[m]>
core::fmt sure
<dirbaio[m]>
what's the Digest trait?
<chrysn[m]>
basically any cryptographic hash (so that your writes don't go into a buffer but you calculate the checksum from the same producer that'd otherwise send the content to a file)
<chrysn[m]>
The hash digest crate providing the trait is maintained by rustcrypto team, and has not had a stable release yet.
<dirbaio[m]>
that's supposed to be implemented by structs that implement some hashing algo, it wouldn't make sense to impl it for e-io
<dirbaio[m]>
or you mean the other way around, an adapter that impls e-io::Write and forwards the written bytes to a digest?
<chrysn[m]>
The latter, yes. In a sense it's an adapter in the other direction.
<chrysn[m]>
(My tentative local embedded-io-adapters has a few more in both directions, eg. implementing the minicbor::Write trait, but I also have a minicbor-adapters crate that can take care of that one).
<dirbaio[m]>
feels a bit niche?
<dirbaio[m]>
the digest crate itself doesn't provide that for std::io
<dirbaio[m]>
and the rust-crypto crates aren't known for their stability š
<chrysn[m]>
That's a good criterion (maybe I'll even PR a statement about that for the embedded-io-adapters' README). Then that'll go into ... extra-embedded-io-adapters or something :-)
andar1an has joined #rust-embedded
<chrysn[m]>
Thanks, PR(s?) will come up depending on how long my current environment will let me work š.
<mrpashapg[m]>
<mrpashapg[m]> Having issues with I2C pull-up resistor setup....
<mrpashapg[m]>
I folded the resistor leads twice over themselves, making their diameter four times thicker than the original when inserted into the breadboard. However, Iām still getting a timeout error