kaczodp napisał: atom1477 napisał: Zmiana wypełnienia w przerwaniu jest standardową praktyką przy wykorzystywaniu PWMa.
AVR ma bufor, który dba o to aby nową wartość PWM wpisać w odpowiednim momencie więc nie można mówić o tym, że to standardowa praktyka
Można mówić, bo nie chodzi wyłącznie o wyeliminowanie glitchów przy zapisie.
Chodzi też o synchronizowanie zapisów jako takich.
Ten bufor o którym mówisz ma na celu wyeliminowanie glitchy przy zapisie, ale nie zapewnia on żadnej innej synchronizacji bo nie ma jak tego zrobić.
Z maina nie da się łatwo zapewnić zsynchronizowanego jednostajnego zapisywania próbka po próbce, w przypadku np. odtwarzania dźwięku. Czy przy sterowaniu silnikiem.
Tylko zapis w przerwaniu zapewnia tę synchronizację. Ale oczywiście przy okazji pozywa się to też problemu z glitchami.
kaczodp napisał: Za to, ustawianie PWM na 0 nie jest dobrą praktyką aby uzyskać stabilny poziom niski, bo będzie generowana krótka szpilka na wyjściu PWM. Miałem ten kłopot i aby się pozbyć szpilki trzeba w przerwaniu wyłączać PWM.
Też nieprawda. Nie napisałem tego, ale mój kod nie ma tego problemu.
Ta szpilka występuje w określonych przypadkach.
Zależy to od tego czy Timer zlicza do góry czy do dołu, i czy tryb pinu IO PWMa jest ustawiony na Normal czy Inverted.
Szpilka występuje zależnie od trybu albo dla wypełnienia 0 albo 255.
W moim kodzie występuje dla 0, ale kod wpisuje do PWMa wypełnienia odwrócone (skąd w kodzie zapis "255 - PWM").
W rzeczywistości zerowe wypełnianie uzyskuję więc dla wpisu 255, i nie ma wtedy szpilki.
kaczodp napisał: Dużo zabawy
Gdy się wie co się robi to jest to mało zabawy.
Mój kod ma kilkanaście prostych linijek i problem jest rozwiązany.
Ty miałeś problemy bo nie wiedziałeś jak je rozwiązać. Stąd jesteś przeciwnikiem kombinowania i uważasz to za jakieś wielkie kombinowanie.
Podczas gdy problemem była Twoja niewiedza, a nie sam fakt kombinowania.
Nie wiedziałeś po prostu że szpilki da się pozbyć inaczej niż poprzez wyłączanie PWMa.
Ja mając wiedzę o tym kiedy te szpilki występują a kiedy nie, wyeliminowałem je. A kod wtedy wcale nie był wielkim kombinowaniem. Nie musiało tam być np. tego Twojego wyłączania PWMa.
kaczodp napisał: a wszystko może zacząć źle działać jak wtrącą się inne częste przerwania, np od UART.
Przerwanie od Timera2 jest wywoływane tylko 150 razy na sekundę.
Żadne inne przerwanie jak jest dobrze napisane, nie powoduje problemów.
Swoją drogą w moim kodzie jest odbiór po UARCie z liczeniem CRC32 w przerwaniu
Przerwania z UARTa przychodzą z częstotliwością jakieś 1kHz.
I nawet to nie jest na tyle dużo żeby blokować przerwania od Timera2.
kaczodp napisał: Zamiast kombinować lepiej skorzystać z możliwości sprzętowych
Dzisiaj tak, gdy są dostępne tanie procesory z Timerami 16 czy 32 bitowymi.
Ale mimo to takie metody kombinowane warto znać.
Ale nie zgadzam się z tym powodem:
kaczodp napisał: niż pchać się w potencjalne kłopoty przykładowo serwo wariuje gdy po Wi-Fi przez ESP-UART wysyłane są informacje albo BT czy USB.
Nie taki jest powód. Powodem jest łatwodostepność tanich zaawansowanych procesorów.
A nie problemy po UARCie, bo ich nie ma jak się dobrze napisze kod.
To że ktoś nie umie napisać dobrego kodu, i on mu zamula procesor i inne przerwania, to już wina tego kogoś a nie tego że używa przerwań.
One po to są są żeby ich używać. Jeżeli ktoś używając ich uzyskuje zamulanie procesora, to nijak nie świadczy o tym że przerwania nie nadają się do używania.
To programista się nie nadaje do pisania obsługi tych przerwań. Ale same przerwania są tu ok.