diff --git a/content/docs/concepts/peripherals/i2c.md b/content/docs/concepts/peripherals/i2c.md index 27f62396..a4e68268 100644 --- a/content/docs/concepts/peripherals/i2c.md +++ b/content/docs/concepts/peripherals/i2c.md @@ -35,6 +35,12 @@ You could think of this auto-increment behavior as reading a file. Step 1 opens Writing is very similar. The main difference is that the controller writes data to the peripheral instead of starting to read bytes after the initial register number is written to the peripheral. +## Target mode + +Typically, I2C peripherals are used in controller mode to communicate with sensors and other devices. In I2C target mode, the peripheral instead takes the role of the target (i.e. the role of a sensor/similar device). In this case, the application logic is responsible for processing and responding to messages initiated by an I2C controller, according to this flow diagram: + +![I2C Target Flow](/images/i2c-target-flow.png) + ## Interacting with a device For this example, we'll use the [MPU6050](https://invensense.tdk.com/products/motion-tracking/6-axis/mpu-6050/) which is a very common (but old) sensor that measures acceleration and rotation. We won't be doing much interesting with it, but it serves as a great introduction into how to work with I2C peripherals with TinyGo. diff --git a/content/docs/guides/build.md b/content/docs/guides/build.md index dc00f683..9f6c58b5 100644 --- a/content/docs/guides/build.md +++ b/content/docs/guides/build.md @@ -172,16 +172,23 @@ You have successfully built TinyGo from source. Congratulations! We're not done yet. Some extra things need to be built before you can start using TinyGo. +If you haven't already, you need to download llvm-project (for the compiler-rt sources that are needed for most architectures): + +```shell +make llvm-source +``` + To be able to use TinyGo on a bare-metal target, you need to generate some files first: ```shell make gen-device ``` -To be able to use TinyGo to build WebAssembly binaries, you will need to compile [wasi-libc](https://github.com/WebAssembly/wasi-libc): +To be able to use TinyGo to build WebAssembly binaries, you will need to compile [wasi-libc](https://github.com/WebAssembly/wasi-libc) and [Binaryen](https://github.com/WebAssembly/binaryen): ```shell make wasi-libc +make binaryen ``` These command may need to be re-run after some updates in TinyGo. diff --git a/content/docs/guides/contributing/_index.md b/content/docs/guides/contributing/_index.md index 3f15640b..9a67a944 100644 --- a/content/docs/guides/contributing/_index.md +++ b/content/docs/guides/contributing/_index.md @@ -44,6 +44,7 @@ Here is how to contribute back some code or documentation: - Fork repo - Create a feature branch off of the `dev` branch - Make some useful change +- Format the change using `make fmt` - Make sure the tests still pass - Submit a pull request against the `dev` branch. - Be kind diff --git a/content/docs/reference/machine.md b/content/docs/reference/machine.md index 88b428d3..3152938a 100644 --- a/content/docs/reference/machine.md +++ b/content/docs/reference/machine.md @@ -84,6 +84,71 @@ SetInterrupt sets an interrupt to be executed when the pin changes state. The pi This call will replace a previously set callback on this pin. You can pass `nil` to disable the interrupt. If you do so, the change parameter is ignored and can be set to any value (such as 0). +## SPI + +```go +type SPIConfig struct { + Frequency uint32 + SCK Pin + SDO Pin + SDI Pin + LSBFirst bool + Mode uint8 +} +``` + +The `SPIConfig` struct contains the configuration for the SPI peripheral. + + * `Frequency` is the maximum frequency that will be used: for example `1 * MHz` for 1MHz. Depending on chip capabilities, this or a lower frequency will be selected. When not set (or set to 0), the default of 4MHz will be used. + * `SCK`, `SDO` and `SDI` are the clock, data out, and data in pins respectively, however support for setting pins other than the default pins may not be supported by a given SPI peripheral. Some chips are flexible and allow the use of any pin, while other boards only allow a limited range of pins or use fixed SCK/SDO/SDI pins. When these pins are left at the zero value, the default for the particular board is used. + * `LSBFirst` configures the SPI peripheral to clock out the least significant bit (LSB) first. The default and most commonly used configuration is the most significant bit first (`LSBFirst=false`). + * `Mode` is the [SPI mode (CPOL/CPHA) to be used](https://en.wikipedia.org/wiki/Serial_Peripheral_Interface#Clock_polarity_and_phase). Mode 0 is appropriate for most peripheral chips, but other modes may be needed in some cases. Check your peripheral documentation for details. + | Mode | CPOL | CPHA | + | ------- | ---- | ---- | + | `Mode0` | 0 | 0 | + | `Mode1` | 0 | 1 | + | `Mode2` | 1 | 0 | + | `Mode3` | 1 | 1 | + +```go +type SPI struct { + // values are unexported or vary by chip +} + +var ( + SPI0 = SPI{...} + SPI1 = SPI{...} +) +``` + +The `SPI` object refers to a single (hardware) SPI instance. Depending on chip capabilities, various objects such as `SPI0` and perhaps others are defined. + +```go +func (spi SPI) Configure(config SPIConfig) error +``` + +The `Configure` call enables and configures the hardware SPI for use, setting the configuration as described in `SPIConfig`. It will return an error when an incorrect configuration is provided (for example, using pins not usable with this SPI instance). See `SPIConfig` for details. + +```go +func (spi SPI) Transfer(b byte) (byte, error) +``` + +Transmit and receive a single byte. Due to the nature of the SPI protocol, they happen both at the same time. + +Use `Tx` instead of `Transfer` for high performance bulk transfers. + +```go +func (spi SPI) Tx(w, r []byte) error +``` + +The `Tx` performs the actual SPI transaction, and return an error if there was an error during the transaction. Because SPI is a synchronous protocol, reading and writing happens at the same time. Therefore, `w` and `r` usually have to be the same length. There are some exceptions: + + * When `r` is nil, the SPI peripheral will only transmit the bytes in `w` and ignore what it receives. + * When `w` is nil, the SPI peripheral will only read the given number of bytes and store it in `r`. It will send out a zero byte for each byte that it reads. + +Some chips may also support mismatched lengths of `w` and `r`, in which case they will behave like above for the remaining bytes in the byte slice that's the longest of the two. + + ## I2C ```go @@ -91,6 +156,7 @@ type I2CConfig struct { Frequency uint32 SCL Pin SDA Pin + Mode I2CMode } ``` @@ -98,7 +164,9 @@ The `I2CConfig` struct contains the configuration for the I2C peripheral. * `Frequency` can be set to either 100kHz (`100e3`), 400kHz (`400e3`), and sometimes to other values depending on the chip. The zero value defaults to 100kHz. * `SCL` and `SDA` can be set as desired, however support for different pins than the default is limited. Some chips are flexible and allow the use of any pin, while other boards only allow a limited range of pins or use fixed SCL/SDA pins. When both pins are left at the zero value, the default for the particular board is used. - + * `Mode` is present on peripherals that support I2C target mode. The default + is I2C controller mode, setting `Mode` to `I2CModeTarget` will configure the + peripheral as an I2C target. ```go type I2C struct { // values are unexported or vary by chip @@ -122,8 +190,39 @@ The `Configure` call enables and configures the hardware I2C for use, setting th func (i2c I2C) Tx(addr uint16, w, r []byte) error ``` -The `Tx` call performs the actual I2C transaction. It first writes the bytes in `w` to the peripheral device indicated in `addr` and then reads `r` bytes from the peripheral and stores the read bytes in the `r` slice. It returns an error if the transaction failed. Both `w` and `r` can be `nil`. +_I2C Controller Mode Only_: The `Tx` call performs the actual I2C transaction. It first writes the bytes in `w` to the peripheral device indicated in `addr` and then reads `r` bytes from the peripheral and stores the read bytes in the `r` slice. It returns an error if the transaction failed. Both `w` and `r` can be `nil`. + +```go +func (i2c I2C) Listen(addr uint16) error +``` + +_I2C Target Mode Only_: The `Listen` call starts the I2C peripheral listening for I2C transactions sent +to `addr` by the controller. The peripheral must have been configured in target +mode (see `I2CConfig` struct) before `Listen` is called. + +```go +func (i2c *I2C) WaitForEvent(buf []byte) (evt I2CTargetEvent, count int, err error) +``` + +_I2C Target Mode Only_: The `WaitForEvent` call blocks the current goroutine waiting for an I2C event. For `I2CReceive` events, the message will be placed in `buf` and return the `count` of bytes received. Oversize messages (those larger than `buf`) will be truncated. + +The underlying peripheral will perform clock stretching, if necessary, in two cases: + + 1. A correctly addressed message is received and the application is not blocked on a call to `WaitForEvent`, + + 2. The application does not call `Reply` with a single I2C clock cycle for `I2CRequest` events. + +Although the I2C target may perform clock stretching, controllers may implement arbitrary timeouts for pending devices. To avoid timeouts from the perspective a controller, the application should: + + 1. Handle the returned event in a timely manner, calling `Reply` if appropriate. + + 2. Not have any go routines that may block indefinitely as `WaitForEvent` may yield the CPU to another go routine while waiting for an event. + +```go +func (i2c I2C) Reply(buf []byte) error +``` +_I2C Target Mode Only_: The `Reply` call sends a response to the controller when an `I2CRequest` event is received by the target. ## UART diff --git a/content/docs/reference/usage/subcommands.md b/content/docs/reference/usage/subcommands.md index 310be5e5..0192c15f 100644 --- a/content/docs/reference/usage/subcommands.md +++ b/content/docs/reference/usage/subcommands.md @@ -36,7 +36,58 @@ Compile and link the program into a regular executable. For microcontrollers, it Run the program, either directly on the host or in an emulated environment (depending on `-target`). ### flash -Flash the program to a microcontroller. +Flash the program to a microcontroller. Some common flags are described below. + +`-target={name}`: Specifies the type of microcontroller that is used. The `name` +of the microcontroller is given on the individual pages for each board type +listed under [Microcontrollers]({{}}). For example, +`arduino-nano`, `d1mini`, `xiao`. + +`-monitor`: Start the serial monitor (see below) immediately after flashing. +However, some microcontrollers need a split second or two to configure the +serial port after flashing, and using the `-monitor` flag can fail because the +serial monitor starts too quickly. In that case, use the `tinygo monitor` +command explicitly. + +### monitor +Start the serial monitor on the serial port that is connected to the +microcontroller. If there is only a single board attached to the host computer, +the default values for various options should be sufficient. In other +situations, particularly if you have multiple microcontrollers attached, some +parameters may need to be overridden using the following flags: + +`-port={port}`: If there are multiple microcontroller attached, an error message +will display a list of potential serial ports. The appropriate port can be +specified by this flag. On Linux, the port will be something like `/dev/ttyUSB0` +or `/dev/ttyACM1`. On MacOS, the port will look like `/dev/cu.usbserial-1420`. +On Windows, the port will be something like `COM1` or `COM31`. + +`-baudrate={rate}`: The default baud rate is 115200. Boards using the AVR +processor (e.g. [Arduino Nano]({{}}), +[Arduino Mega 2560]({{}})) use 9600 +instead. + +`-target={name}`: If you have more than one microcontrollers attached, you can +sometimes just specify the target name and let `tinygo monitor` figure out the +port. Sometimes, this does not work and you have to explicitly use the `-port` +flag. + +The serial monitor intercepts several control characters for its own use instead +of sending them to the microcontroller: + +* Control-C: terminates the `tinygo monitor` +* Control-Z: suspends the `tinygo monitor` and drops back into shell +* Control-\\: terminates the `tinygo monitor` with a stack trace +* Control-S: flow control, suspends output to the console +* Control-Q: flow control, resumes output to the console +* Control-@: thrown away by `tinygo monitor` + +**Note**: If you are using `os.Stdin` on the microcontroller, you may find that +a CR character on the host computer (also known as Enter, `^M`, or `\r`) is +transmitted to the microcontroller without conversion, so `os.Stdin` returns a +`\r` character instead of the expected `\n` (also known as `^J`, NL, or LF) to +indicate end-of-line. You may be able to get around this problem by hitting +`Control-J` in `tinygo monitor` to transmit the `\n` end-of-line character. ### gdb Compile the program, optionally flash it to a microcontroller if it is a remote target, and drop into a GDB shell. From there you can set breakpoints, start the program with `run` or `continue` (`run` for a local program, `continue` for on-chip debugging), single-step, show a backtrace, break and resume the program with Ctrl-C/`continue`, etc. You may need to install extra tools (like `openocd` and `arm-none-eabi-gdb`) to be able to do this. Also, you may need a dedicated debugger to be able to debug certain boards if no debugger is integrated. Some boards (like the BBC micro:bit and most professional evaluation boards) have an integrated debugger. diff --git a/content/docs/tutorials/serialmonitor.md b/content/docs/tutorials/serialmonitor.md new file mode 100644 index 00000000..abdd46fb --- /dev/null +++ b/content/docs/tutorials/serialmonitor.md @@ -0,0 +1,414 @@ +--- +title: "Serial Monitor" +weight: 3 +description: | + How to write to and read from the serial port. +--- + +When you run a Go program on a desktop computer, you can use the `fmt.Print()`, +`fmt.Println()`, and `fmt.Printf()` functions from the Go standard [fmt +package](https://pkg.go.dev/fmt) to print strings and numbers to the terminal +program on the desktop computer. The Go language also supports the low-level +[print() and println()](https://go.dev/ref/spec#Bootstrapping) built-in +functions to print to the terminal. + +A TinyGo program running on a microcontroller can use those same functions to +print strings and numbers to its serial monitor port and have them appear on the +terminal program on the host computer. By default, the `fmt` functions and the +`print()/println()` functions are configured to send to the `machine.Serial` +object of the microcontroller. + +On some microcontrollers, the `machine.Serial` object is configured to send to +the +[UART](https://en.wikipedia.org/wiki/Universal_asynchronous_receiver-transmitter) +chip, which is often wired to a [USB-to-serial +adapter](https://en.wikipedia.org/wiki/USB-to-serial_adapter) chip on the dev +board. The adapter chip converts the serial bits into USB packets to the host +computer. On other microcontrollers, the USB controller is built directly into +the [microcontroller SoC](https://en.wikipedia.org/wiki/System_on_a_chip). The +`machine.Serial` object on these microcontrollers is configured to send to the +USB bus directly, instead of going through a USB-to-serial adapter. + +In the context of this tutorial, it does not matter whether the microcontroller +uses a UART controller or a USB controller. In both cases, the microcontroller +will appear as a serial device on the host computer which can communicate via +applications that read from and write to the serial port on the host computer. + +## Serial Output + +### Using `fmt.Print()` and `fmt.Println()` + +Here is a sample program that writes a line every second to the `machine.Serial` +port: + +```go +package main + +import ( + "fmt" + "time" +) + +func main() { + count := 0 + for { + fmt.Println(count, ": Hello, World") + time.Sleep(time.Millisecond * 1000) + count++ + } +} +``` + +This can be flashed to the microcontroller using the `tinygo flash` command +described in the [Blinky tutorial]({{}}). + +### Using `print()` and `println()` + +One problem with the above program is that `fmt` is a large package that +consumes substantial amount of flash memory on a microcontroller. The built-in +functions `print()` and `println()` consume far less resources. The above +program can be written like this: + +```go +package main + +import ( + "time" +) + +func main() { + count := 0 + for { + println(count, ": Hello, World") + time.Sleep(time.Millisecond * 1000) + count++ + } +} +``` + +An estimate of the flash memory consumption can be printed by the TinyGo +compiler using the [-size]({{}}) flag. +Here is a table that shows the 2 versions of the program above for some +microcontrollers that I have readily available: + +``` ++-----------------+---------------+-----------+ +| Board Type | fmt.Println() | println() | ++-----------------+---------------+-----------+ +| Arduino Zero | 43532 | 7328 | +| Seeeduino Xiao | 43532 | 7388 | +| STM32 BluePill | 41756 | 6296 | +| ESP8266 D1 Mini | 44961 | 3588 | +| ESP32 | 42410 | 3335 | ++-----------------+---------------+-----------+ +``` + +The `fmt` package increases flash memory consumption by 35 kB to 40 kB. On some +microcontrollers with limited amount of flash memory, (e.g. the STM32 Blue Pill +with 64 kB of flash, the Arduino Zero or Seeeduino Xiao both with 256 kB of +flash), it may be worth avoiding the overhead of the `fmt` package by using the +built-in `print()` and `println()` instead. + +## Serial Monitor on Host Computer + +To see the output of the serial port from the microcontroller, we need to run a +serial monitor application on the host computer. There are many ways to do this, +but the easiest is probably the `tinygo monitor` subcommand which is built +directly into the `tinygo` program itself. + +### `monitor` subcommand + +After flashing the program above, run the `tinygo monitor` program to see the +output every second from the microcontroller: + +``` +$ tinygo monitor +Connected to /dev/ttyACM0. Press Ctrl-C to exit. +4 : Hello, World +5 : Hello, World +[...] +``` + +In this example, the serial monitor missed the first 4 lines of "Hello, World" +(0 to 3) because the program started to print those lines immediately after +flashing, but before the serial monitor was connected. + +### `-monitor` flag + +It is often useful to automatically start the monitor immediately after flashing +your program to the microcontroller. The `tinygo flash` command takes an +optional `-monitor` flag to accomplish this: + +``` +$ tinygo flash -target=xiao -monitor +``` + +On some microcontrollers, the `-monitor` flag fails with the following error +message because the monitor starts too quickly: + +``` +$ tinygo flash -target=arduino-zero -monitor +[...] +Connected to /dev/ttyACM0. Press Ctrl-C to exit. +error: read error: Port has been closed +``` + +If this happens, you can chain the `flash` and `monitor` subcommands manually, +with a 1 or 2-second delay between the two commands. On Linux or MacOS, the +command invocation looks like this: + +``` +$ tinygo flash -target=arduino-zero && sleep 1 && tinygo monitor +``` + +(The `&&` separator runs the next command only if the previous command completed +without errors. This is safer than using the semicolon `;` separator because the +semicolon continues to execute commands even if the previous command returned an +error code.) + +### Baud Rate + +The default [baud rate](https://en.wikipedia.org/wiki/Serial_port#Speed) of the +serial port for almost all microcontrollers supported by TinyGo is 115200. The +exceptions are boards using the AVR processors ([Arduino Nano]({{}}), [Arduino Mega 1280]({{}}), [Arduino Mega 2560]({{}})). On these, the serial port +is set to 9600, so you need to override the baud rate of `tinygo monitor` like +this: + +``` +$ tinygo monitor -baudrate=9600 +``` + +You can combine the `flash` subcommand, the `-monitor` flag, and the `-baudrate` +flag into a single invocation like this: + +``` +$ tinygo flash -target arduino-nano -monitor -baudrate 9600 +``` + +(Notice that the `=` after each flag has been replaced with a space. It's an +alternative syntax that some people prefer because a space is easier to type +than an equal sign `=`.) + +### Serial Port on Host + +The microcontroller will be assigned a serial port on the host computer. If you +have only a single microcontroller attached, you will normally not need to worry +about what these serial ports are called. The `tinygo monitor` will +automatically figure out which serial port to use. + +On Linux machines, the serial port will have a `USB` prefix or an `ACM` prefix +like this: + +* `/dev/ttyUSB0` +* `/dev/ttyACM0` + +On MacOS machines, the serial port will look like this: + +* `/dev/cu.usbserial-1420` +* `/dev/cu.usbmodem6D8733AC53571` + +On Windows machines, the serial port looks something like: + +* `COM1` +* `COM31` + +### Multiple Microcontrollers + +If you have more than one microcontroller attached to the host computer, the +`tinygo flash` and `tinygo monitor` subcommands can *sometimes* figure out which +port it is using, but they will sometimes print out an error message, like this: + +``` +$ tinygo flash -target arduino-nano +error: multiple serial ports available - use -port flag, +available ports are /dev/ttyACM0, /dev/ttyUSB0 +``` + +You then need to supply the `-port` flag to identify the microcontroller that +you want to flash and monitor: + +``` +$ tinygo flash -target=arduino-nano -port=/dev/ttyUSB0 + +$ tinygo monitor -port=/dev/ttyUSB0 -baudrate=9600 +``` + +Sometimes it is possible to combine the two commands into a single command even +in the presence of multiple microcontrollers: + +``` +$ tinygo flash -target xiao -monitor +``` + +But sometimes, combining `flash` and `monitor` into a single command does not +work. In that case, you can issue the `flash` and `monitor` commands separately. +But it is often easier to just pull out the extra microcontroller(s) so that +only a single board is connected to the host computer. + +``` +$ tinygo flash -target=arduino-nano -monitor +error: multiple serial ports available - use -port flag, +available ports are /dev/ttyACM0, /dev/ttyUSB0 + +$ tinygo flash -target=arduino-nano -monitor -port=/dev/ttyUSB0 -baudrate=9600 +[...] +avrdude: 4238 bytes of flash verified +avrdude done. Thank you. +[...] +error: multiple serial ports available - use -port flag, +available ports are /dev/ttyACM0, /dev/ttyUSB0 +``` + +## Serial Input + +Occasionally it is useful to send characters from the host computer to the +microcontroller. The following program reads a single byte from the +`machine.Serial` object and prints the character back to the host computer. + +The caveat is that the `Serial.ReadByte()` feature is *not* currently +implemented on every microcontroller supported by TinyGo. For example, the +following program does not work on the ESP32 or the ESP8266. + +```go +package main + +import ( + "machine" + "time" +) + +func main() { + time.Sleep(time.Millisecond * 2000) + println("Reading from the serial port...") + + for { + c, err := machine.Serial.ReadByte() + if err == nil { + if c < 32 { + // Convert nonprintable control characters to + // ^A, ^B, etc. + machine.Serial.WriteByte('^') + machine.Serial.WriteByte(c + '@') + } else if c >= 127 { + // Anything equal or above ASCII 127, print ^?. + machine.Serial.WriteByte('^') + machine.Serial.WriteByte('?') + } else { + // Echo the printable character back to the + // host computer. + machine.Serial.WriteByte(c) + } + } + + // This assumes that the input is coming from a keyboard + // so checking 120 times per second is sufficient. But if + // the data comes from another processor, the port can + // theoretically receive as much as 11000 bytes/second + // (115200 baud). This delay can be removed and the + // Serial.Read() method can be used to retrieve + // multiple bytes from the receive buffer for each + // iteration. + time.Sleep(time.Millisecond * 8) + } +} +``` + +You can flash this program to the microcontroller (in this example, a SAMD21 M0+ +clone that emulates an Arduino Zero), and fire up the monitor like this: + +``` +$ tinygo flash -target=arduino-zero +$ tinygo monitor +Connected to /dev/ttyACM0. Press Ctrl-C to exit. +Reading from the serial port... +abcdef^A^B^D^E^F^G^H^I^J^K^L^M^N^O^P^R^T^U^V^W^X^Y^^^[^]^_^? +``` + +Type a few characters in the `tinygo monitor`, for example "abcdef". You should +see the characters echoed back by the microcontroller, as shown above. If you +type a [nonprintable control +characters](https://en.wikipedia.org/wiki/C0_and_C1_control_codes), these are +echoed back as 2 characters: the caret character `^` and a letter representing +the control character. For example, typing Control-P prints `^P`. + +Of the 32 possible control characters, some of them are intercepted by the +`tinygo monitor` itself instead of being sent to the microcontroller: + +* Control-C: terminates the `tinygo monitor` +* Control-Z: suspends the `tinygo monitor` and drops back into shell +* Control-\\: terminates the `tinygo monitor` with a stack trace +* Control-S: flow control, suspends output to the console +* Control-Q: flow control, resumes output to the console +* Control-@: thrown away by `tinygo monitor` + +## Alternative Serial Monitors + +There are many alternative serial monitor programs that can be used instead of +`tinygo monitor`. The setup is slightly more complicated because you will need +to supply the serial port and baud rate of the microcontroller as described in +the [Serial Port on Host](#serial-port-on-host) and [Baud Rate](#baud-rate) +subsections above. + +### Arduino IDE + +The [Arduino IDE](https://www.arduino.cc/en/software) contains its own serial +monitor. You may choose to use that instead. You need to set the serial port +(something like `/dev/ttyUSB0` on Linux, or `/dev/cu.usbserial-1420` on MacOS), +and set the baud rate to 115200 (or 9600 on AVR processors). + +### pyserial + +The [pyserial](https://pyserial.readthedocs.io/en/latest/pyserial.html) is a +Python library that comes with its own serial monitor. Setting up a python3 +environment is a complex topic that is beyond the scope of this document. But if +you are able to install `python3` and `pip3`, you can install `pyserial` and use +its built-in `miniterm` tool roughly like this: + +``` +$ python3 -m pip install --user pyserial +$ python3 -m serial.tools.miniterm /dev/ttyUSB0 115200 +``` + +Another useful feature of `pyserial` is the `list_ports` command: + +``` +$ python3 -m serial.tools.list_ports +/dev/ttyACM0 +/dev/ttyS0 +/dev/ttyUSB0 +3 ports found +``` + +This is useful when you plug in a random microcontroller to the USB port, and +you cannot remember which serial port it is mapped to. + +### picocom + +The [picocom](https://github.com/npat-efault/picocom) terminal emulator can be +installed on both Linux and MacOS. If you are using an Ubuntu flavored Linux, +the installation is something like: + +``` +$ sudo apt install picocom +``` + +On MacOS, most people use [Homebrew](https://brew.sh/), and it can be installed +like this: + +``` +$ brew install picocom +``` + +It can be invoked like this: + +``` +$ picocom -b 115200 /dev/ttyACM0 +port is : /dev/ttyACM0 +picocom v3.1 +[...] +Type [C-a] [C-h] to see available commands +Terminal ready +``` diff --git a/content/media/video.md b/content/media/video.md index 1d4d32ec..c7b9197b 100644 --- a/content/media/video.md +++ b/content/media/video.md @@ -7,6 +7,15 @@ description: > Videos/Podcasts talking about TinyGo --- +**FOSDEM 2023 - Ron Evans - Go Even Further Without Wires** - *February 4, 2023* +https://video.fosdem.org/2023/UD2.218A/goevenfurtherwithoutwires.mp4 + +**FOSDEM 2023 - Daniel Esteban - Visually programming Gon** - *February 4, 2023* +https://video.fosdem.org/2023/UD2.218A/govisuallyprogramming.mp4 + +**GopherCon US 2022 - Donia Chaiehloudj - TinyGo: Getting the Upper Hen** - *October 8, 2022* +https://www.youtube.com/watch?v=D46NzhBoQC0 + **Pragmatik.tech - Charath Ranganathan - Multiple videos on TinyGo and Raspberry Pi Pico** - *July 2022 onwards* https://www.youtube.com/channel/UChxDHx-FThGJscOn3ljTi6A diff --git a/static/images/i2c-target-flow.png b/static/images/i2c-target-flow.png new file mode 100644 index 00000000..bf816395 Binary files /dev/null and b/static/images/i2c-target-flow.png differ