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
<dirbaio[m]> I have a repro on h755 with pwm :D
<dirbaio[m]> out of the box 2.26us
<dirbaio[m]> let's see how much can it be optimized
emerent has quit [Ping timeout: 256 seconds]
emerent has joined #rust-embedded
<dirbaio[m]> embassy-stm32 + interruptexecutor 950ns
<cr1901> JamesMunns[m]: I got postcard UDP to work locally with smol... sort of: https://github.com/orgs/smol-rs/discussions/298
<dirbaio[m]> 890ns :D
<JamesMunns[m]> c1901: neat!
<dirbaio[m]> connect PA6 to PB5, put scope on PA6 and PA5.
<dirbaio[m]> `cd examples/stm32h7; cargo run --release --bin pwm`
<JamesMunns[m]> I still contend that 110ns, or 55 CPU cycles, is not a lot of wiggle room :p
<dirbaio[m]> yeah you can barely make it under your 1us target, and that's only asserting a GPIO
<JamesMunns[m]> (it is very neat that you did it! I would not want to audit that I NEVER have a CS > 55 CPU cycles)
<dirbaio[m]> whatever Rock Boynton needs to do after the input gpio is triggered will probably take more time
<dirbaio[m]> in the embassy channel he mentioned he has to do an spi transfer
<dirbaio[m]> honestly I think it'll be tight even if you use raw interrupts instead of async
<JamesMunns[m]> Does stm32h7 have anything like DMA shortcuts?
<dirbaio[m]> https://matrix.to/#/!YoLPkieCYHGzdjUhOK:matrix.org/$SW-tReOivSuFoDe8J1Jjl5ojp0KiTA6IkECu-v6wQ4A?via=matrix.org&via=tchncs.de&via=grusbv.com
<JamesMunns[m]> like, could he prep a SPI transfer, and have the GPIO interrupt automatically bonk the start?
<dirbaio[m]> i'm very curious to know what that super important u32 is
<dirbaio[m]> and why can't you send it to the FPGA beforehand
cr1901 has quit [Read error: Connection reset by peer]
<dirbaio[m]> or if it changes dynamically, why updating it periodically wouldn't wor
<dirbaio[m]> s/wor/work/
cr1901 has joined #rust-embedded
IlPalazzo-ojiisa has quit [Quit: Leaving.]
<cr1901> https://github.com/ryankurte/embedded-hal-compat/pull/32 So, AFAICT, it is not possible to use ehal1.0 the release w/ the compat layer?
<dirbaio[m]> yeah, it's not done
<cr1901> Very good thanks :)
salsasteve[m] has joined #rust-embedded
<salsasteve[m]> Hey Gang, I have given this a grand attempt and i think i maybe missing something fundamental to making pwm with the Tcc1Pwm. I got the code to compile but nothing is happening. I feel like im referencing everything properly.... (full message at <https://catircservices.org/_matrix/media/v3/download/catircservices.org/cyKQncQuMJSkcIHkWMCplSHy>)
<salsasteve[m]> * Hey Gang, I have given this a grand attempt and i think i maybe missing something fundamental to making pwm with the Tcc1Pwm. I got the code to compile but nothing is happening. I feel like im referencing everything properly.... (full message at <https://catircservices.org/_matrix/media/v3/download/catircservices.org/ObFPMLOEOFantJiCLFlqJLhr>)
<JamesMunns[m]> just checking, if you replace the PWM code with like set_high and set_low as a GPIO, does that work?
<JamesMunns[m]> that's maybe the first step, to make sure your delays and other setup code is working as expected
<salsasteve[m]> JamesMunns[m]: I do have this working in another example in my repo
<salsasteve[m]> salsasteve[m]: code is almost identical just the pwn setup and set_duty added
<JamesMunns[m]> Cool! Then it seems to be down to the PWM. I've not ever used the atsamd crate before, it might be worth opening an issue there? It's always hard to debug chips you aren't familiar with.
<JamesMunns[m]> Do you know you aren't panicking here?
<JamesMunns[m]> `clocks.tcc0_tcc1(&gclk0).unwrap()`?
<salsasteve[m]> s/pwn/pwm/, s/set_duty/set\_duty/
<JamesMunns[m]> if you have two LEDs, it might be worth using one as a GPIO and one as a PWM, so you can make sure it isn't hanging somewhere
<JamesMunns[m]> then you really have narrowed it down to the setup running (tho maybe not being correct), as well as the duty amounts
<salsasteve[m]> <JamesMunns[m]> "Cool! Then it seems to be down..." <- > <@jamesmunns:beeper.com> Cool! Then it seems to be down to the PWM. I've not ever used the atsamd crate before, it might be worth opening an issue there? It's always hard to debug chips you aren't familiar with.... (full message at <https://catircservices.org/_matrix/media/v3/download/catircservices.org/LIEfenppLxynGUCNenCTufuS>)
<JamesMunns[m]> Ah, I'm saying:
<JamesMunns[m]> * if you are panicking here, it will definitely not work (not sure if you are logging or have some other way to check if it is "still alive"
<salsasteve[m]> JamesMunns[m]: lol im pretty its dying here according to the light on my board. I still havent setup a logging. Not really sure how but maybe thats a good direction to go in.
<salsasteve[m]> s/here//, s/light/lights/
<JamesMunns[m]> It's somewhere to start!
<JamesMunns[m]> Adding the defmt and defmt-rtt crates is usually a good start, then you can use probe-rs cli to run and get logs back over the debugging wires
<salsasteve[m]> JamesMunns[m]: this is a great idea thank you for the crates
pbsds has quit [Quit: The Lounge - https://thelounge.chat]
pbsds has joined #rust-embedded
<salsasteve[m]> James Munns: figured it out and it was a user error. I was using with_external_32kosc instead of the correct with_internal_32kosc clock
<JamesMunns[m]> Glad you got it figured out!
<JamesMunns[m]> Pwm all working now?
<RockBoynton[m]> <dirbaio[m]> "whatever Rock Boynton needs to..." <- Masterful work getting that latency down! It's sounding like a SPI transaction completing within the 1us even with DMA might be tough with the embassy executor. As for why it needs to be such short timing, you have reminded me something important in my growth as an engineer is questioning requirements! I'll talk to the RF, EE, and PL engineers on the project and see if I can
<RockBoynton[m]> be convinced this is truly a need or this job can be offloaded to the FPGA.
<RockBoynton[m]> Its a bummer that if I need one or two gpio interrupts this way, then I can't use exti for any of them.
<RockBoynton[m]> * Masterful work getting that latency down! It's sounding like a SPI transaction completing within the 1us even with DMA might be tough with the embassy executor. As for why it needs to be such short timing, you have reminded me something important in my growth as an engineer is questioning requirements! I'll talk to the RF, EE, and PL engineers on the project and see if I can be convinced this is truly a need or this job can
<RockBoynton[m]> be offloaded to the FPGA.
<RockBoynton[m]> Its a bummer that if I need one or two gpio interrupts this way, then I can't use exti for any others
notgull has joined #rust-embedded
notgull has quit [Ping timeout: 256 seconds]
Guest7282 has left #rust-embedded [Error from remote client]
dicklessgreat[m] has joined #rust-embedded
<dicklessgreat[m]> s/know//
<dicklessgreat[m]> s/know//, s/comatibility./compatibility?/
vollbrecht[m] has joined #rust-embedded
<vollbrecht[m]> <dicklessgreat[m]> "Hi guys!..." <- > <@dicklessgreat:matrix.org> Hi guys!... (full message at <https://catircservices.org/_matrix/media/v3/download/catircservices.org/DCsmttQmKIFntLZfWvBBFiaH>)
<vollbrecht[m]> * that depends on what the original creator/maintainer wants to do with it, if your goal is to get the PR accepted. So best to try to ask him directly. ( After you get that sorted you can decided if his answer is working on you or not and proceed)
<vollbrecht[m]> For the transition period it would not be bad to have both versions available, by eitere have them both in tree and have them selected by a feature flag or just fully upgrade it and release a new version. The question is only if the 0.2 version would still receive any non patching releases in the future. If its otherwise "finished" i don't see a big problem in it being a new version replacing the old. As a potential user still
<vollbrecht[m]> can use the older version if he needs to.
<vollbrecht[m]> * that depends on what the original creator/maintainer wants to do with it, if your goal is to get the PR accepted. So best to try to ask him directly. ( After you get that sorted you can decided if his answer is working on you or not and proceed)
<vollbrecht[m]> can use the older version if he needs to.
<vollbrecht[m]> For the transition period it would not be bad to have both versions available, by eitere have them both in tree and have them selected by a feature flag or just fully upgrade it and release a new version. The question is only if the 0.2 version would still receive any non patching releases in the future. If its otherwise "finished" i don't see a big problem in it being a new version replacing the old, as a potential user still
Guest7282 has joined #rust-embedded
<dicklessgreat[m]> <vollbrecht[m]> "> <@dicklessgreat:matrix.org> Hi..." <- > <@vollbrecht:matrix.org> that depends on what the original creator/maintainer wants to do with it, if your goal is to get the PR accepted. So best to try to ask him directly. ( After you get that sorted you can decided if his answer is working on... (full message at <https://catircservices.org/_matrix/media/v3/download/catircservices.org/vrdAErmHnttOagnWLkfJriNQ>)
IlPalazzo-ojiisa has joined #rust-embedded
<M9names[m]> yes. 1.0 was only released a couple of weeks ago.
<M9names[m]> personally I expect HALs will keep supporting both for quite a while to give driver crate authors time to upgrade.
<M9names[m]> for a driver there's not much reason to support both IMO. users can always pick an older version for 0.2 support.
cr1901_ has joined #rust-embedded
cr1901 has quit [Ping timeout: 256 seconds]
<dicklessgreat[m]> Oh, I found this guidance and I should keep in mind during contribution, right?
<dicklessgreat[m]> s/during/for/
<dicklessgreat[m]> * Oh, I found this guidance and I should keep this in mind for contribution, right?
<dicklessgreat[m]> * Oh, I found this guidance and I should keep this in mind for development/contribution, right?
<M9names[m]> right
Alex[m]1 has joined #rust-embedded
<Alex[m]1> Hi, I'm trying to understand SysTick on stm32f103. I've noticed weird slowdowns in my code which seem to be coming from the fugit durations not being what they say they are. Setting Systick TIMER_HZ value to 1000 seems to make my code run correctly (best guess), setting it to 1000000 so I can get microsecond timing, the durations coming back are off by a factor ~6 so my code updates slower than it should (because it waits for systick
<Alex[m]1> to report that a certain period of time passed).
<Alex[m]1> Looking at the reload value being set in SysTick (stm32fxx-hal) I see:... (full message at <https://catircservices.org/_matrix/media/v3/download/catircservices.org/tataQWptqUtfLjrcorAjYvkk>)
<Alex[m]1> I'm sampling the clock ever main loop iteration and I don't have any delays or busy loops, so it should be catching each time SYST_CSR_COUNTFLAG is set and not missing any.
<Alex[m]1> Should I just not expect to be able to do microsecond timing?
<Alex[m]1> Not the biggest deal, but I wanted to be able to profile some sections of code
<Alex[m]1> I actually don't know why sysclk is coming out as 8MHz. Maybe that's something I should look into
<Alex[m]1> Ok, it's just default value
<Alex[m]1> Ok, I think I've got a workable solution by setting sysclk and TIMER_HZ fast together
<Alex[m]1> Still not accurate at all, but will do
<Alex[m]1> Is there a better way to time sections of code at the microsecond level on stm32f103?
<Alex[m]1> Wait, I think I've cracked it. If I'm timing a section of code that takes longer than 1us, I'm going to miss some times the counter wrapped, so it's going to report an incorrect passage of time using the polling method. I'm an idiot
emerent has quit [Ping timeout: 276 seconds]
Foxyloxy_ has quit [Quit: Textual IRC Client: www.textualapp.com]
Foxyloxy has joined #rust-embedded
emerent has joined #rust-embedded
<spinfast[m]> 480 cycles is a lot.. seemingly a small asm routine might actually make sense for that interrupt vector handler?
<spinfast[m]> Like really, how many ops to start a dma transfer… maybe 1 or two register writes?
Matthew_shearer6 has joined #rust-embedded
<Shell> ah, I miss matrix spam
<Shell> making it on to irc
Allie has joined #rust-embedded
cr1901_ is now known as cr1901
Matthew_shearer6 has left #rust-embedded [#rust-embedded]
crabbedhaloablut has quit [Read error: Connection reset by peer]
crabbedhaloablut has joined #rust-embedded
crabbedhaloablut has quit [Read error: Connection reset by peer]
crabbedhaloablut has joined #rust-embedded
notgull has joined #rust-embedded
corecode[m] has quit [Quit: Idle timeout reached: 172800s]
<M9names[m]> <Alex[m]1> "Is there a better way to time..." <- if you want usec accuracy and the interval is not super long, the cortex-m cycle counter register is pretty good for this.
<M9names[m]> have to do the cycle->time calculation after the measurement, but assuming you know how fast the CPU is running that is fine.
notgull has quit [Ping timeout: 264 seconds]
<M9names[m]> https://docs.rs/cortex-m/latest/cortex_m/peripheral/index.html should give you enough info on how to use it
barafael[m] has quit [Quit: Idle timeout reached: 172800s]
vollbrecht[m] has quit [Quit: Bridge terminating on SIGTERM]
whitequark[cis] has quit [Quit: Bridge terminating on SIGTERM]
JomerDev[m] has quit [Quit: Bridge terminating on SIGTERM]
JamesMunns[m] has quit [Quit: Bridge terminating on SIGTERM]
_catircservices has quit [Quit: Bridge terminating on SIGTERM]
Alex[m]1 has quit [Quit: Bridge terminating on SIGTERM]
JackGreenbaum[m] has quit [Quit: Bridge terminating on SIGTERM]
ryan-summers[m] has quit [Quit: Bridge terminating on SIGTERM]
lulf[m] has quit [Quit: Bridge terminating on SIGTERM]
d3zd3z[m] has quit [Quit: Bridge terminating on SIGTERM]
M9names[m] has quit [Quit: Bridge terminating on SIGTERM]
thejpster[m] has quit [Quit: Bridge terminating on SIGTERM]
RockBoynton[m] has quit [Quit: Bridge terminating on SIGTERM]
FreeKill[m] has quit [Quit: Bridge terminating on SIGTERM]
RobertJrdens[m] has quit [Quit: Bridge terminating on SIGTERM]
adamgreig[m] has quit [Quit: Bridge terminating on SIGTERM]
firefrommoonligh has quit [Quit: Bridge terminating on SIGTERM]
dicklessgreat[m] has quit [Quit: Bridge terminating on SIGTERM]
dirbaio[m] has quit [Quit: Bridge terminating on SIGTERM]
spinfast[m] has quit [Quit: Bridge terminating on SIGTERM]
dkhayes117[m] has quit [Quit: Bridge terminating on SIGTERM]
salsasteve[m] has quit [Quit: Bridge terminating on SIGTERM]
eldruin[m] has quit [Quit: Bridge terminating on SIGTERM]
_catircservices has joined #rust-embedded
_catircservices has quit [Quit: Bridge terminating on SIGTERM]
_catircservices has joined #rust-embedded
_catircservices has quit [Quit: Bridge terminating on SIGTERM]
_catircservices has joined #rust-embedded
notgull has joined #rust-embedded
salsasteve[m] has joined #rust-embedded
<salsasteve[m]> <jamesmunns> "Pwm all working now?" <- it was just one pwm. its working pretty smooth now