mc2kwacz pisze:Bo przerwania zakłócają program główny, przerwania wyższego poziomu zakłócają przerwania niższego poziomu i program główny i tak dalej.

Tradycyjnie zielonego pojęcia nie masz, a pogadać sobie musisz ...
System czasu rzeczywistego pracuje na przerwaniu o najwyższym priorytecie i absolutnie nic nie ma prawa go zakłócać, przynajmniej w teorii.

.

mc2kwacz pisze:wtedy można pokusić się o próbę przyspieszenia rdzenia i tym sposobem zmniejszenie jittera. Ale to wcale nie musi się udać, bo po tym zabiegu program po prostu może przestać działąć poprawnie. Bo to jest real time.

Autorzy programu najzwyczajniej bredzą, bo w tym PIC-u nie ma mowy o żadnym jitterze.
Po prostu czym więcej trzeba obliczyć, tym wolniejszy trzeba dać okres bazowy.
Tutaj pomoże optymalizacja kodu, przepisanie procedur z C na asembler, ale z tego co zrozumiałem źródła nie są dostępne ...
Jitter jest natomiast wtedy, gdy coś występującego losowo zakłóca pracę procesora.
Na przykład DMA, zarządzanie energią, czy inne cuda których oczywiście w PIC-u nie ma, najzwyczajniej wyłączają procesor, lub blokują dostęp do pewnych zasobów, więc czas wykonania zadania staje się nieprzewidywalny.

.

mc2kwacz pisze:50kHz (ale z rozsądnym procentowo jitterem 10-20kHz realnie)

Jak zwykle nie masz bladego pojęcia o czym mówisz.

.

mc2kwacz pisze:Dlaczego porażka? Do wielu zastosowań tyle wystarczy.

Po prostu jestem pod wrażeniem.
50 kHz z portu LPT to prehistoria, amatorszczyzna i coś tam jeszcze, a 1 kHz z USB wystarczy do wielu zastosowań ...

.