-
-
Notifications
You must be signed in to change notification settings - Fork 2.9k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Add support for CLKIN on modern gyros to improve flight performance. #13502
Comments
Any timer with connection to output to pin should do. IMO it is better to rty to use least-useful timer (TIM12, TIM13, TIM14, TIM15, TIM16, TIM17) or even (currently unused?) LPTIMx Another possibility is USART (smartcard mode clock), SPI (I2S MCK, but I did not check that 32k is possible).
Great for testing, but IMO almost useless otherwise. ODR is guarantied, you can synchronize data to clock, using status register if necessary.
Good for testing. But sharing clock for both gyros (possibly with one clock inverted) should be enough.
Actually, it would be useful to implement general software PLL that can sync to peripheral without INT. But for gyro, direct sync is very reasonable.
Maybe as last resort, but there are so many better options.
Actually, I could use one ;-) But there are other, more interesting things possibly with H7 |
My thought there was that the advanced control timers and gyro clock generation is new and more of an unknown at this point, so using a more capable timer is probably a good idea until more code is written, additionally the peripheral interconnect of TIM1 and TIM8 is better.
I was thinking of being able to stagger gyro readings from different gyros to effectively double the data throughput or to balance load. |
@hydra : Part of my thinking is from Cleanflight F103 days - every timer was precious ;-) SPRACING is probably only available hardware, so used pins are kind of fixed now. Eventually, less valuable pins may be supported . Stagger is interesting idea. But readout is less than 16kHz, so even shared clock shall be ok. But changing clock phase may have influence on noise (IMO each gyro element will still resonate on it's mechanical frequency. External clock will probably influence digital part only) |
@hydra @ledvinap , I confirmed that using CLKIN will not change the gyro element resonate frequency (primary stage). Resonate frequency are different for all axis. CLKIN is used for Accel and Gyro sencondary stage only: ADC conversion, filtering, etc.... |
Yes, as-per the datasheet list of improvements. To me, inverting the /system/ dependency is the biggest win, i.e. the system/scheduler controls the gyro instead of reacting to it. Currently the gyro drivers and scheduler has code dealing with timing gyro EXTIs and handling scheduler skew which could be bypassed/removed/improved if the system generated the gyro clock. |
@hydra : The code will stay in for other targets. And with RTOS, you can simply preempt on EXTI, no prediction of EXTI would be necessary. |
Is your feature request related to a problem? Please describe
Gyros like the ICM-42688-P have a CLKIN signal which allows the FC to generate the clock signal.
TDK's datasheet for the ICM-42688-P says:
https://invensense.tdk.com/download-pdf/icm-42688-p-datasheet/
Describe the solution you'd like
The CLKIN signal can be generated from a timer, STM's advanced control timers are better suited to this, e.g. TIM1/TIM8. TIM8 makes a great candidate on the H723/H730/H743/750.
Additionally, if the INT signal is also connected to another channel on the same advanced control timer, then it's possible to easily verify and monitor the gyro INT signal timing in relation to the clock signal.
For dual-gyro boards it's also possible to use all 4 channels of TIM8, 2 per gyro.
The SPRacingH7EF for example, is configured as follows:
MCU:
GYROS:
Describe alternatives you've considered
Not using CLKIN and having the system work from INT timings and guessing the gyro clock.
It's also possible to use a timer, + dma stream + gpio BSRR or ODR registers to generate a clock signal on an arbitrary GPIO pin, but this isn't as efficient as using a timer.
Other information
I have hardware available for testing if needed if anyone wants to work on this.
The text was updated successfully, but these errors were encountered: