Firmware size problem

[Pako2]

Right now I have found, that (in the current version) RDM6300 only works,
when DEBUG is defined. This is because the command Serial.begin(9600) is inside the #ifdef/#endif block.
And that's the problem. When I add Serial.begin(9600), the firmware size is too big (and prevents OTA updates).
It is clear that it is necessary to optimize the code. For example, we can optimize the selectors in esprfid.js (as @nardev suggested).
However, unfortunately, I do not have enough experience with jQuery and I am not the most suitable person for this task.
Here is probably another option. Instead of the 1M / 3M configuration, we could use the 3M / 1M configuration. Obviously, this brings other limitations ...

[omersiar]

We can use 2/2 option as well, i do not know if it is hit the main code base on esp8266 core.

[Pako2]

Unfortunately, your remark is relevant, it really is not a solution.
I've been looking at ld scripts and even in the eagle.flash.8m6m.ld configuration, the sketch space is still the same (1044464B).

[omersiar]

You are right about the sketch size, proprietary boot loader is limiting the sketch size to be at most 1MB but does not limit the spiffs or ota size.

https:/esp8266/Arduino/blob/master/tools/sdk/ld/eagle.flash.4m2m.ld

[omersiar]

Also there is a possibility to do the OTA update with SPIFFS, but i did not go too deep into that.

[omersiar]

Maybe it can be more convenient way to solve OTA problem, in that case you do not need to spare a complete 1MB flash size for it, but the user must make space for update if the logs are full.

[omersiar]

I believe i can make it to version 1.0.0, hopefully :)

[Pako2]

IT WORKS!
I tried to use build_flags = -Wl,-Teagle.flash.4m2m.ld
and the compiler reported this:

DATA:    [=====     ]  47.8% (used 39180 bytes from 81920 bytes)
PROGRAM: [=====     ]  50.7% (used 529808 bytes from 1044464 bytes)

However - the status page in the web interface reported that Free Flash is 1568768 !
Then I've tried to perform an OTA update and it works!
So the result: configuration 2/2 reduces SPIFFS, but space for the sketch has increased.

[omersiar]

Yes i used it before, i just wanted to keep it under 512kb, so i switched back to 4m1m

[Pako2]

I understand, but now it seems that keeping the 512kb limit will be very difficult now.
For example, adding RDM6300 support does not work without the limit being exceeded.

[omersiar]

I am working on SPIFFS solution, i am close, need 1-2 hours.

[Pako2]

Great, I'm curious about it.

[omersiar]

After digging into SPIFFS update, i realized that the Updater class is not capable of that.

esp8266/Arduino#5334

[Pako2]

So until it is resolved (hopefully it will be solved), we will have to use a 2/2 configuration?

[omersiar]

I do not think it is going to be implemented on Core anytime soon, so yes 2/2 configuration is way to go.