github
/
tinygo
mirror of https://github.com/tinygo-org/tinygo.git
1
0
Fork 0
Code Issues Projects Releases Wiki Activity
You can not select more than 25 topics Topics must start with a letter or number, can include dashes ('-') and can be up to 35 characters long.
3310 Commits
99 Branches
41 Tags
26 MiB
Tree: 383e7ae14a
Branches Tags
${ item.name }
Create tag ${ searchTerm }
Create branch ${ searchTerm }
from '383e7ae14a'
${ noResults }
tinygo/targets/bluepill.json

13 lines
298 B
Raw Normal View History

stm32: initial support
6 years ago
{
all: clean up Cortex-M target files In this commit I've moved all core-specific flags to files for that specific core. This is a bit of a cleanup (less duplicated JSON) but should also help in the future when core-specific changes are made, such as core specific build tags or when the FPU finally gets supported in TinyGo. Some notable specific changes: - I've removed floating point flags from the Teensy 3.6 target. The reason is that the FPU is not yet supported in TinyGo (in goroutine stack switching for example) and floating point numbers would only be supported by C files, not Go files (because the LLVM FPU feature flags aren't used). This would create an ABI mismatch across CGo. - I've added the "cpu":"cortex-m7" to the cortex-m7.json file to match the configuration for the Teensy 4.0. This implies a change to the nucleo-f722ze (because now it has its CPU field set). Somehow that reduces the code size, so it looks like a good change. I don't believe any of these changes should have any practical consequences. One issue I've found is in the Cortex-M33 target: it uses armv7m, which is incorrect: it should be armv8m. But the chip is backwards compatible so this should mostly work. Switching to armv8m led to a compilation failure because PRIMASK isn't defined, this may be an actual bug.
4 years ago
"inherits": ["cortex-m3"],
stm32: i2c implementation for F7, L5 and L4 MCUs
4 years ago
"build-tags": ["bluepill", "stm32f103", "stm32f1", "stm32"],
all: add a flag to the command line to select the serial implementation This can be very useful for some purposes: * It makes it possible to disable the UART in cases where it is not needed or needs to be disabled to conserve power. * It makes it possible to disable the serial output to reduce code size, which may be important for some chips. Sometimes, a few kB can be saved this way. * It makes it possible to override the default, for example you might want to use an actual UART to debug the USB-CDC implementation. It also lowers the dependency on having machine.Serial defined, which is often not defined when targeting a chip. Eventually, we might want to make it possible to write `-target=nrf52` or `-target=atmega328p` for example to target the chip itself with no board specific assumptions. The defaults don't change. I checked this by running `make smoketest` before and after and comparing the results.
3 years ago
"serial": "uart",
compileopts: add linkerscript key Setting the linker script as one property (instead of as part of the generic ldflags property) allows it to be overriden. This is important for the SoftDevice on Nordic chips, because the SoftDevice takes up a fixed part of the flash/RAM and the application must be flashed at a different position. With this linkerscript option, it is possible to create (for example) a pca10040-s132v6 that overrides the default linker script.
5 years ago
"linkerscript": "targets/stm32.ld",
all: compile and link using clang, where possible
6 years ago
"extra-files": [
Revert "all: move stm32 files to separate repository" This reverts commit 644356c220ed88f110d01300f671a170cd36eb04.
3 years ago
"src/device/stm32/stm32f103.s"
targets: let specific targets inherit more general targets This avoids a ton of duplication and makes it easier to change a generic target (for example, the "cortex-m" target) for all boards that use it. Also, by making it possible to inherit properties from a parent target specification, it is easier to support out-of-tree boards that don't have to be updated so often. A target specification for a special-purpose board can simply inherit the specification of a supported chip and override the properites it needs to override (like the programming interface).
6 years ago
],
targets: refactor flash/gdb target configuration Instead of specifying explicit commands, most of these commands have been replaced by more specific properties. This is work that will be necessary for an eventual -programmer flag to the compiler, with which it is possible to select which programmer to use to flash or debug a chip. That's not very useful for boards that already include a programmer or bootloader for that purpose, but is very useful for novel boards or single-purpose boards that are not already included in TinyGo.
5 years ago
"flash-method": "openocd",
"openocd-interface": "stlink-v2",
"openocd-target": "stm32f1x"
stm32: initial support
6 years ago
}