I want to use TinyGo for the Teensy 3.6, which is powered by the MK66FX1M0VMD18, a NXP Kinetis K66 processor. TinyGo does not currently support any NXP device.

• [x] Add SVD
  • posborne/cmsis-svd#93
• [x] src/device/nxp/mk66f18.go
  • I updated gen-device-svd to work with NXP SVDs
• [x] src/runtime/runtime_nxpmk66f18.go (and maybe runtime_nxp.go)
• [x] src/machine/machine_nxpmk66f18.go (and maybe machine_nxp.go)
• [x] src/machine/board_teensy36.go
  • I think I can just pull this from #548
• [x] targets/nxpmk66f18.ld, targets/nxpmk66f18.json
• [x] targets/teensy36.json

This is just a tracking issue for any outstanding work required for us to compile a vecty-style web app into WASM with tinygo. I think this would be a fantastic milestone for this repo and the Go WASM community at large, so lets see what remains outstanding.

• Channels
• syscall/js callback support
• a subset of reflect including
  • reflect.ValueOf, reflect.TypeOf, reflect.New and the following functions of the reflect.Value type:
    • Kind, Elem, String, Interface, Type, NumField, Field, Set

Would love to have @slimsag take a quick look at this if possible, but otherwise I think @bketelsen will know the best what is outstanding.

Not all architectures are supported yet. In particular, the current design doesn't support WebAssembly. Other architectures (avr, xtensa, riscv64) can be supported but are left as a TODO.

This PR does result in an increase in code size if either defer or panic is used. There is no way to turn this feature off with this PR, but I don't think we should do that for the following reasons:

• The code size increase only happens when defer or panic is used (especially defer). If you really care about code size, you may want to avoid those.
• Having another knob to configure the compiler is a maintenance burden. We already have quite a few (-gc, -scheduler).

To give an idea of the code size change, here is the difference in binary size before and after the last commit of this PR:

before  after   diff
 10796  10796      0  0.00%  tinygo build -size short -o ./build/test.hex -target=itsybitsy-m0 ./examples/adxl345/main.go
 13708  13708      0  0.00%  tinygo build -size short -o ./build/test.hex -target=pybadge ./examples/amg88xx
  9088   9088      0  0.00%  tinygo build -size short -o ./build/test.hex -target=itsybitsy-m0 ./examples/apa102/main.go
 10108  10108      0  0.00%  tinygo build -size short -o ./build/test.hex -target=itsybitsy-m0 ./examples/apa102/itsybitsy-m0/main.go
  6524   6524      0  0.00%  tinygo build -size short -o ./build/test.hex -target=microbit ./examples/at24cx/main.go
 10516  10516      0  0.00%  tinygo build -size short -o ./build/test.hex -target=itsybitsy-m0 ./examples/bh1750/main.go
  9672   9672      0  0.00%  tinygo build -size short -o ./build/test.hex -target=itsybitsy-m0 ./examples/blinkm/main.go
 13772  13772      0  0.00%  tinygo build -size short -o ./build/test.hex -target=itsybitsy-m0 ./examples/bmp180/main.go
 12380  12380      0  0.00%  tinygo build -size short -o ./build/test.hex -target=trinket-m0 ./examples/bmp388/main.go
  6724   6724      0  0.00%  tinygo build -size short -o ./build/test.hex -target=bluepill ./examples/ds1307/sram/main.go
  4396   4396      0  0.00%  tinygo build -size short -o ./build/test.hex -target=microbit ./examples/easystepper/main.go
 11096  11096      0  0.00%  tinygo build -size short -o ./build/test.hex -target=itsybitsy-m0 ./examples/hcsr04/main.go
  5596   5596      0  0.00%  tinygo build -size short -o ./build/test.hex -target=microbit ./examples/hd44780/customchar/main.go
  5580   5580      0  0.00%  tinygo build -size short -o ./build/test.hex -target=microbit ./examples/hd44780/text/main.go
 11360  11360      0  0.00%  tinygo build -size short -o ./build/test.hex -target=arduino-nano33 ./examples/hd44780i2c/main.go
 15640  15640      0  0.00%  tinygo build -size short -o ./build/test.hex -target=microbit ./examples/hub75/main.go
 10780  10780      0  0.00%  tinygo build -size short -o ./build/test.hex -target=pyportal ./examples/ili9341/basic
 11804  11804      0  0.00%  tinygo build -size short -o ./build/test.hex -target=xiao ./examples/ili9341/basic
 29628  29628      0  0.00%  tinygo build -size short -o ./build/test.hex -target=pyportal ./examples/ili9341/pyportal_boing
 10832  10832      0  0.00%  tinygo build -size short -o ./build/test.hex -target=pyportal ./examples/ili9341/scroll
 11884  11884      0  0.00%  tinygo build -size short -o ./build/test.hex -target=xiao ./examples/ili9341/scroll
 12752  12752      0  0.00%  tinygo build -size short -o ./build/test.hex -target=circuitplay-express ./examples/lis3dh/main.go
 15304  15304      0  0.00%  tinygo build -size short -o ./build/test.hex -target=microbit ./examples/lsm303agr/main.go
 12780  12780      0  0.00%  tinygo build -size short -o ./build/test.hex -target=arduino-nano33 ./examples/lsm6ds3/main.go
 13036  13036      0  0.00%  tinygo build -size short -o ./build/test.hex -target=itsybitsy-m0 ./examples/mag3110/main.go
 10500  10500      0  0.00%  tinygo build -size short -o ./build/test.hex -target=itsybitsy-m0 ./examples/mcp3008/main.go
 10540  10540      0  0.00%  tinygo build -size short -o ./build/test.hex -target=itsybitsy-m0 ./examples/mma8653/main.go
 10388  10388      0  0.00%  tinygo build -size short -o ./build/test.hex -target=itsybitsy-m0 ./examples/mpu6050/main.go
  4444   4444      0  0.00%  tinygo build -size short -o ./build/test.hex -target=microbit ./examples/pcd8544/setbuffer/main.go
  4452   4452      0  0.00%  tinygo build -size short -o ./build/test.hex -target=microbit ./examples/pcd8544/setpixel/main.go
  2468   2468      0  0.00%  tinygo build -size short -o ./build/test.hex -target=arduino ./examples/servo
  8732   8732      0  0.00%  tinygo build -size short -o ./build/test.hex -target=pybadge ./examples/shifter/main.go
  5072   5072      0  0.00%  tinygo build -size short -o ./build/test.hex -target=microbit ./examples/ssd1306/i2c_128x32/main.go
  5332   5332      0  0.00%  tinygo build -size short -o ./build/test.hex -target=microbit ./examples/ssd1306/spi_128x64/main.go
  5116   5116      0  0.00%  tinygo build -size short -o ./build/test.hex -target=microbit ./examples/ssd1331/main.go
  5696   5696      0  0.00%  tinygo build -size short -o ./build/test.hex -target=microbit ./examples/st7735/main.go
  5448   5448      0  0.00%  tinygo build -size short -o ./build/test.hex -target=microbit ./examples/st7789/main.go
 14160  14160      0  0.00%  tinygo build -size short -o ./build/test.hex -target=circuitplay-express ./examples/thermistor/main.go
  8088   8088      0  0.00%  tinygo build -size short -o ./build/test.hex -target=circuitplay-bluefruit ./examples/tone
 10592  10592      0  0.00%  tinygo build -size short -o ./build/test.hex -target=arduino-nano33 ./examples/tm1637/main.go
 17064  17064      0  0.00%  tinygo build -size short -o ./build/test.hex -target=itsybitsy-m0 ./examples/vl53l1x/main.go
  5828   5828      0  0.00%  tinygo build -size short -o ./build/test.hex -target=microbit ./examples/waveshare-epd/epd2in13/main.go
  5364   5364      0  0.00%  tinygo build -size short -o ./build/test.hex -target=microbit ./examples/waveshare-epd/epd2in13x/main.go
  5684   5684      0  0.00%  tinygo build -size short -o ./build/test.hex -target=microbit ./examples/waveshare-epd/epd4in2/main.go
  8692   8692      0  0.00%  tinygo build -size short -o ./build/test.hex -target=circuitplay-express ./examples/ws2812
  1420   1420      0  0.00%  tinygo build -size short -o ./build/test.hex -target=arduino   ./examples/ws2812
   720    720      0  0.00%  tinygo build -size short -o ./build/test.hex -target=digispark ./examples/ws2812
 24788  24788      0  0.00%  tinygo build -size short -o ./build/test.hex -target=trinket-m0 ./examples/bme280/main.go
 13528  13528      0  0.00%  tinygo build -size short -o ./build/test.hex -target=circuitplay-express ./examples/microphone/main.go
 13124  13124      0  0.00%  tinygo build -size short -o ./build/test.hex -target=circuitplay-express ./examples/buzzer/main.go
 15136  15136      0  0.00%  tinygo build -size short -o ./build/test.hex -target=trinket-m0 ./examples/veml6070/main.go
  8664   8664      0  0.00%  tinygo build -size short -o ./build/test.hex -target=arduino-nano33 ./examples/l293x/simple/main.go
 10072  10072      0  0.00%  tinygo build -size short -o ./build/test.hex -target=arduino-nano33 ./examples/l293x/speed/main.go
  8632   8632      0  0.00%  tinygo build -size short -o ./build/test.hex -target=arduino-nano33 ./examples/l9110x/simple/main.go
 10104  10104      0  0.00%  tinygo build -size short -o ./build/test.hex -target=arduino-nano33 ./examples/l9110x/speed/main.go
 15264  15264      0  0.00%  tinygo build -size short -o ./build/test.hex -target=circuitplay-express ./examples/lis2mdl/main.go
 10512  10512      0  0.00%  tinygo build -size short -o ./build/test.hex -target=arduino-nano33 ./examples/max72xx/main.go
  6094   6094      0  0.00%  tinygo build -size short -o ./build/test.hex -target=arduino ./examples/keypad4x4/main.go
  8952   8952      0  0.00%  tinygo build -size short -o ./build/test.hex -target=xiao ./examples/pcf8563/clkout/
  9976   9976      0  0.00%  tinygo build -size short -o ./build/test.hex -target=feather-m0 ./examples/ina260/main.go
  8656   8656      0  0.00%  tinygo build -size short -o ./build/test.hex -target=nucleo-l432kc ./examples/aht20/main.go
  7492   7496      4  0.05%  tinygo build -size short -o ./build/test.hex -target=hifive1b ./examples/ssd1351/main.go
 21300  21332     32  0.15%  tinygo build -size short -o ./build/test.hex -target=arduino-nano33 ./examples/espat/espconsole/main.go
 22460  22492     32  0.14%  tinygo build -size short -o ./build/test.hex -target=arduino-nano33 ./examples/espat/esphub/main.go
 22492  22524     32  0.14%  tinygo build -size short -o ./build/test.hex -target=arduino-nano33 ./examples/espat/espstation/main.go
 10912  10952     40  0.37%  tinygo build -size short -o ./build/test.hex -target=itsybitsy-m0 ./examples/mcp23017/main.go
 11356  11396     40  0.35%  tinygo build -size short -o ./build/test.hex -target=itsybitsy-m0 ./examples/mcp23017-multiple/main.go
  6312   6352     40  0.63%  tinygo build -size short -o ./build/test.hex -target=nucleo-f103rb ./examples/shiftregister/main.go
 10016  10072     56  0.56%  tinygo build -size short -o ./build/test.hex -target=pyportal ./examples/touch/resistive/fourwire/main.go
 12824  12880     56  0.44%  tinygo build -size short -o ./build/test.hex -target=pyportal ./examples/touch/resistive/pyportal_touchpaint/main.go
  6124   6184     60  0.98%  tinygo build -size short -o ./build/test.hex -target=microbit ./examples/microbitmatrix/main.go
 15844  15992    148  0.93%  tinygo build -size short -o ./build/test.hex -target=arduino-nano33 ./examples/wifinina/webclient/main.go
 53660  54460    800  1.49%  tinygo build -size short -o ./build/test.hex -target=itsybitsy-m0 ./examples/bmi160/main.go
 58404  59316    912  1.56%  tinygo build -size short -o ./build/test.hex -target=itsybitsy-m0 ./examples/flash/console/spi
 56408  57336    928  1.65%  tinygo build -size short -o ./build/test.hex -target=pyportal ./examples/flash/console/qspi
 61000  61976    976  1.60%  tinygo build -size short -o ./build/test.hex -target=feather-m4 ./examples/sdcard/console/
247992 249480   1488  0.60%  tinygo build -size short -o ./build/test.hex -target=pyportal ./examples/ili9341/slideshow
 20004  21596   1592  7.96%  tinygo build -size short -o ./build/test.hex -target=arduino-nano33 ./examples/wifinina/udpstation/main.go
 61028  62724   1696  2.78%  tinygo build -size short -o ./build/test.hex -target=p1am-100 ./examples/p1am/main.go
 52840  54748   1908  3.61%  tinygo build -size short -o ./build/test.hex -target=feather-m0 ./examples/gps/i2c/main.go
 52560  54468   1908  3.63%  tinygo build -size short -o ./build/test.hex -target=feather-m0 ./examples/gps/uart/main.go
 15196  17328   2132 14.03%  tinygo build -size short -o ./build/test.hex -target=bluepill ./examples/ds1307/time/main.go
 29552  31752   2200  7.44%  tinygo build -size short -o ./build/test.hex -target=arduino-nano33 ./examples/wifinina/ntpclient/main.go
 54996  57332   2336  4.25%  tinygo build -size short -o ./build/test.hex -target=itsybitsy-m0 ./examples/mcp2515/main.go
 51460  53876   2416  4.69%  tinygo build -size short -o ./build/test.hex -target=arduino-nano33 ./examples/wifinina/tcpclient/main.go
 61624  64300   2676  4.34%  tinygo build -size short -o ./build/test.hex -target=xiao ./examples/pcf8563/alarm/
 60232  62924   2692  4.47%  tinygo build -size short -o ./build/test.hex -target=xiao ./examples/pcf8563/time/
 61528  64220   2692  4.38%  tinygo build -size short -o ./build/test.hex -target=xiao ./examples/pcf8563/timer/
 49948  52684   2736  5.48%  tinygo build -size short -o ./build/test.hex -target=itsybitsy-m0 ./examples/adt7410/main.go
 52092  54828   2736  5.25%  tinygo build -size short -o ./build/test.hex -target=itsybitsy-m0 ./examples/bmp280/main.go
 44932  47668   2736  6.09%  tinygo build -size short -o ./build/test.hex -target=microbit ./examples/sht3x/main.go
 63672  67104   3432  5.39%  tinygo build -size short -o ./build/test.hex -target=feather-m0 ./examples/dht/main.go
139744 144244   4500  3.22%  tinygo build -size short -o ./build/test.hex -target=feather-m4 ./examples/sdcard/tinyfs/
 57976  62588   4612  7.96%  tinygo build -size short -o ./build/test.hex -target=itsybitsy-m0 ./examples/ds3231/main.go
 93948  99040   5092  5.42%  tinygo build -size short -o ./build/test.hex -target=wioterminal ./examples/rtl8720dn/mqttsub/
122832 128836   6004  4.89%  tinygo build -size short -o ./build/test.hex -target=wioterminal ./examples/rtl8720dn/webserver/
124396 130624   6228  5.01%  tinygo build -size short -o ./build/test.hex -target=wioterminal ./examples/rtl8720dn/webclient/
sum: 67968 (2.72%)

What you can see here:

• The overall code size increase is 2.72%.
• Many examples (about two thirds) don't change in binary size at all. Probably because they don't use defer or panic.
• Examples that increased in binary size are usually large examples, >25kB or so. It looks like they import the fmt package, which seems to use defer and /recover.

I really like this tinygo project and am trying to figure out how to add support for this neat little thing: https://wiki.makerdiary.com/nrf52840-mdk/

I've managed to add this as target:

{
	"llvm-target": "armv7em-none-eabi",
	"build-tags": ["nrf52840_mdk", "nrf52840", "nrf", "arm", "js", "wasm"],
	"linker": "arm-none-eabi-gcc",
	"pre-link-args": ["-nostdlib", "-nostartfiles", "-mcpu=cortex-m4", "-mthumb", "-T", "targets/nrf52.ld", "-Wl,--gc-sections", "-fno-exceptions", "-fno-unwind-tables", "-ffunction-sections", "-fdata-sections", "-Os", "-DNRF52840_XXAA", "-Ilib/CMSIS/CMSIS/Include", "lib/nrfx/mdk/system_nrf52.c", "src/device/nrf/nrf52.s"],
	"objcopy": "arm-none-eabi-objcopy",
	"flash": "nrfjprog -f nrf52 --sectorerase --program {hex} --reset"
}

And added machine/board_nrf52840-mdk.go (which is just a copy of board_pca10040.go for now)

// +build nrf,nrf52840_mdk

package machine

// LEDs on the nrf52840-mdk (nRF52840 dev board)
const (
	LED  = LED1
	LED1 = 17
	LED2 = 18
	LED3 = 19
	LED4 = 20
)

// Buttons on the nrf52840-mdk (nRF52840 dev board)
const (
	BUTTON  = BUTTON1
	BUTTON1 = 13
	BUTTON2 = 14
	BUTTON3 = 15
	BUTTON4 = 16
)

When I now run: tinygo flash -target=nrf52840-mdk examples/button

I get:

github.com/aykevl/tinygo/src/runtime/runtime_nrf.go:33:12: invalid operation: nrf.UART0 (variable of type *device/nrf.UART_Type) has no field or method PSELTXD

So, obviously, I'm missing something. But, I can't add "nrf52" to the build-tags, because then I get a bunch of re-declaration errors:

GPIO_PIN_CNF_DRIVE_D0S1 redeclared in this block
...

So, anyone here wanna help me adding support for this dev board? I'm new to this code, and figured it would be quicker to ask about this here since I couldn't find anything on the wiki about how to add a new board. Wasn't as straight forward as I thought, unless I'm missing something.

Thanks!

This saves about a kilobyte of flash, and attempts to address the AVR size increase issue in #1181. Similar to #1181 and the avr-libc allocator, this is a best-fit allocator.

Please add support for the Ardunio MEGA 2560 boards, as this board provides a larger number of GPIO's than most of the other boards (54 off).

https://www.arduino.cc/en/Main/arduinoBoard_Mega2560?setlang=en

We need to define an API to interact with interrupts in TinyGo in an idiomatic way. At the moment, there is some support but they rely on magic comments and are hard to use correctly. For example:

//go:export RTC1_IRQHandler
func handleRTC1() {
    // ...
}

Here are a few requirements I could come up with, for such an API:

• It should be portable across processor architectures. For example: Cortex-M, AVR, traditional ARM, RISC-V (both the older PLIC design and the upcoming standard, which will likely be CLIC-based), perhaps others? I've seen roughly these designs:
  • Full interrupt vector table with hardware stacking/unstacking, as implemented in Cortex-M.
  • Interrupt vector, but apart from saving/restoring the PC the interrupt controller expects the software to handle everything. This is the case for AVR and the new CLIC-based interrupt scheme in RISC-V.
  • Single entry point with software vectoring. This is the case for the old RISC-V design, can optionally be used with the new CLIC-based RISC-V interrupt design, and is used on the older ARM core in the GameBoy Advance.
• It should be efficient to implement. That is, it should not use extra RAM for the vector table on Cortex-M or always require jumping through a handler of some sort if that is not absolutely necessary.
• It should fit well in the Go language. That means it should not conflict too much with normal Go-style programs: lots of goroutines that perform blocking operations and a scheduler that switches between all these goroutines.
• It should be easy to use.

This is the design I came up with uses two different kinds of interrupt handlers, as I recognize there are certain interrupts that are easier to use in one style or in the other:

• Low-level interrupts, much like you would use in your classical C or assembly based embedded application. This should map as closely as possible to the hardware and be as efficient as possible. Such interrupts have limitations, such as being unable to use heap allocation or not being able to perform blocking operations (but non-blocking channel operations should still be allowed). The idea is that you register a function as an interrupt and possibly need to manually enable/configure it. These interrupts are usually run in response to certain events when some action needs to be performed, such as pressing a button.
• High level blocking operations. This is closer to how I/O is usually done in Go. The typical example would be waiting for an SPI transmission to be completed before continuing.

Here is my proposed API in pseudo-Go:

// Low level interrupt style
type runtime.Interrupt struct { ... }
func runtime.NewInterrupt(interruptNumber uintptr, handler func()) runtime.Interrupt {}
func (i runtime.Interrupt) Enable() {}
func (i runtime.Interrupt) Disable() {}
func (i runtime.Interrupt) IsEnabled() {}
func (i runtime.Interrupt) SetPriority(priority uint8) {} // TODO: how should priority numbers be specified?

// High level interrupt style
func runtime.BlockOnInterrupt(interruptNumber uintptr) {}

This system will have some limitations:

• The interrupt number must always be a compile-time constant. If it is not, the compiler would not be able to determine where to place the interrupt in the interrupt vector and could thus not keep the interrupt vector table in ROM.
• An interrupt cannot be registered twice. While it is possible for the compiler to update it and pick the last registration (or the first), this will probably be unexpected and better to show an error instead.
• The runtime.NewInterrupt call must always be called in global scope, to initialize a global variable (this could be _). This makes sure the compiler can resolve the call at compile time.
• The handler must be statically known to the compiler. This limitation may be lifted later by letting the compiler write a wrapper function - but I don't think this will often be necessary.

The high level implementation could be implemented by a compiler transformation that inserts a new interrupt handler and suspends/resumes the goroutine at the right time. Multiple suspend points should be allowed (unlike runtime.NewInterrupt).

An example of the low-level API:

var rtc1Interrupt = runtime.NewInterrupt(nrf.IRQ_RTC1, func() {
    // handler code
})
func init() {
    rtc1Interrupt.SetPriority(prio) // TODO: how should priorities be numbered?
    rtc1Interrupt.Enable()
}

An example of the high-level API:

func (spi SPI) Transfer(w byte) (byte, error) {
    // send byte
    for /* has byte been sent? */ {
        runtime.BlockOnInterrupt(nrf.IRQ_SPI0)
    }
    // read response byte
}

The compiler may eventually learn to rewrite high-level blocking operations to low-level interrupt handlers, if it can determine this would result in equivalent behavior. An example would be a single-function goroutine that is started once at startup and only ever blocks on a single interrupt, with no external calls.

Problems I see now with this proposal:

• Interrupts should be usable by the machine package, and they currently aren't because the runtime package imports the machine package. Perhaps they should be moved to a separate package?
• How to specify the priority of interrupts when blocking on them? Is this relevant at all?
• There might be race conditions in the BlockOnInterrupt call (TOCTOU).

This can be useful to test improvements in LLVM master and to make it possible to support LLVM 11 for the most part already before the next release. That also allows catching LLVM bugs early to fix them upstream.

Note that tests do not yet pass for this LLVM version, but the TinyGo compiler can be built with the binaries from apt.llvm.org (at the time of making this commit).

One concrete example of what I want to do with this change is to test/improve AVR support: upstream master has a number of improvements that aren't included yet in LLVM 10.

Note that #1055 should be merged first.

I believe this works without issues, but I've also got to figure out LLVM 10 at the same time. I also have only checked 0.11.0, not 0.12.0 yet. So let's see how CI feels about this.

Adding a tracking case for monitoring progress of WASM target when building from OSX.

OSX developers cannot use tinygo to build WASM targets because WASM is an experimental feature in LLVM

$ tinygo build -o test.wasm test.go
error: No available targets are compatible with this triple.

The Facts:

• Tinygo can build on OSX when LLVM 7 is installed via brew. However, WASM targets are experimental in LLVM 7 and not supported by the homebrew recipe.
• WASM will be supported in LLVM 8 (Expected release March 2019)

RELATED:

• #47 OSX Support
• Tracking LLVM 8 progress
• Rejected PR to add WASM target to LLVM via Homebrew

Possible Workarounds:

• Wait for LLVM 8 in March of 2019
• Build LLVM 7 from source with full WASM support (Does this work?)
• ???

Within a time we will have a significant number of supported machines/boards. This will bloat the base tinygo srcs.

Proposal

This proposal is about to split the machines-related code in "bundles". The existing code allows to merge regular Go sources and TinyGo (btw, src/os/exec/exec.go never being used with current implementation because os/exec is overriden by Go sources). The approach is to traverse bundles src directories and merge the contents with the TinyGo sources in the cached root. Same should be done for lib and bin if present. The per bundle targets should be merged separately.

Dependencies In order to support cross-bundle dependencies, it's possible to wrap the go install command to be called within bundle directory (set the GOPATH variable). The existing PoC should be re-worked to follow pkg-structure of Go packages.

Caching At the first implementation the targets being traversed each invocation and only missing symlinks are re-created. The bundle modifications (install, update, remove) should invalidate the existing cache.

The PoC that splits up the nrfx package: https://github.com/tinygo-org/tinygo/pull/3361

• added new board feather-m0-express for the Adafruit Feather M0 Express board (inspired by feather-m0)

I'm still really confused regarding the UART though, not sure whether this is correct. So far I struggle to test it with a CMSIS-DAP debugger & USB-to-TTY-Serial on the other side.

Pinout used:

This PR attempts to add some basic support for PDM and implements it for the Nordic 52840 based SoCs and the CircuitPlayground-Bluefruit board.

I could imagine maybe the configuration and API can be filled out a bit more to do things like configure and fetch sample rate. I'm completely new to tinygo and have only played with microcontrollers here and there as a hobby, so hopefully I haven't done anything too boneheaded.

With the change in this PR, I was able to complete a tinygo version of the Adafruit VU meter with my son on the Bluefruit. I couldn't easily figure out how to write to the "CPLAYBTBOOT" onboard flash filesystem to try storing a WAV file, but I did go so far as to echo out a 1 second integer buffer (per the PR's example code) and save that as a WAV on my laptop and play it back. So I think in general it works.

As a side note, I noticed that there is a "microphone" PDM driver that can run I2S in PDM mode. I think maybe this is a quirk of a specific board, to be able to run I2S in PDM mode? I wonder if it would make sense later to refactor this as a PDM device and just make the controller-specific implementation leverage its I2S. It was a bit confusing to me to see this microphone driver documented as a PDM but then need an I2S in order to use it.

Thanks!

I am currently debugging this code that tries to delete the keys in a map (to empty it while retaining bucket storage)

https://github.com/corazawaf/coraza/blob/v3/dev/internal/corazawaf/rulegroup.go#L105

(for the below, note that I tried copying the keys into a slice before deleting to see if it was iterator+delete behavior problem but it was all the same so simplified back to normal map iteration).

I noticed a memory leak and after adding if len(transformationCache) > 0 { panic } after the deletion could verify that the map wasn't getting cleared with tinygo wasm. It works fine with Go.

I have added this instrumentation to hashmap.go

https://github.com/anuraaga/tinygo/compare/custom-gc...anuraaga:tinygo:hashmapdelete-debug?expand=1

And shrunk down the test to similar one as last time

https://github.com/corazawaf/coraza-proxy-wasm/compare/main...anuraaga:coraza-1225?expand=1#diff-173fbfd8d8844658344b121461b4290d0a85230caae9825240705df8130e8b75R33 ~/go/bin/tinygo build -scheduler=none -target=wasi -opt=2 -o mapbench.wasm

The debug output looks something like this

hashmapBinaryGet 0x0001019c 0x0000ffd0 16 1666840535
could find key
hashmapBinaryDelete 0x0001019c 0x0000ffb8 16 1666840535
delete could find key 0x0001019c 0x0000ffb8 1666840535
hashmapBinaryGet 0x0001019c 0x0000ffd0 16 1666840535
couldn't find key

The key address for get is 0x0000ffd0 and delete is 0x0000ffb8. That being said the hash is the same in this example so it's being able to clear the map but with the same instrumentation when looking at the output for the original coraza code, the hash values were also different. I'm not sure why I wasn't able to reproduce this hash value difference, but either way, the key is in a local variable k, which there is only one of, so intuitively I suppose those addresses must be the same and the difference is unexpected.

One weird thing I found while making the repro is it seems the value struct needs to be more than 2 strings worth of size to exhibit the behavior - with three fields, get and delete have different addresses, while with two fields they are the same.

Looked through the code in hashmap.go and map.go (compiler) and couldn't see anything suspicious, the code paths for get/lookup vs delete look basically the same for both, but the difference does cause our real-world code to fail with the map not being cleared. With the code looking the same, the issue may be in IR reduction?

Note the above simpleish test case approach is also applied to the real world code here (which is where I was observing the address+key value difference)

https://github.com/corazawaf/coraza/compare/v3/dev...anuraaga:scratch?expand=1

The output looks like this (we can see the different hash values)

[2022-12-28 04:04:56.210312][25][info][wasm] [source/extensions/common/wasm/context.cc:1170] wasm log coraza-filter my_vm_id: hashmapBinaryGet 0x09887b70 0x0000fb98 16 2748313615
[2022-12-28 04:04:56.210312][25][info][wasm] [source/extensions/common/wasm/context.cc:1170] wasm log coraza-filter my_vm_id: could find key
[2022-12-28 04:04:56.210312][25][info][wasm] [source/extensions/common/wasm/context.cc:1170] wasm log coraza-filter my_vm_id: hashmapBinaryDelete 0x09887b70 0x0000fbf8 16 3003228291
[2022-12-28 04:04:56.210313][25][info][wasm] [source/extensions/common/wasm/context.cc:1170] wasm log coraza-filter my_vm_id: delete couldn't find key 0x09887b70
[2022-12-28 04:04:56.210313][25][info][wasm] [source/extensions/common/wasm/context.cc:1170] wasm log coraza-filter my_vm_id: hashmapBinaryGet 0x09887b70 0x0000fb98 16 2748313615
[2022-12-28 04:04:56.210314][25][info][wasm] [source/extensions/common/wasm/context.cc:1170] wasm log coraza-filter my_vm_id: could find key

I noticed that when building for wasi, the runtime_memhash_ option cannot be overridden because the leveldb option always gets added, but only one file is allowed to be compiled

❯ ~/go/bin/tinygo build -scheduler=none -target=wasi -opt=2 -o mapbench.wasm -tags="runtime_memhash_tsip" .
# runtime
/Users/anuraag/git/tinygo/src/runtime/memhash_tsip.go:18:6: ptrToSlice redeclared in this block
/Users/anuraag/git/tinygo/src/runtime/memhash_leveldb.go:16:6: 	other declaration of ptrToSlice
/Users/anuraag/git/tinygo/src/runtime/memhash_tsip.go:47:6: hash64 redeclared in this block
/Users/anuraag/git/tinygo/src/runtime/memhash_leveldb.go:82:6: 	other declaration of hash64
/Users/anuraag/git/tinygo/src/runtime/memhash_tsip.go:119:6: hash32 redeclared in this block
/Users/anuraag/git/tinygo/src/runtime/memhash_leveldb.go:34:6: 	other declaration of hash32