[2.0.x] Platformio - automate build & environment selection

[Bob-the-Kuhn]

Yes, this is for the lazy ones.

This PR automates selecting the build/environment in PlatformIO (when used within Atom).

With just 2 or 3 mouse clicks you can kick off a PlatformIO build rather than scrolling through the build options looking for the one you want.

The Atom package process-palette is used to provide a new menu which kicks off a Python script. This script grabs the motherboard from Configuration.h and then searches pins.h for the motherboard. The command line version of PlatformIO is kicked off using the gathered info and its output is sent to a Python window.

Rather than complicating the script & having to modify it as boards are added, the pins.h file has been modified to include the CPU(s) and environments(s) used by each motherboard. The added info is in the comment portion of each motherboard's include line.

---

ENVIRONMENT SETUP

1. Install Atom and PlatformIO as usual.
2. Install the package process-palette in Atom.

process-palette will automatically read the file process-palette.json in the project's top directory and add the new menu.

---

USER INSTRUCTIONS

1 Edit the Marlin files as usual.
2. Open the project in PlatformIO
3. Click the Auto Build menu. It is immediately to the right of the PlatformIO menu.
4. Click on the type of build (build, clean, upload, ...)
5. If the motherboard (and Marlin) supports more than one CPU then a popup will appear that asks you to click on the correct CPU. Click the CONFIRM button to proceed.
6. A progress bar pops up indicating that something is actually happening. Be patient - PlatformIO can take minutes to complete.
7. A window pops up showing the PlatformIO output stream plus the motherboard name, build type and environment used.

The output window is actually a mini-editor. It can be moved and resized. The text can be scrolled, selected, copied and saved to a file.

In step 5 there are four pop ups:

• 1280 or 2560 CPU
• 644 or 1284 CPU
• Use DUE USB or native port for the upload
• Melzi with or without Optiboot

---

TESTING

This has been tested in Windows and in Ubuntu. It has not been tested in OSX.

---

TO DO

• Test in OSX
• Generate Marlin 1.1.x version. This consists of copying over the new/changed files, removing the 2.0.x section from pins.h and making the AT90USB section of platformio.ini the same as in 2.0.x (remove PRINTRBOARD and BRAINWAVE sections and add in a generic teensy20 section)
• Finalize the environment for SCOOVO_X9H (probably Rambo), CREALITY_ENDER (probably sanguino_atmega1284p), BRAINWAVE (probably teensy20) and THE_BORG (probably STM32F1).
• Find out if all Melzi motherboards can have Optiboot.
• Generate docs if this moves forward.
  - Take another look to see if can stream the PlatformIO output rather than wait for it to complete.
  - Need to back out some test oriented code.
  - Need to add comments and fix up the whitespace/formatting.
• Would be nice to have CONTROL-A working.
• Incorporate bug fixes & improvments as they come in.

[thinkyhead]

Very cool. I'll give it a test in macOS later today. I'll also investigate whether we can get the same out of VSCode, which is preferred by some over Atom.

[thinkyhead]

I've added a commit to bring this up to date with the latest bugfix-2.0.x, so it now passes.
After I squash and rebase, you'll need to update your working copy:

git checkout auto-build-2.0-PR
git fetch origin
git reset --hard origin/auto-build-2.0-PR

[p3p]

@Bob-the-Kuhn I'm going to combine the LPC1768_debug_and_upload and LPC1768 environments if that's ok, there is no difference anyway other than specifying your debug server parameters, I'm in the middle of trying to tidy up the LPC176x platform a bit, but I got held back by trying to debug odd sd card issues some people have on MKS SBase that I can't reproduce (would probably help if I had a mks sbase ^^)

[thinkyhead]

Initial macOS test indicates I need to install some extras into my Python virtual environment:

import _tkinter # If this fails your Python may not be configured for Tk
ImportError: No module named _tkinter

[Bob-the-Kuhn]

This guy only runs under Python 2.7. By chance are you running 3.x?

[Bob-the-Kuhn]

I don't use the PlatformIO debug tool so LPC1768_debug_and_upload can go away completely. Makes it simpler.

[thinkyhead]

This guy only runs under Python 2.7. By chance are you running 3.x?

The major version reported by the script is 2, so it's probably the same 2.7.10 reported in the shell by python --version Python being what it is, I'll need to check which virtualenv it's using when invoked by Atom. Sites I've checked say that Tk (or at least TkInter) has bugs on macOS, but probably they're nothing serious.

I investigated whether we could just use an extra environment in platformio.ini, such as [env:auto] and then have a python pre-script replace the settings ahead of the build, but it appears that many of the environment values are fixed and/or already pre-determined by the time the pre-script runs. And of course there's no way to just "jump" over to one of the other environments.

I also looked at whether the script invoked by process-palette could just hook into Atom and send an event to invoke PIO Build (platform), but apparently scripts invoked by process-palette are in a shell without any hooks into Atom. To use Atom's dialogs and events, we'd basically have to write an Atom "marlin-build" plugin package and install it from the package installer.

All of which is to say, this solution seems to be the most straightforward, and invoking pio in this manner from the shell gives us complete control over build options. So, other settings in the Marlin configs could also be used to modify build flags if we ever needed to do that.

[Bob-the-Kuhn]

Just changed to the streaming version of auto_build.py

[Bob-the-Kuhn]

@JohnnyTheOne - you were involved in adding the optiboot option to platformio.ini - maybe you can answer some questions.

Is optiboot only on upgraded boards?

Can it be installed on any 644 or 1284 board?

@benlye - we're trying to understand the upload speed options/requirements for the 644 & 1284 boards. My impression is that they all upload at 115.2k except for the Melzi & Anet boards that have not been upgraded to the Optiboot bootloader.

The goal is to develop a list of the boards and the correct environment for them.

My current thinking is that all the 644 & 1284 boards upload at 115.2k except for the following (where we'll have to ask what baudrate to use):

      ANET_10
      MELZI
      MELZI_CREALITY
      MELZI_MAKR3D
      MELZI_MALYAN
      MELZI_TRONXY

The pins files indicates that ANET_10 and MELZI_MAKR3D are 1284 boards. Are the other four also 1284 only boards?

[JohnnyTheOne]

I do not have enough knowledge to answer you. ANET_10 board is 1284P and used this for Bootloader upload
https://github.com/JohnnyTheOne/anet3dprinter