stm32f? r? t6 core board [double happiness] v0.2. F103, F334, F446, CH32V.


Some non-essential components are not installed in the actual photos.
Each IO leads to two pin headers, which is [double] (believe me, this is very useful).
The GPIO order is rearranged into a continuous straight line every 8 bits, which is [Happy].
Hence the name [Double Happiness].
Theoretically compatible with stm32f series suffix such as r? All models of t6's entire series of lqfp64 packages can be selected on demand (not all have been tested, only the f103 series has been tested and available). To use the f4 series, you need to disconnect the jumpers R51 and R52 (0R resistors) and install C28. No modifications are required when using the f1 series.

Theoretically compatible with CH32V and other pin-compatible microcontrollers (not actually tested).
Except for the IO occupied by the crystal oscillator, all other IO pins are led out, and each pin is led out to two connected pin headers. The four 20*2 rows of needles in the middle circle are all connected by two needles in the inner and outer directions. After one of the two pins is occupied, you can use an oscilloscope, multimeter or on-board LED to observe the level of this IO on the other pin to facilitate debugging the program. This is a design based on my experience. It has been tested that this design can bring great convenience.
There are a small number of commonly used peripheral devices on the board (LED, buttons, rotary encoder, buzzer, EEPROM, CH340, infrared receiver tube, infrared transmitter tube, WS2812, DS18B20&DHT11, etc.), but all peripheral devices are not fixedly connected to the GPIO to avoid There is a conflict when IO is used elsewhere (a pitfall encountered when using commercially available development boards, so improvements were made). Instead, lead out the pin header and use Dupont lines to connect to the GPIO pin header as needed.
The buzzer circuit is compatible with active buzzers and passive buzzers, choose as needed.
The button uses a two-pin direct plug-in package.
Onboard boot mode DIP switch and reset button.
Onboard ch340 USB to UART, USB TypeC interface (USB1).
The UART1 of the microcontroller and the UART of the CH340 are not connected on the board (this is also a pitfall encountered when using commercially available development boards, so improvements were made). When connection is required, use jumper caps or Dupont wires to connect two adjacent sets of pin headers. It is convenient to connect the UART port to other places without conflict. The silkscreen on the side has pinout notes.

Use high-precision active crystal oscillator as the main clock to increase reliability in high-speed signal applications. (Aside from the topic, the sequelae of playing HIFI metaphysics, I want to use high-precision active crystal oscillators wherever there is a crystal oscillator)
The USB interface (PA11, PA12) of the microcontroller itself is also led to the USB TypeC interface (USB2) (but I will not write The USB program has therefore not been tested). All USB traces have differential impedance matching. Where the impedance changes due to the trace passing through the pin header, a piece of copper is added based on feeling to compensate for some impedance.
Both USB TypeC can supply power to the development board, and can also be connected to the power pin header for power supply. The power header can also provide power to other external modules. There is a pin header for the SWD downloader interface.
A Schottky diode (D2) is connected in reverse parallel to the power supply to prevent reverse connection. If it is reversely connected, the power supply will be short-circuited to prevent reverse voltage from being added to the chip (use a power supply with short-circuit protection, most switching power supplies, DCDC modules and three-terminal voltage stabilization are available). Schottky diodes must be used, and the conduction voltage drop is lower than the reverse conduction voltage drop of the chip to be effective. There will be no impact if the connection is normal. In actual testing, this can save me many times when I feel groggy after staying up for four days and three nights in an electronic competition.
Some interesting aspects of the design are improvements made based on my superficial experience: 1: After looking at the pin diagram of stm32, I know that for the sake of "scalability", st arranges the GPIO pins in a very chaotic order. , the lower 8 bits of a group of GPIO ports are even scattered in three directions of the chip, which is very confusing. It is not like every 8 bits are arranged in a straight line like the 8051 microcontroller. Most of the development boards sold on the market lead out the pin headers according to the original order of the chip, inheriting the confusion, which makes it very inconvenient to use many peripheral devices with parallel data interfaces, such as screens with RGB565 interfaces, high-speed ADCs with 12-bit parallel output, etc. If If you want to send/read the entire number from 16 bits of a GPIO port in the code at once, then the hardware must find where the various pins of the GPIO port are scattered on the development board, and then use multiple The 1p Dupont cable is inserted one by one, which is very messy, easy to make mistakes, and easy to loosen. If you want to use the entire 8p Dupont cable to plug in the whole row and connect it on the hardware, then the software will need complex shifts, AND or operations to convert a number. Splitting and combining into multiple variables and then outputting/reading multiple times on multiple sets of GPIO ports is also confusing, error-prone and wastes running speed, which is very "brain congestion". My design is to solve this problem by routing the lines on the PCB and rearranging the GPIO pins into a continuous linear arrangement of 8 bits. P0~P7 of each group of GPIOx are in one row, and P8~P15 are in one row. When using it, you can follow the usage habits of 8051 microcontroller. Use 8P Dupont wires to connect peripheral devices in a row on the hardware. The entire number can be output at once in the code, no more "brain congestion", happy. 2: Each pin of the microcontroller has two pin headers, which is convenient for measurement and observation. When one pin is plugged in, use an oscilloscope, multimeter or LED to observe the other pin. A bus that facilitates multiplexing, connecting multiple peripheral devices to one pin. 3: A row of 16 LED lights, combined with the previous feature, can observe the IO status with the naked eye. Create observable phenomena in unobservable programs, such as assigning register values to pins and observing the register values with the naked eye to facilitate debugging.
At the same time, there are 8 pull-up resistors that share the pin header with the LED. When a pull-up resistor is needed, you can use a DuPont wire to connect it from here. 4: The analog power supply is powered by a separate LDO regulator, and a separate analog ground is connected to the general ground with a 0r resistor. Optimizing signal integrity based on feeling, laying copper on a relatively complete ground plane in a large area, most signal lines have a complete ground plane at the bottom, and the ground return path from the ground plane to the decoupling capacitor is relatively straight and smooth.
It has been verified that it is available. The previous version of this design (V0.1) was used in my 2021 e-sports competition and played an important role. After a small amount of improvements, the V0.2 version was formed.

Known BUG: The SD card holder is placed in the wrong direction, with the opening facing inward, and the card insertion position is blocked and cannot be used. Just don't install it, other functions will not be affected.
There may be undiscovered bugs, feedback is welcome.