ATNEL tech-forum

Re: Problem z timerem programowym

2018-10-10T19:11:26+01:00

Jeśli to stały czas i nie ma możliwości zmienić taktowania przerwań to ja w takich przypadkach wykorzystuje dodatkową flagę, która daje sygnał dla warunku w przerwaniach i to tam jest odświeżana wartość dla timera. Działa zawsze prawidłowo Natomiast w sytuacji gdy odliczany czas jest modyfikowany stosuje inna zmienną w przerwaniach, która np. wstępnie podzieli mi przez dwa i zamiast 300 wpisuje wtedy 150. Jest 8bit? No jeeest

Statystyki: Napisane przez SylwekK — 10 paź 2018, o 19:11

Re: Problem z timerem programowym

2018-10-10T17:53:59+01:00

To nie ma znaczenia, czy użyjesz jednej zmiennej 16-bitowej, czy dwóch zmiennych 8-bitowych. Kiedy użyjesz zmiennej 16-bitowej, kompilator i tak musi rozbić to na dwie operacje 8-bitowe, bo to mikrokontroler 8-bitowy. I pomiędzy tymi operacjami nie może wystąpić przerwanie, które zmodyfikuje tę zmienną.

Podam Ci taki przykład:

wartość zmiennej Timer1 wynosi 255, czyli 0x00FF,
program dochodzi do momentu, kiedy wartość zmiennej Timer1 trzeba porównać z wartością 0 (mówię tu o instrukcji warunkowej if( !(Timer1) ),
nie można porównać dwóch bajtów jednocześnie, bo mikrkontroler ma rejestry 8-bitowe, więc najpierw porównywany jest starszy bajt, który wynosi 0x00, czyli warunek jest spełniony,
teraz występuje przerwanie od timera, i zmienna zostaje powiększona o 1, czyli przyjmuje wartość 0x0100,
mikrokontroler wraca do wykonywania programu głównego, i porównuje teraz młodszy bajt (bo starszy przecież już porównał); teraz młodszy bajt (z liczby 0x0100) wynosi również 0x00, więc warunek znowu jest spełniony,
w związku z tym, że wynikiem porównaniu starszego bajtu z zerem była prawda i wynikeim porównania młodszego bajtu z zerem była prawda, mikrokontroler uznaje, że cała liczba jest równa zero, a przecież nie jest, bo wynosi 0x0100.

Wszystko byłoby dobrze, gdyby pomiędzy dwoma operacjami porównania nie wystąpiło przerwanie i nie zmodyfikowało zmiennej, bo wtedy drugie porównanie zwróciłoby fałsz i wszystko byłoby OK. Dlatego w momencie modyfikowania, czy też porównywania zmiennej wielobajtowej należy przerwania wyłączyć. Przykłady masz podane powyżej.

Można też zrobić tak, jak zrobiłeś, pod warunkiem, że wykonanie bloku instrukcji pomiędzy cli() a sei() nie będzie trwało zbyt długo. Należy zadbać o to, żeby wyłączenie przerwań trwało jak najkrócej. Dlatego podałem przykład z tworzeniem kopii zmiennej, bo to wyłącza przerwania tylko na kilka taktów. Twój sposób wyłączy zapewne na dłużej, choć w tym przypadku jeszcze nie będzie tragedii. Piszę o tym raczej, żebyś zapamiętał na przyszłość, bo gdyby w bloku instrukcji było jakieś wyświetlenie na LCD lub transmisja UART, wtedy Twój sposób nie jest dobry.

Statystyki: Napisane przez andrews — 10 paź 2018, o 17:53

Re: Problem z timerem programowym

2018-10-10T17:45:52+01:00

dobra, doszedłem do właściwego dla mojego przypadku rozwiązania
[syntax=c]cli();
if(!Timer1)
{
LED1_TOG;
Timer1 = 300;
}
sei();[/syntax]
inaczej zazwyczaj podczas sprawdzania warunku if wchodził w przerwanie,
Dziękuję za pomoc i pozdrawiam

Statystyki: Napisane przez sildurian — 10 paź 2018, o 17:45

Re: Problem z timerem programowym

2018-10-10T17:14:30+01:00

sildurian napisał(a):

i w momencie jak jest wykonywana operacja if może dojść do przerwania?

No toż przecież po to mówimy ci o atomowym podejściu ... tak oczywiście że chodzi o przerwania - a o cóż innego miałoby chodzić. Zarówno sprawdzanie jak i zapis trzeba robić atomowo i masz przykłady wyżej na to

Statystyki: Napisane przez mirekk36 — 10 paź 2018, o 17:14

Re: Problem z timerem programowym

2018-10-10T16:58:50+01:00

Dziękuję,
W międzyczasie doszedłem do czegoś takiego i efekt jest taki jak miałem wcześniej
[syntax=c]while(1)
{
if((!TimL)&&(!TimH))
{
LED1_TOG;
timer_conv = 300; // zmienna globalna uint16_t
TimL = (uint8_t)timer_conv; // zmienna globalna volatile uint8_t
TimH = timer_conv >> 8; // zmienna globalna volatile uint8_t
}
}
}

ISR(TIMER2_COMP_vect) //100kHz -> 10us
{
uint8_t valTimL;
uint8_t valTimH;

valTimL = TimL;
valTimH = TimH;
if(valTimL) TimL = --valTimL;
else if(valTimH) {TimH = --valTimH; TimL = 255;}
}[/syntax]
teraz w warunku if operuję na zmiennych 8bitowych, a i tak problem jest taki sam, czyli rozumiem, że operacja zajmuje więcej taktów zegara i w momencie jak jest wykonywana operacja if może dojść do przerwania?

Statystyki: Napisane przez sildurian — 10 paź 2018, o 16:58

Re: Problem z timerem programowym

2018-10-10T16:22:21+01:00

sorki - jeszcze sprawdzanie wartości timera trzeba atomowo - ale to już andrews mnie ubiegł

Statystyki: Napisane przez mirekk36 — 10 paź 2018, o 16:22

Re: Problem z timerem programowym

2018-10-10T16:23:21+01:00

Nie zapewniasz atomowego dostępu atomowego dostępu do zmiennej wielobajtowej, używanej zarówno w przerwaniu, jak i w głównej pętli programu. Operacje na takiej zmiennej w mikrokontrolerach 8-bitowych, jak słusznie już sam zauważyłeś, potrzebują co najmniej dwóch taktów zegara. Jeśli pomiędzy tymi taktami wystąpi przerwanie, operacja na takiej zmiennej będzie niepoprawna. U Ciebie taka sytuacja jest to wysoce prawdopodobna, bo operacje na zmiennej Timer1 to większość kodu w pętli głównej.

Aby temu zapobiec, w programie głównym w momencie dostępu do takiej zmiennej należy wyłączać przerwania. Spróbuj zrobić na przykład coś w tym stylu:[syntax=c]#include
#include

#define LED1 (1<#define LED1_OFF PORTB |= LED1;
#define LED1_ON PORTB &=~LED1;
#define LED1_TOG PORTB ^= LED1;

volatile uint16_t Timer1;

int main (void)
{
uint16_t kopia;

/* ##### PORT_B ################################################## */
DDRB |= LED1; // jako wyjscia
DDRD |= (1<
// ustawienie TIMER2
TCCR2 |= (1< TCCR2 |= (1< TCCR2 |= (1< OCR2 = 109; // dodatkowy podział
TIMSK |= (1<
sei();

while(1)
{
cli();
kopia = Timer1;
sei();

if(!kopia)
{
LED1_TOG;
kopia = 300;
}

cli();
Timer1 = kopia;
sei();
}
}

ISR(TIMER2_COMP_vect) //100kHz -> 10us
{
uint16_t n;

n = Timer1;
if (n) Timer1 = --n;
}[/syntax]

EDIT:
Widzę, że kolega Mirek mnie uprzedził, ale post może zostawię, bo chyba zapomniał o operacji porównania zmiennej Timer w warunku if.

Statystyki: Napisane przez andrews — 10 paź 2018, o 16:20

Re: Problem z timerem programowym

2018-10-10T16:19:38+01:00

Jeśli to jest aż tak istotne to trzeba wprowadzić atomowość po prostu, czyli zamień linię:

[syntax=c]Timer1 = 300;[/syntax]

na taką postać:

[syntax=c]uint8_t sreg = SREG;
cli();
Timer1 = 300;
SREG = sreg;[/syntax]

Statystyki: Napisane przez mirekk36 — 10 paź 2018, o 16:19

Problem z timerem programowym

2018-10-10T15:28:08+01:00

Cześć,
Robiłem projekt i musiałem wykorzystać timer programowy, niestety występowało nieregularne miganie diody, która powinna migać ze stały okresem. Chcąc sprawdzić o co chodzi napisałem uproszczony program do migania diodą i sprawdzić czy licznik sprzętowy działa poprawnie zmieniając stan wyjścia OC2. Timer sprzętowy okazuje się być ok. Problem jest wydaje mi się ze zmienną uint16_t. Atmega32 to 8 bitowy procesor i pewnie używa flagę przeniesienia. ustawiając wartość timera programowego na więcej niż 255 czyli tyle ile mieści jeden bajt zauważyłem, że wejście w warunek if występuje co 300 plus jeszcze 300-255. Co widać na zdjęciach z oscyloskopu.
Poniżej kod
[syntax=c]#include
#include

#define LED1 (1<#define LED1_OFF PORTB |= LED1;
#define LED1_ON PORTB &=~LED1;
#define LED1_TOG PORTB ^= LED1;

volatile uint16_t Timer1;

int main (void)
{
/* ##### PORT_B ################################################## */
DDRB |= LED1; // jako wyjscia
DDRD |= (1<
// ustawienie TIMER2
TCCR2 |= (1<TCCR2 |= (1<TCCR2 |= (1<OCR2 = 109;// dodatkowy podział
TIMSK |= (1<
sei();

while(1)
{

if(!Timer1)
{
LED1_TOG;
Timer1 = 300;
}
}
}

ISR(TIMER2_COMP_vect) //100kHz -> 10us
{
uint16_t n;

n = Timer1;
if (n) Timer1 = --n;
}[/syntax]
testowane na zestawie atb 1.04b

zdjęcie 1. przerwanie co 100kHz, wartość Timer1 = 300, czyli co 3ms zmiana stanu pinu.

zdjęcie 2. przerwanie co 100kHz, wartość Timer1 = 300, czyli co 3ms zmiana stanu pinu, dodatkowo mamy zmianę stanu co około 46us

zdjęcie 3. przerwanie co 100Hz, wartość Timer1 = 300, czyli co 3s zmiana stanu pinu.

zdjęcie 4. przerwanie co 100Hz, wartość Timer1 = 300, czyli co 3s zmiana stanu pinu, dodatkowo mamy zmianę stanu co około 460ms, jednak nie zawsze, "czasem" działa, widać to po 3 prawidłowych zmianach stanu pinu.

Dla wartości Timer1 < 256 działa poprawnie, tak jak pisałem jest pewnie problem z caryflag. Dzieliłem już zmienną 16bit na dwie ale to nie pomogło.
[syntax=c]uint8_t TL;
uint8_t TH;
while(1)
{
TL = (uint8_t) Timer1;
TH = Timer1 >>8;

if((TL == 0x00) && (TH == 0x00))
{
LED1_TOG;
Timer1 = 300;
}
}[/syntax]
Dostałem coś takiego:

Jak sobie z tym radzić, co robię źle?

Statystyki: Napisane przez sildurian — 10 paź 2018, o 15:28