Skip to content

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

Merged
merged 5 commits into from
May 3, 2017

Conversation

kegilbert
Copy link
Contributor

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

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
Copy link
Contributor Author

@kegilbert kegilbert Apr 28, 2017

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.

Copy link
Contributor

@0xc0170 0xc0170 May 2, 2017

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

Copy link
Contributor

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...

@bridadan
Copy link
Contributor

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!

@bridadan bridadan self-assigned this Apr 28, 2017
Copy link
Contributor

@0xc0170 0xc0170 left a 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
Copy link
Contributor

@0xc0170 0xc0170 May 2, 2017

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

Copy link
Contributor

@bridadan bridadan left a 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,
Copy link
Contributor

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?

Copy link
Contributor Author

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,
Copy link
Contributor

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.

Copy link
Contributor Author

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 */
Copy link
Contributor

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.

Copy link
Contributor Author

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,
Copy link
Contributor

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,
Copy link
Contributor

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,
Copy link
Contributor

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 😄

@0xc0170
Copy link
Contributor

0xc0170 commented May 3, 2017

/morph test

@mbed-bot
Copy link

mbed-bot commented May 3, 2017

Result: SUCCESS

Your command has finished executing! Here's what you wrote!

/morph test

Output

mbed Build Number: 138

All builds and test passed!

@theotherjimmy
Copy link
Contributor

Looks good. No outstanding problems. Merging.

@sg-
Copy link
Contributor

sg- commented May 3, 2017

Seems OK but where are the docs and guidelines so the next 100 boards coming dont skip adding this?

@bridadan
Copy link
Contributor

bridadan commented May 3, 2017

@sg- good point. Where is the appropriate place to put docs/guidelines for mbed OS?

@sg-
Copy link
Contributor

sg- commented May 3, 2017

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.

@geky
Copy link
Contributor

geky commented May 3, 2017

@sg- ¯\_(ツ)_/¯

@theotherjimmy
Copy link
Contributor

Poring guide is a good start. https://docs.mbed.com/docs/mbed-os-handbook/en/latest/advanced/porting_guide/

@theotherjimmy
Copy link
Contributor

@sg- that's the /shrug command in slack.

exmachina-auto-deployer pushed a commit to exmachina-dev/mbed-os that referenced this pull request May 16, 2017
…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
JanneKiiskila pushed a commit to JanneKiiskila/mbed-os that referenced this pull request Aug 22, 2017
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.
adbridge pushed a commit that referenced this pull request Sep 12, 2017
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.
adbridge pushed a commit that referenced this pull request Sep 13, 2017
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.
aisair pushed a commit to aisair/mbed that referenced this pull request Apr 30, 2024
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
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

8 participants