<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]>
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
<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]
<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?
<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>
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
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.