ESP8266 Community Forum

- Mon May 25, 2015 3:25 pm #18445

Nice, I am looking forward for the code! It comes down to two very different use-cases: pushing new FW in development mode vs. pull updates in "production" mode.

Attaching my modified "cgiflash.c", this is nowhere near as elegant as the patch files you provide, sorry about this. The new code is mostly work by Andrei Tatar. Everything is pretty much hardcoded now, I am working to fully automate FW version checking and auto-updating, this is pretty straight forward to achieve.

I also fiddled a bit with the urls so that they make a more sense (at least to me)

HttpdBuiltInUrl builtInUrls[]={
{"/", cgiRedirect, "/index.tpl"},
{"/flash/read", cgiReadFlash, NULL},
{"/flash/next", cgiGetFirmwareNext, NULL},
{"/flash/upload", cgiUploadFirmware, NULL},
{"/flash/reboot", cgiRebootFirmware, NULL},
{"/flash/download", cgiDownloadFirmware, NULL},
{"/led.tpl", cgiEspFsTemplate, tplLed},
{"/index.tpl", cgiEspFsTemplate, tplCounter},
{"/led.cgi", cgiLed, NULL},

You do not have the required permissions to view the files attached to this post.

- Mon May 25, 2015 7:31 pm #18463 Interesting. I wonder how much more code this pulls in from the SDK and whether it's not just as easy to write the fetching explicitly given that the code to check the binary and flash it is already all there.

- Tue May 26, 2015 12:47 am #18471

Interesting. I wonder how much more code this pulls in from the SDK and whether it's not just as easy to write the fetching explicitly given that the code to check the binary and flash it is already all there.

The code increased by roughly 3K, so pretty much acceptable. It runs quite reliably as well, I interrupted it on purpose several times and it does detect that and aborts the upgrade. I'd too prefer open source code, but that does the job well for now.
I'm mostly concerned with the free user space now, the 236KB is just about enough for the default esphttpd with one cat image and that's not enough for me. I'll probably be looking at replacing the SPI flash chip with a 1 or 2MB one to accommodate for the loss of code space.

Another thing, I used to save user config to 0x3C000, that now falls under partition1. Moving these to 0x3E000 as per the below memory map will probably work, but I haven't tested yet if they do get overwritten. Has anyone tested that?

@0x00000 4KB bootloader
@0x01000 236KB partition1
@0x3E000 16KB user parameters
@0x40000 4KB unused
@0x41000 236KB partition2
@0x4E000 16KB system parameters

- Tue May 26, 2015 3:00 am #18474 User params don't get overwritten (unless I have a bug). I've also toyed with the idea to put the espfs in there, but that would make upgrades a bit more dicey.
I really like the POST upgrade I currently have. I've been developing my firmware a lot over the past 3 days and have reflashed many dozens of times and so far I have not had to resort back to serial upload at all. The fact that the upgrade doesn't use any of the espfs itself makes it plausible to update that in-place. But if you need >16KB of espfs it doesn't help either.
BTW, I added purecss to my web pages to get responsive styling in just 4KB, that has been a nice upgrade. Now I just need to sprinkle a little more ajax around and it'll be quite satisfying...