Add support for Particle Argon, Boron and Xenon boards

[suda]

Tested on all three devices:

• ✅ GPIO
• ✅ UART
• ✅ I2C

This PR also adds the ability to change the UART ports when calling Configure on nRF platform (used to test UART on different pins).

Flashed using Particle Debugger which works with cmsis-dap profile in OpenOCD.

[conejoninja]

It's another repo, but it would be great if the info about the boards is added to the tinygo.org website : https://github.com/tinygo-org/tinygo-site/tree/master/content/microcontrollers

[conejoninja]

Boron and Xenon are missing the type "Pin" in some constants. Regular digital/analog pins are missing (A1, D8, D3, D2,...) in the three boards. Everything else looks good to me, I do not have the boards but I saw the tweet so I guess it works.

[suda]

✅ Added the GPIO pins
✅ Fixed some incorrect pins in Boron
✅ Updated to support changes from #883 and set machine.Serial to the USB-CDC

Once #884 gets merged in, I can also set the correct Particle USB VID/PID

[conejoninja]

Great! thanks for your contribution. One last thing, add them to the list of supported targets https://github.com/tinygo-org/tinygo/tree/dev#supported-boardstargets and I think we can merge this.

[conejoninja]

We should add them to the tinygo website too https://github.com/tinygo-org/tinygo-site/tree/master/content/microcontrollers

[aykevl]

There is one thing missing: smoke tests for these devices. Take a look here: https://github.com/tinygo-org/tinygo/blob/master/Makefile#L255-L256. These tests make sure the boards will continue to build with future changes to the machine package and in fact catch a lot of bugs in CI.

I have added a number of nitpicks below. They are optional to me, feel free to fix them or not.

[aykevl]

Looks good to me.

One thing I realize just now is that you might want to use a custom linker script for this chip to preserve the bootloader and SoftDevice. See targets/nrf52840-s140v7.ld for an example.

[conejoninja]

Good for me too, should we merge now and add the linker script later?

[aykevl]

I'd like to know what @suda thinks before merging.

[suda]

Oooh the script would be great but I agree with Daniel, we can decouple it into a separate PR.

[conejoninja]

Thanks for this PR! Great job 👍 now merging

[aykevl]

@conejoninja for the next PR: to keep a clean history can you squash such commits? They're mostly going back and forth fixing things while the core change is really just one thing. Ideally it would have been one commit per board but I think that would be hard to change at a later time. A clean history is convenient for things like making a changelog and bisecting bugs.

[conejoninja]

no problem! I always have doubts between rebase and squash, but I just left a note to myself to squash from now on. :)

[aykevl]

There is no hard and fast rule, but in general I try to keep one commit per actual change:

• Changes that make sense on their own should be kept in separate commits.
• Commits that fix issues in previous commits in the same PR (after reviews etc.) are not independent changes and should ideally be squashed into those original commits.

Not everyone knows the git-fu to do such things so it's not a big problem, but it helps to keep the history clean when possible.