2024-09-12 12:00 AM
Hi all
I am working on a time based velocity estimate from an incremental encoder. Currently its set up so that one timer is running in encoder mode, which works perfectly, the timer counts up and down fine through the full resolution of the encoder. I wanted this timer to generate a trigger event upon every timer counter change, which could trigger another free running timer to latch its value upon the trigger, generating a timestamp for that encoder event. This timer then generates two dma requests that move both the encoder value and the timestamp into variables in the code that can then be used for the velocity estimate. To generate these triggers the only way i have found is to set the trigger event selection for the encoder timer to Compare Pulse (OC1), this works to some extent. Triggers are generated and values are being latched, but its only every 4' encoder count that generates a trigger, this effectively removes 3/4 of the encoder resolution which is not optimal. In the reference manual its stated that the Compare Pulse (OC1) event triggers every time the CC1IF flag is raised, which to my knowledge should happen every time a value is captured in the CCR1 register.
From what i can gather in the reference manual there also exist the TI1F_ED trigger, which looks like it should generate triggers both on falling and rising edges from the signal. I can setup the trigger source on my timestamping timer to TI1_ED, however this still only latches every 4 counter value change on the encoder timer.
Is there a way i have overlooked, that can generate triggers on every counter change, or on all both rising and falling edges from the encoder signal? or is there maybe a workaround that can achieve the same behavior? Its not an option to utilize interrupts, since the cpu would be overloaded by these at higher speeds, where the encoder value is changing rapidly.
Looking forward to some input.
Solved! Go to Solution.
2024-09-12 01:17 AM
Which STM32?
You seem to use Cube/HAL terminology, which does not quite match the Reference Manual. It would be better to describe the problem and step you are taking in terms of registers fields content, so that we are on common ground.
In the "traditional" STM32 TIM, once set to Encoder mode, there is no way to get both edges of one (not to mention both (or the resulting count signal fed to counter in 4x mode)) channel's to output as TRGO.
Probably the only solution to this problem, at the cost of external pin(s), but then quite simple, is to connect the encoder signals externally to both the "encoder" and the "timestamping" timer (in the latter then use it for both-edge capture).
JW
2024-09-12 01:17 AM
Which STM32?
You seem to use Cube/HAL terminology, which does not quite match the Reference Manual. It would be better to describe the problem and step you are taking in terms of registers fields content, so that we are on common ground.
In the "traditional" STM32 TIM, once set to Encoder mode, there is no way to get both edges of one (not to mention both (or the resulting count signal fed to counter in 4x mode)) channel's to output as TRGO.
Probably the only solution to this problem, at the cost of external pin(s), but then quite simple, is to connect the encoder signals externally to both the "encoder" and the "timestamping" timer (in the latter then use it for both-edge capture).
JW
2024-09-12 01:28 AM
Hi waclawek
Its an Nucleo-F429ZI.
I am primarily using Cube/Hal terminology, most of the setup is done in cube using the UI. I also came to the conclusion that it was not possible to get TRGO's for all edges.
We are not limited on external pins, so this seems like a good solution. We will look into this approach further thank you!.
2024-09-12 02:28 AM
Hi Waclawek
We got it working with the extra external wires, once again thank you!