<re_irc>
<@sajattack:matrix.org> no word if it has accessible jtag though
PyroPeter has quit [Ping timeout: 265 seconds]
PyroPeter has joined #rust-embedded
fabic has quit [Ping timeout: 264 seconds]
fabic has joined #rust-embedded
Amanieu_ has quit [*.net *.split]
cyrozap has quit [*.net *.split]
Lumpio- has quit [*.net *.split]
x56 has quit [*.net *.split]
cyrozap has joined #rust-embedded
Lumpio- has joined #rust-embedded
Amanieu has joined #rust-embedded
x56 has joined #rust-embedded
fabic has quit [Ping timeout: 265 seconds]
fabic has joined #rust-embedded
Shell is now known as Shellhound
SanchayanMaity has quit [Ping timeout: 245 seconds]
SanchayanMaity has joined #rust-embedded
<re_irc>
<@mygnu:matrix.org> 👍
<re_irc>
<@henrik_alser:matrix.org> firefrommoonlight:matrix.org: Ahh! Good to hear! (How id that even possible, isn't this typestate enforced? Or what hal is that?)
fabic has quit [Ping timeout: 260 seconds]
fabic has joined #rust-embedded
<re_irc>
<@firefrommoonlight:matrix.org> Not using typestates
<re_irc>
<@henrik_alser:matrix.org> firefrommoonlight:matrix.org: What hal?
<re_irc>
<@henrik_alser:matrix.org> Or have i been sleeping for too long?
<re_irc>
<@firefrommoonlight:matrix.org> I even have an I2C example with open drain in the readme :/
<re_irc>
<@henrik_alser:matrix.org> Ahh i see! What’s the reason for not using typestates?
<re_irc>
<@firefrommoonlight:matrix.org> They cause friction when used in practical code. I think a lot of the examples you see in HALs that use them omit this by using simple examples with everything in the main fn
<re_irc>
<@firefrommoonlight:matrix.org> They do, of course, prevent problems like this!
fabic has quit [Ping timeout: 258 seconds]
<re_irc>
<@henrik_alser:matrix.org> Can’t think of what situations it has caused me problems but yeah it has saved me so many times and was one of the big selling points for me to switch to rust a cpl years ago
<re_irc>
<@henrik_alser:matrix.org> But ymmv of course :)
<re_irc>
<@diondokter:matrix.org> Sometimes it got in the way for me. But then you can always just create an enum containing all the different states you're gonna need. Or if you need only one state, you can make a type alias.
<re_irc>
<@diondokter:matrix.org> But, I do like it in general (for configs that don change a lot) and has saved me more time than it has cost me :)
fabic has joined #rust-embedded
fabic has quit [Ping timeout: 260 seconds]
<re_irc>
<@henrikssn:matrix.org> Does anyone use defmt in combination with embedded-time?
<re_irc>
<@henrikssn:matrix.org> In particular, I want to print the value of a `Duration` but rustc complains that `the trait `Format` is not implemented for `embedded_time::duration::Generic<<C as embedded_time::Clock>::T>`
<re_irc>
<@dirbaio:matrix.org> `embedded-time` would have to add support for `defmt`
<re_irc>
<@dirbaio:matrix.org> alternatively you can make your own wrapper type
<re_irc>
<@dirbaio:matrix.org> ```rust
<re_irc>
<@dirbaio:matrix.org> impl defmt::Format for FormatDuration { ... impl here ... }
<re_irc>
<@dirbaio:matrix.org> type FormatDuration(embedded_time::duration::Generic<whatever>);
<re_irc>
<@dirbaio:matrix.org> or use defmt's Display2Format or Debug2Format, but that'll format it as a string on the target so you lose the efficiency advantage of defmt
<re_irc>
<@thejpster:matrix.org> Quick macro question - is it possible to have a macro create a global variable with a unique name?
<re_irc>
<@thejpster:matrix.org> Trying to stuff things into linker sections - don't care what they are called, but if I want two of them and I call the macro twice, it complains I have two variables with the same name.#
<re_irc>
<@dirbaio:matrix.org> I don't think it's possible with macro_rules, no...
<re_irc>
<@thejpster:matrix.org> Boo
<re_irc>
<@thejpster:matrix.org> I don't even think concat_idents is stable either.
<re_irc>
<@dirbaio:matrix.org> you can create "anonymous" scopes with `const _`
<re_irc>
<@dirbaio:matrix.org> hopefully that works!
<re_irc>
<@dirbaio:matrix.org> thejpster
<re_irc>
<@firefrommoonlight:matrix.org> This is my main spear against `defmt`. You could print arbitrary `Debug` (and/or `Format`)-impling data with other solutions
<re_irc>
<@dirbaio:matrix.org> core::fmt::Debug, core::fmt::Display force the use of `core::fmt` which is insanely bloated
<re_irc>
<@firefrommoonlight:matrix.org> Makes sense
<re_irc>
<@dirbaio:matrix.org> if the bloat is OK for your usecase then of course use it instead of defmt
<re_irc>
<@firefrommoonlight:matrix.org> (Those other solutiosn were super slow compared to defmt!)
<re_irc>
<@firefrommoonlight:matrix.org> I remember ITT target printing a char at a time in front of my eyes
<re_irc>
<@dirbaio:matrix.org> defmt's "pain" is worth it if you want to optimize speed or code size
<re_irc>
<@dirbaio:matrix.org> but yeah it definitely brings some pain, these efficiency gains are not free
<re_irc>
<@korken89:matrix.org> firefrommoonlight:matrix.org: Noah and I made a PoC for dwarffmt, it used dwarf information to print anything without the need for a derive or something like that. Sadly we didn't finish it yet. If you want you can have a look :) https://github.com/korken89/fasthosting/tree/recursion-works
<re_irc>
<@korken89:matrix.org> Nothing is documented yet though :P
<re_irc>
<@firefrommoonlight:matrix.org> Nice
<re_irc>
<@henrikssn:matrix.org> dirbaio:matrix.org: The binary size for the release build decreased by 50% when I moved from RTT logging to defmt
<re_irc>
<@henrikssn:matrix.org> It does make quite a difference
<re_irc>
<@dirbaio:matrix.org> yeah it was 50% for me too :D
<re_irc>
<@dirbaio:matrix.org> and defmt 0.3 will be even smaller
fabic has joined #rust-embedded
<re_irc>
<@firefrommoonlight:matrix.org> Why does the logger affect release builds?
<re_irc>
<@firefrommoonlight:matrix.org> Does this increase go away If you remove all defmt::info etc lines?
<re_irc>
<@henrikssn:matrix.org> You can just disable the featurein Cargo.toml, but that means you also lose the logging
<re_irc>
<@henrikssn:matrix.org> With RTT, first the debug build outgrew my 128kB of flash, then the release build followed and app did not build anymore
<re_irc>
<@henrikssn:matrix.org> Now debug build is ~60kB
fabic has quit [Ping timeout: 258 seconds]
<re_irc>
<@dirbaio:matrix.org> yeah I ship the firmware with logs because it has a thingy that snapshots and uploads the logs on crash
<re_irc>
<@dirbaio:matrix.org> ofc you can completely disable defmt in release builds if you don't need it
<re_irc>
<@firefrommoonlight:matrix.org> What if you comment out the debug lines but leave defmt in otherwise? Do you still pay the penalty? I am thinking for production flashing
<re_irc>
<@dirbaio:matrix.org> defmt-rtt has some statics that probably won't get optimized out.
<re_irc>
<@TimSmall:matrix.org> I'm implementing a crate to read data (and possibly carry out some limited configuration) on some Solar PV -> Grid inverters. The protocol is documented by the manufacturer http://yamasun.com.tw/upload/F_20170313191367UrC8jo.PDF and is implemented as simplex RS485, and also over USB HID (with an additional packet header). I believe it's also possible to communicate with the same device using UDP over wifi...
<re_irc>
... as well, and I presume that the same protocol is used yet again, but encapsulated into UDP packets. I've started implementing it using Google's zerocopy crate (from the Fuchsia OS project) to implement it, since this is a packety format, with optional encapsulation in other packets (USB HID), but I was wondering if serde would be a better fit?
<re_irc>
<@TimSmall:matrix.org> Any thoughts welcome!
<re_irc>
<@TimSmall:matrix.org> I plan to support misc OS environments (e.g. for USB data exchange), but I'd like to have a micro-controller be able to be the bus master too (initially with RS485).
<re_irc>
<@jamesmunns:beeper.com> Happy to chat about RS-485, also using that for Powerbus, but using a totally bespoke (serde based) line format.
<re_irc>
<@ryan-summers:matrix.org> custom build.rs to pick the linker
<re_irc>
<@dirbaio:matrix.org> ryan-summers:matrix.org: I had that a while ago, but app and bootloader need different features enabled in deps... :(
<re_irc>
<@ryan-summers:matrix.org> Ah right, forgot about that
<re_irc>
<@dirbaio:matrix.org> and different deps too (no defmt in bootloader for example...)
<re_irc>
<@dirbaio:matrix.org> it turned into an optional-dep mess very fast lol
<re_irc>
<@ryan-summers:matrix.org> Why not just carefully track versions in your TOML files carefully whenever you update deps and use two crates?
<re_irc>
<@ryan-summers:matrix.org> Outside of the fact that it's annoying
<re_irc>
<@dirbaio:matrix.org> yeah, that's probably the least bad
<re_irc>
<@dirbaio:matrix.org> just giving up
<re_irc>
<@dirbaio:matrix.org> and having one cargo.lock per crate...
<re_irc>
<@ryan-summers:matrix.org> I mean it conceptually doesn't make sense to have a single lockfile for a binary that doesn't use deps that are in the lockfile
<re_irc>
<@dirbaio:matrix.org> why not?
<re_irc>
<@dirbaio:matrix.org> app+bl share many deps
<re_irc>
<@ryan-summers:matrix.org> But not the same deps
<re_irc>
<@dirbaio:matrix.org> sharing a Cargo.lock ensures they're the same version, helps make CI builds faster
<re_irc>
<@ryan-summers:matrix.org> Because features change them
<re_irc>
<@ryan-summers:matrix.org> The actual compiled dep is different with different features
<re_irc>
<@dirbaio:matrix.org> that's a small fraction of the crates only though
<re_irc>
<@ryan-summers:matrix.org> But I see what you mean, shared deps and features could theoretically be faster
<re_irc>
<@dirbaio:matrix.org> I'm also highly annoyed that Cargo can't build incompatible trees at the same time
<re_irc>
<@dirbaio:matrix.org> I can't build app+bl at the same time
<re_irc>
<@ryan-summers:matrix.org> Why not just do two processes?
<re_irc>
<@dirbaio:matrix.org> (I can if I give each a private target/ dir, but then it wastes more effort building duplicate deps)
<re_irc>
<@dirbaio:matrix.org> so I just run `cargo build this`, `cargo build that`
<re_irc>
<@ryan-summers:matrix.org> Most CI (e.g. GHA) allows you to easily parallelize builds
<re_irc>
<@dirbaio:matrix.org> but end-stages of the build are mostly single threaded (linking etc)
<re_irc>
<@ryan-summers:matrix.org> Linking isn't the long part ime
<re_irc>
<@dirbaio:matrix.org> it is if you're building app, bootloader, ~10 test binaries, for 9 product/revision combinations :D
<re_irc>
<@ryan-summers:matrix.org> Eh, I'd personally probably die on a different hill
<re_irc>
<@dirbaio:matrix.org> CPU averages ~35% over all the build
<re_irc>
<@dirbaio:matrix.org> 😭
<re_irc>
<@ryan-summers:matrix.org> Again, just parallelize your build with a custom --dir flag for each CI thread
<re_irc>
<@dirbaio:matrix.org> 124 binaries total
<re_irc>
<@ryan-summers:matrix.org> Doesn't GHA allow you to use custom build environment containers, so you could automatically scale some cloud infra for it?
<re_irc>
<@dirbaio:matrix.org> using selfhosted gitlab
<re_irc>
<@ryan-summers:matrix.org> And cache intermediary results using cargo-cache for each build
<re_irc>
<@ryan-summers:matrix.org> Oh
<re_irc>
<@dirbaio:matrix.org> still
<re_irc>
<@dirbaio:matrix.org> a full cold build takes 15min averaging 35% cpu
<re_irc>
<@dirbaio:matrix.org> it could take 5min at 100% cpu
<re_irc>
<@dirbaio:matrix.org> but noooo
<re_irc>
<@ryan-summers:matrix.org> With cargo caching you can make it a lot faster btw
<re_irc>
<@ryan-summers:matrix.org> Dunno if gitlab CI supports caching deps like that
<re_irc>
<@dirbaio:matrix.org> it does but it sucks
<re_irc>
<@jamesmunns:beeper.com> sccache if it's in an env you control?
<re_irc>
<@dirbaio:matrix.org> it'd be neat if you could tell cargo
<re_irc>
<@dirbaio:matrix.org> I want `[bin=application, features=product-foo], [bin=application, features=product-bar]`, GO
<re_irc>
<@dirbaio:matrix.org> same bin but different feats
<re_irc>
<@dirbaio:matrix.org> so linking etc gets paralelized
<re_irc>
<@dirbaio:matrix.org> how do you tell rust-analyzer to treat one Cargo.toml as "main" and ignore the others?
<re_irc>
<@dirbaio:matrix.org> what does rust-analyzer even do if you open a dir with multiple crates but with no workspace?
<re_irc>
<@thejpster:matrix.org> I've spent a lot of time thinking in the past how I can make build systems faster.
<re_irc>
<@thejpster:matrix.org> I eventually concluded that the only way to be sure is just to let the whole build run from scratch.
<re_irc>
<@thejpster:matrix.org> (this was pre-Rust - my goodness have I worked on some real doozies in the past. Like the one that would pipe Makefiles through Perl to generate new Makefiles)
<re_irc>
<@thejpster:matrix.org> I just bought more CI minutes and moved on.
<re_irc>
<@thejpster:matrix.org> You almost certainly have owned a product running firmware that was built with that make/perl/make build system too.
<re_irc>
<@dirbaio:matrix.org> dirbaio:matrix.org: found it: `rust-analyzer.linkedProjects`
<re_irc>
<@dirbaio:matrix.org> so I just enable the one thing I'm working on: `"rust-analyzer.linkedProjects": ["ak-application/Cargo.toml"]`
<re_irc>
<@dirbaio:matrix.org> that activates RA for that crate, but also its in-repo deps automatically
<re_irc>
<@dirbaio:matrix.org> and doesn't explode due to conflicting features
<re_irc>
<@dirbaio:matrix.org> yay
emerent is now known as Guest540
emerent_ has joined #rust-embedded
emerent_ is now known as emerent
Guest540 has quit [Killed (tungsten.libera.chat (Nickname regained by services))]