Atlantis <m...@w...pl> napisał(a):
> Dyskusja toczyła się parę wątków wyżej.
> Tak naprawdę mój projekt jest modyfikacją tego kodu:
> https://github.com/Spritetm/esphttpd

Pamiętam, ale zawsze jest łatwiej gdy widzi się kompletny kod :)

> Moje obawy budzi jednak jeszcze jeden fakt - biblioteki te odwołują się
> m.in. do stdio.h, a z tego co kiedyś czytałem, na ESP8266 nie jest to
> zalecane z uwagi na sposób w jaki biblioteka korzysta z funkcji
> memloc(). Z tego co pamiętam w SDK udostępnione są zamienniki
> najczęściej używanych funkcji z stdio i to z nich powinno się korzystać.

Wcale nie tak rzadko korzysta się z zamienników standardowego stdio. Ze
względu na ograniczenia mikrokontrolerów ludzie piszą swoje własne, np.
tinyprintf http://www.sparetimelabs.com/tinyprintf/tinyprintf.p
hp A nawet to
standardowe stdio jest okrajane i np. wymaga dodatkowych przełaczników
llinkera żeby działało %f

> No i jak to już ktoś napisał. Może i ESP8266 jest popularną platformą,
> ale nie wiem kto wpadł na tak idiotyczny pomysł, żeby umieszczenie
> funkcji we flashu wymagało osobnego atrybutu, a domyślnie trafiała ona
> do obszaru RAM-u o rozmiarze zaledwie 32kB...

Być może jest to idiotyczne, ale z mojej przygody z Blackfinem pamiętam, że
tam było tak samo :)

> Nie wiem czy w chwili obecnej jedyną rozsądną alternatywą nie będą dla
> mnie moduły od Microchipa. Są co prawda zauważalnie droższe, ale łatwo
> zintegrować je z istniejącymi projektami opartymi na ENC28J60,
> wykorzystującymi biblioteki MLA (z Harmony jeszcze nie
> eksperymentowałem). Ten temat mam już w miarę rozpracowany. Może z
> wyższą ceną związana będzie też nieco lepsza jakość?

Gdybyś coś z nimi robił, to będe wdzięczny za podzielenie się wrażeniami na
grupie.

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

do góry

On 30/10/2018 07:35, cezar wrote:
> On 28/10/2018 07:26, Atlantis wrote:
>> Szukam jakiejś alternatywy dla programowalnych modułów WiFi od
>> Espressif. Microchip produkował kiedyś moduły WiFi na SPI, które można
>> było podpiąć do mikrokontrolera. Niestety w chwili obecnej nie ma ich w
>> polskich sklepach.
>>
>> Ostatnio natknąłem się na coś takiego:
>> https://botland.com.pl/moduly-wifi/4390-modul-wifi-e
mw3165-cortex-m4-.html
>>
>> https://elty.pl/pl/p/Modul-WiFi-EMW3165-Cortex-M4-ze
wnetrzna-antena/1682
>>
>> Tutaj wersja "breadboard friendly", ze zintegrowanym programatorem:
>> https://allegro.pl/wifi-mcu-stm32f4-wifi-broadcom-lu
a-emw3165-i6052421775.html
>>
>>
>> Z opisu wynika, że jest to STM32F4 zamknięty w jednym module z
>> kontrolerem WiFi.
>>
>> Ktoś z Was się z tym zetknął? Istnieje możliwość programowania tego nie
>> w języku Lua, ale normalnie, za pomocą kompilowanego kodu C? Istnieją
>> jakieś biblioteki, które pozwoliłyby na obsłużenie modułu WiFi i
>> realizację połączenia sieciowego w standardowy sposób, choćby za pomocą
>> jakiegoś lwIP?
>>
>
>
> jest sporo alternatyw ale uwierz mi ze jezeli o wsparcie, community,
> dokumentacje i mozliwosci to nie ma nic lepszego niz ESP8266 i ESP32
>


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


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

Wersja bez atmela na pokładzie jest do dostania za 10-15 dolców.

No ale bez 500mA nie podchodź....

c.

do góry

Marek <f...@f...com> napisał(a):
> Nie wiem jak jest teraz ale jak rok temu intesowalem się ESP8266 i ESP32
> to nigdzie nie mogłem znaleźć źródeł stosu tcpip używanego w tych mcu oraz
> jaka jest organizacja softu.

W przypadku ESP8266 używane jest lwip (źródła w SDK, katalog
ESP8266_NONOS_SDK-2.1.0\examples\lwip_open_src_templ
ate_proj\lwip\)

> Wszędzie wyglądało, z user ładuje ttylko swój kod a reszta siedzi gdzieś w
> środku, to mnie trochę zniechęciło, bo to wyglądało jak typowy blackbox.

Pytanie czy rzeczywiście musisz mieć źródła wszystkiego i wszystko
kontrolować. W wielu przypadkach tak formuła będzie ułatwieniem.

> Jak jest teraz?

Z tego co wiem to podobnie. Na ESP8266 była funkcja user_init() a na ESP32
jest app_main(). Funkcje te inicjują Twój kod. Reszta Twojego kodu reaguje
na zdarzenia. Można korzystać z FreeRTOS i tworzyć taski.

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

do góry

On Tue, 30 Oct 2018 10:36:48 +0100, Atlantis <m...@w...pl>
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?

--
Marek

do góry

On Tue, 30 Oct 2018 12:43:17 +0100, "Grzegorz Niemirowski"
<g...@p...onet.pl> wrote:
> Z tego co wiem to podobnie. Na ESP8266 była funkcja user_init() a
> na ESP32
> jest app_main(). Funkcje te inicjują Twój kod. Reszta Twojego kodu
> reaguje
> na zdarzenia. Można korzystać z FreeRTOS i tworzyć taski.

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?

--
Marek

do góry

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

do góry

Atlantis wrote on 30.10.2018 15:10:
> 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.

do góry

On 30.10.2018 19:21, Zbych wrote:

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

do góry

Atlantis <m...@w...pl> napisał(a):
> 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/

do góry

On 31.10.2018 11:56, Grzegorz Niemirowski wrote:

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

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.

do góry