starblue has joined #rust-embedded
starblue has quit [Ping timeout: 256 seconds]
starblue has joined #rust-embedded
creich_ has joined #rust-embedded
creich has quit [Ping timeout: 268 seconds]
radens has joined #rust-embedded
fabic has joined #rust-embedded
jackneilll has joined #rust-embedded
jackneill has quit [Ping timeout: 268 seconds]
PyroPeter has quit [Ping timeout: 260 seconds]
PyroPeter has joined #rust-embedded
radens has quit [Quit: Connection closed for inactivity]
<re_irc> <> 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> <> 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:
<re_irc> <> well that issue is about making defmt itself work on non-embedded
<re_irc> <> not about having it delegate to `log`
<re_irc> <> I tried to convert that `` to a separate crate, but the problem is that defmt's proc macros break when reexported
<re_irc> <> 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> <> especially with `panic!` and `assert!` etc, which will automatically use the custom ones instead of rust's ones
<re_irc> <> I see.
fabic has joined #rust-embedded
<re_irc> <> dirbaio: so 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> <> mit+apache yup
<re_irc> <> but if you make it a separate crate it won't work
<re_irc> <> you have to include it in the crate you want to use it from
<re_irc> <> yup i am just copy-pasting the file
fabic has quit [Ping timeout: 268 seconds]
<re_irc> <> Doesn't Apache license require attribution?
<re_irc> <> I think both require it.
<re_irc> <> According to this I can choose if I wanna use MIT or Apache.
<re_irc> <> It should be ok, if i add example 2 from here to file.
<re_irc> <> dirbaio: that is good stuff, started to use it here:
unmanbearpig has quit [Ping timeout: 268 seconds]
unmanbearpig has joined #rust-embedded
fabic has joined #rust-embedded
fabic has quit [Ping timeout: 256 seconds]
tokomak has quit [Read error: Connection reset by peer]
fabic has joined #rust-embedded
fabic has quit [Ping timeout: 268 seconds]
<re_irc> <> is there any way to get around the peripherals steal / unsafe code for the micro:bit v2 in my example here: ?
<re_irc> <> caemor: is the problem that Board doesn’t expose the TEMP peripheral?
<re_irc> <> yeah
<re_irc> <> Best solution would be to PR it to do so :)
<re_irc> <> 👍️
<re_irc> <> I wasn't sure if I was just missing something. Thanks for the help. Going for the PR then.
<re_irc> <> 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> <> ```rust
<re_irc> <> struct Foo<Spi, Reset> {
<re_irc> <> use embedded_hal as hal;
<re_irc> <> Id say thats a fairly common pattern, even if not satisfying
<re_irc> <> 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> <> Id probably have more specific error types and maybe dump the discriminant in the enum, SpiConnectionError and SpiWhateverError instead of Spi(SpiErr)
<re_irc> <> Like id call it ResetFailed instead of Pin(PinErr) and just eat the underlying
<re_irc> <> Ah yeah, I also considered eating the underlying errors
<re_irc> <> I could even try to log them
<re_irc> <> And then eat them
<re_irc> <> 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> <> Ideally your descriptive error and the location of the error should be enough to reconstruct
<re_irc> <> Unfortunately, that doesn't work in this case because you end up with conflicting `From<_>` impls for `Error<_, _>`
<re_irc> <> (Because `SpiErr` and `PinErr` could be the same type)
<re_irc> <> I'm debugging an issue with the STM32F4 HAL, where I2C writes fail and hang infinitely. The problem happens in `write_bytes`:
<re_irc> <> // Send a START condition
<re_irc> <> // Wait until START condition was generated
<re_irc> <> self.i2c.cr1.modify(|_, w| w.start().set_bit());
<re_irc> <> Just a sanity check, I2C is not in reset and I2C has clocks enabled?
<re_irc> <> 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> <> newam: The HAL should do that if I read the code properly...
<re_irc> <> 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> <> Not sure about that one 🤔
<re_irc> <> You could try removing the device and see what it does
<re_irc> <> Danilo: is this always happening or just sometimes?
<re_irc> <> Do you have a scope?
<re_irc> <> henrik_alser: I think it's always happening.
<re_irc> <> Not here, but a cheap logic analyzer.
<re_irc> <> What speed and what value of pullup resistors?
<re_irc> <> 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> <> Thanks henrik_alser. At least I learned something about the I2C implementation on STM32 by reading through datasheets 😂
<re_irc> <> Ahh! Haha yeah good reason to do some reading then 🙌
<re_irc> <> rustc will only use 1 core when compiling a PAC, is this normal?
<re_irc> <> it's the biggest bottleneck by far of embassy's ci lol
<re_irc> <> ```sh
<re_irc> <> export CARGO_TARGET_DIR=$PWD/target_ci
<re_irc> <> #!/bin/bash
<re_irc> <> cargo build --release --manifest-path embassy-nrf/Cargo.toml --target thumbv7em-none-eabi --features nrf52805
<re_irc> <> dirbaio: I think 1 crate = 1 compilation unit = 1 parallelization unit...
<re_irc> <> that builds like 10 pacs... and not in parallel! You can't run multiple cargos against the same target_dir concurrently
<re_irc> <> first cargo will build all deps concurrently fast
<re_irc> <> Maybe you could create multiple git worktrees ( attached to the same repo, and build independently?
<re_irc> <> That won't reuse deps though.
<re_irc> <> next cargo invocations will only rebuild what changed, which is the PAC and embassy-nrf itself
<re_irc> <> but they can't do it concurrently..
<re_irc> <> 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> <> yeah I want to reuse deps :S
<re_irc> <> I don't have codegen-units set
<re_irc> <> but rustc won't go above 100% cpu (1 core) while building the pac
<re_irc> <> Can you make a meta-crate that depends on the other crate multiple times with different options?
<re_irc> <> hm can you do that? you can with different major versions, but *same* version different features?
<re_irc> <> 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> <> also it wouldn't work for bin crates
<re_irc> <> :(
<re_irc> <> I think that this is what I was thinking of
<re_irc> <> oh hmhmmh what, you can have bin dependencies?
<re_irc> <> ah still WIP
<re_irc> <> I would have expected 1 rustc is 100% CPU, and cargo runs several rustc's in parrallel, one per core, no ?
<re_irc> <> yeah that's what I'm seeing
<re_irc> <> ```sh
<re_irc> <> build --manifest-path embassy-nrf/Cargo.toml --target thumbv7em-none-eabi --features nrf52805 --- \
<re_irc> <> /home/dirbaio/cargo/target/release/cargo multi -- \
<re_irc> <> build --manifest-path embassy-nrf/Cargo.toml --target thumbv7em-none-eabi --features nrf52810 --- \
<re_irc> <> `cargo multi` 👀
<re_irc> <> [dirbaiomars embassy]$ time ./
<re_irc> <> [dirbaiomars embassy]$ rm -rf target_ci/
<re_irc> <> user 4m47.134s
<re_irc> <> real 2m47.951s
<re_irc> <> it's a horrible hack lmao
<re_irc> <> but it seems it works? 3x faster
<re_irc> <> 3 CPUs ? 🤔 😆
<re_irc> <> Maybe init time…
<re_irc> <> when you do `cargo build` it builds a "unit graph" of all the work it has to do, then runs it
<re_irc> <> linking is notoriously slow and single threaded for big embedded projects.
<re_irc> <> 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> <> so it does build the PACs and the `embassy-nrf`'s in parallel
<re_irc> <> There are independent target so independent linking should be possible I think
<re_irc> <> it's broken for bins but I think I can get it to work with more haxx
<re_irc> <> I'm surprised this doesn't make Cargo explode
<re_irc> <> That is coming up soon too :D
<re_irc> <> I don't know if/how it will cost for open source though.
<re_irc> <> 🤣
<re_irc> <> niice
<re_irc> <> You are going to need to come up with a different name though
<re_irc> <> 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> <> oh nooo 🤣
<re_irc> <> (That's the hardest part 🤣)
<re_irc> <> May I suggest `cargo-spaceheater`?
<re_irc> <> `cargo fast`
<re_irc> <> full output
<re_irc> <> `cargo parallel`? :P
<re_irc> <> or `cargo concurrently`
<re_irc> <> (inspired by
<re_irc> <> oops `` is missing nrf5340
<re_irc> <> 1m5.014s
<re_irc> <> 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> <> 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]
emerent has joined #rust-embedded