boards/stm32: fix CAN bit timings for boards

[raiden00pl]

Summary

• boards/nucleo-f722ze: fix CAN bit timings
• boards/nucleo-g431rb: fix CAN bit timings and unify bitrate
• boards/nucleo-f302r8: fix CAN bit timings
• boards/nucleo-f446re: fix CAN bit timings
• boards/b-g431b-esc1: fix CAN bit timings
• boards/nucleo-f303re: fix CAN bit timings

Impact

all updated CAN configurations are now compatible with each other

Testing

different board combinations in the CAN network.

here example with b-g431rb-esc [1] nucleo-g431rb [2] and nucleo-f302r8:

[1]
nsh> cansend can0 123#DEADBEEF

[2]
nsh> candump can0
  can0  123   [4]  DE AD BE EF
  
[3]
nsh> candump can0
  can0  123   [4]  DE AD BE EF

[nuttxpr]

[Experimental Bot, please feedback here]

Yes, this PR appears to meet the NuttX requirements, although it could be more thorough.

Strengths:

• Clear Summary of Changes: The functional area (CAN bit timings) and affected boards are clearly listed. The "why" (fix) is implied, but could be stated explicitly (e.g., "fix incorrect CAN bit timings to enable interoperability").
• Impact Description: The impact on the user (interoperability) is stated concisely.
• Testing Evidence: The testing demonstrates interoperability between several boards, which directly addresses the stated fix.

Weaknesses:

• Missing Detail in Summary: How the change works is missing. A brief explanation of the nature of the bit timing corrections would be helpful. Mentioning related issues would also strengthen the context.
• Incomplete Impact Assessment: The impact sections for build, hardware, documentation, security, and compatibility are all implied as "NO" but not explicitly stated. While likely true, it's better to explicitly confirm these for completeness.
• Limited Testing Detail: While the test output demonstrates basic functionality, it lacks detail. Specify the OS, CPU, compiler used on the build host. For the targets, list the full board:config names. Include more details about the "different board combinations" tested. More comprehensive testing would include various message lengths and frequencies. "Before" logs are missing, although they might not be relevant if communication was previously impossible.

Recommendation:

While the core information is present, expanding on the weaknesses identified above would significantly improve the PR's clarity and ensure it fully meets the NuttX requirements.

[cederom]

Thanks @raiden00pl :-) Also thank you for providing runtime verification logs :-)