Elektroda.pl
Elektroda.pl
X
Elektroda.pl
Advanced Search

Search our partners

Find the latest content on electronic components. Datasheets.com
Datasheets
Elektroda.pl
Please add exception to AdBlock for elektroda.pl.
If you watch the ads, you support portal and users.

Zapisywanie i odczyt z eeprom i attiny2313.

20rafalo 30 Jun 2012 18:47 5217 51
Lock | New topic
  • #1
    20rafalo
    Level 19  
    Witam
    Przeglądałem forum, jednak zastosowane propozycje nie dały rezultatów.. ;/
    mam problem z zapisem i odczytem z pamięci eeprom.
    Jak mają wyglądać te instrukcje poprawnie??
    Robię tak(fragment kodu dot eeprom):
    Code: 

    int i=1;

    static EEMEM int i_ee;

    

    eeprom_write_block(&i, &i_ee, sizeof(i));

    eeprom_read_block(&i, &i_ee,sizeof(i));

    Robiłem wiele innych opcji ale ciągle wyskakuje błąd kompilatora... ;/
    Code: 

    make all 

    Building file: ../main.c

    Invoking: AVR Compiler

    avr-gcc -Wall -Os -fpack-struct -fshort-enums -std=gnu99 -funsigned-char -funsigned-bitfields -mmcu=attiny2313 -DF_CPU=1000000UL -MMD -MP -MF"main.d" -MT"main.d" -c -o"main.o" "../main.c"

    Finished building: ../main.c

     

    Building file: ../in avrstudio/ava.c

    Invoking: AVR Compiler

    avr-gcc -Wall -Os -fpack-struct -fshort-enums -std=gnu99 -funsigned-char -funsigned-bitfields -mmcu=attiny2313 -DF_CPU=1000000UL -MMD -MP -MF"in avrstudio/ava.d" -MT"in\ avrstudio/ava.d" -c -o"in avrstudio/ava.o" "../in avrstudio/ava.c"

    ../in avrstudio/ava.c:7:1: warning: "F_CPU" redefined

    <command-line>: warning: this is the location of the previous definition

    ../in avrstudio/ava.c: In function 'zapisz':

    ../in avrstudio/ava.c:77: warning: passing argument 1 of '__eewr_byte_tn2313' from incompatible pointer type

    ../in avrstudio/ava.c: In function 'odczytaj':

    ../in avrstudio/ava.c:82: warning: passing argument 1 of '__eerd_byte_tn2313' from incompatible pointer type

    ../in avrstudio/ava.c:82: error: too many arguments to function '__eerd_byte_tn2313'

    ../in avrstudio/ava.c:82: warning: statement with no effect

    make: *** [in avrstudio/ava.o] Error 1

    Co jest źle i jak poprawić?
    pzdr
  • #3
    mirekk36
    Level 42  
    Takich "podpowiedzi" ostatnio pełno na forum więc postaram ci się pomóc.

    Po pierwsze - popełniasz błąd bo definiujesz gdzieś w programie

    #define F_CPU

    a już jest ono w makefile wstawione pewnie przez środowisko więc niepotrzebnie to robisz albo sam zdefiniowałeś to kilka razy

    poza tym nie pokazałeś całego kodu a błędy które ujawniłeś wcale nie dotyczą tylko tego małego fragmentu, który przedstawiłeś

    Wklej więc większą część kodu albo całość to uda się coś bardziej precyzyjnie podpowiedzieć - gdzie robisz błędy.
  • #4
    alagner
    Level 26  
    Spróbuj zrzutować wskaźniki na void.
  • #5
    20rafalo
    Level 19  
    mirekk36 wrote:
    Po pierwsze - popełniasz błąd bo definiujesz gdzieś w programie

    #define F_CPU

    a już jest ono w makefile wstawione pewnie przez środowisko więc niepotrzebnie to robisz albo sam zdefiniowałeś to kilka razy

    w eclipse nie trzeba dawać tej linijki i dlatego. Ale w AVRStudio trzeba. Kod wklejony z eclipse.
    To ostrzeżenie nie robi problemu.
    To mnie zastanawia: "error: too many arguments to function '__eerd_byte_tn2313' "
    Jutro wkleję kod. Dodam, że bez linijek związanych z eeprom (wklejone poprzednio) program działa.
    Ale potrzebuje dostępu do eeprom ;/
  • #6
    drzasiek
    CNC specialists  
    20rafalo wrote:
    Ale w AVRStudio trzeba.

    Kto powiedział, że trzeba?
    Można ,ale nie jest zalecane i na pewno nie trzeba.
    Jakie AVR Studio używasz?
  • #7
    gaskoin
    Level 38  
    A co ma IDE do preprocesora ?

    Zarówno W AVRS jak i w Eclipsem jak i w notatniku można dodać parametr -D do wywołania kompilatora a można też dać sobie #define.

    Zaleca się jednak dodać stałą globalną -DF_CPU=8923642945UL
  • #8
    20rafalo
    Level 19  
    drzasiek wrote:
    20rafalo wrote:
    Ale w AVRStudio trzeba.

    Kto powiedział, że trzeba?
    Można ,ale nie jest zalecane i na pewno nie trzeba.
    Jakie AVR Studio używasz?

    Panowie nie rozdzielajmy włosa na czworo...
    Może takie przejęzyczenie- można, trzeba, powinno się.. - pomińmy to.
    Problemem jest zapisanie do eeprom...
    zaraz dam kod...
  • #9
    drzasiek
    CNC specialists  
    20rafalo -> nie chodzi o przejęzyczenie. Po prostu napisałeś że w Eclipse nie trzeba a w AVR Studio trzeba. A to jest tak, że ani w jednym ani w drugim nie trzeba a nawet nie powinno się. To było tylko sprostowanie. Czekamy na kod.
  • #10
    20rafalo
    Level 19  
    dondu coś o tym wiem ;P -kiedyś też tylko definiowałem, a tak naprawdę fusebity to ustawiają.
    Jest to trochę mylące (ustawianie za pomocą #define), ale jak na razie nie skupiam się nad częstotliwością pracy..
    Panowie często mnie się zdarzało tak: program nie działa choć powinien, po resecie+ nowy projekt oraz skopiowaniu kodu działa- i tym razem tak jest.
    Uszczupliłem kod do minimum, tak, aby zająć się tylko problemem zapisu i odczytu z pamięci eeprom
    Kod:
    Code: c
    Log in, to see the code


    Panowie chciałem aby zmienna "i" została zapisywana do pamięci i potem z niej odczytywana.
    Problem- odcinanie zasilania uC - które jest założeniem w projekcie.
    Po załączeniu zasilania- zliczanie powinno zacząć się od poprzedniej wartości.
    if (we_on) - załącza się po ponownym dostaniu napięcia przez uC.

    (Dalej mam warunki wykrycia stanu "0" , tak aby pętla nie zliczała non stop - nie zamieszczałem.)

    Ilość cykli nie będzie duża- maks 50tyś przez cały okres przydatności układu. Także te kwestie pomińmy ;P
    PS fajnie jak by podtrzymać zasilanie na uC przez chwile - do wykonania się pętli wykrywającej "0" - jakie kondensatory polecacie?
    Z góry dzięki ;)
  • #11
    dondu
    Moderator on vacation ...  
    20rafalo wrote:
    dondu coś o tym wiem ;P -kiedyś też tylko definiowałem, a tak naprawdę fusebity to ustawiają.
    Jes to trochę mylące (ustawianie za pomocą #define), ...

    Nie obraź się, ale fusebity to jedno, a F_CPU to drugie :)
    Z tej wypowiedzi wynika, że nie znasz różnicy, a to bardzo istotne tym bardziej, że używasz delay().

    Wklejając kod wyskoczyło Ci czerwone ostrzeżenie - czemu do niego się nie zastosowałeś?
    Później w trakcie wysyłania posta wyskoczył pop-up - także zignorowałeś.
  • #13
    mirekk36
    Level 42  
    LordBlick wrote:
    pinieważ ani I ani i_ee nie są tablicami, tylko zmiennymi 16-bit, powinieneś użyć eeprom_read_word/eeprom_write_word

    Tak byłoby logiczniej ale nie oznacza to chyba, że zapis typu:

    Code: c
    Log in, to see the code


    jest błędny w tym przypadku i nie zadziała. Bo zadziała i odniesie taki sam skutek. Zapis bloku wcale przecież nie musi się odnosić do tablic a z drugiej strony to nawet zmienna typu uint8_t jest tablicą jakby nie patrzeć, tyle że jednoelementową biorąc pod uwagę że przekażemy jej adres z operatorem &.
  • #14
    20rafalo
    Level 19  
    dondu wrote:
    Z tej wypowiedzi wynika, że nie znasz różnicy, a to bardzo istotne tym bardziej, że używasz delay()

    Za ich pomocą można ustawiać bez problemu - zresztą niech inni Ci powiedzą...
    I z tym jak na razie nie mam problemu. Kiedyś jak ustawiałem programowo to były..
    Sprawdź sobie w AVRStudio...

    dondu wrote:
    Wklejając kod wyskoczyło Ci czerwone ostrzeżenie - czemu do niego się nie zastosowałeś?

    Później w trakcie wysyłania posta wyskoczył pop-up - także zignorowałeś.

    teraz to już cie nie rozumiem. Jak to zignorowałem??
    Kod był napisany poprawnie składniowo i błąd wyświetlony przez kompilator był fałszywy.
    Wystarczyło uruchomić od nowa całe środowisko i się kompiluje bez problemu. Wrzuć sobie i skompiluj jak nie wierzysz... zresztą...
    Pisałem o tym wcześniej!
    mirekk36 czyli jest ok... W takim razie teraz zapisze i odczyta zmienną "i" w takich warunkach jak pisałem poprzednio?
  • #16
    dondu
    Moderator on vacation ...  
    Po pierwsze nie denerwuj się, gdyż prosiłem na wstępie, byś się czasem nie obraził, co dodatkowo wytłuściłem.
    Dodam, że nie chcę Ci wytykać czegokolwiek, tylko pomóc.

    20rafalo wrote:
    dondu wrote:
    Z tej wypowiedzi wynika, że nie znasz różnicy, a to bardzo istotne tym bardziej, że używasz delay()

    Za ich pomocą można ustawiać bez problemu - zresztą niech inni Ci powiedzą...
    I z tym jak na razie nie mam problemu. Kiedyś jak ustawiałem programowo to były..

    Po drugie z Twoich wypowiedzi nie wynika, że rozumiesz różnicę między ustawianiem zegara fusebitami, a za pomocą F_CPU. I tylko na to zwracam Ci uwagę, byś w tym zakresie wiedzę poszerzył, bo nie ja będę czas tracił, tylko Ty :)


    20rafalo wrote:
    dondu wrote:
    Wklejając kod wyskoczyło Ci czerwone ostrzeżenie - czemu do niego się nie zastosowałeś?
    Później w trakcie wysyłania posta wyskoczył pop-up - także zignorowałeś.

    teraz to już cie nie rozumiem. Jak to zignorowałem?? ....

    Przepraszam, nie napisałem dokładnie ale nie ma to już znaczenia.
  • #17
    snnaap
    Level 25  
    Mam takie pytanie wynikające z mojej ciekawości świata, czy osoby które wypowiadają się łamach tego wątku zawsze korzystając z biblioteki eeprom.h przy dostępie do pamięci eeprom uK / czy może kiedyś nie skorzystał z biblioteki i wykonały tę operację odwołując się bezpośrednio do EEDR, EECR i EEAR?
  • #19
    LordBlick
    VIP Meritorious for electroda.pl  
    snnaap wrote:
    czy osoby które wypowiadają się łamach tego wątku zawsze korzystając z biblioteki eeprom.h przy dostępie do pamięci eeprom uK / czy może kiedyś nie skorzystał z biblioteki i wykonały tę operację odwołując się bezpośrednio do EEDR, EECR i EEAR
    Jeśli o mnie chodzi, operuję na rejestrach w asm, ale znajomość bibliotek avr-libc niczemu nie wadzi.
    http://www.nongnu.org/avr-libc/user-manual/group__avr__eeprom.html
  • #20
    20rafalo
    Level 19  
    dondu wrote:
    Dodam, że nie chcę Ci wytykać czegokolwiek, tylko pomóc.

    To dobrze ;)
    Panowie prosił bym, aby nie odbiegać od tematu, tylko zająć się eeprom -zapis i odczyt.
    Gdyż na tak małym fragmencie kodu schodzi mi już drugi dzien na forum ;/
    Z góry dzięki.
    Zadziała to co wcześniej napisałem??
    pzdr

    Dodano po 3 [minuty]:

    mirekk36 wrote:
    pomyśl o tych funkcjach o których wspomniał LordBlick: eeprom_read_word/eeprom_write_word

    Niestety- zmieniając na "word" - wyświetla się błąd kompilacji.
    Code: 
    error: too many arguments to function '__eerd_word_tn2313'
  • #21
    LordBlick
    VIP Meritorious for electroda.pl  
    20rafalo wrote:
    Niestety- zmieniając na "word" - wyświetla się błąd kompilacji.
    Nawet nie zajrzałeś do opisu biblioteki. "Too many arguments" - za wiele argumentów(Google Translate też pomaga... ;) ). Wywal size.
    Link do opisu biblioteki podałem wcześniej.
  • #22
    20rafalo
    Level 19  
    LordBlick wrote:
    "Too many arguments"

    angielski na tyle znam, że nie potrzebowałem translatora na to wyrażenie, jednak fakt, nie znam opisu tej biblioteki ;/
    Jeszcze jedno - jak zostawiłem "block" program się kompiluje i niby jest ok. W symulatorze
    Code: 
    eeprom_write_block(&i, &i_ee, sizeof(i));
    ta linia zapisuje do pamięci, jednak jak program wróci do początku i chce odczytać
    Code: 
    eeprom_read_block(&i, &i_ee,sizeof(i));
    to odczytuje wartość inną, początkową "i=1", a nie np 2 w drugim obiegu itd ;/

    Dodano po 18 [minuty]:

    o i są błędy...

    Code: c
    Log in, to see the code


    Quote:
    **** Build of configuration Release for project testowy ****

    make all
    Building file: ../main.c
    Invoking: AVR Compiler
    avr-gcc -Wall -Os -fpack-struct -fshort-enums -std=gnu99 -funsigned-char -funsigned-bitfields -mmcu=attiny2313 -DF_CPU=1000000UL -MMD -MP -MF"main.d" -MT"main.d" -c -o"main.o" "../main.c"
    ../main.c: In function 'main':
    ../main.c:32: warning: pointer targets in passing argument 1 of '__eerd_word_tn2313' differ in signedness
    ../main.c:32: error: too many arguments to function '__eerd_word_tn2313'
    ../main.c:32: warning: statement with no effect
    ../main.c:38: warning: pointer targets in passing argument 1 of '__eewr_word_tn2313' differ in signedness
    ../main.c:38: warning: passing argument 2 of '__eewr_word_tn2313' makes integer from pointer without a cast
    make: *** [main.o] Error 1


    Dodano po 4 [minuty]:

    Dodano po 9 [minuty]:

    Trochę posiedziałem i zrobiłem tak:

    Code: c
    Log in, to see the code

    Nie ma błędów, jednak podczas symulacji jest ten sam problem.
    Macie jakieś pomysły?
  • #23
    snnaap
    Level 25  
    Dla programu przedstawionego przez autora tego wątku chyba jednak prościej, mniej kłopotliwie i bardziej energooszczędnie byłoby użycie najprostszych procedur proponowanych (o dziwno!!) przez producenta uK np:


    Code: c
    Log in, to see the code


    itd

    A jakie korzyści z nauki czytania not by z tego doszły.

    Pozdrawiam
  • #25
    LordBlick
    VIP Meritorious for electroda.pl  
    Dorzucę jeszcze jednego hinta - nazwa tablicy jest sama w sobie wskaźnikiem na pierwszy element. Sprawdź:
    Code: C
    Log in, to see the code
    P.S. : Na forum używaj syntax = C, taki kod jest czytelniejszy.
    Edit: Poprawiłem, zgodnie z sugestiami niżej.
  • #26
    mirekk36
    Level 42  
    snnaap wrote:
    Dla programu przedstawionego przez autora tego wątku chyba jednak prościej, mniej kłopotliwie i bardziej energooszczędnie byłoby użycie najprostszych procedur proponowanych (o dziwno!!) przez producenta uK np:


    Code: c
    Log in, to see the code


    itd

    A jakie korzyści z nauki czytania not by z tego doszły.

    Pozdrawiam


    No ja bym się z tym mocno nie zgodził, dlatego, że funckje przygotowane w AVR GCC działają niezawodnie i zawsze - dzięki czemu nie ma miejsca na pomyłkę. Poza tym i tak nie warto zapisywać do EEPROM pojedynczych zmiennych a zebrać je po prostu w jakąś dużą strukturę i wtedy całą tę strukturę zapisywać / odczytywać jako blok.

    Dodano po 1 [minuty]:

    LordBlick wrote:
    Dorzucę jeszcze jednego hinta - nazwa zmiennej jest sama w sobie wskaźnikiem.


    Czy koledze może się coś nie pomyliło tutaj? Sama nazwa tablicy jest wskaźnikiem na jej pierwszy element ale już nazwa zmiennej na pewno nie jest wskaźnikiem i dlatego trzeba się wtedy posłużyć operatorem pobierania adresu &
  • #27
    snnaap
    Level 25  
    mirekk36 wrote:


    No ja bym się z tym mocno nie zgodził, dlatego, że funckje przygotowane w AVR GCC działają niezawodnie i zawsze - dzięki czemu nie ma miejsca na pomyłkę. Poza tym i tak nie warto zapisywać do EEPROM pojedynczych zmiennych a zebrać je po prostu w jakąś dużą strukturę i wtedy całą tę strukturę zapisywać / odczytywać jako blok.



    Łatwo się ich używa jak jakoś wie jak z nich korzystać i jak wywołać dana funkcję/procedurę. Jak widać na przykładzie tego wątku nie wszyscy mają taką wiedzę. A niewiedz ta prowadzi do właśnie do pomyłek i późniejszego szukania przez 5 dni gdzie leżał błąd.

    Drugi problem to taki że użycie gotowej biblioteki to pójście na łatwiznę, używający nawet nie zastanawia się co siedzi w środku takiej biblioteki i jak naprawę ona działa a później pojawiaj się dziwne błędy wynikające z jej nieprawidłowego użycia.

    Akurat Ty powinieneś wiedzieć sporo na ten temat, bo jak zdążyłem zauważyć sam piszesz niektóre biblioteki i nie korzystasz z bibliotek innych a czemu? Bo wtedy najlepiej wiadomo jak dana biblioteka wygląda, co zawiera, jakie ma mocne strony a jakie ograniczenia, czy może się mylę?
  • #28
    mirekk36
    Level 42  
    snnaap wrote:

    Akurat Ty powinieneś wiedzieć sporo na ten temat, bo jak zdążyłem zauważyć sam piszesz niektóre biblioteki i nie korzystasz z bibliotek innych a czemu? Bo wtedy najlepiej wiadomo jak dana biblioteka wygląda, co zawiera, jakie ma mocne strony a jakie ograniczenia, czy może się mylę?


    Tzn ja mam takie podejście, że jeśli coś jest gotowego w AVR GCC to z tego korzystam - bo pisanie często własnych funkcji tego typu może być mniej opłacalne (czytaj optymalne) ....

    Poza tym jak nie wiadomo o co chodzi w tych funkcjach - no toż ta do blokowego zapisu jest prosta jak drut:

    tworzymy sobie jakąś piękną strukturę ze zmiennymi, które mają być w eeprom. Ale skorzystajmy ze zdefiniowania typu:

    Code: c
    Log in, to see the code


    potem definiujemy sobie pięknie np dwie zmienne:

    Code: c
    Log in, to see the code


    no i potem proszę bardzo chcesz wpisać dane z RAM do EEPROM, żeby zapamiętać ustawienia użytkownika gdzieś w programie? to proszę

    Code: c
    Log in, to see the code


    podobnie z odczytem.

    A jak potrzebuję dodać jakąś zmienną ??? odjąć ? co za problem wystarczy dodać struktury albo wyjąć ze struktury. Czy to nie jest wygodniejsze niż babranie się co chwilę w kodzie z definiowaniem oddzielnych gdzieś zmiennych ? korzystajmy ze struktur i korzystajmy z tego co daje nam AVR GCC - o to mi chodzi. Ale jeśli ktoś zechce robić coś na niskopoziomowych funkcjach i bawić się w oczekiwania to w zasadzie można byłoby powrócić nawet do asemblera. Wtedy to już na pewno będzie każdy wiedział od podszewki co i jak się robi.

    Troszkę więc nieuprawnione chyba jest stwierdzenie, że korzystanie z funkcji dostępnych w kompilatorze jest pójściem na łatwiznę - nieprawdaż ?
  • #30
    snnaap
    Level 25  
    mirekk36 wrote:

    Troszkę więc nieuprawnione chyba jest stwierdzenie, że korzystanie z funkcji dostępnych w kompilatorze jest pójściem na łatwiznę - nieprawdaż ?


    Chłopcze, czepiasz się słówek.

    Mi nie musisz tłumaczyć co i jak, jestem na tyle rozgarnięty że łapie to - chodź może Ty uważasz inaczej.

    Jeżeli ktoś potrzebuje pomocy z takim tematem to uważam że jest początkującym, a jak ktoś jest początkujący to niech zacznie od początku od prostych rzeczy nie uważasz?

    A co do przykładu kolegi to nie ma w nim mowy o strukturach a jedynie o prostej zmiennej typu int.
    Więc wywód o strukturach w tym wątku może lekko namieszać koledze.
Lock | New topic