Oprogramowanie sterownika BLF-VLD

[pralat]

Witam,

bawię się ostatnio softem BLF-VLD dostępnym tutaj. Wszystko działa fajnie, jednak trochę dziwie jest rozwiązana sprawa oszczędzania zużycia eepromu, czyli ilości zapisów.

Struktura eepromu jest taka:

Kod: Zaznacz cały

#define CLICK_CELLS 3       // spread wear of click detection over 3 cells
typedef struct
{
// ... pomijam 7 nieistotnym teraz pól ...
    uint8_t click_cell;     // index of currently used cell for click detection
    uint8_t last_click[CLICK_CELLS];  // type of last tap (short, long, none)
    uint8_t mode_arr[NUM_MODES]; // array holding offsets to the mode lines for
                                 // the configured modes
} State_t;

I teraz w "click_cell" zapisywany jest numer komórki, która używana jest do detekcji "kliku", są na to przeznaczone 3 komórki. Czyli w teorii fajnie, jednak w funkcji main() jest coś takiego:

Kod: Zaznacz cały

   // read the state data at the start of the eeprom into a struct
    eeprom_read_block(&state, 0, sizeof(State_t));

    last_click = get_last_click&#40;&#41;; // <--- tutaj zwiększany jest indeks wspomnianej komórki
...
 eeprom_write_block&#40;&state, 0, sizeof&#40;State_t&#41; - sizeof&#40;state.mode_arr&#41;&#41;;

Czyli wygląda na to, że przy każdym uruchomieniu (po krótkim czy długim kliku) wykonywany jest eeprom_write_block, który zapisuje zawsze 16 bajtów, a zastosowanie "click_cell" niewiele daje (pomaga tylko w zapisie dokonywanym w przerwaniu).

[ Dodano: 13 Marzec 2013, 12:42 ]
Od razu dodam też jakie widziałbym tutaj rozwiązanie. Po pierwsze, trzeba zoptymalizować format trybów - obecnie każdy tryb opisany jest 4 bajtami: typ oraz 3 parametry. Jednak 3 parametry rzeczywiście potrzebne są tylko dla typu "strobo", a tryby stałych potrzebują tylko 1 parametr. W sofcie określonych jest 9 trybów stałych, z tego wynika, że 2*8=18 bajtów jest zmarnowanych.
Na tych bajtach można zrealizować zapisy cykliczne tych danych, które są zmieniane często: czyli informacja o ostatnim kliku oraz licznik krótkich klików (potrzebny do wejścia w tryby ukryte). Na każdy taki rekord potrzebne byłyby 3 bajty:
- nr sekwencyjny zapisu
- typ kliku
- ilość klików
czyli przykładowo taki rekord:

Kod: Zaznacz cały

struct {
 uint8_t sequence;
 uint8_t clicks;
 uint8_t last_click;
}

... a działałoby to tak, że przy odczycie szukałbym sobie komórki z najnowszym wpisem, co rozpoznawałbym po nr sekwencyjnym. Kolejne zapisy robiłbym do kolejnych komórek, zwiększając za każdym razem nr sekwencyjny.
Czyli (może być oderwane od rzeczywistości) np.
offsety 0-5 zarezerwowane na jakieś inne rzeczy i zapis w kolejnych przebiegach rekordów dot. klikania pod:
offset 6: 0 x y
offset 9: 1 x y
offset 12: 2 x y
...
po dotarciu do granicy pól przeznaczonych na te wpisy, z powrotem trafiam pod offset 6, a po "przekręceniu" nr sekwencyjnego oczywiście zaczynam od 0, np.

offset 15: 254 x y
offset 18: 255 x y
offset 6: 0 x y
(x, y - dane związane z klikaniem, wartości w tym przykładzie nieistotne)

Tym samym rozłożę zapisy na 18 komórek eepromu, co daje 6 rekordów po 3 bajty. Oznacza to, że żywotność eepromu zwiększy się 6-krotnie.
Być może napisałem trochę niejasno, czasami trudno mi przekazać ideę

[Pyra]

Witam

... a działałoby to tak, że przy odczycie szukałbym sobie komórki z najnowszym wpisem, co rozpoznawałbym po nr sekwencyjnym.

W zasadzie to chyba żaden z pierwszych parametrów nie przyjmuje wartości "0" tak więc wystarczyło by wypełnić wszystkie niepotrzebne początkowe pola tą wartością i procek po starcie szukał by pierwszej niezerowej komórki.

Pozdrawiam

[pralat]

Tak również można zrobić, jednak wymagałoby to kasowania poprzednich wartości, tj. ustawiania przynajmniej jednego bajtu na zero w "starym" rekordzie. Zaoszczędziłbym 1 bajt, ale zwiększyłaby się ilość zapisów.

[Pyra]

Witam
W zasadzie, to zmienia się tylko wskaźnik klików, dane konfiguracyjne mogą sobie spokojnie leżeć...

Pozdrawiam

[pralat]

Oczywiście, tak jak napisałem - moim celem jest pozbycie się tego zapisu 16 bajtów za każdym razem, który jest zbędny i można się go pozbyć. Tylko te kliki są konieczne. Przy okazji usunę też na stałe kod, którego nigdy nie użyję (np. programowanie trybów), co pozwoli pozyskać jeszcze kilka bajtów z eepromu.

[ptja]

A jest w ogóle szansa na "wyklikanie" 100 tysięcy razy?

[pralat]

Jak się ktoś bawi latarką i przechodzi między bankami trybów poprzez 6-kliki na przykład, to w parę minut można naklikać ze 100 razy. Oczywiście, nie robi się tego non-stop, a nawet jakby to daje i tak 1000 takich "sesji". Jak padnie eeprom, można wymienić po prostu cały sterownik za $3 lub samego procka. Jednak: jeżeli można te zapisy zrobić optymalnie, to dlaczego nie? W końcu po to robi się modyfikacje latarek, żeby było lepiej niż jest obecnie

[ Dodano: 13 Marzec 2013, 20:52 ]
Po skasowaniu nieużywanej funkcjonalności, konkretnie programowania trybów, stało się jasne, że przetrzymywanie parametrów trybów w eepromie jest zupełnie bezcelowe. Tym samym odpadło 48 bajtów, a rzeczywiście zapisywać trzeba tam chyba ze 4 bajty łącznie
Jest jeszcze kwestia, na którą zwrócił mi uwagę jeden użytkownik z forum BLF: mianowicie procki Atmel mogą zapisywać eeprom nie w postaci pojedynczych bajtów, ale całych stron o nieznanej wielkości. Jak dokładnie jest - nie wiadomo, bo Atmel odpowiada wymijająco.

[ Dodano: 15 Marzec 2013, 15:19 ]
Zrobiłem zmianę miejsca zapisu w eepromie, jednak nie tak, jak planowałem na początku. Okazało się, że kod realizacji pomysłu jaki przedstawiłem wyżej zajmował we wstępnej wersji ok. 380 bajtów
Zrealizowałem to w taki sposób, że przewidziałem 9 "slotów" za zapis stanu w eepromie. Dodatkowo pierwszym bajt w eepromie określa indeks aktualnie używanego slotu. Ten indeks przesuwam, jeżeli ilość klików == 4 bo oczywiście bez sensu byłoby go przesuwać za każdym razem - wróciłbym do punktu wyjścia, czyli zapisu w to samo miejsce (jednej komórki co prawda) przy każdym starcie.
Tym sposobem udało się zrealizować w zadowalającej części założenie, przy czym wielkość kodu wyszła na styk i prawdopodobnie jeżeli będę chciał dodać jakąś funkcjonalność, to "oszczędzanie" eepromu poleci w pierwszej kolejności...