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.

Przechowywanie i zarządzanie parametrami sterownika mikroprocesorowego

JarekC 04 Nov 2019 21:37 303 3
  • #1
    JarekC
    Level 31  
    Witam,

    Chciałbym podyskutować i wymienić doświadczenia na temat sposobu zarządzania i przechowywania parametrów sterownika mikroprocesorowego programowanych przez użytkownika.

    Ogólne założenia:
    - parametry przechowywane w EEPROM
    - program sterownika w "C"
    - parametry różnych typów bool, uint8, int8, uint16 ...
    - zmienne inicjowane przez odczytane parametry zdefiniowane w różnych plikach
    - ilość parametrów od kilku do kilkudzisięciu
    - wymagana kopia zapasowa
    - wymagana suma kontrolna.

    Na razie nie udało mi się wypracować jakiegoś standardu, w każdym sterowniku mam to zrobione trochę inaczej.

    Przykład jednej z moich realizacji, wersja uproszczona bo parametry są tylko typu int8 i uint8.

    1. Mam zdefiniowane strukturę opisującą parametr
    Code: c
    Log in, to see the code


    2. Mam zdefiniowaną tablicę konfiguracyjną parametrów sterownika (dla przykładu tylko dwa parametry)
    Code: c
    Log in, to see the code


    3. Mam zdefiniowane położenie parametrów w pamięci EEPROM
    Code: c
    Log in, to see the code


    Powyższe definicje powodują że zmienne mogą być porozrzucane w różnych miejscach, a dane w EEPROM stanowią ciągły blok.

    4. Po załączeniu sterownika odczytuję blok danych i kopię z pamięci EEPROM do bufora RAM oraz sprawdzam poprawność sum kontrolnych.
    Następnie sprawdzam poprawność zakresu wszystkich parametrów zarówno dla oryginału i kopii, dodatkowo liczę ilość wykrytych błędów w obydwu blokach, w przypadku przekroczenia zakresu wpisywana jest wartość domyślna.
    Po takiej analizie podejmuję decyzję z którego bloku skorzystać wg algorytmu:
    - jeżeli suma kontrolna oryginału jest poprawna i nie ma błędu zakresów to wybieram oryginał
    - w przeciwnym wypadku jeżeli suma kontrolna kopii jest poprawna i nie ma błędów zakresu to wybieram kopię
    - w przeciwnym wypadku wybieram blok z mniejszą ilością błędów
    Kopiuję parametry do zmiennych.
    W przypadku gdy wystąpiły błędy wyświetlam odpowiedni komunikat, parametry w EEPROM są korygowane dopiero po interwencji użytkownika (wejście do menu konfiguracyjnego i zatwierdzenie ustawień).

    Nie bardzo mam pomysł jak powyższe rozwiązanie rozszerzyć na przypadek z parametrów różnych rozmiarów (int8, int16 ...)

    A jakie wy macie doświadczenia w tej kwestii, jakieś ciekawe rozwiązania?

    Pozdrawiam
    JarekC
  • #2
    tmf
    Moderator of Microcontroller designs
    Pierwsze pytanie - czy planujesz możliwość uaktualniania firmware? Jeśli tak, to problemem jest powiązanie adresów w EEPROM z adresami w ładowanej aplikacji. Oczywiście zakładając, że uaktualnianie firmware nie powinno kasować ustawień zawartych w EEPROM. Ja to rozwiązałem tak, że do wartości w EEPROM dobieram się przez tokeny - krótkie identyfikatory (mogą być łańcuchem tekstowym, co polepsza czytelność kodu). Dzięki temu wiązanie zmiennej z wartością w EEPROM odbywa się dynamicznie i żadne adresy nie są na sztywno zaszyte w kodzie aplikacji. Daje to też dodatkową możliwość dodawania nowych danych. Z każdym polem powiązane jest pole danych. Na początku rekordu jest zapisana jego długość obejmująca długość tokena + pola danych. Ponieważ długość tokena jest znana (format ASCIZ), więc można na tej podstawie wyliczyć długość pola danych - czyli wielkość typu. Funkcja zwraca mi adres w EEPROM odnalezionego rekordu + jego długość. Przy zapisie podaję nazwę klucza, zapisywany blok danych i jego długość. Sprawdza się to bardzo dobrze.
  • #3
    BlueDraco
    MCUs specialist
    Z praktyki:
    - wygodniej trzymać dane w strukturze, niż w pojedynczych zmiennych; przy składowaniu danych w pamięci Flash wygodnie jest mieć unię zawierającą strukturę i wektor bajtów lub słów
    - w pamięci ROM mamy na stałe zapisaną domyślną wartość struktury konfiguracyjnej
    - jeśli mamy EEPROM, to w EEPROM trzymamy kopię struktury z RAM, a po modyfikacji aktualizujemy zmienione pola i ew. sumę kontrolną
    - jeśli mamy Flash, to zapisujemy do Flash rekordy modyfikacji, zawierające indeks wektora i nową wartość
    - przy starcie zaczynamy od skopiowania struktury z ROM do RAM, a potem wprowadzamy w niej zmiany na podstawie zawartości Flash lub EEPROM
  • #4
    JarekC
    Level 31  
    tmf wrote:
    Pierwsze pytanie - czy planujesz możliwość uaktualniania firmware? Jeśli tak, to problemem jest powiązanie adresów w EEPROM z adresami w ładowanej aplikacji. Oczywiście zakładając, że uaktualnianie firmware nie powinno kasować ustawień zawartych w EEPROM.


    Tak założenie jest że oprogramowanie może być aktualizowane ale to nie jest problemem gdy tylko zarezerwujemy odpowiednią ilość pamięci EEPROM i zachowamy stałe położenie.
    W poniższym przykładzie mamy dwa parametry ale swobodnie możemy dokładać następne, jedyna niedogodność to że po wgraniu nowego firmware obsługującego dodatkowe parametry przy pierwszym uruchomieniu zostanie zgłoszony bład sumy kontrolnej.

    Code: c
    Log in, to see the code


    Ewentualnie można by przesunąć sumę kontrolną na koniec rezerwowanego bloku i wtedy nie będzie tego problemu.

    BlueDraco wrote:
    Z praktyki:
    - wygodniej trzymać dane w strukturze, niż w pojedynczych zmiennych; przy składowaniu danych w pamięci Flash wygodnie jest mieć unię zawierającą strukturę i wektor bajtów lub słów


    Tylko jak to zorganizować gdy np korzystamy z bibliotek i inicjujemy niektóre zmienne (np IP, adres bramy itp).
    Przenosić zmienne do własnej struktury czy może wykorzystywać pośrednią zmienną konfiguracyjną.