Skip to content

Adjustments for latest STM32 data#176

Draft
eduardosm wants to merge 1 commit into
LibrePCB:masterfrom
eduardosm:stm32-update
Draft

Adjustments for latest STM32 data#176
eduardosm wants to merge 1 commit into
LibrePCB:masterfrom
eduardosm:stm32-update

Conversation

@eduardosm

Copy link
Copy Markdown
Contributor

New data in LibrePCB/stm-db#7

There are breaking changes.

For example, in STM32F100V[CDE]Tx two "IO" pins became "MonoIO", which means different symbol with different UUID.

Before:
old

After:
new

@ubruhin

ubruhin commented Jun 29, 2026

Copy link
Copy Markdown
Member

There are breaking changes.

That is not an option. We have to be 100% sure there are no breaking changes.

For example, in STM32F100V[CDE]Tx two "IO" pins became "MonoIO", which means different symbol with different UUID.

To me, the new symbol looks better, but the old one would also be fine to keep, to avoid messing up existing schematics. So both options would be fine for me. But in any way, the change has to be non-breaking.

Possible options:

  • (Manually) edit the UUID cache to make sure new pins keep the old UUID
  • Manual "hacks" in the generator to patch specific parts to restore their old properties, avoiding new UUIDs
  • Blacklist existing library elements which would break, keeping the old files as-is (not nice, but may be OK especially for legacy parts)
  • Other ideas?

I think in the end, it also depends on how many library elements are affected by breaking changes. For just a few parts, a manual, hacky way could be fine.

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

Labels

None yet

Development

Successfully merging this pull request may close these issues.

2 participants