ESP8266 - rozmiar flasha

W dniu piątek, 19 października 2018 11:23:13 UTC-5 użytkownik Atlantis napisał:

Nie wiem czy tak daleko zaszedles:

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.

Atlantis snipped-for-privacy@wp.pl napisał(a):

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

Do 4 MB. Przykładowo ESP-WROOM-02 ma 2 MB. Najtańsze i najpopularniejsze (chyba nadal) ESP-01 mają 0,5 MB.

Skrypt linkera.

ESP32 :)

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

Skrypt linkera jest generowany w locie, przez Makefile:

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.

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

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

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

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):(.bss+0x24): multiple definition of `__tzyear' /opt/Espressif/ESP8266_SDK/lib/libc.a(tzset_r.o):(.bss+0xc): first defined here /opt/Espressif/ESP8266_SDK/lib/liblwip.a(sntp.o):(.bss+0x28): multiple definition of `__tznorth' /opt/Espressif/ESP8266_SDK/lib/libc.a(tzset_r.o):(.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):(.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):(.literal+0x0): undefined reference to `_read_r' /opt/Espressif/ESP8266_SDK/lib/libc.a(stdio.o):(.literal+0x4): undefined reference to `_write_r' /opt/Espressif/ESP8266_SDK/lib/libc.a(stdio.o):(.literal+0x8): undefined reference to `_lseek_r' /opt/Espressif/ESP8266_SDK/lib/libc.a(stdio.o):(.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):(.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

W dniu 22.10.2018 o 11:16, Atlantis pisze:

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 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 }

W dniu 22.10.2018 o 12:07, Atlantis pisze:

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

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

Atlantis snipped-for-privacy@wp.pl napisał(a):

Właśnie, takie coś byłoby dziwne :) 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

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?

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.

Prawie wszędzie pododawałem ICACHE_FLASH_ATTR. W swoim kodzie miałem tylko kilka funkcji bez tego parametru (m.in. główną pętlę i kilka callbacków, które w przykładach były zrealizowane w ten sposób, więc zostawiłem). Nic się nie zmieniło. Zresztą funkcja która "przeważa" też jest ICACHE_FLASH_ATTR...

Nie wiem jak biblioteka esphttpd, ale w moim kodzie prawie wszystko w tej chwili powinno trafiać do irom0.text.

Zawsze możesz sprawdzić czy funkcje trafiają do tego segmentu co trzeba albo porównując rozmiar poszczególnych segmentów, albo robiąc szczegółową mapę z nazwami funkcji.

W jaki sposób? ;) Czyli mam rozumieć, że źródło problemu nie leży w zbyt małej ilości flasha, ale raczej jest jakiś problem ze skryptem linkera?

Problem polega na tym, że ktoś bezmyślnie przyjął położenie segmentu .text. Domyślnie funkcje powinny być w większym (i wolniejszym) segmencie a tylko wybrane funkcje powinny trafiać do tego szybszego (i mniejszego) segmentu. A według tego co piszesz jest dokładnie na odwrót.

Możesz kazać linkerowi wyprodukować plik z mapą (-Wl,-Map=aaaaa.map) - powinny być tam widoczne wszystkie funkcje i segmenty, do których trafiły.