Skocz do zawartości
Komentator

Kompendium pamięci zewnętrznych: EEPROM, FLASH, FRAM

Pomocna odpowiedź

Kompendium pamięci zewnętrznych: EEPROM, FLASH, FRAM

Wybór rodzaju używanej pamięci zewnętrznej ma wpływ na działanie całego urządzenia. Jak dobrać pamięć, która pozwoli na szybki odczyt, zapewni bezawaryjność i pomieści wszystkie dane? Kompendium pamięci zewnętrznych to zbiór porad, które znacznie ułatwiają wybór pomiędzy technologiami EEPROM, FLASH oraz FRAM.

UWAGA, to tylko wstęp! Dalsza część artykułu dostępna jest na blogu.

Przeczytaj całość »

Poniżej znajdują się komentarze powiązane z tym wpisem.

  • Lubię! 1

Udostępnij ten post


Link to post
Share on other sites
1 godzinę temu, Komentator napisał:

Fragment dokumentacji popularnego układu ATmega168 (znanego z Arduino UNO)

A nie 328?

  • Lubię! 1

Udostępnij ten post


Link to post
Share on other sites
Gość es2

Autor publikacji wprowadza w błąd

Cytat

Jeśli każdy sektor w pamięci posiada 16 stron, a każda strona 256 bajtów to potrzebujemy 4kB wolnej pamięci RAM na bufor pomocniczy – całkiem sporo.

- Wszystkie pamięci FLASH mają możliwość kasowana stron sektorów bloku. W opisywanym przypadku wystarczy więc 256bajtów RAM a nie 4kB.

-Wszystkie pamięci FLASH jakie znam, mają bufor wielkości strony. Dane wysyła się do bufora po czy dokonuje zapisu.  Nie ma więc potrzeby tworzenia bufora w RAM uC. Kolejne udogodnienie (nie zawsze występuje) to tryb wczytaj-zmodyfikuj-zapisz. Strona jest wczytywana do bufora w pamięci FLASH (tak ZAWSZE czyta sie pamięć FLASH, nawet jak odczyt jest liniowy, to "w tle" pośredniczy bufor) tam można ją zmodyfikować, po czy następuje operacja kasowania i zapisu.

Bzdurą więc jest stwierdzenie, że w przypadku użycia pamięci FLASH, potrzeba dużo RAM w uC. Artykuł jest sponsorowany i widać sponsorowi zależy na sprzedaży pamięci FRAM , choć często wystarczyłaby FLASH. Duża i tania pamięć FLASH, może oferować (przy utracie pojemności) liczbę cykli zapisu, nieosiągalna dla pamięci EEPROM. Dzięki temu, że wiele pamięci FLASH, ma dwa bufory, implementacja pseudo EEPROM, nie wymaga tworzenia buforów w RAM uC.

- Pamięci EEPROM. W artykule napisane jest o tym jaki są wolne, zapis jednego bajtu to 5ms. Nigdzie jednak nie napisano, że pamięci EEPROM posiadają stronicowy tryb zapisu. Małe pamięci (np 512bajtów) posiadają bufor 2..4bajty,  większe (np 2kB) co najmniej 8 bajtów, duże, (np24LC512) 64 bajty.  Przy zapisie strony, czas zapisu bajtu wynosi więc 5ms / 64 = ok 78us.

Dobrze by było, aby autor artykułu, zanim wypowie się publicznie, przeczytał noty katalogowe pamięci a administrator, jak najszybciej poprawił treść, bo wprowadza w błąd i sugeruje używanie pamięci FRAM jako jedynie słusznych.

PS

Oczywiście, jeśli sie uprzeć, to znajdzie się jakieś archaiczne wykonania FLASH gdzie bez bufora w uC się nie obejdze, zwłaszcza w trybie R-WR czy EEPROM, które nie mają trybu stronicowego, ale tak jak nikt rozsądny, nie używa w nowych projektach Z-80 czy 8051 12-taktowego (1-taktowe to  pudrowanie trupa mają sens w liftingu starych projektów a nie tworzeniu nowych, zwłaszcza jak porówna się ceny i mozliwości), tak i nie ma sensu w nowych konstrukcjach używać archaicznych pamięci.

Udostępnij ten post


Link to post
Share on other sites
56 minut temu, es2 napisał:

Autor publikacji wprowadza w błąd

- Wszystkie pamięci FLASH mają możliwość kasowana stron sektorów bloku. W opisywanym przypadku wystarczy więc 256bajtów RAM a nie 4kB.

-Wszystkie pamięci FLASH jakie znam, mają bufor wielkości strony. Dane wysyła się do bufora po czy dokonuje zapisu.  Nie ma więc potrzeby tworzenia bufora w RAM uC. Kolejne udogodnienie (nie zawsze występuje) to tryb wczytaj-zmodyfikuj-zapisz. Strona jest wczytywana do bufora w pamięci FLASH (tak ZAWSZE czyta sie pamięć FLASH, nawet jak odczyt jest liniowy, to "w tle" pośredniczy bufor) tam można ją zmodyfikować, po czy następuje operacja kasowania i zapisu.

Bzdurą więc jest stwierdzenie, że w przypadku użycia pamięci FLASH, potrzeba dużo RAM w uC. Artykuł jest sponsorowany i widać sponsorowi zależy na sprzedaży pamięci FRAM , choć często wystarczyłaby FLASH. Duża i tania pamięć FLASH, może oferować (przy utracie pojemności) liczbę cykli zapisu, nieosiągalna dla pamięci EEPROM. Dzięki temu, że wiele pamięci FLASH, ma dwa bufory, implementacja pseudo EEPROM, nie wymaga tworzenia buforów w RAM uC.

Dobrze że zastrzegasz, że Twoje rozważania dotyczą tylko pamięci jakie znasz.
Micron (np. MT25Q...) sector erase 64kB, subsector erase 4kB, Winbond W25Q... sector erase 4kB i ogólnie cała seria układów FLASH SPI 25xx.
Możesz podać przykładowe oznaczenia pamięci FLASH SPI, które można czyścić stronami po 256bajtów (nadal to więcej niż 1 bajt). Przyda się dla potomnych i będzie wartościowym uzupełnieniem do artykułu.

Dziękuję za czujność. Mamy cały magazyn pamięci FRAM i nie mamy co z nimi zrobić 😉

  • Lubię! 1

Udostępnij ten post


Link to post
Share on other sites
Gość es2

Nie ważne czy strona ma 256bajtów czy 64kB, ważne, że bufor znajduje się w pamięci.

AT45DB321D:

User Configurable Page Size
– 512 Bytes per Page
– 528 Bytes per Page
Page Program Operation
– Intelligent Programming Operation
– 8,192 Pages (512/528 Bytes/Page) Main Memory
Flexible Erase Options
– Page Erase (512 Bytes)
– Block Erase (4 Kbytes)
– Sector Erase (64 Kbytes)
– Chip Erase (32 Mbits)
Two SRAM Data Buffers (512/528 Bytes)

Poproszę o przykład EEPROM (dużego) bez możliwości zapisu stronami i współczesnej FLASH, która nie ma bufora i bajty zapisywane są pojedynczo.

Udostępnij ten post


Link to post
Share on other sites

Z całym szacunkiem, ale gdybyś przeczytał artykuł ze zrozumieniem to bym nie musiał teraz cytować:

"pamięci AT45xx wyróżniają się wbudowanym dodatkowym buforem pomocniczym, który zmniejsza zapotrzebowanie na pamięć RAM."

Gdybyś faktycznie przeczytał ze zrozumieniem, to byś nie zadawał też drugiego pytania.

PS. Dopiero teraz zobaczyłem Twoją forumową reputacje i dałem się nabrać na te zaczepki 😉

Udostępnij ten post


Link to post
Share on other sites
1 godzinę temu, eksio napisał:

A nie 328?

Słuszna uwaga, na zrzucie z dokumentacji był zaznaczony poprawny układ, ale w podpisie wkradł się błąd - już poprawiłem 🙂

Udostępnij ten post


Link to post
Share on other sites

Na początek chciałbym podziękować autorowi za zajęcie się niełatwym tematem pamięci eeprom oraz podzieleniem swoją wiedzą.

Nie jestem ekspertem od pamięci, jednak pewne doświadczenie z pamięciami EEPROM, a FLASH w szczególności mam, stąd moje drobne uwagi:

18 godzin temu, Komentator napisał:

w układach EEPROM mamy możliwość zapisania (nadpisania) pojedynczych bajtów, zaś w układach FLASH czyszczenie oraz zapis musimy przeprowadzać zbiorczo.

Co do czyszczenia (erase) jest to jak najbardziej prawda, jednak w przypadku zapisu można byłoby polemizować - pamięć Flash NOR (albo chociaż wspomniana N25Q128A) pozwala na zapisanie pojedynczych bajtów. Można nawet zmieniać pojedyncze bity - zapisując możemy zmieniać bit o wartości 1 na 0, ale nie odwrotnie, więc kolejne zapisy działają jak logiczna koniunkcja (AND). To trochę czepiactwo, ale takie sztuczki pozwalają wydłużyć życie pamięci w niektórych zastosowaniach.

18 godzin temu, Komentator napisał:

Sekwencja zapisu kilku bajtów do pamięci FLASH powinna być następująca:

  1. odczyt danych z sektora do bufora,
  2. wyczyszczenie sektora w pamięci
  3. modyfikacja bajtów w buforze,
  4. zapis danych do sektora.

Można od biedy przyjąć, że jest to jakaś sekwencja zapisu, ale na pewno nie należy uważać, że taka być powinna. Jeśli między punktami 2, a 4 nastąpi zanik zasilania, błąd itd, stracimy być może bardzo cenne dane. Nie mówię, że tak się nie robi, ale mając coś ważnego w pamięci można to inaczej rozwiązać - chociażby przy użyciu dwóch sektorów. Wystarczy najpierw skopiować dane do nowej lokalizacji, sprawdzić czy się poprawnie zapisały i dopiero wtedy usunąć stare. Opcji jest dużo więcej, przykładowo kasowanie danych często nie wykonuje się od razu - ponieważ zajmuje dużo czasu, można wykonywać je w "tle", a wykorzystywać kolejne sektory.

Wszystko zależy od zastosowania - więc nagorszy jest wyraz "powinna", resztę można przeboleć.

Przy okazji - wykorzystując dodatkowe sektory w pamięci zewnętrznej argument o wykorzystaniu pamięci RAM chyba można odłożyć między bajki, aczkolwiek małe mikrokontrolery pewnie nie będą miały pamięci liczonej w GiB i wtedy faktycznie proste algorytmy mają zastosowanie.

Następny fragment to czepianie, ale jakoś nie mogłem pominąć:

18 godzin temu, Komentator napisał:

Jeżeli tylko istnieje możliwość poświęcenia 4 wyprowadzeń mikrokontrolera to protokół SPI będzie najlepszym wyborem.

Od razu przychodzi mi do głowy mnóstwo kontrprzykładów - a może QSPI jest lepszy, dlaczego nie SD/MMC, a jak znajdę pamięć i2c za 10% ceny to nadal SPI jest najlepsze, itd. itp... Proponuję uważać z podawaniem ex cathedra co jest na świecie najlepsze, może się trafić taki maniak jak ja i jak znajdzie jeden kontrprzykład, to cały wywód wyrzuci do kosza. Może lepiej napisać że: to no ogół dobry wybór, najlepszy znany autorowi, najlepszy ze względu na cenę w projekcie xyz itd.

18 godzin temu, Komentator napisał:

Do obsługi takich pamięci stosuje się zaawansowane kontrolery, które dbają o to, aby każda z komórek była zapisana porównywalną ilość razy, a uszkodzone sektory są odpowiednio zaznaczane i wyłączane z użytku

Wear-leveling, bo tak nazywa się technika dbania od równomierne zużycie pamięci może być stosowana za pomocą samego oprogramowania. Co więcej zużycie pamięci występuje również w przypadku NOR oraz tradycyjnego eeprom. Przy okazji - to argument za użyciem FRAM, pozostałe omawiane pamięci i tak po pewniej liczbie cykli kasowania, nie będą działały poprawnie. Oczywiście NAND może zawierać uszkodzone sektory od nowości. Ale to trochę jak z pikselami matrycy LCD - chcemy mieć tanio i wysoką rozdzielczość, więc czasem trzeba się pogodzić z wypalonym pikselem / sektorem.

Jak chodzi o pamięci Flash, to szkoda że w artykule nie pojawiła się informacja o eMMC - jest to pamięć NAND Flash z wbudowanym kontrolerem. Dzięki temu można jej używać w sposób zbliżony do dysku twardego - albo raczej karty SD. W każdym razie "gołe" pamięci NAND Flash są nadal używane, ale obserwując np. rynek klonów Raspberry-Pi coraz trudniej je sporkać. Natomiast eMMC jest bardzo popularne.

18 godzin temu, Komentator napisał:

Problemu z degradacją komórek nie ma w przypadku pamięci NOR.

Jest oczywiście lepiej niż w przypadku NAND, ale zarówno cykle kasowania, jak i czas są wrogiem każdej pamięci eeprom. NOR nie jest wyjątkiem...

I na koniec - jak chodzi o różnice między FRAM/eeprom/NOR flash, a NAND Flash występuje ogromna różnica w odczycie. Wszystkie z pierwszej grupy pozwalają na odczyt pojedynczych bajtów. Natomiast w przypadku NAND Flash konieczny jest odczyt całej strony - nawet jeśli interesuje nas jeden bajt.

Dlaczego to taka różnica? Otóż nowsze mikrokontrolery, np. z rodziny STM32 mają wbudowane kontrolery pamięci NOR Flash z interfejsem QSPI. Dzięki temu program może się wykonywać bezpośrednio z pamięci zewnętrznej. Nie potrzebne są dedkowane procedury dla SPI, żeby używać FRAM, czy eeprom, czy jeszcze bardziej skomplikowany kod dla NAND. Konfigurujemy kontroler QSPI Flash i od tego momentu mikroprocesor widzi NOR Flash w swojej przestrzeni adresowej. To bardzo fajna sprawa - polecam 🙂

  • Lubię! 2

Udostępnij ten post


Link to post
Share on other sites

Elvis, dziękuje za merytoryczne uwagi. Ze wszystkim się zgadzam, ale odniosę się jeszcze do kilku wybranych kwestii.

Co do zapisu i czyszczenia - racja że można zmieniać "1" na "0" bez wcześniejszego czyszczenia, ale osobiście w praktyce nigdy z taką implementacją się nie spotkałem, co oczywiście nie znaczy że ktoś tak nie robił. Artykuł jest napisany bez wdawania się w szczegóły w wielu miejscach aby nie komplikować sprawy i nie przytłoczyć osób dopiero wchodzących w temat. Jestem sobie w stanie wyobrazić kiedy uC nadpisuje jakieś liczniki binarne we flashu gdzie tylko zmieniają się pojedyncze bity w bajcie i tylko z "1" na "0", ale w praktyce nigdy się z tym nie spotkałem. Osobiście zawsze czyszczę przed nadpisaniem danych i fakt że często to robię w tle. Biorąc pod uwagę że zwykle zapisuje się pamięć stronami, to minimum 256*8 bitów nie mogłoby zmieniać swojego stanu z 0 na 1. Dla mnie przypadek abstrakcyjny, ale jeżeli znasz jakąś ciekawą i praktyczną implementacje w/w mechanizmu to chętnie się zapoznam. Człowiek uczy się całe życie.

Co do sekwencji zapisu - pełna zgoda. Jest to tylko przykład i to "powinna być" można zastąpić "może być".

I masz racje, powinienem się wystrzegać sformułowań typu "najlepsza/najlepszy" - chciałem żeby poradnik był praktyczny dla osób wchodzących w temat i powinienem był bardziej zaznaczyć że jest to tylko moje subiektywne zdanie i nie mam wyłączności na prawdy uniwersalne 😉

Dziękuje za wartościowy komentarz.

Udostępnij ten post


Link to post
Share on other sites

Z tymi zmianami z 1 na 0 to była głównie ciekawostka - chciałem tylko wspomnieć, że niektóre pamięci NOR flash można zapisywać blokami mniejszymi niż strona, bity to już ekstremalny przypadek.

Przykład użycia sztuczek ze zmianą bitów mógłby się przykładowo przydać do implementacji licznika uruchomień urządzenia, niedawno taki temat się pojawił. Oczywiście "ładniejsza" opcja to użycie pamięci FRAM, ale jeśli jej akurat nie mamy to zmiany bitów mogą być metodą na zmniejszenie liczby cykli kasowania. Bo to co ważne to pamiętać, że NOR ma ograniczoną liczbę cykli kasowania.

Natomiast mechanizm zmian bitów z 1 na 0 bez możliwości powrotu jest bardzo często używany w pamięciach OTP (One Time Programmable).

  • Lubię! 1

Udostępnij ten post


Link to post
Share on other sites
(edytowany)

No tak, ale to tak naprawdę zawsze sprowadza się do operacji na bitach (zakładając że pamięć nie jest wyczyszczona). Jeżeli w pamięci jest zapisany bajt np. 0x28, tj. binarnie 00101000 to możemy ten bajt nadpisać tylko trzema wartościami (00001000, 00100000, 00000000) więc każda operacja zapisu bez wcześniejszego czyszczenia musi się sprowadzić do sprawdzenia bitów czy przypadkiem nie chcemy zmienić z 0 na 1 (co nie przejdzie), a czy to ma sens? to osobna kwestia. Więc nawet zwykły licznik (0, 1, 2, ...) nie ma tutaj zastosowania. Dopiero licznik 2^n (0,2,4,8,16,32...). Ale jeżeli pamięć ma same 0xFF (jest czysta) to i owszem zgoda - możemy zapisywać bajt po bajcie. W pamięciach EEPROM i FRAM można z kolei nadpisać poprzednią zawartość co jest czasem pożądane i wygodne.

Edytowano przez Art
  • Lubię! 1

Udostępnij ten post


Link to post
Share on other sites

To często ma sens. Możesz na przykład używać zapisu unarnego do trzymania jakiegoś prostego licznika, albo mapę bitową w której zaznaczasz zajęte już sektory — wiele systemów plików zaprojektowanych specjalnie dla flash właśnie tak robi.

  • Lubię! 1

Udostępnij ten post


Link to post
Share on other sites

Podobna zasada jest bardzo popularna w pamięciach OTP (One-time Programming) - nowy układ ma pamięć zapełnioną zapalnymi bitami, czyli bajtami o wartości 0xff. Można dowolny bit wyzerować, ale jeśli się to wykona, nie można już go ponownie ustawić (w przypadku eeprom mamy możliwość skasowania sektora, natomiast OTP nie daje takiej możliwości).

Taka pamięć bardzo często jest wykorzystywana do przechowywania konfiguracji mikrokontrolera/mikroprocesora oraz zabezpieczeń. Przykładowo konsole Nintendo używają pamięci OTP do blokowania możliwości downgrade-u oprogramowania. Gdy zainstalujemy nową wersję, kasowany jest kolejny bit - i nie mamy już możliwości powrotu do poprzedniej, np. podatnej na złamanie zabezpieczeń. 

  • Lubię! 1

Udostępnij ten post


Link to post
Share on other sites
Gość es2
(edytowany)
48 minut temu, Elvis napisał:

Podobna zasada jest bardzo popularna w pamięciach OTP (One-time Programming) - nowy układ ma pamięć zapełnioną zapalnymi bitami, czyli bajtami o wartości 0xff. Można dowolny bit wyzerować,

Nie przypadkowo, w większość popularnych 8-bitowych  mikroprocesorów rozkaz NOP ma kod 0x00.

Edytowano przez es2

Udostępnij ten post


Link to post
Share on other sites

Jak zwykle nasz ekspert podaje co wie jako prawdę objawioną. Już nawet wikipedia lepiej działa: https://en.wikipedia.org/wiki/NOP_(code)

Oczywiście są układy, których instrukcja NOP ma kod zero, ale nie wiem czy można je nazwać większością. No chyba że większością tych, które się zna.

  • Lubię! 1

Udostępnij ten post


Link to post
Share on other sites

Dołącz do dyskusji, napisz odpowiedź!

Jeśli masz już konto to zaloguj się teraz, aby opublikować wiadomość jako Ty. Możesz też napisać teraz i zarejestrować się później.
Uwaga: wgrywanie zdjęć i załączników dostępne jest po zalogowaniu!

Anonim
Dołącz do dyskusji! Kliknij i zacznij pisać...

×   Wklejony jako tekst z formatowaniem.   Przywróć formatowanie

  Dozwolonych jest tylko 75 emoji.

×   Twój link będzie automatycznie osadzony.   Wyświetlać jako link

×   Twoja poprzednia zawartość została przywrócona.   Wyczyść edytor

×   Nie możesz wkleić zdjęć bezpośrednio. Prześlij lub wstaw obrazy z adresu URL.


×
×
  • Utwórz nowe...