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/so
ftware-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

do góry

W dniu 10.01.2019 o 15:06, Queequeg pisze:
> 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/BCM2
835-ARM-Peripherals.pdf
Na stronie 140 widać PWM0 i PWM1.

> 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-D
river-HAT-providing-precise-PWM-output-16-Channel-12
-bit-I2C-Interface-support/32919741085.html

https://www.aliexpress.com/item/16-Channel-12-bit-PW
M-Servo-Driver-I2C-interface-PCA9685-module-for-ardu
ino-or-Raspberry-pi/32718274859.html

> 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).

do góry

Am 10.01.2019 um 15:06 schrieb Queequeg:
> 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/so
ftware-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

do góry

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.

do góry

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.

do góry

On 1/10/19 11:23 AM, cezar wrote:
> 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.

do góry

W dniu czwartek, 10 stycznia 2019 08:06:31 UTC-6 użytkownik Queequeg napisał:
> 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/so
ftware-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-raspb
erry-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...

do góry

W dniu czwartek, 10 stycznia 2019 15:06:31 UTC+1 użytkownik Queequeg napisał:
> 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/so
ftware-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ć.

do góry

s...@g...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.

--
Eksperymentalnie: http://facebook.com/groups/pl.misc.elektronika

do góry

W dniu 2019-01-13 o 22:46, Queequeg pisze:
> s...@g...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.

do góry