[2.0.x] Enable local board repository for PIO

[fiveangle]

-Enable boards_dir option in PIO INI
-Remove defunct custom board file operations from PIO auto-build environment
-Remove now-defunct teensy20 PIO environment entry, replaced by at90USB1286_CDC and at90USB1286_DFU (using teensy20 entry always put AT90USB board bootloaders in jeopardy of being overwritten due to the very small size of the official Teensy++ 2.0 bootloader)
-Update monitor_speed for AT90USB boards
-Whitespace

[fiveangle]

Something appears to have gone wonky with Travis builds and doesn't appear related to this PR:

.piolibdeps/U8glib-HAL_ID1932/src/clib/u8g_rot.c:48:1: warning: initialization from incompatible pointer type
u8g_dev_t u8g_dev_rot = { u8g_dev_rot_dummy_fn, NULL, NULL };
^
.piolibdeps/U8glib-HAL_ID1932/src/clib/u8g_rot.c:48:1: warning: (near initialization for 'u8g_dev_rot.dev_fn')
.piolibdeps/TMC2130Stepper_ID1493/src/source/TMC2130Stepper.cpp:193:10: error: prototype for 'uint32_t TMC2130Stepper::TPOWERDOWN()' does not match any in class 'TMC2130Stepper'
uint32_t TMC2130Stepper::TPOWERDOWN() { return TPOWERDOWN_sr; }
^
In file included from .piolibdeps/TMC2130Stepper_ID1493/src/source/TMC2130Stepper.cpp:1:0:
.piolibdeps/TMC2130Stepper_ID1493/src/TMC2130Stepper.h:91:8: error: candidates are: void TMC2130Stepper::TPOWERDOWN(uint8_t)
void TPOWERDOWN(     uint8_t input);
^
.piolibdeps/TMC2130Stepper_ID1493/src/TMC2130Stepper.h:90:11: error:                 uint8_t TMC2130Stepper::TPOWERDOWN()
uint8_t TPOWERDOWN();
^
.piolibdeps/TMC2130Stepper_ID1493/src/source/TMC2130Stepper.cpp:194:6: error: prototype for 'void TMC2130Stepper::TPOWERDOWN(uint32_t)' does not match any in class 'TMC2130Stepper'
void TMC2130Stepper::TPOWERDOWN(uint32_t input) {
^
In file included from .piolibdeps/TMC2130Stepper_ID1493/src/source/TMC2130Stepper.cpp:1:0:
.piolibdeps/TMC2130Stepper_ID1493/src/TMC2130Stepper.h:91:8: error: candidates are: void TMC2130Stepper::TPOWERDOWN(uint8_t)
void TPOWERDOWN(     uint8_t input);
^
compilation terminated due to -fmax-errors=5.
*** [.pioenvs/megaatmega2560/libe24/TMC2130Stepper_ID1493/source/TMC2130Stepper.cpp.o] Error 1
========================== [ERROR] Took 26.39 seconds ==========================
================================== [SUMMARY] ==================================
Environment megaatmega2560      	[ERROR]
Environment megaatmega1280      	[SKIP]
Environment at90USB1286_CDC     	[SKIP]
Environment at90USB1286_DFU     	[SKIP]
Environment DUE                 	[SKIP]
Environment DUE_USB             	[SKIP]
Environment DUE_debug           	[SKIP]
Environment LPC1768             	[SKIP]
Environment melzi               	[SKIP]
Environment melzi_optiboot      	[SKIP]
Environment rambo               	[SKIP]
Environment sanguino_atmega644p 	[SKIP]
Environment sanguino_atmega1284p	[SKIP]
Environment STM32F1             	[SKIP]
Environment STM32F4             	[SKIP]
Environment teensy35            	[SKIP]
Environment malyanm200          	[SKIP]
========================== [ERROR] Took 26.39 seconds ==========================

[p3p]

A library updated with a new version that had a few issues, it's fixed now but will take a bit to propagate through platformio,

[Bob-the-Kuhn]

Definitely a better solution.

It'll be 2-4 weeks before I'm back home & can test this in Ubuntu & macOS. Since it's a PIO option then I think the risk is pretty small.

I'll modify my doc changes accordingly.

---

I'm not sure that deleting the Teensy20++ environment is a good idea.

I've tried many times to upload CDC & DFU boards using the Teensy environment and the Teensy loader always refused to start the upload.

I'm speculating that the concern comes from using the Teensy environment to build an image and then using a non-PIO tool to do the upload. That could blow the CDC/DFU bootloader away if the image is max'd out and the lock bits aren't set right.

Now that we can do the DFU/CDC uploads from withing PIO I don't think that should be a concern.

---

Maybe there is a legitmate concern with the new PIO CDC/DFU upload options.

The new CDC/DFU options use AVRDUDE. There's no way (that I know of) to check the image size before AVRDUDE is kicked off. If the lock bits are set wrong and the image is too big then it will blow away the bootloader.

I don't see an elgant way of fixing this. The best I see right now would be to modify autobuild to do a build first, get the image size from the buffer (or the ELF, or ...) and then kick off the upload if the size is OK. Time to re-read the platformio.ini and AVRDUDE docs to see if there is a usueful option.

[fiveangle]

I don't understand the concern to keep the Teensy++ 2.0 environment at all and contend it should not be reverted.

There is not a single 3D printer control board that uses an actual Teensy++ 2.0 board (with Paul's "Halfkay" bootloader that consumes 2k PROGMEM) and so the issue for AT90USB users to compile with PIO up to ~130000 bytes and upload to their board always had the possibility to blow away the large CDC, LUA, DFU boot loaders that all consume 8k PROGMEM boundary so only have 122880 bytes available before encroaching on the bootloader.

The only thing that can come with keeping the environment now that you have a working custom board definition for AT90USB boards is if we want to keep the ability to generate hex files that can overwrite the bootloader of non-Halfkay boards without warning 😝 .

The Teensy uploader utility only works with the Halfkay bootloader resident only on genuine factory Teensy boards, so we always have had to use a separate utility to upload, and the Teensy Uploader helper app that Paul wrote/maintains will never ever ever work with any 3D printer board.

[fiveangle]

Regarding DFU boards, one piece of trivia is that the dfu-uploader is far more tailored for flashing DFU-equipped boards, being smart enough to not allow flashing more than the configured [progmem-total] - [size-of-the-bootloader-based-on-what-the-boundary-fuses-say].

But I don't think that's compelling enough to implement it parallel of avrdude since the board definition file (ever since #10943) prevents PIO from creating a hex that is too large. You could probably easily add a script like you suggest that checks the size of the resulting image and simply not proceed with flashing if greater than 122880 bytes, but it seems overly-redundant (as long as the Teensy++ 2.0 entry is put to pasture as it needs to be 😁 )

[Bob-the-Kuhn]

I just tested the maximum_size entry in the JSON. It really works.

Thanks - elegant, simple, applies to every situation and no further work needed. 🙂

[fiveangle]

"I'm speculating that the concern comes from using the Teensy environment to build an image and then using a non-PIO tool to do the upload. That could blow the CDC/DFU bootloader away if the image is max'd out and the lock bits aren't set right."

yup