-
Notifications
You must be signed in to change notification settings - Fork 55
Use +512 for 0x43 and +256 for 0x44 expander pins #847
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
base: add-arduino-nesso-n1
Are you sure you want to change the base?
Changes from all commits
File filter
Filter by extension
Conversations
Jump to
Diff view
Diff view
There are no files selected for viewing
| Original file line number | Diff line number | Diff line change |
|---|---|---|
|
|
@@ -243,6 +243,28 @@ class DisplayController; | |
|
|
||
| #ifdef ARDUINO_ARDUINO_NESSO_N1 | ||
| static NessoBattery battery; ///< Nesso-N1 Battery instance | ||
|
|
||
| /**************************************************************************/ | ||
| /*! | ||
| @brief Printable subclass of ExpanderPin for use with Serial.println() | ||
| Allows ExpanderPin to be used interchangeably with uint8_t pins | ||
| when printing to Serial. | ||
| */ | ||
| /**************************************************************************/ | ||
| class WsExpanderPin : public ExpanderPin, public Printable { | ||
|
Member
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Is this only used for DigitalGPIO? Wouldn't it make more sense to sit within the DigitalGPIO class header than the application header?
Member
Author
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Currently it's only to add compatibility for one debug print call of flexyPinName (ExpanderPin instance), which could instead print the original decimal pinName, and so this class could probably be removed entirely, but it potentially would be extended to the pixel/uart/pwm classes.
Member
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more.
The WsExpanderPin class and its instances could sit as a component and be able to translate between different classes |
||
| public: | ||
| WsExpanderPin(uint16_t _pin) : ExpanderPin(_pin) {} | ||
| WsExpanderPin(ExpanderPin ep) | ||
| : ExpanderPin(ep.pin | (ep.address == 0x44 ? 0x100 : 0x200)) {} | ||
|
|
||
| size_t printTo(Print &p) const override { | ||
| size_t n = p.print("0x"); | ||
| n += p.print(address, HEX); | ||
| n += p.print("_"); | ||
| n += p.print(pin); | ||
| return n; | ||
| } | ||
| }; | ||
| #endif | ||
|
|
||
| /**************************************************************************/ | ||
|
|
@@ -322,7 +344,7 @@ class Wippersnapper { | |
| // Encodes a pin event message | ||
| bool | ||
| encodePinEvent(wippersnapper_signal_v1_CreateSignalRequest *outgoingSignalMsg, | ||
| uint8_t pinName, int pinVal); | ||
| uint16_t pinName, int pinVal); | ||
|
|
||
| // Pin configure message | ||
| bool configureDigitalPinReq(wippersnapper_pin_v1_ConfigurePinRequest *pinMsg); | ||
|
|
||
| Original file line number | Diff line number | Diff line change |
|---|---|---|
|
|
@@ -20,10 +20,10 @@ | |
|
|
||
| /** Holds data about a digital input pin */ | ||
| struct digitalInputPin { | ||
| uint8_t pinName; ///< Pin name | ||
| long period; ///< Timer interval, in millis, -1 if disabled. | ||
| long prvPeriod; ///< When timer was previously serviced, in millis | ||
| int prvPinVal; ///< Previous pin value | ||
| uint16_t pinName; ///< Pin name | ||
|
Member
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. This change is throughout the API, is it necessary? What's the reason for the change?
Member
Author
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. The idea is to move away from uint8_t pin numbers and towards uint16_t pin numbers. 0-255 (uint8_t) are effectively then reserved for the main boards pins (including any bsp related higher ranges like the LED on PicoW controlled via CYW43 wifi coprocessor at "virtual" pin 64). Ranges above 255 are expander pins, be those defined by the BSP (Nesso) or ourselves (Memento). Mainly it was an easy way to switch code path for expander pins, and between each expander, with similar logic to the ExpanderPins constructor:
Member
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Do we need this right now? Could we switch to uint16_t in API v2 codebase, instead?
Member
Author
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. We would instead then have to manually define every pin number translation in the firmware, to map a custom pin number within the uint8_t range (call it 240 and 241 for the two buttons) to the ExpanderPin i2c addresses of 0x44 and channels of 0 and 1 respectively. The board def would have two pins at 240 and 241 to keep within uint8_t.
Member
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more.
If you want to do this, it can potentially break the API and will need more testing. I'd like to see a separate PR opened for moving to |
||
| long period; ///< Timer interval, in millis, -1 if disabled. | ||
| long prvPeriod; ///< When timer was previously serviced, in millis | ||
| int prvPinVal; ///< Previous pin value | ||
| }; | ||
|
|
||
| // forward decl. | ||
|
|
@@ -42,28 +42,13 @@ class Wippersnapper_DigitalGPIO { | |
|
|
||
| void | ||
| initDigitalPin(wippersnapper_pin_v1_ConfigurePinRequest_Direction direction, | ||
| uint8_t pinName, float period, | ||
| uint16_t pinName, float period, | ||
| wippersnapper_pin_v1_ConfigurePinRequest_Pull pull); | ||
| void | ||
| deinitDigitalPin(wippersnapper_pin_v1_ConfigurePinRequest_Direction direction, | ||
| uint8_t pinName); | ||
|
|
||
| uint16_t pinName); | ||
| int digitalReadSvc(int pinName); | ||
| void digitalWriteSvc(uint8_t pinName, int pinValue); | ||
| #if defined(ARDUINO_ARDUINO_NESSO_N1) | ||
| // void | ||
| // initDigitalPin(wippersnapper_pin_v1_ConfigurePinRequest_Direction | ||
| // direction, | ||
| // ExpanderPin pinName, float period, | ||
| // wippersnapper_pin_v1_ConfigurePinRequest_Pull pull); | ||
| // void | ||
| // deinitDigitalPin(wippersnapper_pin_v1_ConfigurePinRequest_Direction | ||
| // direction, | ||
| // ExpanderPin pinName); | ||
|
|
||
| int digitalReadSvc(ExpanderPin pinName); | ||
| void digitalWriteSvc(ExpanderPin pinName, int pinValue); | ||
| #endif | ||
| void digitalWriteSvc(uint16_t pinName, int pinValue); | ||
| void processDigitalInputs(); | ||
|
|
||
| digitalInputPin *_digital_input_pins; /*!< Array of gpio pin objects */ | ||
|
|
||
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I don't feel
provision()is an appropriate place for this - how about within _boards.h ?There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yeah, that would probably be best.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Great, let's refactor it
Uh oh!
There was an error while loading. Please reload this page.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Ah, no I totally forgot, the reason I did it there was so the flash has initialised before the battery charger kicks in, instead of battery charger first and possibly causing a brownout for the flash begin / write afterwards.
Not sure that logic is sound to be fair, probably worth just shifting it out.