Sterownik driver LED 2,8-4,5V 2,8A programowalny
marmez, zgadzam się i się nie zgadzam. Pełna zgoda, że za zbyt mocne strobo powinny być ostrzeżenia i kary. Jak ktoś tego nie rozumie, to faktycznie jest problem.
Natomiast stroboskop 3Hz jest o tyle fajny, że można być widocznym i wyróżnionym przy znacznie mniejszej mocy, spora oszczędność energii. W trójmieście bardzo popularna sprawa (tu na szczęście faktycznie niewiele osób używa tak mocnego oświetlenia).
Nie uważam, że stroboskopy powinny być trudno dostępne, ale tak prosta czynność, jak sprawdzenie na sobie oddziaływania większej mocy powinno być odruchem.
Natomiast stroboskop 3Hz jest o tyle fajny, że można być widocznym i wyróżnionym przy znacznie mniejszej mocy, spora oszczędność energii. W trójmieście bardzo popularna sprawa (tu na szczęście faktycznie niewiele osób używa tak mocnego oświetlenia).
Nie uważam, że stroboskopy powinny być trudno dostępne, ale tak prosta czynność, jak sprawdzenie na sobie oddziaływania większej mocy powinno być odruchem.
witam
xander122
ja mam grega v 1.3
w instrukcji jest napisane
cytuje z opisu grega
[16-klik] Programming enable - aktywacja/deaktywacja opcji 6..8-kliku
• włączasz latarkę
• czekasz 2 sekundy (lub dłużej)
• wykonujesz 16-klik
• LED miga 6-krotnie (przed aktywacją) lub 3-krotnie (przed dezaktywacją) z częstotliwością 1Hz
(w tym czasie można zrezygnować z wyboru wyłączając latarkę)
• czekasz 2 sekundy po ostatnim błysku (lub dłużej)
• powyższa czynność zmienia stan opcji "programming enable" na przeciwną (czyli przy włączonej wyłącza i odwrotnie)
u mnie działa
pozdr
xander122
ja mam grega v 1.3
w instrukcji jest napisane
cytuje z opisu grega
[16-klik] Programming enable - aktywacja/deaktywacja opcji 6..8-kliku
• włączasz latarkę
• czekasz 2 sekundy (lub dłużej)
• wykonujesz 16-klik
• LED miga 6-krotnie (przed aktywacją) lub 3-krotnie (przed dezaktywacją) z częstotliwością 1Hz
(w tym czasie można zrezygnować z wyboru wyłączając latarkę)
• czekasz 2 sekundy po ostatnim błysku (lub dłużej)
• powyższa czynność zmienia stan opcji "programming enable" na przeciwną (czyli przy włączonej wyłącza i odwrotnie)
u mnie działa
pozdr
Tak, info z danymi technicznymi w linku poniżej (stopka). Premiera drivera extended v2.0 koło 7 kwietnia.
Ostatnio zmieniony niedziela 30 mar 2014, 17:49 przez greg, łącznie zmieniany 2 razy.
Sterownik extended v3.5 HE <klik>
Instrukcje sterowników w PDF <klik>
kontakt: info(at)krypton(dot)pl
(podstawić @ i . w stosowne miejsca)
Instrukcje sterowników w PDF <klik>
kontakt: info(at)krypton(dot)pl
(podstawić @ i . w stosowne miejsca)
Aktualnie dostępna jest kolejna wersja drivera podstawowego, czyli standard v1.5.
Zmiany w opcjach oprogramowania w porównaniu z wersją standard 1.4
+ sterowanie up-down
+ stroboskop dostępny po 3. kilkach
+ reset do ustawień fabrycznych
+ fabrycznie aktywna blokada funkcji programowania (wyłączyć przed programowaniem)
Uwaga odnośnie klików: w tym driverze istotny jest czas przerwy w zasilaniu. Inaczej niż w poprzednich modelach. Kliki w tempie 0,5s czyli w miarę szybkie, dodatkowo istotny jest czas braku prądu - ten ma być krótki, krótkie "czarne" mignięcie LED. Po czasie 0,5s braku prądu moduł Brown-out Detector jest resetowany - driver traktuje to jako wyłączenie latarki (pełny reset licznika klików). Na PCB nie ma żadnych dodatkowych elementów (kondensator podtrzymujący), wszelkie funkcje realizowane są na fabrycznym driverze programowo.
Zmiany w opcjach oprogramowania w porównaniu z wersją standard 1.4
+ sterowanie up-down
+ stroboskop dostępny po 3. kilkach
+ reset do ustawień fabrycznych
+ fabrycznie aktywna blokada funkcji programowania (wyłączyć przed programowaniem)
Uwaga odnośnie klików: w tym driverze istotny jest czas przerwy w zasilaniu. Inaczej niż w poprzednich modelach. Kliki w tempie 0,5s czyli w miarę szybkie, dodatkowo istotny jest czas braku prądu - ten ma być krótki, krótkie "czarne" mignięcie LED. Po czasie 0,5s braku prądu moduł Brown-out Detector jest resetowany - driver traktuje to jako wyłączenie latarki (pełny reset licznika klików). Na PCB nie ma żadnych dodatkowych elementów (kondensator podtrzymujący), wszelkie funkcje realizowane są na fabrycznym driverze programowo.
Sterownik extended v3.5 HE <klik>
Instrukcje sterowników w PDF <klik>
kontakt: info(at)krypton(dot)pl
(podstawić @ i . w stosowne miejsca)
Instrukcje sterowników w PDF <klik>
kontakt: info(at)krypton(dot)pl
(podstawić @ i . w stosowne miejsca)
greg, jak rozwiązałeś wyłączenie BOD podczas uśpienia procka? Mam mały problem z tym
Chyba, że rozumuje w złym kierunku...
Oczywiście jeśli to zawodowa tajemnica to rozumiem.
Chyba, że rozumuje w złym kierunku...
Oczywiście jeśli to zawodowa tajemnica to rozumiem.
Moje sterowniki:
AHE+ v1
KHE
v201 / v211
AHE+ v1
KHE
v201 / v211
Generalnie przechowuję zmienne w sekcji .noinit, czyli obszarze pamięci, który nie jest inicjowany po podniesieniu się z Brown-out. W przypadku driverów typu 105C i podobnych masz około 0,5s czasu po zaniku zasilania na ponowny rozruch bez utraty danych. Niestety rezystory dzielnika szybko rozładowują kondensator na zasilaniu, gdyby nie to, procek może przechowywać dane nawet do kilkudziesięciu sekund, a nawet kilku minut (na standardowym kondensatorze filtrującym Vcc).
Jest to okrutnie wygodne, gdyż zwyczajnie nie używasz wcale EEPROM. Po prostu zmienne w SRAM masz zachowane, o ile zanik zasilania nie jest większy od 0,5s.
Żaden kondensator dodatkowy nie jest tu potrzebny. BOD musi być aktywny. Polecam metodę kolegom driverowym dłubaczom. Zapewniam, że wiele zmieni w Waszym podejściu do programowania ATtiny
Jest to okrutnie wygodne, gdyż zwyczajnie nie używasz wcale EEPROM. Po prostu zmienne w SRAM masz zachowane, o ile zanik zasilania nie jest większy od 0,5s.
Żaden kondensator dodatkowy nie jest tu potrzebny. BOD musi być aktywny. Polecam metodę kolegom driverowym dłubaczom. Zapewniam, że wiele zmieni w Waszym podejściu do programowania ATtiny
Sterownik extended v3.5 HE <klik>
Instrukcje sterowników w PDF <klik>
kontakt: info(at)krypton(dot)pl
(podstawić @ i . w stosowne miejsca)
Instrukcje sterowników w PDF <klik>
kontakt: info(at)krypton(dot)pl
(podstawić @ i . w stosowne miejsca)
Witam
Pozdrawiam
Oj trzeba chyba będzie zmienić podejście do driverka, ale na razie mam padnięty klipsgreg pisze:Generalnie przechowuję zmienne w sekcji .noinit,
Pozdrawiam
Izali miecz godniejszy niżli topór w boju?
Piszmy po polsku, wszak jesteśmy Polakami.
Piszmy po polsku, wszak jesteśmy Polakami.
greg pisze:Generalnie przechowuję zmienne w sekcji .noinit, czyli obszarze pamięci, który nie jest inicjowany po podniesieniu się z Brown-out.
Czyli, jak dobrze rozumiem, po pierwszym odpaleniu nasze zmienne mają wartość 0 (ew FF lub losowe) ale zapisując "poprawne" wartości i po wystąpieniu resetu z układu brown-out nadal są one zachowane (o ile są w sekcji .noinit). Znikają dopiero, gdy napięcie spadnie jeszcze niżej (~1-1,4V) niż te aktywujące reset z brown-out'a (~1,8V)?greg pisze:Po prostu zmienne w SRAM masz zachowane, o ile zanik zasilania nie jest większy od 0,5s.
ElSor, ja tak to właśnie rozumie. Zaraz biorę się za programowanie
Moje sterowniki:
AHE+ v1
KHE
v201 / v211
AHE+ v1
KHE
v201 / v211
Jestem pod wrażeniem
To działa
Do tego ponad 100 bajtów kodu zaoszczędzonego
Greg od początku do końca to Twój pomysł?
Jeśli tak to chylę czoła
Teraz w prostych driverach bez pamięci trybu w ogóle można sobie odpuścić eeprom
sorki za post pod postem..
To działa
Do tego ponad 100 bajtów kodu zaoszczędzonego
Greg od początku do końca to Twój pomysł?
Jeśli tak to chylę czoła
Teraz w prostych driverach bez pamięci trybu w ogóle można sobie odpuścić eeprom
sorki za post pod postem..
Moje sterowniki:
AHE+ v1
KHE
v201 / v211
AHE+ v1
KHE
v201 / v211