ESP8266 Community Forum

- Sat Jun 06, 2015 7:50 am #19641 Moin,

there is nothing like "it's ignored because it's interrupt driven".
You are the boss telling the code where to go and if you decide wrong it just crashes.

Cal

Get your modules here:

https://www.banggood.com/custlink/KvGGhGF4wG

- Thu Jul 09, 2015 7:15 am #22842 The root of this problem is dat every function you write leads to dependencies on libraries. For instance powf() (which I had the exact problem with) must be "drawn in" from libc. No single function in libc or libgcc are compiled to go to the .text_irom0 section (pure flash). So you can make any function in your program go to pure flash (with the ICACHE_FLASH_... #define) and still your iram memory will fill up, with all sorts of library functions you didn't write, but are drawn in. Powf is a particularly nasty one, it draws in lots of other functions in it's turn, which also end up in iram. I decided to just no use powf in the end, it's simply using too much iram space. The only solution would be to re-write the powf function and mark it .text_irom0 section or to take the existing code from glibc and compile it yourself, with the appropriate sections and do that for every dependency as well.

I would very much appreciate it if someone with the proper knowledge would create a patch against libc where floating point functions are placed into irom_text section. I don't think anyone should use floating point code in interrupt or flash-writing context.

- Thu Jul 09, 2015 7:20 am #22843 Regarding the enabling/disabling of cache memory. REAL cache memory (not the one that ICACHE_FLASH_RAM refers to).

I was under the firm impression that "our" xtensa core doesn't feature any cache at all, it has been mentioned many times.

Then, apparently, it's used for OTA-updates, which most of us never use. Then it would be a real shame that half of the IRAM cannot be used.

I think it will be tricky to use this in practise. At the point where our code gets run, it has already been copied (the iram0 part), no sense in changing the "cache" at that point really...?

- Sun Jul 12, 2015 7:39 pm #23101 Not debugging, but a simple observation... I find that if I use -any- of the time.h functions (gmtime(), localtime(), gmtime_r(), etc), my compile immediately bombs out with iram1_0 out-of-memory error messages. Freeing up a couple of "struct tm"'s worth of memory elsewhere in the program does -not- help. I've already got a modified eagle.app.v6.ld file and use ICACHE_FLASH_ATTR all over the place.

I'm running TuanPM's MQTT application with some additional calls to some DS3231 test code, so nothing too heavyweight. Really, all I'm trying to do at the moment is have the ESP8266 update the DS3231 RTC with an epoch-based timestamp broadcast from the (NTP controlled) MQTT server. Nothing too complex.

Right now I've dumped the SDK function calls and I'm using a slightly modified version of the Arduino breaktime()/maketime() functions instead (with absolutely no problem).

As I said, not debugging, but just anecdotal confirmation that some calls (like the original powf()) seem to be outright memory hogs.