New platform: WeActStudio.BluePill-Plus-GD32 #2071
Draft
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.
Detailed description
bluepillplus
. In-tree platforms default to 72 MHz and do not leverage full potential of Gigadevices. Unmapping own SWJ-DP is not always acceptable, andstlink
pinout is just weird.I do not expect this to be merged, because in-tree
-Dprobe=bluepill
already does provide some functionality. I do not implement vanilla PC13 bluepills, it's impossible for me to discern these from bluepillplus. This platform has feature parity withblackpill-f4
, except I'm dissatisfied with its USBOTG-FS DWC2 bugs.Choice of USART for Aux and SWO was influenced by existing 2x128 aux_serial DMA ping-pong buffers, which are insufficient for 1024 byte Zmodem packet operation I need in DUT firmware. So SWO is faster for burst operation. When that's refactored, I'll swap them back such that 6Mbaud VCP is possible.
TODO: I'd like to use
platform_ident
to indicate autodetection results, and to leverage meson options to pick linkerscripts which influence flash size for drivers and RAM size for heap/buffers/SWO.Your checklist for this pull request
Closing issues