ARM w małej obudowie z prawdziwym EEPROM

Question

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

cwieek · Answer

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

Smashing · Answer

To może lepiej dodać baterię i zależności od wersji STM'a masz do 4Kb pamięci.

BlueDraco · Answer

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.

Jado_one · Answer

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.

Szymon Tarnowski · Answer

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.

Badmaneq · Answer

Jeżeli wystarczające będzie 4 kB eeprom to kup LPC11U67JBD48, jego parametry masz tutaj http://www.nxp.com/products/microcontrollers/cortex_m0_m0/lpc1100/LPC11U67JBD48.html#overview

michalko12 · Answer

LPC1500 z Cortexem-M3 wyjątkowo udana seria uC.

BlueDraco · Answer

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.

Szymon Tarnowski · Answer

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

BlueDraco · Answer

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.

Szymon Tarnowski · Answer

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.

Freddie Chopin · Answer

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

nsvinc · Answer

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: CLog in, to see the codesizeof(Conf)=4. Dla 4kB sektora daje to 1024 'sloty' na taką strukturę. Odczyt:Code: CLog in, to see the codeZ zapisem gorzej:Code: CLog 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...

BlueDraco · Answer

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.

nsvinc · Answer

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.

BlueDraco · Answer

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.

nsvinc · Answer

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 ;]