T.M.F. pisze:
>>> A po co mam zapamietywac jej stan?
>>
>> Bo przerwanie, które właśnie wpuściłeś w połowie obsługi innego
>> przerwania z powrotem ci tą flagę odblokuje.
>
> Znowu manipulujesz. Napisalem, ze przy jednopoziomowej obsludze jest to
> niepotrzebne. Przy wielopoziomowej jest to konieczne

Przecież rozmawiamy o emulacji priorytetów przerwań, czyli z automatu
można założyć, że są sytuacje gdy jedne przerwania przerywają drugie, a
nawet trzecie. Zresztą problem nie pojawia się tylko wtedy gdy kilka
przerwań wchodzi na siebie. Czasem trzeba wyłączyć przerwanie na czas
rekonfiguracji peryferiów, czasem potrzebna jest sekcja krytyczna z
wyłączonym konkretnym przerwaniem (a nie wszystkimi). Zakładanie z góry,
że flaga przerwania jest zawsze ustawiona, to proszenie się o kłopoty.

>> A co mnie obchodzi 51? To jest jedyny procesor z priorytetami przerwań?
>
> A o jakiej rodzinie rozmawiamy? Bo mam wrazenie, ze '51 vs. AVR.

Nie, próbowałeś udowodnić, że priorytety przerwań nie są potrzebne, bo
je sobie możesz wyrzeźbić w sofcie.

>>> Programowo to tak samo skomplikowane jak zabawa z rejestrami, zeby
>>> ustawic kontroler. Zreszta w ogole tego nie zauwazam, bo mi to
>>> zalatwia klasa napisana w C++, ktora jest skladnikiem HAL w moim
>>> projekcie.
>>
>> A co to ma do rzeczy jeśli chodzi o czas wykonania albo o konieczność
>> napisania tego?
>
> Napisac raz i zapomniec.

Czy ma to wpływ na czas wykonania przez procesor?

>> Czytaj z uwagą. Pisałeś wcześniej, że możesz odblokować przerwania na
>> samym, początku. Trzeci raz ci piszę, że nie możesz, bo coś z tym
>> uartem musisz zrobić zanim odblokujesz przerwania.

> w samej procedurze obslugi przerwania UART (i tylko w tej) musze przed
> odblokowaniem zlikwidowac przyczyne, czyli np. odebrac znak.

No nareszcie za którymś razem zrozumiałeś. Czyli jednak nie możesz
odblokować przerwań na samym początku, tak jak to wcześniej proponowałeś.