Update IRremoteESP8266 library to canonical site.

[crankyoldgit]

Hi,
as one of the collaborators on the IRremoteESP8266 library, we've had a number of odd reports of our library not working coming from some ESPEasy users. I think I've trace the root of the problem to your project referencing an unmaintained fork instead of the canonical version.

I'll create a pull request to fix what I can immediately see might be the issue, however, can you please check there is no other references your project has to the unmaintained version?

Thanks in advance.

[psy0rz]

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??)

[crankyoldgit]

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

[psy0rz]

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.

[psy0rz]

btw thanks for informing us about that outdated repo :)

[crankyoldgit]

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.

[crankyoldgit]

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.

[crankyoldgit]

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

[psy0rz]

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

perhaps its related.

[crankyoldgit]

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. :-)

[psy0rz]

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.

[crankyoldgit]

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

[psy0rz]

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

[psy0rz]

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.

[crankyoldgit]

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.

[crankyoldgit]

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.

[psy0rz]

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

[uzi18]

Try add option -C after -t to objdump 02.04.2017 11:40 AM "DatuX" <notifications@github.com> napisał(a):

…

yeah i'll let you know, there are probably many things we can do on our side first. — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub <#188 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AAHOU3D6g6LBtCbKP6f4WliKZu-Puih7ks5rr20YgaJpZM4MtbYF> .

[psy0rz]

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.

[uzi18]

Did You checked also without Controllers? 03.04.2017 8:37 PM "DatuX" <notifications@github.com> napisał(a):

…

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. — You are receiving this because you commented. Reply to this email directly, view it on GitHub <#188 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AAHOUwWyW6n7edUyo6xW3soBNVbMFr57ks5rsTxkgaJpZM4MtbYF> .

[psy0rz]

yup

[psy0rz]

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

[crankyoldgit]

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

[psy0rz]

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.

[crankyoldgit]

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.

[psy0rz]

well if its kludgy dont do it:)

[crankyoldgit]

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

[crankyoldgit]

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

[psy0rz]

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

very nice.

Edwin