Witam, jakiś czas temu wysypał się mój zegar NTP. Szukając przyczyny problemów natrafiłem na bardzo ciekawą rzecz. Metodą komentowania kolejnych linii kodu doszedłem, że problem leży w zdarzeniu od NTP, które wcześniej działało bez problemów. Schodząc głębiej spotkałem jeszcze większe dziwy - procek blokował się nie w pętli ani inny podejrzanym miejscu, ale tu:
Wewnątrz funkcji client_ntp_process_answer z biblioteki tuxgraphic, przy operacji która, przynajmniej według mojej wiedzy, nie ma prawa nic blokować.
Dodam jeszcze, że taka sytuacja zdarzyła się wcześniej kilka razy, ale wtedy wystarczyło na chwilę wyłączyć zasilanie i wszystko ruszało.
Widział któryś kolega kiedyś takie cuda?

Sprawdzałeś czy nie brakuje Ci stosu?

_________________
Pozdrawiam, Adrian.

To raczej nie jest problem. Tzn. przy starym stanie ramu(83,6%) mogło tak być, zwłaszcza że mam dość pamięciożerne funkcje, ale teraz zjechałem do 64,4% i dalej to samo.

W czystym projekcie spróbuj tą konwersję zrobić rzutując na wskaźnik 32-bitowy albo z użyciem unii tablicy i zmiennej 32-bitowej. Porównaj kod asemblerowy np.


Daje od nopa do nopa:

_________________
Dragonus Cracovus: Biomagia

Sprawdziłem oba warianty, i przy obu działało, tyle że na wyjściu otrzymywałem jakieś głupoty. Co synchronizację była zupełnie inna godzina.
Najpierw myślałem, że to przez zwykłe niedopatrzenie - 52 zamiast 0x52, ale po zmianie(i czyszczeniu projektu) nic się nie zmieniło. Na koniec, w akcie desperacji zakomentowałem nowy kod i odpaliłem na powrót to co było. I teraz najlepsze - ruszyło od strzała jak trzeba Na razie działa, jakby znowu coś się walnęło to dam znać. I dzięki Krauser za pomoc, nie wiem jak, ale twoje metody chyba uzdrowiły ATmege .

Znaczy, że rzutowanie nie przejdzie, ale w tablicy można zamienić kolejość:

_________________
Dragonus Cracovus: Biomagia

Nie przejdzie, bo kolega trzyma dane w buforze od najstarszego bajtu (big endian) a AVRy są "little endian". Tak mi jeszcze przyszło do głowy pytanie. Przestawiasz gdzieś jeszcze w kodzie ten wskaźnik "time"?

_________________
Pozdrawiam, Adrian.

Nie, to jest argument funkcji z biblioteki tuxgraphic. Używam go tylko w tym miejscu. A po drodze to wygląda tak:
1. Jest sobie globalna struktura w której trzymam wszystkie dane o czasie.
2. Wskaźnik do tej struktury jest przekazywany do zdarzenia od NTP.
3. W tym zdarzeniu wskaźnik do pola struktury z czasem unixowym idzie do funkcji bibliotecznej (tak - &czas->czas_unix)
Zauważyłem jeszcze jedną rzecz, otóż dekodowanie z odwróconymi bajtami nie wiesza systemu, efekt jest taki sam przy unii i rzutowaniu. Natomiast ręczne składanie i odwrócona unia dają efekt w postaci zawieszenia.

W Greenbooku Mirek opisuje jak monitorować stos, a na płycie jest oczywiście kod programu. To, że po kompilacji masz pokazane użycie pamięci na poziomie 64% oznacza tylko tyle, że zmienne globalne tyle zajmują. Sprawdź sobie co zmieni zdefiniowanie dużej tabeli przed funkcją main i w funkcji main. Ta tablica buf jest raczej duża wnioskując po buf[0x52]

_________________
Dragonus Cracovus: Biomagia

Wiecie co koledzy? Należą się wam przeprosiny. Problem nie leżał w tym miejscu. Dziś wrzuciłem projekt na zestaw ATB, i sytuacja się powtórzyła. ATmega1284 automatycznie wyklucza wszelkie problemy ze stosem, więc zacząłem szukać gdzie indziej. Okazało się, że w funkcji wykonującej korekcję czasu do odpowiedniej strefy czasowej wkradła się potencjalna pętla nieskończona. Zakomentowanie składania czasu unixowego sprawiało, że jej warunek był zawsze fałszywy, więc nie powodowała wtedy problemów. Na razie wygląda na to, że wszystko jest OK, ale to potwierdzi dopiero dłuższa obserwacja. Dzięki wam obu za zainteresowanie sprawą i mam nadzieję, że taka sytuacja się nie powtórzy.