-
Notifications
You must be signed in to change notification settings - Fork 3k
Add consistent button names across targets #4249
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
Conversation
Revert HRM1017 file source deletion Added in small comment next to additions Added mapping to BTN-labelled switches Added mapping to USER_BUTTON-labelled switches Undo incorrect mapping to SWIO pin in NORDIC target
@@ -104,6 +104,8 @@ typedef enum { | |||
LED3 = PB_3, | |||
LED4 = PB_3, | |||
USER_BUTTON = 0x20, // no user button on the board |
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.
This switch is specified as not existing, left the new button map in but could also pull it out since it's not really needed.
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.
@bcostm Is this used in the apps somewhere? I assume as all of ST are defining USER_BUTTON
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.
There is no user button on the small Nucleo 32 pins boards like this one. This definition was probably left by mistake...
This looks great, nice work @kegilbert! I will do a more in depth review in future. @sg- or @0xc0170 may just want to take a look at this since it touches so many targets. Can't imagine this is too controversial though! |
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.
Plenty targets define USER_BUTTON, or USER_BUTTONx. BUTTONx schema sounds fine to me. What is a requirement - a target might not have any button ? How this can be tested?
@@ -104,6 +104,8 @@ typedef enum { | |||
LED3 = PB_3, | |||
LED4 = PB_3, | |||
USER_BUTTON = 0x20, // no user button on the board |
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.
@bcostm Is this used in the apps somewhere? I assume as all of ST are defining USER_BUTTON
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 caught a few missing definitions, but honestly other than that everything looks good to me!
// Standardized button names | ||
BUTTON1 = SW1, | ||
BUTTON2 = SW2, | ||
BUTTON3 = SW3, |
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.
This is an interesting one actually, since SW2
and SW3
aren't actually connected. In this case I'd say let's not add any BUTTONx
definitions. I'd rather this fail at compile time. What do you think @0xc0170?
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.
Updated
// Standardized button names | ||
BUTTON1 = SW1, | ||
BUTTON2 = SW2, | ||
BUTTON3 = SW3, |
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.
Same here regarding not connected buttons.
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.
Updated
@@ -128,6 +128,8 @@ typedef enum { | |||
LED_YELLOW = GPIO6, | |||
LED_BLUE = GPIO5, | |||
USER_BUTTON = GPIO7, /*NEW connection on NCS36510-RF Rev 1.1 - Alias of SW1 */ | |||
// Standardized button names | |||
BUTTON1 = USER_BUTTON, | |||
SW1 = GPIO7, /*NEW connection on NCS36510-RF Rev 1.1 */ | |||
SW2 = GPIO10, /*NEW connection on NCS36510-RF Rev 1.1 */ |
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.
Looks like SW2
was missed.
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.
Interesting, that was a failure on my script end I'll add those in. Good catch!
@@ -142,6 +142,8 @@ typedef enum { | |||
JOYSTICK_UP = PA_3, | |||
JOYSTICK_DOWN = PA_5, | |||
USER_BUTTON = JOYSTICK_CENTER, | |||
// Standardized button names | |||
BUTTON1 = USER_BUTTON, |
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.
Huh, had never considered how to handle joysticks! Could potentially even add BUTTON2-5
for each direction, though I think ST could always add that if they wanted to. I think you've handled it nicely here.
|
||
// Standardized button names | ||
BUTTON1 = USER_BUTTON, | ||
BUTTON2 = SW1, |
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.
Still not quite right, USER_BUTTON
and SW1
both map to GPIO7
. I would think the correct definitions would be as follows:
BUTTON1 = SW1,
BUTTON2 = SW2,
// Standardized button names | ||
BUTTON1 = USER_BUTTON, | ||
BUTTON2 = JOYSTICK_LEFT, | ||
BUTTON3 = JOYSTICK_RIGH, |
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.
Travis caught a typo here. This should be BUTTON3 = JOYSTICK_RIGHT,
, not BUTTON3 = JOYSTICK_RIGH,
. Looks like a T
was dropped 😄
/morph test |
Result: SUCCESSYour command has finished executing! Here's what you wrote!
OutputAll builds and test passed! |
Looks good. No outstanding problems. Merging. |
Seems OK but where are the docs and guidelines so the next 100 boards coming dont skip adding this? |
@sg- good point. Where is the appropriate place to put docs/guidelines for mbed OS? |
How does @geky make the cool ascii shrug character?!? I'd suggest getting with @AnotherButler to find a place or create one if it doesnt exist. Probably in the porting guide around a section that describes what should be in PinNames.h and if there should be an extension (macros say) where an alias is created. Eventually PinNames needs to be broken apart for MCU and board and I think this could be the tipping point to put together. @theotherjimmy should have thoughts on this with current work around targets and such. |
@sg- ¯\_(ツ)_/¯ |
Poring guide is a good start. https://docs.mbed.com/docs/mbed-os-handbook/en/latest/advanced/porting_guide/ |
@sg- that's the |
…lwip_broadcast Release mbed OS 5.4.5 and mbed lib v142 Ports for Upcoming Targets Fixes and Changes 4059: [Silicon Labs] Rename targets ARMmbed#4059 4115: Support for Qt Creator Generic project export and associated Makefile ARMmbed#4115 3915: Feature vscode ARMmbed#3915 4205: tests: race test - add not supported for single threaded env ARMmbed#4205 4187: [NCS36510] Reduce default heap size allocated by IAR to 1/4 of RAM ARMmbed#4187 4145: test - add nanostack to examples.json file ARMmbed#4145 4093: Update.py: New feature - update a branch instead of a fork, plus general improvements. ARMmbed#4093 4225: fixed missing device_name for xDot and removed progen ARMmbed#4225 4243: Config: config header file should contain new line ARMmbed#4243 4251: Fix C++11 build error w/ u-blox EVK-ODIN-W2 ARMmbed#4251 4236: STM32 Fixed warning related to __packed redefinition ARMmbed#4236 4224: Add `mbed new .` output to export ARMmbed#4224 4190: LPC4088: Enable LWIP feature ARMmbed#4190 4136: Error when bootloader is specified but does not exist ARMmbed#4136 3881: Remove debug links to printf/exit in NDEBUG builds ARMmbed#3881 4260: Inherit Xadow M0 target from LPC11U35_501 ARMmbed#4260 4249: Add consistent button names across targets ARMmbed#4249 4254: Removed unused variable in TARGET_NXP/lpc17_emac.c ARMmbed#4254
UBLOX_ODIN_EVK_W2 is missing the abstract button definitions originally introduced with PR ARMmbed#4249. Fix two tab to spaces issues on the go as well.
UBLOX_ODIN_EVK_W2 is missing the abstract button definitions originally introduced with PR #4249. Fix two tab to spaces issues on the go as well.
UBLOX_ODIN_EVK_W2 is missing the abstract button definitions originally introduced with PR #4249. Fix two tab to spaces issues on the go as well.
Ports for Upcoming Targets Fixes and Changes 4059: [Silicon Labs] Rename targets ARMmbed/mbed-os#4059 4187: [NCS36510] Reduce default heap size allocated by IAR to 1/4 of RAM ARMmbed/mbed-os#4187 4225: fixed missing device_name for xDot and removed progen ARMmbed/mbed-os#4225 4251: Fix C++11 build error w/ u-blox EVK-ODIN-W2 ARMmbed/mbed-os#4251 4236: STM32 Fixed warning related to __packed redefinition ARMmbed/mbed-os#4236 4190: LPC4088: Enable LWIP feature ARMmbed/mbed-os#4190 4260: Inherit Xadow M0 target from LPC11U35_501 ARMmbed/mbed-os#4260 4249: Add consistent button names across targets ARMmbed/mbed-os#4249
Description
There's currently no standardization across device switch names (as we do with LED names). This change maps currently existing switch mappings to a 1-indexed BUTTON name.
Related to #4032
Migrations
This change does not modify any existing applications, it only provides a new button name option.
Testing
Built without error and tested functionality on a K64F
Concerns
The DELTA_DFCM_NNN40 uses BUTTON0 as its mapped name already so I did not modify that file.
I did not touch all targets, I started with targets that defined switches in some way in PinNames.h through an automated script and may have missed some. Pushing forward with the bulk of what I have.
cc
@mray19027 @bridadan