Oprogramowanie sterownika BLF-VLD
: środa 13 mar 2013, 12:05
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:
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:
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:
... 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ę
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;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(); // <--- tutaj zwiększany jest indeks wspomnianej komórki
...
eeprom_write_block(&state, 0, sizeof(State_t) - sizeof(state.mode_arr));
[ 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;
}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ę
