logo elektroda
logo elektroda
X
logo elektroda
Adblock/uBlockOrigin/AdGuard mogą powodować znikanie niektórych postów z powodu nowej reguły.

Attiny2313 - [C] Zmienne globalne - program nie przechodzi do funkcji main()

worf 18 Gru 2012 09:21 3168 25
  • #1 11667103
    worf
    Poziom 10  
    Witam,

    Mam problem ze zmiennymi globalnymi. Do momentu gdy kod wygląda jak poniżej, program działa poprawnie. Program w założeniu ma obsługiwać transmisje danych przez USART, natomiast wersja poniżej została skrócona do minimum w celu znalezienia przyczyn powstania błędu.

    Problem objawia się następująco:
    Jak tylko od komentuje "//volatile char flaga;" deklaracje zmiennej globalnej, program przestaje działać (A przynajmniej dioda nie mruga). Deklaracja "zwykłej" zmiennej w postaci "char flaga;" poza funkcją main() również wywołuje ten sam problem.

    Kod: C / C++
    Zaloguj się, aby zobaczyć kod


    Drugi problem:
    Gdy program z za komentowanymi zmiennymi globalnymi kompiluje w WinAVR 2010-01-20 (gcc ztcp 4.3.3 lub 4.3.4) program jak już pisałem działa. kompilacja pod Linuxem i gcc-avr 4.7.0 i program niestety przestaje działać.

    Co robię źle?

    pozdrawiam
  • #2 11667528
    tmf
    VIP Zasłużony dla elektroda
    gcc 4.7.0 to wersja eksperymentalna i stara, zdecydowanie nie powinieneś jej używać. W ogóle wersji 4.7 pod linuksem nie powinieneś używać, chyba, że znasz się na patchowaniu kompilatora i wiesz jakie patche trzeba zaaplikować dla AVR. Pod linuxa ściągnij toolchain z Atmela.
    Co do twojego błędu - pokaż raport z kompilacji, ilość użytej pamięci i opcje kompilacji.
  • #5 11669299
    worf
    Poziom 10  
    Niestety to nie pomogło. Sprawdziłem też na innym uC (aby wykluczyć, że może jest uszkodzony) i mam ten sam efekt. Podobnie jak na innych poziomach optymalizacji. Przy braku optymalizacji, jedyna zmiana to ostrzeżenie kompilatora, że funkcje z delay.h nie będą działać prawidło.
  • #7 11670865
    worf
    Poziom 10  
    Wersja w moim poprzednim załączniku, była skompilowana pod windowsem. Kompilacja pod linuxem, daje taki sam wynik jak załączony przez Ciebie, jednak niezależnie czy program (pod linuxem) kompilowany jest z za komentowaną/nie za komentowaną zmienna volatile, to niestety nie działa.

    Pytanie, czy u Ciebie na uC ten program działa poprawnie? Jako poprawne działanie mam na myśli, miganie diody led.

    Co do kwestii linuxa, to zgodnie z sugestią kolegi "tmf" nie chce się na tym koncentrować, jeżeli ta wersja może powodować problemy.

    Jako podsumowanie mogę napisać:
    - dodanie deklaracji zmiennej zaraz za plikami nagłówkowymi powoduje, że program nie działa (diodal led nie miga)
    - efekt występuje na 2 różnych uC, można więc wykluczyć uszkodzony układ
    - kompilator nie ostrzega o żądnych błędach
    - efekt występuje niezależnie od ustawionej flagi optymalizacji
    - usunięcie z pliku: "#include <stdlib.h>, #include <avr/interrupt.h>, #define UART_BAUD 19200, #define UART_CONST (F_CPU/(16ul*UART_BAUD)-1)" nie zmienia sytuacji, w dalszym ciągu po deklaracji zmiennej globalnej program nie działa.

    Będę wdzięczny za ew pomysły.

    pozdrawiam
  • #8 11670920
    sulfur
    Poziom 24  
    Na efekty będziesz musiał poczekać. Dzsiaj już nic nie zrobię, po za tym, że kompiluję najnowszą 4.7.2. Jutro po południu podłącze jakąś atmegę i zobaczę czy gada. Dam też znać co wyszło na nowej wersji kompilatora.
  • #9 11671016
    dondu
    Moderator na urlopie...
    worf napisał:
    Jako poprawne działanie mam na myśli, miganie diody led.

    Ale świeci, czy też nie? A może świeci słabo?

    Jak masz ustawione fusebity w stosunku do deklarowanych 4MHz?

    worf napisał:
    Będę wdzięczny za ew pomysły.

    Pokaż schemat.

    W załączniku plik Hex skompilowany z Twojego kodu - zaprogramuj nim i zobacz, czy zadziała.

    Cytat:
    rm -rf Proba_10.o Proba_10.elf dep/* Proba_10.hex Proba_10.eep Proba_10.lss Proba_10.map
    Build succeeded with 0 Warnings...
    avr-gcc -mmcu=attiny2313 -Wall -gdwarf-2 -std=gnu99 -Os -funsigned-char -funsigned-bitfields -fpack-struct -fshort-enums -MD -MP -MT Proba_10.o -MF dep/Proba_10.o.d -c ../Proba_10.c
    avr-gcc -mmcu=attiny2313 -Wl,-Map=Proba_10.map Proba_10.o -o Proba_10.elf
    avr-objcopy -O ihex -R .eeprom -R .fuse -R .lock -R .signature Proba_10.elf Proba_10.hex
    avr-objcopy -j .eeprom --set-section-flags=.eeprom="alloc,load" --change-section-lma .eeprom=0 --no-change-warnings -O ihex Proba_10.elf Proba_10.eep || exit 0
    avr-objdump -h -S Proba_10.elf > Proba_10.lss

    AVR Memory Usage
    ----------------
    Device: attiny2313

    Program: 118 bytes (5.8% Full)
    (.text + .data + .bootloader)

    Data: 1 bytes (0.8% Full)
    (.data + .bss + .noinit)


    Build succeeded with 0 Warnings...
  • #10 11671038
    sulfur
    Poziom 24  
    No ale z tego co wiem to wersja z WinAVR działa. Problem się zaczyna na nowszej wersji gcc na linuksie.
    btw dondu jaką masz wersję toolchaina ?

    Załączam wynik kompilacji z gcc 4.7.2. Różnica jest ale raczej symboliczna.
  • #11 11671055
    dondu
    Moderator na urlopie...
    Nie wykluczając oczywiście błędu kompilatora, to jest on jednak raczej mało prawdopodobny przy tak prostym programie. A znając różne przypadki Elektrodowych tematów, to jest za to spore prawdopodobieństwo, że przyczyna problemów leży w zupełnie innym miejscu :)
  • #12 11671065
    sulfur
    Poziom 24  
    No właśnie jeśli wierzyć autorowi i ma kod, który skompiluje i wgra do sprzętu i wszystko działa zgodnie z oczekiwaniami - a następnie wszystko powtórzy tylko zmieniając kompilator no to coś musi iść nie tak.
  • #14 11671332
    worf
    Poziom 10  
    Plik wystawiony przez dondu Próba_10: Wgrany i Działa :]
    Dwa pytania:
    - Jak wersja GCC?
    - Proszę tylko o potwierdzenie, że w pliku linia z deklaracją zmiennej globalnej była od komentowana.

    Plik załączony przez sulfur.
    Niestety nie działa - Dioda nie mruga, nie "żarzy" się itp.

    Co do samego układu.
    Został w tej chwili uproszczony do minimum:
    - Podłączone zasilanie,
    - Podłączona dioda Led przez rezystor do portu PD4 przez rezystor i to wszystko.

    Wiem, że w pliku nagłówkowym powinno być #define F_CPU 8000000UL (jest #define F_CPU 4000000UL) a nie mam podłączonego kwarcu, ale to też zmieniałem i nie wypływa to na niedziałanie układu.
    Dodatkowo dodanie dodatkowego "zapalenia diody led" (PORTD = _BV(PD4);) zaraz za linijkę "DDRD = _BV(PD4);" odpowiedzianą za ustawienie portu jako wyjście, przed pętlą for(), też nic nie zmienia.
    Zrobiłem to aby wykluczyć ew problemy z pętlą for()

    pozdrawiam
  • #15 11671352
    tos18
    Poziom 42  
    Definicja F_CPU jest potrzebna funkcji delay do obliczenia czasu opóźnienia i ma odpowiadać częstotliwość taktowania procesora w Hz. Avr Studio ma w właściwościach projektu pole wyboru gdzie można wpisać tą częstotliwość - wówczas definicja jest ignorowana.
  • #16 11671460
    worf
    Poziom 10  
    Wiem, jaki jest cel używania F_CPU, niestety poprawienie na 8000000UL gdy kwarc jest nie podłączony, w dalszym ciągu nie wpływa na działanie programu.

    Prośba do użytkownika dondu o informację z wersją toolchain.
    Bo widzę, że w sekcji ".data" moja zmienna jest zadeklarowana i jego binarka po wgraniu działa.

    pozdrawiam
    W
  • #17 11671770
    mirekk36
    Poziom 42  
    worf napisał:
    Wiem, jaki jest cel używania F_CPU, niestety poprawienie na 8000000UL gdy kwarc jest nie podłączony, w dalszym ciągu nie wpływa na działanie programu.


    No i bardzo dobrze - bo tak ma być i tak będzie - dokąd będziesz stosował w kodzie programu

    #define F_CPU xxxxxxx

    tak się tego NIGDY NIE robi, a jak chcesz żeby się skończyły twoje kłopoty z toolchainami, zmiennymi globalnymi i z tym wszystkim - to zobacz sobie to:

    http://mirekk36.blogspot.com/2012/11/instalka-eclipse-atmel-toolchain.html

    Ustawisz sobie taktowanie we właściwościach projektu - dołączysz toolchain jaki będziesz chciał i wszystko zacznie ci normalnie działać. Polecam to właśnie rozwiązanie, przynajmniej sprawdź ;) a później ocenisz sam.
  • #18 11672337
    szulat
    Poziom 23  
    różnice w generowanym kodzie najlepiej sprawdzać przez avr-objdump -d main.elf ale w sumie to bez znaczenia, wątek i tak trzeba zacząć od nowa zapominając o wszystkim co dotychczas napisano, bo przypadkiem mam akurat podłączony attiny2313 i po wgraniu hexa z worf_gcc470.zip okazuje się że działa (przełącza stan, ale co 4 sekundy zamiast co 1 bo fusow nie zmienialem)

    więc nie wiem co jest problemem na pewno nie jest to niedziałający kompilator

    worf_gcc472.zip był niepotrzebny bo hex identyczny jak ...470.zip

    mirekk36 napisał:

    #define F_CPU xxxxxxx

    tak się tego NIGDY NIE robi, a jak chcesz żeby się skończyły twoje kłopoty z toolchainami, zmiennymi globalnymi i z tym wszystkim - to zobacz sobie to

    to niewątpliwie dobra rada, zwłaszcza przy wieloplikowych projektach ale nie popadajmy w przesądy i voodoo, F_CPU jest zwykłą definicją preprocesora której nie można obwiniać o powodowanie problemów "z tym wszystkim" (a już na pewno nie ze zmiennymi globalnymi i działaniem kompilatora), jedyne na co może wpłynąć to aż dwa pliki .h (setbaud i delay) a w programikach składających się z jednego pliku ustawianie tej wartości na początku źródła jest równie dobre a nawet lepsze niż ustawianie w projekcie bo przynajmniej wklejając kod od razu wszyscy widzą co jest ustawione.
  • #19 11672451
    tmf
    VIP Zasłużony dla elektroda
    mirekk36 napisał:
    worf napisał:
    Wiem, jaki jest cel używania F_CPU, niestety poprawienie na 8000000UL gdy kwarc jest nie podłączony, w dalszym ciągu nie wpływa na działanie programu.


    No i bardzo dobrze - bo tak ma być i tak będzie - dokąd będziesz stosował w kodzie programu

    #define F_CPU xxxxxxx

    tak się tego NIGDY NIE robi, a jak chcesz żeby się skończyły twoje kłopoty z toolchainami, zmiennymi globalnymi i z tym wszystkim - to zobacz sobie to:

    http://mirekk36.blogspot.com/2012/11/instalka-eclipse-atmel-toolchain.html

    Ustawisz sobie taktowanie we właściwościach projektu - dołączysz toolchain jaki będziesz chciał i wszystko zacznie ci normalnie działać. Polecam to właśnie rozwiązanie, przynajmniej sprawdź ;) a później ocenisz sam.


    Znam twoją niechęć do Atmel Studio, ale popadasz w przesadę. Eclipse to tylko IDE, jak ma rozwiązać kłopoty z toolchainem? Tak samo Eclipse, jak i Atmel Studio wywołjują zewnętrzne narzędzia, w dodatku te same, do kompilacji projektu.
    W obu środowiskach można definiować symbole w tym F_CPU, w dodatku robi się to całkiem podobnie. I jakkolwiek z różnych powodów warto F_CPU definiować w makefile to nie zawsze trzeba. Akurat jeśli mamy jeden prosty plik, to wystarczy F_CPU zdefiniować przez zainkludowaniem <delay.h> i po kłopocie. A my dzięki temu wiemy, że jest zdefiniowane.
  • #20 11672686
    mirekk36
    Poziom 42  
    szulat napisał:
    a w programikach składających się z jednego pliku ustawianie tej wartości na początku źródła jest równie dobre a nawet lepsze niż ustawianie w projekcie bo przynajmniej wklejając kod od razu wszyscy widzą co jest ustawione.


    Tak hmm w projektach jedno-plikowych - to może od razu przejść na Bascoma - tam w ogóle nie ma projektów wielo-plikowych i wszystko jest jaśniejsze i każdy widzi co jest ustawione. Abo w ogóle wrócić do NOTEPAD.EXE ... i ręcznego wywoływania narzędzi toolchaina ...

    I wcale nie zwalałem winy #define F_CPU na karb nie działania zmiennych globalnych .... jak ktoś się w tym wszystkim zaczyna dopiero poruszać, jest początkujący to warto naprowadzić go na jedno - proste rozwiązanie - a nie pokazywać jak to można sobie sprawdzać

    avr-objdump -d main.elf

    jak ktoś podstaw działania z tym wszystkim jeszcze nie zna. Zamiast więc dyskutować z moją poradą - postaraj się np takiej osobie opisać coś więcej na temat posługiwania się

    avr-objdump -d main.elf

    a nie rzucać tylko hasło .... tak będzie lepiej.
  • #21 11672787
    szulat
    Poziom 23  
    mirekk36 napisał:
    Tak hmm w projektach jedno-plikowych - to może od razu przejść na Bascoma - tam w ogóle nie ma projektów wielo-plikowych
    no to czekam na propozycje na jakie pliki WARTO podzielić program migający ledem który cały ma 20 linijek ;)

    mirekk36 napisał:
    I wcale nie zwalałem winy #define F_CPU
    a ja wcale nie mówiłem że twoja rada jest całkiem zła, bo ogólnie jest dobra - tylko że nie pomaga w rozwiązaniu tego konkretnego problemu, a może i przeszkadza bo niepotrzebnie skupia uwagę na rzeczach nieistotnych

    mirekk36 napisał:
    Zamiast więc dyskutować z moją poradą - postaraj się np takiej osobie opisać coś więcej na temat posługiwania się

    avr-objdump -d main.elf

    posługiwanie sie jest proste - wywołujemy avr-objdump -d main.elf i patrzymy co wychodzi :D i gdyby jeden kompilator robił zły kod a drugi dobry to od razu widać różnicę i można to jednoznacznie stwierdzić zamiast kombinować i zgadywać, u kogoś działa u kogoś nie działa, a może źle podłączone, a może się źle wgrał wsad - w przypadku pliku nie ma takich wątpliwości.
  • #22 11672828
    mirekk36
    Poziom 42  
    szulat napisał:
    mirekk36 napisał:
    Tak hmm w projektach jedno-plikowych - to może od razu przejść na Bascoma - tam w ogóle nie ma projektów wielo-plikowych
    no to czekam na propozycje na jakie pliki WARTO podzielić program migający ledem który cały ma 20 linijek ;)

    Może mnie źle zrozumiałeś, ja po prostu jestem zdania (mogę chyba mieć własne? ale szanuję też twoje), że NIGDY nie trzeba używać tego #define F_CPU skoro jest ono albo generowane przez porządne środowisko programistyczne - np ECLIPSE - automatycznie albo jakby się ktoś uparł to i samemu w makefile można wrzucić. Po co się męczyć i mieszać w głowie początkującemu - przecież nie zatrzyma się na miganiu diodą jak go wciągnie ;)

    szulat napisał:
    mirekk36 napisał:
    I wcale nie zwalałem winy #define F_CPU
    a ja wcale nie mówiłem że twoja rada jest całkiem zła, bo ogólnie jest dobra - tylko że nie pomaga w rozwiązaniu tego konkretnego problemu, a może i przeszkadza bo niepotrzebnie skupia uwagę na rzeczach nieistotnych

    Wg ciebie może skupia na rzeczach nieistotnych - ale zwykle w takich przypadkach problemy się właśnie rozpoczynają i to poważne właśnie z działaniem wszelkich funkcji _delay_xx .... a jedno ciągnie drugie - bo masa błędów zwykle już całkiem jest słabo rozróżniana przez osobę startującą - więc ja mam tu inne zdanie - i wiem że ta podpowiedź często pomaga - a w ślad za nią idą inne - tylko ja wolę od początku i po kolei .... Ty możesz inaczej

    szulat napisał:
    avr-objdump -d main.elf

    posługiwanie sie jest proste - wywołujemy avr-objdump -d main.elf i patrzymy co wychodzi :D i gdyby jeden kompilator robił zły kod a drugi dobry to od razu widać różnicę i można to jednoznacznie stwierdzić zamiast kombinować i zgadywać, u kogoś działa u kogoś nie działa, a może źle podłączone, a może się źle wgrał wsad - w przypadku pliku nie ma takich wątpliwości.


    Skup się więc na tym i wyjaśnij więcej - co to znaczy że patrzymy co wychodzi - ty może to widzisz a dla początkującego to będzie sieczka i czarna magia ....

    Więc jeszcze raz powtórzę - zamiast skupiać się na tym kto lepiej podpowiada czy wprowadza w błąd idź swoją drogą pomagania - ja swoją - a osoba która pyta wybierze sama która porada bardziej do niego trafiła - OK ? Bo się tworzy niepotrzebny offtop.
  • #23 11672852
    szulat
    Poziom 23  
    mirekk36 napisał:
    Bo się tworzy niepotrzebny offtop.

    spoko, cały wątek jest gigantycznym offtopem bo problem w ogóle nie leży w kompilacji - na moim attiny przecież działa ten sam hex
  • #24 11673489
    worf
    Poziom 10  
    Problem rozwiązany!!!

    Dziękuję serdecznie wszystkim za pomoc.

    Źródło problemu:
    W pliku Makefile jako output FORMAT ustawiona byla stała binary.
    Następnie plik wrzucałem poleceniem:
    avrdude -p attiny2313 -P usb -c usbasp -U lfuse:w:0xc2:m -U hfuse:w:0xdf:m -U efuse:w:0xff:m -U flash:w:main.hex

    Zmiana w pliku Makefile output format na ihex, rozwiązała problem.

    Zakładam więc, ze albo ja źle uploaduje binarke do avr'a albo mój programator sobie z nią nie radzi!?

    pozdrawim
    W
  • #25 11674606
    szulat
    Poziom 23  
    worf napisał:
    Zakładam więc, ze albo ja źle uploaduje binarke do avr'a albo mój programator sobie z nią nie radzi!?

    to że sobie nie radzi to jeszcze można zrozumieć ale najlepsze że radzi sobie jak zakomentujesz zmienną! :D
    no ale format binarny to brak formatu, więc zależnie od treści programu może wyjść cokolwiek... jak avrdude interpretował ten plik który "nie działał"? masz log?
  • #26 11675212
    worf
    Poziom 10  
    Binary: (Z nie za komentowaną zmienna)
    avrdude: verifying ...
    avrdude: 1 bytes of efuse verified
    avrdude: reading input file "main.hex"
    avrdude: input file main.hex auto detected as raw binary
    avrdude: writing flash (18 bytes):
    Wsad do procka miał ~130bajtów

    Writing | ################################################## | 100% 0.02s

    Binary: (Z za komentowaną zmienna)
    avrdude: verifying ...
    avrdude: 1 bytes of efuse verified
    avrdude: reading input file "main.hex"
    avrdude: input file main.hex auto detected as raw binary
    avrdude: writing flash (110 bytes):

    Writing | ################################################## | 100% 0.05s

    Ihex (Z nie za komentowaną zmienna)
    avrdude: verifying ...
    avrdude: 1 bytes of efuse verified
    avrdude: reading input file "main.hex"
    avrdude: input file main.hex auto detected as Intel Hex
    avrdude: writing flash (134 bytes):

    Writing | ################################################## | 100% 0.06s

    iHex: (Z za komentowaną zmienna)

    avrdude: 110 bytes of flash written
    avrdude: verifying flash memory against main.hex:
    avrdude: load data flash data from input file main.hex:
    avrdude: input file main.hex auto detected as Intel Hex
    avrdude: input file main.hex contains 110 bytes
    avrdude: reading on-chip flash data:

    Reading | ################################################## | 100% 0.03

    Teraz, już łatwo zauważyć źródło problemu...
    Tym niemniej, przejrzę bugtracka i ew napiszę maila do developera avrdude, bo szkoda żeby ta wiedza uciekła.

    pozdrawiam
    W
REKLAMA