- Sun Sep 07, 2014 7:18 am
#295
Also, would be nice to see where stack pointers points too (which is in a1 reg IIRC).
- Sun Sep 07, 2014 9:02 am
#296
From ESP8266 English datasheet, section 9:
This hints to a cache mechanism for the Flash contents, IMHO...
The application and firmware is executed in on-chip ROM and SRAM, which loads the
instructions during wake-up, through the SDIO interface, from the external flash.
This hints to a cache mechanism for the Flash contents, IMHO...
- Wed Sep 24, 2014 2:15 am
#875
So do we have any more information on memory constraints?
iram is 32k or 64k? Whole application has to fit in this size or dynamic caching possible?
dram is 80k?
iram is 32k or 64k? Whole application has to fit in this size or dynamic caching possible?
dram is 80k?
- Wed Sep 24, 2014 4:17 am
#876
What i found out during poking around with this chip is that there are 96k of RAM starting at 0x3FFF8000 (data ram) and 32k starting at 0x40100000 (instruction ram). However, this is only the RAM that i was able to write to from within an application running on the chip.
It dynamically loads and caches code from the flash memory during execution. Any function that is not prefixed by an ICACHE_FLASH_ATTR ends up in the instruction RAM segment, those that are prefixed end up in the flash, which maps to the instruction ROM segment.
This does say little about what amount of cache RAM there ist, of course. There are registers in the core to set up access to address spaces, but they are only writable when the code executes with ring 0 privileges. So far i have not tested if user code runs with those privilleges or not. Also, i have not yet tested how the cores address space maps to the flash. On bootup the RAM based code is loaded from flash from the bootloader, this is the multi-segment file that gets uploaded to 0x00000 during writing.
Going by the linker scripts there seems to be quite a lot of instruction space usable on the flash, just check the start addresses and sizes given for the app1 and app2 scripts, compared to the regular one. It's also quite possible that by using a 4MByte flash, instead of the 512kByte, it is possible to use even more codespace. There are internal functions in the built-in ROM that check the flash type/size. Unfortunately Espressif is rather unhelpful when it comes to explaining/documenting these things. Heck, they even seem to deny that there is any internal ROM at all. But that could be a case of bad chinglish, of course.
Once i'm done with writing my tool i will prod the chip a bit more to see what it can address/execute. What i found out so far is that the IRAM segments are readable by user code, so there is a chance that these can also be used to store data (at worst indirectly, but that should be good enough to hold some sort of read-only filesystem for, for example, a small web-server or somesuch).
But as said, i can prod at it more only after i am finished with my esptool...
Greetings,
Chris
wififofum wrote:So do we have any more information on memory constraints?
iram is 32k or 64k? Whole application has to fit in this size or dynamic caching possible?
dram is 80k?
What i found out during poking around with this chip is that there are 96k of RAM starting at 0x3FFF8000 (data ram) and 32k starting at 0x40100000 (instruction ram). However, this is only the RAM that i was able to write to from within an application running on the chip.
It dynamically loads and caches code from the flash memory during execution. Any function that is not prefixed by an ICACHE_FLASH_ATTR ends up in the instruction RAM segment, those that are prefixed end up in the flash, which maps to the instruction ROM segment.
This does say little about what amount of cache RAM there ist, of course. There are registers in the core to set up access to address spaces, but they are only writable when the code executes with ring 0 privileges. So far i have not tested if user code runs with those privilleges or not. Also, i have not yet tested how the cores address space maps to the flash. On bootup the RAM based code is loaded from flash from the bootloader, this is the multi-segment file that gets uploaded to 0x00000 during writing.
Going by the linker scripts there seems to be quite a lot of instruction space usable on the flash, just check the start addresses and sizes given for the app1 and app2 scripts, compared to the regular one. It's also quite possible that by using a 4MByte flash, instead of the 512kByte, it is possible to use even more codespace. There are internal functions in the built-in ROM that check the flash type/size. Unfortunately Espressif is rather unhelpful when it comes to explaining/documenting these things. Heck, they even seem to deny that there is any internal ROM at all. But that could be a case of bad chinglish, of course.
Once i'm done with writing my tool i will prod the chip a bit more to see what it can address/execute. What i found out so far is that the IRAM segments are readable by user code, so there is a chance that these can also be used to store data (at worst indirectly, but that should be good enough to hold some sort of read-only filesystem for, for example, a small web-server or somesuch).
But as said, i can prod at it more only after i am finished with my esptool...
Greetings,
Chris
