Skip to content
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

fix(HardwareSerial): fix pin remapping in begin() on master #10379

Merged
merged 1 commit into from
Oct 1, 2024

Conversation

pillo79
Copy link
Contributor

@pillo79 pillo79 commented Sep 26, 2024

Description of Change

The pin remapping functions have to be called as early as possible in the HardwareSerial::begin() function, to immediately convert the input parameters from the user to the GPIO numbers used everywhere in the core. However, there is code that assigns GPIO numbers to txPin/rxPin before the call to digitalPinToGPIONumber.

This issue has always been dormant since the introduction of pin remapping in 9b4622d, but is evident on 3.x due to the full pinmuxing support that actually detaches pins - disabling the default Serial0 pins.

Move the pin remapping function calls earlier in the begin() function to fix this issue.

Tests scenarios

Tested on the Nano ESP32 - Serial0.begin(115200) was selecting "random" pins instead of the expected defaults.

Related links

See also #10380 for the same fix on 2.x.

The pin remapping functions have to be called as early as possible in
the begin() function, to immediately convert the input parameters to the
GPIO numbers used everywhere in the core.

This issue has always been dormant since the introduction of pin
remapping in 2.x via 9b4622d, but was exposed by the proper pin muxing
support that is present in the 3.x core.

Move the pin remapping function calls earlier in the begin() function to
fix this issue.
Copy link
Contributor

github-actions bot commented Sep 26, 2024

Warnings
⚠️

Some issues found for the commit messages in this PR:

  • the commit message "fix(HardwareSerial): fix pin remapping in begin()":
    • scope/component should be lowercase without whitespace, allowed special characters are _ / . , * - .

Please fix these commit messages - here are some basic tips:

  • follow Conventional Commits style
  • correct format of commit message should be: <type/action>(<scope/component>): <summary>, for example fix(esp32): Fixed startup timeout issue
  • allowed types are: change,ci,docs,feat,fix,refactor,remove,revert,test
  • sufficiently descriptive message summary should be between 20 to 72 characters and start with upper case letter
  • avoid Jira references in commit messages (unavailable/irrelevant for our customers)

TIP: Install pre-commit hooks and run this check when committing (uses the Conventional Precommit Linter).

👋 Hello pillo79, we appreciate your contribution to this project!


Click to see more instructions ...


This automated output is generated by the PR linter DangerJS, which checks if your Pull Request meets the project's requirements and helps you fix potential issues.

DangerJS is triggered with each push event to a Pull Request and modify the contents of this comment.

Please consider the following:
- Danger mainly focuses on the PR structure and formatting and can't understand the meaning behind your code or changes.
- Danger is not a substitute for human code reviews; it's still important to request a code review from your colleagues.
- Resolve all warnings (⚠️ ) before requesting a review from human reviewers - they will appreciate it.
- To manually retry these Danger checks, please navigate to the Actions tab and re-run last Danger workflow.

Review and merge process you can expect ...


We do welcome contributions in the form of bug reports, feature requests and pull requests.

1. An internal issue has been created for the PR, we assign it to the relevant engineer.
2. They review the PR and either approve it or ask you for changes or clarifications.
3. Once the GitHub PR is approved we do the final review, collect approvals from core owners and make sure all the automated tests are passing.
- At this point we may do some adjustments to the proposed change, or extend it by adding tests or documentation.
4. If the change is approved and passes the tests it is merged into the default branch.

Generated by 🚫 dangerJS against 2d6fcef

Copy link
Contributor

github-actions bot commented Sep 26, 2024

Test Results

 56 files   - 83   56 suites   - 83   4m 12s ⏱️ - 18m 4s
 21 tests  - 13   21 ✅ ± 0  0 💤 ±0  0 ❌ ±0 
135 runs   - 98  135 ✅  - 30  0 💤 ±0  0 ❌ ±0 

Results for commit 2d6fcef. ± Comparison against base commit b05f18d.

This pull request removes 13 tests.
performance.coremark.test_coremark ‑ test_coremark
performance.fibonacci.test_fibonacci ‑ test_fibonacci
performance.psramspeed.test_psramspeed ‑ test_psramspeed
performance.ramspeed.test_ramspeed ‑ test_ramspeed
performance.superpi.test_superpi ‑ test_superpi
test_touch_errors
test_touch_interrtupt
test_touch_read
validation.periman.test_periman ‑ test_periman
validation.timer.test_timer ‑ test_timer
…

♻️ This comment has been updated with latest results.

@pillo79 pillo79 marked this pull request as ready for review September 26, 2024 16:17
@me-no-dev me-no-dev requested a review from SuGlider September 26, 2024 18:50
@me-no-dev me-no-dev added the Status: Pending Merge Pull Request is ready to be merged label Oct 1, 2024
@me-no-dev me-no-dev merged commit a4cbdaf into espressif:master Oct 1, 2024
73 checks passed
P-R-O-C-H-Y pushed a commit to P-R-O-C-H-Y/arduino-esp32 that referenced this pull request Oct 2, 2024
The pin remapping functions have to be called as early as possible in
the begin() function, to immediately convert the input parameters to the
GPIO numbers used everywhere in the core.

This issue has always been dormant since the introduction of pin
remapping in 2.x via 9b4622d, but was exposed by the proper pin muxing
support that is present in the 3.x core.

Move the pin remapping function calls earlier in the begin() function to
fix this issue.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Status: Pending Merge Pull Request is ready to be merged
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants