Nie chodzilo mi o tworzenie LRS'a samemu, ale o rozwoj juz istniejacego OpenLRS'a.
Moje kilkuletnie doswiaczenie konkretnie i w tym temacie wskazuje, ze jesli procesor robi jeszcze jakies "powazniejsze obliczenia", to juz nie wygenerujesz nieszumiacego sygnalu nawet dla 2ch serv. Trzeba opierac sie o sprzetowe Timery (nawet 8 bitowe wystarcza), a konkretnie o OCR, robic jakies czarodziejskie sleep'y i inne wygibasy. W przerwaniu nie mozna nawet dac ustalenia stanu innego portu (niz ten sprzetowy), zeby nie rzezbilo po tym sygnale pozniej.Radzu pisze:wchodziły dane po serialu i sterowało do 8 serw, jak robiłem podgląd sygnałów na oscyloskopie to impulsy były całkiem niezłej jakości i nie było widać żadnego siania, może wystarczy samą funkcję generowania PWM nieco poprawić, zrezygnować z funkcji Arduino i napisać to w standardowym C (kompilator powinien to łyknąć) i będzie lepiej.
Delikatna materia, ktorej problemy kompletnie nie wystepuja w ARM'ach :)
Moj kod obslugi 2ch serv w PWM'ie zapewnia rozdzielczosc 2x i prawie 10x wieksza (zaleznie od serva), niz daje MK...a napisanie takiego kodu w ASM i kombinowanie zajelo mi kilka miesiecy. Raczej nie warto sobie podstawiac nog juz na samym poczatku i lepiej od razu wybrac najlepszy mozliwy procesor. <- ja takich rad nie sluchalem, bo tez wydawalo mi sie ze na avr mozna zrobic wszystko. Mozna duzo...ale jakim kosztem
EDIT: jesli juz to musi byc arduino, to naprawde dobrym rozwiazaniem sa te STM32.
Pisze sie tak samo - po prostu biblioteki sa inne, a programuje sie chyba nawet latwiej (z racji tego, ze STM ma od razu bootloader i nie trzeba sie meczyc z jakimis fusebitami, itp.... a sama predkosc procesora ustala sie juz w kodzie)