Problem z wykonaniem warunków

[WREALCON]

Witam

Mam ciekawy problem:
Jest sobie zmienna CA, której wartość mieści się w zakresie <0, 63>.
Górną granice sprawdzam poprzez warunek:
if (CA == 64) CA = 63

Po kilku - kilkunastu godzinach warunek ten nie jest wykonywany i program sie "wiesza", gdyż wykonuje funkcje dla wartości powyzej 63.
CA jest modyfikowane tylko w jednym miejscu (inkrementowana). Poza tym jednym miejscem, CA jest zczytywane.
Używam CrossWorksa. Na zasilaniu (wyjscie z 7805) jest jeden kondensator 1uF. Nie dawałem na nóżkach dodatkowych 100nF.
Zastanawiam się, czy to nie jest problemem. Jeśli tak, prosiłbym o wyjaśnienie, dlaczego się tak dzieje.
Jeśli nie jest to problemem, proszę o jakieś sugestie

Pozdrawiam,
wrealcon

[gaweł]

Niewiele jest tu informacji technicznych. Sugestie hadrware'owe: jaki to procek (oprócz tego, że byc może AVR), problem blokady zasilania jest istotny. Jeżeli procek ma kilka nóżek zasilających, to każdą trzeba blokować kondensatorem. Może masz słaby zasilacz i do zasilania układu przedostają się zakłócenia z sieci. Jak byś zrobił badanie z użyciem akumulatora, to można by było coś już wykluczyć. Kolejne pytanie jest taki: czy to dzieje się zawsze po tych kilku-kilkunastu godzinach, czy tylko czasami?
Sugestie software'owe: to wizyta u wróżki, z tych informacji nic nie wynika. Czy niewłaściwa zawartość zmiennej jest źródłem zawieszania? Czy jest watchdog? A może by tak kawałek kodu?
Przy okazji to powinno być napisane:

if(CA>=64) CA = 63;

Zauważ, ze to rozwiązanie jest "strukturalnie stabilne".

[WREALCON]

Gaweł, już postaram się napisać szerzej, jak to wygląda:
Software, kod:
void main(void)
{
unsigned int CA = 0;
while (1)
{
ProcessAddress(CA);
CA++;
if (CA == 64)
CA = 0;
}
}
Brak watchdog'a. Pisząc, że się zawiesza, mam na mysli, że zmienna jest powyżej 64, tak więc program przetwarza dane zbędne, które zabierają masę czasu i czas potrzebny do "przekręcenia" się zmiennej CA jest na tyle wysoki, iż można nazwać to zawieszeniem się układu.

Gaweł, wiem, że powinno być CA > 63, jednak sam fakt, że takie coś ma miejsce, jest troche zastanawiające. I dzieje się to cały czas po tych kilku - kilkunastu godzinach.

HARDWARE:
Zasilanie:
Wejściowe 12V(z komputerowego z odzysku) + kondensator 1uF, 7805, na wyjściu 5V + kondensator 1uF.
Przy nóżkach procka nie ma żadnych kondensatorów blokujących (tak jak pisałem w poscie pierwszym). Jakie tam powinny być ?? 100nF ?? Jaki mialoby to wplyw na dzialanie procka ?

Procesor:
Atmega 16, DIP40, 16MHz, 5V.

Jakieś sugestie ??

[alaris]

Jakie tam powinny być ?? 100nF ?? Jaki mialoby to wplyw na dzialanie procka ?

Tak 100n, przy kazdym, dodatnim pinie zasilajacym. Jezeli chodzi o dzialanie, to elementy te zmniejszaja przedostawanie sie zaklocen elektromagnetycznych do ukladu.
Twoj przypadek jest rzeczywiscie dziwny, jednakze moje doswiadczenie mowi, ze wina zazwyczaj lezy po stronie programisty. Zobacz, czy wewnatrz funkcji ProcessAddress nie dokonujesz modyfikacji zmiennej CA. Jezeli nie, to ustalenie przyczyny w sposob "rozumowy" bedzie dosc trudne... Ja zaczalbym od zastawiania pulapek w programie, tzn. wysylania na wyswietlacz/terminal zmiennych i probowal ustalic jaka sytuacja powoduje taki blad.
A przy okazji: jak u Ciebie z pamiecia? Jezeli wykorzystujesz duza czesc pamieci uK, jest ryzyko, ze nadpiszesz swoje dane. Poza tym czy nie uzywasz wskaznikow/zmiennych deklarowanych dynamicznie, co tez powoduje czasem problemy z niszczeniem danych...

[WREALCON]

Co do programistycznej strony, to jestem pewien, że CA modyfikuje tylko w main i że podaje ją przez wartość do funkcji. Nie używam wskaźników.
Zużycie RAM'u jest na poziomie 400B, tak więc tu też powinno być OK.
Moim strzałem jest to, że może brak tych kondensatorów powoduje jakieś błędne działanie np. RAM'u, co powoduje przekłamanie wartości części bajtów (raz na jakiś czas), w których też jest zapisana wartość CA. Wynikiem tego byłoby to, że warunek jest sprawdzany poprawnie, zaś wartość CA jest zła...

Czy jest taka możliwość w ogóle ?

[elektronWielki]

pokaż cały program i schemat układu

[gaweł]

Gaweł, już postaram się napisać szerzej, jak to wygląda:
Software, kod:
void main(void)
{
unsigned int CA = 0;
while (1)
{
ProcessAddress(CA);
CA++;
if (CA == 64)
CA = 0;
}
}

Sugeruję zastosowanie takiego eksperymentu badawczego:

Kod: Zaznacz cały

void main(void) 
{ 
unsigned int CA = 0; 
<Zgaś LED'a>;
while (1) 
{ 
if(CA>=64) <Zapal Led'A>;
ProcessAddress(CA); 
CA++; 
if (CA == 64) 
CA = 0; 
} 
}

Gdzie <zapal LED'a> i <Zgaś LED'a> robi wiadomo co na dowolnym wybranym pinie dowolnego portu z przyłączoną diodą LED. Jakie będą efekty?
Dla późniejszej praktyki warto to zrobić dla wariantu z i bez kondensatorów 100nF. Rozumiem, że badania są czasochłonne, ale tak to już jest.

Moim strzałem jest to, że może brak tych kondensatorów powoduje jakieś błędne działanie np. RAM'u, co powoduje przekłamanie wartości części bajtów (raz na jakiś czas), w których też jest zapisana wartość CA.

Strzał nie jest pozbawiony sensu. Napisałeś wyżej, że procek jest napędzany przez 16MHz, więc zauważ, pracuje z dużym impulsowym poborem prądu. Każda zmiana stanu wewnętrznych bramek, przerzutników etc w procku skutkuje impulsowym poborem prądu. Dlatego daje sie kondensatory (typowo 100nF) na każdym pinie zasilania jak najbliżej układu i nie mogą to być kondensatory styrofleksowe (najlepiej jakieś monolityczne).

[Aro]

Jeśli masz możliwość to spróbuj uruchomić program na innym procku. Sam miałem kiedyś dziwny przypadek uszkodzenia dwóch komórek pamięci RAM. Jak nie masz drugiego procka pod ręką to spróbuj zmienić adres zmiennej.
Wątpię w winę kondensatorów, bo wiem z doświadczenia, że procesory AVR są bardzo odporne na takie impulsowe zakłócenia. Mam nawet przed sobą płytkę z plątaniną kabli na której do niedawna nie było żadnych kondensatorów, a mimo to procesor chodził bez problemu z kwarcem 16MHz. Dodam, że do tej samej szyny jest podłączona przetwornica impulsowa także bez kondensatora. Aż boję się pomyśleć jak bardzo zaśmiecone było napięcie zasilania.... Problem zaczął się podczas wysyłania do AVRka równolegle 8 bitów z częstotliwością 16MHz(!!!). Wtedy pojawiał się "śnieg" na wyświetlaczu graficznym, ale procesor wciąż uparcie działał poprawnie.
Poza tym radze sprawdzić dokładnie cały program na symulatorze, czasem niektóre rzeczy są zbyt oczywiste, żeby zwracać na nie uwagę

[WREALCON]

Problem rozwiązany.

Dodałem 2 kondensatory 100nF przy nóżkach zasilajacych i działa od 36 godzin z warunkiem CA==64.

Dziekuje za uwagę,
wrealcon.

[gaweł]

(...)Dodałem 2 kondensatory 100nF przy nóżkach zasilajacych(...)

Taki kondensator powinien znajdować się przy KAŻDYM cyfrowym układzie scalonym użytym w urządzeniu (a dokładniej to przy każdym pinie zasilającym, bo są układy mające kilka wyprowadzeń zasilających).