Overhaul the pin handling (not backwards compatible) #224
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
This PR will track changes to the pin handling. The original goal was to allow using the analog pins as digital inputs through bitlash, as well as make the analog pin reference selectable. At the same time, this changes some of the internals of the pin handling for better consistency and cleaner code. This does mean this will become backwards incompatible - function names have changed (both in bitlash and C++) and the pin modes now have different numbering. The pin reports will change as well, but that wasn't implemented yet (neither has analog reference selection).
So this is not finished yet, just wanted to collect some feedback early.
Some more detailed list of changes, from the biggest commit:
Split INPUT mode into INPUT_DIGITAL and INPUT_ANALOG. This allows
using analog pins as digital pins as well. It requires explicitely
choosing either of these modes, except when using pin.makeinput,
which autoselects based on the pin type.
Rename and renumber the pin mode constants. This makes things a bit
more consistent and by removing the negative values we allow using
the upper bits of the mode as flags or other values.
Generalize the "pin mode" value into a "pin config" value, which
contains the pin mode, combined with other values. Right now, this
is only a flag for wether the pullup is enabled (which was previously
part of the mode), but in the future flags like "reports enabled" or
values like the analog reference to use can be included.
This removes the pin.setmode command and replaces it with pin.config,
which works similar. It accepts the following modes: disabled,
disconnected, input_digital, input_analog, output_digital,
output_pwm. Additionally, the value flag_pullup can be added to
the input modes to enable pullups (defaulting to disabled). e.g.:
When setting a pin to output_digital, it now gets written to LOW by
default. Previously, the value would be unchanged, which meant that
if the pullup was previously enabled, it would be HIGH, otherwise it
would be LOW. When using pin.config, the value can be overridden
(which is useful if you must go from input-with-pullup to output-high
without going through output-low for some reason).
pin.makeinput no longer takes input or input_pullup as the second
argument, but instead expects a 0 or 1 value to disable/enable
pullups. Leaving it out makes the default depend on the pin type (see
next item).
When setting an analog pin to input using pin.makeinput, it no longer
defaults to having the pullup enabled. Since the pullup is connected
to 3.3V, that's too high for the ADC, and if the voltage sensed comes
from a voltage divider, having the pullup enabled will even influence
the values read.
PinConfig and Mode values are now wrapped in structs, so you can do
things like config.mode().input() to see if an input mode was
selected. The constants for them are no also in their own scope, so
you write things like PinConfig::Mode::DISCONNECTED, which is more
clear than before. It seems like this would be a good usecase to use
C++11 enum classes to add scoping and type safety, but you cannot add
methods to enum classes. So this uses a struct with methods and an
old-style enum, which fixes the scoping but is a bit less typesafe.
This struct-wrapping does not add any storage overhead and minimal
to no code size overhead.
This does not properly update the reports yet. They are somewhat
updated, but analog pins still only generate analog reports now and the
pin modes are replaced by the new pin configs directly, which have
different values. There should probably be a single mode report and a
single value report, instead of splitting through analog and digital,
but that's for a later commit.