Driver Flagiusza (programowalny) - nowa odsłona

[Pyra]

Jestem laikiem elektronicznym ale funkcjonalności wygląda SUUUPER! Gratulacje!
Szczerze mówiąc myślałem o czymś podobnym jako driver i sterowanie do Ledlenser P7 (jest osobny temat) ale mam pytanie o zakres - piszesz do 6V, czyli jak to będzie wyglądało przy 4xAAA (bateria alkaliczna) no i 4xaku NiMH (niby coś koło 4.8V)?

Pozdrawiam, Paweł

To 6V wynika z dwu powodów, deklarowane przez producenta max napięcie zasilania ATTiny13 wynosi 5,5V. W związku z tym, że ATtiny jest zasilany poprzez diodę krzemową tak więc 5,5 +0,6 daje 6,1V, ale musimy mieć jakiś zapas. Ponadto ważna jest też moc strat na elementach regulacyjnych czyli AMC, Dla prądu znamionowego 350mA, dopuszczalne napięcie na AMC to około 2V.....

Pozdrawiam

[lennin]

Zakładając, że jesteś prawdziwym "kosmitą" i włączasz oraz wyłączasz latarkę raz na 5 minut przez 24 godziny na dobę, 7 dni w tygodniu, przez 365 dni w roku, to przy i tak mocno wyśrubowanych założeniach dojdziesz do gwarantowanej żywotności pamięci po... uwaga: ponad 30 latach! (3.200.000/288/365)

To sprawdzimy czy jestem kosmitą za 30 lat napisze czy wytrzyma

[df]

To sprawdzimy czy jestem kosmitą za 30 lat napisze czy wytrzyma

Trzymam Cię za słowo

[Gardol]

co do tych 6V to wolę wyjaśnienie Flagiusza niż Pyry... nie będę wyjaśniał swoich zdolności po raz kolejny
Można się odezwać na PM w sprawach konkretnych jeśli chodzi o zastosowania do LL P7 jak już cała reszta składników będzie na miejscu?

[Pyra]

Drugim rozwiązaniem które testowałem (i które także odrzuciłem) było połączenie pinu 5-go z bardzo blisko znajdującą się przelotką od +Vcc i badanie "wprost" stanu logicznego na zasilaniu. Przy tak małej pojemności jest za mało czasu na reakcję i trzeba zwiększać pojemność podtrzymującą - czyli stosować dobrze znane Ci rozwiązanie, na którym opierałem się w poprzednich projektach.

Biorę to pod uwagę. Kondziołka większego chyba zmieszczę w miejscu opisu D1/R5, wtedy na Pin 2 lub 3 podał bym VCC z baterii, ale chyba by tu trzeba przez jakiś rezystorek, bo
Uwe pin > VDD proc, trochę mnie to niepokoi
Pin 5 ma już u mnie swoją rolę do odegrania

OK, z zainteresowaniem będę śledził Twoje próby.

Mam nadzieję, że będzie tam coś interesującego. Podwaliny pod to rozwiązanie położyłem w projekcie, w którym 1 klik - tryb w górę, 2 kliki - tryb w dół.
Zastanawiałem się też czy obniżenie trybu w rozumieniu numeru to dobry pomysł, w wypadku programowalnych trybów, bo może sobie ktoś ustawić np.: Low, Hi, Mid. Niekorzystną sytuacją by było gdyby driverek próbował przeskoczyć w dół z Mid, ustawił by Hi i szybko przeskoczył znów niżej czyli w Low. Ale w sytuacji ustawień Hi, Mid, Lo, już nie będzie tak wesoło..... Rozważam aktualnie możliwość programowego obniżania wartości PWM, bez faktycznej zmiany trybu....

Zgadza się pomysł tego rozwiązania nie jest nowością - na jego temat wielokrotnie dyskutowałem również w ramach tego forum i także z EdiMem, dlatego też pochyliłem się nad tematem i zadbałem o to by wszystko było zaprojektowane w sposób bezpieczny, architektonicznie najbardziej poprawny i nie robię z zastosowanych przeze mnie rozwiązań żadnych tajemnic, gdyż dobrze wiem, że nie ma w nich żadnych "kruczków" - i nie mam tu nic do ukrycia.

To jest tak samo jak z kryptografią - nie jest sztuką zrobić black-box`a i przekonywać na słowo, że jest on odporny na ataki oraz zmuszać łamaczy nie do odnajdywania algorytmicznie słabych punktów nieznanego (utajonego) rozwiązania oraz jego reverse-engeeneringu.
Prawdziwą sztuką jest pokazać rozwiązanie/algorytm w szczegółach, który sam się obroni użytą w nich myślą i nietuzinkowym rozwiązaniem - co w odniesieniu do analogi z dobrą kryptografią nie sprowadza się do "zaufania na słowo", lecz jest jawnym dowodem np. matematycznie uzasadniającym siłę danego rozwiązana na kryptoanalizę.

O to to to!

Pozdrawiam

[df]

co do tych 6V to wolę wyjaśnienie Flagiusza niż Pyry... nie będę wyjaśniał swoich zdolności po raz kolejny

Jest dokładnie tak jak napisał to Kolega Pyra.

Natomiast minimalne napięcie sterownika jest uwarunkowane następującymi czynnikami:
- procesor (ATtiny13v) - aby pracował musi mieć zasilanie co najmniej 1,8V, a ponieważ w szeregu z jego zasilaniem jest krzemowa dioda, trzeba dodać +0,7V co daje minimum na poziomie 2,5V
- napięciem Vf diody LED, którą sterownik będzie zasilał powiększonym o +0,15V spadku napięcia na stabilizatorach prądu diody (AMC) w zakresie pełnej stabilizacji
- oraz oczywiście ustawioną w sofcie minimalną wartością napięcia pracy, przy której włącza się zabezpieczenie akumulatora - 2,9V, ale pewnie je obniżę do 2,8V

Można się odezwać na PM [...]

Jeżeli ktokolwiek ma do mnie pytania nie związane bezpośrednio z tematem dyskusji dot. tego projektu (lub wstydzi się o coś zapytać publicznie na łamach forum) to jak najbardziej zapraszam na PW ( flagiusz@op.pl )

[df]

Kondziołka większego chyba zmieszczę w miejscu opisu D1/R5

Tak, da się - to dobre miejsce bo na pin.4 masz GND.

wtedy na Pin 2 lub 3 podał bym VCC z baterii, ale chyba by tu trzeba przez jakiś rezystorek, bo Uwe pin > VDD proc, trochę mnie to niepokoi

A czemu nie na pin.5?

Jest zdecydowanie bliżej i albo zworkę, albo kilka-kilkanaście kiloomów idealnie tam wejdzie.
Każdy port (poza resetem) jest zablokowany do masy i Vcc zwrotnie diodami (ESD).
jak podłączysz zasilanie do dowolnego portu (poza res.) to procek wstanie i zacznie pracować, bo prąd zamknie się przez port, diodę zabezpieczającą do Vcc.
Przy założeniu, że nie będziesz go zasilał w takiej konfiguracji z napięcia >5,5V to nie masz się czego obawiać.

Pin 5 ma już u mnie swoją rolę do odegrania

No tak, oj kuszą Cię widzę te dwa kanały PWM, oj kuszą

[Calineczka]

Darku, gratuluję
Od niedawna dwuklikam sobie tym twoim pomysłem i całkiem mi to do gustu przypadło.
Koledzy dopytują o wersję komercyjną, kiedy pojawi się w sklepiku?
Pisałeś o możliwości sterowania switchem-gdzie go podłączyć? Na schemacie nie jest zaznaczony. Może w przypadku jego zastosowania można by zmienić sposób sterowania?

[Bulba]

Zajefajna konstrukcja, nareszcie driver bez pieciuset trybow, siedmiuset grup etc....
No i zabezpieczenie dla tych ktorzy uzywaja lijonow nonprotect
Jezeli cena bedzie przystepna, to widze tutaj malego Hita
Gratulacje!

[czarny_kruk]

Gratulacje df. Pokazales co mozna wyciagnac z tego sterowniczka dzieki swietnemu softowi. W zasadzie nie ma sie czego doczepic. Zasugerowalbym jedynie zmiane w ostrzeganiu o rozladowanym accu. Z praktyki moim zdaniem lepsze jest konkretna ilosc (np. 5-8) migniec co 8sek po przekroczeniu progu niz mruganie niepotrzebnie przez kilkanascie minut. Alternatywne rozwiazanie to aby klikniecie po wlaczeniu sie ostrzegania powodowalo zaprzestanie dalszego migania co 8sek, zejscie do moon-mode pozostaje aktywne.

Co do watpliwosci Calineczki to microswitcha mozna podlaczyc do dowolnego wolnego portu i masy, zatem najlatwiej bedzie skorzystac z ktorejs pociagnietej sciezki. Po zmianie softu zamiast ktorejs blokady (trybow albo poziomow) bedzie mozna podlaczyc softswitcha. Tak przypuszczam.

[df]

Zajefajna konstrukcja, nareszcie driver bez pieciuset trybow, siedmiuset grup etc.... No i zabezpieczenie dla tych ktorzy uzywaja lijonow nonprotect
[...]
Gratulacje!

Dziękuję

Gratulacje df. Pokazales co mozna wyciagnac z tego sterowniczka dzieki swietnemu softowi.

Dziękuję, choć nie powiedziałem jeszcze ostatniego słowa
Ale o tym za chwilę...

Zasugerowalbym jedynie zmiane w ostrzeganiu o rozladowanym accu. Z praktyki moim zdaniem lepsze jest konkretna ilosc (np. 5-8) migniec co 8sek po przekroczeniu progu niz mruganie niepotrzebnie przez kilkanascie minut.

Jeżeli ostrzeganie o niskim stanie miałoby się samo po kilku razach wyłączyć, to jaki miałoby ono sens? Celem tego jest właśnie informowanie użytkownika, że kończy się energia i jest on dopóty informowany, dopóki napięcie na akumulatorze jest poniżej ustalonej wartości.
Założę się, że wielu użytkowników po kilku ostrzeżeniach nie będzie już tego pamiętać i nagle zostanie zaskoczonych ciemnością (zabezpieczenie przed głębokim rozładowaniem).

Alternatywne rozwiazanie to aby klikniecie po wlaczeniu sie ostrzegania powodowalo zaprzestanie dalszego migania co 8sek, zejscie do moon-mode pozostaje aktywne.

Użytkownik w każdej chwili ma możliwość zmiany trybu na inny (jak i zmiany jasności w trybie), więc może świadomie zmienić tryb na mniej prądożerny.
Jeżeli tego nie zrobi, a napięcie zbliży się do granicy odcięcia, to sterownik ten sam podejmie za niego decyzję i przełączy jasność w moon-mode zachowując dany tryb pracy.
Jedno kliknięcie wycofa moon-mode przywracając ustawioną jasność w tym trybie itd.

Co do watpliwosci Calineczki to microswitcha mozna podlaczyc do dowolnego wolnego portu i masy, zatem najlatwiej bedzie skorzystac z ktorejs pociagnietej sciezki. Po zmianie softu zamiast ktorejs blokady (trybow albo poziomow) bedzie mozna podlaczyc softswitcha. Tak przypuszczam.

Mikroswitch włączyć można między pin 1 MCU, a masę - sterowanie takie samo jak odcięciem zasilania.

OK, pracuję nad rozszerzoną wersją 2.1, która zachowa wszystkie funkcje co opisana 2.0, a dodatkowo będzie miała tryb konfiguracji sterownika (nie mylić z ustawieniami jasności) z możliwością sprzętowej blokady. Tryb ten będzie osiągalny po 5-ciu szybkich kliknięciach i będzie się składał z 4 kolejnych opcji wyboru: TAK / NIE.

W ten sposób możliwe będzie softwarowe ustawianie następujących parametrów:
1. dostępność trybu strobe-rowerowy (tak=będzie/nie=nie będzie)
2. opcja pomiaru i kontroli stanu napięcia baterii (tak=włączona/nie=wyłączona)
3. pamięć ostatniego trybu (tak=włączona/nie=wyłączona)
4. opcja konfiguracji jasności dostępna po 3-kliku (tak=włączona/nie=wyłączona)

Każda z opcji wyboru przebiega w następujący sposób:
- przez 2 pierwsze sek. sterownik oczekuje ze zgaszoną diodę - kliknięcie w tym czasie anuluje zmianę danego parametru i powoduje przejście do kolejnego z zachowaniem jego aktualnej wartości
- następnie sterownik zapali diodę z jasnością średnią (tak) i co 2 sekundy będzie zmieniał jej jasność na niską (nie) i spowrotem - pojedyncze kliknięcie w danym stanie oznacza dokonanie wyboru danej opcji i przejście do kolejnego parametru
- brak dokonania wyboru dowolnej z opcji w czasie 10 sek. spowoduje wyjście z trybu konfiguracji bez dokonywania zmian.

Istnieje możliwość blokady trybu konfiguracji poprzez zwarcie zworki R3 - będzie to jedyny sprzętowy "przełącznik", gdyż reszta została przeniesiona do softu.

Rozwiązanie to wnosi nowy wymiar w możliwościach adaptacji działania sterownika pod indywidualne potrzeby użytkownika.

W nowej wersji obniżyłem progi napięć w funkcji pomiaru napięcia ogniwa na:
< 3,05V - ostrzeganie
< 2,9V - przełączenie w moon-mode
< 2,8V - wyłączenie (zabezpieczenie przed głębokim rozładowaniem)

A zatem w praktyce będzie to działać tak:
- pracujący wybrany tryb (do czasu spadku napięcia do ok. 3,05V)
- pracujący wybrany tryb z ostrzeganiem co 8 sek. (3,05-2,9V)
- przełączenie w moon-mode
- przełączenie w moon-mode + ostrzeganie
- wyłączenie sterownika (zabezpieczenie)

Wersja 2.1 przechodzi aktualnie testy.

[emerel]

Wersja 2.1 przechodzi aktualnie testy.

Gratuluję i czekam (-y ) na wersję "produkcyjną", szerzej dostępną.

pozdrawiam!

[Bulba]

Zapomnialem zapytac wczesniej, jaka jest jego sprawnosc ?

[czarny_kruk]

Zasugerowalbym jedynie zmiane w ostrzeganiu o rozladowanym accu. Z praktyki moim zdaniem lepsze jest konkretna ilosc (np. 5-8) migniec co 8sek po przekroczeniu progu niz mruganie niepotrzebnie przez kilkanascie minut.

Jeżeli ostrzeganie o niskim stanie miałoby się samo po kilku razach wyłączyć, to jaki miałoby ono sens? Celem tego jest właśnie informowanie użytkownika, że kończy się energia i jest on dopóty informowany, dopóki napięcie na akumulatorze jest poniżej ustalonej wartości.
Założę się, że wielu użytkowników po kilku ostrzeżeniach nie będzie już tego pamiętać i nagle zostanie zaskoczonych ciemnością (zabezpieczenie przed głębokim rozładowaniem).

Wg mnie to dyskusyjna sprawa. Kwestia ilosci tych przypomnien. Po 5-8 mozna juz dosc dobitnie zapamietac o co chodzi, a z autopsji wiem ze miganie przez kilkanascie minut JEST uciazliwe, kiedy to mozemy jeszcze w pelni korzystac z energii.

Alternatywne rozwiazanie to aby klikniecie po wlaczeniu sie ostrzegania powodowalo zaprzestanie dalszego migania co 8sek, zejscie do moon-mode pozostaje aktywne.

Użytkownik w każdej chwili ma możliwość zmiany trybu na inny (jak i zmiany jasności w trybie), więc może świadomie zmienić tryb na mniej prądożerny.
Jeżeli tego nie zrobi, a napięcie zbliży się do granicy odcięcia, to sterownik ten sam podejmie za niego decyzję i przełączy jasność w moon-mode zachowując dany tryb pracy.
Jedno kliknięcie wycofa moon-mode przywracając ustawioną jasność w tym trybie itd.

Tyle, ze po przelaczeniu na nizszy tryb przez uzytkownika miganie zdaje sie nie znika? Czyli zalozmy - korzystajac ze sredniej jasnosci wlacza sie miganie i z racji nieduzego obciazenia mamy to miganie zagwarantowane przez kilkadziesiat minut.

Zapomnialem zapytac wczesniej, jaka jest jego sprawnosc ?

Srednia sprawnosc dla zasilania z li-ion i tego rozwiazania (driver liniowy) wyniesie okolo 90%.

[lennin]

df napisał/a:

czarny_kruk napisał/a:
Alternatywne rozwiazanie to aby klikniecie po wlaczeniu sie ostrzegania powodowalo zaprzestanie dalszego migania co 8sek, zejscie do moon-mode pozostaje aktywne.

Użytkownik w każdej chwili ma możliwość zmiany trybu na inny (jak i zmiany jasności w trybie), więc może świadomie zmienić tryb na mniej prądożerny.
Jeżeli tego nie zrobi, a napięcie zbliży się do granicy odcięcia, to sterownik ten sam podejmie za niego decyzję i przełączy jasność w moon-mode zachowując dany tryb pracy.
Jedno kliknięcie wycofa moon-mode przywracając ustawioną jasność w tym trybie itd.

Tyle, ze po przelaczeniu na nizszy tryb przez uzytkownika miganie zdaje sie nie znika? Czyli zalozmy - korzystajac ze sredniej jasnosci wlacza sie miganie i z racji nieduzego obciazenia mamy to miganie zagwarantowane przez kilkadziesiat minut.

Nie do końca tak jest. Z autopsji wiem że mryganie w 100% ustępuje przy przełączeniu na przykładowe 10% na długi okres czasu. Pewnie to wina mich akusów