Merge Oak into ESP8266 Arduino project

[digistump]

Continued from #35:

[igrr]

Erik,
Refactoring our core to accept different bootloaders and ROM layouts is certainly doable. Particle integration might fit into variant folder, and we can add that variant as a git submodule/subtree of esp8266/Arduino repository.
Having the ESP8266WiFi library in the core directory might also be achieved by moving it into variant folder.
I see that you use a different flash tool, but that could be added to the combined boards manager package as well.
Overall i think the most technically challenging part would be to handle different ROM layouts when calling flash image generation tool, but with some tinkering around boards.txt i'm certain this can be done.

[digistump]

We use three different tools:

Esptool2 (https://github.com/raburton/esptool2) - which we use for making
the bin file because we need the irom checksum embedded in the bin for
verification of the OTA programming.

Esptool.py instead of Esptool-ck for serial uploads because Esptool.py sets
the first byte in flash memory to the the size of the memory chip, which is
needed for our bootloader to allow booting from different 1Meg sections of
flash (if esptool-ck now does this please correct me, but it didn't last
time I tried - probably in november).

OakCLI (github.com/digistump/oakcli) - which is our OTA upload tool that
uploads the bin file to the Particle cloud and triggers the OTA
programming.

Would it make sense for either of the features for the first two tools to
get integrated into Esptool-ck? That might allow unifying those as well.
OakCLI doesn't make sense to integrate into anything, since it is so
specific to the Oak, but it could easily be pulled into the packages and is
pretty small (about 5mb zipped).

We have two types of uploads:

Particle OTA: Doesn't care what the ROM layout is, has a single linker file
regardless of what flash section it sends up in. Needs esptool2 to generate
the bin for the checksum feature.

Serial Upload: Can be accommodated with the existing boards.txt for your
project, always uploads to 0x2000 and is just for debugging and development
mostly. The only catch right now is that esptool2 and esptool.py needs to
be used for the reasons above.

Any thoughts on the best way to accommodate those? I know that with enough
compiler variables in the boards.txt we could switch between these
different tools, but it seems like unifying at least some of this might be
better.

On Wed, Mar 9, 2016 at 5:10 AM, Ivan Grokhotkov [email protected]
wrote:

Erik,
Refactoring our core to accept different bootloaders and ROM layouts is
certainly doable. Particle integration might fit into variant folder, and
we can add that variant as a git submodule/subtree of esp8266/Arduino
repository.
Having the ESP8266WiFi library in the core directory might also be
achieved by moving it into variant folder.
I see that you use a different flash tool, but that could be added to the
combined boards manager package as well.
Overall i think the most technically challenging part would be to handle
different ROM layouts when calling flash image generation tool, but with
some tinkering around boards.txt i'm certain this can be done.

—
Reply to this email directly or view it on GitHub
#55 (comment).

[igrr]

esptool-ck can set flash size in binary image header while building the image. This is unlike esptool.py, which sets flash size when it is uploading the image. See readme, -bz argument.

Before replacing esptool.py with esptool-ck for the uploading stage, i would recommend you to try uploading to the Oak on all three platforms. I don't know which USB-UART chip you use inside, and i know that with some chip/OS combinations (PL2303 w/ OS X, for instance), esptool-ck works less reliably than esptool.py. Good thing is that if you try it and it doesn't work, i can probably debug and fix this.

Regarding irom checksum, i think esptool-ck can do this, but i need to check the binaries generated by esptool2 to be sure. I will update you on that.

[pfeerick]

@igrr Oak uses an externally connected, user provided, USB-UART, so that shouldn't be an issue (that and the constant encouragements to use CH340s when the FTDIs play up)! So it sounds like for a change from esptool2 -> esptool-ck that it is probably just the irom checksum embedding that needs to be there.