Witam wszystkich to mój pierwszy post i jak można się było spodziewać z pierwszym problemem
Ciężko jest zaczynać programować jeśli już na początku nie mogę dojść co jest grane... Napisałem mały programik aby przetestować sobie przerwania na ATMEGA8 w CTC i programowe timery, które często stosowałem w BASCOM. Wg noty PDF poustawiałem przerwania (wydaje mi się że dobrze, ale to mi się tylko tak wydaję więc proszę o sprawdzenie), zmienne licznikowe zdefiniowane jako volatile aby były widoczne (i można było z nich korzystać) i w przerwaniu i w pętli głównej (też mi się wydaje, że zrobiłem to dobrze) no i ...nie działa.
Proszę o pomoc. Dioda na pb1 powinna migać szybciej niż diody na pb2 i pb3 (migające równocześnie).

_________________
http://www.sylwekkuna.com

W Atmega8 preskaler ustawia się w TCCR1B,
zamiast

użyj

Bit WGM12 też znajduje się w TCCR1B.

No niestety. kombinuję z tymi rejestrami i efektu nie widać ...

_________________
http://www.sylwekkuna.com

Bit WGM12 znajduje się w rejestrze TCCR1B a nie w TCCR1A. Tu masz babola

Wiem coś o tym http://forum.atnel.pl/topic4418.html

_________________
ATB 1.04, Bluebook wyd.II, Greenbook wyd.II

Zmień procedurę obsługi przerwania. Wygląda to tak jakbyś próbował zrobić timer programowy na wzór mirkowego ale nie napisał całości. Luknij do bluebooka

Nooo, teraz działa! Dzięki Kurcze, żę tak powiem "za Bascoma" nie musiałem aż tak dokładnie studiować pdf, chyba czas się nawrócić

Nowa wersja:


W ten sposób dochodzimy do sedna sprawy. Otóż celowo zrobiłem dwa identyczne liczniki na 16-o bitowych zmiennych aby sprawdzić jak sobie poradzą z przerwaniami. Niestety, tak jak myślałem nie jest dobrze. Diody, które powinny migać równocześnie błyskają sobie w zasadzie jak chcą już od pierwszych chwil, a tylko ta na pb0 miga prawidłowo. Czy zna ktoś rozwiązanie oprócz uzupełniania wartości licznika bezpośrednio w przerwaniu, lub blokowaniu przerwań na czas badania warunku (i odświeżenia licznika jednocześnie)? Można wykorzystać znacznik i przekazywać jego stan do.. i z.. przerwania, ale to jednak dodatkowa zmienna...

_________________
http://www.sylwekkuna.com

Teraz to będziesz musiał spać z PDFami pod poduszką

_________________
+++++[>++++<-]>[>++++++<-]>.---------.+++.

PO PIERWSZE - zbyt dużą częstotliwość ustawiłeś dla Timera1 do takich celów 1ms !!! Zupełnie niepotrzebnie do takich celów - wystarczyłoby 10ms. Piszę o tym trochę w bluebooku (co ? jak ? i dlaczego?) .... Pomyśl sobie ile czasu trwają operacje w przerwaniu biorąc pod uwagę prolog i epilog (przeanalizuj sobie nawet pobieżnie kod asm przerwania) ... Drga sprawa w bluebooku pokazałem nieco zoptymalizowany sposób działania na tych timerach programowych ... Może wygląda na ciut bardziej zakręcony ale właśnie jest bardziej optymalny czasowo.

I teraz tak - uważaj. W tym twoim prostym przykładzie WSZYSTKIE DIODY LED mrugają tak jak należy i WCALE nawet nie trzeba wyłączać przerwań na żeby dobrze migały skąd wiem - no bo odpaliłem to właśnie sobie na zestawie ATB

ale jeśli ty testujesz to być może w jakimś swoim większym projekcie gdzie w pętli głównej dzieje się jeszcze wiele innych rzeczy to nie ma co się dziwić - do takich operacji PEWNIE że trzeba podejść ATOMOWO jak to się mówi ...

taki sposobów jest mnóstwo począwszy od zainkludowania biblioteki atomic.h i posłużeniem się makrami "atomic block" , albo po staremu jak to się mówi czyli oklepaną metodą z rejestrem SREG o tak np:




albo tak:

_________________
zapraszam na blog: http://www.mirekk36.blogspot.com (mój nick Skype: mirekk36 ) [ obejrzyj Kurs EAGLE ] [ mój kanał YT TV www.youtube.com/mirekk36 ]

Mirku, a co sądzisz o wyjęciu obsługi multipleksowania poza przerwanie do oddzielnej funkcji uruchamianej w pętli głównej.
A w przerwaniu tylko machanie flagą


A w pętli głównej uruchamiamy takie coś:

Nie wiem dlaczego akurat to pytanie w tym wątku ale ...

Wydaje mi się (zaznaczam wydaje ...), że taki sposób na multipleksowanie będzie skazany przy większym projekcie niż tylko samo multipleksowanie, skazany na niepowodzenie. Użycie tego w przerwaniach daje gwarancję takiej samej częstotliwości odświeżania. Zaś próba organizacji tego tak jak proponujesz w projekcie, który musi coś tam jeszcze innego czasem zrobić w pętli głównej skończy się migotaniem co jakiś nieregularny czas albo w ogóle ciągłym migotaniem ... Dla oka to mogą być mało przyjazne efekty.

_________________
zapraszam na blog: http://www.mirekk36.blogspot.com (mój nick Skype: mirekk36 ) [ obejrzyj Kurs EAGLE ] [ mój kanał YT TV www.youtube.com/mirekk36 ]

Fakt miało być w innym, w tym którym było o ustawianiu flag w przerwaniach. Ale jak widać zbyt późna godzina powoduje przekłamania

No, dziś wreszcie mogłem trochę przy kompie z C posiedzieć Kończy mi się właśnie sezon weselny i mało czasu niestety na naukę mam - idzie zima to myślę, że nadrobię



Zgadza się częstotliwość jest dość wysoka, ale zawsze ją dobierałem w BASCOMIE aby zoptymalizować potrzebne czasy do odliczania i wykorzystać przeważnie 8-bitowe zmienne do tego celu. Ten "błąd" tak rażącego migania zauważyłem przez czysty przypadek kiedy komuś na priv demonstrowałem timery programowe.
W moich, niektórych większych projektach ustawałem jeszcze większą częstotliwość (np. 25kHz) i paradoksalnie efekt rozjazdu czasowego był tam pomijalny, a już na pewno nieistotny dla działania programu, który miał np. odliczyć 2 minuty czy 10 minut i jeśli ten czas uciekł mi nawet o 1-2s to tragedii nie było, bo czas ten był powtarzalny (!) i można go było spokojnie podrasować. Można sobie nawet z ciekawości w pierwszym programie ustawić przerwania na 10kHz i sam zobaczysz, że diody migają względnie stabilnie, a przede wszystkim bez nagłych skoków tak jak to miało miejsce przy wolniejszym timerze.
Książkę oczywiście czytam za koleją od początku i jestem już przy ADC i być może dlatego o kombinacjach z timerami programowymi jeszcze nie doczytałem Czasem tylko wracam do poprzednich rozdziałów jeśli nagle mi się jakaś składnia zapomni...

Wróćmy do programu. Jakoś nie dopuszczam nawet myśli, żeby wyłączyć przerwania na czas badania warunków i takie rozwiązania mnie nie satysfakcjonują. Wróciłem do jednobajtowych zmiennych licznikowych tak jak to robiłem bardzo często w bascomie jeśli zależało mi na większej dokładności Myślałem po prostu, że obsługa przerwań będzie szybsza w C i taki błąd nie wystąpi (bascom naprawdę śmieci w przerwaniach!)... chyba się przeliczyłem
Do rzeczy - wszystkie liczniki z poniższego programu są 16-o bitowe i ustawione na 0,5s, ale tylko jeden tak naprawdę liczy ustawiony czas


Aha, czy przypadkiem aby była poprawna częstotliwość rejestr nie musi być uzupełniany liczbą 999?:

OCR1A = 999; //1000Hz 1ms (8000000/8/1000=1kHz)

EDIT:
Tak sobie kombinuje z tą składnią i coraz bardziej mi się podoba efektywność C. W powyższym kodzie jeszcze uprościłem licznik przez co zyskałem na nim aż 6 bajtów, a to sporo jak na jeden licznik w przerwaniach.



Nie ukrywam, że podobny zapis "if (L1p-- <1)" podpatrzyłem w jednym z programów z bluboka (postanowiłem odnaleźć przed czasem te liczniki ).
Nawyk optymalizacji mam od początków mojego kontaktu z komputerami, a widzę, że w C jest spore pole do popisu
Myślałem, że jeszcze na takim zapisie coś zyskam "if (!(L1p--))" ale kod w asm się nie zmienił nawet o 1 bajt.

_________________
http://www.sylwekkuna.com