Prevent redefine of HSE_VALUE if already user-overridden #1281
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Summary
Commercially sold Blackpill F411CE boards feature a 25MHz crystal, but if a board differs, HSE_VALUE can still be overridden while keeping everything else the same. With defensive programming like this, users of a custom (or differing commercially sold) board can easily use this variant with the same chip but just a slightly different crystal.
This PR fixes/implements the following bugs/features
HSE_VALUE
if neededThis topic e.g. appeared in https://community.platformio.org/t/env-blackpill-f401ce-consistently-creates-bad-binaries-that-hangs-the-mcu/18567 when a user was trying to use this Arduino core with a custom board with the 3 interchangable chips F401CC, F401CE and F411CE, all having a 25MHz crystal.
If a user would ever want to use a similiar setup but with a 25MHz crystal where the Arduino core uses the default 8MHz one or vice versa, it would be nice to always let the user redefine
HSE_VALUE
. With a simple#ifndef
check, that's implemented here.