-
Notifications
You must be signed in to change notification settings - Fork 112
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
fix(stm32h7): timer version assignements #511
base: main
Are you sure you want to change the base?
Conversation
Apparently, multiple timer versions are not allowed at once. I am quite sure that the H7 parts do actually use timers of different versions. For example, I checked the |
I made a "fix" to allow mismatching timer peripheral versions in the chip generator. |
1236d4b
to
1c76bdc
Compare
@Dirbaio I created a single file in the following way:
Is there a good way to test this? |
As you said, @Dirbaio Do you have a suggestion for avoiding a lot of code duplication? We may just generate for either the v1 or the v2 timers. The others would not be usable in that case - not perfect, but at least 9 timers can be used correctly in case of v2 (vs. 8 v1 timers). I adjusted this PR according to the last suggestion. |
a4cb325
to
60b204b
Compare
60b204b
to
1061ea7
Compare
Is this a good approach, or should we change it? |
1061ea7
to
d5590f8
Compare
@elagil if you look through the diff the CI bot posted, there's many timers where the |
@Dirbaio I know, the disabled timers are the v1 timers. This PR deliberately makes it so that only v2 timers are active. Up to now, all timers (even v2) were used with the v1 register set. I chose to enable only v2 timers with this PR because there are more v2 than v1 timers, and they have more features. These now use the v2 register definitions, as they should. Do you have an idea for solving this problem? v1 and v2 do not have compatible registers and cannot be merged into a single definition file. As you said, in embassy, we cannot use multiple driver versions at once. See also the comment above: #511 (comment) |
ah sorry I should've read the thread instead of assuming my memory is in working order 😅 There's people out there using a lot of timers, sometimes someone asks in Matrix how to free the timer used by the time driver because they're running out. I can imagine making a bunch of timers not have registers will be unpopular. I'd say allowing all timers to be usable is better than having 100% accuracy but only allowing using half the timers. so yes, if some timers have some features and the others don't then we'll need two copies of fieldsets/enums and make the right timer block use the right ones... The HAL will have to deal with this ... somehow. Perhaps it's okay for now to be slightly inaccurate, for example using the "more advanced" enums/fieldsets for all timers and hope users read the docs of which features are available on which timers. |
Ok, I will think of something for handling two versions at once without excessive duplication. I need some of the advanced features of the v2 timers (e.g. USB SOF signal as trigger), so I can't just use v1 definitions. |
Disables v1 timers, until there is support for multiple timer versions in embassy at the same time.
d5590f8
to
5056d39
Compare
Closes #509