search

digistump / OakCore

Arduino/Platformio Core for Oak including Particle library
GNU Lesser General Public License v2.1
54 stars 28 forks source link

Merge Oak into ESP8266 Arduino project #55

Open digistump opened 8 years ago

digistump commented 8 years ago

Continued from #35:

igrr commented 8 years ago

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 commented 8 years ago

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 notifications@github.com 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 https://github.com/digistump/OakCore/issues/55#issuecomment-194290739.

igrr commented 8 years ago

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 commented 8 years ago

@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.