Update IRremoteESP8266 library to canonical site. about espeasy HOT 28 CLOSED

I found a tool that can show some more information:

psy@psypad ~/ESPEasy % ./memanalyzer.py /home/psy/.platformio/packages/toolchain-xtensa/bin/xtensa-lx106-elf-objdump .pioenvs/dev_4096/firmware.elf
   Section|                   Description| Start (hex)|   End (hex)|Used space
------------------------------------------------------------------------------
      data|        Initialized Data (RAM)|    3FFE8000|    3FFE8458|    1112
    rodata|           ReadOnly Data (RAM)|    3FFE8460|    3FFEACEC|   10380
       bss|      Uninitialized Data (RAM)|    3FFEACF0|    3FFF49C8|   40152
      text|            Cached Code (IRAM)|    40100000|    40107F00|   32512
irom0_text|           Uncached Code (SPI)|    40201010|    402827E3|  530387
Total Used RAM : 51644
Free RAM : 30276
Free IRam : 274

i found it here: https://raw.githubusercontent.com/SmingHub/Sming/develop/tools/memanalyzer.py

from espeasy.

The results are here: https://github.com/letscontrolit/ESPEasy/blob/mega/dist/Plugin_sizes.txt

Especially the IRAM usage is a problem currently. Without any plugins we only have around 2k left. Some plugins with ISR's need to use some IRAM. I'll see what i can do to reduce that first.

from espeasy.

i updated it to v1.0.2 and trying to compile it, suddenly all the versions give this error:

/home/psy/.platformio/packages/toolchain-xtensa/bin/../lib/gcc/xtensa-lx106-elf/4.8.2/../../../../xtensa-lx106-elf/bin/ld: .pioenvs/test_1024/firmware.elf section `.text' will not fit in region `iram1_0_seg'            

(currently trying to find out whats going on, or is the library really big??)

from espeasy.

The library isn't really big, but it has grown since the version you had referenced.

from espeasy.

it adds about 10k. i would have expected we would have way more rom left still.

we probably hit some kind of limt. will have to find out how it works and perhaps write a script that lists the rom usage per plugin and go from there.

from espeasy.

btw thanks for informing us about that outdated repo :)

from espeasy.

Some quick googling, it appears it isn't the rom that is being exhausted, but the (i)ram.
http://www.esp8266.com/viewtopic.php?f=9&t=12754

Some of the interrupt routines for decoding incoming IR commands have been moved to iram for speed in the library. This hasn't been an issue for us, but given all the other libraries you use/include, you've probably exhausted the iram in the total build.

from espeasy.

We've got two interrupt procedures that have ICACHE_RAM_ATTR enabled, they are not particularly large. My guess is you've been close to the total iram budget for a while and the minor recent changes in those two have pushed you over.

from espeasy.

FWIW, it seems it wasn't our library that was causing you issues. You already had iram problems prior to this. e.g. #185

from espeasy.

yep but that was only for that users environment and not reproducable. we also use travis to automaticly build every commit.

perhaps its related.

from espeasy.

Ack. I'm seeing what I can do to reduce iram usage by our lib. You might want to think of sharding/splitting your travis builds with less modules enabled in each shard to reduce the problem, and let users select what ever modules they want. There is only so much one can squeeze into a ESP8266 after all. :-)

from espeasy.

yes indeed. i'm going to find out how to show the iram and other usage after compiling, and then write a script that automaticly determines usage for every plugin in our system. that we it will be easier to split of 'huge' plugins.

after that i'm going to find out what things we can do to reduce usage in general.

until now we are just guessing about usage, instead of actually measuring it.

from espeasy.

Please ping me on that commit, I'm interested to see how you implement it.

from espeasy.

this is with the infrared plugins disabled, as you can see we're already very limited.

i'll transform that pythonscript in something that tries to determine usage of all rams and roms per plugin.

from espeasy.

Yeah, IIUIC the iram limit is 32k, so you were/are right on it. I'm interested to see how much we use.
I think I've done everything we can at our end to reduce iram usage, but if you find something else, let us know.

from espeasy.

Hmm, we could split the library into a receive and a transmit portion. Only the receiver part needs iram, but that would break a lot of existing usage. Something for another day.

from espeasy.

yeah i'll let you know, there are probably many things we can do on our side first.

from espeasy.

from espeasy.

from espeasy.

yup

from espeasy.

@crankyoldgit using the IR receive functions uses 288 bytes of IRAM it seems. Thats probably because of the interrupt handler routine. Could you check if its easy to save some bytes in that function? Even 10s of bytes will help if its possible, without any compromises.

from espeasy.

@psy0rz I've been thinking of it ever since I saw your data. I haven't yet come up with an easy/good/safe way to do that yet. Now that I know how tight iram is, it's certainly a desired outcome. I'll try to let you know if I come up with something.

from espeasy.

Ok, if it cant be done, it cant be done. :)

Its too bad that we only have around 2k left to work with of the 32k. Makes you wonder what else can be done in the ESP8266/Arduino core libraries to reduce IRAM memory usage.

from espeasy.

Per the impending PR on our library, we should be reducing by about 28 bytes of IRAM when it gets updated.

I've got two other ideas to try that might reduce it further, but they are really horrible potential kludges.

from espeasy.

well if its kludgy dont do it:)

from espeasy.

That may be why I haven't done it. ;-)

from espeasy.

FYI, v1.2.0 of IRremoteESP8266 has been released with reduced IRAM usage.

from espeasy.

thanks @crankyoldgit , the plugin that uses your lib went from 288 to 260 bytes IRAM. :)

very nice.

Edwin

from espeasy.