Po brutalnym wyciągnięciu do tablicy nie mam wyboru - muszę to cholerstwo opisać .

Projekt ten to oprogramowanie do latarki PowerLED (kilka ładnych W w diodę, ogniwa przemysłowe 18650, czasami na rowerku mylą mnie ze skuterem/samochodem ).
Aby móc zapanować nad tą jasnością potrzebne jest jakieś sterowanie, bo po poświeceniu taką latareczką ustawioną na 100% w zegarek przez kilka minut widzielibyśmy tylko jasną plamę .
Stosuję się w tym celu zazwyczaj stabilizatory liniowe AMC7135 (do ustalania prądu maksymalnego). Dalsza regulacja jasności odbywa się poprzez odpowiedni PWM (jeżeli jest wystarczająco szybki to oko nie zauważy migotania diody).
Typowy chiński driver: http://www.swiatelka.pl/upload_img/obra ... 5d6012.jpg

Jak widać jest (prawie) wszystko co potrzebne do szczęścia - element(y) wykonawczy i dzielnik do kontroli napięcia na ogniwie (chemia Li.... czyli najmniej ~2.5V pod obciążeniem co w porównaniu z napięciem "diodki" - 3V wygląda OK, ale potrzebujemy jeszcze przecież wcześniejszego ostrzegania o kończącym się ogniwie).

Dlaczego prawie? Niektórzy pewnie oburzą się, gdzie tutaj jest podłączony przycisk do podawania sygnałów na procka (zmiana trybów, itp.). Otóż nie ma go , sygnały podajemy faktycznie poprzez zwykły przycisk, ale odłączający zasilania od całego drivera (odcinający GND konkretnie).
Wymusza to oczywiście specyficzne podejście do odczytywania gestów/klików - korzystanie z EEPROMu tutaj to po prostu konieczność.
Żeby nie było za łatwo, możemy mierzyć tylko czas świecenia, a nie czas przerwy, więc robi się już ciekawie

No to mamy pierwsze założenia, problemy i schematy. O konkretnych opcjach/możliwościach tego projektu przeczytacie tutaj: http://www.swiatelka.pl/viewtopic.php?p=108868#108868 (nie będę kopiował, bo post będzie znacznie za długi). Zajmiemy się tym, co tam nie zostało zamieszczone - czyli przeanalizujemy main.c (link do pobrania w tamtym temacie, naprawdę polecam dokładnie przeanalizować opis programowania i opcji w setup.h, bo nie będziecie wiedzieć co się dzieje)

Typowa "gra wstępna" biblioteki do przerwań, delayów, i obsługi EEPROMu. Do tego 2 makra do rejestrów i portów. Mamy również 1 makro typu "funkcja inline" - to konkretnie wydobywa numer aktywnego slotu.
Ostatnie makro służy do wygodnego rozpisywania do macierzy wartości "startowych" ustawień slotów. (patrz Bluebook-4.6.4) Tutaj konkretnie wykorzystane do tworzenia nazw makr z których wartości dopiero będą pobierane.

Naszej "gry wstępnej" ciąg dalszy. Tutaj jednak już coś konkretnego - tworzymy cały szkielet do przechowywania danych. Struktury typu TSET są praktycznie stałymi - nie zmieniają się nigdy w czasie "życia" programu - tylko podczas przeprogramowania. Dlaczego nie wpiszę ich bez użycia EEPROMu? Nie mam po prostu na to miejsca w kodzie Zużycie Flasha wynosi 1002/1024
W TSET mieszczą się:
- dostępne jasności
- ustawienia stroboskopów (czasy i dzielniki)
Teraz przechodzimy do do struktur typy TCFG - tutaj już mamy te wartości, które zmieniają się w trakcie korzystania z latarki.
Odpowiednio:
- który slot jest teraz włączony
- ile slotów jest aktywnych
- licznik kliknięć (do wchodzenia w programowanie i wychodzenia z blokady)
- stan blokady
- ustawienia slotów (3 najmłodsze bity zawierają przypisaną jasność, 2 następne stroboskopy)
- i 4 zmienne potrzebne do programowania (odpowiednio poziom menu w którym teraz jesteśmy i co wybraliśmy na danym poziomie).
Dlaczego 2 razy definiuje struktury tego samego typu? Bo jedna instancja jest w EEPROMie, a druga w RAMie
Jak widać struktury ładowane do EEPROMu pobierają masę danych z Setup.h - dlatego ważne jest, abyście przeanalizowali opis na swiatelkach).
2 ostatnie linijki to już definicja kilku zmiennych pomocniczych oraz zmiennej do przekazywania wartości z przerwania do funkcji main (stąd to volatile).

Teraz potrzebujemy kilku funkcji (wyrzucić trochę kodu, który nie odpowiada za logikę drivera), które zwiększą przejrzystość programu głównego (dlatego wszystkie są inline).
Mamy odpowiednio:
1. Sczytanie wartości zapisanych w EEPROMie (potrzebna co odcięcie zasilania od uP, a w ciągu dnia reset odbywa się z 50-200 razy u mnie
Jak widać zawiera również "Proste poprawianie struktury na wypedek blednego zapisu EEPROMU". Wiadomo, można zrobić to lepiej - trzymać 2 instancje w EEPROMie, liczyć proste CRC, itd.. Ale nie ma na to po prostu miejsca w kodzie. Dlatego jest proste poprawiania, które powinno pozwolić na ręczne przywrócenie wszystkich ustawień bez wyciągania programatora oraz pobożne życzenie, aby EEPROM dobrze się zapisywał (jak na razie naklikałem się jak głupi podczas pisania tego drivera i w żadnym momencie wartości mi się nie posypały.
2. Zapis EEPROMu (tylko tej struktury, która się zmienia).
3. Wyłączenie zmiennych uruchamiających programowanie oraz wyzerowanie licznika kliknięć
4. Funkcję do obsługi "zapamiętania trybu"

Jeżeli powyższy kod nie jest oczywisty, to tego poniżej nawet nie macie co czytać
Uwaga! Zaczynamy cuda i dziwy

Duży fragment kodu, co? Jest to praktycznie cała logika drivera, tego nie da się praktycznie tłumaczyć fragmentami...
Dodatkowym utrudnieniem jest fakt, że zazwyczaj operujecie na zupełnie innym sterowaniu - wy odczytujecie stany przycisków i w oparciu o to coś robicie. Tutaj mamy tylko informację o włączeniach uP
Jak już napisałem - tego nie da się tłumaczyć fragmentami. Ale nie jesteśmy tutaj po to, żeby robić rzeczy wykonalne
Do kodu dodałem znaczniki /*.....*/ oznaczają one miejsce w kodzie, które omawiam.
A1 - Jeżeli włączona jest blokada drivera to praktycznie cała logika jest wyłączona/nie potrzebna.
A2 - Czekamy więc na ilość kliknięć (zwiększaną dzięki A3), która wyłączy tryb blokady
B1 - Rozpisujemy programowanie - fragment cfg_ram.menu_lvl[1]>3 odpowiada za przedwczesne wyjście z programowania (kiedy w II etapie wybierzemy opcje wyższą niż 4 i wybieranie jasności (etap III) jest niepotrzebne.
B2 - jeżeli nie ustawiamy teraz blokady trybów, to po wyjściu z menu latarka zaświeci na pierwszym slocie
B3 - gdyby te 2 if-y nie były pod else-m to nie moglibyśmy ustawić trybu blokady dla trybu nie należącego do wybranego zakresu
Numeracje tutaj zaczynamy od 0, a nie jak w Setup.h (z powodów oczywistych ).

Obsłużyliśmy już logikę, teraz możemy rozpocząć
Konfigurujemy więc sobie ADCka oraz Watchdoga (ATtiny13 ma tylko jeden timer, który musi być szybki i obsługiwać diodę, a my potrzebujemy jeszcze drugiego, wolnego do obsługi pewnych zdarzeń.

Na samym końcu wydobywamy to, po co ten sterownik został stworzony , czyli jasności i stroboskopy.
Schemat jest następujący:
1. Najmłodszy bit cfg_ram.ktory_tryb odpowiada za ignorowanie kliknięcia, 3 następne przechowują właściwą informację o tym, który slot jest wybrany.
2. Komórka z informacjami o slocie zawiera 3bitową informację o jasności (3 najmłodsze bity, które wydobywamy ANDowaniem bitowym). (2 następne to informacja o stroboskopie).
3. Skoro mamy już numer poziomu jasności to możemy pobrać dla niego odpowiednią jasność.

A - ten fragment odpowiada za ignorowanie kliknięcia/zapamiętanie trybu
B - jeżeli na slocie jest stroboskop to musimy wydobyć jeszcze jego czasy

A w przerwaniu realizujemy sobie czasu do ignorowania kliknięcia oraz sygnalizację niskiego napięcia

I dzięki tym wszystkim syzyfowym operacjom możemy zamrugać diodką trochę ciekawiej, niż w "Bluebookowy" sposób

_________________
Nie pisz komentarzy - dobry kod komentuje się sam.