ATNEL tech-forum

Re: Timery , podstawa czasu

2021-03-15T21:58:40+01:00

Tak. Panowie właśnie uświadomiliście mi, że przerwania to 'rzecz' sprzętowa i mogą wystąpić w dowolnym momencie pętli while(1). Nie wiem co mi się ubzdurało, że zakładałem, że przerwanie zawsze powinno być na początki while(1). A co za tym idzie IFy zawsze powinny być wykonywane w takiej kolejności jakiej są napisane.

Więc wyglądało to tak, że np. dwa razy pod rząd mógł wykonać się odczyt temperatury (co zajmowało ~3ms) i było to już widoczne jako migotanie. A że zdarza się dość często to i migotanie jest widoczne. Za jakiś czas mogły wykonać się dwa wyświetlnia pod rząd (co akurat nie miałoby konsekwencji). Czasami mogły wykonywać się pokolei itd... Generalnie wszystkie możliwie kombinacje z których najgorsza ze względu na wyświetlanie jest kombinacja w której następuje odczyt temperatury 2x pod rząd.

W moim przypadku używam tylko tego jednego przerwania, więc rzeczywiście mógłbym wstawić 'wyświetlanie' do przerwania, ale dla czytelności pozostawię je w while(1) w IFie (czyli tak jak miałem przed napisaniem tego posta).
Myślę, że na tą chwilę wszystko jest jasne.
Dzięki.

Statystyki: Napisane przez qutrit — 15 mar 2021, o 21:58

Re: Timery , podstawa czasu

2021-03-15T18:17:12+01:00

adamma25 napisał(a):

W zasadzie to mógłbyś obydwie funkcje umieścić w przerywaniu

Nie jest to dobre rozwiązanie. Czas wykonywania przerwania powinien być jak najkrótszy.
W przypadku AVR'ów, gdzie nie można ustawić priorytetów przerwań, kod umieszczony w przerwaniu blokuje inne przerwania.
Przy bardziej wymagających projektach takie podejście może być źródłem problemów.
W przypadku tego projektu, obsługę LCD w przerwaniu ze względu na wysoki priorytet da się jeszcze obronić, natomiast wrzucanie do przerwania jeszcze obsługi odczytu temperatury nie jest już najlepszym pomysłem. (Co nie znaczy, że to nie będzie działać).
Rozwiązanie autora z jednym if'em jest lepszym rozwiązaniem. Eliminuje problem migania LCD, a nie blokuje innych przerwań o ile takich używa.

Statystyki: Napisane przez auers — 15 mar 2021, o 18:17

Re: Timery , podstawa czasu

2021-03-15T16:36:15+01:00

A gdybyś funkcję wyświetl () umieścił w procedurze obsługi przerwania? Wtedy zawsze wykona się w odpowiednim czasie ?

------------------------ [ Dodano po: 6 minutach ]

W zasadzie to mógłbyś obydwie funkcje umieścić w przerywaniu

Statystyki: Napisane przez adamma25 — 15 mar 2021, o 16:36

Re: Timery , podstawa czasu

2021-03-13T20:26:32+01:00

Spróbuję jeszcze raz Ci to wyjaśnić.
Przerwanie timera może wystąpić w dowolnym momencie pętli głównej.
Jeżeli trafisz, że wywoła się przed 1 if'em lub za 2-gim to wszystko jest zgodnie z twoim założeniem, najpierw wywoła się if nr 1 potem nr 2.
Natomiast jeżeli przerwanie trafi się pomiędzy if'ami. Pierwszy if się już nie wykona. W międzyczasie zmieniają się wartości zmiennych timer. Drugi If' już jest spełniony i wywołuje funkcje z drugiego warunku, w twoich przypadkach obsługa odczytu temperatury. Następuje kolejny obieg pętli i dopiero wtedy wykonuje się pierwszy z if'ów z obsługą wyświetlacza.
Stąd oba if'y zawsze się wykonują. Kolejność uzależniona od miejsca w którym wywoła się przerwanie.
Dla zobrazowania wstawiam info o miejscu przerwania w kodzie:
[syntax=c]while (1) {
if(!test) {
wyswietl(); //wywolanie tej funkcji nastąpi dopiero w kolejnym obiegu pętli po wystąpieniu przerwania
test=1;
}
// Tu może pojawić się przerwanie - które zamienia kolejność wywołania if'ów//
if (!test1) {
odczytajTemperatury(); // wtedy najpierw wywoła się ta funkcja
test1 = 1;
}[/syntax]

Niestety w twoim przypadku czas wykona procedury odczytu temperatury zakłóca wówczas obsługę LCD.

Statystyki: Napisane przez auers — 13 mar 2021, o 20:26

Re: Timery , podstawa czasu

2021-03-13T20:13:50+01:00

Nie wykonują się w losowy sposób! "Zmiana" jest wtedy, kiedy "wyzeruje" Ci się zmienna test1 pomiędzy sprawdzeniem warunków, czyli if(!test) -> przerwanie, w którym test=0 i test1=0 -> if(!test1)

Statystyki: Napisane przez Marhef — 13 mar 2021, o 20:13

Re: Timery , podstawa czasu

2021-03-13T20:07:53+01:00

auers napisał(a):

Quote:

Powyższe zachowanie jest wynikiem zmiany kolejności wykonywania IFów. Ale jak pisałem powyżej, one nie są 'gubione' tylko wykonywane są tak jakby w losowy sposób ale zawsze oba.

Już Ci napisałem z czego to wynika.

Aby się tego pozbyć możesz zrobić tak:
[syntax=c]main() {
volatile uint16_t test, test1;
...
.
while (1) {
if(!test) {
wyswietl();
if (!test1) {
odczytajTemperatury();
test1 = 400;
}
test=1;
}[/syntax]

Oczywiście musisz zmienić procedurę odczytu temperatury.

No właśnie nie zabardzo widzę z czego to wynika To co napisałeś jest obejściem problemu. Podobne obejście przedstawiłem powyżej tj:
[syntax=c]while (1) {
if(!test) {
wyswietl();
odczytajTemperatury();
test=1;
}[/syntax]

To też działa bardzo dobrze (temperatury się odczytują wyświetlacz nie miga) i nie muszę nic zmieniać. Tak miałem zanim napisałem ten post.

Chciałbym aby ktoś mi wyjaśnił to, to co napisałem w poście -> "Napisane: wczoraj, o 23:23". W skrócie: dlaczego dwa IFy które nic nie robią (oprócz 'delay' aby było widać w analizatorze) wykonują się w losowy sposób ?

Statystyki: Napisane przez qutrit — 13 mar 2021, o 20:07

Re: Timery , podstawa czasu

2021-03-13T12:57:34+01:00

Quote:

Powyższe zachowanie jest wynikiem zmiany kolejności wykonywania IFów. Ale jak pisałem powyżej, one nie są 'gubione' tylko wykonywane są tak jakby w losowy sposób ale zawsze oba.

Statystyki: Napisane przez auers — 13 mar 2021, o 12:57

Re: Timery , podstawa czasu

2021-03-13T12:31:04+01:00

Spróbuję to rozwiąć.
Podstawa czasu 2.5ms jest graniczną dla wyświetlacza (8 sztuk 7segmentów). Każdy case x: z odczytTemeratury(); (kod powyżej) zajmuje ~0.5ms - więc spokojnie się mieści w podstawie czasu 2.5ms

Powinno być tak:
pierwszyIF -> wyswietl(); + drugiIF->odczytTemeratury(); + pozostały czas do następnego przerwania. I tak powinno być cały czas.

Ale jeżeli:
pierwszyIF->wyswietl(); + drugiIF->odczytTemeratury(); + pozostały czas do następnego przerwania
I teraz jeśli z jakiś powodów znowu:
drugiIF->odczytTemeratury(); [to 'zabiera on' 0.5ms] + pierwszyIF->wyswietl(); + pozostały czas do następnego przerwania

Dwa 'drugieIFy' powyżej trwają łącznie 3ms i to już jest widoczne jako migotanie.
Albo inaczej pisząc na wykonanie 'pierwszychIFów' powyżej trzeba czekać powyżej 3ms, co jest już widoczne jako migotanie.
Powyższe zachowanie jest wynikiem zmiany kolejności wykonywania IFów. Ale jak pisałem powyżej, one nie są 'gubione' tylko wykonywane są tak jakby w losowy sposób ale zawsze oba.

Nie wiem czy bardziej wyjaśniłem czy zamotałem ale starałem się jak mogłem.

------------------------ [ Dodano po: 14 minutach ]

auers napisał(a):

qutrit napisał(a):

Ta zmiana kolejności wykonywania ifów w rzeczywistości powoduje migotanie LED. Dlaczego ta zamiana występuje ? Zawsze wykonywane są oba ify, tylko czasami następuje zmiana kolejności ich wykonywania.

Sama zmiana kolejności sterowań przekaźnikami, przy takim kodzie jest możliwa.
Jeżeli przerwanie wykona się po pierwszym if'ie najpierw wywoła się obsługa przekaźnika2, a w następnym obiegu pętli dopiero obsługa przekażnika1.

------------------------ [ Dodano po: 36 minutach ]

Powinieneś trochę zmienić podejście do obsługi zadań związanych z wyświetlaczem i odczytem danych.
Jeżeli masz wyświetlacz LCD, który obsługujesz przez multipleksowanie, to priorytetem jest obsługa tego wyświetlacza a nie odpytywanie temperatury.
W zależności od czujnika i czemu to ma służyć, temperaturę możesz odpytać np. raz na sekundę (przy DS18B20 i tak nie wiele szybciej możesz to zrobić). Szkoda zakłócać wyświetlacz obsługą DS'a.
Same if'y zostaw tak jak masz i będzie dobrze.
Ustaw tylko wartość test1 nie na 1 a np. na 400 i daj znać jaki jest efekt.

wlacz/wylaczPrzekaznikx() - służuły mi teraz to podłaczenia analizatora. Same przekaźniki na ten czas były oczywiście odłączone. Tylko nazwy funkcji pozostały.
Generalnie muszę odczyt temepratury podzielić na fragmenty, bo na raz się nie da. Tzn. wykonując wszystkie komendy raz/sekunde będę miał migotanie co sekunde (może i rzadziej niż teraz ale za to bardziej widzoczne).
"Ustaw tylko wartość test1 nie na 1 a np. na 400 i daj znać jaki jest efekt." Coś podobnego realizuję w 'case KONWERSJA_CZAS' w funkcji odczytTemeratury() (kod powyżej) ale też zamieszczam poniżej:
[syntax=c]case KONWERSJA_CZAS:
if (++zmiennaPomocnicza > 400) { // czekamy na konwert ~400x2.5ms = 1000 ms)
zmiennaPomocnicza = 0;
czyKonwertowac = 0;
procedura = RESET;
}
break;[/syntax]

To znaczy zanim przejdzie mi do następnego case ( w tym przypadku powrót do case RESET:) to ten case KONWERSJA_CZAS wykona się 400 razy. Co w sumie i tak sprowadza się do odczytu temepratury co ~1sekunde.
Jak zauważyłem to zmiana kolejności wykonywania IFów następuje głównie w momencie wysyłania/odbierania danych z DSa. Przyczym jak pisałem powyżej IFy nie są gubione.
Tak jak pisałem powyżej. Jeżeli to migotanie w jakiś sposób zależałoby od funkcji wyswietl(); i odczytTemeratury(); to efekt byłby widoczy również w sytuacji gdy obie funkcjie umieszcze są w jednym IFie. A w tym przypadku efekt migotania nie występuje. Pojawia sie tylko po umieszceniu tych funkcji w osobnych IFach.

Statystyki: Napisane przez qutrit — 13 mar 2021, o 12:31

Re: Timery , podstawa czasu

2021-03-13T10:53:28+01:00

qutrit napisał(a):

Statystyki: Napisane przez auers — 13 mar 2021, o 10:53

Re: Timery , podstawa czasu

2021-03-13T10:33:59+01:00

micky napisał(a):

Jakie masz ustawione próbkowanie analizatora?

Sample rate: 12MS/s

Ale samo próbkowanie to jedno. Drugą kwestią jest to, że widać ten efekt poprzez migotanie LED.

Statystyki: Napisane przez qutrit — 13 mar 2021, o 10:33

Re: Timery , podstawa czasu

2021-03-13T07:19:19+01:00

Jakie masz ustawione próbkowanie analizatora?

Statystyki: Napisane przez micky — 13 mar 2021, o 07:19

Re: Timery , podstawa czasu

2021-03-12T23:23:01+01:00

auers napisał(a):

Szukasz błędu nie tam gdzie trzeba.
To na pewno nie if'y są przyczyną twoich problemów.

Właśnie chyba nie do końca. Taki oto kod:
[syntax=c]while (1) {
if(!test) {
wylaczPrzekaznik1();
_delay_us(50);
wlaczPrzekaznik1();
test=1;
}

if (!test1) {
wylaczPrzekaznik2();
_delay_us(50);
wlaczPrzekaznik2();
test1 = 1;
}
}[/syntax]
Daje taki output. Nie wiem dlaczego, co jakiś czas następuje zmiana kolejności wykonywania ifów (pomarańczowa ramka).

Ta zmiana kolejności wykonywania ifów w rzeczywistości powoduje migotanie LED. Dlaczego ta zamiana występuje ? Zawsze wykonywane są oba ify, tylko czasami następuje zmiana kolejności ich wykonywania.
Takie zachowanie też tłumaczy dlaczego migotania nie ma gdy funkcje odczytTemperatury(); i wyswietl(); umieszczone są w jednym ifie.

Statystyki: Napisane przez qutrit — 12 mar 2021, o 23:23

Re: Timery , podstawa czasu

2021-03-11T19:58:50+01:00

Szukasz błędu nie tam gdzie trzeba.
To na pewno nie if'y są przyczyną twoich problemów.

Statystyki: Napisane przez auers — 11 mar 2021, o 19:58

Re: Timery , podstawa czasu

2021-03-11T19:18:24+01:00

auers napisał(a):

A nie zrobiłeś przypadkiem ISR wewnątrz pętli while() ?

Nie. Nie zrobiłem ISR wewnątrz pętli. W moim pierwszym poscie jest błąd. Ostatnia klamra powinna być nad ISR. Sorry ale chciałem umieścić, to co najistotniejsze i źle usunąłem klamry.

Statystyki: Napisane przez qutrit — 11 mar 2021, o 19:18

Re: Timery , podstawa czasu

2021-03-11T18:39:49+01:00

A nie zrobiłeś przypadkiem ISR wewnątrz pętli while() ?

Statystyki: Napisane przez auers — 11 mar 2021, o 18:39

Re: Timery , podstawa czasu

2021-03-10T23:35:24+01:00

"A jakie wartości mają nadane zmienne test i test1?" Nawet jak przypiszę wartości test=0 i test1=0 to nic nie zmienia. Nadal jak funkcje są w osobnych ifach to jest migotanie wyświetlaczy.

Oto wywoływane funkcje:
void odczytajTemperatury(void):
W jednym przerwaniu ~2.5ms wykonywany jest jeden case (zwykle case skłąda się z: wysłanie polecenia -> zmiana czujnika -> wysłanie polecenia).
Kiedyś mierzyłem i każdy case mieścił się w 2.5ms. Chyba będę musiał jeszcze raz to pomierzyć, jeżeli nikomu nic nie przyjdzie do głowy.

[syntax=c]void odczytajTemperatury(void) { // podzielona na case aby byla szansa wyslania/odebrania instrukcji w czasie przerwania tj.~2.5ms
static uint8_t czujnik = DS_ZRODLO;
static uint8_t daneZCzujnuka[9];
static int16_t temperatura[2] = {BLAD_CZUJNIKA, BLAD_CZUJNIKA};
static int16_t zmiennaPomocnicza;
static int8_t czyKonwertowac = 1;

switch (procedura) {
case RESET:
resetDS(czujnik);
zmienCzujnikPowtorzProcedure(&czujnik);
break;

case SKIP:
wyslijBajt(DS_SKIP, czujnik);
zmienCzujnikPowtorzProcedure(&czujnik);
break;

case KONWERT_POLECENIE:
if (czyKonwertowac == 1) {
wyslijBajt(DS_CONVERT, czujnik);
pasozytStart(czujnik);
zmienCzujnikPowtorzProcedure(&czujnik);
} else {
procedura = ODCZYT_POLECENIE;
}
break;

case KONWERSJA_CZAS:
if (++zmiennaPomocnicza > 400) { // czekamy na konwert ~400x2.5ms = 1000 ms)
zmiennaPomocnicza = 0;
czyKonwertowac = 0;
procedura = RESET;
}
break;

case ODCZYT_POLECENIE:
wyslijBajt(DS_READ_SCRATCHPAD, czujnik);
zmienCzujnikPowtorzProcedure(&czujnik);
break;

case ODCZYTUJ:
daneZCzujnuka[zmiennaPomocnicza] = odczytajBajt(czujnik); // daneWyjsciowe dopoki....
if (++zmiennaPomocnicza > 8) { //.... daneWyjscioweasz 9 bajtow , wtedy przejdz do obliczen
uint8_t indeksTablica = czujnik == DS_ZRODLO ? ZRODLO : ODBIOR;
if (crc8(&daneZCzujnuka[0], 9) == 0) {//jezeli CRC sie zgadza
temperatura[indeksTablica] = (daneZCzujnuka[0] | (daneZCzujnuka[1] << 8)) * MIEJSCA_PO_PRZECINKU >> 4;
} else {
temperatura[indeksTablica] = BLAD_CZUJNIKA; // blad CRC- konkretnego czujnika
}
zmiennaPomocnicza = 0;
zmienCzujnikPowtorzProcedure(&czujnik);
}
break;

case POLICZ:
temperaturyBledy(temperatura);
czyKonwertowac = 1;
procedura = RESET;
break;
}
}

static void zmienCzujnikPowtorzProcedure(uint8_t *czujnik) {
if (*czujnik == DS_ZRODLO) {
*czujnik = DS_ODBIOR;
} else {
*czujnik = DS_ZRODLO;
procedura++;
}
}[/syntax]

Oraz funkcja wyswielt(): Wysiwetlacz to jest taki moduł do którego wysyłamy 2 bajty. PIerwszy bajt aktywuje dany wyświetlacz a drugi bajt to dane na ten wyświetlacz.
[syntax=c]static inline void wyswielt(void) {
static uint8_t wyswietlacz = 0;
spiSend16bits(daneSpi(wyswietlacz));
if (++wyswietlacz > 7) {
wyswietlacz = 0;
}
}[/syntax]

Statystyki: Napisane przez qutrit — 10 mar 2021, o 23:35

Re: Timery , podstawa czasu

2021-03-10T15:48:03+01:00

A jakie wartości mają nadane zmienne test i test1?

Statystyki: Napisane przez janusz17 — 10 mar 2021, o 15:48

Re: Timery , podstawa czasu

2021-03-10T11:49:56+01:00

Zbyt dużo czasu mikrokontroler spędza w procedurze odczytajTemperatury(). Można zrobić profilingm, aby to sprawdzić. Być może procedura ta blokuje multiplexowanie (bo chyba, w taki sposób obsługiwany jest wyświetlacz). Proszę powiedzieć coś więcej o odczytajTemperatury();

Statystyki: Napisane przez Draxter32 — 10 mar 2021, o 11:49

Re: Timery , podstawa czasu

2021-03-10T10:37:32+01:00

Nie wiem, ale coś może być w tych funkcjach. ?

Statystyki: Napisane przez adamma25 — 10 mar 2021, o 10:37

Timery , podstawa czasu

2021-03-09T20:59:47+01:00

Witam,
Mam taki oto kod - dlaczego w tym przypadku wyświetlacz LED (8xLED) miga ?
[syntax=c]main() {
volatile uint8_t test, test1;
TCCR0A |= (1 << WGM01);
TCCR0B |= (1 << CS02) | (1 << CS00); // 1024
TIMSK0 |= (1 << OCIE0A);
OCR0A = 20; //20-> 2.5ms
sei();
....
while (1) {
if(!test) {
wyswietl();
test=1;
}

if (!test1) {
odczytajTemperatury();
test1 = 1;
}
.....
ISR(TIM0_COMPA_vect) {
uint16_t x;
x = test;if (x)test = --x;
x = test1;if (x)test1 = --x;
}
}[/syntax]

a w takim przypadku nie miga:
[syntax=c]main() {
volatile uint8_t test, test1;
TCCR0A |= (1 << WGM01);
TCCR0B |= (1 << CS02) | (1 << CS00); // 1024
TIMSK0 |= (1 << OCIE0A);
OCR0A = 20; //20-> 2.5ms //OCR0A = 78; //dla 10ms wychodzi 78 bo 8MHz/preskaler(1024)/odsiwezanie(100Hz)
sei();
....
while (1) {
if(!test) {
wyswietl();
odczytajTemperatury();
test=1;
}
.....
ISR(TIM0_COMPA_vect) {
uint16_t x;
x = test;if (x)test = --x;
}
}[/syntax]

Dlaczgo jak wyswietl(); i odczytajTemperatury(); są wywoływane w osobnych ifach (pierszy kod) to LED miga ?
A gdy wyswietl(); i odczytajTemperatury(); są wywoływane w jednym ife (drugi kod) to LED nie miga ?
Dzięki za odpowiedzi.

Statystyki: Napisane przez qutrit — 9 mar 2021, o 20:59