ATNEL tech-forum

Re: Składanie zmiennej - dziwny problem

2015-10-16T09:49:24+01:00

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.

Statystyki: Napisane przez robi99956 — 16 paź 2015, o 09:49

Re: Składanie zmiennej - dziwny problem

2015-10-15T19:42:11+01:00

Federerer napisał(a):

Sprawdzałeś czy nie brakuje Ci stosu?

Quote:

To raczej nie jest problem.

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]

Statystyki: Napisane przez Krauser — 15 paź 2015, o 19:42

Re: Składanie zmiennej - dziwny problem

2015-10-15T07:59:21+01:00

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.

Statystyki: Napisane przez robi99956 — 15 paź 2015, o 07:59

Re: Składanie zmiennej - dziwny problem

2015-10-14T22:16:15+01:00

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"?

Statystyki: Napisane przez Federerer — 14 paź 2015, o 22:16

Re: Składanie zmiennej - dziwny problem

2015-10-14T19:25:18+01:00

robi99956 napisał(a):

Co synchronizację była zupełnie inna godzina

Znaczy, że rzutowanie nie przejdzie, ale w tablicy można zamienić kolejość:
[syntax=c]CONV conv;
conv.tab[0] = buf[0x55];
conv.tab[1] = buf[0x54];
conv.tab[2] = buf[0x53];
conv.tab[3] = buf[0x52];
*time = conv.number;[/syntax]

Statystyki: Napisane przez Krauser — 14 paź 2015, o 19:25

Re: Składanie zmiennej - dziwny problem

2015-10-14T19:07:09+01:00

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 .

Statystyki: Napisane przez robi99956 — 14 paź 2015, o 19:07

Re: Składanie zmiennej - dziwny problem

2015-10-14T15:57:21+01:00

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.
[syntax=c]#include
#include

uint32_t t;
uint8_t buf[10];

typedef union
{
uint8_t tab[4];
uint32_t number;
}CONV;

int main(void)
{
uint16_t seed = 0xABCD;
uint32_t * time = &t;
srand(seed);
for(uint8_t i = 0; i < 10; ++i)
{
buf[i] = rand() & 0x00FF;
}
asm volatile("nop\r\n"::);
#if 0
*time = ( ( (uint32_t)buf[2] << 24 ) | ( (uint32_t)buf[3] << 16 ) | ( (uint32_t)buf[4] << 8 ) | ( (uint32_t)buf[5] ) );
#endif

#if 1
*time = *((uint32_t *)(buf+2));
#endif

#if 0
CONV conv;
conv.tab[0] = buf[2];
conv.tab[1] = buf[3];
conv.tab[2] = buf[4];
conv.tab[3] = buf[5];
*time = conv.number;
#endif
asm volatile("nop\r\n"::);
PORTA = *time & 0x000000FF;
while(1)
{

}
return 0;
}[/syntax]

Daje od nopa do nopa:
[syntax=bash]d6:80 91 0a 01 ldsr24, 0x010A
da:30 91 0b 01 ldsr19, 0x010B
de:20 91 0c 01 ldsr18, 0x010C
e2:90 91 0d 01 ldsr25, 0x010D
e6:80 93 04 01 sts0x0104, r24
ea:30 93 05 01 sts0x0105, r19
ee:20 93 06 01 sts0x0106, r18
f2:90 93 07 01 sts0x0107, r25[/syntax]

Statystyki: Napisane przez Krauser — 14 paź 2015, o 15:57

Re: Składanie zmiennej - dziwny problem

2015-10-13T15:27:19+01:00

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.

Statystyki: Napisane przez robi99956 — 13 paź 2015, o 15:27

Re: Składanie zmiennej - dziwny problem

2015-10-12T20:20:10+01:00

Sprawdzałeś czy nie brakuje Ci stosu?

Statystyki: Napisane przez Federerer — 12 paź 2015, o 20:20

Składanie zmiennej - dziwny problem

2015-10-11T16:17:18+01:00

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:
[syntax=c]*time = ( ( (uint32_t)buf[0x52] << 24 ) | ( (uint32_t)buf[0x53] << 16 ) | ( (uint32_t)buf[0x54] << 8 ) | ( (uint32_t)buf[0x55] ) );[/syntax] 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?

Statystyki: Napisane przez robi99956 — 11 paź 2015, o 16:17