Ale co to ma do tematu?

Zamiast powielać impulsy lepiej przestawić sterownik na mniejszą ilość kroków. Jeśli z portu wyjdzie 20kHz, to przy pełnym kroku typowego silnika dostaniesz 30m/min czyli 100 obrotów na sekundę. Powodzenia

Ja już swoje powiedziałem, że się NIE DA tego zrobić z sensem
Możesz założyć do Skody felgi od Ferrari. Może i będzie lepiej wyglądać, może Ci się samopoczucie poprawi, ale to wszystko co zyskasz.

Wykonaj proste doświadczenie myślowe. Przypadek pierwszy: jeden impuls. Co robisz? Przypadek drugi: dwa impulsy. Przypadek trzeci: dwa im pulsy i zaraz po nich szybki impuls w przeciwnym kierunku. Przypadek czwarty: dwa szybkie impulsy i trzeci po czasie 5x dłuższym po czym czwarty bardzo szybko.
Zaproponuj uniwersalny bezbłędny algorytm "powielania precyzji".

Da się ale nie ma to sensu.
Ponieważ nie jesteś w stanie w żaden sposób przewidzieć kiedy i CZY W OGÓLE pojawi się kolejny impuls, więc nie możesz zrobić żadnej aproksymacji czy predykcji czasowej która wciskałaby dodatkowe impulsy sensownie. Musiałbyś je wstawiać natychmiast aby zdążyć przed kolejnym ewentualnym impulsem zewnętrznym.
Nic nie zyskujesz. Płynności ruchu większej nie ma, precyzji większej nie ma, rozdzielczość taka sama. Tyle że sterownik silnika inaczej ustawiony, żeby zachować skalę.

To musiałby być układ który przejmowałby wszystkie linie, analizował i interpolował czasowo zachowując relacje czasowe. Takie nadpróbkowanie wtórne jak w lepszych odtwarzaczach CD. Tyle że tam to ma sens aby dopasować się do standardu CD i jednak poprawić dynamikę. W przypadku CNC prościej, lepiej i taniej zainstalować lepszy sterownik.

Ale z czym masz problem?
Dowiedziałeś się czego chciałeś?

Ten co ma pojęcie się odezwał ))
Mam na biurku jeden z takich projektów rozgrzebany. Dwa zadania o JEDNAKOWO wysokim priorytecie, które muszą pracować z dokładnością czasową na poziomie 1us z maksymalnym błędem 2us, bo powyżej system przestaje działać poprawnie (błędne wyniki pomiarów). Nie są ze sobą zsynchronizowane. Jedno z tych zadań jest wyzwalane sygnałem niezależnym od procesora i jego zegara i ma zmienną częstotliwość w zakresie ok. dekady. Drugie zadanie jest wyzwalane przez zasoby procesora, ale ma zmienność częstotliwości w zakresie 2 dekad. Do tego proces komunikacyjny dwukierunkowy ale bez fifo na wejściu i normalne obliczenia numeryczne, dość złożona trygonometria pomiarowa z dokładnością co najmniej integer, obsługa peryferiów zewnętrznych w tym ekranu graficznego.
Zegar procesora 32MHz, wykorzystanie czasu ALU na poziomie do 90% w szczycie, zależnie od relacji czasowych.
Przy 32MHz zegara mam zastępcze pasmo procesów krytycznych 250kHz*2=500kHz (*2 bo 2 niezależne procesy real time). Iloraz: 64
LinuxCNC na pececie z zegarem 3GHz i procesorem numerycznym oraz nieograniczoną pamięcią uzyskuje pasmo procesów krytycznych... 50kHz. Aż I to przy pełnej autokontroli nad przebiegiem tego procesu Iloraz: 60000.
Dedykowane urządzenie jako zarządzające systemem real time jest ~1000 razy wydajniejsze w tym przypadku
I dlatego pecet to NIE JEST metoda na profesjonalny sterownik. W ogólnym przypadku, nie ma żadnych szans w starciu z dedykowanym sprzętem. Po prostu żadnych.

P.S. Nawet jeśli nie ma żadnego procesu zakłócającego i proces krytyczny jest wyzwalany przerwaniem czasowym, to jitter często się pojawia, bo rzadko kiedy program przerwania wykonuje się bez uprzednich warunków, skoków, zawsze identycznie czasowo.

Oj, chyba niewiele miałeś do czynienia z poważnymi programami na kontroler...
W sterowniku, który nie jest 100% masterem systemu real time, i jednocześnie pracuje z dużym wypełnieniem wykorzystania ALU, nie ma możliwości ustrzec się niestabilności czasu wyzwalania procesów. Bo przerwania zakłócają program główny, przerwania wyższego poziomu zakłócają przerwania niższego poziomu i program główny i tak dalej. Przy tym wszystkim trzeba zapewniać, żeby się ograniczone zasoby nie pożarły ze sobą i żeby nie pojawiły się niekontrolowane wartości niedokończonych obliczeń. Nawet mechanizmy tupu FIFO podłączone do portów komunikacyjnych mogą nie wystarczyć.
System czasu rzeczywistego, dobrze działający, to jest wyzwanie. Wielowątkowy system czasu rzeczywistego w małym procesorze o skromnych i nierozwijalnych zasobach, stosunkowo powolnym, z uproszczonym mechanizmem matematycznym (czasem bardzo), to potrafi być wielkie wyzwanie. Strojenie całkowicie gotowego i proceduralnie poprawnego programu, żeby pracował poprawnie w real time, często nawet wymusza poważne zmiany w budowie i filozofii działania całego oprogramowania.
Napisanie dobrego programu na jednoukładowiec, małego, oszczędnego, wydajnego i bezbłędnego, w porównaniu ze znacznie bardziej funkcjonalnym programem na peceta w języku wysokiego poziomu, to jest wyższy poziom wtajemniczenia. Mało kto potrafi. Czy urządzenie robił zawodowiec czy amator widać to po tym, jaki procesor został użyty do jakiego projektu, jak zasoby zostały wykorzystane i w jakim stopniu.

Kwarc 4MHz mówi o tym, że... kwarc jest 4MHz i na razie nic więcej. Żeby dowiedzieć się jak jest taktowany rdzeń i peryferia, trzeba jeszcze przeanalizować wsadowego HEX-a. Może być i maksymalna częstotliwość katalogowa, pewnie ze 40Mhz dla tego procesora. I od tego trzeba zacząć. Bo jeśli jest taktowany wysoko, to przyspieszyć się nie da. Jeśli 2x lub wolniej od fmax, 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.

A gdzie tu sprzeczność?
50kHz (ale z rozsądnym procentowo jitterem 10-20kHz realnie) dla maszyny profesjonalnej i uniwersalnej, to MAŁO.
1kHz dla maszynki niskobudźetowej, która może jest wycinarką do styropianu albo ma grawerować breloczki, albo po prostu jest wykonana ze sklejki i szybciej ani precyzyjniej nie ma sensu, albo ma być eksperymentem czy pierwszym krokiem po minimalnych kosztach, to WYSTARCZY.

Dlaczego porażka? Do wielu zastosowań tyle wystarczy.
Nie wiadomo też jak jest taktowany procesor, czy na maksimum czy nie. W dokumentacji nie znalazłem opisu kwarcu. Jeśli nie jest na maksimum, to można dość łatwo zmodyfikować program (hex) tak żeby rdzeń pracował 2x lub 4x szybciej a komunikacja miała tę samą prędkość.
Choć nie sądzę, że projektant nie wykorzystał maksymalnej prędkości procesora

Przy pracy półkrokowej to jest 2,5 obrotu na sekundę. Czyli średnio 750mm/min. Do prostej maszynki edukacyjnej moim zdaniem spokojnie wystarczy. Zakładam, że jeśli oszczędzamy na sterowaniu to oszczędzamy również na mechanice, która w związku z tym jest słaba i nie warto próbować sterować jej ani precyzyjnie ani z wysokimi parametrami.