Mikroprocesorowy sterownik latarki (Flagiusz)

[pawelsz]

wydaje mi się, że można by dodać ograniczenie przed ustawieniem takiej samej jasności sąsiednich trybów w pierwszej grupie

a jeśli ktoś zechce mieć tylko jedną jasność ?

[Calineczka]

wydaje mi się, że można by dodać ograniczenie przed ustawieniem takiej samej jasności sąsiednich trybów w pierwszej grupie.
Ułatwi to orientację w którym aktualnie trybie jest latarka - przy ustawionej takiej samej jasności (np. przez przypadek)

Dzięki za sugestie, ale rzeczywiście uniemożliwiło by to świadomemu userowi wybór dwóch identycznych jasności. Poza tym aktualnie jest tak dużo trybów, że pamięć Attiny(tego modelu procka, tzn. 13V) jest zapełniona pod pokrywke . Trzeba by rezygnować z jakichś funkcji....a i tak wszystkich się nie zadowoli. Dlatego Df robi czasem soft na zamówienie

[zgrzezly]

teoretycznie w setupie np. można by zaimplementować funkcję blokady (on/off) przed ustawieniem identycznych poziomów świecenia trybów ciągłych.
abstrahując oczywiście od przepełnionej pamięci w mikroprocesorze.

[Calineczka]

teoretycznie w setupie np. można by zaimplementować funkcję blokady (on/off) przed ustawieniem identycznych poziomów świecenia trybów ciągłych.
abstrahując oczywiście od przepełnionej pamięci w mikroprocesorze.

zgadzam się całkowicie, możliwość taka istnieje.Należało by wówczas, czysto teoretycznie, kazac sterownikowi coś zrobić, zasygnalizować błąd w jakiś sposób lub automatycznie przypisac poziom niżej/wyżej....etc

[m-blue]

Moze i glupie pytanie:) ale w temacie prockow, to srednio siedze:) czy procesaor w jakis sposob sprawdza jakie jest napiecie na wejsciu, tzn czy jest jakas mozliwosc kontroli zasilania w sensie, jak napiecie zaczyna byc za niskie to cos tam bedzie realizowane przez uklad, miganie itp?

[lennin]

Oj poczytaj trochę. Było o tym w podobnym kontekście rozpoznawania rodzaju zasilania i zabezpieczenia przed nadmiernym rozładowaniem ogniw

[Calineczka]

Procesor ma możliwość sprawdzania tego, ale oficjalnie nie wypuściliśmy żadnej wersji która to robi.Nieoficjalnie są
Attiny13V ma jeden przetwornik analogowo-cyfrowy i trudno jest mierzyć jednocześnie prąd(by go ograniczać) i napięcie wejściowe(by móc chronić akku li-ion)

[m-blue]

ok, to w razie potrzeby bede wiedzial z kim negocjowac:)
Swoja droga, nie chodzi mi o aku, ale bardziej o temat naglego braku swiatla.
Kombinuje z latarka pod wode a tam nagla ciemnosc jest dosc malo bezpiecznym zjawiskiem:) a tak zawsze wiadomo, ze trzeba do gory bo zatraz bedzie koniec:)
Co do aku, to poki co mam nimh, wiec teoretycznie wyjechanie ich do zera nie jest tragedia.
kombinuje teraz nad jakims pakietem z np 18650, ale poki co musze skonczyc jedno i ew puscic dalej, zeby byly srodki na nastepna zabawe:)

[EdiM]

Witam
Jednoczesny (a raczej prawie jednoczesny) pomiar napięcia i prądu nie powinien stanowić problemu. Oczywiście zależy to od zastosowanego algorytmu pracy układu sterowania z pomiarem prądu. Niestety mam ogólnie pewne wątpliwości co do zastosowanej 'bezstratnej' metody ograniczenia prądu.

[m-blue]

mam na mysli bardziej ostrzeganie, typu kilka migniec itp, niz calkowite ograniczenie pradu. zawsze mozna zmienic tryb, co przedluzy czas pracy, przynajmniej jesli dobrze zrozumialem Twoja odpowiedz

[EdiM]

Witam
Chciałem zapytać, jak w sterowniku zaimplementowano zapamiętywanie trybów?
W tej chwili robię pewną konstrukcję i znowu wracam do moich ulubionych AVRów, ale według specyfikacji mają one podaną trwałość 100.000 cykli zapisu. Zakładając, że po każdym włączeniu jest nowy zapis, a czasem nawet 2, sytuacja nie wygląda najlepiej.
Tak więc czy możesz zdradzić jakieś szczegóły w tym temacie?

[df]

Edim, ja nie robię zapisów przy każdym starcie MCU.
Przy starcie robię odczyt z EEPROMu i ustawiam parametry pracy trybu.
Natomiast zapis robię tylko wówczas, gdy:
1. jest włączona opcja pamięci ustawień (w setupie)
2. zapisywany numer trybu jest inny niż już w pamięci zapisany
3. z nieznacznym opóźnieniem - po kilku sekundach od ostatniej reakcji użytkownika

Dzięki temu w bardzo znaczącym stopniu ograniczam liczbę cykli zapisu, mocno oszczędzając pamięć i troszkę prądu.

Każdorazowe inkrementowanie licznika trybu oraz zapis up-time`u (bo zapewne to masz na myśli pisząc o tym drugim zapisie) i zapisywanie ich przy każdym resecie (odcięciu zasilania) w EEPROMie uważam za pójście na skróty i błąd w sztuce.
Takie rozwiązanie jest faktycznie bardzo nietrwałe, a do tego przy odpowiednio szybkim klikaniu lub słabym kontaktowaniu wyłącznika może prowadzić do błędnych zapisów (musisz zagwarantować kilka-kilkanaście taktów zegarowych na wykasowanie/zapis do EE).

Dlatego też opracowałem zupełnie inne, architektonicznie lepsze rozwiązanie, minimalizując do minimum operacje zapisu, których u mnie w czasie zmian trybów po prostu nie ma.

[EdiM]

Dziękuje za błyskawiczną odpowiedź. Czyli inkrementowanie trybu odbywa się bez pomocy EEPROMu? Do tego służy ten stosunkowo duży kondensatorek (100u)?
W driverach z DXa na procku PIC jest na pewno zapis do EEPROMa. Ale tam jest nieco wyższa trwałość (lub inaczej szacowana) - milion cykli, więc wystarczy swobodnie.

[df]

Dziękuje za błyskawiczną odpowiedź. Czyli inkrementowanie trybu odbywa się bez pomocy EEPROMu? Do tego służy ten stosunkowo duży kondensatorek (100u)?

Dokładnie tak.

Na początku testowałem też zapisy do EE podczas zaników zasilania (gdy wykryję na porcie dłuższy zanik, a MCU dalej pracuje podtrzymywany z C), ale czasem pojawiały się błędy - np. zmieniając wartość z 00 na 01 czasem wychodziło FF, czasem 7F - widać było, że pojedyncze bity się czasem nie programowały.
Do zapisu w EEPROM`ie musisz mieć gwarancję stabilności napięcia (zwykle wyższego niż minimum 1,8 dla serii XXv) przez kilka taktów trwania zapisu.

W driverach z DXa na procku PIC jest na pewno zapis do EEPROMa. Ale tam jest nieco wyższa trwałość (lub inaczej szacowana) - milion cykli, więc wystarczy swobodnie.

Tak jest niewątpliwie taniej i nieco prościej.
Nie muszą wstawiać droższego tantala/elektrolita (teoretycznie w ogóle nie muszą dawać pojemności), nie muszą ciągnąć linii do portu z detekcją zaniku napięcia itd. co nie znaczy, że jest to rozwiązanie trwalsze i lepsze.

Z resztą właśnie dokładnie takie podejście zastosowałem w sofcie do najmniejszego driverka na światełkach (BTW - Arku, czekamy na oficjalne ustanowienie rekordu ).
No ale tam z uwagi na masakryczny brak miejsca nie dało się niczego więcej wstawić poza najmniejszym z najmniejszych Atmeli i mosfetem w sot-23.

[EdiM]

Z błędami w zapisie w EEPROMie nie powinno być problemu jeśli nie ma zaawansowanych trybów, itp. Zapis do pamięci w chwili wykrycia spadku napięcia przy wyłączaniu trochę nie ma sensu, przecież i tak za każdym cyklem włącz-wyłącz zapisujemy, to można zrobić zaraz po załączeniu, kiedy mamy w miarę wysokie zasilanie i w miarę długo.
Ja chyba jednak zrobię zapisy do EE, tylko zaimplementuję algorytmy zwielokratniające ilość zapisów.

Za to w małym PICu który stosuję np w UP100, jako podtrzymanie do przełączania trybów wystarcza nawet bardzo mały kondensatorek - 100n.