Administrace komentářů

V prvom rade treba vsetko, co je pristupne z prerusenia, deklarovat ako volatile. Bez toho compilator nerata, ze hodnota sa moze zmenit mimo kontext aktualneho kodu. Kompilator moze optimalizovat kod tak, ze si udaje drzi v registroch a necita udaje z pamate. Tym padom zmena z prerusenia nie je reflektovana v hlavnej slucke kodu.

Druha vec je, ze napr do "Cnt" zapisujes aj pocas prerusenia aj mimo neho. Taky kod musi byt spravne zabaleny do tzv. "ATOMIC_BLOCK". Inac povedane, funkcia FifoGetByte by mala docasne vypnut prerusenie a zapnut ho az ked su vsetky zmeny zapisane do pamate. V opacnom pripade moze nastat situacia, ze funkcia "FifoGetByte" a "FifoAddByte" sa bude prelinat a navzajom si prepisu data. Situacia, ked sa napr. nacitaju data pre if a/alebo dekrementaciu. V preruseni dojde k zmene udajov, ale k naslednemu zapisu dojde podla pred tym nacitanych dat a nie realnych .... o tomto by sa dalo dlho hovorit. Ked si pohladas "ATOMIC_BLOCK" v avr-gcc dokumentacii tak najdes hromadu roznych prikladov, preco sa to ma pouzivat.

Este co sa tyka kodu samotneho. Doproucujem pouzivat tzv. "Exact-width integer types", namiesto char/int/word/etc. ... vasina AVR procesorov je 8bit. Ak je mozne, tak je dobre drzat premene na velkosti 8bit. Vsetko vacsie znamena navyse instrukcie (spomalenie kodu), ale hlavne rozdelenie operacii na viacej krokov. Kym napr inkrementacia 8bit hodnoty bude na jeden krok (instrukciu), tak 16bit hodnota musi byt rozdelena na niekolko dalsich instrukcii. Ak pocas toho este dojde aj k preruseniu, tak je dalsi problem na svete. Nechce sa mi to teraz hladat, ale mam pocit, ze word bude 16bit, co si myslim, ze je aj tak vela na FIFO pre AVR.

"Exact-width integer types" maju format int8_t (so znamienkom), uint8_t (bez znamienka) az po 64 (8, 16, 32, 64).