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.