radens has quit [Quit: Connection closed for inactivity]
<re_irc>
<@farbodpm:matrix.org> jamwaffles:matrix.org: Sorry, I solved the problem. TNX for your attention. Now I am working on decoding the msg on the host. I would appreciate if U share your experiance.
tokomak has joined #rust-embedded
creich_ has quit [Quit: Leaving]
creich has joined #rust-embedded
fabic has quit [Ping timeout: 256 seconds]
fabic has joined #rust-embedded
fabic has quit [Ping timeout: 264 seconds]
emerent has quit [Read error: Connection reset by peer]
emerent has joined #rust-embedded
<re_irc>
<@andresv:matrix.org> dirbaio: i am thinking if it makes sense to create a separate crate for your macros. There is an issue in `defmt` essentially about the same problem: https://github.com/knurling-rs/defmt/issues/463
<re_irc>
<@dirbaio:matrix.org> well that issue is about making defmt itself work on non-embedded
<re_irc>
<@dirbaio:matrix.org> not about having it delegate to `log`
<re_irc>
<@dirbaio:matrix.org> I tried to convert that `fmt.rs` to a separate crate, but the problem is that defmt's proc macros break when reexported
<re_irc>
<@dirbaio:matrix.org> also if you include it as a mod in your crate, the macros work everywhere without having to explicitly `use` them which is nice, and is not the csae if you import the macros from another crate
<re_irc>
<@dirbaio:matrix.org> especially with `panic!` and `assert!` etc, which will automatically use the custom ones instead of rust's ones
<re_irc>
<@andresv:matrix.org> I see.
fabic has joined #rust-embedded
<re_irc>
<@andresv:matrix.org> dirbaio: so fmt.rs is under MIT / Apache, do you happen to know if I can just copy it to a separate crate that is also MIT / Apache or do I have to also add attributions or something to that file?
<re_irc>
<@dirbaio:matrix.org> mit+apache yup
<re_irc>
<@dirbaio:matrix.org> but if you make it a separate crate it won't work
<re_irc>
<@dirbaio:matrix.org> you have to include it in the crate you want to use it from
<re_irc>
<@andresv:matrix.org> yup i am just copy-pasting the file
<re_irc>
<@henrik_alser:matrix.org> caemor: is the problem that Board doesn’t expose the TEMP peripheral?
<re_irc>
<@caemor:matrix.org> yeah
<re_irc>
<@henrik_alser:matrix.org> Best solution would be to PR it to do so :)
<re_irc>
<@caemor:matrix.org> 👍️
<re_irc>
<@caemor:matrix.org> I wasn't sure if I was just missing something. Thanks for the help. Going for the PR then.
<re_irc>
<@wim:dewith.io> I have a question about error types in the `embedded-hal` crate. Let me illustrate with an example, where I am writing a driver for a device `Foo`, which has an SPI interface and a reset pin:
<re_irc>
<@wim:dewith.io> use embedded_hal as hal;
<re_irc>
<@jacobrosenthal:matrix.org> Id say thats a fairly common pattern, even if not satisfying
<re_irc>
<@jacobrosenthal:matrix.org> you can also do from impls for all the errors and use into or auto coercion of the return type to save the .map_err, but then its more boilerplate somewhere else in your code
<re_irc>
<@jacobrosenthal:matrix.org> Id probably have more specific error types and maybe dump the discriminant in the enum, SpiConnectionError and SpiWhateverError instead of Spi(SpiErr)
<re_irc>
<@jacobrosenthal:matrix.org> Like id call it ResetFailed instead of Pin(PinErr) and just eat the underlying
<re_irc>
<@wim:dewith.io> Ah yeah, I also considered eating the underlying errors
<re_irc>
<@wim:dewith.io> I could even try to log them
<re_irc>
<@wim:dewith.io> And then eat them
<re_irc>
<@jacobrosenthal:matrix.org> for a published drive probably wouldnt hardcode logging, especially in embedded hard to know what style (defmt?) and then youd want to feature flag it for those who dont want it.
<re_irc>
<@jacobrosenthal:matrix.org> Ideally your descriptive error and the location of the error should be enough to reconstruct
<re_irc>
<@grantm11235:matrix.org> (Because `SpiErr` and `PinErr` could be the same type)
<re_irc>
<@dbrgn:matrix.coredump.ch> I'm debugging an issue with the STM32F4 HAL, where I2C writes fail and hang infinitely. The problem happens in `write_bytes`:
<re_irc>
<@dbrgn:matrix.coredump.ch> // Send a START condition
<re_irc>
<@dbrgn:matrix.coredump.ch> // Wait until START condition was generated
<re_irc>
<@newam:matrix.org> Just a sanity check, I2C is not in reset and I2C has clocks enabled?
<re_irc>
<@newam:matrix.org> Does anyone know of a good non-async HTTP client crate? I don't want to eat the tokio compile times for a quick hack :|
<re_irc>
<@dbrgn:matrix.coredump.ch> newam: The HAL should do that if I read the code properly...
<re_irc>
<@dbrgn:matrix.coredump.ch> It's also possible that a faulty device is connected, but that shouldn't prevent the hardware from generating the start condition, right?
<re_irc>
<@newam:matrix.org> Not sure about that one 🤔
<re_irc>
<@newam:matrix.org> You could try removing the device and see what it does
<re_irc>
<@henrik_alser:matrix.org> Danilo: is this always happening or just sometimes?
<re_irc>
<@henrik_alser:matrix.org> Do you have a scope?
<re_irc>
<@dbrgn:matrix.coredump.ch> henrik_alser: I think it's always happening.
<re_irc>
<@dbrgn:matrix.coredump.ch> Not here, but a cheap logic analyzer.
<re_irc>
<@henrik_alser:matrix.org> What speed and what value of pullup resistors?
<re_irc>
<@dbrgn:matrix.coredump.ch> Damn. I'm such an idiot. The project was lying around for a few weeks, and apparently the pullups aren't on my breadboard anymore and I didn't notice 🤦♂️🤦♂️🤦♂️
<re_irc>
<@dbrgn:matrix.coredump.ch> Thanks henrik_alser. At least I learned something about the I2C implementation on STM32 by reading through datasheets 😂
<re_irc>
<@henrik_alser:matrix.org> Ahh! Haha yeah good reason to do some reading then 🙌
<re_irc>
<@dirbaio:matrix.org> rustc will only use 1 core when compiling a PAC, is this normal?
<re_irc>
<@dirbaio:matrix.org> it's the biggest bottleneck by far of embassy's ci lol
<re_irc>
<@dbrgn:matrix.coredump.ch> dirbaio: I think 1 crate = 1 compilation unit = 1 parallelization unit...
<re_irc>
<@dirbaio:matrix.org> that builds like 10 pacs... and not in parallel! You can't run multiple cargos against the same target_dir concurrently
<re_irc>
<@dirbaio:matrix.org> first cargo will build all deps concurrently fast
<re_irc>
<@dbrgn:matrix.coredump.ch> Maybe you could create multiple git worktrees (https://git-scm.com/docs/git-worktree) attached to the same repo, and build independently?
<re_irc>
<@dbrgn:matrix.coredump.ch> That won't reuse deps though.
<re_irc>
<@dirbaio:matrix.org> next cargo invocations will only rebuild what changed, which is the PAC and embassy-nrf itself
<re_irc>
<@dirbaio:matrix.org> but they can't do it concurrently..
<re_irc>
<@newam:matrix.org> dbrgn:matrix.coredump.ch: it also depends on the codegen-units setting which is 16 by default, but a lot of people here set it to 1 for the best optimization.
<re_irc>
<@dirbaio:matrix.org> yeah I want to reuse deps :S
<re_irc>
<@dirbaio:matrix.org> I don't have codegen-units set
<re_irc>
<@dirbaio:matrix.org> but rustc won't go above 100% cpu (1 core) while building the pac
<re_irc>
<@grantm11235:matrix.org> Can you make a meta-crate that depends on the other crate multiple times with different options?
<re_irc>
<@dirbaio:matrix.org> hm can you do that? you can with different major versions, but *same* version different features?
<re_irc>
<@grantm11235:matrix.org> I thought I saw something about that being possible, or at least in progress. I might be thinking of `--target` options instead of features though...
<re_irc>
<@dirbaio:matrix.org> also it wouldn't work for bin crates
<re_irc>
<@come_744:converser.eu> dirbaio:matrix.org: I would have expected 1 rustc is 100% CPU, and cargo runs several rustc's in parrallel, one per core, no ?
<re_irc>
<@dirbaio:matrix.org> yeah that's what I'm seeing
<re_irc>
<@dirbaio:matrix.org> when you do `cargo build` it builds a "unit graph" of all the work it has to do, then runs it
<re_irc>
<@newam:matrix.org> linking is notoriously slow and single threaded for big embedded projects.
<re_irc>
<@dirbaio:matrix.org> this `cargo multi` thing I wrote parses multiple build commands, builds the unit graph for each, then *merges* them and then runs the merged unit graph
<re_irc>
<@dirbaio:matrix.org> so it does build the PACs and the `embassy-nrf`'s in parallel
<re_irc>
<@come_744:converser.eu> newam:matrix.org: There are independent target so independent linking should be possible I think
<re_irc>
<@dirbaio:matrix.org> it's broken for bins but I think I can get it to work with more haxx
<re_irc>
<@dirbaio:matrix.org> yeah if they give you 10 slow workers for free, it'd be great if you could choose 5 fast workers for free instead or something
<re_irc>
<@dirbaio:matrix.org> oops `fast.sh` is missing nrf5340
<re_irc>
<@dirbaio:matrix.org> 1m5.014s
<re_irc>
<@newam:matrix.org> newam:matrix.org: For anyone else wondering the same thing, `isahc` is really good. Faster to compile than tokio + reqwest when you only need to make a single HTTP get.
<re_irc>
<@dbrgn:matrix.coredump.ch> henrik_alser: hm, added the pullups, issue still happens. I guess I'll have to look at it with the scope tomorrow.
jackneilll has quit [Quit: Leaving]
jackneill has joined #rust-embedded
emerent_ has joined #rust-embedded
emerent is now known as Guest7858
emerent_ is now known as emerent
Guest7858 has quit [Ping timeout: 268 seconds]
derefnull has joined #rust-embedded
emerent has quit [Read error: Connection reset by peer]