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

Emulacja EEproma we flashu

22 Gru 2017 23:37 2484 86
  • Poziom 27  
    Witam,

    zaczynam poznawanie ARMów.
    Nie ukrywam, że brak eeproma jest dla mnie bardzo bolesny.
    Nie potrafię przyjąć argumentu, że przecież można małą i tanią pamięć dostawić sobie na płytce, bo po to idziemy do przodu w technologii, aby ułatwiać sobie a nie utrudniać życie.
    Ale OK.
    Postanowiłem zając się zapisem danych nieulotnych do Flasha.
    Udało mi się to i teraz moge zapisać i odczytać dowolna daną pod dowolny adres.

    Moje pytanie brzmi .
    Jaki zakres adresów jest bezpieczny do zapisu tych danych?
    Bo rozumiem, że jesli zapisywane dane trafią na program, to nastąpi totalny crash?
  • BotlandBotland
  • Poziom 27  
    kaseciak22 napisał:
    A co byś powiedział na emulację EEPROMa poprzez Bluetooth?
    https://www.youtube.com/watch?v=oKFKy_JLnL8


    Może kazdy z nas pisze różne programy.
    Ale ja praktycznie każdy program mam z nastawami.
    Nastawy te miałem dotychczas w eepromie.
    Wiem że mozna je zapisywać przy pomocy boototha, wifi, czymkolwiek i obojetnie gdzie.
    Ale ja potrzebuje je zapisać w procesorze.
    Niby jest wersja ARMów z eepromem, ale nawet w TME nie można ich kupić.
  • Poziom 37  
    wiesz o zwykle obecnych niewielkich ilościach rejestrów nieulotnych?
    Trzeba je podtrzymać bateryjką, nie są czyszczone przez reset.

    W popularnym na tanich płytkach uP F103 to jest 10 rejestrów dwubajtowych
    Na mocniejszych jest więcej.
  • Użytkownik usunął konto  
  • BotlandBotland
  • Specjalista - Mikrokontrolery
    Jedyne - podkreślę jedyne - pewne rozwiązanie, to odpowiednia modyfikacja skryptu linkera, tak aby dla emulowanego EEPROMu wydzielić strony na których nie będzie niczego innego. Wszystkie inne opcje to typowa "rosyjska ruletka".
  • Poziom 37  
    R-MIK napisał:

    Fredy napisał:

    Bo rozumiem, że jesli zapisywane dane trafią na program, to nastąpi totalny crash?

    Niekoniecznie totalny. Parę dni temu miałem błąd i trafiłem z danymi w obszar programu. Był to jednak obszar, gdzie znajdowały sie stałe (komunikaty tekstowe). Program sie nie zawieszał ale wyświetlał "krzaki".


    Pozostanę przy interpretacji "totalny".
    Tylko przypadkowa zbieżność obszaru, użytych technik programowania (hipotetycznie: sizeof() a nie strlen()) dała/sprawiała wrażenie ograniczonego błędu. Można gdybać, że nie-wizualne dane miały wartość odjazdową, tylko nie miały okazji się ujawnić.
  • Poziom 27  
    Czyli jak widać brak eepromu doskwiera nie tylko mi.
    Trzeba zatem sobie wyraźnie powiedzieć, że to jest OGROMNA wada Armów.
    Bo na każdym kroku słychać tylko ochy i achy dotyczące Armów.
    Wolałbym 100 bajtów eepromu w każdym procesorze, aniżeli 200 liczników czy 100 Uartów i 1GB flasha.
    Pod tym względem cudowne były i są Xmegi , szkoda tylko, że sie nie wstrzeliły w rynek i są takie drogie.
  • Poziom 37  
    Fredy napisał:
    Czyli jak widać brak eepromu doskwiera nie tylko mi.
    Trzeba zatem sobie wyraźnie powiedzieć, że to jest OGROMNA wada Armów.


    Zgodził bym się. Zwłaszcza dla tych z nas bardziej programujących na gotowych płytkach, niż lutujących.
  • Poziom 22  
    Fredy napisał:
    Czyli jak widać brak eepromu doskwiera nie tylko mi.
    Trzeba zatem sobie wyraźnie powiedzieć, że to jest OGROMNA wada Armów.

    Zależy jak chcesz na to patrzeć. Z drugiej strony, zewnętrzny EEPROM jest dostępny w razie czego na zewnątrz - można się do niego podpiąć i poprawić zawartość o ile trzeba. Jego wielkość dobierasz akurat tak jak Ci pasuje, jak potrzebujesz dużego, to po prostu wstawisz duży. STM32 w sporej części mają kawałek pamięci podtrzymywany bateryjnie, którego można użyć do przechowywania części danych. A samo podtrzymanie bateryjne może być zaletą, w momencie jak trzeba przywrócić stan fabryczny. Także, to jak zwykle zależy. ;)
  • Użytkownik usunął konto  
  • Poziom 27  
    Sareph napisał:
    Fredy napisał:
    Czyli jak widać brak eepromu doskwiera nie tylko mi.
    Trzeba zatem sobie wyraźnie powiedzieć, że to jest OGROMNA wada Armów.

    Zależy jak chcesz na to patrzeć. Z drugiej strony, zewnętrzny EEPROM jest dostępny w razie czego na zewnątrz - można się do niego podpiąć i poprawić zawartość o ile trzeba. Jego wielkość dobierasz akurat tak jak Ci pasuje, jak potrzebujesz dużego, to po prostu wstawisz duży. STM32 w sporej części mają kawałek pamięci podtrzymywany bateryjnie, którego można użyć do przechowywania części danych. A samo podtrzymanie bateryjne może być zaletą, w momencie jak trzeba przywrócić stan fabryczny. Także, to jak zwykle zależy. ;)


    Sorki, ale nie po to dążę do miniaturyzacji, aby stosować super procesor ARM a do tego baterię, lub zewnętrzny eeprom.
  • Użytkownik usunął konto  
  • Moderator Mikrokontrolery Projektowanie
    Freddie Chopin napisał:
    Jedyne - podkreślę jedyne - pewne rozwiązanie, to odpowiednia modyfikacja skryptu linkera, tak aby dla emulowanego EEPROMu wydzielić strony na których nie będzie niczego innego. Wszystkie inne opcje to typowa "rosyjska ruletka".


    Ja akurat nie lubię modyfikować skryptów linkera, bo zwykle nie są one potem dystrybuowane z projektem, albo się je zapomina dołączyć/zarchiwizować i w połączeniu z niedoskonałą pamięcią programisty dotyczącą samego faktu modyfikacji prowadzi to do nieciekawych problemów. Pamięć na emulację EEPROM można zarezerwować tworząc tablicę, dzięki align można ją wyrównać do strony. Zaletą tego rozwiązania jest to, że całość jest w czystym C/C++. Ma to tez pewne wady. Warto też pamiętać, że niektóre ARMy mają wydzielony obszar FLASH, który służy do emulacji EEPROM. Obszar ten cechuje się często zmienionymi parametrami elektrycznymi lub możliwością stosowania mniejszych stron/adresowania komórek, co ułatwia emulację lub zwiększa liczbę dostępnych zapisów. Wtedy istotnie jedynym pewnym sposobem, żeby emulacja trafiła we właściwe miejsce, jest skrypt linkera. Tyle, że wtedy zwykle firmowy skrypt już ma odpowiednie możliwości.
    IMHO sama dyskusja na temat tego, czy brak EEPROM jest dużą wadą jest drugorzędna. W swoich programach i tak stosuję warstwę pośredniczącą w dostępie do EEPROM i to czy występuje on fizycznie w MCU, czy jest emulowany jest dla mnie bez znaczenia. Tym bardziej, że w ten sposób zapewniam też wear leveling i kontrolę integralności danych. W prostych aplikacjach istotnie wygodniej jest mieć po prostu EEPROM (zresztą są chyba ARMy, które EEPROM mają).
  • Użytkownik usunął konto  
  • Moderator Mikrokontrolery Projektowanie
    Piotrus_999 napisał:
    tmf napisał:
    Ja akurat nie lubię modyfikować skryptów linkera


    Innej poprawnej opcji nie ma. To jest zreszta dość typowa opinia osób, które piszą na AVR-y bo tam skrypty linkera są "ukryte" gdzieś w podkatalogach toolchaina i większość piszących nawet nie wie że one istnieją.

    Ciekawe jak bez skryptów kol. @tmf chciałby np. wykorzystać CCMRAM (dodajmy że jesteśmy w dziale ARM)


    Proponowałbym jednak czytać ze zrozumieniem :) Piszemy o emulacji EEPROM, więc nie wiem po co kolega wyjeżdża z wątkami niezwiązanymi z tematem?
    To gdzie się znajdują skrypty linkera zależy od środowiska, jeśli używam IDE danego producenta, to oczekuję wymagania minimalnej interwencji z mojej strony. I wolę sytuację, w której producent daje mi odpowiedni skrypt, czy różne jego inkarnacje pod różne zastosowania (jak np. kopiowanie kodu do RAM) niż żebym miał sam to robić. Modyfikacja skryptów linkera powinna mieć miejsce wtedy, gdy jest to konieczne.
  • Użytkownik usunął konto  
  • Moderator Mikrokontrolery Projektowanie
    Piotrus_999 napisał:
    Zgadzam się w 100% z kol @Freddie Chopin że jest to jedyne poprawne rozwiązanie rozwiązanie.


    To napisz dlaczego uważasz, że zadeklarowanie miejsca na emulowany EEPROM w C jest błędne? W sytuacji, gdy nie mamy jakiegoś wyszególnionego obszaru FLASH, który na emulację lepiej się nadaje?

    Piotrus_999 napisał:
    makefile też nie należy używać - bo tez można zapomnieć dołączyć do projektu.

    Znowu argument dziwny. Używasz IDE i dystrybuujesz makefile? Bo raczej sensowniej byłoby plik projektu z IDE.
  • Użytkownik usunął konto  
  • Użytkownik usunął konto  
  • Użytkownik usunął konto  
  • Użytkownik usunął konto  
  • Moderator Mikrokontrolery Projektowanie
    Piotrus_999 napisał:
    tmf napisał:
    Znowu argument dziwny. Używasz IDE i dystrybuujesz makefile? Bo raczej sensowniej byłoby plik projektu z IDE.

    Nie rozumiem. Jezeli publikuję projekt ze źródłami nawet jak w trakcie pisania używałem IDE to tworzę tez plik makefile, który umozliwia zbudowanie projektu nawet jak ktoś nie ma/nie używa danego IDE. Co nie oznacza oczywiście że nie dołącze plików projektu tego IDE jak by ktoś miał i chciał użyć do zmian.

    Nie rozumiem Twoich wątpliwości .


    Bo się nie starasz i czytasz fragmenty, zamiast całość. Są też inne możliwości, ale nie będę o nich wspominał.
    Pisałeś:
    Piotrus_999 napisał:
    makefile też nie należy używać - bo tez można zapomnieć dołączyć do projektu.

    Jak rozumiem używać znaczy modyfikować w celu dostosowania do własnych potrzeb. Argument chybiony, bo tym sie zajmuje IDE. Sam makefile, jak wiesz, i tak jest używany do budowania projektu, ale jest tworzony automatycznie i użytkownik bezpośrednio w nim nie miesza, stąd też argument chybiony.
    BTW, chętnie poznałbym wyjaśnienia dlaczego do emulacji EEPROM jednym sposobem jest modyfikacja skryptu linkera.
  • Konstruktor DIY elektronika
    tmf napisał:
    To napisz dlaczego uważasz, że zadeklarowanie miejsca na emulowany EEPROM w C jest błędne?

    Bo po aktualizacji softu adres się może zmienić?
    Ja wolę dać ustawienia na końcu flasha i ograniczyć w linkerze jego ilość tak żeby program tam na 100% nie trafił.

    Jeżeli chodzi o to dlaczego zwykle nie ma eepromu w ARMach to wydaje mi się że dla tego, bo producentom urządzeń na tym nie zależy. Mają gdzieś trwałość, byle niska cena i wytrzymało okres gwarancji.
    Ostatnio grzebałem przy urządzeniu pewnego znanego producenta, jednego z najdroższych w swojej kategorii. Urządzenie przestało działać. Okazało się że ustawienia były trzymane w pamięci jednokrotnego zapisu i pamięć się skończyła.
  • Specjalista - Mikrokontrolery
    Fredy napisał:
    Czyli jak widać brak eepromu doskwiera nie tylko mi.
    Trzeba zatem sobie wyraźnie powiedzieć, że to jest OGROMNA wada Armów.
    Bo na każdym kroku słychać tylko ochy i achy dotyczące Armów.
    Wolałbym 100 bajtów eepromu w każdym procesorze, aniżeli 200 liczników czy 100 Uartów i 1GB flasha.
    Pod tym względem cudowne były i są Xmegi , szkoda tylko, że sie nie wstrzeliły w rynek i są takie drogie.

    Na razie w sumie tylko Ty marudzisz, choć nie wiem czemu... Po pierwsze można emulować EEPROM we flash, zrobiłem tak w bardzo wielu projektach, zawsze działało to bardzo dobrze. Po drugie są ARMy z EEPROMem, a argument że nie ma ich w TME jest tak słaby że nawet nie będę go komentował. Dostawa z farnella kosztuje z grubsza tyle samo co z TME, czasowo wychodzi identycznie (jeden dzień), wybór mikrokontrolerów jest nieskończenie większy.

    tmf napisał:
    Pamięć na emulację EEPROM można zarezerwować tworząc tablicę, dzięki align można ją wyrównać do strony. Zaletą tego rozwiązania jest to, że całość jest w czystym C/C++.

    Nie wiem w jaki sposób takie wyrównanie będzie w "czystym C/C++" (; Co najwyżej w czystym C11/C++11, a takie terminy jak wiadomo wywołują u większości osób reakcję alergiczną, gdyż wszystko nowsze niż 18 lat jest definitywnie błędne. No i jeszcze trzeba mieć kompilator w wersji która wspiera te standardy.

    tmf napisał:
    Ma to tez pewne wady.

    Rozwiązanie kompletnie się nie sprawdzi w przypadku mikrokontrolerów o różnych rozmiarach strony, ot choćby STM32F4, gdzie mamy 4 x 16 kB, 1 x 64 kB, a potem już chyba wszystkie kolejne po 128 kB - w takim przypadku ewidentnie najlepszą lokalizacją dla emulacji EEPROMu są jedne z pierwszych (małych) stron - żadnymi magicznymi słowami kluczowymi nie umieścisz tam tablicy. Przy okazji rozwiązanie jest dziurawe również w tym, że taka tablica jest wtedy częścią programu, przez co przy każdym wgrywaniu kodu jest ona kasowana, a do tego przy każdej kompilacji może się znaleźć pod innym adresem. Obydwie te cechy są wysoce niepożądane w każdej aplikacji w której używałem emulacji EEPROMu. W każdej.

    tmf napisał:
    Ja akurat nie lubię modyfikować skryptów linkera, bo zwykle nie są one potem dystrybuowane z projektem, albo się je zapomina dołączyć/zarchiwizować i w połączeniu z niedoskonałą pamięcią programisty dotyczącą samego faktu modyfikacji prowadzi to do nieciekawych problemów.

    Słaby argument. Jak ktoś nie potrafi wraz z projektem dodać do repozytorium tak kluczowego pliku jak skrypt linkera, to nie wiem po co rozpatrywać taką amatorkę... Sorry... Że ktoś czegoś nie lubi - no cóż, ja na przykład bardziej lubię wydawać kasę niż ją zarabiać, ale nie sądzę aby to był mocny argument o tym jakie rozwiązanie jest lepsze w tym przypadku, bo kwestia Twoich czy moich preferencji jest tutaj kompletnie nieistotna.
  • Moderator Mikrokontrolery Projektowanie
    piotr_go napisał:
    tmf napisał:
    To napisz dlaczego uważasz, że zadeklarowanie miejsca na emulowany EEPROM w C jest błędne?


    Bo po aktualizacji softu adres się może zmienić?


    Dlatego pisałem, że ma pewne wady, których zresztą jest więcej. Ale pytanie moje było związane ze stwierdzeniem:
    Piotrus_999 napisał:
    Zgadzam się w 100% z kol @Freddie Chopin że jest to jedyne poprawne rozwiązanie rozwiązanie.

    Swoją drogą wada o której piszesz ma znaczenie tylko w sytuacji, w której pomiędzy aktualizacjami softu muszą być zachowane ustawienia. Jeśli softu nie planujemy aktualizować, to niekoniecznie to przeszkadza.
  • Specjalista - Mikrokontrolery
    tmf napisał:
    Swoją drogą wada o której piszesz ma znaczenie tylko w sytuacji, w której pomiędzy aktualizacjami softu muszą być zachowane ustawienia. Jeśli softu nie planujemy aktualizować, to niekoniecznie to przeszkadza.

    Szczególnie wygodne jest to, jeśli w tym emulowanym EEPROMie są jakieś kluczowe dla działania urządzenia parametry (np. parametry pracy silników krokowych, adres MAC i IP) i taki program debuggujemy. Definitywnie bardziej lubię modyfikować skrypty linkera niż 100x dziennie wpisywać dokładnie te same wartości do urządzenia nad którym pracuję, bo przecież każde wgranie i już parametry przepadły. Nie wiem po co bronić tak słabego pomysłu, zwłaszcza że ta mityczna modyfikacja skryptu linkera jest bardzo prosta i naprawdę nie trzeba być doktorem habilitowanym aby ją ogarnąć.

    Dodano po 1 [minuty]:

    tmf napisał:
    Jeśli softu nie planujemy aktualizować, to niekoniecznie to przeszkadza.

    Dobry plan to podstawa (; Ciekawe jaki to soft nie wymaga aktualizacji (;
  • Konstruktor DIY elektronika
    Jeszcze odnośnie nie udostępniania makefile czy skryptu linkera bo "generowany automatycznie" w IDE.
    Spotkałem się z takim dziadostwem. IDE nie miałem bo płatne albo pod inny system, w makefile powinny być jakieś dodatkowe parametry, projekt się nie kompiluje i szukaj czego brakuje.
  • Moderator Mikrokontrolery Projektowanie
    Freddie Chopin napisał:
    tmf napisał:
    Jeśli softu nie planujemy aktualizować, to niekoniecznie to przeszkadza.


    Dobry plan to podstawa (; Ciekawe jaki to soft nie wymaga aktualizacji (;


    Większość? Aktualizowałeś kiedyś soft w lodówce, pralce, kuchence mikrofalowej i większości sprzętu, który ma MCU? Ile widziałeś projektów amatorskich, które przewidują aktualizację?

    Dodano po 1 [minuty]:

    piotr_go napisał:
    Jeszcze odnośnie nie udostępniania makefile czy skryptu linkera bo "generowany automatycznie" w IDE.
    Spotkałem się z takim dziadostwem. IDE nie miałem bo płatne albo pod inny system, w makefile powinny być jakieś dodatkowe parametry, projekt się nie kompiluje i szukaj czego brakuje.


    Ale ktoś pisał o nieudostęnianiu makefile? Jest to plik generowany automatycznie i m.in. po to używam IDE, aby do niego nie zaglądać, a nawet zapomnieć, że istnieje.

    Dodano po 4 [minuty]:

    Freddie Chopin napisał:
    Szczególnie wygodne jest to, jeśli w tym emulowanym EEPROMie są jakieś kluczowe dla działania urządzenia parametry (np. parametry pracy silników krokowych, adres MAC i IP) i taki program debuggujemy.


    Dla każdego rozwiązania znajdziesz wady i zalety, o tym zresztą od początku pisałem. Tak samo jako kontrprzykład mogę podać inną sytuację - dostałem program, który bazuje na autorskim skrypcie linkera, którego nie mam, a nawet nie mam świadomości, że autor poczynił w nim dalekoidące zmiany. I co? Jestem w jakoś lepszej sytuacji? Domyślny IP i MAC mogę sobie wpisać jako domyślną wartość w emulowanym EPROMIE.
    Mam wrażenie, że siedzisz jeszcze w czasach vi i dłubania ręcznego w toolchainie. Ja uważam, że pisząc w C mam używać C, a nie specyficznych zaklęć. Chyba, że jest to rzeczywiście niezbędne.
  • Konstruktor DIY elektronika
    tmf napisał:
    Ale ktoś pisał o nieudostęnianiu makefile?


    tmf napisał:
    #18 23 Gru 2017 13:14
    Używasz IDE i dystrybuujesz makefile?