Jest to mój pierwszy wpis tutaj, więc na początek pragnę wszystkich serdecznie przywitać

Otóż mam problem z projektem pilota IR (realizowanym według rozdziału z bluebooka "Pilot na podczerwień"). Układ pracuje na plastikowej płytce stykowej, zasilany jest z baterii 4,5V.

Jako że nie miałem pod ręką attiny2313, użyłem atmegi8 i pozmieniałem odpowiednio rejestry i liczniki.

Problem polega na tym, że pilot najprawdopodobniej nie emituje prawidłowych ramek lub w ogóle nie generuje nośnej. Jakieś tam dane próbuje wysłać, bo po zwiększeniu prescalera w timerze1 służącym za odczekiwanie 889us (i wzięciu tym sposobem pod lupę emitowanej ramki) widzę, że dioda led sygnalizująca wysyłanie radośnie migocze.

Z braku tranzystora PNP użyłem NPN (BC547) i napisałem funkcje wysyłu danych o odwróconej logice stanów.



Proszę kogoś biegłego w rejestrach atmegi8 o sprawdzenie, czy poprawnie mam ustawione wartości rejestrów.


btw Zmieniłem też wpisy z przykładu w książce (KEY1)|(KEY2)|(KEY3)|(KEY4)|(KEY5) na KEYS_MASK ale to nie powinno mieć wpływu na nic...

Innym problemem jest to, że nie mogę wybudzić atmegi ze stanu powerdown poprzez INT0, ale to sprawa drugorzędna, dlatego na razie sleep_mode() ująłem w komentarz.



Kody wklejamy przy pomocy syntax=c - Różowo-zielony (czyli sraczkowy) J.

send_rc5_zero() i send_rc5_one() powinny pozostać bez zmian. Początkowa konfiguracja portu wystarczy. W funkcji czekaj_us(uint16_t usekundy) brakuje zerowania licznika timera 1 i najlepiej na początek zastąp to funkcją _delay_us.
Do obserwacji czy coś się wysyła dobrze posłużyć się kamerą w komórce. Jak coś jest to jeszcze możesz uprościć program tak, że co sekundę generujesz nośną i przez drugą nic nie robisz, a do odbiornika podpinasz sobie diodę LED i obserwujesz czy odbiornik łapie nośną.

_________________
Dragonus Cracovus: Biomagia

Ok. Dzięki za uwagę

Ale głupotę zrobiłem ze zmianą tych funkcji Przecież generowanie bitów się nie zmienia, tylko samo generowanie nośnej przyjmuje odwrotne stany

Co to za sposób z kamerką w telefonie?

--

Chyba wiem już, czemu nie mogę wybudzić mikroklocka ze snu. Zamiast edytować temat, napiszę sam dla siebie podpowiedź - może przyda się komuś kto tego jeszcze nie wiedział tak samo jak ja.


Nota pdf głosi wszak:
"Note that recognition of falling or rising
edge interrupts on INT0 and INT1 requires the presence of an I/O clock, described in “Clock
Systems and their Distribution” on page 25. Low level interrupts on INT0/INT1 are detected
asynchronously. This implies that these interrupts can be used for waking the part also from
sleep modes other than Idle mode."

Moje ustawienie bitu ISC01 czyli reakcja na zbocze opadające chyba jest przyczyną.

------------------------ [ Dodano po: 15 minutach ]

A czy w trybie CTC (Clear on Compare Match) licznik sam się nie zeruje po zrównaniu wartości z OCR?

Słuszna uwaga. Masz rację.

Podczerwieni nie widać gołym okiem, ale już patrząc na obraz z kamerki można zobaczyć. Sprawdź sobie na dowolnym pilocie IR.

_________________
Dragonus Cracovus: Biomagia

aparat cyfrowy tez chwyta ir nawet ten w komorce

Wysłane z telefonu

_________________
Usługi druku przestrzennego - www.drumik.pl

Hurra! Zadziałało!

W zasadzie sednem było ustawienie funkcji send_rc5_one i send_rc5_zero jak w oryginale

Dzięki!

------------------------ [ Dodano po: 37 minutach ]

Natomiast jeszcze ciekawostka: w procedurze obsługi przerwania, żeby to zadziałało, musiałem odwrócić kolejność ustawień rejestrów. Tj. najpierw ustawić kierunek i stan PD2, a dopiero potem kierunki i stany KEY1-KEY5.

Odwrotnie nie chciało ruszyć ISR...