ATNEL tech-forum

Re: Problem z przerwaniami, które się "zawieszają"

2016-06-22T17:09:18+01:00

Dzięki wielkie! Tak, ten kod był oczywiście pisany dla zabawy, bo się dopiero uczę. Zawsze jak robię jakiś projekt z Bluebooka to potem sam wymyślam sobie co się jeszcze da z tego zrobić ciekawego, coś zmienić, ulepszyć itp.

Faktycznie to chodziło o to, bo jak sobie policzyłem moją Atmegę8 8Mhz i ten preskaler, to faktycznie żeby doliczyć do końca to mija jakieś 8s. I dokładnie na ten czas zmiana w wyświetlaczach się zatrzymywała.

Teraz jak już wiem, co jest przyczyną, poprawiłem sobie swój kod i wszystko działa tak jak chciałem. Bo wrzuciłem sobie zmianę tego rejestru wewnątrz, do przerwania, o tak:

[syntax=c]ISR(TIMER1_COMPA_vect)
{
/* reszta kodu przerwania */
static int licznik2 = 0;

++licznik2;
if (przyspiesz)
{
if (licznik2==10)
{

if (OCR1A>50) OCR1A -= (OCR1A>500) ? 200 : 50;
licznik2 = 0;

}
}
else
{
if (licznik2==10)
{

if (OCR1A<2000) OCR1A +=50;
licznik2 = 0;

}
}

}[/syntax]
i potem w pętli głównej mam tylko dwie linijki:
[syntax=c]while(1)
{
przyspiesz ^=1;
_delay_ms(10000);
}[/syntax]
które robią całą resztę. Także jeszcze raz dzięki wielkie i teraz czas na następny projekt

Statystyki: Napisane przez Scynk — 22 cze 2016, o 17:09

Re: Problem z przerwaniami, które się "zawieszają"

2016-06-22T09:53:55+01:00

Scynk napisał(a):

Po mojemu teoretycznie wszystko powinno działać. A dzieje się coś dziwnego, mianowicie wyświetlacze najpierw się faktycznie "rozpędzają" a potem nagle na jakieś 3-4s przerwanie tak jakby "zawiesza się", tzn. że przez ten czas świeci się cały czas tylko jeden wyświetlacz np. cyfra 3 na drugim wyświetlaczu. I nic więcej się nie dzieje. A potem jak się "odetnie", to wyświetlacze są już bardzo rozpędzone i zaczynają zwalniać. I potem znowu za jakiś czas staje na jednej cyfrze. 3-4s. i znowu się zmieniają tak jak powinny. Czy ktoś z was spotkał się kiedyś z czymś takimś? Co może być przyczyną?

Wprawdzie ten kod jest tylko "4fun", ale lubię ludzi dociekliwych, więc spróbuję odpowiedzieć.
Osobiście się z tym nie spotkałem, ale wiem co może być przyczyną
Zacytuję datasheet:

Quote:

However,
changing the TOP to a value close to BOTTOM when the counter is running with none or a
low prescaler value must be done with care since the CTC mode does not have the double buffering
feature. If the new value written to OCR1A or ICR1 is lower than the current value of
TCNT1, the counter will miss the Compare Match. The counter will then have to count to its maximum
value (0xFFFF) and wrap around starting at 0x0000 before the Compare Match can occur.
In many cases this feature is not desirable.

Ty wpisujesz wartość do OCR1A w dosyć przypadkowych, trudnych do przewidzenia momentach. Nie jest to w żaden sposób zsynchronizowane z pracą timera. Jeśli wpiszesz do OCR1A wartość niższą od aktualnej wartości rejestru TCNT1, to licznik będzie musiał doliczyć do maximum, czyli do 65535 i dopiero wtedy się wyzeruje. W tym czasie nie zdarzy się żadne przerwanie od porównania z przyczyn oczywistych (wartość OCR1A będzie cały czas mniejsza od TCNT1), a to przecież w procedurze obsługi tego przerwania jest kod, który wyświetla następną cyfrę. Nie znam częstotliwości taktowania Twojego mikrokontrolera, więc policz sam, ile czasu mu zajmie doliczenie do 65535 z preskalerem 1024.

Pozdrawiam

Statystyki: Napisane przez andrews — 22 cze 2016, o 09:53

Re: Problem z przerwaniami, które się "zawieszają"

2016-06-20T21:02:49+01:00

Hehe Pisząc "rozpędzanie" i "zwalnianie" miałem na myśli że przełączanie (multipleksowanie) między wyświetlaczami odbywa się z coraz większą/mniejszą częstotliwością. Chodzi o to, że jak jest te 50Hz, to widzimy jakby wszystkie 3 wyświetlacze się świeciły. I chciałem zrobić programik, żeby efekt był taki, że wyświetlacze zmianiają się od powiedzmy sekundy, czyli świeci się cyfra na pierwszym wyświetlaczu -> 1s -> drugi wyświetlacz -> 1s -> trzeci itp. i stopniowo zwiększamy częstotliwość tak, żeby się zmieniały co powiedzmy 0,5s. potem np. 0.25s i ostatecznie dochodzimy do 50Hz. Chciałem zrobić tak, żeby obserwując te migotanie od bardzo wolnego tempa (1s) do tych 50Hz dało się zauważyć, jak w pewnym momencie ludzkie oko się poddaje i świecą się wszystkie trzy wyświetlacze. Mam nadzieję, że teraz już wszystko jasne

------------------------ [ Dodano po: 3 minutach ]

Daro69 napisał(a):

zerknij na warunki.
przy OCR1A = od 51 do 1999, oba są spełnione.

Ale jeśli dobrze rozumiem, to nie wpływa na siebie, bo i tak przecież się wykonuje tylko jedna pętla na raz, nie? Czyli jak na samym początku programu mamy OCR1A = 2000; to jedzie pierwsza pętla, i ona dopiero wtedy się kończy jak OCR1A spadnie poniżej 50, a dopiero potem zaczyna się druga, tak?

Statystyki: Napisane przez Scynk — 20 cze 2016, o 21:02

Re: Problem z przerwaniami, które się "zawieszają"

2016-06-20T20:59:40+01:00

zerknij na warunki.
przy OCR1A = od 51 do 1999, oba są spełnione.

Statystyki: Napisane przez Daro69 — 20 cze 2016, o 20:59

Re: Problem z przerwaniami, które się "zawieszają"

2016-06-20T20:47:51+01:00

Ja bym pomógł ale gdybym był w stanie zrozumieć co to oznacza "rozpędzanie" albo "spowalnianie" wyświetlaczy a jeszcze gdyby z ciekawości dowiedzieć się po co takie rodeo ? to byłoby fajnie

Statystyki: Napisane przez mirekk36 — 20 cze 2016, o 20:47

Problem z przerwaniami, które się "zawieszają"

2016-06-20T20:38:16+01:00

Jako że jest to mój pierwszy post witam wszystkich serdecznie Jestem początkujący w temacie uC, i natknąłem się na moim zdaniem dziwny problem, z którym nie wiem jak sobie poradzić. Otóż mam Bluebooka i zabrałem się za projekt z multipleksowaniem wyświetlaczy. Mam Atmegę8, więc trochę musiałem się namęczyć z ustawieniem CTC na timerze, ale ostatecznie po zmianie wyszło mi coś takiego: [syntax=c]//ustawienie timer 1
TCCR1B |= (1<TCCR1B |= (1<OCR1A = 2000; //dodatkowy podział przez 2000 (rejestr przepełnienia)
TIMSK |= (1<i działa . Reszta kodu jest identyczna jak w książce, tylko używam 3 wyświetlaczy a nie 4. A potem pojawił się pomysł, żeby te migające wyświetlacze się "rozpędzały" i "zwalniały". Więc dokonałem takiej zmiany w pętli głównej programu:
[syntax=c]while(1)
{
while (OCR1A>50)
{
OCR1A -=5;
_delay_ms(30);
}

_delay_ms(2000);

while (OCR1A<2000)
{
OCR1A += 5;
_delay_ms(30);
}
_delay_ms(2000);

}[/syntax]
Po mojemu teoretycznie wszystko powinno działać. A dzieje się coś dziwnego, mianowicie wyświetlacze najpierw się faktycznie "rozpędzają" a potem nagle na jakieś 3-4s przerwanie tak jakby "zawiesza się", tzn. że przez ten czas świeci się cały czas tylko jeden wyświetlacz np. cyfra 3 na drugim wyświetlaczu. I nic więcej się nie dzieje. A potem jak się "odetnie", to wyświetlacze są już bardzo rozpędzone i zaczynają zwalniać. I potem znowu za jakiś czas staje na jednej cyfrze. 3-4s. i znowu się zmieniają tak jak powinny. Czy ktoś z was spotkał się kiedyś z czymś takimś? Co może być przyczyną? Pozdrawiam

Statystyki: Napisane przez Scynk — 20 cze 2016, o 20:38