<re_irc>
<@shakencodes:matrix.org> I am using the eeprom24x library and have found that the read_byte() function sometimes does not return. Is this a known behavior?
<re_irc>
Usually this happens after the immediately preceding read_byte() call returned an error. And I suspect there is a hardware problem with the EEPROM or its connection.
<re_irc>
While I have two actions already planned (stop reading after an error; replace the EEPROM and connector on the dev-board setup), I still believe that it is bad behavior for the function to just go away and not come back. (My system watchdog is 10 seconds, so it has plenty of opportunity to timeout.)
<re_irc>
<@shakencodes:matrix.org> I am using the eeprom24x library and have found that the read_byte() function sometimes does not return. Is this a known behavior? Usually this happens after the immediately preceding read_byte() call returned an error. And I suspect there is a hardware problem with the EEPROM or its connection. While I have two actions already planned (stop reading after an error; replace the EEPROM and connector on the dev-board...
<re_irc>
... setup), I still believe that it is bad behavior for the function to just go away and not come back. (My system watchdog is 10 seconds, so it has plenty of opportunity to timeout.) P.S. Thank you for the library. It has been a great deal of help.
<re_irc>
<@jamesmunns:beeper.com> Is that using I2C under the hood?
<re_irc>
<@jamesmunns:beeper.com> It _probably_ means the HAL you are using's I2C methods don't properly handle some error states, including timeout
<re_irc>
<@shakencodes:matrix.org> Yes. And I've just determined that, when it fails, the preceding read had an I2C(Nack) error.
<re_irc>
<@jamesmunns:beeper.com> Which chip/hal?
<re_irc>
<@shakencodes:matrix.org> I'm on the embassy_hal on STM32WL55.
<re_irc>
<@jamesmunns:beeper.com> Interesting! Are you using it in async or blocking mode?
<re_irc>
<@shakencodes:matrix.org> I'm trying to figure out how to confirm, but I'm pretty sure this is blocking. (It is acting like blocking, there is no await, and I can see from the types that DMA is not being used.)
<re_irc>
<@jamesmunns:beeper.com> Then very likely blocking! At least in async, you could use embassy-time's timeout handler, to cancel the read future after a certain amount of time to prevent deadlock. But, the eeprom24x crate may not offer an async API.
<re_irc>
<@jamesmunns:beeper.com> Either way, I would report it to the embassy hal repo! I've seen some bugs like that in other STM32 hals (not from embassy), and there can sometimes be weird edge cases or errata when you get error conditions
<re_irc>
<@shakencodes:matrix.org> Thank you! The fact that it errors on one call and then locks up on the next fits that the i2c bus is somehow not well.
<re_irc>
<@jamesmunns:beeper.com> Yeah, in the past I've seen exactly that: if you don't clear a specific error flag, the next read will never complete, and the whole i2c driver locks up.
<re_irc>
<@jamesmunns:beeper.com> Yeah, I saw that on HN! Happy to see they are making progress. Seeing them finding issues in sudo while working on the rewrite was interesting too :D
<re_irc>
For me, the mention in the article reminded me of the two positive engagements my teams have had with Ferrous. Hopefully not getting too commercial here... but, as I said, it made me smile.
<re_irc>
<@shakencodes:matrix.org> I missed the sudo issue discussion! Sounds interesting.
starblue2 has joined #rust-embedded
<re_irc>
<@firefrommoonlight:matrix.org> Shoutout to Ferris. Probe-run and defmt are great examples of "just works" for something important
<re_irc>
<@firefrommoonlight:matrix.org> Outstanding tools that make the Rust embedded experience smoother than any on C (or OpenOCD etc in Rust)
starblue1 has quit [Ping timeout: 240 seconds]
HumanGeek has quit [*.net *.split]
vancz has quit [*.net *.split]
jr-oss has quit [*.net *.split]
HumanGeek has joined #rust-embedded
jr-oss has joined #rust-embedded
vancz has joined #rust-embedded
HumanGeek has quit [Max SendQ exceeded]
HumanGeek has joined #rust-embedded
<re_irc>
<@Ablu:matrix.org> Can I somehow set the EABI version (-meabi) for Rust targets? I get: arm-poky-linux-gnueabi-ld: error: source object /opt/arm-sdk/tmp/sysroots/qemuarm/usr/lib/libm.so has EABI version 5, but target /home/ablu/projects/libgpiod/bindings/rust/target/armv7-unknown-linux-gnueabihf/debug/examples/find_line_by_name-6fd5fc28935e8c2f has EABI version 0
<re_irc>
when trying to link from my Yocto toolchain into my Rust binary.
<re_irc>
<@Ablu:matrix.org> Probably I would need some Rust alternative for "-mthumb -mfpu=neon -mfloat-abi=hard -mcpu=cortex-a15"?
<re_irc>
<@Ablu:matrix.org> Well, the hard-float part should hopefully come from the "armv7-unknown-linux-gnueabihf", but setting "-C target-cpu=cortex-a15" does not have any impact.
<re_irc>
<@9names:matrix.org> how about you build a basic rust binary with your settings first, and check the EABI it's producing? I suspect that error is indicating something else is broken.
<re_irc>
<@9names:matrix.org> alternatively: yocto has support for building a rust toolchain, and for building rust projects as part of your image.
<re_irc>
if you're not already using the toolchain it built, maybe you should be doing that...
<re_irc>
<@Ablu:matrix.org> : This is just building an example. Attempting to build a minimal example yields the same errors when linking libc and loader. "file" on the target file says "EABI5 version 1" for both files though... that seems interesting...
<re_irc>
<@Ablu:matrix.org> : Yeah, I could probably build a Rust toolchain from Yocto, but that would require everyone to do their own clang compilations, which I would like to avoid. But it may help to spy at what Rust is doing different...
<re_irc>
<@Ablu:matrix.org> Ah. I switched from ld -> gcc for linking and manually added all the flags from $CC and that worked :). I _thought_ I tried something along that yesterday... But maybe I just took the $LDFLAGS...
<re_irc>
<@jerricko:linuiz.org> What is this?
_whitelogger has joined #rust-embedded
starblue2 has quit [Ping timeout: 252 seconds]
starblue2 has joined #rust-embedded
IlPalazzo-ojiisa has joined #rust-embedded
hifi has quit [Server closed connection]
hifi has joined #rust-embedded
dc740 has joined #rust-embedded
Foxyloxy has joined #rust-embedded
Foxyloxy_ has quit [Read error: Connection reset by peer]
Foxyloxy has quit [Read error: Connection reset by peer]
dc740 has quit [Remote host closed the connection]
dc740 has joined #rust-embedded
Socker has joined #rust-embedded
dc740 has quit [Remote host closed the connection]
dc740 has joined #rust-embedded
<re_irc>
<@romancardenas:matrix.org> emul
emerent has quit [Ping timeout: 246 seconds]
emerent has joined #rust-embedded
<re_irc>
<@romancardenas:matrix.org> I have a question for the RISC-V/ESP32 folks: how do you feel about a new feature in "riscv-rt" to enable atomic emulation for any RISC-V target that would need it? does it make sense?
<re_irc>
<@jamesmunns:beeper.com> Does having it in the riscv-rt crate help any better than having it as a dependency directly? Other than discoverability?
<re_irc>
<@jamesmunns:beeper.com> (or do you mean automatically installing the emulation trap handler in the rt crate?)
<re_irc>
<@romancardenas:matrix.org> I was thinking about making "riscv-atomic-emulation-trap" an optional dependency in "riscv-rt" and a feature gate that overrides the default trapping behavior when active to emulate atomic operations
<re_irc>
<@romancardenas:matrix.org> So end users do not need to worry about adding an extra dependency and overriding the exception handler
<re_irc>
<@jamesmunns:beeper.com> Interesting!
<re_irc>
<@jamesmunns:beeper.com> It's a _little_ cursed, but probably useful :D
<re_irc>
<@onsdag:matrix.org> You could probably hook the default exception handler at linking stage
<re_irc>
<@onsdag:matrix.org> That way you’d avoid shipping it with the runtime
<re_irc>
<@onsdag:matrix.org> If you know what I mean
<re_irc>
<@onsdag:matrix.org> Also, I’ve ran into some issues with that crate since it doesn’t take into account compressed (16-bit) instructions, so it sometimes panics about misaligned access. I haven’t been able to recreate it, but it felt logical at the time
<re_irc>
<@onsdag:matrix.org> * access when reading 32-bit atomic instructions aligned to 16-bits.
<re_irc>
<@onsdag:matrix.org> So you’d have a PROVIDE(DefaultExceptionHandler = some_handler) where some handler checks if emulation is needed and runs it
<re_irc>
<@onsdag:matrix.org> * some_handler
<re_irc>
<@onsdag:matrix.org> : I thought it was a pretty cool way to solve the problem when I first stumbled on it
<re_irc>
<@onsdag:matrix.org> Or I guess you can just provide an ExceptionHandler without touching the linker scripts since the default should be weak?
<re_irc>
<@onsdag:matrix.org> * define
<re_irc>
<@onsdag:matrix.org> Ah that’s what you said… 😅
<re_irc>
<@onsdag:matrix.org> Either way, I think it’s better to leave it like this
<re_irc>
<@romancardenas:matrix.org> I was thinking about your second approach, yes... I'll probably develop a proof of concept and get back to you :D
<re_irc>
<@romancardenas:matrix.org> : You mean leave it as it is now?
<re_irc>
<@onsdag:matrix.org> : Yeah, and maybe have a library providing an exception handler which “wraps” the riscv-atomic-emulation crate
<re_irc>
<@onsdag:matrix.org> For folks that don’t care about exception handling except the atomic emulation bit
<re_irc>
<@romancardenas:matrix.org> : Ok, like instead of depending on the emulation crate you depend on this new one right?
<re_irc>
<@onsdag:matrix.org> : Yes, or better yet, it could be a part of the emulation crate (behind a feature)
<re_irc>
<@romancardenas:matrix.org> : And the emulation trait would optionally depend on riscv-rt? So you can either youse riscv-rt or the emulation trait with the feature active
<re_irc>
<@onsdag:matrix.org> : It doesn’t necessarily have to depend on riscv-rt, it would probably still build if there is no valid runtime crate, the exception handler would just remain unused which I think is sensible behaviour.
<re_irc>
<@onsdag:matrix.org> The ESP’s use esp-riscv-rt which is very similar to riscv-rt and could also potentially benefit from having a handler like this
<re_irc>
<@onsdag:matrix.org> The crates are incompatible with each other so if you pull in riscv-rt for this feature, I can’t use esp-riscv-rt somewhere down the line is my point
<re_irc>
<@romancardenas:matrix.org> : I see. I like your idea about the feature in the emulator, I'll try that 😃