RTV forum PL | NewsGroups PL

Alternatywa dla ESP8266/ESP32? Moduł EMW3165.

NOWY TEMAT

elektroda NewsGroups Forum Index - Elektronika Polska - Alternatywa dla ESP8266/ESP32? Moduł EMW3165.

Goto page Previous  1, 2, 3  Next

Atlantis
Guest

Tue Oct 30, 2018 3:10 pm   



On 30.10.2018 14:30, Marek wrote:

Quote:
przypisując funkcjom atrybutów ICACHE_FLASH_ATTR, przez co są one
umieszczane w RAM-ie.

W jakim celu?  Serio w zastosowaniu do httpd było to konieczne na tym mcu?

Pisząc poprzednią wiadomość popełniłem błąd. Atrybut ICACHE_FLASH_ATTR
umieszcza funkcję we flashu. Wszystkie funkcje pozbawione tego atrybutu
są po starcie programu kopiowane do RAM-u i wykonywane z niego. A
przeznaczone jest na to tylko 32kB.

Co więcej - z wygenerowanej mapy linkera wynika, że do RAM-u trafia
także biblioteka standardowa i trochę funkcji systemowych. I prawdę
mówiąc nie mam pojęcia czy i jak mogę coś z tym zrobić...

Zbych
Guest

Tue Oct 30, 2018 7:21 pm   



Atlantis wrote on 30.10.2018 15:10:
Quote:
On 30.10.2018 14:30, Marek wrote:

przypisując funkcjom atrybutów ICACHE_FLASH_ATTR, przez co są one
umieszczane w RAM-ie.

W jakim celu?  Serio w zastosowaniu do httpd było to konieczne na tym mcu?

Pisząc poprzednią wiadomość popełniłem błąd. Atrybut ICACHE_FLASH_ATTR
umieszcza funkcję we flashu. Wszystkie funkcje pozbawione tego atrybutu
są po starcie programu kopiowane do RAM-u i wykonywane z niego. A
przeznaczone jest na to tylko 32kB.

Co więcej - z wygenerowanej mapy linkera wynika, że do RAM-u trafia
także biblioteka standardowa i trochę funkcji systemowych. I prawdę
mówiąc nie mam pojęcia czy i jak mogę coś z tym zrobić...

Sprawa wydaje się bardzo prosta do rozwiązania - trzeba zmienić skrypt
linkera tak, żeby segment .text domyślnie był we flashu (40200000h) i
tylko wybrane (krytyczne czasowo) funkcje miały atrybut umieszczający je
w RAMie segmencie irom0.text (40100000) i jednocześnie we flashu jako
dane inicjalizujące. Poprawki mogą też wymagać skrypty startowe
przepisujące ten segment do RAMu.

Atlantis
Guest

Wed Oct 31, 2018 10:44 am   



On 30.10.2018 19:21, Zbych wrote:

Quote:
Sprawa wydaje się bardzo prosta do rozwiązania - trzeba zmienić skrypt
linkera tak, żeby segment .text domyślnie był we flashu (40200000h) i
tylko wybrane (krytyczne czasowo) funkcje miały atrybut umieszczający je
w RAMie segmencie irom0.text (40100000) i jednocześnie we flashu jako
dane inicjalizujące. Poprawki mogą też wymagać skrypty startowe
przepisujące ten segment do RAMu.

Problem polega na tym, że to chyba wykracza poza moje obecne
umiejętności. Teoretycznie bawiłem się trochę skryptami linkera i kodem
startowym, eksperymentując z 6502 i AT89SAM7, jednak to były absolutne
podstawy. :)

Spróbuję jednak poeksperymentować. Okazuje się, że to nie kompilowane
pliki przeoczone przez autora biblioteki są źródłem problemu. Wszędzie
gdzie się tylko dało dodałem ICACHE_FLASH_ATTR, funkcje trafiły do
irom0.text, a jednak w niczym to nie pomogło. Zdecydowana większość
sekcji .text jest zajmowana przez biblioteki wchodzące w skład SDK,
które domyślnie są ładowane właśnie do RAM-u.
Szybki research w sieci pokazuje, że nie jestem jedyną osobą, która
natknęła się na ten problem. Ludzie ponoć modyfikują pliki bibliotek
oraz skrypty linkera, aby funkcje trafiały tam, gdzie powinny.

Grzegorz Niemirowski
Guest

Wed Oct 31, 2018 11:56 am   



Atlantis <marekw1986NOSPAM@wp.pl> napisał(a):
Quote:
Spróbuję jednak poeksperymentować. Okazuje się, że to nie kompilowane
pliki przeoczone przez autora biblioteki są źródłem problemu. Wszędzie
gdzie się tylko dało dodałem ICACHE_FLASH_ATTR, funkcje trafiły do
irom0.text, a jednak w niczym to nie pomogło. Zdecydowana większość
sekcji .text jest zajmowana przez biblioteki wchodzące w skład SDK,
które domyślnie są ładowane właśnie do RAM-u.
Szybki research w sieci pokazuje, że nie jestem jedyną osobą, która
natknęła się na ten problem. Ludzie ponoć modyfikują pliki bibliotek
oraz skrypty linkera, aby funkcje trafiały tam, gdzie powinny.

Możesz zmienić SDK na takie, w którym jest odwrotnie :)

https://github.com/SuperHouse/esp-open-rtos/wiki/ESP-SDK-Differences
In Espressif's SDK, function code is stored in instruction RAM by default.
As there is only 32KB of instruction RAM, most functions need annotating
with the ICACHE_FLASH_ATTR attribute in order to move them to flash.

In esp-open-rtos, function code is stored in flash by default. Code which
need to be called very often with high performance, or which need to be
called while flash is unmapped, can be annotated with the IRAM attribute
defined in common_macros.h to store it in instruction RAM.

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

Atlantis
Guest

Wed Oct 31, 2018 12:29 pm   



On 31.10.2018 11:56, Grzegorz Niemirowski wrote:

Quote:
Możesz zmienić SDK na takie, w którym jest odwrotnie Smile

Pierwsze pytanie, a raczej wątpliwość: czy stosowane przeze mnie
biblioteki (przede wszystkim ta do serwera http) będą zgodne z
alternatywnym SDK?

Po drugie, czy ta modyfikacja dotyczy tylko kodu użytkownika? Bo z tego
co widzę, to u mnie głównym źródłem problemu są biblioteki z SDK, które
linker umieszcza w RAM-ie.

Grzegorz Niemirowski
Guest

Wed Oct 31, 2018 1:28 pm   



Marek <fake@fakeemail.com> napisał(a):
Quote:
To wiem, ale czy kod stosu tcpip jest linkowany za każdym razem z usercode
i tak całość flashowana czy usercode jest osobno flashowany?

Jest linkowany razem.

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

Atlantis
Guest

Wed Oct 31, 2018 2:16 pm   



On 30.10.2018 11:52, cezar wrote:

Quote:
Jeszcze jedna zabawka, którą się bawiłem i działa wyśmienicie:

https://labs.mediatek.com/en/chipset/MT7688#HDK

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.

Grzegorz Niemirowski
Guest

Wed Oct 31, 2018 2:20 pm   



Atlantis <marekw1986NOSPAM@wp.pl> napisał(a):
Quote:
Pierwsze pytanie, a raczej wątpliwość: czy stosowane przeze mnie
biblioteki (przede wszystkim ta do serwera http) będą zgodne z
alternatywnym SDK?

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

Quote:
Po drugie, czy ta modyfikacja dotyczy tylko kodu użytkownika? Bo z tego
co widzę, to u mnie głównym źródłem problemu są biblioteki z SDK, które
linker umieszcza w RAM-ie.

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ę Smile Jako przykład wziąłem ten projekt:
https://github.com/QB4-dev/esp_nano_httpd_basic_example 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.aSad.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.aSad.literal.* .text .literal .text.*)
Rekompilacja i... sukces!
..irom0.text 218020 1075908608
..text 10628 1074790400
Zaoszczędzone 15 kB Smile 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

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

Atlantis
Guest

Wed Oct 31, 2018 3:15 pm   



On 31.10.2018 14:20, Grzegorz Niemirowski wrote:

Quote:
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.aSad.literal.* .text .literal .text.*)

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.aSad.literal .text .literal.* .text.*)
*libpp.aSad.literal.* .text .literal .text.*)
*libm.aSad.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...

Grzegorz Niemirowski
Guest

Wed Oct 31, 2018 4:02 pm   



Atlantis <marekw1986NOSPAM@wp.pl> napisał(a):
Quote:
Gdzie dokładnie trzeba umieścić tę linijkę?

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

Quote:
Modyfikuję skrypt eagle.app.v6.ld, używany w moim projekcie.

Na pewno ten? Poza tym tutaj ta sekcja jest dużo dłuższa:
https://github.com/espressif/ESP8266_NONOS_SDK/blob/master/ld/eagle.app.v6.ld
Możesz puścić make VERBOSE=1 i wkleić linijkę od linkowania?

Quote:
Zmodyfikowany fragment wygląda następująco:
.irom0.text : ALIGN(4)
{
_irom0_text_start = ABSOLUTE(.);
*libmbedtls.aSad.literal .text .literal.* .text.*)
*libpp.aSad.literal.* .text .literal .text.*)
*libm.aSad.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...

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.

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

Atlantis
Guest

Fri Nov 02, 2018 10:00 am   



On 31.10.2018 16:02, Grzegorz Niemirowski wrote:

Quote:
Na pewno ten? Poza tym tutaj ta sekcja jest dużo dłuższa:
https://github.com/espressif/ESP8266_NONOS_SDK/blob/master/ld/eagle.app.v6.ld

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


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

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

Jeśli zakomentować wspomniany kawałek kodu, zostanie wygenerowana
następująca mapa:
https://pastebin.com/pepCwbtX

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


Quote:
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.

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

Grzegorz Niemirowski
Guest

Fri Nov 02, 2018 10:33 am   



Atlantis <marekw1986NOSPAM@wp.pl> napisał(a):
Quote:
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...
Możesz puścić make VERBOSE=1 i wkleić linijkę od linkowania?
Cały wynik jest tutaj. W tym przypadku użyłem standardowego,
niezmodyfikowanego skryptu linkera, ale biblioteki są już zmodyfikowane.
https://pastebin.com/QTNyJEFE

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.

Quote:
Jeśli zakomentować wspomniany kawałek kodu, zostanie wygenerowana
następująca mapa:
https://pastebin.com/pepCwbtX
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...

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

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

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.

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

Atlantis
Guest

Fri Nov 02, 2018 10:51 am   



On 02.11.2018 10:33, Grzegorz Niemirowski wrote:

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

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ł...


Quote:
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.

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?

Grzegorz Niemirowski
Guest

Mon Nov 05, 2018 12:29 am   



Atlantis <marekw1986NOSPAM@wp.pl> napisał(a):
Quote:
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ł...

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

Quote:
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.

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

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

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:
https://github.com/RIOT-OS/RIOT/blob/master/cpu/esp8266/syscalls.c

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

Atlantis
Guest

Mon Nov 05, 2018 1:10 pm   



On 05.11.2018 00:29, Grzegorz Niemirowski wrote:

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

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ć?


Quote:
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.

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


Quote:
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:
https://github.com/RIOT-OS/RIOT/blob/master/cpu/esp8266/syscalls.c

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

Goto page Previous  1, 2, 3  Next

elektroda NewsGroups Forum Index - Elektronika Polska - Alternatywa dla ESP8266/ESP32? Moduł EMW3165.

NOWY TEMAT

Regulamin - Zasady uzytkowania Polityka prywatnosci Kontakt RTV map News map