> pamiętać. Podejście typu "muszę mieć wszystko pod kontrolą" niczym się
> nie różni od pisania w asm i świadczy o ubogim warsztacie.
Tu bym się nie zgodził.
Spotkamy się tu za 20 lat i ubogim warsztatem okaże się Twój C++.
Zresztą niektórzy twierdzą, że już tak jest.
Warsztat to chyba nie jest dobre słowo na metody pracy.
Wydaje mi się, że mieszasz. Uznajesz, że wybór języka programowania
wpływa na warsztat.
Na to jest już szereg innych określeń: inteligencja, umiejętność myślenia
przestrzennego,
dobra realizacja zadań. I moim zdaniem nie ma to kompletnie nic wspólnego
z rodzajem języka, którego używasz.
Choć, przyznaję, nauka kolejnego może rozwijać "warsztat".
Zupełnie tak samo, jak nauka budowy kolejnego ukontrolera.
A ja właśnie piszę w ASM tak gdzieś od 28 lat mniej więcej.
Mój warsztat jest bardzo "ubogi":
1) kod jest napisany zwięźle i czytelnie.
2) czysty kod rzadko przekracza kilka kB. Jeśli już, to są to szybkie
tablice LUT.
3) każda linijka ma swój komentarz.
4) nigdy nie analizuje kodu w ASM. Nie używam klawiszy Page Up/Down w tym
celu.
5) strukturę logiczną kodu mam zawartą w przestrzeni 2 wymiarowej w postaci
algorytmu
lub innych form zapisu, takich jak tabela stanów, opis struktur danych itp.
6) samo kodowanie sprowadza się do zamiany bloków logicznych na mnemoniki
konkretnego mikrokontrolera 8,16,32 bitowego
7) kodowanie jest czynnością przyjemną choć dość prymitywną.
8) najprzyjemniejsze jest uruchamianie. IDE mnie interesuje tylko w celu
postawienia Breakpointa i odczytanie stanu procesora.
9) cała analiza opiera się na oglądaniu kolorowych algorytmów.
10) przy moim toku pracy nie interesuje mnie na jaki typ procesora piszę.
Może być to MICROCHIP, Freescale, 8051core, MIPS - cokolwiek.
W szczególności nie interesuje mnie nawet język programowania.
Mógłby to być C++ czy C bez różnicy.
Tylko tak się składa, że asm sprawdza się najlepiej.

I teraz. Twój przykład mnie po prostu zastrzelił.
Nie pamiętam kiedy używałem w ogóle całkowitego blokowania przerwań.
(twoje cli())
Ja je najczęściej tylko włączam na początku kodu po włączeniu zasilania.
Cała reszta oparta jest na logicznym przemyśleniu sposobu wykorzystania
sprzętu.
Ważna jest komunikacja POP (ISR) i programu głównego.
Czasem ważne są priorytety przerwań.

W związku z powyższym proponuję zmienić przykład, gdyż usiłuje on udowodnić,
że:
1) wyższość jednego sposobu komunikacji (tutaj niby C++) nad drugim
(C )polega na tym, że wygodniej jest wyłączać przerwania, co jest po prostu
dość śmieszne.
Poniekąd wskazał to też kolega, który twierdzi, jeśli dobrze zrozumiałem,
że woli sobie sam decydować, gdzie włączyć, a gdzie wyłaczyć przerwania.
A okazuje się, że nikt się nie zastanawia: W jakim celu w ogóle je wyłączać?
Mogła by paść odpowiedź: bo mój kod nie zdąży, gdyż jest obiektowy :-)
2) Twoja argumentacja:
"W C musisz uzyć zmiennej tymczasowej. W C++ nie, kod jest
znacznie czytelniejszy"
Czy ja wiem?
Toż przecież - spójrz w swój kod po kompilacji.
Jestem ciekaw, jak niby to Twój destruktor przekazuje UART_D, czyli fizyczny
rejestr,
bez pośrednictwa nawet rejestru?
3) Jeden z tu obecnych kolegów, powiedział mi przed laty, że on pisze w C, a
potem podgląda skompilowany kod i poprawia idiotyzmy kompilatora.
Ja uważam, że ta metoda jest dobra. Sam próbowałem, ale...
Czas leci do przodu, a kompilatory operują już na wysokiej klasie
abstrakcji.
Po skompilowaniu powstają tak niebosiężne bzdury, że poprawianie zajmowałoby
mi mnóstwo czasu, więc jest to dla mnie zbyt kosztowne.
No bo jak poprawiać kod asm wygenerowany przez kompilator,
który odczytuje timer w przerwaniu i zachowuje na stosie 20 rejestrów
procesora,
wykonuje jedno podstawienie i przywraca te rejestry.
Niestety zwiększając częstotliwość przerwań, okazuje się, że szybki procesor
spędza swój żywot na zapisywaniu stosu w tą i z powrotem, tracąc głupio
swoją moc obliczeniową
oraz potencjalną gotowość do błyskawicznej reakcji na inne zmienne
środowiskowe.

--
-- .
pozdrawiam
Sylwester Łazar
http://www.alpro.pl Systemy elektroniczne.
http://www.rimu.pl -oprogramowanie do edycji schematów
i projektowania PCB.