Queequeg
Guest
Thu Jan 10, 2019 4:06 pm
Hej,
Disclaimer: nigdy nie programowałem GPIO na raspi.
Z tego co wiem, raspi ma tylko jeden sprzętowy kanał PWM, a jak ktoś chce
więcej, to musi radzić sobie software'owo lub różnymi innymi dodatkami.
Wygooglałem, że w Pythonie robi to np. biblioteka WiringPi.
https://projects.drogon.net/raspberry-pi/wiringpi/software-pwm-library/
Piszą, że rozsądna częstotliwość to 100 Hz (przy podziale na 100), bo
powyżej się to przycina.
Pytanie do praktyków: czy częstotliwość rzędu 500 Hz powielona trzy razy
(bo potrzebuję trzech kanałów) jest realna na raspberry pi 3 (z poziomu
Pythona, nie C), czy od razu dać sobie z tym spokój i zrobić międzymordzie
na AVR? Nie jestem pewien, o którym raspberry tam piszą, a przecież między
jedynką i trójką jest przepaść.
Czy ten PWM jest bardzo niestabilny, gdy procesor jest obciążony? Jeśli
tak, to czy użycie schedulera FIFO lub RR (sched_setscheduler, nie wiem
czy da się to zrobić z poziomu Pythona ale na pewno można napisać wrapper)
pomaga?
--
http://facebook.com/groups/pl.misc.elektronika
Zbych
Guest
Thu Jan 10, 2019 4:41 pm
W dniu 10.01.2019 o 15:06, Queequeg pisze:
Quote:
Hej,
Disclaimer: nigdy nie programowałem GPIO na raspi.
Z tego co wiem, raspi ma tylko jeden sprzętowy kanał PWM, a jak ktoś chce
więcej, to musi radzić sobie software'owo lub różnymi innymi dodatkami.
A nie dwa?
https://www.raspberrypi.org/app/uploads/2012/02/BCM2835-ARM-Peripherals.pdf
Na stronie 140 widać PWM0 i PWM1.
Quote:
czy od razu dać sobie z tym spokój i zrobić międzymordzie
na AVR?
Może taki gotowiec?
https://www.aliexpress.com/item/Raspberry-Pi-Servo-Driver-HAT-providing-precise-PWM-output-16-Channel-12-bit-I2C-Interface-support/32919741085.html
https://www.aliexpress.com/item/16-Channel-12-bit-PWM-Servo-Driver-I2C-interface-PCA9685-module-for-arduino-or-Raspberry-pi/32718274859.html
Quote:
Czy ten PWM jest bardzo niestabilny, gdy procesor jest obciążony? Jeśli
tak, to czy użycie schedulera FIFO lub RR (sched_setscheduler, nie wiem
czy da się to zrobić z poziomu Pythona ale na pewno można napisać wrapper)
pomaga?
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).
Waldemar
Guest
Thu Jan 10, 2019 5:01 pm
Am 10.01.2019 um 15:06 schrieb Queequeg:
Quote:
Hej,
Disclaimer: nigdy nie programowałem GPIO na raspi.
Z tego co wiem, raspi ma tylko jeden sprzętowy kanał PWM, a jak ktoś chce
więcej, to musi radzić sobie software'owo lub różnymi innymi dodatkami.
Wygooglałem, że w Pythonie robi to np. biblioteka WiringPi.
https://projects.drogon.net/raspberry-pi/wiringpi/software-pwm-library/
Piszą, że rozsądna częstotliwość to 100 Hz (przy podziale na 100), bo
powyżej się to przycina.
Pytanie do praktyków: czy częstotliwość rzędu 500 Hz powielona trzy razy
(bo potrzebuję trzech kanałów) jest realna na raspberry pi 3 (z poziomu
Pythona, nie C), czy od razu dać sobie z tym spokój i zrobić międzymordzie
na AVR? Nie jestem pewien, o którym raspberry tam piszą, a przecież między
jedynką i trójką jest przepaść.
Czy ten PWM jest bardzo niestabilny, gdy procesor jest obciążony? Jeśli
tak, to czy użycie schedulera FIFO lub RR (sched_setscheduler, nie wiem
czy da się to zrobić z poziomu Pythona ale na pewno można napisać wrapper)
pomaga?
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
Jacek Radzikowski
Guest
Thu Jan 10, 2019 5:13 pm
On 1/10/19 11:01 AM, Waldemar wrote:
Quote:
Am 10.01.2019 um 15:06 schrieb Queequeg:
[...]
Czy ten PWM jest bardzo niestabilny, gdy procesor jest obciążony? Jeśli
tak, to czy użycie schedulera FIFO lub RR (sched_setscheduler, nie wiem
czy da się to zrobić z poziomu Pythona ale na pewno można napisać
wrapper)
pomaga?
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.
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.
cezar
Guest
Thu Jan 10, 2019 5:23 pm
On 10/01/2019 16:13, Jacek Radzikowski wrote:
Quote:
On 1/10/19 11:01 AM, Waldemar wrote:
Am 10.01.2019 um 15:06 schrieb Queequeg:
[...]
Czy ten PWM jest bardzo niestabilny, gdy procesor jest obciążony? Jeśli
tak, to czy użycie schedulera FIFO lub RR (sched_setscheduler, nie wiem
czy da się to zrobić z poziomu Pythona ale na pewno można napisać
wrapper)
pomaga?
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.
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.
Jacek Radzikowski
Guest
Thu Jan 10, 2019 5:36 pm
On 1/10/19 11:23 AM, cezar wrote:
Quote:
On 10/01/2019 16:13, Jacek Radzikowski wrote:
On 1/10/19 11:01 AM, Waldemar wrote:
Am 10.01.2019 um 15:06 schrieb Queequeg:
[...]
Czy ten PWM jest bardzo niestabilny, gdy procesor jest obciążony? Jeśli
tak, to czy użycie schedulera FIFO lub RR (sched_setscheduler, nie wiem
czy da się to zrobić z poziomu Pythona ale na pewno można napisać
wrapper)
pomaga?
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.
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.
Guest
Thu Jan 10, 2019 6:47 pm
W dniu czwartek, 10 stycznia 2019 08:06:31 UTC-6 użytkownik Queequeg napisał:
Quote:
Hej,
Disclaimer: nigdy nie programowałem GPIO na raspi.
Z tego co wiem, raspi ma tylko jeden sprzętowy kanał PWM, a jak ktoś chce
więcej, to musi radzić sobie software'owo lub różnymi innymi dodatkami.
Wygooglałem, że w Pythonie robi to np. biblioteka WiringPi.
https://projects.drogon.net/raspberry-pi/wiringpi/software-pwm-library/
Piszą, że rozsądna częstotliwość to 100 Hz (przy podziale na 100), bo
powyżej się to przycina.
Pytanie do praktyków: czy częstotliwość rzędu 500 Hz powielona trzy razy
(bo potrzebuję trzech kanałów) jest realna na raspberry pi 3 (z poziomu
Pythona, nie C), czy od razu dać sobie z tym spokój i zrobić międzymordzie
na AVR? Nie jestem pewien, o którym raspberry tam piszą, a przecież między
jedynką i trójką jest przepaść.
Czy ten PWM jest bardzo niestabilny, gdy procesor jest obciążony? Jeśli
tak, to czy użycie schedulera FIFO lub RR (sched_setscheduler, nie wiem
czy da się to zrobić z poziomu Pythona ale na pewno można napisać wrapper)
pomaga?
Gdzies czytalem ze uzywajac assemblera/C mozna szybciej machac gpio na malinie.
Tu jakis gostek robil testy:
http://codeandlife.com/2012/07/03/benchmarking-raspberry-pi-gpio-speed/
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....
Guest
Thu Jan 10, 2019 9:10 pm
W dniu czwartek, 10 stycznia 2019 15:06:31 UTC+1 użytkownik Queequeg napisał:
Quote:
Hej,
Disclaimer: nigdy nie programowałem GPIO na raspi.
Z tego co wiem, raspi ma tylko jeden sprzętowy kanał PWM, a jak ktoś chce
więcej, to musi radzić sobie software'owo lub różnymi innymi dodatkami.
Wygooglałem, że w Pythonie robi to np. biblioteka WiringPi.
https://projects.drogon.net/raspberry-pi/wiringpi/software-pwm-library/
Piszą, że rozsądna częstotliwość to 100 Hz (przy podziale na 100), bo
powyżej się to przycina.
Pytanie do praktyków: czy częstotliwość rzędu 500 Hz powielona trzy razy
(bo potrzebuję trzech kanałów) jest realna na raspberry pi 3 (z poziomu
Pythona, nie C), czy od razu dać sobie z tym spokój i zrobić międzymordzie
na AVR? Nie jestem pewien, o którym raspberry tam piszą, a przecież między
jedynką i trójką jest przepaść.
Czy ten PWM jest bardzo niestabilny, gdy procesor jest obciążony? Jeśli
tak, to czy użycie schedulera FIFO lub RR (sched_setscheduler, nie wiem
czy da się to zrobić z poziomu Pythona ale na pewno można napisać wrapper)
pomaga?
--
http://facebook.com/groups/pl.misc.elektronika
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ć.
Queequeg
Guest
Sun Jan 13, 2019 11:46 pm
sczygiel@gmail.com wrote:
Quote:
Gdzies czytalem ze uzywajac assemblera/C mozna szybciej machac gpio na malinie.
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.
--
Eksperymentalnie:
http://facebook.com/groups/pl.misc.elektronika
jacek
Guest
Mon Jan 14, 2019 1:24 am
W dniu 2019-01-13 o 22:46, Queequeg pisze:
Quote:
sczygiel@gmail.com wrote:
Gdzies czytalem ze uzywajac assemblera/C mozna szybciej machac gpio na malinie.
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ć...
--
pzdr, j.r.
Queequeg
Guest
Mon Jan 14, 2019 1:03 pm
jacek <jacek.rutkowski@wp.pl> wrote:
Quote:
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!
--
Eksperymentalnie:
http://facebook.com/groups/pl.misc.elektronika