06:03 <re_irc> <TimSmall> wembly: I dunno about the atsamd board you are using, but on stm32f411 (using "stm32f4xx-hal")... The "smartleds" driver uses the (MOSI pin of) an SPI peripheral to output its signal, and the HAL layer assumes that SPI clock rates aren't critical (because SPI usually has an external clock signal, so the peripheral can handle quite a wide range of clock rates), and so just sets the SPI peripheral with a loosely matching...

06:03 <re_irc> ... clock rate to the one which was asked for. This makes the neopixels sad because they have reasonably tight timing requirements.

06:03 <re_irc> <TimSmall> ... so maybe put a scope or a frequency meter on the SPI clock pin (or just add some debug code in to print out the actual clock rate which was configured).

11:34 <re_irc> <James Munns> This might be useful to other folks, but here's a snippet of code I use to measure idle CPU time. It's specifically for MnemOS, but it honestly should work in just about any application. Credit to dirbaio for suggesting the technique :)

11:34 <re_irc> https://gist.github.com/jamesmunns/3a8abd81185a98be8757df6bbee34e15

11:34 <re_irc> <James Munns> It _will_ increase the latency of serving an interrupt from the idle state (but not much, probably a dozen or two clock cycles), so make sure it fits in your timing budget :)

11:38 <re_irc> <James Munns> Specifically this is in RTIC already

11:39 <re_irc> <James Munns> There might be a clever-er way to handle this without an actual hwtimer, maybe just using systick? But then for RTIC it would have to be a "native" feature.

11:49 <re_irc> <James Munns> Also, if there is some cursed edge case you see that I don't handle, please let me know, this isn't super battle tested code, I wrote it last night :p

11:49 <re_irc> <James Munns> (but seems to work pretty well!)

12:05 <re_irc> <robtsuk> wembly: Does the unmodified neopixel sample work?

12:07 <re_irc> <robtsuk> oh, also, make sure you are running a release build, I have this vague recollection the neopixel samples are very sensitive to execution speed and don't work reliably in debug builds

15:08 <re_irc> <wembly> robtsuk: yes, that works fine, i've narrowed it down to something i'm doing with getting the peripherals

15:11 <re_irc> <wembly> if get the peripherals in "main" and pass everything to my init function it works fine, if i get the peripherals in the init function it seems to be unhappy

15:13 <re_irc> <wembly> i also moved the code to use TC's and not the deprecated SpinTimer, so i'm hoping that makes things a bit less sensitive to the type of build (release/debug)

15:32 <re_irc> <wembly> ....... actually i think the release/debug build might be the problem i'm running into, thank you robtsuk

17:37 <re_irc> <James Munns> (in general, non-release builds in rust, both embedded and not, are MUCH slower than release builds. often more than a difference of 10X or so)

17:51 <re_irc> <wembly> good to know

17:51 <re_irc> <wembly> i wasn't aware of that