Czas wykonywania pętli głównej programu nie ma zupełnie nic wspólnego z ustawieniami timerów, chyba że te generują przerwania, które z kolei jeśli zawierają dużą ilość kodu i są często wywoływane to oczywiście spowalniają wykonywanie pętli głównej programu w skrajnych przypadkach mogą niemalże zatrzymać jej wykonywanie. Tu kwestia tego niemalże - jeśli przerwanie zostanie wywołane następuje skok do jego obsługi, i np w trakcie tej obsługi przychodzi kolejne wywołanie przerwania, zostaje podniesiona flaga oczekiwania na jego wykonanie, w momencie zakończenia obsługi obecnego przerwania następuje skok powrotny do wykonywania głównego programu, ale z uwagi na oczekującą flagę przerwania wykona się tylko jedna instrukcja z programu głównego i nastąpi kolejny skok do obsługi oczekującego przerwania.
Tak więc jak już pisałem program zwolni do jednej instrukcji pomiędzy przerwaniami - w skrajnym przypadku oczywiście.
Jeśli nie ma żadnych przerwań lub jeśli są krótkie i w miarę rzadko wywoływane to sam program główny jest wykonywany z pełną prędkością zegara taktującego, przerywany jedynie tymi procedurami przerwań.
Właśnie dla tego tak pożądane są sprzętowe moduły w uC (liczniki, UARTy magistrale SPI i I2C itp) , ponieważ działają niezależnie od programu nie zajmując mocy obliczeniowej procesora.

Ale ten licznik masz w pętli głównej programu?

Wyliczenie częstotliwości nie będzie takie proste, bo na całość składa się kilka czynników: wywoływane przerwanie i jego czasochłonność i częstotliwość + skoki do i z obsługi, skok i powrót do/z funkcji w której masz ten licznik++, inne rzeczy które są w pętli głównej jak warunki pętle i operacje.
Jeśli czujesz się na siłach to możesz podejrzeć plik asemblera po kompilacji (plik *.lss w katalogu Release) i na jego podstawie policzyć. Ale to nie będzie stała częstotliwość ze względu chociażby na przerwanie które jest wywoływane co twoje 200Hz. Pętla główna to nie timer, nie da się tego policzyć szybko i precyzyjnie, a dodatkowo wystarczy że coś zmienisz w kodzie to całe obliczenia trzeba na nowo robić bo każda zmiana powoduje że kompilator może zmienić listę rozkazów, a częstotliwość właśnie zależy od ich ilości.

Jak się nie jest biegły w liczenia czasu instrukcji uC ( wciąż próbuje się tego nauczyć) to zapina się jakiś analizator stanu np saeale I patrzy na ekranie na wynik, jak nie złapie stanu przy jednym obrocie pętli to można to mnożyć np zablokować pętle while po np 10 czy 100 zapetleniach, potem dzielisz wynik z saeale.

W sumie dalej nas nie uczy tego jak to policzyć bo to już "ryba a nie wędka" no ale cóż, nie jest to takie proste.

Pozdrawiam.

Chodziło mi bardziej o cały program, pętla z przerwaniami, jeden obrót , komunikacji nie licze bo ona może trwać cały czas.

Np mamy zadanie gdzie pętla i mniej strategiczne przerwania ma trwać ileś tam dajmy nato 1ms, sam wyświetlacz 2x16 pochłania dużo czasu więc wszystko zależy od założeń programu.

To kto co zrobi w przerwania h to jego dobra wola, prawidłowo powinno się wiadome krytyczne operacje.

Preskaler zawsze masz w rejestrach timera więc ma wpływ wyłącznie na dany timer. Pętla główna programu napędzana jest z prędkością taktowania uC i ewentualnie zakłócana przerwaniami.