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 joined #rust-embedded
cr1901 has quit [Killed (NickServ (GHOST command used by cr1901_!~cr1901@2601:8d:8600:911:56b:2539:c72c:cf8c))]
cr1901_ is now known as cr1901
starblue has quit [Ping timeout: 252 seconds]
starblue has joined #rust-embedded
GenTooMan has quit [Ping timeout: 244 seconds]
GenTooMan has joined #rust-embedded
crabbedhaloablut has quit [Remote host closed the connection]
emerent has quit [Ping timeout: 260 seconds]
crabbedhaloablut has joined #rust-embedded
emerent has joined #rust-embedded
explore has joined #rust-embedded
<re_irc> <ignormies> Back again with another weird SPI issue. If I try to ".write" more than 13 bytes (exactly) in a single call/packet, the SCK signal stops working properly.
<re_irc> First image shows a normal, working signal, with a packet of 13 bytes of "0b10101010" (alternating 1s and 0s) and the second image shows what happens if I add just a single more byte. (top graph is MOSI, bottom is SCK). SCK hiccups every (exactly) 24 periods, preventing the data getting sent.
<re_irc> This issue goes away if I use "opt-level = 3", but with anything less this is present. Anyone know what's up with this? How can I investigate the true cause of this? GrantM11235 mentioned above that some non-inlined code was fixed here in the next version of "stm32f1xx_hal" but I tried using the git master version of the crate and the issue persisted (unless I crank optimizations all the way up).
<re_irc> loop {
<re_irc> <ignormies> Actually, this occurs with "opt-level = 3" with more than exactly 28 bytes in the packet, so there's more to this going on
<re_irc> <ignormies> +even
explore has quit [Quit: Connection closed for inactivity]
causal has quit [Quit: WeeChat 3.6]
<re_irc> <almindor> ignormies: I had something similar happen if I misconfigured my MISO line (I didn't even use it in most cases but I did have the pin used in the SPI)
m5zs7k has quit [Ping timeout: 252 seconds]
m5zs7k has joined #rust-embedded
vancz has quit []
vancz has joined #rust-embedded
starblue has quit [Ping timeout: 252 seconds]
starblue has joined #rust-embedded
dc740 has joined #rust-embedded
<re_irc> <ignormies> almindor: Can you elaborate what you mean by "misconfigured"? I'm currently using "NoMiso".
GenTooMan has quit [Ping timeout: 244 seconds]
GenTooMan has joined #rust-embedded
<re_irc> <newam> ignormies: I had a similar issue in the stm32wlxx-hal. Still need to track it down. I think it is a compiler bug, older compiler versions don't show it.
<re_irc> <newam> ignormies: do you have a GitHub issue for this? I want to subscribe if there is 🙂
<re_irc> Now that I know it's not just a me issue I should dig into the codegen and find out what is going on.
GenTooMan has quit [Ping timeout: 244 seconds]
GenTooMan has joined #rust-embedded
GenTooMan has quit [Excess Flood]
GenTooMan has joined #rust-embedded
<re_irc> <ignormies> newam: I can definitely open one this evening 👍. Should it just be on the HAL repo?
<re_irc> <newam> Yeah, that makes the most sense for now I think.
GenTooMan has quit [Ping timeout: 244 seconds]
GenTooMan has joined #rust-embedded
GenTooMan has quit [Ping timeout: 248 seconds]
<re_irc> <almindor> ignormies: I had the actual physical pin connected to the device (I didn't use it to read anything tho), but I didn't configure the PIN on the MCU (I just left it out and use a SCK, MOSI, CS combo). This seems to have caused some issues IIRC, but it was some time ago I might've misremembered
GenTooMan has joined #rust-embedded
causal has joined #rust-embedded
causal has quit [Client Quit]