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

ButtonBoard examples #425

Open
bennuttall opened this Issue Sep 1, 2016 · 28 comments

Comments

Projects
None yet
3 participants
@bennuttall
Member

bennuttall commented Sep 1, 2016

It's not clear to me from the docs how to make effective use of the new ButtonBoard class.

I want to be able to read and process the number of buttons pressed. Unless I'm missing something, this seems to be done using bb.value:

>>> bb.value
ButtonBoardValue(_0=False, _1=False, _2=False)
>>> any(bb.value)
False
>>> not any(bb.value)
True
>>> all(bb.value)
False
>>> sum(bb.value)
0
>>> sum(bb.value) > 1:
False

But I'm not sure about how to use bb.values as a source, for example the average value of the buttons being passed into a PWMLED, achieved without source/values:

while True:
    led.value = sum(bb.value) / len(bb.value)

I tried with the averaged tool but that requires multiple .values, not a .values with multiple values!

Anyway, we should add some decent examples: something simple in the class docstring and some examples in the recipes. If obvious use cases aren't sufficiently easy, it may be worth considering adding some calculated properties to the API. It's also not obvious how to get the number of buttons pressed because .value is not shown in the docs.

@bennuttall

This comment has been minimized.

Show comment
Hide comment
@bennuttall

bennuttall Sep 1, 2016

Member

Additionally, there's

>>> sum(b.is_pressed for b in bb)
0

and

>>> bb[0].is_pressed
False
Member

bennuttall commented Sep 1, 2016

Additionally, there's

>>> sum(b.is_pressed for b in bb)
0

and

>>> bb[0].is_pressed
False
@lurch

This comment has been minimized.

Show comment
Hide comment
@lurch

lurch Sep 1, 2016

Contributor

They're not yet recipe-quality, but there's some usage examples in #340

bb.values needs to be used in combination with a source that expects the same number of values. For example something like:

from gpiozero import *
lb = LEDBoard(3, 4, 5, 6)
bb = ButtonBoard(7, 8, 9, 10)
lb.source = bb.values

And then pressing the button connected to e.g. GPIO9 would light up the LED connected to GPIO5.

I think part of what you're asking also overlaps with #365 and #379

Personally I'd be against adding calculated properties to the base ButtonBoard class, but of course user-code is free to do that with a subclass.

P.S. #370 (comment) ;-)

Contributor

lurch commented Sep 1, 2016

They're not yet recipe-quality, but there's some usage examples in #340

bb.values needs to be used in combination with a source that expects the same number of values. For example something like:

from gpiozero import *
lb = LEDBoard(3, 4, 5, 6)
bb = ButtonBoard(7, 8, 9, 10)
lb.source = bb.values

And then pressing the button connected to e.g. GPIO9 would light up the LED connected to GPIO5.

I think part of what you're asking also overlaps with #365 and #379

Personally I'd be against adding calculated properties to the base ButtonBoard class, but of course user-code is free to do that with a subclass.

P.S. #370 (comment) ;-)

@bennuttall

This comment has been minimized.

Show comment
Hide comment
@bennuttall

bennuttall Sep 1, 2016

Member

Why does bb.value return a ButtonBoardValue object, not a tuple?

Member

bennuttall commented Sep 1, 2016

Why does bb.value return a ButtonBoardValue object, not a tuple?

@bennuttall

This comment has been minimized.

Show comment
Hide comment
@bennuttall

bennuttall Sep 1, 2016

Member

You could also do:

bb_summed_values = (sum(i) for i in bb.values)
while True:
    print(next(bb_summed_values))

or

bb_averaged_values = (sum(i) / len(i) for i in bb.values)
led.source = bb_averaged_values

Ah! This works. Is there a better way?

Member

bennuttall commented Sep 1, 2016

You could also do:

bb_summed_values = (sum(i) for i in bb.values)
while True:
    print(next(bb_summed_values))

or

bb_averaged_values = (sum(i) / len(i) for i in bb.values)
led.source = bb_averaged_values

Ah! This works. Is there a better way?

@lurch

This comment has been minimized.

Show comment
Hide comment
@lurch

lurch Sep 1, 2016

Contributor

Why does bb.value return a ButtonBoardValue object, not a tuple?

It's all wrapped up in the magic inside CompositeDevice ;-) ButtonBoardValue is an (automatically created) namedtuple, so I believe you should be able to treat it as though it was just a tuple. (It's a namedtuple, because the CompositeDevice constructor allows devices to be passed as both positional-args and keyword-args)

Unfortunately that's another area where the docs are somewhat lacking.

Ah! This works.

It does? Cool! I'm guessing it's probably a Python3-specific thing though, as it's relying on lazy evaluation of the iterator?

Is there a better way?

The 'better way' might be to explicitly construct a generator, like some of the stuff me and @waveform80 were discussing in #119

Contributor

lurch commented Sep 1, 2016

Why does bb.value return a ButtonBoardValue object, not a tuple?

It's all wrapped up in the magic inside CompositeDevice ;-) ButtonBoardValue is an (automatically created) namedtuple, so I believe you should be able to treat it as though it was just a tuple. (It's a namedtuple, because the CompositeDevice constructor allows devices to be passed as both positional-args and keyword-args)

Unfortunately that's another area where the docs are somewhat lacking.

Ah! This works.

It does? Cool! I'm guessing it's probably a Python3-specific thing though, as it's relying on lazy evaluation of the iterator?

Is there a better way?

The 'better way' might be to explicitly construct a generator, like some of the stuff me and @waveform80 were discussing in #119

@lurch

This comment has been minimized.

Show comment
Hide comment
@lurch

lurch Sep 1, 2016

Contributor

...or I guess you might be able to do:

from gpiozero.compat import mean
led.source = map(mean, bb.values)

(but note that I've not actually tried this)

Contributor

lurch commented Sep 1, 2016

...or I guess you might be able to do:

from gpiozero.compat import mean
led.source = map(mean, bb.values)

(but note that I've not actually tried this)

@lurch

This comment has been minimized.

Show comment
Hide comment
@lurch

lurch Sep 1, 2016

Contributor

I'm guessing it's probably a Python3-specific thing though...

Nope, not Python3-specific, I didn't realise you were actually using a generator comprehension.

Contributor

lurch commented Sep 1, 2016

I'm guessing it's probably a Python3-specific thing though...

Nope, not Python3-specific, I didn't realise you were actually using a generator comprehension.

@bennuttall

This comment has been minimized.

Show comment
Hide comment
@bennuttall

bennuttall Sep 1, 2016

Member

Yeah, generator expressions, lazy evaluation. Very handy.

Your map example works btw.

Member

bennuttall commented Sep 1, 2016

Yeah, generator expressions, lazy evaluation. Very handy.

Your map example works btw.

@waveform80

This comment has been minimized.

Show comment
Hide comment
@waveform80

waveform80 Sep 3, 2016

Member

Yup - generator expressions are absolutely awesome (and have been since 2.x). As @lurch has pointed out, ButtonBoard is great for hooking up to similarly sized LEDBoard's (the coincidental naming is, I'm sure, intentional). However, I think it'll also be a good base for either user classes (as noted above) or possibly more built-in classes of our own. In particular, looking at the DIP-switches on the pidee, I was thinking of a DipSwitch class which'd provide the integer value defined by the switches (which could be trivially derived from ButtonBoard, overriding its value property in a similar way LEDBarGraph does for LEDCollection).

However, before then I'm determined to do some of the "boring bits" - hopefully including some doc improvements.

Member

waveform80 commented Sep 3, 2016

Yup - generator expressions are absolutely awesome (and have been since 2.x). As @lurch has pointed out, ButtonBoard is great for hooking up to similarly sized LEDBoard's (the coincidental naming is, I'm sure, intentional). However, I think it'll also be a good base for either user classes (as noted above) or possibly more built-in classes of our own. In particular, looking at the DIP-switches on the pidee, I was thinking of a DipSwitch class which'd provide the integer value defined by the switches (which could be trivially derived from ButtonBoard, overriding its value property in a similar way LEDBarGraph does for LEDCollection).

However, before then I'm determined to do some of the "boring bits" - hopefully including some doc improvements.

@bennuttall

This comment has been minimized.

Show comment
Hide comment
@bennuttall

bennuttall Sep 4, 2016

Member

It sounds like you're suggesting DipSwitch would be a composite class, but it's not uncommon to use a single dip switch. Of course this would just be identical to a button.

So it sounds like, similarly to LEDBoard and LEDBarGraph, we see two different use cases for a collection of buttons:

  • map each button to an output device 1->1
  • process the combination of active buttons

Does that require two classes? I'm not sure.

Depending on use case, you may want to know:

  • sum of buttons pressed
  • mean of buttons pressed
  • integer representation of numbers pressed (e.g. 0111 = 7)
  • more?

For example, the pidee has 8 dip switches => 256* combinations. Maybe it would be useful to be able to process the combination number to trigger a particular action? *edited

Would we want to provide each of these as a property, or just provide the value tuple and allow users to compute this themselves?

Member

bennuttall commented Sep 4, 2016

It sounds like you're suggesting DipSwitch would be a composite class, but it's not uncommon to use a single dip switch. Of course this would just be identical to a button.

So it sounds like, similarly to LEDBoard and LEDBarGraph, we see two different use cases for a collection of buttons:

  • map each button to an output device 1->1
  • process the combination of active buttons

Does that require two classes? I'm not sure.

Depending on use case, you may want to know:

  • sum of buttons pressed
  • mean of buttons pressed
  • integer representation of numbers pressed (e.g. 0111 = 7)
  • more?

For example, the pidee has 8 dip switches => 256* combinations. Maybe it would be useful to be able to process the combination number to trigger a particular action? *edited

Would we want to provide each of these as a property, or just provide the value tuple and allow users to compute this themselves?

@lurch

This comment has been minimized.

Show comment
Hide comment
@lurch

lurch Sep 4, 2016

Contributor

Does that require two classes?

I don't think so. If you want to access each button individually, you can either create them all as separate Button objects, or access them by name or by index (depending on how the ButtonBoard was constructed) as attributes of the ButtonBoard object.

For example, the pidee has 8 dip switches => 64 combinations.

Your binary logic has gone wrong ;-) 2 ** 8 = 256

Maybe it would be useful to be able to process the combination number to trigger a particular action?

Yeah, that kinda ties in with my thoughts in #261 - being able to supply additional args to the callback functions (in this case, it would be nice if the when_changed callback could be told which button has changed value).

Although you can trigger different actions based on the combination with the current code, by reading bb.value inside the bb.when_changed callback.

Depending on use case, you may want to know ...[snip]... Would we want to provide each of these as a property, or just provide the value tuple and allow users to compute this themselves?

IMHO apart from your DotsBoard example, the use-cases for wanting to know the sum or mean of the buttons pressed would be very limited. So IMHO the base ButtonBoard class should stay as-is.

And going back to @waveform80 's example of a DipSwitch class overriding the value property: my gut instinct would be to keep value to being either boolean, 0->1, -1->+1, or various tuples of those. And then provide perhaps a combined_value (or something) property, which returns the bitwise integer interpretation of value. Similar to #329, #371, http://gpiozero.readthedocs.io/en/v1.3.1/api_input.html#gpiozero.DistanceSensor.distance etc.

Contributor

lurch commented Sep 4, 2016

Does that require two classes?

I don't think so. If you want to access each button individually, you can either create them all as separate Button objects, or access them by name or by index (depending on how the ButtonBoard was constructed) as attributes of the ButtonBoard object.

For example, the pidee has 8 dip switches => 64 combinations.

Your binary logic has gone wrong ;-) 2 ** 8 = 256

Maybe it would be useful to be able to process the combination number to trigger a particular action?

Yeah, that kinda ties in with my thoughts in #261 - being able to supply additional args to the callback functions (in this case, it would be nice if the when_changed callback could be told which button has changed value).

Although you can trigger different actions based on the combination with the current code, by reading bb.value inside the bb.when_changed callback.

Depending on use case, you may want to know ...[snip]... Would we want to provide each of these as a property, or just provide the value tuple and allow users to compute this themselves?

IMHO apart from your DotsBoard example, the use-cases for wanting to know the sum or mean of the buttons pressed would be very limited. So IMHO the base ButtonBoard class should stay as-is.

And going back to @waveform80 's example of a DipSwitch class overriding the value property: my gut instinct would be to keep value to being either boolean, 0->1, -1->+1, or various tuples of those. And then provide perhaps a combined_value (or something) property, which returns the bitwise integer interpretation of value. Similar to #329, #371, http://gpiozero.readthedocs.io/en/v1.3.1/api_input.html#gpiozero.DistanceSensor.distance etc.

@bennuttall

This comment has been minimized.

Show comment
Hide comment
@bennuttall

bennuttall Sep 4, 2016

Member

Your binary logic has gone wrong ;-) 2 ** 8 = 256

Derp. I did 8**2 not 2**8. I blame Sunday.

my gut instinct would be to keep value to being either boolean, 0->1, -1->+1, or various tuples of those. And then provide perhaps a combined_value (or something) property, which returns the bitwise integer interpretation of value

I think that makes sense.

Member

bennuttall commented Sep 4, 2016

Your binary logic has gone wrong ;-) 2 ** 8 = 256

Derp. I did 8**2 not 2**8. I blame Sunday.

my gut instinct would be to keep value to being either boolean, 0->1, -1->+1, or various tuples of those. And then provide perhaps a combined_value (or something) property, which returns the bitwise integer interpretation of value

I think that makes sense.

@waveform80

This comment has been minimized.

Show comment
Hide comment
@waveform80

waveform80 Sep 4, 2016

Member

And going back to @waveform80 's example of a DipSwitch class overriding the value property: my gut instinct would be to keep value to being either boolean, 0->1, -1->+1, or various tuples of those. And then provide perhaps a combined_value (or something) property, which returns the bitwise integer interpretation of value. Similar to #329, #371, http://gpiozero.readthedocs.io/en/v1.3.1/api_input.html#gpiozero.DistanceSensor.distance etc.

Sorry, rushing again - that's exactly what I meant (0..1 value range, separate property for the "raw value" similar to the SPI pots stuff).

Member

waveform80 commented Sep 4, 2016

And going back to @waveform80 's example of a DipSwitch class overriding the value property: my gut instinct would be to keep value to being either boolean, 0->1, -1->+1, or various tuples of those. And then provide perhaps a combined_value (or something) property, which returns the bitwise integer interpretation of value. Similar to #329, #371, http://gpiozero.readthedocs.io/en/v1.3.1/api_input.html#gpiozero.DistanceSensor.distance etc.

Sorry, rushing again - that's exactly what I meant (0..1 value range, separate property for the "raw value" similar to the SPI pots stuff).

@bennuttall

This comment has been minimized.

Show comment
Hide comment
@bennuttall

bennuttall Sep 4, 2016

Member

cough

the unmerged SPI pots stuff #329 / #331

Member

bennuttall commented Sep 4, 2016

cough

the unmerged SPI pots stuff #329 / #331

@waveform80

This comment has been minimized.

Show comment
Hide comment
@waveform80

waveform80 Sep 4, 2016

Member

Actually I was talking about raw_value which is merged - but yes, I'll get onto the voltage stuff soon. I'm currently working on the SPI tests (already squashed a couple of bugs, and had to rethink exactly where SPI options are handled in the software implementation - nothing API breaking though).

Member

waveform80 commented Sep 4, 2016

Actually I was talking about raw_value which is merged - but yes, I'll get onto the voltage stuff soon. I'm currently working on the SPI tests (already squashed a couple of bugs, and had to rethink exactly where SPI options are handled in the software implementation - nothing API breaking though).

@bennuttall

This comment has been minimized.

Show comment
Hide comment
@bennuttall

bennuttall Sep 4, 2016

Member

Ah ok, cool!

Member

bennuttall commented Sep 4, 2016

Ah ok, cool!

@lurch

This comment has been minimized.

Show comment
Hide comment
@lurch

lurch Sep 4, 2016

Contributor

OffTopic: The more I think about LEDBoard and ButtonBoard, the more I think that the ADC classes (MCP3008 etc.) should have been implemented as a kind of ADCBoard subclass, i.e. create a single ADCBoard object for each actual chip, and then each channel of the ADC is simply a separate property / attribute of the ADCBoard. Which would have eliminated the need for the 'shared' SPI stuff.
Oh well, can't break the API now :-/

Contributor

lurch commented Sep 4, 2016

OffTopic: The more I think about LEDBoard and ButtonBoard, the more I think that the ADC classes (MCP3008 etc.) should have been implemented as a kind of ADCBoard subclass, i.e. create a single ADCBoard object for each actual chip, and then each channel of the ADC is simply a separate property / attribute of the ADCBoard. Which would have eliminated the need for the 'shared' SPI stuff.
Oh well, can't break the API now :-/

@bennuttall

This comment has been minimized.

Show comment
Hide comment
@bennuttall

bennuttall Sep 4, 2016

Member

I think you're right. I had the same thought recently (well, I decided classes like MCP3008 weren't like the others, but I couldn't figure out how they should be. And that's it.)

Damn.

Member

bennuttall commented Sep 4, 2016

I think you're right. I had the same thought recently (well, I decided classes like MCP3008 weren't like the others, but I couldn't figure out how they should be. And that's it.)

Damn.

@bennuttall

This comment has been minimized.

Show comment
Hide comment
@bennuttall

bennuttall Sep 4, 2016

Member

Actually I was thinking it's un-gpiozero-like to have multiple instances of MCP3008. And instances of MCP3008 representing devices like potentiometers doesn't quite make sense. Perhaps something like:

from gpiozero import MCP3008, Potentiometer

adc = MCP3008()
pot = Potentiometer(adc[0])

where adc[0] is an AnalogPin object, would make more sense.

Member

bennuttall commented Sep 4, 2016

Actually I was thinking it's un-gpiozero-like to have multiple instances of MCP3008. And instances of MCP3008 representing devices like potentiometers doesn't quite make sense. Perhaps something like:

from gpiozero import MCP3008, Potentiometer

adc = MCP3008()
pot = Potentiometer(adc[0])

where adc[0] is an AnalogPin object, would make more sense.

@lurch

This comment has been minimized.

Show comment
Hide comment
@lurch

lurch Sep 4, 2016

Contributor

Yeah, something like that.
Although it's not immediately obvious to me what functionality a specific Potentiometer class would offer over an AnalogPin?

EDIT: Unless you wanted to 'decode' the voltage read by the ADC into an 'angle' of the potentiometer - like an inverse Servo ;-)

Contributor

lurch commented Sep 4, 2016

Yeah, something like that.
Although it's not immediately obvious to me what functionality a specific Potentiometer class would offer over an AnalogPin?

EDIT: Unless you wanted to 'decode' the voltage read by the ADC into an 'angle' of the potentiometer - like an inverse Servo ;-)

@bennuttall

This comment has been minimized.

Show comment
Hide comment
@bennuttall

bennuttall Sep 4, 2016

Member

Not entirely sure myself, but you could say the same about LED and Buzzer. They differ only slightly now (and in the first few commits were just class LED(OutputDevice): pass and class Buzzer(OutputDevice): pass.

It just feels like that's how it should be.

Member

bennuttall commented Sep 4, 2016

Not entirely sure myself, but you could say the same about LED and Buzzer. They differ only slightly now (and in the first few commits were just class LED(OutputDevice): pass and class Buzzer(OutputDevice): pass.

It just feels like that's how it should be.

@lurch

This comment has been minimized.

Show comment
Hide comment
@lurch

lurch Sep 4, 2016

Contributor

Fair enough - I guess user-friendliness and ease-of-use need to be the overriding aims here.

Should there be class Switch(Button): pass ?

Contributor

lurch commented Sep 4, 2016

Fair enough - I guess user-friendliness and ease-of-use need to be the overriding aims here.

Should there be class Switch(Button): pass ?

@bennuttall

This comment has been minimized.

Show comment
Hide comment
@bennuttall

bennuttall Sep 4, 2016

Member

😈

(because there's no devil's advocate emoji)

Member

bennuttall commented Sep 4, 2016

😈

(because there's no devil's advocate emoji)

@lurch

This comment has been minimized.

Show comment
Hide comment
@lurch

lurch Sep 5, 2016

Contributor

OTOH, I guess a Switch is opened and closed, whereas a Button is pressed and released ;-)

Contributor

lurch commented Sep 5, 2016

OTOH, I guess a Switch is opened and closed, whereas a Button is pressed and released ;-)

@bennuttall

This comment has been minimized.

Show comment
Hide comment
@bennuttall

bennuttall Sep 5, 2016

Member

I guess so. Or on/off like a light switch:

http://img.weiku.com/b%5C003%5C269%5C65421_15_Rocker_Electronic_Switch_SS11_.jpg

I was thinking about switches recently. Particularly a three position one like this:

https://ae01.alicdn.com/kf/HTB1WLhvJXXXXXafXFXXq6xXFXXXM/10-PCS-lot-electronic-switch-band-3-black-ship-type-switch-3-feet-become-warped-board.jpg_640x640.jpg

It doesn't make sense that a reed switch would be pressed / released either. activated / deactivated makes sense but isn't as friendly. Would a collection of switches be a SwitchBoard?

We're going off topic here, and I honestly don't know whether we should continue this elsewhere.

Member

bennuttall commented Sep 5, 2016

I guess so. Or on/off like a light switch:

http://img.weiku.com/b%5C003%5C269%5C65421_15_Rocker_Electronic_Switch_SS11_.jpg

I was thinking about switches recently. Particularly a three position one like this:

https://ae01.alicdn.com/kf/HTB1WLhvJXXXXXafXFXXq6xXFXXXM/10-PCS-lot-electronic-switch-band-3-black-ship-type-switch-3-feet-become-warped-board.jpg_640x640.jpg

It doesn't make sense that a reed switch would be pressed / released either. activated / deactivated makes sense but isn't as friendly. Would a collection of switches be a SwitchBoard?

We're going off topic here, and I honestly don't know whether we should continue this elsewhere.

@lurch

This comment has been minimized.

Show comment
Hide comment
@lurch

lurch Sep 6, 2016

Contributor

I guess from an electrical PoV, a three-position switch would be like a one-dimensional keypad matrix? Or perhaps it's more like two mutually-exclusive buttons? (I suppose it depends how you choose to wire it up)

I guess what we really want is more suggestions / feedback from the community about what other kinds of (simple) components Gpio Zero should provide built-in support for. Anything you picked up from any of the Picademies?

Contributor

lurch commented Sep 6, 2016

I guess from an electrical PoV, a three-position switch would be like a one-dimensional keypad matrix? Or perhaps it's more like two mutually-exclusive buttons? (I suppose it depends how you choose to wire it up)

I guess what we really want is more suggestions / feedback from the community about what other kinds of (simple) components Gpio Zero should provide built-in support for. Anything you picked up from any of the Picademies?

@waveform80

This comment has been minimized.

Show comment
Hide comment
@waveform80

waveform80 Sep 7, 2016

Member

OffTopic: The more I think about LEDBoard and ButtonBoard, the more I think that the ADC classes (MCP3008 etc.) should have been implemented as a kind of ADCBoard subclass, i.e. create a single ADCBoard object for each actual chip, and then each channel of the ADC is simply a separate property / attribute of the ADCBoard. Which would have eliminated the need for the 'shared' SPI stuff.
Oh well, can't break the API now :-/

Yes, having been elbow deep in the SPI code for the last day or two I'm inclined to agree. The shared stuff is horrific to test. On the other hand, adding an ADCBoard and Analog pins and the like isn't an API break. It'd be confusing in as much as there'd be two ways of doing things, but it wouldn't necessarily be backward incompatible (e.g. call the resulting MCP3008 class MCP3008Pins or something so it didn't clash with the existing stuff). Then we could deprecate the existing MCP3008 class with a view to removing it in 2.0 or thereabouts. Anyway, this should all go in a separate ticket if we decide to persue that course (side note: the existing software SPI implementation wouldn't have to change either; the shared classes would just be deprecated).

Member

waveform80 commented Sep 7, 2016

OffTopic: The more I think about LEDBoard and ButtonBoard, the more I think that the ADC classes (MCP3008 etc.) should have been implemented as a kind of ADCBoard subclass, i.e. create a single ADCBoard object for each actual chip, and then each channel of the ADC is simply a separate property / attribute of the ADCBoard. Which would have eliminated the need for the 'shared' SPI stuff.
Oh well, can't break the API now :-/

Yes, having been elbow deep in the SPI code for the last day or two I'm inclined to agree. The shared stuff is horrific to test. On the other hand, adding an ADCBoard and Analog pins and the like isn't an API break. It'd be confusing in as much as there'd be two ways of doing things, but it wouldn't necessarily be backward incompatible (e.g. call the resulting MCP3008 class MCP3008Pins or something so it didn't clash with the existing stuff). Then we could deprecate the existing MCP3008 class with a view to removing it in 2.0 or thereabouts. Anyway, this should all go in a separate ticket if we decide to persue that course (side note: the existing software SPI implementation wouldn't have to change either; the shared classes would just be deprecated).

@lurch

This comment has been minimized.

Show comment
Hide comment
@lurch

lurch Sep 7, 2016

Contributor

I think we're all in agreement then. I'll open a new issue.
And it's just occurred to me that we could construct an LEDBoard with pwm=True, and then do LEDBoard.source = ADCBoard.values - neat! :-)

(and it would be really cool to see e.g. https://www.adafruit.com/product/2327 implemented as a ServoBoard - leading to ServoBoard.source = ADCBoard.values)

Contributor

lurch commented Sep 7, 2016

I think we're all in agreement then. I'll open a new issue.
And it's just occurred to me that we could construct an LEDBoard with pwm=True, and then do LEDBoard.source = ADCBoard.values - neat! :-)

(and it would be really cool to see e.g. https://www.adafruit.com/product/2327 implemented as a ServoBoard - leading to ServoBoard.source = ADCBoard.values)

@lurch lurch referenced this issue Sep 7, 2016

Open

ADCBoard #429

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment