Fix typos

deining · aykevl · commit 637f5842d087 · 2025-09-29T17:03:54.000+02:00
diff --git a/content/docs/concepts/compiler-internals/harvard-arch.md b/content/docs/concepts/compiler-internals/harvard-arch.md
@@ -5,4 +5,4 @@ weight: 10
 
 The AVR architecture is a modified Harvard architecture, which means that flash and RAM live in different address spaces. In practice, this means that any given pointer may either point to RAM or flash, but this is not visible from the pointer itself.
 
-To get TinyGo to work on the Arduino, which uses the AVR architecutre, all global variables (which include string constants!) are marked non-constant and thus are stored in RAM and all pointer dereferences assume that pointers point to RAM. At some point this should be optimized so that obviously constant data is kept in read-only memory but this optimization has not yet been implemented.
+To get TinyGo to work on the Arduino, which uses the AVR architecture, all global variables (which include string constants!) are marked non-constant and thus are stored in RAM and all pointer dereferences assume that pointers point to RAM. At some point this should be optimized so that obviously constant data is kept in read-only memory but this optimization has not yet been implemented.
diff --git a/content/docs/concepts/low-power.md b/content/docs/concepts/low-power.md
@@ -8,7 +8,7 @@ description: >
 ---
 
 Microcontrollers are usually rather non-demanding when it comes to power consumption.
-Couple hudreds mW is the most you may expect a hobby project would use.
+Couple hundreds mW is the most you may expect a hobby project would use.
 
 Sometimes, even that is not low enough.
 Power your project from a battery, and it'd benefit greatly from consuming less.
@@ -17,15 +17,15 @@ Common scenario for such projects is sleeping most of the time, and only rarely
 The main caveat here is if not configured properly, microcontroller and peripherals continue to consume power while your program "sleeps".
 
 The standard way to pause execution in Go is to use `time.Sleep()` function that is available in TinyGo too. Depending on the chip and effort put into its support, the efficiency of this function may vary. The only thing certain: this is _not worse_ than busy looping until a certain time has passed.  
-Still, with such high-level function as `time.Sleep()` it is not always possible to disable everything that consumes power as the decisions may depend on the application, presense of peripherals and the board used.
+Still, with such high-level function as `time.Sleep()` it is not always possible to disable everything that consumes power as the decisions may depend on the application, presence of peripherals and the board used.
 
 Most microcontrollers have one or more "low power" modes, also known as "deep sleep" and, sometimes, "dormant".  
 In such modes microcontroller may consume as low as milli- or even micro-Watts.  
 TinyGo gives you low level access to hardware to try and make most of it.
 
 ## Implementations
 
-Manufacturers implement different modes, depending of capabilites of their products and name these modes differently too.
+Manufacturers implement different modes, depending of capabilities of their products and name these modes differently too.
 Hence no naming consistency across microcontrollers, unfortunately.
 
 Always consult "Power consumption" part of a respective datasheet to understand capabilities of your hardware.  
diff --git a/content/docs/guides/contributing/_index.md b/content/docs/guides/contributing/_index.md
@@ -49,7 +49,7 @@ Here is how to contribute back some code or documentation:
 - Submit a pull request against the `dev` branch.
 - Be kind
 
-Please rebase (not merge) from the dev branch if your PR needs to incorporate changes that occured after your feature branch was created. You can accomplish that via the git command line:
+Please rebase (not merge) from the dev branch if your PR needs to incorporate changes that occurred after your feature branch was created. You can accomplish that via the git command line:
 
 ```
 git checkout dev
diff --git a/content/docs/guides/debugging.md b/content/docs/guides/debugging.md
@@ -68,7 +68,7 @@ There is a variety of choice when it comes to debug probes, but most debug probe
 Here are some debug probes that are known to work in TinyGo for at least some boards:
 
   * [SEGGER J-Link Edu Mini](https://www.segger.com/products/debug-probes/j-link/models/j-link-edu-mini/): this debugger can debug pretty much all ARM Cortex-M chips and is generally very reliable. However, it comes with some possible issues: it's entirely closed source, it is only allowed to be used for non-commercial purposes and it doesn't support as many chips as the full version.
-  * [Particle Debugger](https://store.particle.io/products/particle-debugger): a [DAPLink](https://armmbed.github.io/DAPLink/) based debugger that can debug practially all ARM Cortex-M chips (like the SEGGER above) and does not have limitations on how it can be used. It is also open source. While this debugger is designed for Particle hardware it can easily handle chips from other vendors.
+  * [Particle Debugger](https://store.particle.io/products/particle-debugger): a [DAPLink](https://armmbed.github.io/DAPLink/) based debugger that can debug practically all ARM Cortex-M chips (like the SEGGER above) and does not have limitations on how it can be used. It is also open source. While this debugger is designed for Particle hardware it can easily handle chips from other vendors.
   * [ST-Link v2](https://www.st.com/en/development-tools/st-link-v2.html): a debugger often included on boards from STMicroelectronics and also sold separately. It is somewhat less powerful than some other debuggers as it is only intended to be used with ST hardware, even though it works with most microcontrollers that support SWD debugging. Note that many online stores sell counterfeit versions of this debugger that may be unreliable.
   * [DIY DAPLink](https://embeddedcomputing.weebly.com/the-5-programmer-debugger.html): a debugger you can make yourself. Requires compatible board, for example [Seeeduino XIAO](https://www.seeedstudio.com/Seeeduino-XIAO-Arduino-Microcontroller-SAMD21-Cortex-M0+-p-4426.html) that costs about $5. Please see linked page for flashing and wiring instructions. For quick and easy start, it is possible to [download uf2 image](http://files.seeedstudio.com/wiki/Seeeduino-XIAO/res/simple_daplink_xiao.uf2) and flash it by simply copying it over to XIAO mounted as an external drive. Members of TinyGo community reported successfully using this method to debug XIAO and Arduino Nano 33 IoT boards.
   * [DYI Picoprobe](https://www.raspberrypi.com/documentation/microcontrollers/raspberry-pi-pico.html#debugging-using-another-raspberry-pi-pico): Is another DIY opensource tool for the Raspberry Pi Pico. It acts as a Serial Wire Debugger (SWD) and UART to usb converter. The Raspberry Pi Pico getting started guide Appendix A page 60 has [instructions to build](https://datasheets.raspberrypi.com/pico/getting-started-with-pico.pdf) from [source](https://github.com/raspberrypi/picoprobe) or you can download and flash the [UF2 image](https://datasheets.raspberrypi.com/soft/picoprobe.uf2).
diff --git a/content/docs/guides/ide-integration/_index.md b/content/docs/guides/ide-integration/_index.md
@@ -28,7 +28,7 @@ Now you need to configure your IDE with these values.
 
 ### Using tinygo-edit
 
-There is a CLI tool called [tinygo-edit](https://github.com/sago35/tinygo-edit) you can use it to Gather the needed build flags and starting the editor using the correct environment variables. Using the CLI you don't need to do the steps manualy.
+There is a CLI tool called [tinygo-edit](https://github.com/sago35/tinygo-edit) you can use it to Gather the needed build flags and starting the editor using the correct environment variables. Using the CLI you don't need to do the steps manually.
 
 ### Using an alias
 
diff --git a/content/docs/guides/tips-n-tricks.md b/content/docs/guides/tips-n-tricks.md
@@ -57,7 +57,7 @@ func (t *MyType) SomeMethod() {
 }
 ```
 
-You may even find yourself having two or more slices pointing at diferent regions of the same array simultaneously, if you are careful.
+You may even find yourself having two or more slices pointing at different regions of the same array simultaneously, if you are careful.
 
 ```
 buf1 := t.buf[:2]
diff --git a/content/docs/reference/microcontrollers/machine/pinetime-devkit0.md b/content/docs/reference/microcontrollers/machine/pinetime-devkit0.md
@@ -938,7 +938,7 @@ Transfer writes/reads a single byte using the SPI interface.
 func (spi SPI) Tx(w, r []byte) error
 ```
 
-Tx handles read/write operation for SPI interface. Since SPI is a syncronous
+Tx handles read/write operation for SPI interface. Since SPI is a synchronous
 write/read interface, there must always be the same number of bytes written
 as bytes read. Therefore, if the number of bytes don't match it will be
 padded until they fit: if len(w) > len(r) the extra bytes received will be
diff --git a/content/docs/reference/microcontrollers/nano-33-ble.md b/content/docs/reference/microcontrollers/nano-33-ble.md
@@ -118,7 +118,7 @@ Instructions needed here.
 
 Nordic Semiconductor's SoftDevice (s140v7) must be flashed first to enable use of [bluetooth](https://github.com/tinygo-org/bluetooth) on this board.
 
-SoftDevice overwrites original bootloader and flashing method described above is not avalable anymore.
+SoftDevice overwrites original bootloader and flashing method described above is not available anymore.
 Instead, please use [debug]({{<ref "../../guides/debugging.md">}}) probe and
 flash your code with `nano-33-ble-s140v7` target.
 
diff --git a/content/docs/reference/microcontrollers/wioterminal.md b/content/docs/reference/microcontrollers/wioterminal.md
@@ -150,5 +150,5 @@ tinygo flash -target=wioterminal [PATH TO YOUR PROGRAM]
 Once you have updated your Wio Terminal board the first time, after that you should be able to flash it entirely from the command line.
 
 ## Notes
-If your Linux Distro doesnt auto mount devices you have to manually mount it to /media/Arduino for the command above to work.
+If your Linux Distro doesn't auto mount devices you have to manually mount it to /media/Arduino for the command above to work.
 You can use the USB port to the Wio Terminal as a serial port. `UART0` refers to this connection.
diff --git a/content/docs/reference/usage/basic.md b/content/docs/reference/usage/basic.md
@@ -22,7 +22,7 @@ To build and then flash a basic blink program for a micro:bit board:
 
 - Plug your micro:bit into your computer's USB port.
 - The micro:bit board will appear to your computer like a USB drive. Determine the path to the board, for example on Linux it will be something like `/media/[USERNAME]/[NAME OF THE BOARD]`.
-- Run the following command, substituing the correct name for the board from the previous step:
+- Run the following command, substituting the correct name for the board from the previous step:
 
 ```shell
 tinygo build -o=/media/[USERNAME]/[NAME OF THE BOARD]/flash.hex -target=microbit examples/microbit-blink
@@ -35,7 +35,7 @@ The top-left pixel of the built-in LED matrix on the micro:bit board should star
 To build and then flash a basic blink program for an Arduino Uno,
 
 - Plug in the board to your computer's USB port.
-- Run the following command, specifiying the serial port if needed. (It defaults to `/dev/ttyACM0` as that is the default port on Linux.)
+- Run the following command, specifying the serial port if needed. (It defaults to `/dev/ttyACM0` as that is the default port on Linux.)
 
 ```shell
 tinygo flash -target=arduino -port=[PORT] examples/blinky1
@@ -50,7 +50,7 @@ To build and then flash a basic blink program for an Circuit Playground Express,
 - Plug your Circuit Playground Express into your computer's USB port.
 - Press the "RESET" button on the board two times to get the Circuit Playground Express board ready to receive code. If you just received the board, it will be running MakeCode, so press the "RESET" button just once. Either way, the NeoPixel LEDs should turn all green.
 - The Circuit Playground Express board will appear to your computer like a USB drive. Determine the path to the board, for example on Linux it will be something like `/media/[USERNAME]/[NAME OF THE BOARD]`.
-- Run the following command, substituing the correct name for the board from the previous step:
+- Run the following command, substituting the correct name for the board from the previous step:
 
 ```shell
 tinygo build -o=/media/[USERNAME]/[NAME OF THE BOARD]/flash.uf2 -target=circuitplay-express examples/blinky1
diff --git a/content/docs/reference/usage/misc-options.md b/content/docs/reference/usage/misc-options.md
@@ -24,7 +24,7 @@ Note: while there is some support for debug symbols, only line numbers have been
         ```
     
     - `full`
-        Try to determine per package how much space is used. Note that these calculations are merely guesses and can somethimes be way off due to various reasons like inlining:
+        Try to determine per package how much space is used. Note that these calculations are merely guesses and can sometimes be way off due to various reasons like inlining:
         ```
         code  rodata    data     bss |   flash     ram | package
         876        0       4       0 |     880       4 | (bootstrap)

Original file line number	Diff line number	Diff line change
`@@ -5,4 +5,4 @@ weight: 10`
`5`	`5`
`6`	`6`	`The AVR architecture is a modified Harvard architecture, which means that flash and RAM live in different address spaces. In practice, this means that any given pointer may either point to RAM or flash, but this is not visible from the pointer itself.`
`7`	`7`
`8`		`-To get TinyGo to work on the Arduino, which uses the AVR architecutre, all global variables (which include string constants!) are marked non-constant and thus are stored in RAM and all pointer dereferences assume that pointers point to RAM. At some point this should be optimized so that obviously constant data is kept in read-only memory but this optimization has not yet been implemented.`
	`8`	`+To get TinyGo to work on the Arduino, which uses the AVR architecture, all global variables (which include string constants!) are marked non-constant and thus are stored in RAM and all pointer dereferences assume that pointers point to RAM. At some point this should be optimized so that obviously constant data is kept in read-only memory but this optimization has not yet been implemented.`
Original file line number	Diff line number	Diff line change
`@@ -57,7 +57,7 @@ func (t *MyType) SomeMethod() {`
`57`	`57`	`}`
`58`	`58`	```
`59`	`59`
`60`		`-You may even find yourself having two or more slices pointing at diferent regions of the same array simultaneously, if you are careful.`
	`60`	`+You may even find yourself having two or more slices pointing at different regions of the same array simultaneously, if you are careful.`
`61`	`61`
`62`	`62`	```
`63`	`63`	`buf1 := t.buf[:2]`