Puya PY32F MCU support by burgrp · Pull Request #5106 · tinygo-org/tinygo

burgrp · 2025-12-02T15:35:12Z

Hi, this is a port of of Puya PY32F super-cheap micro-controllers.
There are two new boards and supported (available on Aliexpress) for PY32F030 and PY32002b.
PY32F030 and PY32002b are supported, PY32F002a and PY32F071 will follow.
It follows the STM32 SVD pattern - there's a small TinyGo SVD repository dependent on Rust py32-rs repo. The repository is here: https://github.com/burgrp/py32-svd . I think it would be worth to move it to tinygo-org.

deadprogram · 2025-12-12T08:24:26Z

Hello @burgrp thank you for working on this.

Have you seen this page?
https://tinygo.org/docs/guides/contributing

I think you will find it helpful. 😸

targets/embedfire-py32f002b.json

targets/embedfire-py32f030.json

deadprogram · 2025-12-13T18:53:43Z

@burgrp I have switched the branch for this PR to dev branch as mentioned here:
https://tinygo.org/docs/guides/contributing/#how-to-use-our-github-repository

Can you please rebase it against the latest dev so it can run all of the latest tests?
Also I made a few comments.

Planning on ordering a few of these myself, thanks for working on it!

b0ch3nski · 2026-01-27T16:53:01Z

@burgrp You are updating bdwgc submodule which is probably not something you meant to do - this breaks a lot of stuff 🔥

burgrp · 2026-01-27T19:04:18Z

You are right... I will fix it and hopefully it will be possible to merge the PR.

burgrp · 2026-02-13T19:51:23Z

@b0ch3nski , the sub-module issue is fixed, all checks are passing

b0ch3nski · 2026-02-15T12:22:11Z

Thanks! I think now there is some unrelated change also in net submodule 😬

deadprogram · 2026-02-15T13:56:07Z

@b0ch3nski looks that way to me as well: https://github.com/tinygo-org/tinygo/pull/5106/changes#diff-d7ea94295bc068e99e5edeacb50734849fb40d5aa39cbc68be5e55c0d90bd60a

@burgrp one other thing that is needed is to add something to the smoketests to show that at least everything can build. Someplace appropriate in here, please: https://github.com/tinygo-org/tinygo/blob/dev/GNUmakefile#L567-L989

Update submodule to fix duplicate SetIDCODE/GetIDCODE method declarations in the generated py32f002bxx.go device file. Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>

burgrp · 2026-02-21T20:20:00Z

@b0ch3nski , @deadprogram smoketests added, net module update reverted

deadprogram · 2026-02-24T10:45:59Z

src/machine/machine_py32_pin.go

+return uint8(p) & 0x0F
+}
+
+func (p Pin) getPort() (*py32.GPIO_Type, uint8) {


Better to use unsafe.Add() if you must. Probably even better to use a switch to avoid possible errors.

deadprogram · 2026-02-24T10:52:16Z

src/machine/machine_py32_pin.go

+switch config.Mode {
+
+case PinInputFloating:
+port.MODER.ReplaceBits(gpioModeInput, gpioModeMask, pos)


I have not installed/run the gen-device-py32 yet, but I assume there are probably some functions like SetMODERInput() that are being generated. Using these are usually preferable, to avoid possible bugs from setting unexpected bits.

Unfortunately there is no SetMODERInput() generated. These helper functions are generated in form SetMODER_MODE0()...SetMODER_MODE15(), which are quite useless for parametric access.
I've fixed the machine constants to use the svd pin0 generated constants e.g.:
gpioModeOutput = py32.GPIO_MODER_MODE0_Output
so there is at least some binding to svd values.

deadprogram · 2026-02-24T10:52:21Z

src/machine/machine_py32_pin.go

+const PinInput PinMode = PinInputFloating
+
+const (
+gpioModeInput = 0


Are any of these being generated from the SVD file already? See comment below.

See my comment above.

deadprogram · 2026-02-24T10:53:23Z

src/machine/machine_py32_uart.go

+// peripheral clock frequency.
+func InitSerialWithClock(clockHz uint32) {
+py32UARTClockHz = clockHz
+//Serial.ConfigureWithClock(UARTConfig{}, clockHz)


Commented line?

deadprogram · 2026-02-24T10:55:39Z

src/runtime/runtime_py32.go

+py32.RCC.SetICSCR_HSI_FS(py32.RCC_ICSCR_HSI_FS_Freq24MHz)
+
+ConfigureSystemTimer(24_000_000)
+machine.InitSerial()


This perhaps needs to be moved into an init() function?

See #5200 (comment)

deadprogram · 2026-02-24T10:55:59Z

targets/embedfire-py32f002b.json

+ ],
+ "build-tags": [
+ "embedfire_py32f002b",
+"default_uart_pins"


Formatting, please.

deadprogram · 2026-02-24T10:59:04Z

This is getting exciting @burgrp thank you so much for working on it! We were discussing during our TinyGo monthly meeting last night ❤️

I made some comments, hopefully @soypat and others can also take a look.

soypat · 2026-02-24T19:51:33Z

I've taken a look and have some reservations on exported API chosen. I'd like to better understand how we define APIs in machine package to understand if the exported functions implemented here match with what the rest of TinyGo does. Basically working on getting something like go doc -tags=rp2040 machine to work (which it does not currently)

soypat · 2026-02-25T15:38:04Z

I vibe coded a tool to help us understand the tinygo APIs better. I'll invite you all to check it out to understand what our APIs look like in TinyGo #5224

soypat

Running tgdoc I've found what look like discrepancies with usual TinyGo API.

You can browse our APIs by running go run ./cmd/tgdoc -http=:18080 ../tinygo/targets ../tinygo/src/machine given tinygodoc shares tinygo parent directory
https://github.com/tinygo-org/tinygodoc

soypat · 2026-03-02T13:07:02Z

src/machine/machine_py32_uart.go

+
+// ConfigureWithClock initializes the UART using the provided peripheral clock
+// frequency (in Hz). This avoids assuming a fixed MCU clock.
+func (uart *UART) ConfigureWithClock(config UARTConfig, clockHz uint32) error {


can we replace clockHz with CPUFrequency() internal call to Configure?

soypat · 2026-03-02T13:08:13Z

src/machine/machine_py32_uart.go

+
+// InitSerialWithClock configures the default Serial using the supplied
+// peripheral clock frequency.
+func InitSerialWithClock(clockHz uint32) {


Same as above, use CPUFrequency(). It is standard tinygo API, present on 160 targets.

soypat · 2026-03-02T13:08:45Z

src/machine/machine_py32_uart.go

+}
+
+// Configure pin for use by UART
+func ConfigureUARTPin(pin Pin, af uint8) {


Shouldn't this be Pin.Configure followed by an SetAltFunc? (is it really necessary to export this?)

Or unexport it if it is expected to only be called internally for UART configuration

You are right, cleaned up to just Pin.Configure+SetAltFunc.
This needs to be exported, because other boards may need explicit call for non-default UART pins.

soypat · 2026-03-04T03:50:58Z

src/machine/machine_py32_clock.go

+func SetCPUFrequency(frequency uint32) {
+CPUFrequencyHz = frequency
+}


This is a very confusing API- it does not actually change the frequency. Prefer unexporting it and either linking with //go:linkname compiler directive from runtime package or setting as constant at build time.

I agree - the function is removed. The variable CPUFrequencyHz still needs to be exported to allow clock change from user code.

Why do you want to allow changing CPU frequency from user code?

This API does not exist yet in TinyGo, we'd likely need to discuss the best design going forward if we are to add it

For two simple reasons (correct me if I'm not seeing something):

TinyGo comes with a finite set of supported dev boards. In practice, final product boards differ, so they may need other setting.

There may be application which need to set clock dynamically, e.g. to save energy.

Are you in immediate need of any of the two? I'm very hesitant on adding this API, especially if it is counter-intuitive. Setting the value of CPUFrequencyHz does not actually modify anything about the CPU's frequency. This is not good API design. We need to discuss this API before adding it

https://github.com/orgs/tinygo-org/discussions/5239

Yes, I need that for one of my projects. Thanks for being open to discuss it!

I'd hate for this to stay in a stale state while we discuss the CPUFrequency API. Could you implement CPU frequency API on your side and test things and let us know how your experimentation goes?

deadprogram changed the base branch from release to dev December 13, 2025 18:43

deadprogram reviewed Dec 13, 2025

View reviewed changes

targets/embedfire-py32f002b.json Outdated Show resolved Hide resolved

deadprogram reviewed Dec 13, 2025

View reviewed changes

targets/embedfire-py32f002b.json Outdated Show resolved Hide resolved

deadprogram reviewed Dec 13, 2025

View reviewed changes

targets/embedfire-py32f030.json Outdated Show resolved Hide resolved

burgrp force-pushed the py32 branch from 8e14179 to fa6d383 Compare December 15, 2025 19:29

burgrp added 19 commits January 7, 2026 01:07

WIP

0736c01

WIP

f2bb62b

WIP

43bcc36

WIP

065b744

WIP

4fefecb

WIP

30a1db1

WIP

7c876ab

WIP

dca5920

WIP

93eb60d

WIP

8a87063

WIP

722e1a0

WIP

ea82d3c

WIP

eb9e9a4

WIP

cb5ecef

WIP

8ce087a

WIP

7e43acf

PR comments fixed

1c07804

pinout yamls removed

71cd7ba

machine: implement default UART pin configuration for Embedfire boards

7fa20c4

burgrp force-pushed the py32 branch from 84756c5 to 7fa20c4 Compare January 7, 2026 00:07

burgrp added 2 commits January 27, 2026 14:23

flash command moved to chip level so VS Code plugin can select bare chip

32e5948

machine: add support for alternate pin mode configuration

e9a2fa3

burgrp added 3 commits January 27, 2026 20:54

WIP

637ba3d

WIP

d5fa72d

WIP

a2f7595

burgrp and others added 5 commits February 21, 2026 00:00

update subproject commit reference in net module

fe054f4

add build targets for embedfire on py32

b4aa171

add support for embedfire target in GNUmakefile for py32

6da46ee

lib/py32-svd: remove duplicate DBGMCU.IDCODE CODE field

1900e16

Update submodule to fix duplicate SetIDCODE/GetIDCODE method declarations in the generated py32f002bxx.go device file. Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>

update subproject commit reference in py32-svd

5788b18

deadprogram reviewed Feb 24, 2026

View reviewed changes

soypat reviewed Mar 2, 2026

View reviewed changes

PR fixes

7e211e1

soypat reviewed Mar 4, 2026

View reviewed changes

refactor: update CPU frequency handling in machine and runtime packages

ff3eff4

Uh oh!

Conversation

burgrp commented Dec 2, 2025

deadprogram commented Dec 12, 2025

Uh oh!

Uh oh!

Uh oh!

deadprogram commented Dec 13, 2025

b0ch3nski commented Jan 27, 2026

burgrp commented Jan 27, 2026

burgrp commented Feb 13, 2026

b0ch3nski commented Feb 15, 2026

deadprogram commented Feb 15, 2026

burgrp commented Feb 21, 2026

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

deadprogram commented Feb 24, 2026

soypat commented Feb 24, 2026

soypat commented Feb 25, 2026

soypat left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

soypat Mar 2, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Choose a reason for hiding this comment

burgrp Mar 3, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Labels

4 participants

soypat Mar 2, 2026 •

edited

Loading

burgrp Mar 3, 2026 •

edited

Loading