Skip to content
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

WIP: HRTIM #96

Draft
wants to merge 58 commits into
base: main
Choose a base branch
from
Draft

WIP: HRTIM #96

wants to merge 58 commits into from

Conversation

usbalbin
Copy link
Contributor

@usbalbin usbalbin commented Nov 30, 2023

Work in progress. This will likely be further split up across multiple PRs.

Currently requires stm32-rs/stm32-rs#860 , thus all the CI errors

TODO:

  • Traitify PreloadSource, MasterPreloadSource
  • Update examples for new traitified changes
    • hrtim/adc-trigger
  • Make sure the timers are started in the examples
  • Go through the examples once more in case of any last minute experiment leftovers

@@ -0,0 +1,113 @@
//This example puts the timer in PWM mode using the specified pin with a frequency of 100Hz and a duty cycle of 50%.
Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

These descriptions should be updated

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Almost all of the hrtim examples are just copy pasted from examples/hrtim/hrtim.rs or examples/hrtim/simple.rs and modified without having their comments updated.


out1.enable_rst_event(&cr1); // Set low on compare match with cr1
out1.enable_rst_event(eev_input4);
out1.enable_set_event(&timer); // Set high at new period
Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@no111u3 sort of related to #98...

I have been experimenting a bit with different ways to specify different types of event sources.

Here an event is specified by passing a reference to the thing to listen to. In this case:

  • reset output on compare register 1 match
  • reset output on external event 4 signal
  • set output on timer period event

The nice thing about this is that there is no way to specify the wrong event source by accident. Also there is no need to figure out what enum and variant to to use, just pass in the actual object(or reference to it).

However this requires the event source to exist before the listener which might make things more complicated?

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@usbalbin thank for this great example. Yesterday I've merged some changes but it will update in some next sessions (for every timers also). So I think about correct and wrong source for event, it might be provided by internal mark field (I'm not sure that rust can do it).

However this requires the event source to exist before the listener which might make things more complicated?

Following the RM on G4 (and other) family:

Note: The clock of the slave timer or ADC must be enabled prior to receive events from the master timer, and must not be changed on-the-fly while triggers are received from the master timer.

That means consumer must be created first, I've checked it on my g474 — violation rule makes ADC crazy.

Copy link
Contributor Author

@usbalbin usbalbin Dec 3, 2023

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

[..] Yesterday I've merged some changes [..]

Nice :)

It least when it comes to hrtim things might get quite complicated(I have not looked at a lot of other timers yet). For example I believe it is possible to use a:

  • DAC to output, for example, a saw tooth shape
  • This is routed to the comparators inverting input
  • The comparators output is routed to the hrtim EEV1
  • EEV1 is used as an rst event for an hrtim timers output.
  • That same hrtim timer triggers the update of the DAC's wave form, and around we go

Which object should be created first? :)

Whatever API we pick, it should preferably support doing things like that, while preventing the user from doing something that will violate the RM's rules.

.HRTIM_COMMON
.hr_control(&mut rcc)
.enable_adc_trigger1_source(Adc13Trigger::TimACmp3)
.enable_adc_trigger1_source(Adc13Trigger::TimACmp4)
Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

If this enable method was instead defined on HrPwmControl then the variables cr3 and cr4 could be passed directly to that method without the need for the enum.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@no111u3 what do you think about something like this d8d2b92 to avoid enums? (Will probably update the examples at some point)

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Hmm, I think it better to use one work variant instead of any workless.

@usbalbin usbalbin mentioned this pull request Jan 5, 2024
@usbalbin usbalbin force-pushed the hrtim_new_attempt branch 2 times, most recently from 6a4b3d0 to da8337e Compare January 19, 2024 09:21
@usbalbin
Copy link
Contributor Author

I have now gotten rid of a few enums in favor of traits to force the user to pass a reference to the actual type instead of an enum variant. See examples/adc-trigger.rs for how that looks like(this is the only example updated so far, it is not yet tested).

For anyone wanting to give it a try, I am using usbalbin/stm32-rs@ab9082b until the next stm32-rs/stm32-rs release

@usbalbin usbalbin force-pushed the hrtim_new_attempt branch 2 times, most recently from 966c1d9 to 9ad72a4 Compare January 24, 2024 16:09
usbalbin and others added 16 commits February 16, 2024 13:15
* Rcc enable is now handled for the entire HRTIM peripheral by dp.HRTIM_COMMON.hr_control() instead of by every timer
* HRTIM calibration is now mandatory, also handled by `dp.HRTIM_COMMON.hr_control()` but also by running on that result `_.wait_for_calibration().
* Add `get_state` for `HrOutput` to check what state an output is in: `Idle`, `Running` or `Fault`
* dma - update for new pac
* adc - triggers
* hrtim
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

2 participants