3 kanały PWM na raspberry pi 3

W dniu 10.01.2019 o 15:06, Queequeg pisze:

A nie dwa?

stronie 140 widać PWM0 i PWM1.

Może taki gotowiec?

Nie robiłem software'owego PWM na RPi, ale mam kilka paneli LED z telebimu, które są właśnie odświeżane software'owo przez RPi3 i każde większe obciążenie widać jako fluktuacje jasności mimo że system jest odchudzony (Raspbian Lite, powyłączane wszystko co nie było niezbędne).

Am 10.01.2019 um 15:06 schrieb Queequeg:

Nie wiem, czy się sprawa opłaca. Nie wiem co jeszcze potrzebujesz robić, ale programowe PWM na Raspberry jest dość upierdliwe, bo nie ma toto RT-Kernela, ja bym nie kopulował się z tym, tylko dał arduino nano czy inne ło tylko do PWMu. Biblioteka WiringPi jest zacna i można dużo zrobić z niej korzystając, ale przy dobrym wyżyłowaniu systemu możesz mieć solidne haki.

Waldek

[...]

Przy większej liczbie PWM czy wyżyłowanych wymaganiach czasowych bym się zastanowił nad przesiadką na Beaglebone. Procesor ma 2 wbudowane koprocesory hard-rt, przy umiejętnym napisaniu programu można otrzymać nanosekundową dokładność i niemal zerowy jitter. Bedzie to o wiele stabilniejsze niż cokolwiek co uda się uzyskać nawet z z RT-linuksem. Albo podłączyć po SPI kostkę do sterowania LEDami mieć święty spokój. W projektach bardziej ambitnych niż machaniem serwem na pokaz czy miganie diodką nie ma sensu szarpać się z programowym generowaniem PWM na systemach nie-RT.

Jacek.

beaglebone nawet bez PRU potrafi wyygenrować kilku-MHz PWMy - gdzies czytałem że do 10MHz jest bezpiecznie. Jak kiedyś się bawiłem to nawet

30-40MHz dało się generować ale nie moge stwierdzić jak czysty był sygnał bo mój oscyoskop to już przerastało.

Ma ich chyba 8 niezależnych.

Ale to chyba na sprzętowym. W archiwach listy beaglebone jest post w którymś ktoś się chwali pomiarami, i najlepsze co się dało to chyba coś ok. kilkuset kHz. IIRC więcej niż pojedyncze MHz nie da się wyciągnąć z głównego procesora, bo szybkość ogranicza czas dostępu to rejestrów I/O, do których trzeba się przebić przez szyny L3/L4. To samo masz w PRU jeśli korzystasz z linii z dostępem przez szynę. Generowałem kiedyś z PRU przebiegi do sterowania kostką TI do LEDów (trzeba było zsynchronizować reset z zegarem, więc tak było najłatwiej), i co któryś impuls czas trwania był 3-4 razy dłuższy. Co innego na pinach do których PRU ma bezpośredni dostęp. Tam nie ma takich ograniczeń. No i sprzętowych PWM jest więcej niż w RPi, a PocketBeagle jest tańsze niż RPi3

Jacek.

W dniu czwartek, 10 stycznia 2019 08:06:31 UTC-6 użytkownik Queequeg napisał:

Gdzies czytalem ze uzywajac assemblera/C mozna szybciej machac gpio na malinie.

Tu jakis gostek robil testy:

Wyciagal sporo wiecej od tych 100Hz co piszesz.

Ja bym jednak wolal se podpiac jakies male arduino po usb, i je prostymi komendami sterowac ustawiajac pwm jaki mi pasuje/potrzeba.

Zaleta taka ze dziala bez problemu, niezaleznie od maliny, jak dobrze ogarniesz to wznowi dzialanie po padzie pradu i wogole lepiej. A kosztuje grosze...

W dniu czwartek, 10 stycznia 2019 15:06:31 UTC+1 użytkownik Queequeg napisał:

A nie lepiej zrobić to na FPGA? Na najprostszym spartanie-6 za mniej niż 10# możesz obsłużyć w pzdu kanałów i masz pewność, że nic Ci się nie będzie ścinać.

Pewnie tak... ale osoba, która będzie to oprogramowywała (nie ja), będzie robiła to w pythonie.

Dzięki za wszystkie odpowiedzi, będzie po drodze AVR.

Prościej dać PCA9685 lub TLC5971 który ma 16 lub 12 sprzętowych PWM i nie trzeba dodatkowego procesora programować...

Nie sądziłem, że takie scalaki istnieją. Faktycznie, nie ma sensu tego robić na AVR. Dzięki!