Extending PinMode to support MCUs with open-drain outputs? #155
Comments
|
I'm totally 👍 to add the |
obra
added a commit
to obra/ArduinoCore-API
that referenced
this issue
Sep 22, 2021
Not every MCU offers open drain pins, but some do. This change means that they'll no longer have to play games to implement an API-compatible pinMode() function that offers open drain. Fixes arduino#155 If you're reading this commit message because you need to add another pin mode to this enum, the hacky trivial workaround is to do something like this in your core: ``` // This typedef is used to extend the PinMode typedef enum // in the ArduinoAPI, since they don't have contants typedef enum { INPUT_ANALOG = 99 , // We assume that the Arduino core will never have 99 PinModes OUTPUT_OPEN_DRAIN // It'd be cleaner to be able to count the size of that enum } PinModeExtension; ``` Because PinMode is an enum and not a proper type, the compiler will let the user pass either a PinMode or a PinModeExtension to your pinMode() function, even though the signature is `void pinMode(pin_size_t ulPin, PinMode ulMode)`
|
Done as #157, with copious notes for the next person who needs to work around lack of some pin mode in the commit message ;) Based on the implementation of Analog pins in the Arduino world, I'm guessing that a standard "INPUT_ANALOG" PinMode is not of general interest? |
obra
added a commit
to obra/ArduinoCore-API
that referenced
this issue
Sep 30, 2021
Not every MCU offers open drain pins, but some do. This change means that they'll no longer have to play games to implement an API-compatible pinMode() function that offers open drain. Fixes arduino#155 If you're reading this commit message because you need to add another pin mode to this enum, the hacky trivial workaround is to do something like this in your core: ``` // This typedef is used to extend the PinMode typedef enum // in the ArduinoAPI, since they don't have contants typedef enum { INPUT_ANALOG = 99 , // We assume that the Arduino core will never have 99 PinModes OUTPUT_OPEN_DRAIN // It'd be cleaner to be able to count the size of that enum } PinModeExtension; ``` Because PinMode is an enum and not a proper type, the compiler will let the user pass either a PinMode or a PinModeExtension to your pinMode() function, even though the signature is `void pinMode(pin_size_t ulPin, PinMode ulMode)`
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
I'm in the process of collaborating with some other folks to build a new Arduino port for GigaDevice's GD32 chips[1]. We're attempting to build on top of ArduinoCore-API. In general, It's so much better than the old way of doing things. One thing we're running into is how to handle gaps in the PinMode enum.
Specifically, we're short an
OUTPUT_OPENDRAINinPinModeWould a PR that adds a new
OUPUT_OPENDRAIN = 0x4to the PinMode definition be welcome? If not, is there an alternate "Arduinoish" way to build the user-facing API to set a pin as an open-drain output?[1] https://github.com/CommunityGD32Cores/ArduinoCore-GD32
Thanks!
The text was updated successfully, but these errors were encountered: