Stroboskop na ATmega16 z regulowanymi parametrami błysków wyposażonym w XOP-15

Witam Szanownych Kolegów.

Chciałbym zaprezentować moją konstrukcję stroboskopu opartego o mikroprocesor ATmega16 i układ detekcji zera sinusoidy sieciowej.

Mikroprocesor steruje impulsem wyzwalającym powstającym od trafo wysokonapięciowego.
Docelowo powinien realizować obsługę przycisków sterujących częstotliwością i jasnością świecenia ksenonowej lampy wyładowczej o mocy 1500W.
Lampa ta jest zasilana poprzez diody prostownicze napięciem sieciowym, a sterowanie jasnością odbywa się za pomocą przesunięcia fazowego napięcia wyzwalającego względem dodatniej połówki napięcia sieci (w maksimum sinusoidy wybija bezpieczniki).

Mam jeszcze problemy ze zrobieniem optymalnego programu na mikroprocesor.
Programuję w Codevision AVR poprzez programator firmy telwis.com.
Nie mam wyprowadzonej końcówki złącza ISP na płytce, po prostu wyciągam procesor z podstawki i umieszczam go w programatorze.
Oczywiście bardziej wygodne jest mieć to złącze.
Jestem początkującym elektronikiem i radzę każdemu początkującemu,
nie popełniajcie tych błędów, co ja.

Na razie opiszę to, co udało mi się zrobić, jeśli chodzi o software:
1. Nie udało mi się wymyślić na początku, żeby użyć ATtiny.
2. Zaimplementowałem obsługę przerwania od timera pracującego w trybie CTC.
3. Zainicjowałem timer wpisując konkretne wartości w jego rejestry sterujące.
4. Odblokowałem przerwania.
5. Udało mi się dokładnie synchronizować impuls wyzwalający poprzez odmierzanie określonego czasu, jeśli detektor wykrył "zero".
Robi to instrukcja w programie głównym "if".

Przy tym punkcie taka rada dla tych, którzy będą starać się zrobić coś podobnego:
Najlepiej użyć do takich rzeczy przerwań zewnętrznych od zmiany stanu portu,
aby nie zajmować czasu procesora ciągłym sprawdzaniem warunku if.

Ja natomiast przy projektowaniu nie wziąłem tego pod uwagę i wykonałem płytkę tak, że nie mam możliwości skorzystania z zewnętrznego przerwania.

6. Starałem się zaimplementować prostą obsługę przycisków sterujących jasnością i częstotliwością błysków, jednak są problemy.

Na razie regulacje nie działają dobrze, bo jedno naciśnięcie przycisku jest interpretowane jako wiele naciśnięć, może nawet kilkadziesiąt, zależy to od czasu w którym jest naciśnięty i pewnie również od tzw. zjawiska drgania styków.

I tu pytanie: jak napisać optymalny program, aby procesor ciągle realizował swoje zadania (niedopuszczalne jest, aby spóźniał się przy podawaniu impulsu wyzwalającego) i dodatkowo, aby zapewniał zmiany zmiennych i,j w rytm naciśnięć przełączników zwierających konkretne linie portu A (0-3) do masy?

Powiedzmy, że oczekujemy tego, aby działało to jak taka klawiatura komputerowa, czyli że dłuższe naciśnięcie przycisku powoduje cykliczne zmiany o 1 wartości zmiennych w zakresie: zmienna i od 0 do 20, zmienna j od 0 do 10.
Powiedzmy również, że oczekujemy tego, aby po dłuższym przytrzymaniu przycisku zmieniał wartość określonej zmiennej w tempie 4/sekundę.
Powiedzmy również, że każde przyciśnięcie przycisku ma być traktowane jako jednokrotne, jeśli przycisk nie jest naciśnięty dłużej niż 1 sekundę.

Panowie, jak proponowalibyście zmienić program tak, aby realizował powyższe wymogi, ale również tak, aby nie zakłócać synchronizacji impulsu wyzwalającego względem dodatniej połówki sin.?

Oczywiście liczę się już z tym, że bez użycia dodatkowych przerwań pochodzących od zmiany stanu linii portu (w ATmedze16 port A0-3 nie posiadają takiej funkcji) oraz bez możliwości dołączenia peryferyjnych układów znoszących efekt tzw.drgania styków może być to trudne do osiągnięcia.
Liczę się również z tym, że może to wpłynąć na chwilową zmianę częstotliwości błysków, jeśli będzie wpływać, to załóżmy, że chcemy ten wpływ również minimalizować.

Będę wdzięczny za sugestie, może nawet za jakieś kody źródłowe. ;P
Jestem początkowy w AVR.

Uwaga na koniec: nie używam operatorów przesunięć bitowych, ponieważ w Codevision musiałbym dodatkowo definiować bazę poszczególnych nazw bitów w rejestrach.
Ten kompilator nie rozpoznaje, np. instrukcji typu:

ale już na przykład taką jak najbardziej:

Wiadomo jednak, że to nam nic nie daje, bo nie uzyskamy samodokumentującego się kodu. Dlatego wpisałem w rejestr wartości w kodzie hex, np. TIMSK=0x02.

Program na procesor poniżej:


Na koniec jeszcze jedno pytanie, które pojawiło mi się w trakcie już budowania samego układu (świeżak jestem):
- aby wysterować tyrystor z mikroprocesora zwierający obwód LC w pętlę, który powoduje szybkozmienne rozładowanie go przez uzwojenie pierwotne trafo, potrzebowałem zewrzeć masy układu sieciowego (N) i masę układu cyfrowego.
Czy taka praktyka jest w ogóle dopuszczalna?

Jeśli nie tak to jak inaczej ?

Wykonanie OK natomiast jakiż to był powód, że nie dało się tego upchać w czymś mniejszym np. Attiny13 albo chociaż Attiny24 ? Zaprzęganie do tak prostego układu Atmegi16 to jak strzelanie z armaty do muchy. Do sterowania fazowego nie jest potrzebny tryb CTC.
Z tym przerwaniem zewnętrznym to masz 100% racji - zdecydowanie ułatwiło by Ci program.
Zastanawiam się jeszcze czy sterowanie tyrystorem pod napięciem prosto z uC jest dobrym pomysłem. Jest dużo niekonsekwencji na tym schemacie, bo jeśli już robisz dość skomplikowane wykrywanie zera z transoptorem na wyjściu to czy nie wystarczyło zastąpić tego dwoma rezystorami jak radzi atmel? Potencjał sieci jest i tak na całym układzie. Gdybyś tyrystor pogonił przez MOC3021 miało by to uzasadnienie i przy tym było by bezpieczniej.

W czym rysowany projekt płytki? Do schematów proponuję chociażby prosty ExpressPCB. Na schemacie nie widzę mostka przed 7805.

O jej tyle instrukcji while w programie... Ja bym całą obsługę lampy upakował do przerywania od licznika, od biedy obsługę przycisków w pętli. Chociaż jak już użyłeś procka do takiej konstrukcji to wykorzystaj sprzętowy UART i zrób prościutki sterownik. Sterowanie przyciskami w obudowie to słaby sposób sterowania. Przydała by się też możliwość wyzwalania zewnętrznego jeśli to ma być sprzęt na imprezy.

Umieszczenie schematu „w pozycji odwrotnej” to już przesada...

Niekonsekwencja jeśli chodzi o bezpieczeństwo. Przy detekcji masz optoizolator, wszystko zasilane transformatorem, a wyjście na żywca podpięte z prockiem.
Dalej co się dzieje po włączeniu zasilania? Bo z tego co widzę pojawić się może przypadkowy stan na nóżce tyrystora, i jak trafi w środek sinusoidy to będzie ciekawie.

>>SylwekK
Dało by się upchać. Tylko po co? Różnica w cenie to jakieś 5zł, a tutaj ma multum możliwości rozbudowy.

Pozdrawiam

Jaki zakres częstotliwości obejmuje twój stroboskop?

AdamZad napisał:

Uwaga na koniec: nie używam operatorów przesunięć bitowych, ponieważ w Codevision musiałbym dodatkowo definiować bazę poszczególnych nazw bitów w rejestrach.
Ten kompilator nie rozpoznaje, np. instrukcji typu:

Kod C - [rozwiń]

TIMSK|=(1<<OCIE0)



ale już na przykład taką jak najbardziej:

Kod C - [rozwiń]

TIMSK|=(1<<TIMSK.1)



Wiadomo jednak, że to nam nic nie daje, bo nie uzyskamy samodokumentującego się kodu. Dlatego wpisałem w rejestr wartości w kodzie hex, np. TIMSK=0x02.

No powiem szczerze, że dziwi mnie troche to co napisałeś. Bo przesunięcia bitowe są przynajmniej dla mnie dużo bardziej czytelne nawet w tej drugiej formie. Nie znam Twojego kompilatora, ale z tego co wiem to te nazwy bitów typu PC3, PC4, OCIE0 itd to to są zwykłe liczby z zakresu 1, 8 poprzypisywane #define'ami w odpowiednich pliku nagłówkowych (#include <avr/io.h>), a u Ciebie nie widzę tej linijki, więc może to jest kwestia związana z tym. No ale znowu używasz <mega16.h> ja powiem szczerze tak nie piszę, tylko piszę to #include <avr/io.h> i potem przy kompilacji podaję na jaki procek. Zaznaczam jeszcze raz, że nie znam Twojego kompilatora.

Witam,

co do wyboru procka, to przy jednej szt. prototypowej i to jeszcze przy małym doświadczeniu w pisaniu oprogramowania, to czym większy tym mniej problemów w trakcie realizacji. Gdy już mamy powiedzmy działający program w całości, wtedy można rozważyć zmianę na mniejszy, ale tylko wtedy gdy jest to uzasadnione, np. nowa mniejsza płytka lub wykonanie w większej ilości.

Co do problemów z obsługą przycisków, to dobrze dostrzegłeś, że wynika to z drgań styków.

Całą ich obsługę możesz umieścić w przerwaniu timera, którego używasz do sterowania częstotliwością, pamiętaj tylko, żeby ich obsługa ograniczała się do jak najprostszych funkcji, które łącznie będą trwać znacznie krócej niż pojedyncze przerwanie z tego timera.

Problem drgań styków możesz rozwiązać na kilka sposobów, wyjaśnię Ci jeden ten który jest najbliżej Twojego założenia.

Przykładowy sposób obsługi jednego przycisku:

w przerwaniu wrzucasz warunek IF, jeżeli pinx ma wartość 0, to:
zwiększ zmienną "drgania", w tym warunku umieść kolejny warunek:
jeżeli zmienna drgania>przyjmij sobie jakąś wartość, np. 25 i pinx=0, to
zwiększ zmienną częstotliwość.

W ELSE wpisujesz, zmienna drgania=0, oznacza, to że w momencie zwolnienia przycisku zostaje zresetowana wartość odmierzająca czas zwłoki eliminujący drganie na styku.
W ten sposób jednokrotne przyciśnięcie zmieni wartość tylko o jeden. Zwłoka jaka jest z reguły wystarczająca na eliminację drgań na styku mieści się w okolicy 25ms.
Teraz rozbudujmy troszkę to, o funkcję przyspieszania zmiany wartości po dłuższym przytrzymaniu przycisku.

Fajnym sposobem na szybką zmianę wartości, ale nie liniową jest taki algorytm:
jeżeli przycisk wciśnięty krócej niż x, to zwiększ o jeden
jeżeli dłużej, to zwiększ o 10.

np. mamy przykładowo wartość=6, a chcemy 358.
Wciskamy przycisk i przytrzymujemy, wartość się zmienia o jeden do momentu ustawienia czasu po jakim ma zwiększać o 10, powiedzmy że zwiększyło do 13 i dalej zwiększa już o 10, czyli 23, 33, 43... Zatrzymujemy na wartości 353 i zwiększamy przez pojedyncze wciśnięcia do 358.

Do ELSE dorzucamy również resetowanie wartości zmiennej przez którą zwiększa o 10.

Drugi sposób:
powiedzmy, że czas zwłoki na przycisku wynosi 200ms, czyli trzymając przycisk wciśnięty, to wartość zmienia się z prędkością co 200ms, gdy przycisk mamy wciśnięty dłużej niż 1 sekundę, to zmniejsz zmienną zwłoki np. o 10, ale ustal sobie wartość minimalną, np. 25ms. Trzymając przycisk wciśnięty, czas zwiększania wartości zmniejsza się o 10ms na sekundę. W ten sposób zmiany ustawianej zmiennej przyciskiem następują liniowo, a czym dłuższe przytrzymanie przycisku, tym szybciej ta wartość się zmienia.

Powodzenia w kończeniu konstrukcji

AVE...

Drgania styków i zajmowanie się nimi są omówione w tej serii artykułów:
http://mirekk36.blogspot.com/2012/10/drgania-stykow-to-bajki-wiec-jak-to.html

Wzór PCB też jakoś dziwnie narysowany. Brak dobrej izolacji galwanicznej między częścią cyfrową, a wykonawczą - jak triak szlag trafi, to uwali mikrokontroler z efektowną eksplozją w tle. Może któryś kolega ma uwalonego mikroklocka i kamerę, by zademonstrować, co napięcie sieciowe robi z taką delikatną elektroniką?
Ogólnie pisząc to jestem na minus...

1. Dlaczego do sterowania przesunięciem fazowym nie jest potrzebny tryb CTC, tutaj chodzi przecież o odmierzenie ściśle określonego czasu od momentu przejścia przez zero? Co kolega Sylwekk ma na myśli ?

2. Płytka rysowana manualnie w programie Eagle

3. Na schemacie nie ma mostka przed stabilizatorem ponieważ jest on wraz z filtrem wbudowany w transformator (wziąłem go z jakiegoś zasilacza dogniazdkowego)

4. Po włączeniu zasilania występuje automatyczny reset procka, więc stany portów mogą istotnie powodować jednorazowe wysterowanie tyrystora który zadziała nie wtedy kiedy trzeba - w praktyce taka sytuacja nie występuje bo miałoby to efekt w postaci wybicia bezpieczników.

5. Co kolega michal-michalik ma na myśli mówiąc o prościutkim sterowniku z wykorzystaniem sprzętowego UART'u ?
Co taki sterownik miałby w ogóle robić ?

6. Zakres częstotliwości którą można ustawiać to 1-20Hz.
Powyżej tej wartości zaczyna być widać efekt nierównomiernego migania.
Gdyby upakować obsługę lampy do przerwań najprawdopodobniej częstotliwości można by było uzyskać nawet i większe ale z uwagi na okres sinusoidy sieciowej napewno nie większe niż 50 Hz.

7. Mój kompilator Codevision zgłasza błąd przy deklaracji typu : #include <avr/io.h>
W ogóle nie rozpoznaje takiej biblioteki .

Reasumując widzę że popełniłem tylko jeden poważny błąd - mianowicie podłączyłem na żywca tyrystor z prockiem.
Nie rozumiem jednak co kolega Sylewkk ma na myśli radząc abym pogonił tyrystor przez MOC3021 ?
Czy takie coś zapewniło by separację galwaniczną i poprawę bezpieczeństwa procka i całego układu ?

Na chwilę obecną postaram się zrobić sobie płytkę testową z możliwością podpięcia ATmega16, ATtiny13 i ATtiny24.
Na płytce znalazłyby się :

1. Podstawki pod te trzy procesory
2. Wyprowadzone jedno złącze ISP do programowania
3. Goldpiny od portów
4. Wyświetlacz LED z komunikacją I2C
5. Parę mikroprzełączników (powiedzmy 6)
6. Matryca punktów lutowniczych z wyprowadzonymi końcówkami w postaci goldpinów (10x4)
7. Czteropozycyjny wyświetlacz 7-segmentowy wraz z dekoderem CD4543 i jednym multiplekserem
8. Cztery potencjometry
9. Osiem diód LED wraz z rezystorami
10. Przycisk reset
11. Transformator sieciowy + filtr + stabilizator napięcia +5V
12. 8 tranzystorów BC517 połączonych z przekaźnikami

Pewnie na tej płytce jeśli mi wyjdzie będę mógł sobie potestować najróżniejsze małe prototypy takie jak np. ten układ sterujący do stroboskopu.
Co o tym myślicie ?

2. Rysuj od razu schemat w Eagle i dopiero na tej podstawie utwórz PCB, dużo mniejsza szansa na popełnienie błędu no i czas przygotowania się zmniejszy.

5. Możliwości jest dużo. Od sterowania mocą błysku, częstotliwości, a na zewnętrznym wyzwalaniu kończąc. Tak to działa w profesjonalnych urządzeniach.

Jeśli chodzi o ten sterownik UART to wiem że można za jego pomocą komunikować procesor z układami peryferyjnymi.
Nie rozumiem jednak jak miałby wyglądać mój sterownik i po co go tutaj wprowadzać. ?
Co miałby konkretnie robić ten sterownik w moim projekcie ?

Sterownik podstawowe funkcje:


A po co? Poprawia wygodę i zwiększa funkcjonalność. To tak samo jak pytać się po co budowałeś stroboskop...

AdamZad napisał:

1. Dlaczego do sterowania przesunięciem fazowym nie jest potrzebny tryb CTC, tutaj chodzi przecież o odmierzenie ściśle określonego czasu od momentu przejścia przez zero? Co kolega Sylwekk ma na myśli ?
...
Nie rozumiem jednak co kolega Sylewkk ma na myśli radząc abym pogonił tyrystor przez MOC3021 ?
Czy takie coś zapewniło by separację galwaniczną i poprawę bezpieczeństwa procka i całego układu ?

Nie jest potrzebny tryb CTC, bo wystarczy zwykłe odmierzanie czasu w przerwaniu od momentu przejścia przez zero i po odliczeniu tego czasu (im dłuższy tym mniej mocy, ale nie dłuższy niż 10ms) wystarczy podać impuls dla tyrystora.
MOC302x to seria optotriaków czyli taki transoptor LED-TRIAK bez detekcji przejścia przez zero idealnie nadający się do układów regulacji fazowej (oczywiście z galwaniczną separacją). Natomiast seria MOC304x to są optotriaki z detekcją przejścia przez zero i te z kolei idealnie nadają się do regulacji grupowej (np. takiej jak POD TYM LINKIEM)

Teraz już chyba rozumiem.
Po prostu nie wiedziałem co masz na myśli pod pojęciem "sterownik".
Powiedz mi jeszcze jeśli możesz czy trudno jest wykonać taki sterownik z komunikacją UART ?
W jaki sposób można zamienić ustawioną wartość potencjometru na informację która ma być potem wysłana w standardzie UART ?

O mikroprocesor nie muszę się chyba martwić bo ma on w sobie zaimplementowany ten driver i protokół ? Mam rację ?

Zgadza się ATmegi mają sprzętowy UART zaimplementowany. Sterownik po prostu sczytuje za pomocą przetwornika A/C wartość napięcia na potencjometrze, potem wrzuca to do bufora UART, a procek sam już to wyśle w odpowiedni sposób.

Ciebie interesuje tylko sposób interpretacji tego co dostaniesz od sterownika w stroboskopie.

Sam odbiornik dostaje jeden bajt informacji, zgłasza przerywanie no i wystarczy odebraną daną zinterpretować.

Poczytaj o sterowaniu DMX 512. Idea będzie podobna

Kurcze, dalej nie jarzę.

Piszesz : "Sterownik po prostu sczytuje za pomocą przetwornika A/C wartość napięcia na potencjometrze, potem wrzuca to do bufora UART, a procek sam już to wyśle w odpowiedni sposób...."

Jak to procek wyśle w odpowiedni sposób ? Masz na myśli odbierze informację ze sterownika poprzez asynchroniczną cyfrową transmisję UART która wstępnie w sterowniku zostaje przekonwertowana z analogowej na cyfrową postać ?

Dlaczego w takim razie w ogóle stosować UART, nie wystarczy podłączyć potencjometr sterownika do nóżek przetwornika A/C procesora ?
Czy może z powodu możliwości wystąpienia zakłóceń ?

Czy jeśli dobrze myślę na powyższe tematy to czy w tym sterowniku musi być jakiś dodatkowy procesor który by realizował zamianę tego analogowego sygnału na cyfrową postać UART żeby mógł się z tym nadrzędnym komunikować ?

Tak musi być drugi układ.

Transmisja danych cyfrowych oszczędza okablowanie i niweluje problemy z tym związane.
Dzięki temu za pomocą jednego przewodu, możesz przesłać więcej informacji.

Może trochę wybiegłem za mocno przed szereg z tym pomysłem...

I sorki jeśli coś nie do końca jasno opisałem, sesja jest to tak w chwilach wolnych odpisuje

Pozdrawiam

I tak jestem Ci wdzięczny za odpowiedzi i sugestie.

Jeśli możesz napisz jeszcze czy tym układem zawierającym w sobie konwerter A/C i wysyłającym w standardzie UART musi być kolejny mikroklocek czy są jakieś inne dedykowane układy ? Jeśli tak, w skrócie prosiłbym o jakiś opis co mogą przykładowo robić.

Najprościej zrobić to na mikro-kontrolerze, dało by się pewnie inaczej, ale sensu to dużego nie ma.
Mając sterownik można zaprogramować multum fajnych funkcji jak już pisałem.
A na dokładny opis nie mam czasu niestety. Odezwij się w Marcu jak się sesja skończy to mogę pomóc Dobra, zostawmy miejsce w wątku na inne uwagi...

Przeczytałem wątek i się trochę podłamałem, ale ogólnie jak chcesz się dowiedzieć konkretnych rzeczy to polecam:
http://mikrokontrolery.blogspot.com/

i z tamtąd kombinować dalszą wiedzę. Tam masz opisane ADC w atmegach, masz opisane timery, UART chyba też jest. Ogólnie skarbnica wiedzy.

Przyczepię się do jeszcze czegoś.
1) tranzystor + prąd zmienny?
2) mostek prostowniczy ze zwartymi wejściami. diod nie łączy się bezpośrednio równolegle ze względu na chociażby ciut NIEIDENTYCZNE napięcia złącz co może się zakończyć tym co punkt 1), lub uC + sieć bez optoizolacji.
Wg mnie to nie powinno być w DIY konstrukcje.

ps.: Gratuluję odwagi! (patrz wyżej)

1. Bez przesady, jest tam spory opornik 120k i dioda, bo rozumiem że mówisz o detektorze przejścia przez zero.

2. Jeśli wiadomo że prądy chwilowe są duże to jeśli będzie on przepływał przez wszystkie diody jednocześnie to będą się mniej grzały jakby była tam jedna.
Wtedy jest tak że prąd rozpływa się w mniej więcej równym stosunku.

Ja z kolei zgodzę się z tym że zrobiłem błąd sprzęgając mikroklocek z częścią siłową (tyrystor) jednak nie zgodzę się z Twoją uwagą.
Zresztą schemat detektora był np. wzięty żywcem z elektroniki praktycznej :
http://ep.com.pl/files/2965.pdf

2. mi się rozchodzi o oporniki wyrównawcze

A propos UART i przykładu dla ATmega: http://mikrokontrolery.blogspot.com/2011/03/rs-232-atmega8-komputer-terminal.html

Szczodros - możesz trochę jaśniej ? Nie bardzo rozumiem co masz na myśli...