Skip to content

Capture API #5

New issue

Have a question about this project? # for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “#”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? # to your account

Open
japaric opened this issue Jun 9, 2017 · 5 comments
Open

Capture API #5

japaric opened this issue Jun 9, 2017 · 5 comments

Comments

@japaric
Copy link
Member

japaric commented Jun 9, 2017

  • What is missing in this API?
  • Can this API be implemented for different devices?
@japaric japaric added the RFC label Jun 9, 2017
@japaric
Copy link
Member Author

japaric commented Jun 9, 2017

What is missing in this API?

Possibly methods to choose the capture "edge". Should this capture the rising edge or the falling edge? This is useful in generic context to capture on "high" signal: you want to capture the rising edge and then the falling edge.

Another question: is a enum Edge { Rising, Falling } enough, or should Edge be an associated type of the Capture trait? Are there microcontrollers that have a "capture both edges" setting?

@adamgreig
Copy link
Member

adamgreig commented Jun 14, 2017

Are there microcontrollers that have a "capture both edges" setting?

Yep, I think most STM32F3/4/7 and maybe 0 have options for rising/falling/both (along with a whole heap of other options...). See CCER register.

@japaric
Copy link
Member Author

japaric commented Jun 15, 2017

OK. The F103 only has two options: rising and falling. The F303 has three: rising, falling and both. I would prefer if each device crate didn't end up inventing their own Edge enum so perhaps we can have the most common Edge enums in this crate. At least Edge2 { Rising, Falling } and Edge3 { Rising, Falling, Both }. Then we have to make the edge related API generic around the Edge enum. So maybe:

trait CaptureOn<Edge> {
    fn capture_on(_: Edge);
}

then generic APIs can use a bound like C: Capture + CaptureOn<Edge2> when they need to capture the rising and falling edges in their implementation.

@japaric
Copy link
Member Author

japaric commented Jan 20, 2018

Update: this trait is available in release v0.1.0 behind the "unproven" Cargo feature.

@Fomys
Copy link

Fomys commented Jul 31, 2022

Hello,
This is my first time contributing here, I don't know if I'm doing it the right way.

With this API, I think it would be difficult to write drivers.
Some drivers only need a capture on the rising edge, which enum should they use? Edge2? Edge3?

Maybe a better way to handle this would be to use multiple traits :

trait CaptureRising {
    fn capture();
}
trait CaptureFalling {
    fn capture();
}
trait CaptureBoth: CaptureRising + CaptureFalling {
    fn capture();
}

And it will be used like this:

struct MyDevice<C: CaptureRising> {
    capture: C
}

impl<C: CaptureRising> MyDevice {
    fn something(&self) {
        self.capture.capture();
    }
}

With this, the driver will be compatible with all devices which implement CaptureRising.

# for free to join this conversation on GitHub. Already have an account? # to comment
Projects
None yet
Development

No branches or pull requests

3 participants