knieriem 0757ccc657 update tools/gen-device-svd w.r.t. recent changes to the structure of stm32-svd files (#5212)
* tools/gen-device-svd: orderPeripherals: prevent skipping base peripherals derived by name

Recent SVDs from stm32-rs, like the one for stm32u595, define derivedFrom
attributes that do not refer to a peripheral group name, but to a
peripheral name. For instance, the peripheral I2C5 may be derived from
"I2C1", not from "I2C". The previous algorithm records, in case the
group name is non-empty, only the group name in the
knownBasePeripherals map, not the name of the peripheral itself.
So in case of the base peripheral I2C1 with group name I2C: although
the peripheral gets added to the sorted list, it would be added to
knownBasePeripherals with the group name "I2C" as key, not with "I2C1".
A following peripheral, I2C5, derived from I2C1, with an empty group
name, would be recorded as known with key "I2C5", but omitted from the
sorted list, because "I2C1" is not recognized as known.
The following peripheral SEC_I2C5, derived from I2C5, with empty group
name, would be added to both the knownPeripherals map and the sorted list.
So if, later, the sorted list is examined, it would find SEC_I2C5
earlier than its base peripheral I2C5, which would be missing from
"peripheralDict", resulting in a nil pointer access.
This patch makes sure that, to stay with the example, that
"I2C1" is recorded as known too (not only the group name "I2C"),
so that "I2C5" won't be skipped anymore, preventing the program from
crashing.

* tools/gen-device-svd: orderPeripherals: ensure ordered content of missingBasePeripherals

After the first run, missingBasePeripherals may contain peripherals
with dependencies that are not guaranteed to be in proper order.

This change implements additional loop runs that try to reduce the
size of the missingBasePeripherals as far as possible.

[With recent SVDs from stm32-rs this change will not produce different
results, though (since these source files contain already properly
ordered peripherals).]

* tools/gen-device-svd: Register: move dim array decoding to utility type dimArray

This allows encoding of dim increment and array indices to be re-used
by other elements supporting dim arrays.

This change just restructures parts of register specific code,
it does not change the output of the program.

* tools/gen-device-svd: parseBitfields: support field dim arrays

Patched SVD files from stm32-rs recently contain many fields with
dim array parameters and names containing %s (like "CC%sIF").
This change adjusts parseBitfields so that these field elements
get resolved.

* tools/gen-device-svd: SVDField: allow multiple enumeratedValues

In recent patched SVD files from stm32-rs there may be two
enumeratedValues elements per SVDField, not just one.
The SVD specification allows up to two entries (they may be used
to define different enums for read and write access).

This change extends SVDField and parseBitfields so that
two enumeratedValues are processed like a single one.

* tools/gen-device-svd: orderPeripherals: sort peripherals of same group with larger number of registers/bitfields first

In group "TIM" there may be general purpose timers like TIM16 and
advanced timers like TIM1. The advanced peripheral may contain a larger
number of registers than the general purpose ones.
TIM1 may contain CCR1..CCR4, SMCR and OR1, while TIM16 only knows
about CCR1.
Unfortunately in some SVDs, like the one for stm32g031, TIM16 is defined
before TIM1. Since register and bitfield constants are generated taking
only the first peripheral of a group into account, the resulting .go
file may lack definitions for e.g. CCR2..CCR4, SMCR, and OR1.

This change adjusts orderPeripherals so that, to stay with the example,
a peripheral like TIM1 will be moved in front of TIM16, resulting in an
output file containing the larger set of definitions.

* tools/gen-device-svd: SVDEnumeration: support isDefault

Recent SVD files created by stm32-rs use "isDefault" in enumeratedValue
elements for purposes like the Div1 enum for clock prescaler registers
without specifying a specific value.
Previously, these enumeratedValues would be skipped because of the
enumEl.Value == 0 condition, and the corresponding const definitions
like "RCC_CFGR2_PPRE2_Div1 = 0x0" would be missing from the
resulting .go files, so existing code relying on these constants would
not compile anymore.
This change adds a utility type enumDefaultResolver that helps
finding an actual value that is unused by the enumeratedValues that
are defined for the field. More examples for values marked
as "isDefault", along with their resolved values:

  DAC_CR_WAVE1_Triangle => 2
  IWDG_PR_PR_DivideBy256 => 6
  DAC_CR_MAMP2_Amp4095 => 0xb

* tools/gen-device-svd: support derivedFrom attribute at field level

This ensures that some more constants are included in the .go files
that would otherwise be skipped (like e.g. ADC_SMPR2_SMP1_Cycles*
of some STM32 devices), which prevented compilation of some programs.

To avoid extending a lot of func argument lists, and since there
is no context.Context in use yet, this change introduces a
global derivationContext.

* tools/gen-device-svd: tweak: stm32: ensure USART_ISR_TXE/TXFNF are present

* tools/gen-device-svd: stm32: ensure CCMR*_Output alternate registers are sorted first

* tools/gen-device-svd: stm32: add IWDG peripheral alias if SVD defines IWDG1
2026-04-05 14:15:40 +02:00
2026-04-05 14:15:40 +02:00
2025-04-22 16:31:19 +02:00
2026-04-05 14:14:55 +02:00
2026-01-05 15:10:31 -05:00
2025-10-03 15:46:25 +02:00
2024-12-18 19:36:30 +01:00
2025-12-18 21:59:18 +00:00
2026-04-05 14:15:40 +02:00
2026-04-05 14:15:40 +02:00
2026-01-02 20:40:17 +00:00
2022-12-19 23:20:11 +01:00

TinyGo - Go compiler for small places

Linux macOS Windows Docker Nix CircleCI

TinyGo is a Go compiler intended for use in small places such as microcontrollers, WebAssembly (wasm/wasi), and command-line tools.

It reuses libraries used by the Go language tools alongside LLVM to provide an alternative way to compile programs written in the Go programming language.

Important

You can help TinyGo with a financial contribution using OpenCollective. Please see https://opencollective.com/tinygo for more information. Thank you!

Embedded

Here is an example program that blinks the built-in LED when run directly on any supported board with onboard LED:

package main

import (
    "machine"
    "time"
)

func main() {
    led := machine.LED
    led.Configure(machine.PinConfig{Mode: machine.PinOutput})
    for {
        led.Low()
        time.Sleep(time.Millisecond * 1000)

        led.High()
        time.Sleep(time.Millisecond * 1000)
    }
}

The above program can be compiled and run without modification on an Arduino Uno, an Adafruit ItsyBitsy M0, or any of the supported boards that have a built-in LED, just by setting the correct TinyGo compiler target. For example, this compiles and flashes an Arduino Uno:

tinygo flash -target arduino examples/blinky1

WebAssembly

TinyGo is very useful for compiling programs both for use in browsers (WASM) as well as for use on servers and other edge devices (WASI).

TinyGo programs can run in Fastly Compute, Fermyon Spin, wazero and many other WebAssembly runtimes.

Here is a small TinyGo program for use by a WASI host application:

package main

//go:wasmexport add
func add(x, y uint32) uint32 {
	return x + y
}

This compiles the above TinyGo program for use on any WASI Preview 1 runtime:

tinygo build -buildmode=c-shared -o add.wasm -target=wasip1 add.go

You can also use the same syntax as Go 1.24+:

GOOS=wasip1 GOARCH=wasm tinygo build -buildmode=c-shared -o add.wasm add.go

Installation

See the getting started instructions for information on how to install TinyGo, as well as how to run the TinyGo compiler using our Docker container.

Supported targets

Embedded

You can compile TinyGo programs for over 94 different microcontroller boards.

For more information, please see https://tinygo.org/docs/reference/microcontrollers/

WebAssembly

TinyGo programs can be compiled for both WASM and WASI targets.

For more information, see https://tinygo.org/docs/guides/webassembly/

Operating Systems

You can also compile programs for Linux, macOS, and Windows targets.

For more information:

Currently supported features:

For a description of currently supported Go language features, please see https://tinygo.org/lang-support/.

Documentation

Documentation is located on our web site at https://tinygo.org/.

You can find the web site code at https://github.com/tinygo-org/tinygo-site.

Getting help

If you're looking for a more interactive way to discuss TinyGo usage or development, we have a #TinyGo channel on the Gophers Slack.

If you need an invitation for the Gophers Slack, you can generate one here which should arrive fairly quickly (under 1 min): https://invite.slack.golangbridge.org

Contributing

Your contributions are welcome!

Please take a look at our Contributing page on our web site for details.

Project Scope

Goals:

  • Have very small binary sizes. Don't pay for what you don't use.
  • Support for most common microcontroller boards.
  • Be usable on the web using WebAssembly.
  • Good CGo support, with no more overhead than a regular function call.
  • Support most standard library packages and compile most Go code without modification.

Non-goals:

  • Be efficient while using zillions of goroutines. However, good goroutine support is certainly a goal.
  • Be as fast as gc. However, LLVM will probably be better at optimizing certain things so TinyGo might actually turn out to be faster for number crunching.
  • Be able to compile every Go program out there.

Why this project exists

We never expected Go to be an embedded language and so its got serious problems...

-- Rob Pike, GopherCon 2014 Opening Keynote

TinyGo is a project to bring Go to microcontrollers and small systems with a single processor core. It is similar to emgo but a major difference is that we want to keep the Go memory model (which implies garbage collection of some sort). Another difference is that TinyGo uses LLVM internally instead of emitting C, which hopefully leads to smaller and more efficient code and certainly leads to more flexibility.

The original reasoning was: if Python can run on microcontrollers, then certainly Go should be able to run on even lower level micros.

License

This project is licensed under the BSD 3-clause license, just like the Go project itself.

Some code has been copied from the LLVM project and is therefore licensed under a variant of the Apache 2.0 license. This has been clearly indicated in the header of these files.

Some code has been copied and/or ported from Paul Stoffregen's Teensy libraries and is therefore licensed under PJRC's license. This has been clearly indicated in the header of these files.

S
Description
Go compiler for small places. Microcontrollers, WebAssembly (WASM/WASI), and command-line tools. Based on LLVM.
Readme BSD-3-Clause 34 MiB
Latest
2025-08-19 12:03:57 +00:00
Languages
Go 91.7%
Linker Script 2.8%
Assembly 2.7%
Makefile 1.2%
C++ 0.5%
Other 0.9%