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)
[syntax=c]
#include <avr/io.h>
#include <util/delay.h>
#include <avr/eeprom.h>
#include <avr/interrupt.h>
#include "setup.h"
#define AMC (1<<PB1)
#define PWM OCR0B
#define TRYB (cfg_ram.ktory_tryb>>1)
#define STP_SLT(SLT)(((SLOT##SLT##_STRB)<<3)+(SLOT##SLT##_LVL)-1)[/syntax]
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.
[syntax=c]typedef uint8_t u08;
typedef struct
{
u08 jasnosci [8];
u08 strb_time1 [3];
u08 strb_factor1[3];
u08 strb_time2 [3];
u08 strb_factor2 [3];
} TSET;
typedef struct
{
u08 ktory_tryb;
u08 ile_trybow;
u08 klikniecia;
u08 rower;
u08 sloty [8];
u08 menu;
u08 menu_lvl[3];
} TCFG;
TSET set_epr EEMEM =
{
{LVL1, LVL2, LVL3, LVL4, LVL5, LVL6, LVL7, LVL8},
{STRB1_TIME1, STRB2_TIME1, STRB3_TIME1},
{STRB1_FACTOR1, STRB2_FACTOR1, STRB3_FACTOR1},
{STRB1_TIME2, STRB2_TIME2, STRB3_TIME2},
{STRB1_FACTOR2, STRB2_FACTOR2, STRB3_FACTOR2}
};
TCFG cfg_epr EEMEM =
{
(AKTUALNY_SLOT - 1)<<1,
SLOTY_WLACZONE - 1,
0,
TRYB_ROWEROWY,
{STP_SLT(1), STP_SLT(2), STP_SLT(3), STP_SLT(4), STP_SLT(5), STP_SLT(6), STP_SLT(7), STP_SLT(8)},
0,
{0, 0, 0}
};
TCFG cfg_ram;
TSET set_ram;
u08 czas, licznik, jasnosc_obecna, numer_stroboskopu;
volatile u08 wdt_epr=0;
[/syntax]
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/1024W 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).
[syntax=c]inline void odczytaj_epr (void)
{
eeprom_read_block(&cfg_ram, &cfg_epr, sizeof(cfg_ram));
eeprom_read_block(&set_ram, &set_epr, sizeof(set_epr));
cfg_ram.ile_trybow&=0b00000111;// Proste poprawianie struktury na wypedek blednego zapisu EEPROMU
}
inline void zapisz_epr (void) {eeprom_write_block(&cfg_ram, &cfg_epr, sizeof(cfg_ram));}
inline void wyzeruj_menu (void)
{
cfg_ram.menu=0;// Wylaczenie programowania
cfg_ram.menu_lvl[1]=0;
cfg_ram.klikniecia=0;// Wyzerowanie licznika klikniec
}
inline void ignoruj_klik (void)
{
cfg_ram.ktory_tryb&=0b11111110;
cfg_ram.klikniecia=0;
}[/syntax]
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"
[syntax=c]int main (void)
{
DDRB |= AMC; // kierunek pinu AMC wyjsciowy
TCCR0A |= (1<<WGM01) | (1<<WGM00) | (1<<COM0B1);// fast PWM, Clear OC0B on Compare Match
TCCR0B |= (1<<CS00); // prescaler 1
odczytaj_epr(); // Odczytanie zawartosci EEPROM[/syntax]
Jeżeli powyższy kod nie jest oczywisty, to tego poniżej nawet nie macie co czytać
Uwaga! Zaczynamy cuda i dziwy
[syntax=c]/*A1*/if (!cfg_ram.rower)// Jezeli driver nie jest zablokowany
{
/*B1*/if ((cfg_ram.menu==3) || (cfg_ram.menu_lvl[1]>3))// Rozpiska z programowania
{// Programowanie slotow
if (cfg_ram.menu_lvl[1]<4) cfg_ram.sloty[cfg_ram.menu_lvl[0]]=(cfg_ram.menu_lvl[1]<<3) | cfg_ram.menu_lvl[2];
if (cfg_ram.menu_lvl[1]==4)// Programowanie slotu rowerowego
{
cfg_ram.rower=1;
cfg_ram.ktory_tryb=(cfg_ram.menu_lvl[0]<<1);
}
else
/*B2*/cfg_ram.ktory_tryb=0;// Ustawianie slotu pierwszego jako aktywny
if (cfg_ram.menu_lvl[1]==5) cfg_ram.ile_trybow=cfg_ram.menu_lvl[0];
wyzeruj_menu();// Programowanie ilosci aktywnych slotow
}
/*B3*/else
{// Obsluga klikniec
if (cfg_ram.ktory_tryb & 0b00000001) cfg_ram.ktory_tryb+=2; else cfg_ram.ktory_tryb++;
if (TRYB>cfg_ram.ile_trybow) cfg_ram.ktory_tryb=1;
}
if (cfg_ram.klikniecia==MENU_IN)// Programowanie
{
for (licznik=0; licznik<MENU_SIG_RPT; licznik++)
{
PWM=MENU_LVL1; _delay_ms (MENU_TIME1);
PWM=MENU_LVL2;_delay_ms (MENU_TIME2);
}
cfg_ram.menu++;
for (licznik=0; licznik<MENU_CHOOSE_RPT; licznik++)
for (czas=0; czas<8; czas++)
{
cfg_ram.menu_lvl[cfg_ram.menu-1]=czas;
zapisz_epr();
PWM=set_ram.jasnosci[czas]; _delay_ms(MENU_CHOOSE_TIME);
}
wyzeruj_menu();// Jezeli nic nie wybrano to wychodzimy
}
}
else
/*A2*/if (cfg_ram.klikniecia==ROWER_STOP)// Wyjscie z trybu rowerowego
{
cfg_ram.rower=0;
cfg_ram.klikniecia=0;
}
/*A3*/cfg_ram.klikniecia++;
zapisz_epr();// Zapis EEPROM[/syntax]
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
).[syntax=c]
ADMUX |= (1<<REFS0)| (1<<MUX0) | (1<<ADLAR); // 1.1V, PB2, 8bit
ADCSRA |= (1<<ADEN) | (1<<ADPS2) | (1<<ADPS0)|(1<<ADSC);// Wlaczenie ADC, prescaler 32, wykonanie pomiaru
WDTCR |= (1<<WDTIE)| (1<<WDP1) | (1<<WDP0);// Watchdog - przerwanie, prescaler 8 -> przerwanie co ~128ms
sei();// Odblokowanie przerwan[/syntax]
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ń.
[syntax=c]licznik=0;// Ustalanie jasnosci i obecnosci stroboskopu
jasnosc_obecna=set_ram.jasnosci[cfg_ram.sloty[TRYB] & 0b00000111];
numer_stroboskopu=cfg_ram.sloty[TRYB]>>3;
if (numer_stroboskopu)
{
numer_stroboskopu--;
licznik=1;
}[/syntax]
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ść.
[syntax=c]while (1)// Swiecenie
{
/*A*/if (wdt_epr)
{
wdt_epr=0;
ignoruj_klik();
zapisz_epr();
PWM=jasnosc_obecna/IGN_CLICK_FACTOR; _delay_ms(IGN_CLICK_SIG);
}
/*B*/if (licznik)
{
for (czas=0; (czas<set_ram.strb_time1[numer_stroboskopu]) && (!wdt_epr); czas++) {PWM=jasnosc_obecna/set_ram.strb_factor1[numer_stroboskopu]; _delay_ms (STRB_TIME1);}
for (czas=0; (czas<set_ram.strb_time2[numer_stroboskopu]) && (!wdt_epr); czas++) {PWM=jasnosc_obecna/set_ram.strb_factor2[numer_stroboskopu]; _delay_ms (STRB_TIME2);}
}
else
PWM=jasnosc_obecna;
}[/syntax]
A - ten fragment odpowiada za ignorowanie kliknięcia/zapamiętanie trybu
B - jeżeli na slocie jest stroboskop to musimy wydobyć jeszcze jego czasy
[syntax=c]ISR (WDT_vect)
{
static u08 batt=0, ign=0;// Ignorowanie klikniecia
if (ign<IGN_CLICK_TIME)if (++ign==IGN_CLICK_TIME) wdt_epr=1;
if ((++batt>=BATT_PAUSE) & (!wdt_epr))// Sprawdzanie napiecia baterii
{
batt=0;
if (ADCH<BATT_LEVEL) {PWM=jasnosc_obecna/BATT_FACTOR; _delay_ms(BATT_TIME);}
ADCSRA |= (1<<ADSC);// Podanie startu ADC
}
}[/syntax]
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
Statystyki: Napisane przez barney — 9 mar 2013, o 21:23
]]>