Alternatywa dla ESP8266/ESP32? Moduł EMW3165.

Znam. Całkiem fajnym modułem tego rodzaju jest też Onion Omega (z tym, że posiada złącze w mniejszym rastrze, niekompatybilne z płytkami stykowymi). Przy czym jednak tego typu płytki nie zawsze są sensowną alternatywą dla mikrokontrolera z modułem WiFi (tudzież modułu WiFi ze zintegrowanym mikrokontrolerem). Czasem ważne jest to, żeby układ po resecie podniósł się jak najszybciej, bez potrzeby uruchamiania systemu operacyjnego.

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

To alternatywne bazuje w dużym stopniu na oficjalnym więc ewentualne przeportowanie nie powinno być trudne.

Dotyczy kodu użytkownika, bo brane są oryginalne skrypty linkera. Nie bałbym się jednak tych skryptów edytować ani tym bardziej z ich względu zmieniać w ogóle platformę :) Jako przykład wziąłem ten projekt:

Po kompilacji sprawdzam rozmiar sekcji: .irom0.text 203076 1075908608 .text 25796 1074790400 Nie jest źle, większość poszła do Flasha. Jednak IRAM jest w większości zapełniony i trzeba coś z tym zrobić. Komendą readelf sprawdzam co poszło do IRAMu. Okazuje się, że mnóstwo znajdujących się tam funkcji pochodzi z biblioteki libpp. Trzeba by ją przenieść do Flasha. Zaglądam do skryptu linkera (eagle.app.v6.old.1024.app1.ld) i widzę, że są już tam linijki przenoszące niektóre biblioteki do sekcji irom0.text. Dodałem więc analogiczną linijkę dla libpp:

*libpp.a:(.literal.* .text.*) Niestety nic to nie dało. Szybkie googlanie podpowiedziało, że trzeba przenieść też sekcje bez kropki w środku nazwy. Dopisana linijka będzie więc miała postać: *libpp.a:(.literal.* .text .literal .text.*) Rekompilacja i... sukces! .irom0.text 218020 1075908608 .text 10628 1074790400 Zaoszczędzone 15 kB :) Google podpowiada, że mozna jeszcze przenieść libm. Wtedy mamy: .irom0.text 223188 1075908608 .text 3496 1074790400 Jeszcze lepiej, zużyte tylko nieco ponad 10% IRAMu a prawie wszystko mamy we Flashu. Wystarczyło dopisać dwie linijki. I pewnie obejdzie sę bez zmiany SDK. Być może właśnie na te modyfikacje skryptu linkera natrafiałeś. A jeśli nie chcesz modyfikować skryptu linkera, to możesz zrobić z drugiej strony: zmodyfikować bibliotekę zmieniając w niej nazwy sekcji. Mozna to zrobić komendą objcopy: xtensa-lx106-elf-objcopy --rename-section .text=.irom0.text --rename-section .literal=.irom0.literal libpp.a

Gdzie dokładnie trzeba umieścić tę linijkę? Modyfikuję skrypt eagle.app.v6.ld, używany w moim projekcie.

Zmodyfikowany fragment wygląda następująco:

.irom0.text : ALIGN(4) { _irom0_text_start = ABSOLUTE(.);

*libmbedtls.a:(.literal .text .literal.* .text.*) *libpp.a:(.literal.* .text .literal .text.*) *libm.a:(.literal.* .text .literal .text.*) *(.irom0.literal .irom.literal .irom.text.literal .irom0.text .irom.text) _irom0_text_end = ABSOLUTE(.); } >irom0_0_seg :irom0_0_phdr

Niestety nie pomogło - projekt ciągle nie chce się kompilować, wyrzucając te same błędy...

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

W definicji sekcji .irom0.text, tak jak zrobiłeś, bo chcemy aby objęła większy fragment linkowanego kodu.

Na pewno ten? Poza tym tutaj ta sekcja jest dużo dłuższa:

żesz puścić make VERBOSE=1 i wkleić linijkę od linkowania?

Jeśli na pewno linker używa tego pliku, to powinno pomóc. Ewentualnie tak mocno wychodzisz poza zakres, że przesunięcie jednej biblioteki nie pomaga. Wtedy mozna dopisać węcej, np. libmain (w poprzednim poście się pomyliłem - chodziło właśnie o libmain, nie libm). Ewentualnie możesz zrobić tak, że zwiększysz obszar iram1 tak bardzo, aż projekt się zlinkuje. Definicję masz na początku skryptu: iram1_0_seg : org = 0x40100000, len = 0x8000 Przykładowo można zmienić 0x8000 na 0x10000. Oczywiście kod wynikowy nie zmieści się w pamięci modułu, ale chodzi o to żeby przeanalizować wynikowy plik wykonywalny. Sprawdzić ile ostatecznie zajęły poszczególne sekcj i które funkcjeoraz z których bibliotek są w tych sekcjach. Można do tego użyć readelf albo przejrzeć plik .map jeśli jego generowanie jest uwzględnione w Makefile.

Plik o tej samej nazwie. SDK pobrałem kiedyś (bodajże z GitHuba) kompilując sobie toolchain do ESP8266. Posługiwałem się wtedy jakimś opisem znalezionym w Sieci. Możliwe, że to po prostu jakaś starsza wersja.

Swoją drogą spróbowałem także drugiego rozwiązania, przez modyfikację plików bibliotek za pomocą zaproponowanej przez Ciebie komendy (xtensa-lx106-elf-objcopy --rename-section .text=.irom0.text

--rename-section .literal=.irom0.literal libpp.a). W ten sam sposób zmodyfikowałem także libc i libgcc, ale nie pomogło - błąd ciągle występuje. Co dziwniejsze wygląda na to, że (w przypadku zakomentowania kawałka kodu celem umożliwienia kodu) mapa pokazuje, że biblioteki faktycznie trafiają do irom0.text. To naprawdę nie ma jakiegokolwiek sensu...

Cały wynik jest tutaj. W tym przypadku użyłem standardowego, niezmodyfikowanego skryptu linkera, ale biblioteki są już zmodyfikowane.

Jeśli zakomentować wspomniany kawałek kodu, zostanie wygenerowana następująca mapa: Jak widzisz wspomniane wcześniej biblioteki trafiają do flasha. BTW w jaki sposób odkręcić tę modyfikację. Nie jestem pewien, czy libc i libgcc jednak nie powinny pozostać w RAM-ie...

Wprowadziłem taką modyfikację, ale projekt cały czas się nie kompiluje...

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

Z tego co widzę, to linker krzyczy o brak definicji wywołań systemowych oraz o zduplikowane funkcje odnoszące się do czasu a nie o przekroczenie zakresu pamięci. I zwracam honor odnośnie generowania skryptu linkera, faktycznie tak jest. Nie zaobserwowałem czegoś takiego w open sdk.

Ogólnie tam powinny być rzeczy, które powinny się wykonać szybko, np. obsługujące przerwania. Ale co konkretnie to nie wiem.

Ale z tego co widzę to chodzi o brakujące i zduplikowane definicje funkcji a nie obszary pamięci. Trzeba by się temu przyjrzeć. W dalszej kolejności można spróbować zmienić SDK na najnowszą wersję tego otwartego.

Mogę jakoś odkręcić te modyfikacje? Zapomniałem zrobić kopie zapasowe. Niby SDK bez problemu ściągnę z sieci, ale jeśli da się prościej (paroma komendami) przywrócić domyślne ładowanie do .text, to chętnie bym z tego rozwiązania skorzystał...

Na trop braku miejsca w .text naprowadził mnie fakt, że w momencie gdy projekt jeszcze się kompiluje ta sekcja jest zajęta prawie w całości.

Jakiś pomysł co o tego, gdzie mogę szukać źródła problemu z dublującymi się/brakującymi funkcjami?

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

Tak jak podpowiada intuicja, zamiast .text=.irom0.text napisać .irom0.text=.text

OK, ale jedno z drugim nie ma żadnego związku.

1. Dublują się symbole __tzyear i __tznorth, które występują jednocześnie w lwip i libc. Są to zmienne (niejawnie) external. Być może rozwiązaniem będzie zadeklarowanie ich w lwip jako static żeby nie były external. Chyba że celowo są jako external. Jeśli są, to można spróbować zmienić im nazwy w obrębie lwip. Albo wywal sntp.c jeśli nie używasz.
2. Brakujące symbole wynikają z braku dostarczenia funkcji obsługujących wywołania systemowe (syscalls), gdy linkujesz z flagą -nodefaultlibs. Musisz dodać te funkcje. Wystarczą w większości puste definicje:
   formatting link

Czyli coś takiego?

xtensa-lx106-elf-objcopy --rename-section .irom0.text=extent

--rename-section .literal=.irom0.literal libpp.a

Treści po "literal" nie zmieniać?

Rozumiem, że mowa o bezpośredniej ingerencji w kod lwip? Bo z tego co widzę, to ta biblioteka standardowo jest dostępna w SDK w formie prekompilowanej, jako plik liblwip.a.

Niestety sntp jest jedną z najbardziej podstawowych bibliotek w tym projekcie. Trochę dziwne, że problem pojawia się teraz. W końcu lwip to chyba standardowy składnik projektów tworzonych na ESP8266, a z sntp korzystałem do tej pory bardzo często i nigdy nic takiego się nie działo...

Ok, dzięki za informację. Przyjrzę się tej sprawie bliżej. :)

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

literal też można przywrócić. To po prostu zmiana nazwy.

Trzeba by poszukać SDK z lwip w postaci źródłowej, np. Open SDK. Oficjalne chyba też w końcu wydano ze źródłami. A może po prostu pomoże nowsza wesja SDK.

Też mnie to zdziwiło, nie spodziewałem się takiego konfliktu.

Moze cos na RTL8710

Podobno ma być wspierany przez Mbed. Jeśli tak to będzie killer...

c.