www.swiatelka.pl

df pisze: Ja tak liczę zarówno w górę jak i w dół - a dokładniej procek liczy.
Przydają się tu przesunięcia bitowe na rejestrach shr i shl
Aby wykładniczo przejść od 0 do 255 robię tak (w asm):
clr A ; zaczynam od zera

i w kolejnych krokach robię:
shl A,1
andi A,0b00000001

co mi daje w kolejnych iteracjach piękne sekwencje:
00000000
00000001
00000011
00000111
00001111
itd.

Spowrotem jest jeszcze łatwiej, bo zaczynam od 255 i przesuwam w prawo:
ser A ; A=255
i w iteracjach po prostu lecę:
shr A,1

A w bascomie będzie to pewnie tak:
A = 0
A = A*2+1 `co przy odrobinie szczęścia *2 zostanie skompilowane do shl (bo ten procesor mnożenia nie ma...)

Nie wiem, czy w drugą stronę przejdzie dzielenie w modulo 2, ale na pewno musi być w Bascomie odpowiednik przesunięcia bitowego w prawo (lub rotacji) bo w asm instrukcje takie procesor ten ma i do tego są one idealne.

Bascom ma instrukcję SHIFT (left / right) tyczącą zmiennych itp. więc też mogę łatwo zaimplementowć ten sposób. Do tej pory jednak nie miałem możliwości konfiguracju poziomów jasności a opierałem się na zaprogramownaiu z góry ustalonych, i dlatego mam cztery tryby ciągłe, aby łatwiej dobrać do warunków oświetleniowych, może w przyszłości

df pisze: Masz rację, to dobry pomysł, choć będzie nieładnie wahać się napięcie na CPU - zwłaszcza w górę, bo w dół wygładzi duży C. Z praktyki Atmelki wiele potrafią znieść i poza zapisami do EEPROMU oraz odczytami z ADC nie powinno być z nimi problemów.
Ja od pewnego czasu ustawiam na fuse bit`ach opcję resetu na burr-brown na najniższą wartość 1,8V (domyślnie jest off). Zauważyłem że gdy BB jest wyłączony i zasilanie spada poniżej 1,8V lub na zasilaniu są śmieci (przetwornice impulsowe troszkę jednak sieją) to procek potrafi się na granicy napięcia zawiesić. Ryzyko rośnie wraz ze wzrostem taktowania. Myślę, że BB to dobra alternatywa dla Watch-dog`a bo zabezpiecza program przed zejściem w obszar niepewności i o tyle fajna, że nie musisz zupełnie dotykać kodu.

A, z tym BB to nie wiedziałem, dobry pomysł.
U mnie operacje zapisu do Epromu obywają się po około 2s od zmiany, więc napięcie na procku jest już ustalone, co do ADC jeszcze nie miałem potrzeby stosować, dopiero jak przejdę na Li-Ion, będę musiał mierzyć napięcie aku.

Pyra pisze:Do tej pory jednak nie miałem możliwości konfiguracju poziomów jasności a opierałem się na zaprogramownaiu z góry ustalonych, i dlatego mam cztery tryby ciągłe, aby łatwiej dobrać do warunków oświetleniowych, może w przyszłości

Zaczniesz o tym myśleć szybciej niż ci się wydaje... ja też długo na swojej pierwszej wesji z predefiniowanymi trybami nie wytrzymałem - to naprawdę wciąga
A widzę, że masz zapał i doświadczenie, więc staram się ubiec Twoje pytania i coś doradzić, podsunąć jakiś pomysł, czy po prostu pokazać alternatywne rozwiązania.

Pyra pisze:U mnie operacje zapisu do Epromu obywają się po około 2s od zmiany, więc napięcie na procku jest już ustalone

A co jak wyłączysz latarkę lub dłużej "klikniesz" robiąc to na chwilę przed 2-gą sekudną, tuż przed zapisem? Ja się na to naciąłem... też wydawało mi się, że szanse są znikome, a do EEPROM`u poszły śmieci. Przy włączonym BB nie ma tego problemu, bo gdy napięcie spadnie poniżej dozwolonej (wybranej) wartości, to procek zatrzyma się i gdy napięcie wróci zrobi reset. Kolejna rzecz, to warto dbać o walidację danych zwłaszcza z EEPROMu - przykład, masz wyczyszczoną pamięć (lub poleciała zawartość EE) i masz FF-y. Ty robisz to dobrze, badasz zakresy i jak coś jest poza to podstawiasz default`a, ale wiele osób wpuszcza takie dane na kod, który głupieje i później godzinami zachodzą w głowę nie wiedząc co się w środku dzieje.

Być może są to rzeczy oczywiste i w testach, czy symulacjach zapewnie nie wyjdą, ale warto mieć je jednak na uwadze, bo prędzej, czy później zdarzy się coś, na czym program może się zupełnie nieoczekiwanie wysypać.

df pisze:

Pyra pisze:Do tej pory jednak nie miałem możliwości konfiguracju poziomów jasności a opierałem się na zaprogramownaiu z góry ustalonych, i dlatego mam cztery tryby ciągłe, aby łatwiej dobrać do warunków oświetleniowych, może w przyszłości

Zaczniesz o tym myśleć szybciej niż ci się wydaje... ja też długo na swojej pierwszej wesji z predefiniowanymi trybami nie wytrzymałem - to naprawdę wciąga
A widzę, że masz zapał i doświadczenie, więc staram się ubiec Twoje pytania i coś doradzić, podsunąć jakiś pomysł, czy po prostu pokazać alternatywne rozwiązania.

Dobry z psychologii jesteś
Właśnie od jakiegoś czasu myślę nad konfigurowalnym midem. Wyszedłem z założenia, że LOW i HI, w zasadzie będą nieruszane i tylko środek będzie można ustawić na poziomie użytkownika. Na razie jednak rozważam rozwiązanie "dwuklika", jak widzisz mój program jest inaczej rozwiązany i nie mam możliwości użycia timera, chcę to rowwiązać przerwaniami. Nie robiłem jeszcze prób, ale zastanawia mnie brak wyzwalania zboczem, a są tylko poziomami logicznymi, czy program nie będzie się zapętlał?

Choć z drugiej strony, kilka osób, którym sie pochwaliłem latarką, i tak nie mogła załapać "o co chodzi z tą zmianą trybów i po co to" ; więc chyba powstaną dwie (albo i więcej) wersji softu.
Na razie jednak trwają przygotowania do zimy

df pisze:

Pyra pisze:U mnie operacje zapisu do Epromu obywają się po około 2s od zmiany, więc napięcie na procku jest już ustalone

A co jak wyłączysz latarkę lub dłużej "klikniesz" robiąc to na chwilę przed 2-gą sekudną, tuż przed zapisem? Ja się na to naciąłem... też wydawało mi się, że szanse są znikome, a do EEPROM`u poszły śmieci. Przy włączonym BB nie ma tego problemu, bo gdy napięcie spadnie poniżej dozwolonej (wybranej) wartości, to procek zatrzyma się i gdy napięcie wróci zrobi reset. Kolejna rzecz, to warto dbać o walidację danych zwłaszcza z EEPROMu - przykład, masz wyczyszczoną pamięć (lub poleciała zawartość EE) i masz FF-y.

U mnie każdy klik wychodzi z pętli odmierzania czasu do zapisu, więc na razie się tym nie przejmowałem.
Z drugiej strony program "poszedł w świat" więc inni mogą mieć to "szczęście"

df pisze: Ty robisz to dobrze, badasz zakresy i jak coś jest poza to podstawiasz default`a, ale wiele osób wpuszcza takie dane na kod, który głupieje i później godzinami zachodzą w głowę nie wiedząc co się w środku dzieje.

Być może są to rzeczy oczywiste i w testach, czy symulacjach zapewnie nie wyjdą, ale warto mieć je jednak na uwadze, bo prędzej, czy później zdarzy się coś, na czym program może się zupełnie nieoczekiwanie wysypać.

A no właśnie, na razie zapisuję tylko nr trybu i sprawdzam czy zawartość pamięci mieści się w zakresie, a program podstawia odpowiednie wartości PWM. Zrobiłem tak, gdyż chciałem wyeleminować głupienie procka przy pierwszym starcie po zaprogramowaniu, gdy komórki mają zawartość FF.
No tak ale w momencie przejścia na konfigurowalne tryby, stanie się to nieodzowne, gdyż nie będę mógł juz sprawdzić zakresu danych, bo każda wrtość będzie z zakresu 0 - 255.

Pozdrawiam

Pyra pisze:Na razie jednak rozważam rozwiązanie "dwuklika", jak widzisz mój program jest inaczej rozwiązany i nie mam możliwości użycia timera, chcę to rowwiązać przerwaniami.

Można i tak i tak.
Ja przyjąłem takie podejście: mam timer który jednocześnie robi sprzętowego PWM`a oraz generuje na overflow przerwanie, w procedurze którego liczę sobie czas.
W głównej części programu obsługuję przyciski zliczając "asynchronicznie" wyliczany przez timer czas oraz licząc czas jak i liczby klików następujących po sobie (w oknie 1 sek).
Dzięki temu mogę rozróżnić 1,2,3... itd. n-kliki.

Inny sposób, tak jak nadmieniłeś może polegać na odwrotnym podejściu - to przycisk generuje przerwanie i w jego procedurze robisz różne związane ze sterowaniem czynności. Ale dalej potrzebujesz mieć podstawę lub przynajmniej licznik czasu (do liczenia wieloklików) - a do tego znów najlepszy jest timer, bo wstawiając waitms lub robiąc inne "sztuczki" ciężko Ci będzie zapanować nad kodem.

W wyższych ATtiny są 2 timerki i jest łatwiej, bo jeden liczy czas lub robi jakieś ważne czynności w czasie, a drugi śmiga generując Fast-PWM.
Ale jak się dobrze przemyśli to da się to samo uzyskać na jednym timerze, choć trzeba się trochę postarać (dla szybkich PWM nie możesz za bardzo rozbudowywać procedury obsługi przerwania, bo się nie zmieścisz z ich obsługą w cyklach procesora i nie dość że będziesz gubił przerwania, to jeszcze zagłodzisz główną część kodu, która będzie wykonywać się w skrajnym przypadku 1 instrukcję na cykl timera skacząc co chwila do proc. obsł. przerwania. I tu, zwłaszcza w takich krytycznych fragmentach jest siła assemblera w stosunku do innych języków wysokiego poziomu, za co go bardzo cenię.

Pyra pisze:Nie robiłem jeszcze prób, ale zastanawia mnie brak wyzwalania zboczem, a są tylko poziomami logicznymi, czy program nie będzie się zapętlał?

Jak najbardziej _można_ wyzwalać przerwania z portu zarówno stanem (L lub H) jak i zboczem (R lub F). Jest tylko jedno ograniczenie, gdy zbocza nie działają, ale ma to miejsce w głębokim uśpieniu - w power-down gdy budzisz procesor sygnałem INT0.
Ale to że wówczas w grę wchodzi tylko stan jest poniekąd zrozumiałe, gdyż w tym trybie zatrzymany jest zegar. A zbocza tu wykrywa się nie przejściem z niskiego w wysoki lub odwrotnie, ale zmianą stanu w kolejnych cyklach zegarowych (zegar portów I/O) - dobrze to widać na diagramach w PDF`ie, że zatrzaskiwany jest stan i w każdym cylku porównywany stan portu z jego wartością (zatrzaśniętą w poprzednim cyklu - coś jak J-K master-slave).

Pozdrawiam,

df pisze: Ja przyjąłem takie podejście: mam timer który jednocześnie robi sprzętowego PWM`a oraz generuje na overflow przerwanie, w procedurze którego liczę sobie czas.
W głównej części programu obsługuję przyciski zliczając "asynchronicznie" wyliczany przez timer czas oraz licząc czas jak i liczby klików następujących po sobie (w oknie 1 sek).
Dzięki temu mogę rozróżnić 1,2,3... itd. n-kliki.

Jeśli dobrze zrozumiałem...
Jako zegar pracuje przepełnienie sprzętowego PWM, jego impulsy są cały czas zliczane. klik powoduje zczytanie wartości "timera" i dalej mierzy czas klika. Klik powoduje ustawienie jakiejś zmiennej, jeśli natomiast przed upływem sekundy pojawi się następny klik, zmienna jest zwiększana o jeden i proces odliczania sekundy jest wznawiany itd. Jeśli po upływie sekundy nie nastąpi kolejny klik, to odczytywana jest zmienna zawierająca liczbę klików, interpretowana i zerowana.

Ja przyjąłem też w jednej z wersji podobne rozwiązanie, z tym, że nie wykorzystuję timera a generuję przerwy (no cóż nie ten poziom znajomości programowania )
Po wykryciu stanu na porcie program skacze do procedury obsługi, tam sprawdza minimalny czas klika, jeśli ok, zwiększa zmienną KLIk o 1 i skacze do pętli odliczającej 1s i sprawdzającej stan portu. Przy ponownej zmianie stanu portu, zmienna KLIK jest ponownie zwiększana o 1 i ponownie wchodzi do pętli. Jeśli sekunda minie, zawartość zmiennej KLIk jest interpretowana jako skok do określonej części programu i zerowana.
Z tym, że na razie ten program rodzi się w głowie
Z przerwaniami miało być podobnie, po prostu odpadła by część sprawdzająca stan portu w różnych miejscach programu.

df pisze:Inny sposób, tak jak nadmieniłeś może polegać na odwrotnym podejściu - to przycisk generuje przerwanie i w jego procedurze robisz różne związane ze sterowaniem czynności. Ale dalej potrzebujesz mieć podstawę lub przynajmniej licznik czasu (do liczenia wieloklików) - a do tego znów najlepszy jest timer, bo wstawiając waitms lub robiąc inne "sztuczki" ciężko Ci będzie zapanować nad kodem.

A no własnie i tu jest problem, bo program się rozrasta....

df pisze:W wyższych ATtiny są 2 timerki i jest łatwiej, bo jeden liczy czas lub robi jakieś ważne czynności w czasie, a drugi śmiga generując Fast-PWM.
Ale jak się dobrze przemyśli to da się to samo uzyskać na jednym timerze, choć trzeba się trochę postarać (dla szybkich PWM nie możesz za bardzo rozbudowywać procedury obsługi przerwania, bo się nie zmieścisz z ich obsługą w cyklach procesora i nie dość że będziesz gubił przerwania, to jeszcze zagłodzisz główną część kodu, która będzie wykonywać się w skrajnym przypadku 1 instrukcję na cykl timera skacząc co chwila do proc. obsł. przerwania. I tu, zwłaszcza w takich krytycznych fragmentach jest siła assemblera w stosunku do innych języków wysokiego poziomu, za co go bardzo cenię.

Tylko, że w assemblerze to ja pisałem programy 20 lat temu na procesor Z80 Pamiętasz gdzie on był? Teraz tylko BASCOM

df pisze: Jak najbardziej _można_ wyzwalać przerwania z portu zarówno stanem (L lub H) jak i zboczem (R lub F). A zbocza tu wykrywa się nie przejściem z niskiego w wysoki lub odwrotnie, ale zmianą stanu w kolejnych cyklach zegarowych (zegar portów I/O) - dobrze to widać na diagramach w PDF`ie, że zatrzaskiwany jest stan i w każdym cylku porównywany stan portu z jego wartością (zatrzaśniętą w poprzednim cyklu - coś jak J-K master-slave).

A ja gdzieś wyczytałem, że ATTiny ma przerwania wyzwalane tylko poziomami i program obsługi w skrajnych wypadkach może się zapętlać, dlatego z rezerwą podchodziłem do tego rozwiązania


Pozdrawiam

Pyra pisze:Jeśli dobrze zrozumiałem...
Jako zegar pracuje przepełnienie sprzętowego PWM, jego impulsy są cały czas zliczane.

Dokładnie tak. Procedurę obsługi przerwania mam podpiętą pod przepełnienie timera i tam inkrementuję sobie liczniki przy każdym pełnym cyklu timera.
I to one przy dobrze przyjętych podziałach są moim "zegarem czasu rzeczywistego" z wystarczającą rozdzielczością.

Pyra pisze:Klik powoduje zczytanie wartości "timera" i dalej mierzy czas klika.

Robię to prościej - pierwszy klik zeruje liczniki czasu - dzięki temu nie muszę odejmować

Pyra pisze:Klik powoduje ustawienie jakiejś zmiennej, jeśli natomiast przed upływem sekundy pojawi się następny klik, zmienna jest zwiększana o jeden i proces odliczania sekundy jest wznawiany itd.

Dokładnie tak - liczę czas od ostatniego kliku (nie ważne, czy pojedynczego, czy wielokrotnego), a na drugiej zmiennej zliczam liczbę klików złapanych w oknie czasowym <1s (by grupować wielokliki). Przy użyciu tego samego licznika czasu realizuję zabezpieczenie przed odbiciami styków. Aby stan został uznany za stabilny musi trwać przez N cykli timera (u mnie przyjąłem ok. 1/64s)

Pyra pisze:Jeśli po upływie sekundy nie nastąpi kolejny klik, to odczytywana jest zmienna zawierająca liczbę klików, interpretowana i zerowana.

Można też tak, ale Twoje rozwiązanie będzie miało niezbyt szczęśliwą cechę sekundowego opóźnienia - cokolwiek byś nie kliknął, to rezultat pojawi się po 1s.
Jest to intrygujące. Ja robię tak, że na bieżąco wykonuje czynności (sterowanie trybami) na podstawie bieżącej wiedzy.
Pojawi się 1-wszy klik, to od razu (gdy przejdzie sito na odbiciach styków) wykonuję zmianę jakby to był pojedynczy klik, gdy w czasie (np.1 sek) pojawi się drugi klik, to wykonuję procedurę obsługi 2-klika itd. Dzięki temu podejściu (nieco bardziej złożonemu) reakcja mojego sterownika jest natychmiastowa.

Pyra pisze:Ja przyjąłem też w jednej z wersji podobne rozwiązanie, z tym, że nie wykorzystuję timera a generuję przerwy (no cóż nie ten poziom znajomości programowania )
Po wykryciu stanu na porcie program skacze do procedury obsługi, tam sprawdza minimalny czas klika, jeśli ok, zwiększa zmienną KLIk o 1 i skacze do pętli odliczającej 1s i sprawdzającej stan portu. Przy ponownej zmianie stanu portu, zmienna KLIK jest ponownie zwiększana o 1 i ponownie wchodzi do pętli. Jeśli sekunda minie, zawartość zmiennej KLIk jest interpretowana jako skok do określonej części programu i zerowana.

Takie rozwiązanie też działa, z pewnością jest dużo prostsze w realizacji, choć prawdopodobnie zajmuje więcej miejsca w kodzie.

Pyra pisze:Z przerwaniami miało być podobnie, po prostu odpadła by część sprawdzająca stan portu w różnych miejscach programu.

Wyniesienie "przycisku" (detekcji zaniku zasilania) na przerwanie też jest dobrym pomysłem - zyskujesz na czystości kodu i jednym miejscu obsługi.
W procedurze przerawnia robisz całą implementację wieloklików z odbiciami itd. i wystawiasz na jakiś zmiennych same stany typu (0-brak kliku, 1-klik,... 3-kliki itd.) które w głównym kodzie interpretujesz już synchricznie odczytując kody z w/w zmiennej.

Pyra pisze:i tu jest problem, bo program się rozrasta....

Dlatego też ja piszę w asm... (nie tylko szybciej pracuje kod, ale i mniej miejsca zajmuje - a poza tym wiem, co procesor w każdym takcie robi)

Pyra pisze:Tylko, że w assemblerze to ja pisałem programy 20 lat temu na procesor Z80

Ja też... i 20 lat temu i na Z80
Chwilę później przesiadłem się na rewelacyjną jak dla mnie serię 8051 - to był niesamowity przeskok, dużo uniwersalnych rejestrów, peryferia, wersje z EEPROMem w środku (a później z Flashem), alternatywnie na zewnątrz też jednym ruchem można było wyprowadzić współdzieloną magistralę i połówki 8-bitowe adresu zatrzaskiwało by uzyskać 16 bitów adresu do zewnętrznej pamięci kodu itd.
A później przeszedłem z asm na 80x86 - ale tam już nie było tak fajnie jak w małych RISC`ach... mało rejestrów, silna specjalizacja rejestrów (mała uniwersalność) - bez stosu ciężko jest cokolwiek zrobić. A w takim ATtiny to wszystko mam na rejestrach, które traktuje jak zwykłe zmienne - stosu praktycznie nie używam (poza zachowywaniem stanu rejestru statusowego w czasie proc.obsł.przerwania).
Później 10 lat przerwy z MCU i radosny come-back z ATtiny

Dziś jak patrzę jak wygląda tworzenie oprogramowania na dzisiejsze MCU, czego to one w środku nie mają itd. to łezka się w oku kręci. Ile razy latałem do kasownika UV kasować EPROMy, bo coś nie zadziałało tak jak powinno ile godzin spędzałem na symulatorach, by się upewnić, że działa jak należy itd...
Dziś ładuję w 2 sek. kod do układu na płytce docelowej i klikam na docelowym układzie - nieporównywalnie szybciej i łatwiej. A i oprogramowanie o niebo lepsze (korzystam z darmowego AVR studio).

Pyra pisze:Pamiętasz gdzie on był? Teraz tylko BASCOM

No pewnie... ZX-81, ZX-Spectrum, jakieś Atari, Amstrady itd. generalnie pierwsze 8-miobitowce.
8051 zaś popularne są w sterownikach klawiatór PC-towych - robią skanowanie klawiszy, komunikację i proste funkcje (pamięć caps/scroll/num-locków, auto-repetycje itd.)
Z "większych" RISC`ów to miałem okazję bawić się Sparc`ami - też fajnie to wyglądało - znacznie prościej i szybciej niż na x86.

Pyra pisze:

df pisze: Jak najbardziej _można_ wyzwalać przerwania z portu zarówno stanem (L lub H) jak i zboczem (R lub F). A zbocza tu wykrywa się nie przejściem z niskiego w wysoki lub odwrotnie, ale zmianą stanu w kolejnych cyklach zegarowych (zegar portów I/O) - dobrze to widać na diagramach w PDF`ie, że zatrzaskiwany jest stan i w każdym cylku porównywany stan portu z jego wartością (zatrzaśniętą w poprzednim cyklu - coś jak J-K master-slave).

A ja gdzieś wyczytałem, że ATTiny ma przerwania wyzwalane tylko poziomami i program obsługi w skrajnych wypadkach może się zapętlać, dlatego z rezerwą podchodziłem do tego rozwiązania

Być może chodziło o budzenie z power-down.

Zobacz (cytuję za: http://atmel.com/dyn/resources/prod_doc ... oc8126.pdf)

9.2 External Interrupts
The INT0 interrupts can be triggered by a falling or rising edge or a low level.

9.3.1 MCUCR &#8211; MCU Control Register
Table 9-2. Interrupt 0 Sense Control

ISC01 ISC00 Description
0 0 The low level of INT0 generates an interrupt request.
0 1 Any logical change on INT0 generates an interrupt request.
1 0 The falling edge of INT0 generates an interrupt request.
1 1 The rising edge of INT0 generates an interrupt request.

Zgadza się?

Natomiast tak jak napisałem z uwagi na brak zegara w power-down detekcja jest na stanach:

7.1 Sleep Modes
Note: 1. For INT0, only level interrupt.

7.1.3 Power-down Mode
... an external level interrupt on INT0, or a pin change interrupt can wake up the MCU.
This sleep mode halts all generated clocks, allowing operation of asynchronous modules only.

Natomiast sam sposób detekcji zmiany stanu (detekcja zboczy R / F) ładnie ujęta jest na diagramie np.

9.2.2 Pin Change Interrupt Timing

Pozdrawiam,

df pisze:

Pyra pisze:Pamiętasz gdzie on [Z80] był?

No pewnie... ZX-81, ZX-Spectrum, jakieś Atari, Amstrady itd. generalnie pierwsze 8-miobitowce.

W Atari był 6510 (bliźniak 6502 z Commodore).

A najuniwersalniejszy procesor z jakim się zetknąłem, w praktyce w pełni ortogonalny, był w PDP 11. Myślę, że byś pokochał ten zestaw rozkazów

Ech, wspomnienia...

Pozdrawiam

[back to read only mode]

df pisze:

Pyra pisze:Klik powoduje zczytanie wartości "timera" i dalej mierzy czas klika.

Robię to prościej - pierwszy klik zeruje liczniki czasu - dzięki temu nie muszę odejmować

No tak o tym nie pomyślałem a to faktycznie dużo prostrze

df pisze:

Pyra pisze:Jeśli po upływie sekundy nie nastąpi kolejny klik, to odczytywana jest zmienna zawierająca liczbę klików, interpretowana i zerowana.

Można też tak, ale Twoje rozwiązanie będzie miało niezbyt szczęśliwą cechę sekundowego opóźnienia - cokolwiek byś nie kliknął, to rezultat pojawi się po 1s.
Jest to intrygujące. Ja robię tak, że na bieżąco wykonuje czynności (sterowanie trybami) na podstawie bieżącej wiedzy.
Pojawi się 1-wszy klik, to od razu (gdy przejdzie sito na odbiciach styków) wykonuję zmianę jakby to był pojedynczy klik, gdy w czasie (np.1 sek) pojawi się drugi klik, to wykonuję procedurę obsługi 2-klika itd. Dzięki temu podejściu (nieco bardziej złożonemu) reakcja mojego sterownika jest natychmiastowa.

Hmmm ja troszkę inaczej zrozumiałem "okno czasowe" co prawda miałem w planie zmniejszyć je do 0,5 - 0,25s i wtedy opóźnienie nie było by tak widoczne, ale Twój sposób jest widzę bardziej optymalny i dużo szybszy.

df pisze:

Pyra pisze:i tu jest problem, bo program się rozrasta....

Dlatego też ja piszę w asm... (nie tylko szybciej pracuje kod, ale i mniej miejsca zajmuje - a poza tym wiem, co procesor w każdym takcie robi)

Wiem... będę musiał przejść na assemblera, ale "mało casu kruca bomba" A jeszcze mam do skończenia odrestaurowywanie obudowy radia Philips z 1938r, następne auto z silnikiem V12 czeka na instalację wtrysku, wzmacniacz lampowy na obudowę...... A wszystko dla kumpli (no wzmacniacz mój) więc "po kosztach"

df pisze: A w takim ATtiny to wszystko mam na rejestrach, które traktuje jak zwykłe zmienne - stosu praktycznie nie używam (poza zachowywaniem stanu rejestru statusowego w czasie proc.obsł.przerwania).

Też bardzo lubię Atmelki, zrobiłem kilka konstrukcji na ATmega8 (termostat do akwarium, zegar, miernik do zasilacza...). Są bardzo elestyczne technologicznie, no i mozliwość oddzielnej konfiguracji każdego pinu w porcie. I tylko żona na mnie patrzy z politowaniem, jak wykazuję radość małego dziecka, kiedy mi w końcu PWM zacznie działać i dioda nie mryga tylko pulsuje albo impulsator zacznie rozpoznawać kierunki obrotu.

df pisze: A i oprogramowanie o niebo lepsze (korzystam z darmowego AVR studio).

Ja mam BASCOM-AVR 4kB kodu mi na razie w zupełności wystaczały

Bardzo dziękuję za cenne informacje.

No to dziś włąśnie chyba zakończyłem prace nad przetwornicą. Ostateczny schemat wygląda jak poniżej:


Wartości elementów:
R1 = 0,2&#937;
R2 = 5,6k&#937;
R3, R4, R4a=10k&#937;
D2 - 1N5819
D3,D4-1N4148

Przy ustawieniu dwóch skrajnych zakresów PWM otrzymałem prądy w LEDa:
PWM = 1 I = 1,06A
PWM = 255 I = 0,0007A = 0,7mA

Można powiedzieć, że osiągnąłem pełen zakres regulacji.
Diody D3 i D4 ograniczają napięcie PWM do wartości 1V, jest to związane z bardzo małą wartością prądu diod. W takim więc wypadku wartośc dzielnika napięcia R2 / (R3+R4+R4a) wynisi 1/5, bo potrzebujemy 0,2V dla wejścia FB. Niestety elementy w układzie praktycznym wymagały korekty, dla uzyskania minimalnego prądu LEDa na poziomie poniżej 1mA.

Minimalne napięcie zasilania uC podczas pracy wynosi 2,27V; tak więc do granicy 1,8V mamy spory zapas. Myślę, że gdyby nie schodzić z minimalnym prądem LEDa poniżej 2mA, można by zastosować jako D2 zwykłą diodę impulsową jak np: 1N4148 a uC i tak miał by minimalne napięcie na poziomie 1,9V.

Wahnięcie prądu LEDa przy zmianie trybów, które widać było jeszcze na ostatnim oscylogramie, zniknęło prawie całkowicie. W normalnym trybie pracy jest niezauważalne, widać dopiero po powiększeniu fragmentu wykresu.

Układ działa więc zadowalająco.
Schemat w trakcie prac został rozbudowany o kilka diod i rezystarów, w stosunku do wersji podstawowej, lecz zyskaliśmy na tym pełen zakres napięć zasilania oraz możliwośc łatwego zaadaptowania do step-up'a.
Podstawową zaletą układu jest jednak zasilanie LEDa naprawdę stałym prądem zyskując możliwość wykorzystania wszelkich możliwości oferowanych prze uC jako układ sterujący, niestety okupioną rozbudowanym układem elektronicznym. Jeśłi jednak dysponujemy dużą ilością miejsca, to układ spełnia swoje zadanie bardzo dobrze.

Pozdrawiam

Jako wieloletni programista (zaczynałem od 8051 w technikum ) czytam Wasze posty z wielką uwagą. I dużą przyjemnością.

Pyra pisze:Też bardzo lubię Atmelki, zrobiłem kilka konstrukcji na ATmega8 (termostat do akwarium, zegar, miernik do zasilacza...). Są bardzo elestyczne technologicznie, no i mozliwość oddzielnej konfiguracji każdego pinu w porcie. I tylko żona na mnie patrzy z politowaniem, jak wykazuję radość małego dziecka, kiedy mi w końcu PWM zacznie działać i dioda nie mryga tylko pulsuje albo impulsator zacznie rozpoznawać kierunki obrotu.

Mnie się udało inaczej. Na ATmega32 zrobiłem 10-kanałowy regulator temperatury do kalandra i sterownik maszyny do cięcia papieru. Na ATmega8 wyświetlacze do regulatora obrotów silnika. I parę innych drobnostek. I jak zaczęły dudki za projekty spływać, koleżanka małżonka przestała się podśmiewywać, a zaczęła dopingować

Powodzenia, panowie!
(powracam do trybu podglądania)
M.

Jest opcja żeby "oszukiwać" wejście FB w przetwornicach z rezystorem po stronie dodatniej?
Np w takiej aplikacji? http://powerelectronics.com/site-files/ ... 1PET08.pdf
Układ MAX16819 wydaje się mi bardzo fajny i nieskomplikowany, fakt że można sterować go PWM-em nawet do 20kHz ale interesuje mnie prawdziwy CC, chociażby na sprawność ledów.

Witam
Na pewno się da, jednak układ już nie będzie taki prosty. Przede wszystkim, trzeba by wymyślić, jak podnieść potencjał sterowania do plusa zasilania przetwornicy, chyba żeby to zrobić na pływającej masie...

Pozdrawiam