Pewne pytanie co do częstotliwości

[skax]

Witajcie, mam pewną rozterkę jeśli chodzi o odliczanie czasu i nadawanie elementom częstotliwości działania. Otóż :

Załóżmy, że chcemy aby dioda LED pulsowała z częstotliwością 1 hz, czyli wykonuje jeden okres w czasie 1 s, wychodzi na to, że w czasie 1 sekundy dioda musi pół czasu palić się i pół nie, czyli stan pinu zmieniamy co 0,5 s - dobrze rozumuję ?

Jeśli tak to nie rozumiem dlaczego tu:

Link do kursu

na samym dole tam gdzie autor chce generować dla diody 1 Hz, wykonuje przerwanie w celu zmienienia stanu pinu co 1s - w tym przypadku wychodzi 0,5 Hz.

Tak samo dla generowania 36 khz, okres wynosi ok 27,8 us, czyli stan pinu muszę zmienić w czasie ok 14,9 sekundy.

Robię tak na delayu :

PORTC ^= (1<<PC0);
_delay_us ( 13.89 );

I tsop 36 khz nie odbiera. Może błąd w tym, że powinno być to na timerze, gdyż delay jest niedokładny, albo dioda dostaje za mały prąd.

Działam na IR LD 274, podłączona jest do PC0 bezpośrednio a i tak słabo świeci. W pilocie diodka daje mocne światło.

Pozdrawiam

[KD93]

Przyczyn może być kilka, ot choćby:

1) TSOP odbiera, ale ponieważ nadajesz ciągły sygnał to się blokuje

2) masz niezgodność ustawionego taktowania z tym które deklarujesz (prosto sprawdzić, ustaw włączanie diody co 1s).

Myślę, że jakbyś pokazał cały schemat i kod to powinno być prościej. Poczytaj o trybie CTC, przydatne do generowania częstotliwości na wyjściu.

[skax]

A co do pierwszej części o częstotliwości ? Które rozumowanie jest dobre ?

[MirekCz]

1. W tekście piszesz 14,9 sekundy, a powinno być 13,9us.

2. Jaki masz zegar procesora? Ustawiłeś go poprawnie w kodzie? Funkcja delay_us działa ok?

3. No i najważniejsze... o ile nie masz bardzo szybkiego zegara twój kod nie ma szans działać.

Przyjmijmy zegar procesora 1mhz ( co jak mnie pamięć nie myli dla atmegi oznacza, że będziesz wykonywał maksymalnie 1mln prostych operacji na sekundę ).

Problemy:

a) Jaki ma błąd w dokładności funkcja delay_us przy wolnym zegarze i krótkim czasie (13,89) ?

b) Co to jest 13,89 w wywołanie funkcji? delay_us zapewne przyjmuje wartość stałoprzecinkową, więc od razu zmieni to się na 14.

c) Dodatkowo masz narzuty typu:

- wywołanie funkcji (o ile kompilator nie zoptymalizuje tego jako funkcję inline)

- zmiana stanu wyjścia PC0

- przynajmniej wykonanie skoku do początku pętli (nie widzę całego kodu, trudno powiedzieć co tam jest)

Zastanów się ile to wszystko zajmie... to będzie przynajmniej kilka komend assemblera (zależy od kompilatora i ustawionych opcji kompilacji) co daje przynajmniej kilka dodatkowych us na wykonanie każdej pętli.

d) Jak używasz zegara wew. to on sam ma błędy na poziomie kilku procent. Jest to do przyjęcia, ponieważ tsopy spokojnie odbierają częstotliwość +/- 10%, ale zmniejsza to ew. błędy w innych miejscach.

Jak widzisz z opisu powyżej prawdopodobnie procesor przełącza diodę dużo rzadziej niż co 13,9us. W zależności od wielu parametrów (ustawiona prędkość zegara, opcje kompilatora, kod w funkcji delay_us, reszta kodu wykonywanego w pętli głównej) może to być spokojnie 20 czy 30us, co będzie już poza częstotliwością wykrywaną przez Twojego TSOPa.

Na próbę możesz spróbować zmniejszyć wartość w delay_us do 13, 12, 11, 10, ... może uda się odpalić to, ale generalnie jest to błędne podejścia do Twojego problemu.

Poprawne podejście to wykorzystanie w procesorze generatora PWM, albo przynajmniej jakiegoś timera i przerwania (chociaż nawet tutaj przy wolnym zegarze mikrokontrolera mogą pojawić się schody jak oprócz tego przerwania będziesz robił inne rzeczy w dokładnie ustalonym czasie).

[Polecacz 101]

Produkcja i montaż PCB - wybierz sprawdzone PCBWay!
   • Darmowe płytki dla studentów i projektów non-profit
   • Tylko 5$ za 10 prototypów PCB w 24 godziny
   • Usługa projektowania PCB na zlecenie
   • Montaż PCB od 30$ + bezpłatna dostawa i szablony
   • Darmowe narzędzie do podglądu plików Gerber
Zobacz również » Film z fabryki PCBWay

[skax]

Oczywiście, 13,9 s - literówka 😉

Właściwie to ten delay generalnie dziwnie działa i PWM nie za bardzo na nim wychodzi ( tak jak np się bawię normalną diodą led ). Mam atmege8 bez żadnych zmian w fusebitach, czyli prawdopodobnie będzie to 1 MHz.

A wreszcie .. czy moje rozumowanie jest dobre ? Chcąc migać diodą z 1hz ustawiamy jej czas świecenia i nieświecenia na pół sekundy czy sekundę ?

HA ! Spadło do totalnego 0 napięcie na wyjściu tsopa po podaniu 11 us

[KD93]

Oczywiście, 13,9 s - literówka 😉

13,9µs

Właściwie to ten delay generalnie dziwnie działa i PWM nie za bardzo na nim wychodzi ( tak jak np się bawię normalną diodą led ).

To masz wprawne oko jak możesz dostrzec dziwne działanie PWM przy tej częstotliwości obserwując diodę 😉

HA ! Spadło do totalnego 0 napięcie na wyjściu tsopa po podaniu 11 us

W takim razie pewnie już wiesz, dlaczego używanie do tego delay'ów mija się z celem. Nie wiem, do czego chcesz użyć tego TSOP'a, ale odbiegając od dedykowanej częstotliwości tracisz na zasięgu. Na dobrą sprawę to nadal nikt nie wie, jaka tam jest faktycznie częstotliwość.

[skax]

Hmm chodziło z tym PWM o to, że nawet jak dałem 1 us na świecenie diody i 99 us na nieświecenie to było widać tą diodę a z 1% myślałem, że będzie raczej niewidoczna. No chyba, że tak to działa 🙂

Poza tym jeszcze zrobiłem coś takiego :

x = 0

//petla

if ( ~PINC & ( 1<<PB0 ) ) x++;

PORTC |= ( 1<<PC0 );
_delay_us ( x)
PORTC &= ~( 1<<PC0 );
_delay_us(100-x);

Gdzie pb0 jest podciągnięte do 1 i zwarte do masy po naciśnięciu switcha.

Nawet jak nic nie duszę, to dioda śie leciutko świeci, a przecież x = 0 ..

[MirekCz]

ehh... nadal nie zrozumiałeś przesłania.

W zależności jak Twój kod dokładnie wyglądał prawdopodobnie to nie był stosunek czasu 1:99.

Dodatkowo przynajmniej dla ludzkiego oka zmiana jasności nie jest liniowa, ale logarytmiczna, więc trudno nam ją dokładnie ocenić. Nawet z wypełnieniem 1% nadal powinieneś tą diodę widzieć (szczególnie jak do wymienionego efektu dojdzie jeszcze podkręcenie obrazu przez aparat).

[skax]

Ok, już teraz rozumiem, że delay niekoniecznie odmierza dokładnie 😉 - o to mi chodziło

[MirekCz]

Nie chodzi o to, że delay nie odmierza dokładnie.

Chodzi o to, że poza funkcją delay masz jeszcze inne komendy, które też wpływają na czas wykonywania programu przez procesor.

Jak mówimy o czymś co dzieje się co np.1ms to w wielu wypadkach można to pominąć (10us przy 1ms to już tylko 1%). Przy dużych częstotliwościach jak w Twoim wypadku (co <14us zmiana stanu) wystarczy kilka us i błąd częstotliwości to już kilkadziesiąt procent.