package main
import (
"machine"
"time"
)
func main() {
led := machine.LED
led.Configure(machine.PinConfig{Mode: machine.PinOutput})
for {
led.Low()
time.Sleep(time.Millisecond * 100)
led.High()
time.Sleep(time.Millisecond * 100)
}
}
pacman -s avr-gcc avr-libc avrdude tinygo
cd to this directory
tinygo flash -target arduino
It worked! I then tried a go-routine, which would not compile and learned this:
scheduler: Use the specified scheduler. The default scheduler varies by
platform. For example, AVR currently defaults to none because it has such
limited memory while asyncify and tasks are used for other platforms.
Normally you do not need to override the default except on AVR where you can
optionally select the tasks scheduler if you want concurrency.
scheduler=tasks The tasks scheduler is a scheduler much like an RTOS
available for non-WASM platforms. This is usually the preferred scheduler.
scheduler=asyncify The asyncify scheduler is a scheduler for WASM based
off of Binaryen’s Asyncify Pass.
scheduler=none The none scheduler disables scheduler support, which
means that goroutines and channels are not available. It can be used to
reduce firmware size and RAM consumption if goroutines and channels are
not needed.
Microbit
Made this program a little more complex with two goroutines:
It worked! Two LEDs are flashing at different rates. This is a more capable 32-bit CPU so goroutines work.
Not sure what host tools are needed, arm-gcc, etc. was already installed – not sure what it uses under the hood. I ran strace on tinygo and did not see any evidence it is calling gcc.
Tinygo has advanced a lot since I last looked at it and appears to be useable for lab work, and perhaps even product programming. The development experience is quite nice.
I was able to run a version on the Arduino that had a goroutine and running tinygo with the -scheduler tasks option. However, when I tried to use channels, I got a compile error.
TinyGo provides a nice -size option which shows how much flash and ram is being used:
The scheduler adds considerable overhead, but it’s interesting more flash is required on the AVR than the ARM MCU.
The ATMega328P MCU on the Arduino has 32KB of flash and 2KB of SRAM, so in either case it seems we have enough left to write a sizable application.
The nRF51822 MCU in the microbit v1 has 256KB of flash and 16KB SRAM, so we have lots of space in this device for applications, however I’m not sure if the nRF stack requires some space as well that is not reported here.
The microbit v2 has 512KB of flash and 128KB of SRAM.
Arm instruction set produced most compact code in my experience I have seen WebKit compiled for
Arm 32bit is almost 20% smaller compared to mips everything else remaining same. It will be interesting to see how density compares with RISCV
