Nieprawidłowy zapis i odczyt danych w EEPROM na ATmega 8 i 32 z kwarcem 18MHz

Sun Mar 11, 2007 6:56 pm   

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())
;

Sun Mar 11, 2007 7:59 pm   

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ł

Sun Mar 11, 2007 8:10 pm   

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ł

Sun Mar 11, 2007 10:38 pm   

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.


--
Marcin Lukasik, marcin na milea kropka pl
http://milea.pl -- sieci bezprzewodowe

``Be who you are and say what you feel, because those who mind don't matter
and those who matter don't mind.''

Sun Mar 11, 2007 10:41 pm   

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

Sun Mar 11, 2007 11:24 pm   

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

Sun Mar 11, 2007 11:25 pm   

Użytkownik "Martin Lukasik" <marcin@milea.pl.i.hate.this.spam> napisał w
wiadomości news:8911d$45f477e5$c1263429$10214@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

Mon Mar 12, 2007 11:00 am   

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.


--
Marcin Lukasik, marcin na milea kropka pl
http://milea.pl -- sieci bezprzewodowe

``Be who you are and say what you feel, because those who mind don't matter
and those who matter don't mind.''

Tue Mar 13, 2007 4:40 am   

Spinacz biurowy, Robot <Robot_nie_mam_maila@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...

--
Adam Wysocki * Warszawa * http://www.chmurka.net/ * GSM: 514 710 213
FidoNet: 2:480/138, SWL: SP5-250730, QTH: KO02MF, CB: 19 Śródmieście
Jakbym chciał, to bym coś mądrego napisał (C) LampA @ p.c.networking
-> Zostało zaledwie 1380 dni do końca kadencji Lecha Kaczyńskiego <-

Tue Mar 13, 2007 4:40 am   

Spinacz biurowy, Robot <Robot_nie_mam_maila@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.

--
Adam Wysocki * Warszawa * http://www.chmurka.net/ * GSM: 514 710 213
FidoNet: 2:480/138, SWL: SP5-250730, QTH: KO02MF, CB: 19 Śródmieście
gophi, wyglądasz trochę gangsta... (C) Cyberdude @ GG 29 lutego 2004
-> Zostało zaledwie 1380 dni do końca kadencji Lecha Kaczyńskiego <-

Tue Mar 13, 2007 10:38 am   

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

Tue Mar 13, 2007 11:37 am   

AK <_akel_@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 :-)


--
Pozdrawiam,
Patryk Sielski
http://www.usprawnienia.pl

Tue Mar 13, 2007 8:41 pm   

Spinacz biurowy, Patryk Sielski <psielski-usun@elka-usun.pw.edu.pl>!


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

--
Adam Wysocki * Warszawa * http://www.chmurka.net/ * GSM: 514 710 213
FidoNet: 2:480/138, SWL: SP5-250730, QTH: KO02MF, CB: 19 Śródmieście
Gophi ma bogaty wybór odchyłów od przeciętności (C) Keyop @ aph 2003
-> Zostało zaledwie 1380 dni do końca kadencji Lecha Kaczyńskiego <-

Tue Mar 13, 2007 8:41 pm   

Spinacz biurowy, AK <_akel_@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ł).

--
Adam Wysocki * Warszawa * http://www.chmurka.net/ * GSM: 514 710 213
FidoNet: 2:480/138, SWL: SP5-250730, QTH: KO02MF, CB: 19 Śródmieście
Netykieta mą domeną a kultura cnotą. hell.pl/kya/turbonetykieta.html
-> Zostało zaledwie 1380 dni do końca kadencji Lecha Kaczyńskiego <-