Elektroda.pl
Elektroda.pl
X
PCBwayPCBway
Proszę, dodaj wyjątek dla www.elektroda.pl do Adblock.
Dzięki temu, że oglądasz reklamy, wspierasz portal i użytkowników.

Ulepszanie ESP8266 do 4MB pamięci

05 Sie 2016 19:42 4596 18
  • Poziom 13  
    Cześć!
    Nagrałem filmik jak wymienić pamięć w ESP8266 na największą obsługiwaną - 4MB.
    Mam nadzieję że komuś pomoże:

    Link
  • PCBwayPCBway
  • Poziom 40  
    Dziwne. Ostatnio czytałem wypowiedź kolegi z tego forum, który przypadki częstych "padów" kości pamięci tłumaczył tym, że ESP tworzy na flashu swoją własną strukturę danych i naruszenie tej struktury powoduje błąd sygnalizowany jako uszkodzenie kości flash. Tymczasem Ty wlutowujesz czysty nie sformatowany w żaden sposób flash i układ wstaje i działa bezproblemowo. Ciekawa sprawa.
  • PCBwayPCBway
  • Poziom 13  
    Stawiam na to że ja używam jej z Ardiuno IDE w ten sposób że wymuszam uruchomienie układu z UART i wgrywam kod, a kolega używał jakiegoś NodeMCU czy innego takiego wytworu.
    W mojej wersji we flashu jest przechowywany wyłącznie skompilowany kod, nic nie zostaje pomiędzy zaprogramowaniami.
  • Poziom 40  
    Chumanista napisał:
    a kolega używał jakiegoś NodeMCU

    To się zgadza - kolega ten używa NodeMCU.
  • Poziom 13  
    No to ono we flashu trzyma cały interpreter LUA i system plików we flashu. A ja tylko program.
  • Moderator na urlopie...
    Ale fakt jest taki, że flashe z "czystym" programem też padają. I co z tego, że flash działa, skoro program ma choćby 1 bajt przekłamany i idzie w krzaki? :D
  • Poziom 40  
    Kolego a może znasz stronkę gdzie od podstaw jest napisane jak skonfigurować arduino pod pracę z ESP? Właśnie sobie pobrałem arduino ale w narzędzia->płytka nie mam esp i tak trochę się motam. Pobrałem bibliotekę Arduino-master z githuba, ale próba wrzucenia przez "pokaż zip" nic nie daje, a ręczne jej wklejenie do folderu libraries powoduje, że po ponownym uruchomieniu mam informację o tym, że biblioteka jest niepoprawna.
  • Poziom 40  
    Hej, dzięki za link. Konfiguruję według opisu i również według tego filmiku:
    https://www.youtube.com/watch?v=tMRpYmDgkL0
    i w momencie jak już chcę wgrać program na ESP dostaję błąd: "warning: espcomm_send_command: didn't receive command response
    warning: espcomm_send_command(FLASH_DOWNLOAD_BEGIN) failed
    error: espcomm_upload_mem failed"
    Port i parametry transmisji są dobre - widzę odpowiedzi w monitorze RSa. Czy muszę mieć wgrany jakiś specjalny firmware na te moje D1 mini?

    Dodano po 26 [minuty]:

    Poprawka. Były dobre. Już nie są. Wziąłem inny moduł i program się wgrał. A ten poprzedni już nie działa na 115200 tylko na 74880bps i po resecie zwraca coś takiego " ets Jan 8 2013,rst cause:2, boot mode:(3,7)" Czy mogę go jakoś zresetować/wrócić do życia?
  • Poziom 22  
    To typowy błąd utraty spójności danych na flashu, podczas zapisu danych zostało odłączone zasilanie i jest zong. Nie ma znaczenie co jest wgrane do flasha, czy Arduino, Basic, Lua. Niektóre pamięci udaje się uratować formatowaniem pamięci. Program znajdziesz na stronie ESPBASIC.COM. Formatuje się w pierwszej kolejności do 1MB, jeśli to się powiedzie, ponownie wygrywamy firmware jaki nas interesuje. Co do programowania ESP w Arduino, to trzeba mieć na uwadze, że to najgorszy z języków programowania dla ESP, ze względu na gigantyczne pożeranie pamięci przez rezerwację pamięci dla zmiennych. Dlatego jest RTOS, Lua, czy Basic bardzo wygodny w przypadku aktualizacji oprogramowania, bo edytor jest obsługiwany ze strony internetowej. Wracając do systemu plików, ESP ma własny i nie ma znaczenia język programowania, kiedy kość jest czysta, formatuje sobie. Jeśli wystąpił błąd we flashu, ESP wpada w pętle bez końca i nie bootuje się, Wywala wtedy błąd na COM przy prędkości 74880. Może się też flashować pokazując, że jest ok załadowany firmware, ale nie chce po resecie wysterować. Nie ma na to złotego środka jak na razie, a bynajmniej mi nie jest znany poza próbą formatowania flasha programem od ESP BASIC.
  • Poziom 40  
    Czyli jak rozumiem, skoro nie działa ESPBASIC pozostaje mi fizyczna wymiana kości FLASH?
  • Poziom 22  
    Kość sama w sobie pewnie jest sprawa, należy ją sformatować. Jest kilka programów do tego, między innymi ten ze strony ESP BASIC, jeśli znajdziesz inne próbuj, na pewno jest jakiś sposób na poprawne formatowanie pamięci. Formatowanie powinno być "", bo to chodzi o jakieś nadpisywane pliki, które dodaje sobie ESP. Łatwo to sprawdzić, właśnie programem do formatowania od Basic'a. Nawet jak masz podpięte 16MB, a formatujesz do 512, to ESP widzi tylko 512kb, a nie 16MB. Niektóre pamięci udaje się tak ożywić, inne nie. Dlaczego, nie wiem. Na wielu forach temat jest poruszany i żadnych konkretów nie znalazłem. Myślę, że można się zapytać, autora ESP BASIC, na czym polega formatowanie i szukać rozwiązania problemu po tej linii.
  • Poziom 2  
    Ktoś napisał że 4M to max widziałem opcje z 32M. Czy to te 32M stanowi problem? Czy bedzie je można wykorzystać?
  • Poziom 22  
    Po części TMF dał Tobie odpowiedź. Wspomniane 32Mbity to 4Mbajty. Natomiast maksymalna wartość jaką firmware pozwala adresować to 128Mbitów czyli 16Mbajtów. W pamięć taką wyposażony jest moduł ESP-13. Oczywiście można wyposażyć ESP w więcej pamięci, ale to nie dotyczy pytania;)
  • Poziom 19  
    Zaprogramowałem już kilka ESP (zarówno 01 jak i 12). Działają bardzo dobrze. Chciałem jednak poznać bliżej sposób działania - jak wygląda współpraca FLASH z wewnętrzną pamięcią RAM? Jak działa pamięć w RTC? Jak "poukładane" są dane we FLASH?
    Tu moje pytanie - czy ktoś widział jakiś dobry opis (polski lub angielski) tych technicznie bardziej zaawansowanych szczegółów?
  • Poziom 21  
    "Tymczasem Ty wlutowujesz czysty nie sformatowany w żaden sposób flash i układ wstaje i działa bezproblemowo. Ciekawa sprawa."

    A i owszem ;->
    Na ten artykuł natknąłem się już po fakcie. Mianowicie miałem parę modułów z ESP-01 (nie "S") z cieszącymi się złą sławą pamięciami PUYA, do których usiłowałem wgrać ESP Basic. Wgrywać, owszem, się wgrywał, ale to co moduły wyprawiały z systemem plików, to [autocenzura]. Niewiele myśląc zamówiłem u Chińczyków kilka kostek W25Q80BVSIG oraz - trochę już myśląc - kilka W25Q32BVSIG. W tzw. międzyczasie otrzymałem zamówione wcześniej ESP-01S i ESP-12F, więc o temacie zapomniałem. Kiedy po tradycyjnych 2 miesiącach w skrzynce znalazłem paczkę a w niej - o dziwo - faktycznie Winbondy, zabrałem się raźno do roboty. I faktycznie - po przelutowaniu układy wstały bezproblemowo, jedynie w przypadku 32-megabitowej kości trzeba było w programatorze (używam ESP8266 Download Tool) zaznaczyć rozmiar nie 32Mbit a 32Mbit-C1, cokolwiek to C1 oznacza. Na razie ESP Basic się nie sypie, więc operacja chyba przebiegła pomyślnie. Mimo, że wątek już dawno zdechł, postanowiłem dorzucić swoje 3 grosze, w razie gdyby jakiś nieszczęsny posiadacz modułów z pamięciami PUYA kopał w poszukiwaniu rozwiązania. Nie kombinować z bibliotekami próbującymi oswoić te pamięci, zamówić kości, przelutować i cieszyć się w pełni sprawnymi (a w przypadku kości 32 Mbit nawet ulepszonymi) modułami. Chyba, że zostajemy przy firmware z komendami AT+ do wersji 1.6.2 włącznie, z tym nawet te PUYA działają prawidłowo, może dlatego, że nie jest tam tworzony system plików.
  • Poziom 32  
    Miałem kilka ESP-01s z tym flashem PUYA i działały bez zarzutu dopóki program nie modyfikował zawartości flash w czasie działania modułu (czyli np. zwykłe operacje na plikach). Wg mnie jednak łatwiej jest dodać parę linijek do "/cores/esp8266/Esp.cpp":
    Code:

    bool EspClass::flashWrite(uint32_t offset, uint32_t *data, size_t size) {
    -    ets_isr_mask(FLASH_INT_MASK);
    -    int rc = spi_flash_write(offset, (uint32_t*) data, size);
    -    ets_isr_unmask(FLASH_INT_MASK);
    -    return rc == 0;
    +   static uint32_t flash_chip_id = 0;
    +
    +   if (flash_chip_id == 0)
    +      flash_chip_id = getFlashChipId();
    +   ets_isr_mask(FLASH_INT_MASK);
    +   int rc;
    +   uint32_t* ptr = data;
    +   if ((flash_chip_id & 0x000000ff) == 0x85) { // 0x146085 PUYA
    +      static uint32_t read_buf[SPI_FLASH_SEC_SIZE / 4];
    +      rc = spi_flash_read(offset, read_buf, size);
    +      if (rc != 0) {
    +         ets_isr_unmask(FLASH_INT_MASK);
    +         return false;
    +      }
    +      for (size_t i = 0; i < size / 4; ++i) {
    +         read_buf[i] &= data[i];
    +      }
    +      ptr = read_buf;
    +   }
    +   rc = spi_flash_write(offset, ptr, size);
    +   ets_isr_unmask(FLASH_INT_MASK);
    +   return rc == 0;
     }

    (tam gdzie - zakomentować, to gdzie plus dodać) niż przelutowywać kość flash.
  • Poziom 21  
    > "Wg mnie jednak łatwiej jest dodać parę linijek do "/cores/esp8266/Esp.cpp":
    [...] niż przelutowywać kość flash."

    Pozwolę sobie nie zgodzić się z tym. Przelutowanie pamięci (koszt kilka zł) rozwiązuje problem radykalnie, a przy zastosowaniu 32-Mbitowej kości przy okazji "ubogaca" moduł. W dodatku dla użytkowników np. ESP Basic, wgrywających gotowy firmware w postaci .bin i tworzących programy .bas, obiekt "/cores/esp8266/Esp.cpp" jest elementem klasowo obcym i ja np. nawet nie mam pojęcia, gdzie miałbym wprowadzić te poprawki.