mirror of
https://github.com/tinygo-org/tinygo.git
synced 2026-08-31 17:59:03 +00:00
b420a8be1798f3bf9d3df1675ffd3e1a1b54329d
2 Commits
| Author | SHA1 | Message | Date | |
|---|---|---|---|---|
|
|
b420a8be17 |
Puya PY32F MCU support (#5106)
* pinout yamls removed * machine: implement default UART pin configuration for Embedfire boards * flash command moved to chip level so VS Code plugin can select bare chip * machine: add support for alternate pin mode configuration * add build targets for embedfire on py32 * add support for embedfire target in GNUmakefile for py32 * lib/py32-svd: remove duplicate DBGMCU.IDCODE CODE field Update submodule to fix duplicate SetIDCODE/GetIDCODE method declarations in the generated py32f002bxx.go device file. * update subproject commit reference in py32-svd * refactor: update CPU frequency handling in machine and runtime packages * refactor: replace ConfigureUARTPin function with direct pin configuration in UART setup * SetAltFunc documentation for GPIO pin alternate functions * refactor: improve UART write and flush error handling with timeout * machine/py32: generalize UART driver to any USART Add a per-instance setup func to the UART type so the driver is no longer hardwired to USART1. DefaultUART stays USART1; add UART2 (USART2) in a separately build-tagged file since py32f002x parts lack USART2. RX IRQ handlers reference runtime-assigned vars to break the init cycle, and setup is assigned in the var initializer so it runs before InitSerial. Add the py32f003_32k_4k target (32K flash / 4K RAM). * Add canonical PY32F002, F003, and F030 density targets Use CMSIS/pyocd device names for target files and build tags. Add all F003 and F030 densities plus F002A/B, correct F002B to 24K flash and its own startup file, fix the F030x8 pyocd target, and update Embedfire inheritance. * Add targets for all PY32 CMSIS devices * Support all PY32 register layout variants * machine/py32: use generated register definitions * machine/py32: fix alternate-function documentation * machine/py32: report the configured CPU frequency * machine/py32: use unsafe.Add for GPIO ports * machine/py32: bound and yield UART polling * machine/py32: configure UART pins from UARTConfig * build: use the current PY32 SVD repository URL * test: cover PY32 UART register layouts * machine/py32: restore dynamic CPU frequency tracking * machine/py32: share the USART TX-ready bit * targets/py32: scale system stacks with RAM * machine/py32: keep clock state internal * targets/py32: normalize generated metadata * machine/py32: normalize GPIO configuration * machine/py32: fix T020 UART setup * machine/py32: reduce clock variant files * machine/py32: clean up UART variants * machine/py32: decouple UART clock capability * lib/py32-svd: use organization repository * runtime/py32: name 24MHz HSI encodings * machine/py32: derive startup clock from capability * machine/py32: use generated USART clock mask * machine/py32: name T020 8-bit UART mode * ci: include PY32 in sharded smoke tests * runtime: remove PY32 HSI frequency workaround |
||
|
|
a213d9ae46 |
ci: run the full smoke test once, and split the GNUmakefile (#5616)
* GNUmakefile: split into topic files in make/ The GNUmakefile had 1295 lines and mixed build configuration, LLVM bootstrapping, device generation, four test suites, the smoke tests, release packaging, and lint tools. The smoke tests alone were 500 lines. Move each part into its own file in make/ and include them from GNUmakefile. config.mk must be included first because the other files use its variables in immediate assignments and conditionals. There is no change in behavior. The parsed make database is identical for the default build and for ASSERT=1, STATIC=1, XTENSA=0, STM32=0, WASM=0, and CROSS=aarch64-linux-gnu, except for MAKEFILE_LIST and the .PHONY list, which now also includes targets that were phony but not declared. The Dockerfile copies GNUmakefile alone before it builds LLVM, to keep that layer independent of the source tree. It must copy make/ too. * make/smoketest.mk: split into groups and add smoketest-quick The smoke test was one recipe of about 500 lines with 236 builds that always ran in sequence. Split it at the group boundaries that were already there, so that: - `make -j smoketest` builds the groups in parallel. A full run goes from 325 to 91 seconds on a 32 core machine. - CI can shard the groups across runners. Each group writes to its own name in build/smoke/, because all builds wrote to test.hex before and would overwrite each other in a parallel build. The output extension selects the format, so it stays per line. Add smoketest-quick, which builds one board for each processor architecture. The full smoke test answers "can TinyGo build for every board", which does not depend on the host OS, so it only needs to run on one OS. The other jobs use smoketest-quick. The comment above the esp32c3 group had 4 spaces of indentation instead of a tab. That was harmless in the middle of a recipe, but it is now the first line of a group, where it would stop the recipe from starting. The set of build commands is unchanged for the default flags and for XTENSA=0, STM32=0, and WASM=0. All 226 checksums are the same as before, for a sequential build and for `make -j16`. * ci: run the full smoke test once, on Linux only The smoke test ran six times for each push: twice on Linux, twice on macOS, once on Windows, and once in the compatibility test. Together that was about 97 minutes of the CI time. The smoke test checks that TinyGo can build a binary for each board. That does not depend on the host OS. The only part that does is one build behind a Windows check. Add a smoketest-linux job that runs the full set, split across four runners that use the tarball from the build-linux job. The groups are balanced with the measured build time of each group. Remove the full smoke test from test-linux-build, which the new job replaces, and use smoketest-quick for the other four jobs. Expected result: about 55 to 39 minutes for the slowest workflow, and about 97 to 35 minutes of total smoke test time. * make/smoketest.mk: build nintendoswitch in smoketest-quick It is the only target that uses the aarch64 LLVM triple. With it, smoketest-quick covers all 13 triples that the full smoke test uses. |