Koledze rajmund96 nie działa, ale wie już, że to dlatego, że w linii: while( Tx_Head == Tx_Tail); ma zwiększoną już zmienną Tx_Head i funkcja obsługi przerwania ISR( USART0_UDRE_vect) działa inaczej. Można to tak napisać:

_________________
Dragonus Cracovus: Biomagia

No nie wierze . Ja się czuje jakbyśmy rozmawiali zupełnie innymi językami Oczywiści że jej UŻYWAM w przerwani Mirku musiałeś mnię zle zrozumieć NO właśnie wcale nie mam problemu z implementacją po prostu chciałem skrócić kod, ale NIE ZAUWAŻYŁEM, że jesli zrobię to w ten sposób który przedstawiłem w pierwszym poście to właśnie mogą się dziać dziwne rzeczy co opisałem z kolei w innym poście.

Czy wam nigdy nie zdarzają się pomyłki ? Ja jestem tylko początkującym więc mam chyba prawo się pomylić... ale to nie znaczy że nie rozumiem jak działa bufor cykliczny
No i znowu się nie zrozumieliśmy, ja wcale tej dodatkowej zmiennej lokalnej nie dodaje na wszelki wypadek i uważam że na przykład w przerwaniu odbiorczym mogłoby się obejść bez niej....

O a kolega Krauser to mnie troszkę zdziwił tym kodem i to podwójnie

Po pierwsze jak na moje oko to nic to nie zmienia bo przerwanie i tak może wstąpić między zwiększeniem zmiennej Tx_Head a przypisaniem danych do bufora mam racje ?

Po drugie co mnie jeszcze bardziej zdziwiło to przecież zmienna Tx_Head zostaje w funkcji zwiększona aż o 2 ?? po co ??

Jest tam taka pętla wstrzymująca program gdy bufor jest pełny:

właśnie w tym czasie bufor zostaje opróżniony przez funkcję obsługi przerwania nadawczego i funkcja może iść dalej.


Wcale nie zostaje zwiększona o 2. W pierwszym przypadku tylko porównywana jest wartość o 1 większa (Tx_Head zostaje takie jakie było). Dopiero w drugim przypadku gdzie jest znak "=" zmienna ta zostaje zmieniona.

W analizie swojego kodu musisz patrzeć i na funkcję send_data i na ISR( USART_UDRE_vect ). Jak w twojej funkcji send_data program zatrzymał się na:

to w jaki sposób przerwanie może wykonać kod w warunku:

i pobrać znak z bufora do rejestru UDR i zwiększyć Tx_Tail, aby warunek w pętli while stał się fałszywy ?

_________________
Dragonus Cracovus: Biomagia

O i wszystko zrozumiałe Krauser dzięki za wytłumaczenie .

------------------------ [ Dodano po: 18 minutach ]

Krauser, ale przecież może się wydarzyć skrajny przypadek kiedy to powiedzmy zostanie przekazany pierwszy znak, następnie zostanie włączone przerwani, ale przerwanie zanim się wykona (uruchomi się jego obsługa) to jeszcze wcześniej funkcja wysyłająca kolejny znak dotrze o do tego momentuczyli nie zostanie przypisana żadna dana buforowi, a mimo to indeks głowy się zwiększy. Następnie zostaje uruchomione przerwanie i klops bo przecież indeks jest zwiększony o 2 po funkcja wykonała się raz w całości a raz do momętu do którego napisałem że się może wykonać i wtedy przerwanie nie z zeruje flagi przerwania po wysłaniu pierwszego znaku, a zrobi to dopiero po wysłaniu kolejnego, a nasz kolejny znak nie jest przypisany czyli jest to 0 dobrze rozumuje ?

Istnieje takie niebezpieczeństwo. Ale powinno wystarczyć przestawienie instrukcji: najpierw przypisanie potem inkrementacja głowy. Ale znów w przypisaniu trzeba by wyliczać nową wartość głowy - i tu się przydaje zmienna tymczasowa.
Z drugiej strony, podobnież kompilator w toku optymalizacji może sobie instrukcje poprzestawiać. Może trzeba by te dwie instrukcje zamknąć w ATOMIC BLOCK? Trochę mało elegancko ale za to ze 100% pewnością.

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

xor wiem że najlepszym wyjściem jest zmienna lokalna tak tylko chcviałem się upewnić czy mam racje z tym tokiem mojego myślenia , a tak przy okazji co to jest ATOMIC BLOCK bo nie słyszałem o czymś takim ?

Zbiór makr wyłączających przerwania na czas wykonania kodu, który jest wewnątrz nich

_________________
Nie pisz komentarzy - dobry kod komentuje się sam.

chodzi o coś takiego :

Tak (tzn. do mniej-więcej czegoś takiego rozwija się ATOMIC_BLOCK), jeżeli nie lubisz się powtarzać to opakuj to w makro

_________________
Nie pisz komentarzy - dobry kod komentuje się sam.

Kiedyś napisałem na forum coś takiego topic2294.html