Arduino AVR Boards 1.6.11 added the {upload.verify} property to the tools.avrdude.upload recipe and {program.verify} to the tools.avrdude.program recipe to support the File > Preferences > Verify code after upload setting.
In Arduino IDE versions 1.6.8 and previous upload.verify is set to true or false depending on the preferences setting which causes Upload to an AVR board with Arduino IDE 1.6.8 or older and Arduino AVR Boards 1.6.11 or newer to generate AVRDUDE commands like:
avrdude -CC:\Users\per\AppData\Local\Arduino15\packages\arduino\tools\avrdude\6.3.0-arduino2/etc/avrdude.conf -v true -patmega328p -carduino -PCOM21 -b115200 -D -Uflash:w:C:\Users\per\AppData\Local\Temp\buildece560c1024a4a94b7c3b05be61aa2fc.tmp/sketch_sep28a.ino.hex:i
program.verify is unset, which causes Upload Using Programmer to an AVR board with Arduino IDE 1.6.8 or older and Arduino AVR Boards 1.6.11 or newer to generate AVRDUDE commands like:
avrdude -CC:\Users\per\AppData\Local\Arduino15\packages\arduino\tools\avrdude\6.3.0-arduino6/etc/avrdude.conf -v {program.verify} -patmega328p -cusbasp -Pusb -Uflash:w:C:\Users\per\AppData\Local\Temp\build77ff2e21c5523c5895e8d065447461cb.tmp/sketch_sep28a.ino.hex:i
AVRDUDE 6.0.1 is able to ignore the spurious item in the command and successfully upload but when used with AVRDUDE 6.3.0 this causes upload to fail:
avrdude: no programmer has been specified on the command line or the config file
Specify a programmer using the -c option and try again
This means that Arduino AVR Boards 1.6.12 and 1.6.14 are not backwards compatible with Arduino IDE 1.6.8 and previous.
Setting a default empty value for the upload.verify and program.verify properties in platform.txt causes Arduino IDE 1.6.8 and older to generate an AVRDUDE command identical to that generated with Arduino AVR Boards 1.6.10 or older(meaning that, as previously, the preferences setting has no effect):
avrdude -CC:\Users\per\AppData\Local\Arduino15\packages\arduino\tools\avrdude\6.3.0-arduino2/etc/avrdude.conf -v -patmega328p -carduino -PCOM21 -b115200 -D -Uflash:w:C:\Users\per\AppData\Local\Temp\buildece560c1024a4a94b7c3b05be61aa2fc.tmp/sketch_sep28a.ino.hex:i
Arduino IDE 1.6.9 and newer overrides the default values of upload.verify and program.verify, therefore this change has no effect on the AVRDUDE command generated and verification is controlled by the preferences setting as usual.
Tested back to Arduino IDE 1.6.2, the oldest IDE version that supports Boards Manager updates.
Previously, during the build, the full package_index.json was downloaded
and distributed with the Arduino IDE.
This lead to a situation where it was difficult to test new AVR cores
before publishing them to the public package_index.json.
Now the bundled AVR core is specificed in the file:
`hardware/package_index_bundled.json`
this index is loaded from the IDE at startup and the package_index.json
is overlayed on it.
This should also solve part of #5143 (Repeatable builds and snapshots of
package/library indexes)
On Linux, setting autosuspend_delay_ms to N and control to auto allows the host pc to suspend the peripheral. Some Linux distro (Ubuntu, Mint) apply this behaviour by default.
If the sketch's prints where less frequent than N milliseconds the sketch prints would never arrive.
This patch allows sending a remote wakeup event to unsuspend the peripheral and allow the serial prints to be received.
to allow WebUSB development, provide a way to change the USB_VERSION reported
using an additional core.
The additional (webUSB) core will survive IDE and AVR core updates
Fixes that more complex methods (like Stream::print(float)) do not work properly.
Without this fix, Wire.print(1.01f); results in '1' because Print::printFloat(double, uint8_t) performs multiple print() and therefore twi_transmit calls. Also Wire.println("Heyho"); results only in a newline character.
In an excess of confidence, these defines were added to Leonardo's variant.h
3rd party boards sometimes avoid inheriting this variant but they still define USBCON, thus breaking the build
As I was not able to base the return types of `begin()` & `end()` off the c_str() function, I have changed the source so the features can be used by C++98 code, while still allowing ranged loops in C++11.
Replaces #4280, only checks for the bootloader once
Tested with Hoodloader2, should work with every LUFA-derived bootloader released after 2014 (.apitable_signatures section must be placed at end of the flash)
BootloaderAPITable.S :
.global BootloaderAPI_Signatures
BootloaderAPI_Signatures:
.long BOOT_START_ADDR ; Start address of the bootloader
.word 0xDF00 ; Signature for the CDC class bootloader
.word 0xDCFB ; Signature for a LUFA class bootloader
makefile:
BOOT_API_LD_FLAGS += $(call BOOT_SECTION_LD_FLAG, .apitable_signatures, BootloaderAPI_Signatures, 8)
Define archive_file_path in Arduino AVR Boards platform.txt to provide
backwards compatibility with IDE versions previous to 1.6.6. The
archive_file_path value set in platform.txt is overridden in IDE 1.6.6+.
This produces avr-ar commands identical to the previous behavior.
- Remove comment in Arduino AVR Boards platform.txt about -w flag. This
is no longer relevant since the compiler warning level is now set by the
user.
- Fix typos
added "build.usb_manufacturer" entry that overrides default macro in USBCore.cpp source file. this isn't really necessary since the source macro is the same as in "boards.txt", but it gives 3rd party board vendors direction in how to have their SAM3X board use their own manufacturer string during USB enumeration.
now "myboard.build.usb_product" and "myboard.build.usb_manufacturer" from a 3rd party board in "boards.txt" are used in source code. if they aren't defined in "boards.txt", default values are used.
Avoid using the overload of print() for signed integer since a negative value is not allowed here.
This results in a smaller (unless print(int) is used somewhere else in the program) and faster code because the overload for unsigned integer is simpler.
The current code is very verbose and a painful to maintain (Change ISR implementation in 20 different places? No Thanks!).
(This was originally part of #4519, but we all agreeded it deserved it's own PR)
