02:51 <re_irc> <ignormies> hey guys, I'm still having some issues with timing for SPI writes, even using the faster "blocking::spi::Write".

02:51 <re_irc> Here are two screenshots of my signal, one built with "--release" and one without. The one with "--release" is obviously better, but still broken.

02:51 <re_irc> And here is a gist (https://gist.github.com/BryceBeagle/8904eab9aef4d3418680479f478f5516) with a minimal reproduction of the issue

02:51 <re_irc> Does anyone know where to begin diagnosing?

02:51 <re_irc> <ignormies> https://psion.agg.io/_matrix/media/r0/download/matrix.org/fMaMTUZnWQxlzHbOegKLJiiM/image.png

02:52 <re_irc> <ignormies> https://psion.agg.io/_matrix/media/r0/download/matrix.org/zZmKogzYhAmEmCFfJIUiRpKC/image.png

02:52 <re_irc> <ignormies> hey guys, I'm still having some issues with timing for SPI writes, even using the faster "blocking::spi::Write".

02:52 <re_irc> Here are two screenshots of my signal, one built with "--release" and one without. The one with "--release" is obviously better, but still broken.

02:52 <re_irc> And here is a gist (https://gist.github.com/BryceBeagle/8904eab9aef4d3418680479f478f5516) with a minimal reproduction of the issue

02:52 <re_irc> Does anyone know where to begin diagnosing? I am using an "stm32f103" bluepill

02:53 <re_irc> <GrantM11235> Is that the clock signal or the data signal?

02:54 <re_irc> <ignormies> That is the data signal, but I am sending "&[0b10101010, 0b10101010]" as a way of diagnosing timing

02:54 <re_irc> <ignormies> * timing, so it looks kinda like a clock signal

02:57 <re_irc> <ignormies> hey guys, I'm still having some issues with timing for SPI writes, even using the faster "blocking::spi::Write".

02:57 <re_irc> Here are two screenshots of my signal, one built with "--release" and one without. The one with "--release" is obviously better, but still broken, with a huge gap between words.

02:57 <re_irc> And here is a gist (https://gist.github.com/BryceBeagle/8904eab9aef4d3418680479f478f5516) with a minimal reproduction of the issue

02:57 <re_irc> Does anyone know where to begin diagnosing? I am using an "stm32f103" bluepill

02:57 <re_irc> <GrantM11235> Is it connected to a regular spi device, or is it neopixels or somthing?

02:57 <re_irc> <ignormies> neopixels

03:09 <re_irc> <GrantM11235> I guess you will need to use dma. Here is an example https://github.com/stm32-rs/stm32f1xx-hal/blob/master/examples/spi-dma.rs

03:13 <re_irc> <GrantM11235> The stm32f1 spi doesn't have a FIFO buffer, so the HAL has to wait for the first byte to finish before it can configure the next byte to be sent

03:15 <re_irc> <ignormies> oh interesting. I guess that makes sense. Maybe I should use the stm32f401 blackpill I have lying around instead -- does that have a buffer?

03:15 <re_irc> Why does "--release" chop out so many instructions here tho?

03:15 <re_irc> <GrantM11235> Are you running the cpu at the full 72mhz?

03:17 <re_irc> <ignormies> let clocks = rcc.cfgr

03:17 <re_irc> // https://stm32-base.org/boards/STM32F103C8T6-Blue-Pill.html

03:17 <re_irc> ... long message truncated: https://psion.agg.io/_matrix/media/r0/download/psion.agg.io/a09004fa55892259a7aeb56c8409f5caf0f7e0583ce4296ff402c8ff09f6dc19 (9 lines)

03:17 <re_irc> .use_hse(8.MHz())

03:17 <re_irc> // https://electronics.stackexchange.com/questions/134684/why-use-stm32-hse

03:17 <re_irc> <ignormies> (at least that was the conclusion I came to, but I'm still not 100% understanding of the clocks)

03:18 <re_irc> <ignormies> let clocks = rcc.cfgr

03:18 <re_irc> // https://stm32-base.org/boards/STM32F103C8T6-Blue-Pill.html

03:18 <re_irc> // https://electronics.stackexchange.com/questions/134684/why-use-stm32-hse

03:18 <re_irc> ... long message truncated: https://psion.agg.io/_matrix/media/r0/download/psion.agg.io/8a31fc397d263261237266ae8000455be34409a7268047366cdc4205e6f357a0 (9 lines)

03:18 <re_irc> .use_hse(8.MHz())

03:20 <re_irc> <GrantM11235> The reason that "--release" helps is that it enables optimizations which allows the cpu to send the next byte faster once it sees that the last byte was sent

03:25 <re_irc> <GrantM11235> I'm a bit surprised that the cpu can't react in time though

03:31 <re_irc> <GrantM11235> I mis-remembered the datasheet. The stm32f1 _does_ have a single word buffer

03:31 <re_irc> <GrantM11235> So there should be plenty of time to keep the spi fed without any gaps

03:32 <re_irc> <ignormies> yeah, according to the reference manual, the TXE flag is set at the _start_ of the transmission for the previous word, not the end

03:32 <re_irc> <ignormies> https://psion.agg.io/_matrix/media/r0/download/matrix.org/IrBGrmotMiqHxDCmOplgeTIy/image.png

03:33 <re_irc> <GrantM11235> ignormies: Are you sending that with a single "write" call?

03:34 <re_irc> <ignormies> here's a gist of what I'm doing:

03:34 <re_irc> https://gist.github.com/BryceBeagle/8904eab9aef4d3418680479f478f5516

03:35 <re_irc> <ignormies> but yeah, single call

03:37 <re_irc> <GrantM11235> Are you using full LTO?

03:38 <re_irc> <ignormies> uhhh, not sure. whatever is default

03:39 <re_irc> <GrantM11235> The default for "--release" is "thin" lto. I'm not sure if it would make a difference though

03:43 <re_irc> <GrantM11235> You can try adding this to your cargo toml

03:43 <re_irc> [profile.release]

03:43 <re_irc> lto = 'fat'

03:48 <re_irc> <ignormies> https://psion.agg.io/_matrix/media/r0/download/matrix.org/lHqhyOXOHJrqmedYzxDjsnfg/image.png

03:48 <re_irc> <ignormies> 🎉

04:13 <re_irc> <ignormies> Thanks so much for the help GrantM11235 ! After some tinkering it looks like using "opt-level" >=2 _and_ "lto = 'fat'" is necessary for me to drive the SPI at the speed I need on this chip

04:17 <re_irc> <GrantM11235> I'm surprised that "lto = 'fat'" makes such a difference. Maybe someone needs to add some "#[inline]" tags somewhere

04:18 <re_irc> <GrantM11235> But for embedded there is really no reason not to use "lto = 'fat'" all the time

04:32 <re_irc> <GrantM11235> Hmm, I'm not seeing any difference at all between fat and thin lto

04:51 <re_irc> <ignormies> GrantM11235: actually, are you sure "thin" is the default? Looks like "thin" works just as well as "fat" for me. this (https://doc.rust-lang.org/cargo/reference/profiles.html#release) has "lto" defaulting to "false" for the "release" profile

04:53 <re_irc> <GrantM11235> Oh, I was accidentally reading the docs for rustc instead of cargo https://doc.rust-lang.org/rustc/codegen-options/index.html#lto

05:15 <re_irc> <GrantM11235> With lto off, I am seeing non-inlined calls to stuff like "stm32f1::stm32f103::spi1::sr::TXE_R::new"

05:17 <re_irc> <Trevor Gross> Hey all, is there any official work toward a HAL for xilinx parts (Zynq specifically), or any guidelines for work with FPGA/Cortex combo parts? https://git.m-labs.hk/m-labs/zynq-rs exists and actually has a lot of work, but I'm wondering why it's not under the embedded wg's umbrella

05:17 <re_irc> <Trevor Gross> https://github.com/xilinx-rs is available if something official is within scope :)

05:20 <re_irc> <GrantM11235> I don't think there are any HALs that are officially part of the wg

05:21 <re_irc> <Trevor Gross> I think I just realized that - the documentation for https://github.com/atsamd-rs/atsamd is so complete that it seems very official

05:34 <re_irc> <Trevor Gross> Is there any reason HALs aren't under the workgroup, other than just adding more things to maintain?

05:39 <re_irc> <GrantM11235> It looks like this will be fixed in the next version of stm32f1xx_hal

05:41 <re_irc> <GrantM11235> Trevor Gross: The HALs aren't really developed by the working group, they are developed by individual devs who may or may not be in the wg

05:46 <re_irc> <GrantM11235> HALs are naturally very opinionated, and it is better to avoid having an "official opinion" (in my unoffical opinion 😁)

08:28 <re_irc> <alex (@alex:matrix.sempto.net)> 9names: Sorry, saw that a bit late. Basically I require something to read electric meters using serial, then read some water sensors and also do some pulse counting to read a water meter

08:29 <re_irc> <alex (@alex:matrix.sempto.net)> So I have built a board with 8 RJ12 connectors and a pi pico

08:30 <re_irc> <alex (@alex:matrix.sempto.net)> Oh and a RS485 interface to report the results back to the server

08:31 <re_irc> <alex (@alex:matrix.sempto.net)> So basically I need to be able to switch those connectors either to UART mode, pulse counting mode or GPIO (high/low) detection.

08:32 <re_irc> <alex (@alex:matrix.sempto.net)> Not sure if I'll manage to do it in rust though. It feels like I'm trying to fly without learning to walk first.

09:32 <re_irc> <9names (@9names:matrix.org)> that certainly is a lot for just getting started! nice practical problem though, and each of the parts shouldn't be insurmountable, I think it's not a bad first project.

09:48 <re_irc> <alex (@alex:matrix.sempto.net)> 9names: Well, not the first rust microcontroller project, just the first one on the pico.

09:48 <re_irc> The first one was a lot more imperative and C like.

09:50 <re_irc> <alex (@alex:matrix.sempto.net)> So I guess I either need to learn how to use the type system or switch back to the simpler less elegant style

09:50 <re_irc> <alex (@alex:matrix.sempto.net)> hardcode more stuff, like connector 1 is always UART, etc

10:49 <re_irc> <jannic> Seems like https://github.com/rust-embedded/riscv-rt/issues/102 is needed for "riscv-rt" to work on current nightly.

10:50 <re_irc> <jannic> * https://github.com/rust-embedded/riscv-rt/pull/103

10:51 <re_irc> <jannic> In the past, the lines read "KEEP(*(.trap))", the "KEEP" was removed but the parentheses stayed. With a recent nightly update lld became more picky and now rejects the lines.

16:33 <re_irc> <almindor> jannic: Nice fix, thanks! could you just please add a CHANGELOG entry as well?