ChanServ changed the topic of #rust-embedded to: Welcome to the Rust Embedded IRC channel! Bridged to #rust-embedded:matrix.org and logged at https://libera.irclog.whitequark.org/rust-embedded, code of conduct at https://www.rust-lang.org/conduct.html
m5zs7k has quit [Quit: m5zs7k]
m5zs7k has joined #rust-embedded
sroemer has joined #rust-embedded
_whitelogger_ has quit [Remote host closed the connection]
_whitelogger_ has joined #rust-embedded
Foxyloxy has quit [Read error: Connection reset by peer]
Foxyloxy has joined #rust-embedded
_whitelogger_ has quit [Remote host closed the connection]
_whitelogger_ has joined #rust-embedded
_whitelogger_ has quit [Remote host closed the connection]
_whitelogger_ has joined #rust-embedded
ello has quit [Remote host closed the connection]
ello has joined #rust-embedded
ello has quit [Quit: ZNC 1.9.1 - https://znc.in]
ello has joined #rust-embedded
dngrs[m] has quit [Quit: Idle timeout reached: 172800s]
Ralph[m] has quit [Quit: Idle timeout reached: 172800s]
tamme[m] has quit [Quit: Idle timeout reached: 172800s]
Makarov has joined #rust-embedded
igiona[m] has quit [Quit: Idle timeout reached: 172800s]
duderonomy has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
sroemer has quit [Ping timeout: 248 seconds]
tschundler has quit [Ping timeout: 245 seconds]
tschundler has joined #rust-embedded
Artea has joined #rust-embedded
Makarov has quit [Ping timeout: 256 seconds]
<JamesMunns[m]> Yo diondokter on the Interrupt blog? Hell yeah: https://interrupt.memfault.com/blog/sequential-storage-crate
<diondokter[m]> Ah it's out!
<diondokter[m]> Pretty nice :)
<diondokter[m]> Oh, haha they kept the last chapter in. 'towards' 1.0. Well, it's already at 3.0 :P
<dirbaio[m]> it doesn't mention "rust" even once, C devs reading that blog are going to be "wtf is a crate" :D
<dirbaio[m]> * to be like "wtf is
<Koen[m]> Must be some modern c25 thing :)
<dirbaio[m]> which is great, let's normalize rust 🚀
<diondokter[m]> It's a repost of my blog at tweedegolf.nl. I expected they'd put a little bit of fluff at the start
<diondokter[m]> Oh well
<dirbaio[m]> if you don't know what a crate is, you're behind the times 🦀
<diondokter[m]> dirbaio[m]: Yeah, I've been really tempted to answer questions on the embedded subreddit where they ask 'How can I do PWM on STM32?'
<dirbaio[m]> "oh you're still not using rust?! 😱"
Makarov has joined #rust-embedded
starblue has quit [Quit: WeeChat 3.8]
Ralph[m] has joined #rust-embedded
<JamesMunns[m]> Hey! I could be potentially interested for my company OneVariable, if you're interested in machine to machine comms things :) Feel free to send me a DM, or shoot an email to contact@ onevariable dot com if you want to chat.
<barafael[m]> I'm updating this bno080 IMU driver to use e-h-1. So far, I have gotten it to compile and I'm soon gonna test if it works. But maybe somebody can have a look if this is done correctly?
<barafael[m]> I'm especially wondering what to do about this existing SensorInterface type, and how to handle supporting async peripheral drivers.
Makarov has quit [Ping timeout: 256 seconds]
JamesSizeland[m] has quit [Quit: Idle timeout reached: 172800s]
duderonomy has joined #rust-embedded
duderonomy has quit [Quit: Textual IRC Client: www.textualapp.com]
sroemer has joined #rust-embedded
dkm[m] has joined #rust-embedded
<dkm[m]> Hello 🦀! Any rmk dev or user here? I have an issue building it for my custom keyb, and I'm not sure what's the issue...
<dirbaio[m]> just ask the question! maybe someone knows
<dkm[m]> I have a board with an stm32f072cbt6 and I've followed the tutorial (with the template). I think I've adjusted all files correctly, but when building, I get:... (full message at <https://catircservices.org/_irc/v1/media/download/Aezcu3vYmiLtsSNXmeHZXYvAtHjeBxR9tL_9yuAnFPpnEIQ-tHytLg0EgmRndiHN8kq1X0kM-ksC-zAV0Jr9Eui_8AAAAAAAAGNhdGlyY3NlcnZpY2VzLm9yZy9zdVNiempJam1iRHJVUnpuc0lKZ0NpeWM>)
<JamesMunns[m]> Are you building with --release?
<dkm[m]> yes
<JamesMunns[m]> (that's a very typical error for when you are totally out of RAM, and the 072 doesn't have a ton
<JamesMunns[m]> * a ton)
<dkm[m]> it's using flip-link, but I don't think it's the issue
_whitelogger has joined #rust-embedded
<dkm[m]> Ok, so maybe by removing defmt (listed in rmk's list of thing to do to reduce size) and reducing the task allocator may help
<dkm[m]> I'll give it a shot in the weekend. Thanks a lot James Munns !
<JamesMunns[m]> yeah, you're specifically out of RAM (not flash - I think you have the 128K part and not the 64K part)
<dkm[m]> yes I have the 128k part 👍️
AdamHorden has quit [Ping timeout: 252 seconds]
AdamHorden has joined #rust-embedded
_whitelogger_ has quit [Remote host closed the connection]
_whitelogger_ has joined #rust-embedded
cinemaSundays has joined #rust-embedded
i509vcb[m] has quit [Quit: Idle timeout reached: 172800s]
<barafael[m]> what's the story with timeouts? I am using an embassy_futures select with my i2c and it works nicely. Is that the intended use?
<dirbaio[m]> Yup
<dirbaio[m]> There's also with_timeout in embassy-time which is a bit shorter
<dirbaio[m]> bt is the same otherwise
<diondokter[m]> Otherwise I don't really know how to discover that b and c exist based on a range from a to d
cinemaSundays has quit [Quit: Connection closed for inactivity]
<diondokter[m]> Yeah, agreed with that emoji...
<diondokter[m]> Maybe the user should directly specify the chain and then I only need to have code to check if it's valid?
<dirbaio[m]> plus they can be different types right? that's why you return a tuple and not an array
<diondokter[m]> Yeah
<JamesMunns[m]> It's sorta like the RTIC multilock stntax
<dirbaio[m]> if you got 2 regs that are identical (same fields etc) do you generate 1 type, or 2?
<JamesMunns[m]> s/stntax/syntax/
<JamesMunns[m]> JamesMunns[m]: I feel like they did a blanket impl instead of codegen tho
<diondokter[m]> dirbaio[m]: That's one type. But I could generate an extra Metadata struct for each individual one
<diondokter[m]> JamesMunns[m]: Yeah, might be possible too (though only for the chosen maximum length).
<diondokter[m]> But then still the question remains how I check whether it forms a valid chain
<JamesMunns[m]> diondokter[m]: Yeah, I probably don't understand the problem well enough :)
<dirbaio[m]> seems very cursed typelevel shit yeah
<diondokter[m]> JamesMunns[m]: Funny thing is that this got implemented because I complained about the abysmal UX of locking each one individually :P
<dirbaio[m]> i'm sure it's doable if you invent a typenum-like abomination
<dirbaio[m]> but maybe it's best not to try?
<dirbaio[m]> an alternative would be to do
<dirbaio[m]> and somehow at runtime if the addresses are consecutive then fuse them into single i2c/spi transactions?
<dirbaio[m]> and if not either issue separate txs, or just panic
<diondokter[m]> JamesMunns[m]: Many devices can read/write multiple registers in one transaction and I want device-driver creators to be able to leverage that
<diondokter[m]> Lol, honestly I did not consider runtime checks
<diondokter[m]> Zero cost everything!
<dirbaio[m]> if they're constants the compielr might be able to optimize them away
<dirbaio[m]> or not
<dirbaio[m]> idk :D
<diondokter[m]> * cost everything! (I say while my compiler is still going after 10 minutes)
<diondokter[m]> Not constants sadly
<diondokter[m]> Well...
<dirbaio[m]> I mean not const constants, I mean values that the compiler can predict so the optimizer can const-propagate
<diondokter[m]> If the compiler is smart enough it could read as constants for the compiler
<diondokter[m]> But it's pretty deep
sroemer has quit [Ping timeout: 248 seconds]
hadez[m] has quit [Quit: Idle timeout reached: 172800s]