Hej, bardzo mi się podoba twórczość mirka36, jak do tej pory wiekszość jego porad działała bez zarzutu, do czasu gdy natknąłem się na eeprom.
Korzystam z atmel studio 6.1 (kwestia przyzwyczajenia). Problem dotyczy zapisu/odczytu bloku zmiennych. Mam wrażenie, że zmienne te albo zapisują się pod niewłaściwym adresem, albo coś przerywa zapis/odczyt, albo robie to błędnie, albo to przez dużą ilość zmiennych w strukturze typu float sprawia problem, albo sam nie wiem w czym rzecz i gdzie dalej szukać.
Założenia są takie, że podczas pierwszego uruchomienia programu ma przyjąć wartości domyślne. W trakcie działania programu te wartości będą zmieniane, później kopia RAM->EEPROM,
Przy starcie najlepiej jakby automatycznie wykrywał czy nastąpiła zmiana względem domyślnych wartości, jednak aby ułatwić debugging - póki co zrobilem sobie na buttonsach, probowalem również z Mirkowskim check_and_load_defaults, jednak za kazdym razem wczytywal ustawienia domyslne (funkcja otrzymuje same 0xFF??? to by wskazywało, że zapis szwankuje).

Z eepromem bawię się pierwszy raz, jednak znając działanie większości istotnych funkcji służącym przerzutu z jednej pamięci do drugiej nadal nie jestem w stanie sobie z tym poradzić.

oto fragmenty programu z którymi walczę od pół dnia, jeśli nie więcej (( wrzucam to co jest odpowiedzialne za zapisy, odczyty ponieważ nie chce zaśmiecać :



Rezultat jest taki, że gdy wybiore "z palca" wczytaj eeprom -> ram, jako wynik dtostrf(jakis parametr z CONFIG_RAM) dostaje "NAN" - prawdopodobnie "not a number" (reakcja na 0xFF???)
Stąd też albo zapis szwankuje albo odczyt, albo po prostu nie nadaje sie do tego i powinienem olać sprawe ;D.
Gdy wgram pliczek EEPROM wygenerowany przez kompilator i zrobie wczytywanie eeprom przy starcie otrzymuję wszędzie zera. (A to raczej prawidłowo bo deklaruję
CONFIG CONFIG_EEMEM EEMEM; bez żadnych wartości) .
samo void USTAWIENIA_INOUT() znajduje się w przerwaniu od timera. Do tej pory nie odnotowalem problemow z czyms takim:
ISR()
{
disable ISR;
rob cos.
enable ISR;
}
Jeszcze pomyslalem o czyms takim jak ATOMIC_BLOCK (podobno nie dopuszcza do przerwania jakiejs procedury, ale to moze tylko pogloski )
Prosze serdecznie o pomoc, dziekuje.

------------------------ [ Dodano po: 14 minutach ]

ALE ZE MNIE DUPKA WOLOWA pomylilem argumenty w:

eeprom_write_block (&CONFIG_EEMEM, &CONFIG_RAM, sizeof(CONFIG_EEMEM) );
powinno byc:
eeprom_write_block (&CONFIG_RAM, &CONFIG_EEMEM, sizeof(CONFIG_RAM) );

Temat do skasowania, albo mozecie zostawic i sie ze mnie smiac i obrzucac jablkami
Albo zostawic jako przestroga - dopiero po napisaniu postu i przeczytaniu jeszcze raz uswiadomilem sobie ta pomylke.

dobrze ze znalazles błąd ale w tym swoim isr ... tak nawiasem mowiac kolejnego babolka robisz

_________________
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 ]

Ktos kiedys madry napisal, ze nie ma sensu ustawiania cli() oraz sei() w przerwaniu i z tym sie zgodze.
Ktos inny jeszcze, ze kazde przerwanie ktore sie rozpoczelo dopoki sie nie skonczy nie zacznie robic nic innego, no i tutaj sie nie zgodze, bo majac w ISR(TIMER0_ovf) refresh od LCD (co ok pol sekundy) , a jednoczesnie majac w ISR(timer2_ovf) komunikat, który uzywa _delay_ms(); jest przerywany mimo to. Z drugiej strony zabawa z flagami... ok, ale trace precyzje wykonywania programu. Majac dosyc obszerny program nalezy liczyc sie z tym ze czesc rzeczy z while(1) wogole sie nie wykona.

... ale tu nie chodzi o to co ktos madry powiedzial ... albo czy dawanie cli w przerwaniu ma sens czy nie. To nie jest kwestia jakiejs tam interpretacji ... czy przyjmowanie czegos na zasadzie wiary .... bierzemy pdf procka w reke a tam jak byk jest napisane ze po wejsciu w przerwanie procek SAM automatycznie blokuje przerwania natomiast przy wyjsciu je odblokowuje i to po rozkazie RETI. A to co kolega pisze w przerwaniu czyli cli o tyle nie jest szkodliwe ze nic nie zmienia a tylko tracimy niepotrzebnie takt zegara .... no to juz to sei na koncu jest hmmmm .... bardzo zlym pomysle gdyz wykonywane jest jeszcze przed prologiem przerwania ... przez co moze byc niezbyt bezpieczne w wielu sytuacjach.

No a to co kolega napisal .... ze w przerwaniach robi np wyswietlanie na lcd czy tez operacje delay ... i ze petla glowna while czasem sie nigdy nie wykona ....hmmmm no to juz jest straszne .... i naprawde warto sobie jeszcze mocno i sporo poczytac nie tylko o tym jak korzysta sie z przerwan bo taki sposob to hmmm troche wypaczenie ich istnienia w 99 % przypadkow .... to do tego warto jescze czytac o wielu innych technikach programowania w c.

bron boze nie pisze tego zlosliwie tylko przy okazji zwracam uwage na pewne aspekty i bledy w podejsciu do niektorych zagadnien .... no chyba ze cos zle zrozumialem ?

_________________
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 ]

To ze cli i sei jest z automatu to sprawa jawna. jednak wylaczanie poszczegolnych przerwan z rejestrow np. TIMSK w ISR juz nie. Ja z tego korzystam i jeszcze nie zauwazylem z tego powodu problemow. Wszystko wykonuje sie jak w zegarku, a robie to bo wkurza mnie tworzenie ciagle jakis zmiennych 8-bitowych na flage, z kolei zakladanie masek na poszczegolne bity to kolejne linijki tekstu (reka boli) . Inaczej sprawa by wygladala jak bym nadawal flagi w przerwaniach do whila tutaj juz nie masz pewnosci ze cos sie wykona dokladnie o czasie. Co do odswiezania LCD to sie zgodze ze to troche naciagane jest wsadzanie tego do ISR. Zdaje sobie sprawe, ze brakuje mi sporo wiedzy o przerwaniach i budowaniu zaleznosci czasowych, jednak do niektorych rzeczy mozna dojsc metoda prob i bledow. Wiele ludzi nawet do petli while(1) nie zaglada, ewentualnie usypia w niej proca. A przerwania sa po to aby z nich korzystac wedle zyczenia.
Przykladowo

ISR(PCINT0_vect) //pinchange interrupt
{
y=1;
PCMSK0 &= ~(1<<PCINT6); // INTERRUPT ON PIN PCINT6 DISABLE
}
zero problemow. raz sie interuptek zrobi i przez nastepne 60 sekund przykladowo spokoj
gdzie jest blad w takim zapisie? bo nadal nie rozumiem

Nigdzie nie ma błędu w takim zapisie bo o to właśnie chodzi

ja odniosłem się do tego - co wynikało z opisu - że piszesz np większy projekt i wszystko w przerwania wsadzasz.

Jeśli to jest jakiś mały projekcik - gdzie poza czymś takim albo i nawet ciut większym - nawet obsługa jakiegoś pilota (jak przedstawiłem to w Bluebooku) to czemu nie ? ... wtedy rzeczywiście pętla główna służy tylko jako narkoza

Ale już nieco większe projekty - to właśnie wykorzystanie takich mechanizmów - prostych w sumie i warto się z tym zapoznać - jak w Bluebooku w rozdziale

"Wstęp do systemów czasu rzeczywistego"

_________________
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 ]

Z checia zajrze w przyszlosci. Az tak utkwily mi w pamieci sprezynki z ADC i Joda Wprowadzenie elementu basniowego do zmudnych linii kodu.