Witam, to mój pierwszy post na forum. Jestem mniej niż początkującym, więc sporo jeszcze musiałbym się nauczyć by samodzielnie coś zaprogramować.

Postanowiłem wykonać projekt pilota na podczerwień z bluebooka (podstawy). Wykorzystałem tranzystor NPN z wylutu, zmieniając tylko w dwóch miejscach wskazane w kodzie instrukcje. Nie jestem pewien, jaki zastosować kondensator filtrujący przy zasilaniu - na schemacie narysowany jest kondensator niespolaryzowany 2,2uF, a o takiej wartości w sklepach są tylko duże, specjalne, foliowe kondensatory - czy o taki kondensator chodzi? Czy może powinienem podłączyć kilka mniejszych kondensatorów?

Zastosowałem kondensator elektrolityczny, ale układ nie działa prawidłowo. Układ zapala kontrolnie diodę przy włączaniu zasilania, ale nie reaguje na naciskanie przycisków. Dopiero później zorientowałem się, że wysyłanie komunikatu przy naciskaniu przycisków działa wtedy, gdy dotykam palcem lub metalowym przedmiotem pinów przycisków. Coś jest nie tak, bo układ działa dobrze tylko przy dotykaniu palcem, tak jakby dopiero zakłócenia prawidłowo wybudzały go ze stanu uśpienia. Czy przyczyną może być płytka stykowa, czy może brak odpowiedniego kondensatora? Układ zasilam napięciem 5V z gniazda gameport komputera.

Załączam kod programu. Od razu przepraszam za #define F_CPU 8000000L, ale programuję pod Linuxem i nie mam środowiska programistycznego - kod edytuję w Geany i kompiluję w konsoli. Ale jak będę robić poważniejsze projekty to będę pamiętał, by kwarc ustawiać w ustawieniach projektu

[ Panie kolego - PRZEDE WSZYSTKIM to bardzo cię proszę - nie umieszczaj kodów bibliotek z książek na forach, po co to robisz ? zastanowiłeś się ? ... jeśli tak każdy wstawi po jednej bibliotece na forach - to po co mi pisać książki i kody ? Szczególnie na tym forum każdy zwykle ma książkę więc co za problem powiedzieć że korzystasz z tego i tego kodu z książki .... no a jak robisz jakieś własne zmiany to co za problem pokazać tu tylko te fragmenty kodu które zmieniłeś - do oceny itp ? .... bardzo proszę miej to na uwadze na przyszłość - ok ? - mirekk36 ]

Zamiesc fotke tego co splodziles.

Witam

...oraz ten zmieniony fragment ( najlepiej linijki oryginalne oraz zmienione )
ATtiny, czy inny uC?

Pozdr.

W rozdziale z którego pochodzi schemat są również zdjęcia na których widać gotowy układ i jako że jest to maleńki pilocik to o dużych kondkach foliowych nie może być tu mowy, zapewne na schemacie chodzi o kondensator tantalowy/ceramiczny smd; tak do testów może być elektrolit (oczywiście właściwie spolaryzowany) ale jako że zasilasz to z zasilacza a nie z baterii to jeszcze dodaj przynajmniej jeden ceramiczny 100nF przy samym uC (zasilanie układu ze źródła które przekształca napięcie sieci 230V to nie to samo co zasilanie z baterii) .
Co do anomalii w działaniu programu na chwilę obecną to brak tu jakichkolwiek informacji które można by poddać analizie.
Czy układ zbudowałeś dokładnie według schematu (w sensie wybór pinów uC)?
Procesor w tym układzie jest wybudzany przerwaniem od INT0 więc pinu wspólnego dla przycisków nie można zmieniać (ewentualnie na INT2 ale wtedy trzeba pozmieniać zarówno definicję pinu jak i wektor przerwania) Jeśli procek nie reaguje to albo zmieniłeś właśnie ten pin albo masz źle wystawione sygnały na piny po drugiej stronie przycisków albo, albo ,albo... no właśnie bez konkretnych informacji z Twojej strony w postaci zdjęcia (ewentualnie schematu jeśli modyfikowany w stosunku do tego z BB) oraz jakie zmiany poczyniłeś w kodzie to niestety ale równie dobrze można powróżyć z fusów właśnie wypitej herbaty...

Najmocniej przepraszam, sądziłem że tylko kodu oznaczonego w książce jako biblioteka nie można kopiować, a nie głównego kodu programu. Początkowo nie chciałem tego wklejać, ale pomyślałem że nie każdy może mieć książkę pod ręką. Jeszcze raz przepraszam i oczywiście to się już nie powtórzy.

Niestety nie mam czym zrobić dobrej jakości zdjęcia, lepiej nie udało mi się zrobić:

Nie zmieniałem pinów, sprawdzałem oznaczenia wg datasheetu, kilkakrotnie sprawdzałem czy dobrze odczytałem schemat i nie znalazłem żadnego błędu. Dla testu zasiliłem też z baterii i dalej jest tak samo. Wg tego schematu zbudowałem układ na płytce:


Mikrokontrolera nie zmieniałem, jest to Attiny2313. Zmiana kodu polegała tylko na zakomentowaniu pierwotnych definicji (dla PNP) i odkomentowaniu wersji alternatywnych (dla NPN). Czyli tak wyglądały te dwa fragmenty po zmianie:



W pętli main:

Oczywiście musiałem też inaczej podłączyć tranzystor. Ale to nie jest przyczyną, bo kontrolne mignięcie diody przy włączaniu zasilania jest wykonywane prawidłowo, a przy naciskaniu przycisków K1-5 komunikat RC5 też jest nadawany (pod warunkiem trzymania palcem pinów mikrokontrolera) i odbierany przez wieżę hifi.
To chyba przeoczyłem to zdjęcie, bo nie wszystkie rozdziały czytałem, a nie mam teraz dostępu do książki.

Witam

Nie wiem czy mówimy o tym samym zdjęciu, bo raz że jest inne niż schemat a dwa że nie ma tylu przycisków.
Czy ten przycisk masz podłączony PB3/PD2 czy jakoś inaczej - na zdjęciu nie widać ew. kabelka do PD2.

A nie masz pomylone emiter z kolektorem?

Pozdr.

Na razie z braku miejsca na płytce mam podłączony tylko jeden przycisk zwierający PB3 z PD2 (przez szary kabelek nad procesorem). Na zdjęciu rzeczywiście nie widać połączeń pinu PD2 z przyciskiem i podłączenia GND do masy, bo są zrobione z drutu posrebrzanego (ze skróconych wyprowadzeń rezystorów), na prześwietlonym zdjęciu ich nie widać.
Wydaje mi się, że tranzystor NPN jest dobrze podłączony, skoro zapala kontrolnie diodę przy włączaniu zasilania i resecie układu oraz miga diodą przy wysyłaniu komunikatów. To chyba jego datasheet http://www.futurlec.com/Datasheet/Transistor/C9013.pdf.

A na pewno dobrze ci to kontaktuje? Wez to polutuj na pajaka i sprawdz. Bo moze skrocone nozki rezystorow sa za krotkie lub za cienkie.

Nie sądzę, bo przewodzenie jest, zastępowałem je innymi przewodami i też jest tak samo. Może coś z tym tranzystorem jest nie tak, bo jak włożyłem go odwrotnie to też dioda się zapala, tylko świeci nieco słabiej. Ale także wysyła komunikaty na "przycisk dotykowy".
Może rezystory do bazy są za małe, bo układ był na 4,5v, a zasilam go 5v? Ale z tego co widzę to nie przekraczam chyba napięć i prądów maksymalnych dla tego tranzystora. O ile znalazłem do niego odpowiedni datasheet.

Witam
Aby wyeliminować ew. błąd tranzystora do wyjścia PB2 zamiast w.w dołącz LED'a z odpowiednim rezystorem 330 - 680R i sprawdź co się dzieje.
Sprawdziłem czy nie ma erraty, wgrałem ten program w wersji NPN i PNP i gwarantuję że działa.
Nie wiem jak się pisze w czymś innym niż ECLIPSE, ale jeśli jest opcja to może nie ustawiłeś odpowiedniego uC - ATtiny2313?.

Pozdr.

Dlaczego 330-680R? Bo wg kalkulatora dla diody zielonej wychodzi 100R, a dla podczerwonej 190R, przy napięciu 5v i prądzie 20mA. Podłączyłem diodę zieloną do PB2 i do + przez rezystor 232R i działa odwrotnie, tj. świeci światłem ciągłym, a w momencie resetu mikrokontrolera gaśnie (tak jak mikrokontroler sterował tranzystorem NPN). W momencie wciśnięcia jednego z przycisków widać, że tylko delikatnie zmniejsza się jasność, praktycznie niezauważalnie. Przy naciskaniu dotykając palcem pozostałych pinów też tak samo przygasa, ale widać, że pulsuje.
Jak podłączyłem do minusa, to miga tylko po włączeniu zasilania lub resecie. Na przycisk nie reaguje, dopiero jak dotykam palcem to miga zgodnie z wysyłanymi komunikatami. Czyli to nie jest wina tranzystora. Dioda jest zapalana, wciskanie przycisków symuluję zwierając bezpośrednio odpowiednie nóżki mikrokontrolera. Zasilanie też poprawiam i dalej tak samo, więc przewodzenie jest. Pozostaje tylko program chyba, albo ten kondensator jednak musi być ceramiczny 2,2uF.

Witam

Żeby Cię w oczy nie raziło; przecież pisałem że do testów - masz tylko sprawdzić czy wyjście pracuje poprawnie.

...a wcześniejsze przykłady udało Ci się przerobić, czy zacząłeś od pilota.
Nie chodzi mi o jakieś wyśmiewanie, pytam tylko jaką masz praktykę w działaniu na tym sprzęcie o którym wspominasz.

Pozdr.

Pierwsze ćwiczenia z miganiem diodą trochę przećwiczyłem, do bardziej skomplikowanych układów nie mam na razie wszystkich części, np. wyświetlaczy. Projekt pilota był najprostszy pod tym względem, a że nie mam pilota do wieży to mnie zaciekawił możliwością praktycznego wykorzystania.
Wcześniej złożyłem sterownik midi na AT89S52, ale pisany w assemblerze. Zadziałał od razu, więcej czasu zajęło mi podłączenie klawiszy do sterownika niż kompilowanie i lutowanie (lutownicą transformatorową jeszcze).
Ale dzięki książce dopiero zrozumiałem, na czym polega programowanie i że byłbym w stanie się tego nauczyć (przedtem umiejętność programowania uważałem za jakieś zdolności nadprzyrodzone ), choć na razie traktuję to raczej jako zabawę. Od razu też stwierdziłem, że język C jest dla mnie bardziej zrozumiały (może dlatego, że wcześniej trochę liznąłem php przy wstawianiu paru skryptów na swojej stronie).

Sama zasada działania układu jest sprytnie pomyślana i bardzo prosta, więc dziwne że nie działa. Jeśli dysponujesz miernikiem to zmierz napięcie na pinie PD2 w stanie spoczynku - napięcie powinno przedstawiać "1" czyli napięcia trochę niższe niż zasilanie.
Natomiast na PB3 czyli po drugiej stronie przycisku powinieneś mieć napięcie bliskie "0". Jeśli tak jest Ponownie zmierz napięcie na pinie PD2 i ciągle mierząc naciśnij przycisk - napięcie powinno spaść do zera - jeśli tak jest, to od strony sprzętu wyglądało by OK.


Powyższe nasuwa podejrzenie że problem leży albo w połączeniach pomiędzy pinami procka a przyciskiem (pomyłka w numerze pinu procka lub niepewne połączenia), albo w samym przycisku. Skoro dotykanie palcem powoduje zadziałanie układu to oznacza że sam program procka przecież działa...
Niestety ale stykówki często są powodem problemów dla tego przy budowie układów na stykówkach trzeba najlepiej miernikiem sprawdzać przejścia pomiędzy elementami układu.

Jeżeli jednak sprzętowo będzie wszystko ok to jedyne co jeszcze możesz sprawdzić to czy po naciśnięciu przycisku w ogóle procesor się wybudza i wykonuje skok do obsługi przerwania. Na samym początku procedury obsługi przerwania wstaw fragment kodu odpowiedzialny za mrugnięcie diodą (ten z początku main). Jeżeli naciśnięcie przycisku spowoduje mrugnięcie diodą to oznaczało by że problem leży w warunkach sprawdzających naciśnięty przycisk..

Spróbuję, w tym miejscu?Wgrałem wcześniej oryginalny kod bez żadnych zmian i też nie działa.
Przy najbliższej okazji kupię jeszcze nowe kondensatory, mam stare z wylutu 100nF więc może nie są już do końca sprawne. Jak podłączyłem większy kondensator ceramiczny to dioda parę razy lekko zajarzyła. Do PB2 mam podłączonych szeregowo kilka rezystorów, może przez to układ jest bardziej podatny na zakłócenia.

Edit: Dodałem to mignięcie diodą i nie zapala jej po naciśnięciu przycisku.
Do czego służy ta zakomentowana linijka , zaraz po kontrolnym mignięciu diodą w main?

Powyższe służy do kalibracji oscylatora.


Czyli procesor w ogule nie wybudza się z uśpienia... A mierzyłeś napięcie na PD2?

Na PD2 w czasie spoczynku jest 1, po wciśnięciu 0. Natomiast na PB1 cały czas jest 0, napięcie tylko minimalnie wzrasta po naciśnięciu przycisku, nawet jak piny zwieram bezpośrednio przewodem. Mierzyłem starym miernikiem analogowym, bo padła mi bateria w multimetrze.

Witam
Tak dla pewności - "przyciskaczek" masz dobrze podpięty? ( właściwe nóżki?)

Pozdr.

Tak, ma tylko dwie nóżki. Jak odwracam to też nie działa
Przycisk zwiera PD2(INT0) z PB1. Dioda przez rezystor do PB2. Zasilanie + do VCC, - do GND. Kupiłem kondensator tantalowy 2,2uF i też to nie pomogło.
Zaprogramowałem jeszcze raz i jednak wybudza się - po wciśnięciu przycisku zapala diodę tak jak wstawiłem w przerwaniu. Przedtem pewnie zły plik wgrałem. Ale komunikatów dalej nie wysyła.
Czy mógłby ktoś podesłać mi gotowy, skompilowany dla Attiny2313 plik hex dla testu? Może coś mi Geany przekłamuje z powodu kodowania, bo nie zapisuje w ISO i musiałem przekodować na UTF-8. Ale dziwne, że kompilator nie zwraca żadnych błędów.

Ale gotowy plik skompilowany masz w oryginalnym folderze projektu na płycie/pendrivie z BB. Plik z rozszerzeniem hex w podkatalogu Release.
Zachowanie stanów na PD2 i PB1 w czasie naciskania przycisku jest początkowo właściwe o czym świadczy zresztą mignięcie diodą. Problem w tym że jakby nie wykonuje się test naciśniętego przycisku...
Jeżeli procek się wybudza i przechodzi do wykonywania procedury obsługi przerwania to możesz próbować debugować dalej.
Musisz przeanalizować dalsze instrukcje w przerwaniu. Na początku przerwania zamieniane są kierunki działania pinów.
Pododawaj sobie paskudne delaye pomiędzy rozkazami (tak brzmi jak herezja delay w przerwaniu - ale do debugowania można) wystarczająco długie byś mógł miernikiem zaobserwować czy poszczególne rozkazy się wykonują.
I tak mrugającą diodę na początku przerwania bym zostawił, nawet wydłużył jej czas świecenia dla pewności że zdążysz puścić przycisk zanim wykonywanie przerwania pójdzie dalej. Chodzi o to by rozewrzeć PD2 od PB1 i raz zmierzyć co się dzieje na PD2 a drugi raz co na PB1.
Swoją drogą jak wytrwasz i dojdziesz do problemu to takiego pilota później zbudujesz z zamkniętymi oczami .

Tylko że jak programuję oryginalnym plikiem hex to kompilator krzyczy, że nie zdefiniowałem częstotliwości kwarcu i mikrokontroler działa w przyśpieszonym tempie, muszę mu wstawić do kodu to paskudne #define F_CPU 8000000UL Ale przyjrzę się składni komendy kompilatora, może da się mu podać w opcjach częstotliwość. Bo rozumiem, że fusebity powinny być ustawione na 8MHz?
Jak to nie pomoże, to zacznę podejrzewać, że Attiny polubiła to głaskanie palcem i tak się uzależniła, że bez tego nie chce działać

Edit: zaprogramowałem oryginalnym hexem z płyty i też nie działa - skoro kod z książki działa to chyba można wykluczyć błąd w programie, chyba że miałem jakieś inne wydanie. Pozostaje tylko kwestia niepewności styków w takim razie, choć nie sądzę, bo przestawianie układu na płytce nie pomaga.

Dopisałem parametr -DF_CPU=8000000UL do avr-gcc i teraz już mogę z czystym sumieniem kompilować bez #define F_CPU w kodzie

Tak, a najlepiej zweryfikuj czy nie masz np ustawionego CKDIV8, oraz CKOUT (generalnie fusy powinieneś mieć: LOW=0xE4, HIGH=0xDF, EXTENDED=0xFF)

No właśnie nie do końca bo przecież dodane miganie diodą na początku przerwania powoduje mrugnięcie diody po naciśnięciu przycisku...
A próbowałeś podłączyć przycisk pod inne porty pod którymi są pozostałe kody zaprogramowane (PB3, PB4, PB5, PB6)? Może coś jest nie tak z pinem PB1?

Fusebity ok. Na innych portach też miga.

Ale miga w sensie dodana komenda na początku obsługi przerwania (czyli jedno mignięcie) czy miga wysyłając kod RC5?

Nie, tylko to jedno mignięcie. Dopiero jak dotykam pozostałych pinów to po tym mignięciu zaczyna wysyłać komendy, ale muszę dłużej przytrzymać przycisk.

A przenieś to mrugnięcie diodą z początku procedury obsługi przerwania nieco niżej przed funkcję "do" zaraz po zmianie stanu bitu toggle i zobacz czy naciśnięcie przycisku również powoduje mrugnięcie (będziesz wiedzieć czy w ogóle program widzi wciśnięty przycisk po zmianie kierunków). Ale najlepiej jak byś powstawiał delaye i pomierzył jak się zachowują poszczególne piny po wciśnięciu przycisku tak jak Ci wcześniej radziłem...

Przeniosłem to mignięcie przed funkcję "do" i już dioda nie migała. Jak powstawiałem delaye to przy dłuższym przytrzymaniu dopiero dioda miga i po tym wysyła komunikat (pierwszy raz bez trzymania palcem ).

Ok to wywal teraz delaye i to mrugnięcie diodą i spróbuj czy dłuższe przytrzymanie też spowoduje wysłanie komendy - coś mi wygląda to albo na wadliwe połączenie na drodze przycisk - stykówka - piny procesora albo przycisk jest wadliwy i nie do końca styka. Bo ewidentnie procek się wybudza i przechodzi do wykonywania przerwania, ale zdecydowanie ma problemy z wykryciem naciśniętego przycisku już w przerwaniu...

Ale gdyby przycisk był wadliwy, to działałby gdy zwierałem piny bezpośrednio kawałkiem przewodu. Wcześniej jak przyciskałem dłużej to też nie pomagało. Może ten delay do eliminacji drgań styków jest zbyt czuły i blokuje wszystkie wciśnięcia?

Oglądałeś poradniki Mirka na temat drgań styków i sposobów ich eliminacji?