Instead of specifying the emulator command in atmega328p.json, specify
it in the two boards based on it (arduino and arduino-nano). This makes
the configuration consistent with the machine package, which only
defines the CPUFrequency function in the board files (and not in
machine_atmega328p.json).
On Windows, it is common that there is a colon in the path. avrdude will
treat that as a separator and everything behind it as the file format
specifier instead of defaulting to Intel hex format.
By explicitly specifying the Intel hex format (with `:i`), this issue
should be fixed.
Setting the linker script as one property (instead of as part of the
generic ldflags property) allows it to be overriden.
This is important for the SoftDevice on Nordic chips, because the
SoftDevice takes up a fixed part of the flash/RAM and the application
must be flashed at a different position. With this linkerscript option,
it is possible to create (for example) a pca10040-s132v6 that overrides
the default linker script.
Instead of specifying explicit commands, most of these commands have
been replaced by more specific properties.
This is work that will be necessary for an eventual -programmer flag to
the compiler, with which it is possible to select which programmer to
use to flash or debug a chip. That's not very useful for boards that
already include a programmer or bootloader for that purpose, but is very
useful for novel boards or single-purpose boards that are not already
included in TinyGo.
* all: add support for specifying target CPU in target config
* avr: specify the chip name in the target CPU
This reduces code size by a large margin. For examples/blinky, it
reduces code size from 1360 to 1266 when compiling for the Arduino Uno
(94 bytes, or ~7%).
This allows the use of some compiler-generated builtins that are
hopefully compatible with LLVM. Example: println(uint8(foo))
Code size is unchanged normally but of course compiler builtins will
increase code size when actually used (for example with division).
Ayke van Laethem