s->tab[i]

W dniu 2013-05-17 05:18, Zbynio pisze:

Tak, jak coś spie@#$@#sz. Słyszałeś o czymś takim jak debuger?

Przy zalozeniu, ze "s" to wskaznik na strukture a nie sama struktura, powinno byc ok. Na szybko sobie sprawdzilem w Keilu na inny procesor, czy z punktu widzenia C jest ok. Wersja "s->tab[i] = ptr[i];" troche optymistycznie przyjmuje, ze adres poczatku struktury jest tozsamy z poczatkiem pierwszej tablicy w niej zawartej (jesli jest pierwszym elementem struktury). Tu bedzie probowac przepisywac kolejne bajty z poczatku struktury do tablicy, bedacej gdzies w tej strukturze. Jak dla mnie to ryzykowne, pozniejsze zmiany w typedef structury na pewno cos popsuja. Marcin

No w³a¶nie. Co do panowania nad struktur± to nad ni± panujê, bo mam j± po to ¿eby by³a to taka swoista "lookup table". Le to jedno miejsce nie dzia³a i ju¿ wczoraj siê dziwi³em co jest nie tak, robi³em podwójne inicjowaie wska¼ników, dla pewno¶ci. Czy znaczy mam nie przyjmowaæ do wiadomo¶ci, ¿e adres struktury to pocz±tek pierwszego elementu? To jest wtgodne, bo raz rozmawiam ze struktu±, albo przez strukturê po elementach

s->tab1[] s->tab2[]....

a raz traktujê j± jako ci±g³y obszar jak kawa³ek ramu liczony od wska¶nika ustawionego na pocz±tek. Wszêdzie mi dzia³a tylko to kopiowanie nie dzia³a.

Ale jak wpiszê:

s->tab[i] = ptr[0x98]; czy inny 0x to dane w tab[i] s± dobre :-) Te co siedz± tam wzglêdem ptr. Tak jakby zmiennej nie bra³ pod uwagê. Zupe³nie irracjonalna sprawa.

Użytkownik "Zbynio" napisał w wiadomości

Wszystko sie moze zle skompilowac jak jest blad kompilatora :-) Czas zajrzec w wygenerowany kod w assemblerze.

Poprawnie.

tez poprawnie.

A "i" jest prawidlowe ? Nie traktowane jako ujemne ?

J.

W dniu 2013-05-17 09:06, Zbynio pisze:

Pokazujesz tylko fragmenty kodu, oczekując podpowiedzi, co jest źle. Tymczasem błąd tkwi pewnie w kodzie którego nie pokazałeś :)

Czy w strukturze oprocz tablic sa jeszcze jakies inne dane ? najlepiej podaj tu definicje calej struktury, bedzie wiadomo co w niej siedzi. Takie moje gdybanie bez znajomosci kodu. Na AVRy dosc dawno nie pisalem, ze moze kompilator cos optymalizuje ( struct packed ??? ale zastanawiam sie, czy packed dla 8 bitowej platformy ma znaczenie ??) .

Tablice zawarte w strukturze sa typu uint8_t ??

Sprobowalem taki kawalek kodu ale __UWAGA__ nie w AvrStudio !! /*********************************/ typedef struct tdAvrStruct { UINT8 i; UINT8 tablica[10]; UINT16 tablica16 [10]; UINT16 licznik;

} AVR_STRUCT;

AVR_STRUCT myStruct, *pmyStruct; UINT16 j;

pmyStruct = &myStruct;

for (j=0; j < 10; j++) pmyStruct->tablica[j] = j;

for (j=0; j y 10; j++) pmyStruct->tablica16[j] = 3 * pmyStruct->tablica[j]; /*********************************/

i po wykonaniu mam w tablica16 trzykrotnie zwiekszone wartosci wczesniej zainicjalizowane w tablica.

mozesz tez sprobowac zamiast :

while (i--) { s->tab[i] = ptr[i];

czegos takiego: while (i--){ s->tab[i] = * (ptr + i ); } teoretycznie to samo jak ptr[i], ale moze faktycznie kompilator cos miesza? Marcin

void test(void) {

size_t i;

uint8_t buf[32];

uint8_t *ptr = (uint8_t *)&mystruct;

eeprom_read_block((void*)&buf[0], (const void*)(EEDATA), 34);

for (i=buf[0]; i<buf[1]; i++) {

f->A[i] = ptr[ buf[2 + i] ];

W eepromie siedzą numery póll struktury, które mam sobie pobrać.

adres 0 to początek

adres 1 ilosc

Tam jest buf[34], teraz ręcznie to przepisałem z błędem

void test(void) {

size_t i;

uint8_t buf[34];

uint8_t *ptr = (uint8_t *)&mystruct;

eeprom_read_block((void*)&buf[0], (const void*)(EEDATA), 34);

for (i=buf[0]; i<buf[1]; i++) {

f->A[i] = ptr[ buf[2 + i] ];

Aż wstyd się przyznać :-)

W #define EEDATA pomyliłem adres w eepromie i patrzyłem na to 100 razy, a były 2 cyferki zamienione miejscami i czytał z obszaru eepromu gdzie były zera :-) Oh LOL :-)

Ale za to przerobiłem wszystkie sposoby zapisu i odwoływania się przez wskaźniki :-) Zawsze to coś :-)