Adding support to the button subsystem

[vrmay23]

nucleo-f767zi.zip
Note: Please adhere to Contributing Guidelines.

Summary

This is the pull request for the changes I've done for the stm32 nucleo-f767zi board, fixing the issues to use the buttons.
More information can be found at this ticket: #16097
The 'core' fix was include the /dev/buttons at stm32_bringup.c file but it was not the only change. I have also added here the same logic used on stm32f103c8t6 (blue pill).

This change was needed otherwise the buttons subsystems won't run at all.

Impact

Basically I've removed the internal board button by for GPIOs to be used by the user (for sure it is the main impact). At least now we can run the button subsystem.

Testing

I have test if for 1 week and although I've test it, and worked very well with 4 external push-buttons, there is 2 situation it is still not working.

A – When I added 8 buttons, only 5 worked. It is NOT a hardware problem since I tested all the buttons with an oscilloscope. It’s also not an issue with the GPIOs I chose, because when I mix the GPIOs but use only 4 buttons, everything works as expected. However, when I use 8 buttons, the GPIOs that were previously working stop working completely (again, I can see the pulses on the oscilloscope, but there’s no feedback on nsh).

B – Probably related to issue A.
When I add the built-in button along with the 4 external buttons, the built-in button stops working. But when I use only the built-in button, it works fine.

[nuttxpr]

[Experimental Bot, please feedback here]

No, this PR does not fully meet the NuttX requirements. Here's why and how to fix it:

Missing or Inadequate Information:

• Summary: While the summary explains the "why," it lacks sufficient detail on the "what" and "how." Be explicit about the files modified and the specific code changes made (e.g., "Added dev/buttons initialization to stm32_bringup.c, mirroring the logic from the stm32f103c8t6 board support.").
• Impact: The impact section is too vague.
  • User Impact: Instead of "removed the internal board button...to be used by the user," specify how the user will now configure and access the buttons. Will they need to modify any configuration files? Are there any new command-line options?
  • Build Impact: If no changes to the build process are required, explicitly state "NO."
  • Hardware Impact: Be specific about which STM32 board(s) are affected. Clearly state that the internal button is now disabled in software.
  • Documentation Impact: If documentation needs updating, state "YES" and briefly describe the required updates. If documentation is included in the PR, state "YES - Documentation updated to reflect the new button configuration."
  • Security Impact, Compatibility Impact, Anything Else: Explicitly state "NO" for each if not applicable.
• Testing:
  • Build Host(s) and Target(s): Provide detailed information about your development environment. Example: "Build Host: Linux (Ubuntu 22.04), x86_64, GCC 11.2.0. Target: STM32F767ZI, nucleo-f767zi config."
  • Testing Logs: The "before" and "after" logs are missing. Include the output of relevant commands (e.g., buttons command in NSH) demonstrating the button functionality before and after the changes. The logs should clearly show that the issue is fixed and that the buttons are working as intended. Also, include logs related to the issues you describe with 8 buttons and the built-in button not working correctly. This will help reviewers reproduce and understand the problems.

Unresolved Issues:

The testing section highlights significant unresolved problems. A PR should generally fix bugs, not introduce new ones. Before submitting, you must address the issues with 8 buttons and the built-in button. If you cannot resolve these issues, create separate issues on GitHub and reference them in the PR.

Recommendations:

1. Provide detailed information as requested above. Be explicit and thorough.
2. Fix the issues with 8 buttons and the built-in button or document them as separate issues.
3. Consider creating a separate branch for the changes related to the external buttons and the built-in button issue. This helps keep the PR focused on the core fix for the original dev/buttons problem.
4. Follow the NuttX coding style and commit message guidelines.

By addressing these points, you'll significantly improve the quality of your PR and increase the likelihood of it being accepted.

[acassis]

Remove extra empty lines

[acassis]

Don't use TAB for formatting text, use Space

[acassis]

Don't use TAB

[raiden00pl]

I don't know if this change fits upstream. By default the board supports only one button and this one button should be supported by upstream configuration.
With your change one-board button is not even supported.

If you wish to support additional buttons for this board, then they should be in addition to the on-board button (not replace it) and probably controlled via Kconfig options.