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

Timer driven Events #98

Open
no111u3 opened this issue Dec 2, 2023 · 3 comments
Open

Timer driven Events #98

no111u3 opened this issue Dec 2, 2023 · 3 comments

Comments

@no111u3
Copy link
Collaborator

no111u3 commented Dec 2, 2023

There aren't any way to setup run ADC from any timer or other event.
Also there aren't any functions to create chain of timers.

@usbalbin if you have some future PR's or any ideas, code snippets, welcome to the discussion.

@usbalbin
Copy link
Contributor

usbalbin commented Dec 2, 2023

Thanks :)

Here is one way in my very much work in progress hrtim PR. :)

@usbalbin usbalbin mentioned this issue Dec 3, 2023
5 tasks
@usbalbin
Copy link
Contributor

usbalbin commented Jan 1, 2024

Is that sort of API something we want to use for most event based things?

Just to summarize:

Avoid enums for representing event sources in the user facing api by instead letting them use the relevant object itself directly (or a reference to it). This also has the side effects that the event source needs to be setup before the consumer starts listening.

For example:

let (timer, (cr1, ..), (mut out1, mut out2)) = dp
        .HRTIM_TIMA
        .pwm_advanced((pin_a, pin_b), &mut rcc)
        [...]
        .finalize(&mut hr_control);

    //Good
    out1.enable_rst_event(&cr1); // Set low on compare match with cr1
    out1.enable_set_event(&timer); // Set high at new period
   
    // Bad
    out1.enable_rst_event(HrTimerEvent::Cr1); // Set low on compare match with cr1
    out1.enable_set_event(HrTimerEvent::Period); // Set high at new period

Incomplete list of vaguely similar things:

  • ADC and pins: pin knows what channel of the ad it is
  • Comp inverting input: pin, dac or vref division (not events but still a bit similar)
  • Opamp: I believe same as comp
  • DAC trigger: timers and hrtim I believe
  • Adc trigger source: lots of timers, hrtim "trigger sources", etc.
  • Hrtim output SET/RST: compare match, period, same things from other timers, hrtim "external events" etc.
  • hrtim period: about the same as above I believe
  • hrtim fault: comp, digital pin etc.
  • hrtim "external event": similar as above

@usbalbin
Copy link
Contributor

usbalbin commented Jan 5, 2024

So implementation wise that would mean that enums are avoided and instead traits are used with member const that are used to configure the listener.

Does this make sense? If so, would you like me to update #96 to follow that pattern? Or does anyone have other thoughts? :)

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

No branches or pull requests

2 participants