DepthDeluxe has quit [Ping timeout: 264 seconds]
<re_irc> <> So, it turns out, I am, as we speculated, a dumb-dumb
<re_irc> <> Forgot about the whole open-drain thing for I2C
<re_irc> <> Sry... "industry-standard 2-wire protocol"
<re_irc> <> dirbaio: would be right to give me shit for not having the I2C constructor set up the pins automatically
<re_irc> <> πŸ‘Ώ
<re_irc> <> you got your rustc privileges suspended for 1 week
<re_irc> <> you'll have to write C for a bit
<re_irc> <> 😜
<re_irc> <> |=crap
fabic has joined #rust-embedded
<cr1901> >you'll have to write C for a bit
<cr1901> A better punishment for me would be "you must write nothing but crates/code for ARM for a year"
<cr1901> lmao
<re_irc> <> x86 is not worse? :D
starblue has quit [Ping timeout: 265 seconds]
<cr1901> Hmmm, good question. x86 probably not, x64 and vectorizable code yes
starblue has joined #rust-embedded
<re_irc> <> new chinese seller on tindie has lots of cool stuff, including this pinetime-alike
<re_irc> <> 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> <> πŸ‘
<re_irc> <> 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> <> Not using typestates
<re_irc> <> What hal?
<re_irc> <> Or have i been sleeping for too long?
<re_irc> <> my own
<re_irc> <>
<re_irc> <> I even have an I2C example with open drain in the readme :/
<re_irc> <> Ahh i see! What’s the reason for not using typestates?
<re_irc> <> 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> <> They do, of course, prevent problems like this!
fabic has quit [Ping timeout: 258 seconds]
<re_irc> <> 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> <> But ymmv of course :)
<re_irc> <> 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> <> 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> <> Does anyone use defmt in combination with embedded-time?
<re_irc> <> 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> <> `embedded-time` would have to add support for `defmt`
<re_irc> <> alternatively you can make your own wrapper type
<re_irc> <> ```rust
<re_irc> <> impl defmt::Format for FormatDuration { ... impl here ... }
<re_irc> <> type FormatDuration(embedded_time::duration::Generic<whatever>);
<re_irc> <> defmt::info!("dur = {:?}", FormatDuration(my_dur));
<re_irc> <> 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> <> Quick macro question - is it possible to have a macro create a global variable with a unique name?
<re_irc> <> 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> <> I don't think it's possible with macro_rules, no...
<re_irc> <> Boo
<re_irc> <> I don't even think concat_idents is stable either.
<re_irc> <> oh wow
<re_irc> <> you can create "anonymous" scopes with `const _`
<re_irc> <> hopefully that works!
<re_irc> <> thejpster
<re_irc> <> This is my main spear against `defmt`. You could print arbitrary `Debug` (and/or `Format`)-impling data with other solutions
<re_irc> <> core::fmt::Debug, core::fmt::Display force the use of `core::fmt` which is insanely bloated
<re_irc> <> Makes sense
<re_irc> <> if the bloat is OK for your usecase then of course use it instead of defmt
<re_irc> <> (Those other solutiosn were super slow compared to defmt!)
<re_irc> <> I remember ITT target printing a char at a time in front of my eyes
<re_irc> <> defmt's "pain" is worth it if you want to optimize speed or code size
<re_irc> <> but yeah it definitely brings some pain, these efficiency gains are not free
<re_irc> <> 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 :)
<re_irc> <> Nothing is documented yet though :P
<re_irc> <> Nice
<re_irc> <> The binary size for the release build decreased by 50% when I moved from RTT logging to defmt
<re_irc> <> It does make quite a difference
<re_irc> <> yeah it was 50% for me too :D
<re_irc> <> and defmt 0.3 will be even smaller
fabic has joined #rust-embedded
<re_irc> <> Why does the logger affect release builds?
<re_irc> <> Does this increase go away If you remove all defmt::info etc lines?
<re_irc> <> You can just disable the featurein Cargo.toml, but that means you also lose the logging
<re_irc> <> With RTT, first the debug build outgrew my 128kB of flash, then the release build followed and app did not build anymore
<re_irc> <> Now debug build is ~60kB
fabic has quit [Ping timeout: 258 seconds]
<re_irc> <> yeah I ship the firmware with logs because it has a thingy that snapshots and uploads the logs on crash
<re_irc> <> ofc you can completely disable defmt in release builds if you don't need it
<re_irc> <> 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> <> defmt-rtt has some statics that probably won't get optimized out.
<re_irc> <> 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 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> <> Any thoughts welcome!
<re_irc> <> 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> <> Happy to chat about RS-485, also using that for Powerbus, but using a totally bespoke (serde based) line format.
<re_irc> <> You might find the defmt docs interesting:
<re_irc> <> Is there a way to "share" a Cargo.lock for multiple crates?
<re_irc> <> Workspace?
<re_irc> <> crates that can *not* go in the same Cargo workspace because they enable incompatible features in deps :(
<re_irc> <> oh :(
<re_irc> <> application + bootloader
<re_irc> <> I can copypaste the Cargo.lock around which kinda works for the "common" deps
<re_irc> <> not afaik, then
<re_irc> <> CI check looking at common deps?
<re_irc> <> but it *removes* the non-common ones
<re_irc> <> and always does "updating index" for them
<re_irc> <> so they'll pick whatever random latest version of the day
<re_irc> <> plus making the build even slower :|
<re_irc> <> Maybe you can curse it by symlinking it 😈
<re_irc> <> You could specify exact versions in your cargo tomls
<re_irc> <> e.g. `lib = "=0.4.3"` or whatever
<re_irc> <> that doesn't work for deps-of-deps :(
<re_irc> <> ah, fair
<re_irc> <> make them an unused dep in the top level? :p
<re_irc> <> I guess
<re_irc> <> still, wtf
<re_irc> <> why is this so hard
<re_irc> <> symlinking also has the same problem: cargo removes crate B's deps when building crate A
<re_irc> <> because it's a super esoteric use case?
<re_irc> <> I don't think it's that esoteric :(
<re_irc> <> I mean (famous last words) I feel like you could "merge" lockfiles somewhat straightfowardly?
<re_irc> <> if you try making a monorepo you *will* run into that
<re_irc> <> all Big Tech is running into that
<re_irc> <> Keep lockfile somewhere common, add a to move it?
<re_irc> <> or copy at build time?
<re_irc> <> Dude, that is next level.
<re_irc> <> copy/symlink doesn't work because of this...
<re_irc> <> Ah but how do you update it
<re_irc> <> yeah
<re_irc> <> if only there was some "update stuff but do NOT remove stuff you think is unused" or something...
<re_irc> <> My favorite part is where we use JSON for symbol names, because we can.
<re_irc> <> I'm running into this problem with application+bootloader
<re_irc> <> I cannot quite believe that is supported, even though I'm looking right at it
<re_irc> <> but also with embedded fw + non-embedded server stuff πŸ’©
<re_irc> <> I guess it gets mangled?
<re_irc> <> That makes me moderately upset honestly
<re_irc> <> I love it
<re_irc> <> uhhh, Jonas is the one that implemented that
<re_irc> <> I think he was just as surprised as we all were.
<re_irc> <> you can have any char in symbol names other than ``
<re_irc> <> ideally I want in the same repo these crates:
<re_irc> <> - firmware bootloader
<re_irc> <> - crate implementing the network protocol (cross platform)
<re_irc> <> - firmware application
<re_irc> <> because I'm going crazy with so many repos
<re_irc> <> but with this I'm going crazy with cargo workspace/lock hacks instead 😭
<re_irc> <> Why not just have 1 crate with 2 bins? Can you not specify a different linker per bin?
<re_irc> <>
<re_irc> <> branch name: `cursed-symbol-names-linkers-must-repent-for-their-sins`
<re_irc> <> custom to pick the linker
<re_irc> <> I had that a while ago, but app and bootloader need different features enabled in deps... :(
<re_irc> <> Ah right, forgot about that
<re_irc> <> and different deps too (no defmt in bootloader for example...)
<re_irc> <> it turned into an optional-dep mess very fast lol
<re_irc> <> Why not just carefully track versions in your TOML files carefully whenever you update deps and use two crates?
<re_irc> <> Outside of the fact that it's annoying
<re_irc> <> yeah, that's probably the least bad
<re_irc> <> just giving up
<re_irc> <> and having one cargo.lock per crate...
<re_irc> <> 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> <> why not?
<re_irc> <> app+bl share many deps
<re_irc> <> But not the same deps
<re_irc> <> sharing a Cargo.lock ensures they're the same version, helps make CI builds faster
<re_irc> <> Because features change them
<re_irc> <> The actual compiled dep is different with different features
<re_irc> <> that's a small fraction of the crates only though
<re_irc> <> But I see what you mean, shared deps and features could theoretically be faster
<re_irc> <> I'm also highly annoyed that Cargo can't build incompatible trees at the same time
<re_irc> <> I can't build app+bl at the same time
<re_irc> <> Why not just do two processes?
<re_irc> <> (I can if I give each a private target/ dir, but then it wastes more effort building duplicate deps)
<re_irc> <> so I just run `cargo build this`, `cargo build that`
<re_irc> <> Most CI (e.g. GHA) allows you to easily parallelize builds
<re_irc> <> but end-stages of the build are mostly single threaded (linking etc)
<re_irc> <> Linking isn't the long part ime
<re_irc> <> it is if you're building app, bootloader, ~10 test binaries, for 9 product/revision combinations :D
<re_irc> <> Eh, I'd personally probably die on a different hill
<re_irc> <> CPU averages ~35% over all the build
<re_irc> <> 😭
<re_irc> <> Again, just parallelize your build with a custom --dir flag for each CI thread
<re_irc> <> 124 binaries total
<re_irc> <> Doesn't GHA allow you to use custom build environment containers, so you could automatically scale some cloud infra for it?
<re_irc> <> using selfhosted gitlab
<re_irc> <> And cache intermediary results using cargo-cache for each build
<re_irc> <> Oh
<re_irc> <> still
<re_irc> <> a full cold build takes 15min averaging 35% cpu
<re_irc> <> it could take 5min at 100% cpu
<re_irc> <> but noooo
<re_irc> <> With cargo caching you can make it a lot faster btw
<re_irc> <> Dunno if gitlab CI supports caching deps like that
<re_irc> <> it does but it sucks
<re_irc> <> (GHA caching sucks too)
<re_irc> <> It speeds up our builds a lot:
<re_irc> <> sccache if it's in an env you control?
<re_irc> <> it'd be neat if you could tell cargo
<re_irc> <> I want `[bin=application, features=product-foo], [bin=application, features=product-bar]`, GO
<re_irc> <> same bin but different feats
<re_irc> <> so linking etc gets paralelized
<re_irc> <> how do you tell rust-analyzer to treat one Cargo.toml as "main" and ignore the others?
<re_irc> <> what does rust-analyzer even do if you open a dir with multiple crates but with no workspace?
<re_irc> <> I've spent a lot of time thinking in the past how I can make build systems faster.
<re_irc> <> I eventually concluded that the only way to be sure is just to let the whole build run from scratch.
<re_irc> <> (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> <> I just bought more CI minutes and moved on.
<re_irc> <> You almost certainly have owned a product running firmware that was built with that make/perl/make build system too.
<re_irc> <> found it: `rust-analyzer.linkedProjects`
<re_irc> <> so I just enable the one thing I'm working on: `"rust-analyzer.linkedProjects": ["ak-application/Cargo.toml"]`
<re_irc> <> that activates RA for that crate, but also its in-repo deps automatically
<re_irc> <> and doesn't explode due to conflicting features
<re_irc> <> yay
emerent is now known as Guest540
emerent_ has joined #rust-embedded
emerent_ is now known as emerent
Guest540 has quit [Killed ( (Nickname regained by services))]