Toad4 czy ktoś już to robił...?

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.

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.

.

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.

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.

.

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.

Panowie chyba czas zamknąć ten temat bo dyskusja sprowadziła się do sparingu słownego a nie o to tu chyba chodzi ...

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

Ja mam jeszcze pytanie.

Czy dałoby radę zrobić na jakimś mikroprocku powielacz kroków dla dwóch osi lub chociaż jednej (wtedy przecież można wstawić po jednym prostym układzie na każdą "linię")? Powiedzmy, że ta zabawka daje 1kHz max ale wstawiamy buforek, który bierze historię paru impulsów i ich odstępów czasowych i z tych informacji, z "niewielkim" ale stałym opóźnieniem, daje impulsy podwojone lub 2^n zwiększone? Tracimy oczywiście na rozdzielczości ale można zyskać na szybkości i płynności ruchu.

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.

pitsa, właśnie w ten sposób u siebie osiągnąłem 25m/min na srubie o skoku 5mm na porcie LPT, windowsie i machu. Przełożenie śruba-silnik 1:1. Nie wiem jak to sie ma do częstotliwości portu LPT, ale rozdzielczość roboczą mam 0,012mm. W pełni mnie to zadowala, bo i tak nawrotny na chinskich srubach jest na poziomie 2 setek
Do realizacji tego wykorzystałem przekładnie elektroniczną w servopacku moich serw. Bez zadnej dodatkowej elektroniki