RTV forum PL | NewsGroups PL

Jak zwiększyć pamięć flash i poprawnie skompilować projekt na ESP8266?

ESP8266 - rozmiar flasha

NOWY TEMAT

elektroda NewsGroups Forum Index - Elektronika Polska - Jak zwiększyć pamięć flash i poprawnie skompilować projekt na ESP8266?

Goto page 1, 2  Next

Atlantis
Guest

Fri Oct 19, 2018 4:22 pm   



Pracuję właśnie nad pewnym projektem, który nie wymaga zbyt potężnego
MCU ani dużej ilości linii IO. Tak naprawdę chodzi tylko o komunikację z
kilkoma układami I2C, machanie paroma liniami, generowanie jednego
sygnału PWM oraz czytanie jednego wejścia analogowego.

Pomyślałem sobie, że spokojnie mogę to załatwić za pomocą ESP8266.
Ponieważ przy okazji chciałbym mieć panel WWW, przez który mogę sobie
ten układ skonfigurować, wziąłem sobie za podstawę skopiowany kiedyś
GitHuba projekt esphttpd z moimi własnymi modyfikacjami i gotową stroną
konfiguracyjną. Potem zacząłem dodawać biblioteki niezbędne z punktu
widzenia mojej funkcjonalności.

Wszystko kompilowało się, do czasu. W pewnym momencie dodałem o jeden
plik za dużo i linker zaczął sypać błędami. Zacząłem eksperymentować,
zakomentowując (na razie) zbędne funkcje. Okazało się, że w pewnym
momencie projektów znów zaczyna się kompilować.

Czyli brak pamięci flash...

Zajrzałem do Makefile. Znajduje się tam następujące ustawienie:

#SPI flash size, in K
ESP_SPI_FLASH_SIZE_K=4096

Próbowałem zwiększyć tę wartość, ale nic to nie dało.

Stąd kilka pytań:

1) Jaki największy flash dostanę w module z ESP8266?
2) Co zmienić w projekcie, żeby prawidłowo się kompilował pod taki
większy model?

W tej chwili, jeśli uda się skompilować projekt, powstają dwa pliki:
0x00000.bin (36,9 kB) oraz 0x40000.bin (223,6 kB).

Ewentualnie, istnieje jakaś łatwa do ogarnięcia alternatywa?

Grzegorz Niemirowski
Guest

Fri Oct 19, 2018 5:19 pm   



Atlantis <marekw1986NOSPAM@wp.pl> napisał(a):
Quote:
Zajrzałem do Makefile. Znajduje się tam następujące ustawienie:
#SPI flash size, in K
ESP_SPI_FLASH_SIZE_K=4096
Próbowałem zwiększyć tę wartość, ale nic to nie dało.

Błędy lecą z linkera więc sprawdź skrypt linkera. Może korzysta on ze
zmiennej z Makefile a może nie.

Quote:
Stąd kilka pytań:
1) Jaki największy flash dostanę w module z ESP8266?

Do 4 MB. Przykładowo ESP-WROOM-02 ma 2 MB. Najtańsze i najpopularniejsze
(chyba nadal) ESP-01 mają 0,5 MB.
https://en.wikipedia.org/wiki/ESP8266

Quote:
2) Co zmienić w projekcie, żeby prawidłowo się kompilował pod taki
większy model?

Skrypt linkera.

Quote:
Ewentualnie, istnieje jakaś łatwa do ogarnięcia alternatywa?

ESP32 Smile
https://en.wikipedia.org/wiki/ESP32
Pytanie ile tego Flasha potrzebujesz. Nie napisałeś jaki masz moduł. ESP8266
to sam mikrokontroler.

--
Grzegorz Niemirowski
https://www.grzegorz.net/

Atlantis
Guest

Fri Oct 19, 2018 6:19 pm   



On 10/19/18 7:19 PM, Grzegorz Niemirowski wrote:

Quote:
Błędy lecą z linkera więc sprawdź skrypt linkera. Może korzysta on ze
zmiennej z Makefile a może nie.

Skrypt linkera jest generowany w locie, przez Makefile:
https://github.com/Spritetm/esphttpd

Można tam ustawić różne tryby kompilacji: OTA, separate (wsad i
skompresowana strona www w osobno wgrywanych plikach) oraz combined
(wsad i www w jednym pliku).

Większość moich plików pochodzi z tego projektu - zmieniłem głównie
część webową i dodałem własne funkcje do obsługi cgi. Dzisiaj zacząłem
dodawać kolejne biblioteki i w pewnym momencie wszystko się wysypało,
zgodnie z opisem z pierwszej wiadomości.


Quote:

Jeszcze z nim nie eksperymentowałem. SDK jest podobne do tego z ESP8266?
Można dostać moduł ze złączem zewnętrznej anteny?


Quote:
Pytanie ile tego Flasha potrzebujesz. Nie napisałeś jaki masz moduł.
ESP8266 to sam mikrokontroler.

Jeszcze nie podjąłem decyzji. Generalnie wymóg jest jeden: złącze
zewnętrznej anteny - urządzenie będzie zamknięte w metalowej obudowie.

Guest

Fri Oct 19, 2018 6:38 pm   



W dniu piątek, 19 października 2018 11:23:13 UTC-5 użytkownik Atlantis napisał:
Quote:
Pracuję właśnie nad pewnym projektem, który nie wymaga zbyt potężnego
MCU ani dużej ilości linii IO. Tak naprawdę chodzi tylko o komunikację z
kilkoma układami I2C, machanie paroma liniami, generowanie jednego
sygnału PWM oraz czytanie jednego wejścia analogowego.

Pomyślałem sobie, że spokojnie mogę to załatwić za pomocą ESP8266.
Ponieważ przy okazji chciałbym mieć panel WWW, przez który mogę sobie
ten układ skonfigurować, wziąłem sobie za podstawę skopiowany kiedyś
GitHuba projekt esphttpd z moimi własnymi modyfikacjami i gotową stroną
konfiguracyjną. Potem zacząłem dodawać biblioteki niezbędne z punktu
widzenia mojej funkcjonalności.

Wszystko kompilowało się, do czasu. W pewnym momencie dodałem o jeden
plik za dużo i linker zaczął sypać błędami. Zacząłem eksperymentować,
zakomentowując (na razie) zbędne funkcje. Okazało się, że w pewnym
momencie projektów znów zaczyna się kompilować.

Czyli brak pamięci flash...

Zajrzałem do Makefile. Znajduje się tam następujące ustawienie:

#SPI flash size, in K
ESP_SPI_FLASH_SIZE_K=4096

Próbowałem zwiększyć tę wartość, ale nic to nie dało.

Stąd kilka pytań:

1) Jaki największy flash dostanę w module z ESP8266?
2) Co zmienić w projekcie, żeby prawidłowo się kompilował pod taki
większy model?

W tej chwili, jeśli uda się skompilować projekt, powstają dwa pliki:
0x00000.bin (36,9 kB) oraz 0x40000.bin (223,6 kB).

Ewentualnie, istnieje jakaś łatwa do ogarnięcia alternatywa?

Nie wiem czy tak daleko zaszedles:
https://github.com/espressif/esptool#esp8266-and-flash-size

nie badalem tematu ale w zaleznosci od tego czy chcesz OTA updates mozesz wygospodarowac calkiem sporo miejsca.

Przy czym nie jestem pewien czy juz tego nie zrobiles.

Jakub Rakus
Guest

Fri Oct 19, 2018 7:14 pm   



On 19.10.2018 20:19, Atlantis wrote:

Quote:
Jeszcze nie podjąłem decyzji. Generalnie wymóg jest jeden: złącze
zewnętrznej anteny - urządzenie będzie zamknięte w metalowej obudowie.

ESP32-WROVER-I

--
Pozdrawiam
Jakub Rakus

Marek
Guest

Sat Oct 20, 2018 11:12 am   



On Fri, 19 Oct 2018 19:19:25 +0200, "Grzegorz Niemirowski"
<gnthexfiles@poczta.onet.pl> wrote:
Quote:
ESP32 Smile

Tak btw. miło mnie zaskoczyło środowisko Arduino pod esp32, że
posiada zintegrowany freertos.

--
Marek

Atlantis
Guest

Mon Oct 22, 2018 9:16 am   



Przy próbie kompilacji dostaję następujące komunikaty. Może komuś coś to
mówi?


make[1]: Wejście do katalogu
'/home/marek/Dropbox/Programowanie/ESP8266/timelord_nixie/libesphttpd'
CC espfs/espfs.c
CC espfs/heatshrink_decoder.c
CC core/httpd-nonos.c
CC core/httpd-freertos.c
CC core/sha1.c
CC core/httpdespfs.c
CC core/auth.c
CC core/base64.c
CC core/httpd.c
CC util/cgiwebsocket.c
CC util/cgiflash.c
CC util/captdns.c
CC util/cgiwifi.c
AR libesphttpd.a
make[2]: Wejście do katalogu
'/home/marek/Dropbox/Programowanie/ESP8266/timelord_nixie/libesphttpd/espfs/mkespfsimage'
cc -I../../lib/heatshrink -I../../include -I.. -std=gnu99
-DESPFS_HEATSHRINK -c -o main.o main.c
cc -I../../lib/heatshrink -I../../include -I.. -std=gnu99
-DESPFS_HEATSHRINK -c -o heatshrink_encoder.o heatshrink_encoder.c
cc -o mkespfsimage main.o heatshrink_encoder.o
make[2]: Opuszczenie katalogu
'/home/marek/Dropbox/Programowanie/ESP8266/timelord_nixie/libesphttpd/espfs/mkespfsimage'
ui/redirect.tpl (66%, heatshrink)
ui/form.css (73%, heatshrink)
ui/menu.css (65%, heatshrink)
ui/wifi/icons.png (100%, none)
ui/wifi/140medley.min.js (74%, heatshrink)
ui/wifi/wifi.tpl (54%, heatshrink)
ui/wifi/connecting.html (60%, heatshrink)
ui/wifi/wifi.css (93%, heatshrink)
ui/status.tpl (51%, heatshrink)
ui/menu.js (66%, heatshrink)
ui/config.tpl (37%, heatshrink)
ui/style.css (76%, heatshrink)
ui/index.tpl (78%, heatshrink)
ui/pass.tpl (45%, heatshrink)
make[1]: Opuszczenie katalogu
'/home/marek/Dropbox/Programowanie/ESP8266/timelord_nixie/libesphttpd'
CC user/stdout.c
CC user/config.c
CC user/io.c
CC user/ds3231.c
CC user/user_main.c
CC user/cgi.c
CC user/i2c_master.c
CC user/rtc.c
CC user/pcf8574.c
AR build/httpd_app.a
LD build/httpd.user1.out
/opt/Espressif/ESP8266_SDK/lib/liblwip.a(sntp.o)Sad.bss+0x24): multiple
definition of `__tzyear'
/opt/Espressif/ESP8266_SDK/lib/libc.a(tzset_r.o)Sad.bss+0xc): first
defined here
/opt/Espressif/ESP8266_SDK/lib/liblwip.a(sntp.o)Sad.bss+0x28): multiple
definition of `__tznorth'
/opt/Espressif/ESP8266_SDK/lib/libc.a(tzset_r.o)Sad.data+0x0): first
defined here
/opt/Espressif/crosstool-NG/builds/xtensa-lx106-elf/lib/gcc/xtensa-lx106-elf/4.8.2/../../../../xtensa-lx106-elf/bin/ld:
build/httpd.user1.out section `.text' will not fit in region `iram1_0_seg'
/opt/Espressif/ESP8266_SDK/lib/libc.a(mallocr.o)Sad.literal+0x10):
undefined reference to `_sbrk_r'
/opt/Espressif/ESP8266_SDK/lib/libc.a(mallocr.o): In function `_malloc_r':
C:\build\build\RC-2010.1\lxinnovation\delivery\lx106\104196\xbuild\Target-libs\newlib\xtensa-elf\newlib\libc\stdlib/\build\tree\RC-2010.1_kuma\p4root\Xtensa\Target-libs\newlib\newlib\libc\stdlib/mallocr.c:2152:
undefined reference to `_sbrk_r'
C:\build\build\RC-2010.1\lxinnovation\delivery\lx106\104196\xbuild\Target-libs\newlib\xtensa-elf\newlib\libc\stdlib/\build\tree\RC-2010.1_kuma\p4root\Xtensa\Target-libs\newlib\newlib\libc\stdlib/mallocr.c:2189:
undefined reference to `_sbrk_r'
/opt/Espressif/ESP8266_SDK/lib/libc.a(freer.o): In function
`_malloc_trim_r':
C:\build\build\RC-2010.1\lxinnovation\delivery\lx106\104196\xbuild\Target-libs\newlib\xtensa-elf\newlib\libc\stdlib/\build\tree\RC-2010.1_kuma\p4root\Xtensa\Target-libs\newlib\newlib\libc\stdlib/mallocr.c:3309:
undefined reference to `_sbrk_r'
C:\build\build\RC-2010.1\lxinnovation\delivery\lx106\104196\xbuild\Target-libs\newlib\xtensa-elf\newlib\libc\stdlib/\build\tree\RC-2010.1_kuma\p4root\Xtensa\Target-libs\newlib\newlib\libc\stdlib/mallocr.c:3351:
undefined reference to `_sbrk_r'
/opt/Espressif/ESP8266_SDK/lib/libc.a(freer.o):C:\build\build\RC-2010.1\lxinnovation\delivery\lx106\104196\xbuild\Target-libs\newlib\xtensa-elf\newlib\libc\stdlib/\build\tree\RC-2010.1_kuma\p4root\Xtensa\Target-libs\newlib\newlib\libc\stdlib/mallocr.c:3327:
more undefined references to `_sbrk_r' follow
/opt/Espressif/ESP8266_SDK/lib/libc.a(stdio.o)Sad.literal+0x0): undefined
reference to `_read_r'
/opt/Espressif/ESP8266_SDK/lib/libc.a(stdio.o)Sad.literal+0x4): undefined
reference to `_write_r'
/opt/Espressif/ESP8266_SDK/lib/libc.a(stdio.o)Sad.literal+0x8): undefined
reference to `_lseek_r'
/opt/Espressif/ESP8266_SDK/lib/libc.a(stdio.o)Sad.literal+0xc): undefined
reference to `_close_r'
/opt/Espressif/ESP8266_SDK/lib/libc.a(stdio.o): In function `__sread':
C:\build\build\RC-2010.1\lxinnovation\delivery\lx106\104196\xbuild\Target-libs\newlib\xtensa-elf\newlib\libc\stdio/\build\tree\RC-2010.1_kuma\p4root\Xtensa\Target-libs\newlib\newlib\libc\stdio/stdio.c:47:
undefined reference to `_read_r'
/opt/Espressif/ESP8266_SDK/lib/libc.a(stdio.o): In function `__swrite':
C:\build\build\RC-2010.1\lxinnovation\delivery\lx106\104196\xbuild\Target-libs\newlib\xtensa-elf\newlib\libc\stdio/\build\tree\RC-2010.1_kuma\p4root\Xtensa\Target-libs\newlib\newlib\libc\stdio/stdio.c:84:
undefined reference to `_write_r'
C:\build\build\RC-2010.1\lxinnovation\delivery\lx106\104196\xbuild\Target-libs\newlib\xtensa-elf\newlib\libc\stdio/\build\tree\RC-2010.1_kuma\p4root\Xtensa\Target-libs\newlib\newlib\libc\stdio/stdio.c:76:
undefined reference to `_lseek_r'
/opt/Espressif/ESP8266_SDK/lib/libc.a(stdio.o): In function `__sseek':
C:\build\build\RC-2010.1\lxinnovation\delivery\lx106\104196\xbuild\Target-libs\newlib\xtensa-elf\newlib\libc\stdio/\build\tree\RC-2010.1_kuma\p4root\Xtensa\Target-libs\newlib\newlib\libc\stdio/stdio.c:103:
undefined reference to `_lseek_r'
/opt/Espressif/ESP8266_SDK/lib/libc.a(stdio.o): In function `__sclose':
C:\build\build\RC-2010.1\lxinnovation\delivery\lx106\104196\xbuild\Target-libs\newlib\xtensa-elf\newlib\libc\stdio/\build\tree\RC-2010.1_kuma\p4root\Xtensa\Target-libs\newlib\newlib\libc\stdio/stdio.c:120:
undefined reference to `_close_r'
/opt/Espressif/ESP8266_SDK/lib/libc.a(makebuf.o)Sad.literal+0x4):
undefined reference to `_fstat_r'
/opt/Espressif/ESP8266_SDK/lib/libc.a(makebuf.o): In function `__smakebuf':
C:\build\build\RC-2010.1\lxinnovation\delivery\lx106\104196\xbuild\Target-libs\newlib\xtensa-elf\newlib\libc\stdio/\build\tree\RC-2010.1_kuma\p4root\Xtensa\Target-libs\newlib\newlib\libc\stdio/makebuf.c:52:
undefined reference to `_fstat_r'
/opt/Espressif/ESP8266_SDK/lib/libc.a(sysfstat.o): In function `fstat':
C:\build\build\RC-2010.1\lxinnovation\delivery\lx106\104196\xbuild\Target-libs\newlib\xtensa-elf\newlib\libc\syscalls/\build\tree\RC-2010.1_kuma\p4root\Xtensa\Target-libs\newlib\newlib\libc\syscalls/sysfstat.c:12:
undefined reference to `_fstat_r'
collect2: error: ld returned 1 exit status
Makefile.ota:50: polecenia dla obiektu 'build/httpd.user1.out' nie
powiodły się
make: *** [build/httpd.user1.out] Błąd 1

Zbych
Guest

Mon Oct 22, 2018 9:51 am   



W dniu 22.10.2018 o 11:16, Atlantis pisze:
Quote:
Przy próbie kompilacji dostaję następujące komunikaty. Może komuś coś to
mówi?

/opt/Espressif/crosstool-NG/builds/xtensa-lx106-elf/lib/gcc/xtensa-lx106-elf/4.8.2/../../../../xtensa-lx106-elf/bin/ld:
build/httpd.user1.out section `.text' will not fit in region `iram1_0_seg'

Nic nie robiłem na 8266, więc to tylko domysły, ale sekcja .text jest
upychana w iram1 (40100000h), który według wiki ma zaledwie 32kB i robi
normalnie za cache. Flash SPI powinien być mapowany od 40200000h, więc
wychodzi że używasz skryptów linkera skrojonych albo pod bootloader albo
inny mały program, który w całości mieści się w cache.

Atlantis
Guest

Mon Oct 22, 2018 10:07 am   



On 22.10.2018 11:51, Zbych wrote:

Quote:
Nic nie robiłem na 8266, więc to tylko domysły, ale sekcja .text jest
upychana w iram1 (40100000h), który według wiki ma zaledwie 32kB i robi
normalnie za cache. Flash SPI powinien być mapowany od 40200000h, więc
wychodzi że używasz skryptów linkera skrojonych albo pod bootloader albo
inny mały program, który w całości mieści się w cache.

To dosyć dziwne, bo:
1) Skrypt linkera jest generowany w locie, przez Makefile.
2) Makefile pochodzi z oryginalnego projektu esphttpd
(https://github.com/Spritetm/esphttpd). W ogóle cały mój projekt bazuje
na tym projekcie, z pewnymi modyfikacjami (inna strona www, dodane
funkcje do obsługi cgi, trochę własnego kodu).
3) Jeśli tylko zakomentować kilka (w tej chwili) niekrytycznych funkcji,
to kod się skompiluje, mając zdecydowanie więcej niż 32kB.


Skrypt linkera wygląda następująco:

MEMORY { irom0_0_seg : org = 0x40240000, len = 0xFFFFFFFFFFFFC000 }

Zbych
Guest

Mon Oct 22, 2018 10:53 am   



W dniu 22.10.2018 o 12:07, Atlantis pisze:

Quote:
3) Jeśli tylko zakomentować kilka (w tej chwili) niekrytycznych funkcji,
to kod się skompiluje, mając zdecydowanie więcej niż 32kB.

Pokaż jak wygląda mapa tak wygenrowanej binarki (objdump -h *.elf)

Atlantis
Guest

Mon Oct 22, 2018 11:06 am   



On 22.10.2018 12:53, Zbych wrote:

Quote:
Pokaż jak wygląda mapa tak wygenrowanej binarki (objdump -h *.elf)

httpd.out: file format elf32-little

Sections:
Idx Name Size VMA LMA File off Algn
0 .data 00000864 3ffe8000 3ffe8000 000000e0 2**4
CONTENTS, ALLOC, LOAD, DATA
1 .rodata 00001188 3ffe8870 3ffe8870 00000950 2**4
CONTENTS, ALLOC, LOAD, READONLY, DATA
2 .bss 000066c0 3ffe99f8 3ffe99f8 00001ad8 2**4
ALLOC
3 .irom0.text 00037448 40240000 40240000 00009120 2**4
CONTENTS, ALLOC, LOAD, CODE
4 .text 0000763c 40100000 40100000 00001ad8 2**2
CONTENTS, ALLOC, LOAD, READONLY, CODE
5 .xtensa.info 00000038 00000000 00000000 00040568 2**0
CONTENTS, READONLY
6 .xt.prop 0002bdc4 00000000 00000000 000405a0 2**0
CONTENTS, READONLY
7 .xt.lit 000015e8 00000000 00000000 0006c364 2**0
CONTENTS, READONLY
8 .comment 00002050 00000000 00000000 0006d94c 2**0
CONTENTS, READONLY
9 .debug_frame 000011fc 00000000 00000000 0006f99c 2**2
CONTENTS, READONLY, DEBUGGING
10 .debug_info 0000f518 00000000 00000000 00070b98 2**0
CONTENTS, READONLY, DEBUGGING
11 .debug_abbrev 00002a70 00000000 00000000 000800b0 2**0
CONTENTS, READONLY, DEBUGGING
12 .debug_loc 000046ee 00000000 00000000 00082b20 2**0
CONTENTS, READONLY, DEBUGGING
13 .debug_aranges 00000678 00000000 00000000 00087210 2**3
CONTENTS, READONLY, DEBUGGING
14 .debug_ranges 000006f0 00000000 00000000 00087888 2**0
CONTENTS, READONLY, DEBUGGING
15 .debug_line 0000544c 00000000 00000000 00087f78 2**0
CONTENTS, READONLY, DEBUGGING
16 .debug_str 000021fb 00000000 00000000 0008d3c4 2**0
CONTENTS, READONLY, DEBUGGING
17 .debug_pubnames 0000011a 00000000 00000000 0008f5bf 2**0
CONTENTS, READONLY, DEBUGGING

Zbych
Guest

Mon Oct 22, 2018 11:47 am   



W dniu 22.10.2018 o 13:06, Atlantis pisze:
Quote:
On 22.10.2018 12:53, Zbych wrote:

Pokaż jak wygląda mapa tak wygenrowanej binarki (objdump -h *.elf)

httpd.out: file format elf32-little

Sections:
Idx Name Size VMA LMA File off Algn
3 .irom0.text 00037448 40240000 40240000 00009120 2**4
CONTENTS, ALLOC, LOAD, CODE
4 .text 0000763c 40100000 40100000 00001ad8 2**2
CONTENTS, ALLOC, LOAD, READONLY, CODE

No to teraz pytanie kiedy kod trafia do sekcji .irom0.text a kiedy do
..text.
Masz tam jakieś atrybuty przy funkcjach? __attribute__((section("blabla")))

Grzegorz Niemirowski
Guest

Mon Oct 22, 2018 12:30 pm   



Atlantis <marekw1986NOSPAM@wp.pl> napisał(a):
Quote:
To dosyć dziwne, bo:
1) Skrypt linkera jest generowany w locie, przez Makefile.

Właśnie, takie coś byłoby dziwne Smile Skąd ta teoria? Skrypt nie jest
generowany, jest jedynie wybierany dynamicznie z mapy.
Makefile.ota:LD_MAP_2:=512:eagle.app.v6.new.512.app2.ld
1024:eagle.app.v6.new.1024.app2.ld 2048:eagle.app.v6.new.2048.ld
4096:eagle.app.v6.new.2048.ld
Makefile.ota:LD_SCRIPT_USR2 := $(call
maplookup,$(ESP_SPI_FLASH_SIZE_K),$(LD_MAP_2))
Skrypty linkera podchodzą z SDK. Który skrypt jest wybierany, możesz
sprawdzić uruchamiając make z parametrem VERBOSE=1

--
Grzegorz Niemirowski
https://www.grzegorz.net/

Atlantis
Guest

Mon Oct 22, 2018 12:33 pm   



On 22.10.2018 13:47, Zbych wrote:

Quote:
No to teraz pytanie kiedy kod trafia do sekcji .irom0.text a kiedy do
.text.
Masz tam jakieś atrybuty przy funkcjach? __attribute__((section("blabla")))

Standardowo przy swoich funkcjach daję ICACHE_FLASH_ATTR. Gdzieś w
plikach nagłówkowych SDK jest to zdefiniowane jako
__attribute__((section(".irom0.text."))).

Z tego co pamiętam, powoduje to, że taki kod jest wykonywany (wolniej)
bezpośrednio z flasha.

Próbowałem usunąć ten argument z paru funkcji, ale nic to nie daje - kod
dalej nie chce się kompilować.

Jakiś pomysł? Co może być nie tak?

Zbych
Guest

Mon Oct 22, 2018 2:00 pm   



W dniu 22.10.2018 o 14:33, Atlantis pisze:
Quote:
On 22.10.2018 13:47, Zbych wrote:

No to teraz pytanie kiedy kod trafia do sekcji .irom0.text a kiedy do
.text.
Masz tam jakieś atrybuty przy funkcjach? __attribute__((section("blabla")))

Standardowo przy swoich funkcjach daję ICACHE_FLASH_ATTR. Gdzieś w
plikach nagłówkowych SDK jest to zdefiniowane jako
__attribute__((section(".irom0.text."))).

Z tego co pamiętam, powoduje to, że taki kod jest wykonywany (wolniej)
bezpośrednio z flasha.

Próbowałem usunąć ten argument z paru funkcji, ale nic to nie daje - kod
dalej nie chce się kompilować.

Jak usuwasz ICACHE_FLASH_ATTR to przemieszczasz funkcję z irom0.text do
..text, który ma tylko 32kB, więc tylko pogarszasz sytuację. Zrób
dokładnie odwrotnie i dodaj do kilku funkcji ICACHE_FLASH_ATTR.

Goto page 1, 2  Next

elektroda NewsGroups Forum Index - Elektronika Polska - Jak zwiększyć pamięć flash i poprawnie skompilować projekt na ESP8266?

NOWY TEMAT

Regulamin - Zasady uzytkowania Polityka prywatnosci Kontakt RTV map News map