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

[Proposal] Add System.Device.Gpio.Clock() #108

Closed
shaggygi opened this issue Dec 17, 2018 · 8 comments
Closed

[Proposal] Add System.Device.Gpio.Clock() #108

shaggygi opened this issue Dec 17, 2018 · 8 comments
Labels
api-suggestion Early API idea and discussion, it is NOT ready for implementation area-System.Device.Gpio Contains types for using general-purpose I/O (GPIO) pins

Comments

@shaggygi
Copy link
Contributor

Referencing #107 as it spawned some thinking on other out-of-box GPIO support.

In addition to Toggle(), it might be worth investigating a Clock() function. For example,

var controller = new GpioController();
int clkPin = 8;
controller.OpenPin(clkPin, PinMode.Output);  // Setup clock pin.
controller.Write(clkPin, PinValue.High); // Set to initial high state.

// Do other logic to to get external hardware ready to clock.

controller.Clock(clkPin, 5); // Starting in high (logic 1) state, begin clocking 5 times.

// clkPin is now idle in initial state (high state).

In many cases, you will most likely need to clock once and read. However, there are also times you need to clock registers and such to rotate bits to a certain location to begin read bits.

  1. Should there be a time interval argument to toggle state (understanding this isn't going to be accurate)?
  2. Should this be an Async method?
  3. Other thoughts?
@joperezr
Copy link
Member

I suppose that the motivation around this is to be able to write a software-based SPI, I2C or PWM protocol?

@joperezr joperezr added api-suggestion Early API idea and discussion, it is NOT ready for implementation area-System.Device.Gpio Contains types for using general-purpose I/O (GPIO) pins labels Dec 20, 2018
@shaggygi
Copy link
Contributor Author

This could benefit within for the bit-banging and protocols, as well. I initialing was thinking for areas like registers, latches, etc. where you sometimes need a to just clock a few times. This would help instead of having to create a bunch of for loops in the future.

An example, that comes to mind... in my senior college project, I interfaced a microcontroller to pull button status out of an N64 controller. The interface was set up in a way where there were X number of bytes somewhere within a range of bytes. The only way to get the info was by an individual data pin. So instead of have to for loop High/Low (or Low/High based on pin state) a number times... I could just say .Clock(1, X) to get me to where the bits started showing up on the data pin.

@joperezr
Copy link
Member

What does X and 1 stand for in your example? In my mind, this method should take in a pinNumber, a double of frequency, and perhaps the number of cycles you want to send the signal.

@shaggygi
Copy link
Contributor Author

shaggygi commented Dec 20, 2018

See original comment above for entire example. 1 represented the clkPin and X represents the number of times to clock.

I agree with you on the state issue (from #107) so the signature of method would have to change. Maybe something like...

int clkPin = 1;
int numberOfClocks = 5;
PinValue idlePinValue = PinValue.High;
controller.Clock(clkPin, numberOfClocks, idlePinValue);

One problem with this is the clkPin Value would already have to be at idlePinValue before calling as it could (1) miss the initial transition or (2) accidentally create an addition clock signal.

@joperezr
Copy link
Member

Won't you also need some sort of parameter to define frequency in case the clock signals have to have some sort of delay between each other?

@shaggygi
Copy link
Contributor Author

Yup, that was for question 1.

  1. Should there be a time interval argument to toggle state (understanding this isn't going to be accurate)?

So the Clock method would be something like below. NOTE: I just threw in the frequency/delay argument, but more thinking is needed (e.g. Optional, default value, etc.).

public void Clock(int clkPin, int numberOfClocks, PinValue idlePinValue, int clockDelay)
{
    for(int clockCnt = 0; clockCnt < numberOfClocks; clockCnt++)
    {
        Thread.Sleep(clockDelay);

        if(idlePinValue == PinValue.Low)
        {
            _controller.Write(clkPin, PinValue.High);            
        }
        else
        {
            _controller.Write(clkPin, PinValue.Low);
        }

        Thread.Sleep(clockDelay);
        _controller.Write(clkPin, idlePinValue);  // Go back to initial idle value.
    }
}

@joperezr
Copy link
Member

I'm not sure this would have enough value in order to have it on our main library API. On the other hand, if more than one device binding needs this, I would be ok if a method like this lives under src/devices/Common and have those bindings that need it to optionally call into this method. If we do want that, this could live in a class like GpioControllerExtensions.cs which looked something like:

public static class GpioControllerExtensions
{
  public static void Clock(this IGpioController controller, int clckPin, int numberOfClocks, PinValue idlePinValue, int clockDelay);
}

@shaggygi
Copy link
Contributor Author

This is another one of those "nice to haves", but not needed. I've only come up with one binding that would need and that small amount of code could reside in its own API. I'll close for now.

@ghost ghost locked as resolved and limited conversation to collaborators Oct 15, 2020
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
api-suggestion Early API idea and discussion, it is NOT ready for implementation area-System.Device.Gpio Contains types for using general-purpose I/O (GPIO) pins
Projects
None yet
Development

No branches or pull requests

2 participants