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
cr1901 has quit [Read error: Connection reset by peer]
cr1901 has joined #rust-embedded
cr1901 has quit [Ping timeout: 276 seconds]
cr1901 has joined #rust-embedded
jcroisant has joined #rust-embedded
cr1901 has quit [Read error: Connection reset by peer]
cr1901 has joined #rust-embedded
_whitelogger has joined #rust-embedded
ska has quit [Ping timeout: 260 seconds]
Emkanea[m] has quit [Quit: Idle timeout reached: 172800s]
ello has quit [Quit: ZNC 1.9.1 - https://znc.in]
ello- has joined #rust-embedded
ello_ has quit [Read error: Connection reset by peer]
ello has joined #rust-embedded
sroemer has joined #rust-embedded
sroemer has quit [Changing host]
sroemer has joined #rust-embedded
sroemer has quit [Client Quit]
sroemer has joined #rust-embedded
rafael[m] has joined #rust-embedded
<rafael[m]> James Munns I found your workshop book for postcard rpc, very cool! I read somewhere (here?) that for the operational side of comms one would need to write an implementation that postcard-rpc will then be able to use. In my case that would be the radio module, for which there is a driver that looks okay. So my question is: Did I understand this correct and if yes did I miss that part in the cool documentation or is there a more
<rafael[m]> generic example maybe? Hobbyist skill level, so I may just have seen but not realized it 😅
<JamesMunns[m]> https://docs.rs/postcard-rpc/latest/postcard_rpc/ has a block diagram, most of what you need to define is how to transit frames by implementing the WireRx/WireTx traits
<JamesMunns[m]> postcard-rpc mostly assumes that the client is a PC, and the server is an MCU.
<rafael[m]> Oh, in my case both sides and maybe later even more are MCU, would that still work? All would need to transmit and receive
<JamesMunns[m]> you might enjoy ergot instead then
<JamesMunns[m]> https://github.com/jamesmunns/ergot/tree/main/demos/rp2040/rp2040-serial-pair shows two rp2040s connected by UART, for example
<rafael[m]> I am looking to have some fun building this thing, so I do not care if I run into some dead ends and skill issues. I looked at ergot but postcard-rpc seemed more hobbyist friendly due to the material around it. Small wonder with ergo being so new. But sure, I can try 🙂 I will have a look and see how much sense I can make out of the example, many thanks! Cool stuff.
<JamesMunns[m]> Yeah, postcard-rpc is more mature, and maybe a little simpler (at a protocol level, there's some gnarly macros that make it less simple), but it's kind of a "local maximum", getting things like MCUs to be clients, or bridging multiple devices, or having interfaces that come or go, etc., all are... not easy to do in postcard-rpc
<JamesMunns[m]> so ergot is a lot of the same "vibes" of postcard-rpc, but the plumbing is changed in a way to make all of those "next steps" actually possible.
<JamesMunns[m]> Feel free to drop by https://matrix.to/#/#mnemos-dev:beeper.com if you have any questions around ergot
<rafael[m]> Reading the example now, I am guaranteed to have questions later 😅
rainingmessages has quit [Quit: bye]
rainingmessages has joined #rust-embedded
phycrax[m] has joined #rust-embedded
<phycrax[m]> does defmt + panicprobe still work with panic_immediate_abort?
ska has joined #rust-embedded
<dirbaio[m]> yes, but you get panic messages only from defmt::panic!, not core::panic!
<dirbaio[m]> core::panic! becomes an instant hardfault
<Ralph[m]> (this is with the embedded_hal::i2c::I2c trait over an embassy_rp impl on RP2040)
<dirbaio[m]> might be a bug
<dirbaio[m]> causing i2c to hang if there's no ack
<Ralph[m]> it seems to be related to the device i'm testing... (this one: https://www.sparkfun.com/sparkfun-qwiic-single-relay.html)
<Ralph[m]> if i test another (that one: https://www.adafruit.com/product/5880) then it works. but only if i haven't tried it with the relay first, otherwise it seems to be dead until i unplug and re-plug the 3.3V supply of the I2C bus (both devices are wired up on the same, with the encoder first and the relay second)
<Ralph[m]> guess i'll just not check for its presence and hope for the best? 🤷
<Ralph[m]> i first thought that it was a timing thing, but even when i gave it 500ms to start up it didn't help (and it anyway should already have started: after all it had power before i flashed the firmware)
TomB[m] has joined #rust-embedded
<TomB[m]> <Ralph[m]> i wanted to add a self-check whether an I2C device is connected and implemented it like this:...
<TomB[m]> s/read/write/, s/i2c_shell/i2c\_shell/
<Ralph[m]> now i took the encoder out of the bus (so i have the relay directly hooked up) and try to check several times in a loop (just to give it a chance) and from what i can see the first time i get an arbitration... (full message at <https://catircservices.org/_irc/v1/media/download/AeEFQ9GpKlWOEdY4h6rpCpH10_NCqxNEz8qqJKBVrdSrtcClveOKYnV8FAkwzCXdX5QTu7Vx2spYKsZcd9pxvta_8AAAAAAAAGNhdGlyY3NlcnZpY2VzLm9yZy9wWnliR3pWUFp5bnlSVGxZTXRuZHBOdG4>)
<TomB[m]> s/read/write/, s/reading/writing/, s/i2c_shell/i2c\_shell/
<JamesMunns[m]> TomB[m]: it's probably the driver not allowing it when it theoretically could
<JamesMunns[m]> TomB[m]: I agree with Tom, "zero length message" is usually used for autodetect, it still confuses some devices tho.
<TomB[m]> maybe, not all drivers support this in zephyr either, and as James Munns noted it can confuse some devices (but in practice it mostly just works, and smbus spec codifies this I believe meaning most devices just work)
<Ralph[m]> i was also used to zero length, was surprised by the check
<Ralph[m]> then i guess this is wrong in `embassy-rp`?
<Ralph[m]> though just removing the check wouldn't work due to `let lastindex = read.len() - 1;` (that'd be `-1`) - it seems that the whole impl relies on having len >= 1, so i'm not sure how this would have to be implemented correctly to allow zero-length reads
<TomB[m]> page 13 in this NXP app note has a comment about this https://www.nxp.com/docs/en/application-note/AN4471.pdf
KevinPFleming[m] has joined #rust-embedded
<KevinPFleming[m]> <Ralph[m]> i tried that:...
<KevinPFleming[m]> the suggestion was to write a zero-length message, not read one :-)
Tidur has joined #rust-embedded
<Ralph[m]> good catch! though it does still end up with pretty much the same error: `InvalidWriteBufferLength`
<Ralph[m]> just removing the check wouldn't help as the function then just wouldn't do anything (i.e. wouldn't start/stop an I2C transaction)
<Ralph[m]> i guess it's time to raise a ticket in embassy about this if we're in agreement that this should be possible?
<Ralph[m]> should only zero-length writes be possible or also zero-length writes?
<Ralph[m]> i briefly checked write_async_internal and it does not have the same check. but i'm pretty sure that it doesn't do anything as it loops over the provided bytes and if there are none it'll end up doing nothing, so that's probably also wrong?
RobWells[m] has joined #rust-embedded
<RobWells[m]> <Ralph[m]> i guess it's time to raise a ticket in embassy about this if we're in agreement that this should be possible?...... (full message at <https://catircservices.org/_irc/v1/media/download/ASG8QJL8iOG4ejueC7esi_HUqtQLpl6bipLFV6JP5HkGOH3Vox46fuijdJ3qjWUE2CVJ_NiR3WSLO7AgSrcO6iC_8AAAAAAAAGNhdGlyY3NlcnZpY2VzLm9yZy9rR1VJRktlUFN5WEFJYnZzRUVDT1BNSU8>)
<Ralph[m]> yes, that was the question (i'm by no means an I2C expert - usually "it just works").
<Ralph[m]> just wanted to make sure that if i raise the issue i write the correct things there. i don't want to ask for zero-length reads if that shouldn't be a thing 🙂
<Ralph[m]> if zero-length writes is all that's needed for an I2C scanner then i'll just ask for that
<Ralph[m]> (since i see Dario reading here - Matrix is a nice surveillance state 😀 - maybe you already have an idea on how to solve this?)
<dirbaio[m]> zero-length transfers should be possible if the hardware allows for it
<dirbaio[m]> maybe they're just not implemented
<dirbaio[m]> removing the check might be enough, not sure.
<Ralph[m]> based on the code (linked above) i don't think that removing the check is enough as it won't interact with I2C at all in that case with the current impl
<dirbaio[m]> right... because setup() doesn't actually trigger the start and wait for the ack
<dirbaio[m]> i'd start by checking the datasheet to see if there's some way to do just that without actually transferring a byte
<dirbaio[m]> then implemen tit
<dirbaio[m]> * then implement it
<dirbaio[m]> (if you want this done the fastest way is for you to send a PR. Embassy is an open source project, there's no one watching issues for feature requests and implementing them)
<Ralph[m]> dirbaio[m]: absolutely, i know! i'm not familiar with the HAL internals and also don't _really_ need this right now, so i'll raise a ticket so that it's "known" and the next one coming around hopefully can use the information present there to know that it "just" needs an implementation.
<Ralph[m]> i might eventually (once i'm done with the things i'm working on) try to fix it, but i'll have to put it off for now as it'd send me off on a tangent - but please nobody wait for that 😅
<Ralph[m]> in case anyone is interested: https://github.com/embassy-rs/embassy/issues/4474
<Ralph[m]> (i wrote a brief test case and attached it there as well)
Tidur has quit [Quit: bye!]
Tidur has joined #rust-embedded
Tidur has quit [Client Quit]
firefrommoonligh has quit [Quit: Idle timeout reached: 172800s]
rainingmessages has quit [Quit: bye]
rainingmessages has joined #rust-embedded
adamgreig_ has quit [Server closed connection]
adamgreig_ has joined #rust-embedded
danielb[m] has quit [Quit: Idle timeout reached: 172800s]
dngrs[m] has quit [Quit: Idle timeout reached: 172800s]
i509vcb[m] has quit [Quit: Idle timeout reached: 172800s]
wose has quit [Server closed connection]
wose has joined #rust-embedded
mathu has quit [Server closed connection]
mathu has joined #rust-embedded
Socke has quit [Ping timeout: 248 seconds]
Socke has joined #rust-embedded
feldrinh[m] has joined #rust-embedded
<feldrinh[m]> I'm looking for a simple concurrency primitive: a type of cell that I can store in a static variable, initialize with a value in the main function and then safely access an immutable reference to the value from anywhere in the program without blocking or locking and with minimal overhead. Any attempt to initialize the cell twice should produce an error.
<feldrinh[m]> Does anybody know a (reasonably well tested) library that implements such a primitive?
M9names[m] has joined #rust-embedded
<M9names[m]> Have you looked at OnceCell in core?
<dirbaio[m]> it's not Sync
<dirbaio[m]> OnceLock does that but it's not no-std
<dirbaio[m]> StaticCell can kinda do that if you pass the `&'static T` to everywhere in the program manually
sypher3[m] has quit [Quit: Idle timeout reached: 172800s]
<feldrinh[m]> <dirbaio[m]> ah embassy-sync has a OnceLock https://docs.rs/embassy-sync/latest/embassy_sync/once_lock/struct.OnceLock.html
<feldrinh[m]> That's pretty much what I had in mind. Though it feels kind of dirty to use a library of async synchronization primitives when writing sync code.
<dirbaio[m]> yeah it'll waste ~2 words of ram (for the waker)
<dirbaio[m]> you can copypaste and remove it
<feldrinh[m]> Does it? I actually checked the source and it doesn't seem to store a waker. It does busy polling in the async methods.
<feldrinh[m]> s/methods/method/
<dirbaio[m]> oh right. there should be no overhead then, if you just ignore the async parts
GuineaWheek[m] has joined #rust-embedded
<GuineaWheek[m]> i’m using device-driver on a chip with a relatively large register space and our builds take like 3 minutes; RUSTFLAGS=“-Ztime-passes” indicates that its spending all that time on coherence_checking; any ideas on why this may be?
<dirbaio[m]> "coherence checking" is the part of the compiler that checks there are no two overlapping impls for the same trait and same type
<dirbaio[m]> device-driver is probably generating code with complex trait bounds or something...
<dirbaio[m]> I don't think there's much you can do as a user, it'd need changing device-driver itself to generate less complex code
<GuineaWheek[m]> I wonder if its read_all_registers/read_all_registers_async
<GuineaWheek[m]> I’d be fine not having those because we’d never use them
<dirbaio[m]> it's checking impls, not methods
<dirbaio[m]> it it generating a lot of impls?
<GuineaWheek[m]> I mean its part of an impl, no?
<GuineaWheek[m]> i’m unsure what you mean
<GuineaWheek[m]> I would really like my compile times to not suck
<GuineaWheek[m]> Maybe it has to do with the usage of RegisterOperation somehow?
<dirbaio[m]> this is what "coherence chekcing" is
<dirbaio[m]> in the example above they obviously don't overlap because they're for different types so I guess the compiler would be able to do it fast, O(n)
<dirbaio[m]> then it's not so obvious anymore and the compiler might become slower
<GuineaWheek[m]> yeah I think it might just be because RegisterOperation is a generic, so there’s some O(n^ouch) combinatorial checks between the generated generic instances going on with the impls?
<dirbaio[m]> like checking each pair: check if impl 1 and 2 overlap, 1 and 3, 1 and 4... then 2 and 3, 2 and 4... then 3 and 4, 3 and 5... which is O(n^2)
<dirbaio[m]> it's just a wild guess but I think it's likely something like this
<GuineaWheek[m]> so I wonder if each register accessor has to check if every other register accessor’s impl overlaps
<GuineaWheek[m]> so compile time is O(registers^2)
<GuineaWheek[m]> not great beyond simple use cases!
<dirbaio[m]> when running into somethign like this the only way out is usually simplifying generics/traits so the compiler is able to do it in O(n) 💀
vancz has quit []