Czy widzicie tu gdzieś błąd?
Przycisk na porcie PB2 powinien zmieniac zmienną setings_1 o 1 a procek zachowuje sie jak po restarcie czyli migają 3 dziody LED1 LED2 LED3.
Programuje dragonem w HVSP z RSTDISB
F_COU=1000000UL

Niby jest ok a nie działa.

Nawaliłeś kodu i w sumie błąd może siedzieć nie w jednym a w kilku miejscach. Mówię tobie, ze testy etapami jest o wiele szybsze. W kilka dni napiszesz mega softa, działającego, albo w 3 godziny i będziesz szukał błędu tydzień, jeżeli jest jeden, a jak więcej to dwa itd.

_________________
sig off ;(

hmm, może użyj innej zmiennej dla Timer1 i Timer2, ale nie wiem czy to coś da

Tak na szybko co mi przychodzi do głowy:



Zmienne inicjowane cholera wie na jaką wartość.
Sprawdź czy przerwanie wywołujesz tak często jak to jest potrzebne i czy nie używasz pinów do odczytu jak wyjście PWM.



Prościej zapisać tak:

Nie żadna cholera - tylko każdy kto poznał podstawy języka C - wie doskonale o tym jaką wartością będą zainicjalizowane te zmienne i dlaczego będzie to zero.

------------------------ [ Dodano po: 2 minutach ]



to teraz sobie porównaj ilość kodu w asemblerze pomiędzy sposobem zaproponowanym przez ciebie a tym sposobem wcześniej , i do tego jeszcze policz CO NAJWAŻNIEJSZE wtedy czas wykonywania się jednego sposobu i drugiego - bo czas ma tu niebagatelne znaczenie, a wtedy zrozumiesz dlaczego nie zawsze "PROŚCIEJ" oznacza LEPIEJ albo WYDAJNIEJ ... ok ?

_________________
zapraszam na blog: http://www.mirekk36.blogspot.com (mój nick Skype: mirekk36 ) [ obejrzyj Kurs EAGLE ] [ mój kanał YT TV www.youtube.com/mirekk36 ]

Tak, znam założenia C. Ale nie do końca ufam kompilatorom .



A czy ja napisałem, że tak będzie wydajniej ? PROŚCIEJ w sensie CZYTELNIEJ.
Co do czasu, który ponoć ma tu niebagatelne znaczenie - CZYTELNIEJ napisany kod zwiększa wynikówkę o ok. 30 cykli, co przy wywoływaniu przerwania co 1000 cykli nie ma znaczenia (samo przerwanie będzie miało do 100 cykli). A jeśli liczy się każda mikrosekunda to się pisze w asemblerze. Przy tak prostym programie kod napisany w asmie będzie szybszy i krótszy.

To w zasadzie po co w ogóle porgramować ? może lepiej robić coś całkiem innego do czego się ma zaufanie. A tak na marginesie to że zmienne globalne są zerowane to nie kwestia wiary



Po tym co piszesz można tylko wyciągnąć wniosek że nie do końca jeszcze rozumiesz ideę timerów programowych i zasadę ich działania w aspekcie zależności tego mechanizmu od działania całego programu, dlatego tylko rozumiem że piszesz takie dziwne rzeczy. Ale myślę że gdy zrozumiesz - to jednocześnie będziesz miał nieco inne zdanie w tym zakresie

_________________
zapraszam na blog: http://www.mirekk36.blogspot.com (mój nick Skype: mirekk36 ) [ obejrzyj Kurs EAGLE ] [ mój kanał YT TV www.youtube.com/mirekk36 ]

Przykład z zerowaniem zmiennych faktycznie nie był najlepszy ale kompilatory tworzą ludzie i nie są oni nieomylni.



Wow! to stwierdzenie jest tak ogólne, że nie wiadomo o co chodzi. Chętnie dowiem się czego nie rozumiem w kwestii używania timerów i jak to się ma do programu z pierwszego postu.

Witam

...kol.mickeu nie odniósł się do tego, ale ten wektor

jest faktycznie dziwny.

Pozdr.

Zastanów się co może się stać, jak nastąpi przerwanie od timera gdy będzie wykonywany np. ten fragment (procek 8 bit)

Witam wszystkich i jednocześnie chciałbym przeprosić za nie swoie winy>
Kod jest ok i śmiga jak szalały
Problemem był "kłaczek miedzi" o cieńszy od włosa pozostawiony przez firmę wykonującą płytki, "kłaczek" zwirał mase do +5 od procesora w momencie wciskania przycisku.
Pechem było to że owy "kłaczek" znajdował się pod kondensatorem tantalowym i do momentu wylutowania nie mogłem go znaleźć, znalazłem go używając lupy x20.

Dziekuje wszystkim za proby pomocy i jeszcze raz przepraszam za sytuacje jaka wyszła nie z mojej winy... ale wyszła.