Atmel AVR, problemy z EEPROM

Mar 11, 2007 14 Replies

Witam,



Zwracam siê z pro¶b± o zerkniêcie na mój sposób zapisu i odczytu danych do EEPROM na Atmel AVR ATmega. Generalnie nie mia³em problemów na ATmega 32 i 16. Ostatnio robi³em co¶ na ATmega 8 i po zapisaniu danych do EEPROM, wy³±czeniu zasilania i ponownym w³±czeniu, czêsto dane by³y inne. Dzi¶ pojawi³y mi siê rzadkie problemy podobnego rodzaju na ATmega 32. Nadmieniê, ¿e taktujê mikrokontrolery kwarcem ~18MHz. Co mo¿e byæ przyczyn± takich b³êdów? Z góry dziêkujê za pomoc.



Robot



Zapis do EEPROM:



/* aktualizacja EEPROMu */



while (!eeprom_is_ready()) ; ch = eeprom_read_byte((uint8_t *)((int)k * 3 + 2)); while (!eeprom_is_ready()) ; if (ch != c[k]._power) eeprom_write_byte((uint8_t *)((int)k * 3 + 2), c[k]._power);



while (!eeprom_is_ready()) ; ch = eeprom_read_byte((uint8_t *)((int)k * 3 + 1 + 2)); while (!eeprom_is_ready()) ; if (ch != c[k]._time) eeprom_write_byte((uint8_t *)((int)k * 3 + 1 + 2), c[k]._time);



while (!eeprom_is_ready()) ; ch = eeprom_read_byte((uint8_t *)((int)k * 3 + 2 + 2)); while (!eeprom_is_ready()) ; if (ch != c[k]._delay) eeprom_write_byte((uint8_t *)((int)k * 3 + 2 + 2), c[k]._delay);



while (!eeprom_is_ready()) ;


----------------------------------



Odczyt z EEPROM:



while (!eeprom_is_ready()) ; c[k]._power = eeprom_read_byte((uint8_t *)((int)k * 3 + 2)); while (!eeprom_is_ready()) ; if (c[k]._power > MAX_POWER) c[k]._power = MAX_POWER; else if (c[k]._power < 1) c[k]._power = 1;



while (!eeprom_is_ready()) ; c[k]._time = eeprom_read_byte((uint8_t *)((int)k * 3 + 1 + 2)); while (!eeprom_is_ready()) ; if (c[k]._time> MAX_TIMES) c[k]._time = MAX_TIMES; else if (c[k]._time < 1) c[k]._time = 1;



while (!eeprom_is_ready()) ; c[k]._delay = eeprom_read_byte((uint8_t *)((int)k * 3 + 2 + 2)); while (!eeprom_is_ready()) ; if (c[k]._delay > MAX_DELAY) c[k]._delay = MAX_DELAY;



while (!eeprom_is_ready()) ;



Witam.

Te¿ nie mia³em problemów za atmega 32 i 16 i zdziwi³em siê jak w³o¿y³em w to samo miejsce atmegê 644. Okaza³o siê ¿e trzeba ustawiæ fuse bity BODLEVEL.

Pozdrawiam Pawe³

W³±cz wew. BOD i ustaw poziom na 4V. Albo zastosuj zewnêtrzny uk³ad resetuj±cy np. DS1813.

Aha i nie rozumiem po co u¿ywasz tyle tych eeprom_is_ready skoro i tak w nieskoñczono¶æ oczekujesz a¿ bedzie gotowy? Przecie¿ w dokumentacji avr-gcc jest wyra¼nie napisane, ¿e:

"All of the read/write functions first make sure the EEPROM is ready to be accessed. Since this may cause long delays if a write operation is still pending, timecritical applications should first poll the EEPROM e. g. using eeprom_is_ready() before attempting any actual I/O"

Czyli wszystkie funkcjie zapisu i odczytu i tak najpierw sprawdzaj± czy eeprom jest gotowy, ale ¿e czekanie na gotowo¶æ eepromu mo¿e trwaæ stosunkowo d³ugo i procesor wtedy marnuje czas czekaj±c w pustej pêtli to "szybkie" aplikacje powinny w³a¶nie u¿ywaæ eeprom_is_ready, ale tylko po to ¿eby sprawdziæ czy jest zajêty i je¿eli jest to robiæ co¶ innego a za chwilê znowu sprawdziæ.

Pozdrawiam Pawe³

Bo pewnie miales cos skopanego gdzies indziej w kodzie.

Pierw nie wiedziales dlaczego nie dzialalo, a pozniej sprawiles, ze dzialalo -- tylko nie wiedziales dlaczego... :-) Tak sie nie robi!

m.

Robiê tak z powodu z³ych do¶wiadczeñ. Kiedy¶ zrobi³em uk³ad, który czêsto traci³ zapisane w EEPROM ustawienia. Dodanie tych while(!eeprom_is_read()); wszêdzie, gdzie siê da, rozwi±za³o problem :) Tylko dlaczego?

Robot

Ok, dziêkujê za odpowied¼. Czy oznacza to, ¿e takie problemy dziej± siê na skutek jakich¶ spadków napiêcia zasilania podczas zapisu do EEPROM? Mo¿e i to by by³o logiczne. Bo np. u mnie uk³ad dzia³a³, a u klienta, który podobno mia³ kiepskie zasilanie w zak³adzie (by³a robiona dla niego specjalnie maszyna z tego powodu) pojawia³y siê w³a¶nie problemy z utrat± danych z EEPROM.

Robot

U¿ytkownik "Martin Lukasik" snipped-for-privacy@milea.pl.i.hate.this.spam> napisa³ w wiadomo¶ci news:8911d$45f477e5$c1263429$ snipped-for-privacy@ZOO.CO.UK...

Mo¿e tak, mo¿e nie. Tylko dziwi mnie Twoja pewno¶æ, co do przyczyn problemu. Chêtnie zatrudniê takiego fachowca w mojej firmie :) Proszê o namiary.

Pozdrawiam Robot

Zdecydowanie przejrzalbym wszystko co sie da, zeby dojsc do tego, dlaczego zachowuje sie tak nie inaczej. Cos co dziala a nie wiem dlaczego... bardzo mnie to dreczy...

Przykro mi, nie jestem "do wziecia" ;-)

m.

Spinacz biurowy, Robot <Robot_nie_mam snipped-for-privacy@hotmail.com!

Nigdy nie przetaktowywałem mikrokontrolerów, ale może właśnie stąd są te problemy? PDFy zeznają jednoznacznie że fmax wynosi 16 MHz.

Spinacz biurowy, Robot <Robot_nie_mam snipped-for-privacy@hotmail.com!

Po jakimś czasie pracy w zawodzie pewne rzeczy się czuje :) To nie magia, tutaj nic nie ma prawa dziać się "nie wiadomo dlaczego" ani "bo tak". Jeżeli coś nie działa zgodnie z dokumentacją, to albo jest błąd w bibliotece, a ty masz niewiarygodne szczęście bycia pierwszą osobą spośród tysięcy innych, której przypadło w zaszczycie odkrycie tego błędu, albo (co dużo bardziej prawdopodobne) coś jest nie tak gdzieś indziej w twoim programie.

Sprowadzenie problemu do najprostszej, deterministycznej postaci najczęściej pomaga zorientować się, co i gdzie jest nie tak...

bywa równiez, ¿e dokumentacja jest niezgodna z faktyczn± realizacja w strukturze krzemu zamierzeñ producenta. Wtedy cz³owiek siê bije siê w piersi, ¿e nie zna sie na rzeczy, ¿e laik i niedoczyta³, a tu w rzeczywistosci uk³ad "zrypany" jest od poczatku przez producenta

AKel

AK <_akel snipped-for-privacy@alpha.net.pl> pisze:

Pamietam jak kumpel psioczyl chyba na at90s8535l. Chcial zaoszczedzic na RTC podpinajac kwarc zegarkowy i pedzac timer asynchronicznie. Bo przeciez "napisac RTC zajmie chwile". RTC dzialal i nagle stawal. Tydzien walczyl i zmiekl. Uzyl PCF8583. Jakis czas pozniej pokazalem mu errate, gdzie atmel przyznaje, ze ta seria moze miec problemy z asynchronicznym taktowaniem przy VCC<4V. Zalecaja VCC>4. Fantastycznie, to rozwiazuje problem tylko nie po to kupuje procek w wersji l zeby pedzic go wysokim napieciem :-)

Spinacz biurowy, AK <_akel snipped-for-privacy@alpha.net.pl>!

Bywa a) bardzo rzadko i b) jeżeli już bywa, to tysiące osób napotykają ten sam problem, przez co bardzo łatwo można wygooglać rozwiązanie.

Prawdopodobieństwo, że to mój program robi coś nie tak, jest niewiarygodnie większe niż że biblioteka robi coś nie tak (i nikt z tysięcy użytkowników tego nie zauważył).

Spinacz biurowy, Patryk Sielski snipped-for-privacy@elka-usun.pw.edu.pl>!

Zdarza się... Ale niepomiernie rzadziej niż błędy w sofcie.

Join the Discussion

Have something to add? Share your thoughts — no account required.

Didn't find your answer?

Ask the community — no account required