Elektroda.pl
Elektroda.pl
X

Search our partners

Find the latest content on electronic components. Datasheets.com
Elektroda.pl
Please add exception to AdBlock for elektroda.pl.
If you watch the ads, you support portal and users.

ARM w małej obudowie z prawdziwym EEPROM

Szymon Tarnowski 09 May 2014 13:10 2481 17
Computer Controls
  • #1
    Szymon Tarnowski
    Level 27  
    Witam, szukam procesora do nowych projektów które mają zastąpić wcześniej używane 8bitowce. Kryterium jest mała obudowa max 48pin oraz fizyczna pamięć EEPROM. Wiem że NXP i ST "właśnie" wprowadziły na rynek takie chipy, ale chodzi mi o jakieś alternatywy które na rynku są od dłuższego czasu.

    Od razu wyjaśniam że emulowany eeprom we flash mnie nie interesuje, urządzenia wykorzystuje już flash do przechowywania dużych rzadko zmienianych danych i potrzebuje chociaż 128B na często zmieniane dane które dodatkowo mają przeżyć pełne flashowanie procesora.
  • Computer Controls
  • #2
    cwieek
    Level 12  
    Jeśli chodzi o ST to niestety tylko rodzina STM32L ma wbudowany eeprom. To wersje low power, które mają maks. częstotliwość 32Mhz więc nie za dużo w porównaniu do serii F. A może łatwiej dodać zewnętrzną pamięć?
  • Computer Controls
  • #3
    Smashing
    Level 20  
    Szymon Tarnowski wrote:
    potrzebuje chociaż 128B na często zmieniane dane które dodatkowo mają przeżyć pełne flashowanie procesora.


    To może lepiej dodać baterię i zależności od wersji STM'a masz do 4Kb pamięci.
  • #4
    BlueDraco
    MCUs specialist
    LPC11E i parę innych serii. W rodzinie STM32F też się parę serii znajdzie. Można też użyć zewnętrznej pamięci na I2C lub SPI za grosze - to po pierwsze.

    A po drugie: Pamięć Flash w STM32 może być programowana pojednyczymi słowami, więc nie ma żadnych problemów w użyciu jej do przechowywania często zmienianych danych. Jesta na to parę sposobów, w zależności od rozmiaru danych, które podlegają modyfikacji - jeśli wymieniasz małe fragmenty - trzymasz w pamięci listę zmian. Jeśli całą strukturę - zapisujesz całość, zajmując kolejne lokacje pamięci. Rezerwujesz na to tyle Flash, żeby rozmiar pamięci dzielony przez rozmiar struktury i mnożony przez liczbę gwarantowanych przez producenta cykli kasowania dawał założoną przez Ciebie liczbę zmian w czasie całego życia urządzenia. Czyli np. jeśli chcesz milion razy zmienić 100 bajtów, a producent gwarantuje 10000 cykli, to potrzebujesz 10kiB Flash.
  • #5
    Jado_one
    Level 22  
    Ja tam bym dał taki mały EEPROM microchipa w obudowie SOT23-5 - wtedy można go dodać do każdego procesora, a miejsca prawie nie zajmuje.
  • #6
    Szymon Tarnowski
    Level 27  
    Dziękuję za sugestie, ale ani zewnętrzny eeprom ani użycie pamięci FLASH nie wchodzi w rachubę.
    Osobiście jestem conajmniej zdziwiony tym że większość producentów procesorów nie-ARMowych nie ma problemów z wbudowaniem EEPROM, a w procesorach ARM jest to jakimś problemem. Projekt chwilowo i tak zawisł, więc mogę poczekać na nowsze procesory.
  • #9
    BlueDraco
    MCUs specialist
    Od paru dobrych lat robię projekty urządzeń, które przechowują dane knfiguracyjne i liczniki czasu w pamięci Flash mikrokontrolera i jakoś nigdy nie tęskniłem za EEPROM. Napisz, o co właściwie chodzi z tym EEPROMem i dlaczego uważasz, że Flash dostępny w mikrokontrolerze nie załatwia sprawy.

    Praktycznie problem z Flash zamiast EEPROM występuje tylko wtedy, gdy minimalny rozmiar jednostki programowalnej pamięci jest spory, tak, jak w dawniejszych modelach LPC1xxx, gdzie programować można było min. 256 bajtów. Jeśli jest możliwość programowania 2 lub 4 bajtów - nie widzę przewagi EEPROM nad Flash.
  • #10
    Szymon Tarnowski
    Level 27  
    Po przemyśleniu argumentów kolegów, doszedłem do wniosku że największym argumentem posiadania dedykowanego EEPROMu jest wygoda:
    A zagwarantowany obszar do odczytu i zapisu, nie trzeba optymalizować danych pod kątem częstotliwości używania ani rozmiaru
    B brak wpływu na format protokołu komunikacji, dozwolone ładowanie po bajcie większych struktur, lub kilku struktur w jednym pakiecie
    C eeprom jest w oddzielnej przestrzeni adresowej, można flashować urządzenie bez utraty konfiguracji i wymieniać eeprom bez tykania flasha
    D szybkie przeszukiwania pamięci, nie trzeba ani trzymać w pamięci kopii listy ani przeszukiwać pamięci FLASH w poszukiwaniu "najświeższej" kopii

    Przemyślę kwestię używania FLASH, być może argumenty finansowe okażą sie kluczowe ;)
  • #11
    BlueDraco
    MCUs specialist
    Z tych czterech tylko punkt D jest niekiedy prawdziwy.
    A. dotyczy Flash i EEPROM.
    B - odczyt z Flash dużo łatwiejszy niż z szeregowego EEPROMu, np. przez bezpośredni dostęp do danej/struktury.
    C. "Oddzielna przestrzeń adresowa" - to ewidentna wada rozwiązania. Jednolity dostęp do wszystkich danych jest znacznie wygodniejszy.
    D - przeszukiwanie Flash jest znacznie szybsze, niż odczyt EEPROM na I2C/SPI.
  • #12
    Szymon Tarnowski
    Level 27  
    BlueDraco wrote:
    Z tych czterech tylko punkt D jest niekiedy prawdziwy.
    A. dotyczy Flash i EEPROM.
    B - odczyt z Flash dużo łatwiejszy niż z szeregowego EEPROMu, np. przez bezpośredni dostęp do danej/struktury.
    C. "Oddzielna przestrzeń adresowa" - to ewidentna wada rozwiązania. Jednolity dostęp do wszystkich danych jest znacznie wygodniejszy.
    D - przeszukiwanie Flash jest znacznie szybsze, niż odczyt EEPROM na I2C/SPI.

    Ad A, w przypadku EEPROM struktury o stałym rozmiarze poprostu są pod określonym adresem, w przypadku symulowanego EEPROM w pamięci FLASH są pod bliżej nieokreślonym adresem.
    Ad B, a kto tu mówi o szeregowym EEPROM? I dlaczego wogóle analizujemy czas samego trwania operacji? Ja tu mowię o sytuacji kiedy jeśli zmienna ma 4 bajty, to w przypadku eeprom czy zapisze ją w jednym zapisie czy w 4 bajtach, to nie wpływa na format zapisu. W przypadku symulowanej pamięci to będą 4 "kawałki" zawierające kolejne "korekty". Z tego wynika że w przypadku zapisu w symulowanym EEPROMie, dobrze jakby protokół uwzględniał rozmiar danych w celu optymalizacji.
    Ad C, absulutnie się tu nie zgodzę, nie mówie tu o dostępie z poziomu programu, ale programatora który jest obsługiwany przez serwisanta
    Ad D, znowu kolega sie uparł zewnętrznej pamięci, zgadzam się, wewnętrzna będzie szybsza.
  • #13
    Freddie Chopin
    MCUs specialist
    Szymon Tarnowski wrote:
    Ad C, absulutnie się tu nie zgodzę, nie mówie tu o dostępie z poziomu programu, ale programatora który jest obsługiwany przez serwisanta

    No ale w czym problem? Kto każe kasować CAŁĄ pamięć? Również używam symulowanego eepromu i nie widzę problemu w aktualizacji firmware bez ruszania konfiguracji.

    4\/3!!
  • #14
    nsvinc
    Level 35  
    Freddie Chopin wrote:
    No ale w czym problem? Kto każe kasować CAŁĄ pamięć? Również używam symulowanego eepromu i nie widzę problemu w aktualizacji firmware bez ruszania konfiguracji.

    Ja widzę. Przy dużych rozmiarach sektora (jednostki kasowania), np. 4kB, zapisywanie często zmiennych wartości do flasha jest nadużyciem. I nie gadajcie rzeczy typu "konfiguracja sie nie zmienia tak często" ani "mozna trzymać dane w tym samym sektorze co kod" - podam prosty przykład:
    Code: C
    Log in, to see the code


    sizeof(Conf)=4. Dla 4kB sektora daje to 1024 'sloty' na taką strukturę.
    Odczyt:
    Code: C
    Log in, to see the code


    Z zapisem gorzej:
    Code: C
    Log in, to see the code

    Cudownie. Tyle roboty (a pominąłem szopki z obsługą flasha, przygotowywania go do zapisu, weryfikacji zapisu, itp itd; ew. API calls) po to zeby zaoszczędzić 1.50zł i kawałek PCB o powierzchni SOT23.
    Dodatkowo, jak widać, zuzywamy nadmiarowe 16 bitów (chociaz 10 bitów by wystarczyło) potrzebne do tagowania wersji - drugie tyle, co danych uzytkowych. Zapisując to do EEPROMa nie potrzeba tagować wersji; konfiguracja zapisuje się zawsze pod ten sam adres i zawsze jest aktualna.
    Tak samo FLASH jak SPI EEPROM z definicji nie będą thread safe i trzeba ręcznie obudować mutexami funkcje dostępowe.
    Jak widać, jakikolwiek kod wykonywalny nie moze byc w tym samym sektorze co przestrzen symulowanego EEPROMu.
    FLASH ma zatem następujące przewagi nad SPI EEPROMem:
    - natychmiastowy dostęp do konfiguracji jeśli wczesniej została ona zlokalizowana i zostało zagwarantowane, ze nie zapisała się w międzyczasie nowsza wersja (kopia konfiga w RAMie z EEPROMu umozliwia to samo...)
    - kronika
    Wady:
    - często skomplikowane procedury przygotowywania FLASHa do zapisu
    - pętle przeszukujące pamięć
    - bardzo dlugo trwające kasowanie sektora
    - utrata kroniki po skasowaniu sektora (ew. mozna ręcznie powielić jej kawałek, przerzucając dane przez RAM)
    - dane nadmiarowe (teoretycznie mozna zrezygnowac z licznika gwarantując liniowy zapis przyrostowy i mechanizm rozpoznawania obecności prawidlowej struktury pod danym adresem - albo licznik, albo suma kontrolna, albo jedno i drugie... )

    Ja jednak wolę EEPROM...
  • #15
    BlueDraco
    MCUs specialist
    Oczywiście, że danych nie trzyma się w jednym sektorze z kodem. Problemem może być wyłącznie rozmiar jednostki pisania (np. w starszych LPC1xxx - 256 bajtów), a nie kasowania. Na dane trzeba zarezerwować min. dwa sektory "kasowalne".

    Jednorazowe napisanie 20 linijek kodu kosztuje kilka złotych, ale powielenie tego kodu w tysiącu urządzeń nie kosztuje nic. Do obsługi I2C trzeba napisać więcej kodu, niż do obsługi "rekordów aktuałizacji" w data Flash, więc na kodzie oszczędności nie ma żadnej, a w sprzęcie jest spora - koszt układu, powierzchni płytki, montażu - to są koszty każdego egzemplarza sprzętu.

    Przeszukiwanie pamięci odbywa się jeden raz, przy starcie urządzenia, więc czas tej operacji jest bez znaczenia. Kolejny sektor kasuje się przy rozpoczęciu zapełniania następnego sektora, więc też nie ma potrzeby oczekiwania na zakończenie tej operacji.

    Praktycznie EEPROM broni się tylko wtedy, gdy potrzeba zapisać sporo danych milion razy.

    Przechowywania konfiguracji i liczników czasu/cykli pracy używam w kilku urządzeniach, i w żadnym z nich nie było sensu używania EEPROM. Jedno z nich np. zlicza czas pracy w sekundach, zapisując czas przy zaniku zasilania. Inne ma ok. 300 bajtów danych konfiguracyjnych, które zmieniane są po jednym bajcie - używam 32-bitowych rekordów aktualizacji i czterech sektorów Flash po 1 KiB.
  • #16
    nsvinc
    Level 35  
    Quote:
    Na dane trzeba zarezerwować min. dwa sektory "kasowalne".

    Nie rozumiem czemu "trzeba" - z jednym sektorem też można sobie poradzić...

    Sektor 1kB to luksus. LPC11xx(L) mają 4kB sektory. Mają również nie za dużo flasha, co w przypadku rozbudowanych kodów, uciążliwe jest marnowanie 4kB na zapis kilkudziesięciu bajtów konfiga. Właśnie tu, gdzie kupuje się procka pod kątem energooszczędności i ceny, często flasha brakuje. Wygrywa EEPROM.

    Nieco lepiej jest w przypadku LPC11xxXL - mają małe sektory kasowalne (256B) i wtedy emulacja EEPROMu zaczyna mieć sens. Jeszcze lepiej wypadają LPC81x. Niestety tych pierwszych nie da się kupić, a te drugie nie mają potrzebnych peryferiów. Jak zawsze, jest trade-off.

    Swoją drogą, STM32F1 nie lubi zapisywać do FLASHa w zakłóconym środowisku - ta lekcja mnie sporo kosztowała. Antena GSM oddalona od procesora na 7cm skutecznie uniemozliwia poprawny zapis, i trzeba mocno kombinować żeby ten zapis udało się przeprowadzić bez przekłamań. A EEPROM w SOT23 zadnych problemow z integralnością danych nie miał, a był jeszcze bliżej anteny.
  • #17
    BlueDraco
    MCUs specialist
    Masz rację, napisałem "trzeba", bo miałm na myśli urządzenie, które nie traci przypadkowo konfiguracji. Jeśli dopuszczasz utratę konfiguracji - wystarczy jeden sektor. z drugiej strony - jeśli dopuszczasz utratę konfiguracji, to po co Ci ten Flash/EEPROM?

    LPC111x pierwszej generacji byąy wyjątkowo paskudne pod tym względem, ale proble nie leży w samym rozmiarze sektora 4 KiB, a w tym, że pisać mona było minimum 256 B, co oznacza, że jedno kasowania sektora następuje na 16 zapisów, nawet, jeśli masz potrzebę pisania tylko jednego bajtu.

    Sam rozmiar sektora kasowalnego nie jest żadnym problemem, ważne jest to, ile razy można coś zapisać bez kasowania, bo to kasowanie powoduje zużycie pamięci. W przypadku mojego urządzenia z "bajtową" modyfikacją danych konfiguracyjnych - na 1 KiB stronie mieszczę 256 rekordów modyfikacji, po 4 bajty każdy, czyli jeden sektor wystarcza na 256 modyfikacji danych. LPC się do tego nie nadaje, bo rekord modyfikacji musiałby zajmować min. 256 B i jeden sektor 4 KiB mieściłby tylko 16 modyfikacji.
  • #18
    nsvinc
    Level 35  
    Blue Draco wrote:
    Jeśli dopuszczasz utratę konfiguracji - wystarczy jeden sektor.

    Niekoniecznie; jeśli ta konfiguracja jest modyfikowana tylko na żądanie, jednoczesnie gwarantując obecność zasilania, to nie ma sensu uzywania wielu sektorów.

    Blue Draco wrote:
    LPC111x pierwszej generacji byąy wyjątkowo paskudne pod tym względem, ale proble nie leży w samym rozmiarze sektora 4 KiB, a w tym, że pisać mona było minimum 256 B, co oznacza, że jedno kasowania sektora następuje na 16 zapisów, nawet, jeśli masz potrzebę pisania tylko jednego bajtu.

    No i ja nawet nie zauważyłem problemu; w moich układach zawsze leżał ten nieszczęsny EEPROM ;] własny bootloader nie był potrzebny więc o zapisie do flasha wiedziałem tylko to z manuala czytanego z nudów po paru głębszych ;]

    Jednak mimo mojego narzekania na emulację EEPROMa we FLASHu, sam stosuję takie rozwiązanie; tyle że ten FLASH jest zewnętrzny ;) ;) skoro i tak potrzebowałem pamięci masowej, a dane konfiguracyjne są zmieniane raz na ruski rok (o ile w ogóle), to z przyczyn oczywistych EEPROM został grzecznie oddelegowany z projektu.
    Jedyne wahania były między zwykłym FLASHem a DataFLASHem; ceny w sumie podobne a pozornie dataFLASH jest milszy w użyciu (wewn bufory, mały sektor kasowalny, itp.) ale jednak zdecydowałem się na zwykły FLASH. Z jednego prostego powodu - małe 264B "strony" (jak to nazwali w datasheet'cie do dataFLASH) moze i mogą być kasowane pojedynczo, jednak co ileś kasowań stron w danym sektorze (kilkadziesiąt stron), każda strona w tym sektorze musi być przepisana. Po rozmyślaniach nad implementacją drivera do dataFLASHa, doszedłem do wniosku, że trzymanie i obsługa liczników kasowań dla kazdego sektora będzie na tyle upierdliwa, że wole zwykły łopatologiczny FLASH, z sektorem 4kB, a jakże ;]