Zła.
Chodzi właśnie o coś dokładnie odwrotnego, aby ewentualne przerwanie nie mogło się wykonać. Przeważnie rozkazy wykonują się od razu. Gdyby tak było to sekwencja:
SEI
ZAPIS PORTU
byłaby ryzykowna, po po SEI mogłoby wykonać się przerwanie, które mogłoby zmodyfikować stan portu. Błąd byłby ciężki do znalezienia to rzadki ale w AVR, zaraz po SEI nie może wykonać się przerwanie, dopiero w kolejnym rozkazie co gwarantuje, ze przerwanie nie zmodyfikuje stanu portu przed jego zapisem. W praktyce zadział to jak sekwencjia
ZAPIS PORTU
SEI
w innych CPU ale nie pytaj jakich bo nie pamiętam wiele z dawnych CPU. Coś tam mi świta, że w Z-80 zaraz po DI (blokada przerwań) modło być wykonanie przerwanie (nie wiem czy we wszystkich trybach czy tylko w IM2 - wektoryzowane) a 6502 odblokowanie przerwań miało skutek natychmiastowy.

Kiedyś zabieg z wykonaniem rozkazu zaraz po odblokowaniu przerwań był używany w pracy krokowej. Na NMI wymuszało się L. CPU prawie cały czas był w przerwaniu. Wykonanie kroku to opuszczenie przerwania gdzie w po przywróceniu znacznika przerwania (W 6502 był on na stosie, w rejestrze stanu, umieszczany sprzętowo, w Z-80 osobny przerzutnik) musiał wykonać się jeden rozkaz po którym program ponownie skakał w przerwanie. Nie pamiętam czy przypadkiem nie taki mechanizm był w CA-80 ale naprawdę wiele lat minęło.

------------------------ [ Dodano po: 34 minutach ]

Od siebie jeszcze dodam, ze w ARM nie używam ATOMIC_BLOCK. Blokuję w NVIC tylko przerwania, które mogłyby przeszkadzać. W AVR takie rozwiązanie raczej się nie przyda. Przerwania są blokowane głównie po to, aby nie zakłócić jakiś krytycznych czasowo funkcji np generowania bitu dla WS2812. Przy czasie impulsu 400ns przerwanie trwające kilka us rozwali wszystko. Nawet wolna transmisja 1-Wire też będzie szwankować. W ARM z reguły to nie problem, bo jest dziesiątki jak nie setki razy szybszy od AVR (taki H743 może być taktowany nawet 480MHz a są i takie co 600MHz mają). W ARM przerwania się blokuje gdy np i w przerwaniu i w programie głównym modyfikuje się np rejestry UART. W takiej sytuacji wystarczy jednak zablokować przerwania od UART.

W AVR też może być podobna sytuacja np licznik wielo bajtowy w przerwaniu. Aby go odczytać w programie głównym trzeba zatrzymać przerwania ale zamiast wyłączać wszystkie wystarczy zablokować przerwanie od timera modyfikującego licznik.

Jest też prosta metoda aby One Wire czy WS2812 na AVR obsłużyć w przerwaniu. Tak jak w przypadku One Wire są dwa rozwiązania czyli timer albo UART tak w przypadku WS2812 SPI lub UART. W necie można znaleźć przykłady a dla One Wire przez UART to nawet Maxim wydał odpowiednią notę katalogową. Szczegóły można tam przeczytać a w skrócie, to ustawia się UART na 9600 Zapisuje FF i sprawdza co wróciło (TX-RX jest zapętlone przez bufor OC). Jak FF to nie zgłosił się slave, jak inna wartość to było zgłoszenie. Komunikacja podobnie tyle, że na 115200. Wysłanie 1 to zapis FF, zera to zapis 0. Odczytanie bitu to zapis FF i odczyt, jak FF to slave zwraca 1, jak <> od FF to zwrócił 0.
Proste a działa na każdym mikrokontrolerze. Próbowałem na AVR, ARM wiem, że działa na porcie COM PC powinno na konwerterze USB-UART ale nie próbowałem. Można sobie zorganizować komunikację w tle (na przerwaniach). WS2812 zarówno na AVR jak i ARM próbowałem na SPI i UART. Działa na przerwaniach ale na AVR lepiej robić to na UART.

ProgramistaAVR czy to dobra odpowiedź? Śledzę ten wątek i uważam, że jest mega ważny i interesujący ale nie wiem czy wszystko dobrze rozumiem a bardzo bym chciał rozumieć

A to dlatego aby przerwanie mogło jeszcze zmodyfikować stan pinu/portu przed zapisem

zasem, aby szybko coś sprawdzić robię to na Arduino. Jak działa, to mam np gotowe, choć niedoskonałe funkcje ale w połączeniu z notą katalogową układu/modułu mogę szybko taki kod przenieść na ARM.

Chyba wystąpię do pracodawcy o dodatek do pracy w szkodliwych warunkach jakim jest Arduino.

Chyba wystąpię do pracodawcy o dodatek do pracy w szkodliwych warunkach jakim jest Arduino.

Nie sprawdzałem tego w andruino - ale jeśli jest tak jak piszesz - i sprawdziłeś to dokładnie - to jakaś masakra. Nie sądziłem że aż tak można spierniczyć sprawę ale też byłaby to kolejna cegiełka do tego dlaczego ludziom w tym andruino zawsze coś się sypie w tych programach.

Prawdopodobnie dlatego, żeby skrócić czas wyłączenia przerwań (czyli czas reakcji na przerwanie) do minimum. Zgodnie z deklaracją producenta:
Atmel/Microchip napisał(a):
The instruction following SEI will be executed before any pending interrupts.
która gwarantuje, że instrukcja następująca bezpośrednio po instrukcji SEI (czyli w tym przypadku zapisanie zmodyfikowanej wartości z powrotem do portu) zostanie wykonana przed wejściem mikrokontrolera w procedurę obsługi przerwania (nawet jeśli to przerwanie już oczekuje na realizację).

Jedyny przypadek, kiedy miałoby to sens, to duże AVR gdzie porty są poza SFR, w obszarze, w którym inne AVR maja SRAM. W takiej sytuacji ustawianie czy kasowanie pinu to 3 rozkazy.

[syntax=asm]//
CLI
IN R16, PORTD // POBIERZ
ORI R16, 0x02 //ZMODYFIKUJ (AND/OR)
SEI
OUT PORTD, R16 //ZAPISZ[/syntax]
Dlaczego sei jest przez zapisem portu?

The instruction following SEI will be executed before any pending interrupts.

Dlaczego sei jest przez zapisem portu? Przecież może się zdarzyć, że po sei nasąpi przerwanie, które zmodyfikuje zawartość portu. Po zakończeniu przerwania port zostanie ustawiony zawartością ustalona w programie głównym, więc to co zostało zrealizowane w przerwaniu, nie odniesie skutku, ściślej odniesie na krótką chwilę.
Logika podpowiada, że sei powinno być po zapisie do portu.

bezzsensowne jest zatem wyłączanie i to w zły sposób przerwań.

Co dlaczego?

Dlaczego? Kto wie?

W arduino przeglądałem jak działają funkcje "pod spodem" i funkcja "digitalWrite" na którą zawsze wszyscy narzekają, że jest wolna jak porównują arduino i natywne C w środku zawsze przed ustawieniem pinu deaktywuje przerwania i potem je uruchamia.
Pierwszy raz się spotkałem z tym i musiałem się zastanowić nad celem tego - przyzwyczaiłem się do makr ustawiających piny jak w BB gdzie nigdy nie dodawało się tego, jednak po przemyśleniu wydaje mi się, że powinny one też być "otoczone" cli() i sei(). Zabezpiecza to przed tym gdy podczas wystawiania danych na port odczytamy coś z portu, a w czasie tego wejdziemy w przerwanie,

czyli te "podstawowe" ustawianie pinów przez makra zostanie zamienione na sbi i cbi, a stan portu nie będzie czytany i po problemie

Zabezpiecza to przed tym gdy podczas wystawiania danych na port odczytamy coś z portu, a w czasie tego wejdziemy w przerwanie, które też coś ustawia na danym porcie i w efekcie możemy nadpisać tamtą wartość - dobrze to rozumiem?

Poza tym - w prockach AVR wiele operacji dostępu do pinów portów jak chodzi o pojedyncze piny wykonać można w sposób atomowy o ile wiesz co to oznacza. Krótko mówiąc po to są w asemblrze AVR taki rozkazi jak sbi czy cbi żeby było to możliwe i kompilator C z tego korzysta garściami. W takich przypadkach stosowanie cli i sei przed i po jest po prostu czystym nonsensem. A w andruino jak mówiłem jest jeszcze pierdyliard innych nonsensów więc nie wymagaj żeby je wszystkie tutaj opisywać bo szkoda czasu. Lepiej się pouczyć C;) będzie on wtedy lepiej spożytkowany.

liczyłem na jakieś wyjaśnienie tego problemu/dyskusję

myśl i pisz program tak jak tego wymaga projekt

Tak jak będziesz robił andruino II ostatnia krew - to wtedy możesz dodać w przeciwnym wypadku myśl i pisz program tak jak tego wymaga projekt

Jak robimy uniwersalnie bibliotekę