Skip to content

fix: rework STM32 and prepare it to support future STM32 products - #132

Open
MaJerle wants to merge 1 commit into
CANopenNode:masterfrom
MaJerle:rework-driver
Open

fix: rework STM32 and prepare it to support future STM32 products#132
MaJerle wants to merge 1 commit into
CANopenNode:masterfrom
MaJerle:rework-driver

Conversation

@MaJerle

@MaJerle MaJerle commented Sep 9, 2026

Copy link
Copy Markdown
Collaborator

Description

I've reworked the STM32 driver, with the intent to greatly separate the CAN and FDCAN implementation. The intent is that down the road we separate the CAN and FDCAN very specific things into its own files, while we keep common related to the STM32 and CanOpen in one place.

Some of the activity:

  • Create a common can_periph_handle_t that is typedef-ed to the CAN_ or FDCAN_HandleTypeDef HAL driver
  • Avoid using too many points with casting, replace with the macro
  • Replace the large switch statements for the DLC with the macro, to make a logic simple and easy to read
  • Simplify start/stop functions
  • Merge receive and transmit functions between CAN and FDCAN, since most of the things are shared, especially the TX completed callback logic
  • Added FDCAN bus-off logic. I suggest before we merge this PR, we check the implementation from another PR Implement manual bus off recovery #129. I can re-merge that PR back to this one and update my PR.
  • This driver does not implement the while loop for multiple reading as done here: Read pending messages from rx fifo #127 I suggest we merge the referenced PR first, I'll reintegrate the changes, and then we merge mine.
  • Fixed wrong MAILBOX numbers for CAN peripherals

Related PR that should be first merged

PR #129.
PR #127.

Type of Change

  • Bug fix
  • New feature
  • Breaking change
  • Documentation update
  • Refactor / code cleanup

Checklist

Please read CONTRIBUTING.md for details on how to run each of the checks below.

  • I have read CONTRIBUTING.md
  • I have tested the changes on a hardware
  • I have checked that the PR works for CAN and FDCAN devices, and explained if and why this rule deviates
  • I have performed the python3 scripts/build.py with success and no errors
  • I have checked and run clang-format with the repository input to format the code
  • I confirm I have completed all the applicable points above, or explained why they don't apply -> no hardware available right now

Additional Notes

The code has been independently review by the Claude Code, but it was not written by it.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants