Alternatywa dla ESP8266/ESP32? Moduł EMW3165.

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:

formatting link
Tutaj wersja "breadboard friendly", ze zintegrowanym programatorem:
formatting link
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?

Reply to
Atlantis
Loading thread data ...

Atlantis szuka jakiejś alternatywy dla programowalnych modułów WiFi od Espressif:

54 zł (słowinie piećdziesiąt cztery złote 00 groszy)! Czy ktoś to w ogóle kupował za taka kasę?! To jest jakoś istotnie lepsze (widzę, że ma złącze do zewnętrznej anteny) od modułów za dwa dolary?

formatting link
?page_id=917

Reply to
invalid unparseable

Jest w polskim farnell, w czym problem? Poza tym jest wiele lokalnych polskich sklepów, które mają dostępny asortyment farnella (np. wekton.com.pl) wystarczy zamówić u nich i przyślą.

Reply to
Marek

W dniu 28.10.2018 o 08:26, Atlantis pisze:

Wiesz oczywiście, że ESP8266 oraz ESP32 można programować za pomocą C?

Ze stron poniżej możesz pobrać (za free lub, jeśli chcesz wspomóc autora, za niewielką kasę) książki na ten temat

formatting link

Reply to
M.L

Wiem. Problem zaczyna się wtedy, gdy trafiasz na jakiś nietypowy problem i zupełnie nikt nie wie jak go rozwiązać, bo znaczna część użytkowników tej platformy to raczej początkujący miłośnicy Arduino. Potem przedzierasz się przez fora żeby dowiedzieć się w jaki sposób zmodyfikować Makefile, żeby to co robisz zadziałało. Natomiast taki STM32 jest w chwili obecnej niemal standardem, więc gdyby miało się okazać, że istnieje moduł zawierający taki MCU, WiFi i zestaw bibliotek potrafiących to ogarnąć w sposób standardowy, o chyba warto byłoby mu się bliżej przyjrzeć.

Reply to
Atlantis

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

Obawiam się, że nie ma popularniejszej, a więc więc mającej teoretycznie lepsze wsparcie, platformy. Zawsze możesz zapytać na Elektrodzie (klimat jest jaki jest, ale przynajmniej można spotkać kompetetnych ludzi) albo podrzucić tutaj linka do źródeł jeśli nie są tajne.

Niestety ST nie opracowało jeszcze czegoś takiego i w sumie jest to dziwne. W przypadku BLE nie mieli problemu (układy BlueNRG-1/2).

Reply to
Grzegorz Niemirowski

jest sporo alternatyw ale uwierz mi ze jezeli o wsparcie, community, dokumentacje i mozliwosci to nie ma nic lepszego niz ESP8266 i ESP32

Reply to
cezar

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. 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. Jak jest teraz?

Reply to
Marek

Dyskusja toczyła się parę wątków wyżej. Tak naprawdę mój projekt jest modyfikacją tego kodu:

formatting link
Udało mi się już dojść do tego, co jest powodem problemów. Całkowicie zapełniona zostaje sekcja ".text" (fragment RAM-u, do którego trafiają funkcje, które powinny być wykonywane jak najszybciej). Wygenerowałem mapę i okazuje się, że trafia tam sporo kodu, który (jak dla mnie) mógłby się wykonywać bezpośrednio z flasha: funkcje systemowe, biblioteka standardowa oraz całkiem sporo kodu odpowiedzialnego za działanie serwera www. Okazuje się, że autor biblioteki libesphttpd wrzucił do projektu gotowe fragmenty kodu do obsługi systemu plików, nie przypisując funkcjom atrybutów ICACHE_FLASH_ATTR, przez co są one umieszczane w RAM-ie. To jeszcze mógłbym ręcznie poprawić. 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ć.

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

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

Reply to
Atlantis

Nie wiem jak jest esp8266 tetaz ale śledze esp32 od początku i bardzo mu kibicowałem.

Zobacz tutaj:

formatting link
tam cały development kit bazujący na FreeRTOS

Polecam pooglądać filmy od tego gościa (jeśli nie przeszkadza Ci Angielski z niemieckim akcentem)

formatting link
c.

Reply to
cezar

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

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

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

formatting link
A nawet to standardowe stdio jest okrajane i np. wymaga dodatkowych przełaczników llinkera żeby działało %f

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

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

Reply to
Grzegorz Niemirowski

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

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

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

c.

Reply to
cezar

Marek snipped-for-privacy@fakeemail.com napisał(a):

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

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

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.

Reply to
Grzegorz Niemirowski

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

Reply to
Marek

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?

Reply to
Marek

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

Reply to
Atlantis

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.

Reply to
Zbych

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.

Reply to
Atlantis

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

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

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

Reply to
Grzegorz Niemirowski

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.

Reply to
Atlantis

ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.