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

AVR Studio i ATMega64 - problem przy wywołaniu procedury

danielbela 02 Cze 2007 02:10 2123 14
REKLAMA
  • #1 3944825
    danielbela
    Poziom 11  
    Posty: 31
    Witam mam następujący problem.
    Mam banalny program napisany w C w programie AVR Studio v4.13 dla procesora ATMega64 - moje pierwsze kroki z tym środowiskiem. I mam dosyć spory kłopot a mianowicie w kodzie:

    #include <avr/io.h>
    #include <util/delay.h>

    #define SET_DIODE PORTD|=0x10
    #define CLR_DIODE PORTD&=0xEF
    #define SET_BIP PORTC|=0x80
    #define CLR_BIP PORTC&=~0x80

    void bip(void)
    {
    SET_BIP;
    _delay_loop_2(100); <- w tym miejscu program się wysypuje
    CLR_BIP;
    }

    int main (void)
    {
    DDRD=0x10;
    DDRC=0x80;
    while(1)
    {
    _delay_loop_2(2000);
    SET_DIODE;
    bip(); <- wywołanie sprawiające problem
    _delay_loop_2(2000);
    CLR_DIODE;
    }
    return 1;
    }

    W momencie wywołania procedury bip() wszystko co jest dalej - a dokładnie już procedurze bip() - podczas obsługi funkcji opóźniającej program przerywa działanie i skacze na początek pętli while(1).
    Nie wiem co jest grane i dlaczego się tak dzieje - symulator pokazuje poprawne działanie programu.
    Próbowałem napisać samemu jakąś funkcję opóźniającą typu:
    void delay(int x)
    {
    do {
    asm("nop;");
    while (x--)
    }
    Od razu napiszę, że zauważyłem że jak zamiast wstawienia pętli opóźniającej wstawię pojedyncze asm("nop;"); to program działa poprawnie.
    Mam ustawioną optymalizację kodu na -O0 - chyba jest to brak optymalizacji, dlatego nie wiem co jeszcze może być nie tak.
    Boję się że jest to efekt przegrzania procka - był przelutowywany, a w poprzedniej konfiguracji odwrotnie zamontowany.
    Jeżeli ma ktoś pomysł co może być nie tak - w kodzie lub może trzeba jeszcze odpowiednio skonfigurować AVR Studio to prosiłbym o pomoc.

    ps. wie ktoś może jaki jest maksymalny poziom zagłębienia pętli?
    Z góry dziękuję za wszelką pomoc
  • REKLAMA
  • #2 3944978
    fantom
    Poziom 31  
    Posty: 1649
    Pomógł: 108
    Ocena: 41
    No i co ta twoja funkcja chodzi dobrze ? Jesli tak to zostaw swoja i nie zawracaj sobie glowy. Byc moze tamta funkcja potrzebuje jakis ustawien (nie wiem nie znam jej). I napewno nie jest to efekt przegrzania procka ;-).

    Apropos: wszyscy korzystaja z pliku avr/delay.h
  • REKLAMA
  • #3 3945179
    danielbela
    Poziom 11  
    Posty: 31
    Właśnie chodzi o to że tak samo nie działa poprawnie.
    A co do tego że wszyscy korzystają z avr/delay.h to AVR Studio podaje mi że jest to już nieaktualna wersja i żeby korzystać z #include <util/delay.h>

    Może jest to kwestia ustawień projektu w AVR Studio. Zauważyłem że są tam dwie możliwości - albo zewnętrzny plik Makefile albo wewnętrzne ustawienia programu.
  • #4 3945512
    zumek
    Poziom 39  
    Posty: 3352
    Pomógł: 695
    Ocena: 52
    danielbela napisał:
    ...Może jest to kwestia ustawień projektu w AVR Studio. Zauważyłem że są tam dwie możliwości - albo zewnętrzny plik Makefile albo wewnętrzne ustawienia programu.

    Ustawień powiadasz - też tak myślę ;)
    Uruchom symulator i zanim wykonasz 1-szy krok , wciśnij CTRL+O i popatrz czy na pewno symulator "symuluje" ATMega64 , a nie jakiś inny. To częsty błąd "nowicjuszy" :D

    Piotrek
  • REKLAMA
  • #5 3945573
    danielbela
    Poziom 11  
    Posty: 31
    Heh no nie, pisałem przecież wcześniej że mam ustawiony procek odpowiedni (chyba pisałem). A na poważnie to w ustawieniach mam zdefiniowany procesor ATMega64, częstotliwość 16MHz oraz brak minimalizacji -O0 (próbowałem z maksymalną na -Os ale efekt ten sam).

    ps. zaraz sprawdzę czy jak przestawię się na starą delay.h to coś zmieni.
    //zmienione

    Nic efekt bez zmian.
    Dokładnie postaram się opisać jaki jest efekt na uP: dioda cały czas świeci (brak migania) a brzęczyk piszczy z częstotliwością diody (jaka powinna być na diodzie czyli z cz. _delay_loop_2(2000) zamiast 100 jak powinno być.
    Próbowałem sprawdzić czy zmiana procka w ustawieniach na inny z rodziny ATMega64 coś zmieni ale nic to nie dało - program startował tylko dla podstawowej wersji ...64.

    //zmienione
    Co ciekawe, zauważyłem, że jak zmienię na:
    while(1)
    {
    _delay_loop_2(2000);
    SET_DIODE;
    _delay_loop_2(2000);
    CLR_DIODE;
    bip(); <- przeniosłem to wywołanie na koniec
    }
    return 1;

    To dioda poprawnie miga i głośniczek piszczy ale długość pisku jest niepoprawna - ma częstotliwość diody.
  • #6 3945701
    zumek
    Poziom 39  
    Posty: 3352
    Pomógł: 695
    Ocena: 52
    danielbela napisał:
    Heh no nie, pisałem przecież wcześniej że mam ustawiony procek odpowiedni (chyba pisałem)...

    Ale można mieć jakiśtam w kompilatorze , a inny w symulatorze ;)
    Jeśli masz taki sam w obu , to OK :)
    danielbela napisał:

    To dioda poprawnie miga i głośniczek piszczy ale długość pisku jest niepoprawna - ma częstotliwość diody.

    Tego pisku z bep() nie możesz usłyszeć - zbyt krótki :)

    Piotrek
  • #7 3945711
    danielbela
    Poziom 11  
    Posty: 31
    Tego pisku z bep() nie możesz usłyszeć - zbyt krótki <- właśnie chodzi o to że kiedy wchodzi do tej procedurki beep() to się wszystko kaszani. Zamiast tego delay(20-100) wchodzi to samo delay co przy diodzie i pislk słychać długi i nader wyraźny.
    Kiedy wrzucę zawartość procedury do main'a to wszystko jest ok, jednak nie da się napisać programu bez możliwości używania funkcji/procedur w których są pętle - a przynajmniej takie buraki u mnie wychodzą :(

    ps. Co do ustawień symulatora to mam poprawnie poustawiane.
  • #8 3945722
    zumek
    Poziom 39  
    Posty: 3352
    Pomógł: 695
    Ocena: 52
    Wiesz co :?: spakuj zip-em cały folder z projektem i wrzuć tu - popatrzymy :)

    Piotrek

    PS
    Napisz która wersja GCC
  • #9 3945771
    danielbela
    Poziom 11  
    Posty: 31
    Wrzuciłem całość do pliku.
    Wersja avr-gcc.exe - 4.1.1
    AVR Studio - 4.13.528
    GUI Version - 4, 13, 0, 528
    AVR Simulator - 1, 0, 2, 0
    ATMEGA64 - 223
    Załączniki:
    • program.rar (6.94 KB) Musisz być zalogowany, aby pobrać ten załącznik.
  • #10 3946206
    zumek
    Poziom 39  
    Posty: 3352
    Pomógł: 695
    Ocena: 52
    Ponieważ nie mam "na składzie" M64 , to opieram sie tylko na symulatorze:
    
    void bip(void)
    {
    	SET_BIP;
    	_delay_loop_2(20);
    	CLR_BIP;
    }
    
    int main (void)
    {
    	DDRD=0x10;
    	DDRC=0x80;
    	while(1) //pętla while wykonuje się w 16191 cykli = 1011.94 us
    	{
    		_delay_loop_2(2000); //8015 cykli = 500.94 us 
    ->		SET_DIODE;
    		_delay_loop_2(2000); //  j/w
    ->		CLR_DIODE;
    ->		bip(); //144 cykle = 9us
    ->	}
    	return 1;
    }
    

    w miejscach oznaczonych -> zatrzymuje sie kursor w czasie symulacji przy użyciu Step Over(F10).
    Moim zdaniem program kompiluje sie dobrze , tylko ... te opóźnienie zdecydowanie za krótkie :(

    Piotrek

    A co z fusebitem ATmega103 compatibility mode :?:
  • #11 3946266
    danielbela
    Poziom 11  
    Posty: 31
    dodałem nową funkcję procedurkę opóźniającą:
    void __delay(int x)
    {
    volatile int i=1;
    for (i=1; i<=x; i++)
    {
    _delay_loop_2(1000);
    }
    }
    jednak po takim zabiegu procek jest jakby martwy - 0 odpowiedzi.
    Zmieniłem w niej _delay_loop_2(1000) na _delay_loop_2(1) i tak samo żadnej odpowiedzi od układu.
    coraz bardziej wydaje mi się, że procek jest uwalony - chociaż do tego najlepiej było by to sprawdzić na innym egzamplarzu.
    ps. wyślij mi na maila jak możesz twojego HEX'a co wygenerowało Tobie AVR Studio - danielbela(_at_)interia.pl - odpalę i sprawdzę, bo może moja wersja jerst skaszaniona

    Dodano po 6 [minuty]:

    zauważyłem właśnie, że jak zmieniłem program, tj:
    void bip(void)
    {
    SET_BIP;
    _delay_ms(20);
    CLR_BIP;
    }

    int main (void)
    {
    DDRD=0x10;
    DDRC=0x80;
    while(1)
    {
    _delay_loop_2(60000);
    SET_DIODE;
    _delay_loop_2(60000);
    CLR_DIODE;
    // bip();
    }
    return 1;
    }
    To częstotliwość migania diodą jest taka sama jak dla delay 2000 - a aktualnie wynosi 60000.
    Kompletnie nie wiem co myśleć o tym, bo powoli przestaje mnie się to podobać :/
  • REKLAMA
  • #12 3946293
    zumek
    Poziom 39  
    Posty: 3352
    Pomógł: 695
    Ocena: 52
    Odpowiedz proszę , jak masz ustawione fusebity .

    Piotrek
  • #13 3946320
    danielbela
    Poziom 11  
    Posty: 31
    właśnie nie wiem :) tzn nie zmieniałem ustawień bo jeszcze nie wiem jak :P
    Najprawdopodobniej mam ustawiony procesor na zegar wewnętrzny 1MHz oraz preskaler 1/64 ale jeszcze nie wiem jak wyłączyć preskaler i zmienić na zegar zewnętrzny (mam generator zewn.).
  • Pomocny post
    #14 3946424
    zumek
    Poziom 39  
    Posty: 3352
    Pomógł: 695
    Ocena: 52
    danielbela napisał:
    właśnie nie wiem :)

    No to wszystko jasne ;) Twoja M64 , na razie "udaje" M103 i żaden program używający stosu , a skompilowany na M64 , chodził nie będzie.
    That's All :(

    Piotrek
  • #15 3946486
    danielbela
    Poziom 11  
    Posty: 31
    //zmienione i usunięte

    Dziękuję wszystkim za pomoc i topic zamykam

Podsumowanie tematu

✨ Problem dotyczy programu napisanego w C w AVR Studio 4.13 dla mikrokontrolera ATMega64, gdzie wywołanie funkcji bip() zawierającej opóźnienie _delay_loop_2 powoduje nieprawidłowe działanie programu – przeskok do początku pętli while(1) i brak oczekiwanego migania diody oraz prawidłowego działania brzęczyka. Użytkownik stosuje nagłówki , a także próbował , bez poprawy. Sprawdzono ustawienia projektu, w tym poprawny model procesora ATMega64, częstotliwość 16 MHz oraz optymalizację kompilatora (-O0 i -Os). Symulator jest skonfigurowany na ATMega64, jednak problem występuje zarówno w symulacji, jak i na rzeczywistym układzie. Próby modyfikacji funkcji opóźniającej i przenoszenia wywołania bip() w pętli nie przyniosły efektu. Podejrzewano błędne ustawienia fusebitów – prawdopodobnie mikrokontroler działa w trybie kompatybilności z ATMega103, co uniemożliwia poprawne działanie stosu i funkcji opóźniających. Użytkownik nie zmieniał fusebitów i nie jest pewien ich aktualnej konfiguracji, domyślnie mikrokontroler pracuje na wewnętrznym zegarze 1 MHz z preskalerem 1/64, mimo że w projekcie ustawiono 16 MHz i zewnętrzny generator. Wskazano, że problem wynika z niezgodności trybu pracy mikrokontrolera z kompilowanym kodem, co powoduje awarie podczas wywołania funkcji z pętlą opóźniającą. Po konsultacjach temat został zamknięty bez dalszych zmian.
Wygenerowane przez model językowy.
REKLAMA