fix: increased UART Read Timeout

[AsCress]

Increases the UART Read timeout to 100ms in our main firmware.
@bessman With the rolling out of flutter 3.29, there have been quite some architectural changes, on how dart code is executed on Android and iOS.
One of them is execution of dart code on the main thread of the running application (which makes it a tiny bit slower, but slow enough to take slightly more than 1ms to transfer the command to the board, especially in debug mode).
In order to keep our app stable in flutter, we would most definitely require a timeout increase.

Summary by Sourcery

Bug Fixes:

• Increased the UART read timeout to 100ms to improve stability with newer Flutter versions that execute Dart code on the main thread, potentially causing delays in command transfer, especially in debug mode. The watchdog timer is also cleared during the timeout period to prevent unexpected resets while waiting for data from the UART

[sourcery-ai]

Reviewer's Guide by Sourcery

The UART read timeout has been increased from 1ms to 100ms to address timing issues introduced by recent Flutter architectural changes. The timeout variable type was changed to uint32_t to accommodate the larger timeout value. A watchdog timer clear call was added to the UART_Read while loop.

No diagrams generated as the changes look simple and do not need a visual representation.

File-Level Changes

Change	Details	Files
Increased the UART read timeout from 1ms to 100ms to accommodate changes in Flutter's architecture that have increased command transfer times, especially in debug mode.	Increased UART_READ_TIMEOUT from (FCY / 1000) to (FCY / 10UL). Changed the timeout variable type from uint16_t to uint32_t. Added a watchdog timer clear call inside the UART_Read while loop.	src/bus/uart/uart.c

---

Tips and commands

Interacting with Sourcery

• Trigger a new review: Comment @sourcery-ai review on the pull request.
• Continue discussions: Reply directly to Sourcery's review comments.
• Generate a GitHub issue from a review comment: Ask Sourcery to create an
  issue from a review comment by replying to it. You can also reply to a
  review comment with @sourcery-ai issue to create an issue from it.
• Generate a pull request title: Write @sourcery-ai anywhere in the pull
  request title to generate a title at any time. You can also comment
  @sourcery-ai title on the pull request to (re-)generate the title at any time.
• Generate a pull request summary: Write @sourcery-ai summary anywhere in
  the pull request body to generate a PR summary at any time exactly where you
  want it. You can also comment @sourcery-ai summary on the pull request to
  (re-)generate the summary at any time.
• Generate reviewer's guide: Comment @sourcery-ai guide on the pull
  request to (re-)generate the reviewer's guide at any time.
• Resolve all Sourcery comments: Comment @sourcery-ai resolve on the
  pull request to resolve all Sourcery comments. Useful if you've already
  addressed all the comments and don't want to see them anymore.
• Dismiss all Sourcery reviews: Comment @sourcery-ai dismiss on the pull
  request to dismiss all existing Sourcery reviews. Especially useful if you
  want to start fresh with a new review - don't forget to comment
  @sourcery-ai review to trigger a new review!
• Generate a plan of action for an issue: Comment @sourcery-ai plan on
  an issue to generate a plan of action for it.

Customizing Your Experience

Access your dashboard to:

• Enable or disable review features such as the Sourcery-generated pull request
  summary, the reviewer's guide, and others.
• Change the review language.
• Add, remove or edit custom review instructions.
• Adjust other review settings.

Getting Help

• Contact our support team for questions or feedback.
• Visit our documentation for detailed guides and information.
• Keep in touch with the Sourcery team by following us on X/Twitter, LinkedIn or GitHub.

[sourcery-ai]

Hey @AsCress - I've reviewed your changes - here's some feedback:

Overall Comments:

• Consider adding a comment explaining why the timeout is defined in terms of FCY.
• Casting FCY to an unsigned long (UL) is good practice to avoid potential overflow issues.

Here's what I looked at during the review

• 🟢 General issues: all looks good
• 🟢 Security: all looks good
• 🟢 Testing: all looks good
• 🟢 Complexity: all looks good
• 🟢 Documentation: all looks good

---

Sourcery is free for open source - if you like our reviews please consider sharing them ✨

• X
• Mastodon
• LinkedIn
• Facebook

_{Help me be more useful! Please click 👍 or 👎 on each comment and I'll use the feedback to improve your reviews.}

[AsCress]

@bessman This PR now contains the commit 37f14a8 cherry-picked from the esp-01 branch.

[AsCress]

@bessman Strangely, the commit HASH is still different.
Is it not possible to cherry-pick the exact same commit, with the same commit HASH to another branch through
git cherry-pick <HASH> ?
I found this on the web:

[bessman]

Ah, right, that commit is on top of 6b6ce08, which we don't want in main. Then the hashes can't be the same, indeed. Then we'll merge as is.