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
Avery[m] has quit [Quit: Idle timeout reached: 172800s]
<JanSommer[m]> Hello everyone,
<JanSommer[m]> I am new to the whole contribution side of Rust.
<JanSommer[m]> I was referred to ask with the Rust Embedded group to see if there is someone who is able to review this PR.
<JanSommer[m]> I created a PR for a new Tier 3 target [1], but it seems to be quite niche. At least several of the reviewer assigned by the lottery had to pass.
<JanSommer[m]> Do you know someone I could reach out to? Or is there another forum where to ask?
<JamesMunns[m]> Maybe CC jessebraham mabez ? They are from Espressif, and might not be as familiar with ARM specific parts, but did upstream an RTOS target based on FreeRTOS
<JamesMunns[m]> And maybe CC thejpster
<JamesMunns[m]> I think this is the right place - or if not, I'm not sure where else would make sense, if you don't get any feedback today, you could add this to the agenda for the WG meeting next tuesday: https://github.com/rust-embedded/wg/discussions/780 to see if anyone else has feedback
<JanSommer[m]> Thanks. There is also not too much ARM specific outside of the spec file. RTEMS has a POSIX layer, so I could mostly reuse the unix flavor of the std library.
<JamesMunns[m]> Gotcha!
lehmrob has joined #rust-embedded
<ryan-summers[m]> MathiasKoch[m]: > <@mathias_koch:matrix.org> ryan-summers:... (full message at <https://catircservices.org/_matrix/media/v3/download/catircservices.org/tmHoCSfKtvSWzqVJmCalTQlA>)
<MathiasKoch[m]> obvious issue with this being, that for instance if you use those keys as storage keys in a key-value store, it wouldn't quite work as i would expect :/
<MathiasKoch[m]> Another way of supporting enums, would be to only support adjacently tagged and internally tagged enum representations? https://serde.rs/enum-representations.html
<MathiasKoch[m]> Or possibly only adjacently tagged..
<MathiasKoch[m]> s/../, in which case it works more like a struct in terms of keys and depth/
<MathiasKoch[m]> Hmm.. or, maybe not in terms of depth, as the content can still take different forms :(
<MathiasKoch[m]> Ohh shit no, any of those "tagged" representations results in the need for multiple keys per enum, that is probably a completely new level of unsupported
mobergmann[m] has joined #rust-embedded
<mobergmann[m]> Hi, I need your expertise. I hope you can help me. 😁
<mobergmann[m]> I want to use the [vl53l0x](https://docs.rs/vl53l0x/latest/vl53l0x/) driver and another driver on the same i2c bus. But it seems, that the i2c is consumed by the vl53l0x ([see here](https://docs.rs/vl53l0x/latest/vl53l0x/struct.VL53L0x.html#method.new)) driver. How would you handle this situation?
<ryan-summers[m]> mobergmann[m]: > <@mobergmann:matrix.bergnetz.org> Hi, I need your expertise. I hope you can help me. 😁
<ryan-summers[m]> > I want to use the [vl53l0x](https://docs.rs/vl53l0x/latest/vl53l0x/) driver and another driver on the same i2c bus. But it seems, that the i2c is consumed by the vl53l0x ([see here](https://docs.rs/vl53l0x/latest/vl53l0x/struct.VL53L0x.html#method.new)) driver. How would you handle this situation?
<ryan-summers[m]> This is why https://crates.io/crates/embedded-hal-bus was designed and released alongside the e-h 1.0 :) If you're on 0.2 e-h, use `shared-bus`
<JamesMunns[m]> Yep, also here's the docs for this: https://docs.rs/embedded-hal/latest/embedded_hal/i2c/index.html#bus-sharing
<dirbaio[m]> Or update the driver to eh1.0 😊
<JamesMunns[m]> the driver is 1.0
<ryan-summers[m]> Yeah I'd recommend upgrading for sure
<mobergmann[m]> <ryan-summers[m]> "> <@mobergmann:matrix.bergnetz...." <- wait, I am a bit confused. Where do I see the version, and the version of what? i am using the latest vl53l0x version and the arduino-hal (cargo generated about two weeks ago)
<ryan-summers[m]> You can look at the cargo.toml of the vl5310x crate, of you can use cargo tree -i embedded-hal and look at the dependency tree of the vl5310x crate
<ryan-summers[m]> s/of/or/, s//`/, s//`/
<dirbaio[m]> nb 💀
<ryan-summers[m]> nb is still in the embedded-nal too... I should probably pull it out
<mobergmann[m]> is nb bad?
<ryan-summers[m]> Its old and outdated. It was an idea before async code existed for embedded
<ryan-summers[m]> But never really worked that well in practice
<ryan-summers[m]> Its' not bad, just not very useful and adds lots of extra type wrappers to Results imo
<mobergmann[m]> ah, to bad 🤔
<mobergmann[m]> * ah, too bad 🤔
<dirbaio[m]> and it couples "nonblockingness" to "fallibility" :P
<ryan-summers[m]> Yeah that too is an unfortunate side-effect
dngrs[m] has quit [Quit: Idle timeout reached: 172800s]
<jessebraham[m]> <ryan-summers[m]> "Its old and outdated. It was..." <- Just out of curiosity, why did we both publishing `embedded-hal-nb@1.0.0` if this is the case?
<jessebraham[m]> It’s always seemed a bit out of place to me, I’ve actually considered just removing it altogether from `esp-hal` because I don’t think I’ve ever really seen anything implement those traits haha
<jessebraham[m]> s/both/bother/
<dirbaio[m]> Compromise to get consensus for removing it from the main crate. Some people do want to keep using it, completely dropping it was controversial.
<dirbaio[m]> But yeah it seems it's not getting much adoption, indeed
<ryan-summers[m]> I've only really seen it as a developmental impediment so far
<ryan-summers[m]> It's easy enough to write your own Error::NotReady if you truly need it
lehmrob has quit [Remote host closed the connection]
whitequark[cis] has quit [Quit: Idle timeout reached: 172800s]
diondokter[m] has quit [Quit: Idle timeout reached: 172800s]
Makarov has joined #rust-embedded
Makarov has quit [Quit: Client closed]
Makarov has joined #rust-embedded
thejpster[m] has quit [Quit: Idle timeout reached: 172800s]
Makarov43 has joined #rust-embedded
Makarov has quit [Ping timeout: 256 seconds]
bartmassey[m] has quit [Quit: Idle timeout reached: 172800s]
rmsyn[m] has quit [Quit: Idle timeout reached: 172800s]
AmanieudAntras[m has quit [Quit: Idle timeout reached: 172800s]
jasperw- has quit [*.net *.split]
tschundler has quit [*.net *.split]
jasperw- has joined #rust-embedded
tschundler has joined #rust-embedded
FolkertdeVries[m has quit [Quit: Idle timeout reached: 172800s]
adamgreig[m] has quit [Quit: Idle timeout reached: 172800s]
bpye has quit [Read error: Connection reset by peer]
bpye has joined #rust-embedded
Makarov91 has joined #rust-embedded
JamesSizeland[m] has joined #rust-embedded
<JamesSizeland[m]> Anyone else having issues flashing devices recently?
<JamesSizeland[m]> I'm getting the same behaviour on Windows and Linux, but has always worked in the past just fine.
<JamesSizeland[m]> When I run `cargo run --release` with my .cargo/config set to run either espflash flash or probe-rs run, I get 'could not execute process' 'program not found' whereas running the full command i.e. 'cargo espflash flash --monitor' it works!
Makarov43 has quit [Ping timeout: 256 seconds]
adamhott[m] has quit [Quit: Idle timeout reached: 172800s]
ello has quit [Quit: ZNC 1.8.2 - https://znc.in]
ello has joined #rust-embedded
ello has quit [Quit: ZNC 1.8.2 - https://znc.in]
ello has joined #rust-embedded
Makarov91 has quit [Quit: Client closed]
ivche has joined #rust-embedded
ivche has quit [Client Quit]
ivche has joined #rust-embedded
lanre[m] has quit [Quit: Idle timeout reached: 172800s]
ivche has quit [Quit: %bye%]
ivche has joined #rust-embedded
Vicente[m] has joined #rust-embedded
<Vicente[m]> <JamesSizeland[m]> "Anyone else having issues..." <- > <@jsizeland:matrix.org> Anyone else having issues flashing devices recently?... (full message at <https://catircservices.org/_matrix/media/v3/download/catircservices.org/dHEKnsMCjfPVBnBmioilhizo>)
M9names[m] has joined #rust-embedded
<M9names[m]> <JamesSizeland[m]> "Anyone else having issues..." <- > <@jsizeland:matrix.org> Anyone else having issues flashing devices recently?... (full message at <https://catircservices.org/_matrix/media/v3/download/catircservices.org/AsWGIsxxPsXQeeiZVNvjJbcF>)
<M9names[m]> Or is this only with esp devices so you need their toolchain
jannic[m] has quit [Quit: Idle timeout reached: 172800s]
cr1901_ has quit [Read error: Connection reset by peer]
jxsl has quit [Ping timeout: 264 seconds]
cr1901 has joined #rust-embedded
<JamesSizeland[m]> 1. BBC micro:bit CMSIS-DAP
<JamesSizeland[m]> <M9names[m]> "Or is this only with esp devices..." <- Now trying the probe-rs-tools to flash an old project to a BBC microbit and I get an error: 2 probes were found:
<JamesSizeland[m]> 2. CMSIS-DAP v1
<M9names[m]> Strange. If you unplug the micro-bit does it still list any probes? Might be able to resolve it by updating the micro-bit firmware.
<M9names[m]> But at least it's able to run probe-rs, so whatever issue you're having with esp is likely limited to the toolchain / environment installed via esp-up
dne has quit [Remote host closed the connection]
dne has joined #rust-embedded
Jonathan[m] has quit [Quit: Idle timeout reached: 172800s]
GrantM11235[m] has quit [Quit: Idle timeout reached: 172800s]
Ninetoone[m] has quit [Quit: Idle timeout reached: 172800s]
Sophie[m] has joined #rust-embedded
<Sophie[m]> I think I don't understand how rtic 1 priorities work. I have two tasks - one which is fast and polls the keyboard and is priority 2. The other is slow and renders to the screen at priority one.
<Sophie[m]> * priority one. Both re-enqueue themselves, and they don't share any common resources. The render method basically has a giant lock over a shared resource most of the time. It seems that this lock prevents the priority 2 task from running, but the locked resource isn't shared by both of them
<Sophie[m]> Is there a way I can get the keyboard task to run even when the render task is locked?
<Sophie[m]> Ah, I had a second priority 2 task which did share the resource w/ the render task, which seems to have caused the keyboard task to not run