www.swiatelka.pl

greg podepnę się pod pytanie Krasnego

- czy jest mozliwość podesłania kupionej już od Ciebie latarki na zmianę softu, czy w grę wchodzi tylko wymiana drivera

Pozdrawiam

Sterownik oczywiście można przeprogramować, ale jest to czasochłonne. Ponad godzina pracy w warsztacie - demontaż (rozklejenie reflektora od piguły, wylutowanie drivera), programowanie, montaż (lutowanie, klejenie) - sporo pracy, koszt 30 zł + wysyłka.

Dodatkowo, jeśli driver w latarce ma kontrolę temperatury, to w grę wchodzi tylko wyższy model drivera czyli "extended", nad którym prace dopiero trwają. Poza tym jest to droższy model i w zasadzie taki upgrade oznacza wymianę całego drivera w latarce.

greg pisze: ochrona ogniwa ustawiona na około 2,8V - informacja 3-ma błyskami i przejście w niższy tryb pracy

Jak zadziała to zabezpieczenie gdy ogniwo osiągnie napięcie 2,8V podczas świecenia w najniższym trybie (0,25% mocy) ?

Poinformuje Cię trzema błyskami i tyle. Niżej z jasnością już nie zejdzie, to oczywiste.

Witam
Dziś odebrałem driverek do testów, niby miał poczekać do jutra, ale... korciło strasznie. Zamontowałem więc w luźnym module. Na początku miałem trochę problemów, gdyż robiło mi się zwarcie na przewodach doprowadzających, ale poradziłem sobie przelutowując je na sam skraj pola kontaktowego MCPCB.
Jak można było przeczytać, byłem trochę sceptycznie nastawiony do n-klika, jednak liczenie do 8 nie sprawiło mi większego problemu. Jedyne co może bym rozważył, to jakaś sygnalizacja zmiany stanu pamięci trybów i myślę tu tylko o potwierdzeniu, gdyż aktualnie po wyklikaniu nie mamy pewności, czy system "zaskoczył". Dowiemy się o tym przy następnym włączeniu, ale jednak może dało by się coś z tym zrobić.
Pozostałe funkcje działają bez zarzutu, poziomy jasności uważam że są wystarczająco zróżnicowane. Mamy do dyspozycji od 9mA do 2,686A (w moim wypadku, ale to wina całego układu zasilania, bo użyłem WF-502), zaskoczyło mnie to pozytywnie, bo w teorii powinno być niecałe 11mA.
Jestem przyzwyczajony do "swoich konstrukcji" gdzie tryby zmieniam zawsze 1-klikiem, tak więc chwilkę potrzebowałem do wypracowania nowego nawyku. Trzeba przyznać, że sam proces klikania jest tu lepiej rozwiązany, bo u mnie czas przerwy jest dość krótki, a tutaj możemy zmieniać tryby klikając bez pośpiechu, nawet bym powiedział że wystarczy wolno. Jednak jest rzecz do której muszę się przyzwyczaić, tutaj wieloklik powoduje zmiany trybów i kilka razy nie byłem pewien czy właściwie wielkolkikam.

Pozdrawiam

Dziękuję za feedback.

Odnośnie sygnalizacji zmiany stanu pamięci, mam identyczne odczucie, że przydałby się tu np. błysk potwierdzający. Tak właśnie miało być, lecz aktualnie po wszelakich optymalizacjach zostało mi tylko 8 bajtów pamięci (z 1024) i tu jest właśnie problem...

Jak uda się jeszcze cokolwiek zoptymalizować, to wcisnę tą sygnalizację w wersję "standard".

W wersji "extended" problemu z brakiem pamięci programu raczej nie będzie.

Witam

greg pisze:Odnośnie sygnalizacji zmiany stanu pamięci, mam identyczne odczucie, że przydałby się tu np. błysk potwierdzający. Tak właśnie miało być, lecz aktualnie po wszelakich optymalizacjach zostało mi tylko 8 bajtów pamięci (z 1024) i tu jest właśnie problem...

Tak właśnie podejrzewałem, bo wspominałeś o zajętości 99,9% pamięci "znam ten ból". Może z jakiegoś mignięcia zrobić podprogram i go wywoływać.
Nie wiem jak inni betatestrzy będą się na to zapatrywać, ale sądzę, że wystarczyło by 8 poziomów jasności, a wtedy regulację można przeprowadzić przesuwając rejestr w lewo +1.

Pozdrawiam

Mnie również 8-klik nie robi problemu (dużo czasu na kolejne kliki, bardzo to wygodne), ale wciąż niepokoi mnie 6-klik zmieniający moc trybu. W prawdziwym użytkowaniu nie powinno się przypadkowo go uruchamiać, ale przy zabawach juz kilkukrotnie przypadkowo wszedłem w zmianę mocy (jest ona sygnalizowana błyskami i można z niej wyjsć przed właścowym uruchomieniem). Dam znać jak driv będzie "battle tested", a nie po zabawie.

Pyra pisze:sądzę, że wystarczyło by 8 poziomów jasności, a wtedy regulację można przeprowadzić przesuwając rejestr w lewo +1

To byłoby proste i testowałem taką opcję, jednak jest poważna wada tego rozwiązania - poziomy jasności są bardzo kiepsko rozłożone. Ja podstawiam z tabeli wartości PWM wyliczone wcześniej zgodnie z kwadratowym prawem ściemniania. To daje zadowalające zróżnicowanie jasności między każdym kolejnym poziomem - czy to niskimi, czy najwyższymi. Moim zdaniem to ważne i ergonomiczne.

Dodatkowo, poniżej wypełnienia 6/255 ATtiny13 nie wysterowuje 8xAMC zupełnie (ciemność).

Witam

Kazik pisze:...ale wciąż niepokoi mnie 6-klik zmieniający moc trybu. W prawdziwym użytkowaniu nie powinno się przypadkowo go uruchamiać, ale przy zabawach juz kilkukrotnie przypadkowo wszedłem w zmianę mocy

Też mi się to zdarzyło, jak wspomniałeś, w normalnym użytkowaniu jest nikła szansa na taki wypadek, ale przy zabawie i owszem...
Może w następnym driverku, zastosujesz odmienne podejście i da się zaimplementować rozpoznanie wielokliku od wielokrotnego kliku. Może czas będzie tu wyznacznikiem...
U siebie rozwiązałem to mierząc czas do pewnej granicy driver nie zmienia trybu, tylko czeka na następny klik, i tak do wykrycia odpowiednio długiego czasu (u mnie przerwy, tu może być świecenie) i dopiero wtedy reaguje na "polecenie". Zdaję sobie sprawę o odmiennej koncepcji sterowania, ale może warto by było rozpatrzyć taką możliwość w przyszłości.

greg pisze:Ja podstawiam z tabeli wartości PWM wyliczone wcześniej zgodnie z kwadratowym prawem ściemniania.

Też tak robię, właśnie ze względu na wspomniane zalety, miałem tylko na względzie oszczędność pamięci.


Pozdrawiam
PS: Jutro w pracy pomęczę go solidnie

Otóż właśnie jest zabezpieczenie przed przypadkowym przeprogramowaniem, a nawet i 2:
• driver informuje o wejściu w tryb programowania: LED miga 3-krotnie z częstotliwością 1Hz (w tym czasie można zrezygnować z programowania wyłączając latarkę) - czyli mamy 3 sekundy na rezygnację
• jeśli nie naciśniemy klawisza włącznika w czasie zmian jasności, cała sekwencja programowania "przejdzie" w ciągu około 60 sekund i tryb nie zostanie przeprogramowany

greg pisze:Dodatkowo, poniżej wypełnienia 6/255 ATtiny13 nie wysterowuje 8xAMC zupełnie (ciemność).

Ja mam w swoim sofcie 4,8,16,32,64,128 i 255/255 (do wyboru) i też się na to nadziałem.
W latarkach na 3xAMC (AK-47 przeprogramowany) i i 4xAMC (AK 101 przeprogramowany) PWM 4/255 działa bez problemów, nie działają niższe: 1 i 2/255.
Wczoraj robiłem dropa na 8xAMC pod XML-a i tryb 4/255, nie działa, jest ciemność, widać dopiero 8/255 (6/255 nie testowałem z braku czasu).
Nie mam niestety oscyloskopu by na to sensownie popatrzeć.
Greg - z tego by wynikało, że to ilość AMC określa na ile nisko z PWM można zejść, dobrze myślę ?

Odnośnie trybu 0,25% - nie jest to moonlight, ale jako niski low zdaje egzamin. Nie oślepia, nadaje się do zajrzenia do plecaka, szuflady, szafy etc. Potrafi też przyświecić na kilka metrów. Ale muszę go jeszcze potestować ze wzrokiem zaadaptowanym do ciemności.

fredek pisze: Greg - z tego by wynikało, że to ilość AMC określa na ile nisko z PWM można zejść, dobrze myślę ?

Tak, ponieważ zwyczajnie AMC mają jakąś pojemność na wejściu, a to wpływa na przebieg szybkiego PWM. Im ich więcej, tym silniej. Dla 8-10 x AMC i 9,3kHz nie da się zejść poniżej wypełnienia PWM 6/255 w tej konstrukcji.

Witam

greg pisze:

fredek pisze: Greg - z tego by wynikało, że to ilość AMC określa na ile nisko z PWM można zejść, dobrze myślę ?

Tak, ponieważ zwyczajnie AMC mają jakąś pojemność na wejściu, a to wpływa na przebieg szybkiego PWM. Im ich więcej, tym silniej. Dla 8-10 x AMC i 9,3kHz nie da się zejść poniżej wypełnienia PWM 6/255 w tej konstrukcji.

A próbował ktoś może dodać rezystor podciągający do plusa, sądzę że znacznie przyspieszył by ładowanie pojemności wejściowych, a z tego co pamiętam to porty w stanie niskim mogą otrzymać większy prąd niż w wysokim.
Jeśli chodzi o driverek, to poza wymienionymi, żadnych uwag nie mam.

Pozdrawiam