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

[ATtiny2313 AVR-gcc] ATtiny2313 AVR-gcc: Przerwania nie zmieniają stanu portu B, co poprawić?

owca2002 01 Wrz 2005 14:23 6864 20
REKLAMA
Zgłoś naruszenie prawa
Odpowiedz | Nowy temat
  • #1 1783492
    owca2002
    Poziom 11  
    Posty: 30
    Napisalem programik, ktory ma zmieniac stan wyjscia portu B co jakis czas (do portu B mam podlaczone diody). Problem polega na tym ze niestety chyba nie obsluguje mi tego przerwana :( moze cos zle pisze, a moze akurat w tym modelu jest jakis haczyk? Oto program

    Kod: text Rozwiń Zaznacz wszystko Kopiuj do schowka
    #include <avr/io.h>
#include <avr/signal.h>
#include <avr/interrupt.h>
	
char licznik;

SIGNAL (SIG_OVERFLOW0)
{
TCNT0 = 0xb2;
  if(--licznik==0)	
  {
  PORTB ^= 0xff;
  licznik=200;
  }
}
int main( void )
{
licznik=200;
  DDRB=0xff;   
  TCNT0 = 0xb2;
  TCCR0B=5;
  TIMSK = (1<<TOIE0);
  sei();
    
  while(1)
  {
   }
  return 0;
}


    wczesniej napisalem program ktory tylko czeka na pojawienie sie flagi przepelnienia timera0 i ten program dzialal :/

    Moderowany przez Light-I:

    Kod ujęto w tagi "code". Tytuł wątku zretuszowano.

  • REKLAMA
  • #3 1784087
    owca2002
    Poziom 11  
    Posty: 30
    niestety nic nie pomoglo :/

    z tego co widze to on nie wchodzi wcale do funkcji SIGNAL :(

    moze jakies inne propozycje??

    uzywam WinAvr'a, moze to przez to??
  • #4 1784272
    zumek
    Poziom 39  
    Posty: 3352
    Pomógł: 695
    Ocena: 52
    owca2002 napisał:

    ...
    uzywam WinAvr'a, moze to przez to??

    Nie , to przez to:
    Kod: text Rozwiń Zaznacz wszystko Kopiuj do schowka
    
//jest
SIGNAL (SIG_OVERFLOW0)
//ma być
SIGNAL (SIG_TIMER0_OVF)

    A kompilator Cię nie ostrzegał :?:

    Piotrek
  • #5 1784298
    owca2002
    Poziom 11  
    Posty: 30
    Wielkie dzieki :D

    bez tego nie moglem zrobic nic wiecej, a kompilator nic sie nie buntowal :( a jesli chodzi o moja ten "OVERFLOW" to taka wersje mam z ksiazki ://
  • REKLAMA
  • #6 1784357
    zumek
    Poziom 39  
    Posty: 3352
    Pomógł: 695
    Ocena: 52
    owca2002 napisał:

    ...
    bez tego nie moglem zrobic nic wiecej, a kompilator nic się nie buntowal :( a jesli chodzi o moja ten "OVERFLOW" to taka wersje mam z ksiazki ://

    Kompilator powinien "wywalić"(pewnie nie zauważyłeś) ostrzeżenie 'SIG_OVERFLOW0' appears to be a misspelled signal handler "błędnie wpisana nazwa sygnału przerwania" .Ten wpisany przez Ciebie , dotyczy 90S2313 , a w ATTiny już inaczej się nazywa.Zwasze warto zapoznać się z plikiem "ioXXX.h" dla proca , który chcemy oprogramować , bo i nazwy rejestrów I/O , też się zmieniają;)

    Piotrek
  • #7 1784477
    GienekS
    Poziom 32  
    Posty: 1971
    Pomógł: 139
    Ocena: 15
    AVR GCC nie sygnalizuje błędnej nazwy wektora przerwania:
    Kod: text Rozwiń Zaznacz wszystko Kopiuj do schowka
    SIGNAL (COS_TAM)
    sam sprawdziłem bo raz sporo czasu straciłem na znalezienie błędu w programie. Też myślałem że powinien takie sprawy zasygnalizować a niestety nie sygnalizuje tego faktu.
  • #8 1784640
    zumek
    Poziom 39  
    Posty: 3352
    Pomógł: 695
    Ocena: 52
    GienekS napisał:
    AVR GCC nie sygnalizuje błędnej nazwy wektora przerwania:
    Kod: text Rozwiń Zaznacz wszystko Kopiuj do schowka
    SIGNAL (COS_TAM)
    sam sprawdziłem bo raz sporo czasu straciłem na znalezienie błędu w programie. Też myślałem że powinien takie sprawy zasygnalizować a niestety nie sygnalizuje tego faktu.

    To w takim razie , co to jest :?:
    Kod: text Rozwiń Zaznacz wszystko Kopiuj do schowka
    
> "make.exe" all

-------- begin --------
avr-gcc (GCC) 3.4.3
Copyright (C) 2004 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.  There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.


Compiling: rs.c
avr-gcc -c -mmcu=attiny2313 -I. -gdwarf-2 -DF_CPU=8000000UL  -Os -funsigned-char -funsigned-bitfields -fpack-struct -fshort-enums -Wall -Wstrict-prototypes -Wa,-adhlns=rs.lst  -std=gnu99 -MD -MP -MF .dep/rs.o.d rs.c -o rs.o 
rs.c:7: warning: `SIG_OVERFLOW0' appears to be a misspelled signal handler

Linking: rs.elf
...
Program:     178 bytes (8.7% Full)
(.text + .data + .bootloader)

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


-------- end --------


> Process Exit Code: 0

    Zawsze warto przejrzec log kompilatora , bo można się nieźle "przejechać" :)

    Piotrek
  • #9 1786045
    GienekS
    Poziom 32  
    Posty: 1971
    Pomógł: 139
    Ocena: 15
    Jako środowiska używam AvrSide może ono nie przekazuje tego ostrzeżenia z kompilatora ? Będę musiał to sprawdzić. Apropo, gdzie tego logu szukać ?
  • #10 1786454
    zumek
    Poziom 39  
    Posty: 3352
    Pomógł: 695
    Ocena: 52
    GienekS napisał:
    Jako środowiska używam AvrSide może ono nie przekazuje tego ostrzeżenia z kompilatora ?

    Ależ pokazuje ;)
    GienekS napisał:

    Będę musiał to sprawdzić. Apropo, gdzie tego logu szukać ?

    Zrób to ;)
    Sprawdź plik "nazwaprojektu.txt" (raport kompilatora i linkera) , oraz w ustawieniach projektu , zakładka "Błędy->Samoczynnie pokaż listę ostrzeżeń" powinna być "zaptaszkowana".
    Cudów nie ma (chyba) :D

    Piotrek

    PS
    Spróbuj KamAVRwork.Też fajna nakładka(IDE) na WinAVR-a.

    Poniżej dowód z AvrSide.
    Załączniki:
    • [ATtiny2313 AVR-gcc] ATtiny2313 AVR-gcc: Przerwania nie zmieniają stanu portu B, co poprawić? AvrSIDE.gif (4.16 KB) Musisz być zalogowany, aby pobrać ten załącznik.
  • #11 1787495
    GienekS
    Poziom 32  
    Posty: 1971
    Pomógł: 139
    Ocena: 15
    Jednak cuda się zdarzają
    Kod: text Rozwiń Zaznacz wszystko Kopiuj do schowka
    SIGNAL (BYLECO)
{;}
    a rezultat
    Kod: text Rozwiń Zaznacz wszystko Kopiuj do schowka
    Build Action :
================================
D:\WinAVR\bin\avr-gcc.exe -gstabs -Os -mmcu=atmega16 -c -pipe -Wall -std=gnu99 ds18x20.c
In file included from ds18x20.c:21:
onewire.h:27:3: warning: #warning | experimental multi-bus-mode is not tested for
onewire.h:28:3: warning: #warning | frequencies below 1,84MHz - use OW_ONE_WIRE or
onewire.h:29:3: warning: #warning | faster clock-source (i.e. internal 2MHz R/C-Osc.)
.............................................
D:\WinAVR\bin\avr-gcc.exe -gstabs -Os -mmcu=atmega16 -c -pipe -Wall -std=gnu99 delay.c
.............................................
D:\WinAVR\bin\avr-gcc.exe -gstabs -Os -mmcu=atmega16 -c -pipe -Wall -std=gnu99 crc8.c
.............................................
D:\WinAVR\bin\avr-gcc.exe -gstabs -Os -mmcu=atmega16 -c -pipe -Wall -std=gnu99 uart.c
.............................................
D:\WinAVR\bin\avr-gcc.exe -gstabs -Os -mmcu=atmega16 -c -pipe -Wall -std=gnu99 onewire.c
.............................................
D:\WinAVR\bin\avr-gcc.exe -gstabs -Os -mmcu=atmega16 -c -pipe -Wall -std=gnu99 main.c
In file included from main.c:38:
onewire.h:27:3: warning: #warning | experimental multi-bus-mode is not tested for
onewire.h:28:3: warning: #warning | frequencies below 1,84MHz - use OW_ONE_WIRE or
onewire.h:29:3: warning: #warning | faster clock-source (i.e. internal 2MHz R/C-Osc.)
.............................................
D:\WinAVR\bin\avr-gcc.exe -mmcu=atmega16 -Wl,-Map=ds18x20.map,--cref -o ds18x20.elf crc8.o delay.o ds18x20.o main.o onewire.o uart.o
.............................................
D:\WinAVR\bin\avr-objdump.exe -h ds18x20.elf

ds18x20.elf:     file format elf32-avr

Sections:
Idx Name          Size      VMA       LMA       File off  Algn
  0 .text         000018b8  00000000  00000000  00000094  2**0
                  CONTENTS, ALLOC, LOAD, READONLY, CODE
  1 .data         0000000a  00800060  000018b8  0000194c  2**0
                  CONTENTS, ALLOC, LOAD, DATA
  2 .bss          00000074  0080006a  0080006a  00001956  2**0
                  ALLOC
  3 .noinit       00000000  008000de  008000de  00001956  2**0
                  CONTENTS
  4 .eeprom       00000000  00810000  00810000  00001956  2**0
                  CONTENTS
  5 .stab         00002b08  00000000  00000000  00001958  2**2
                  CONTENTS, READONLY, DEBUGGING
  6 .stabstr      00001213  00000000  00000000  00004460  2**0
                  CONTENTS, READONLY, DEBUGGING
.............................................
D:\WinAVR\bin\avr-nm.exe  ds18x20.elf
Symbols listed in "ds18x20.smb" file
.............................................
D:\WinAVR\bin\avr-objdump.exe -S ds18x20.elf
.............................................
D:\WinAVR\bin\avr-objcopy.exe -R .eeprom -O ihex ds18x20.elf ds18x20.hex
.............................................
D:\WinAVR\bin\avr-objcopy.exe -j .eeprom --set-section-flags=.eeprom="alloc,load" --change-section-lma .eeprom=0 -O ihex ds18x20.elf ds18x20.eeh
.............................................
D:\WinAVR\bin\avr-objcopy.exe --debugging -O coff-ext-avr --change-section-address .data-0x800000 --change-section-address .bss-0x800000 --change-section-address .noinit-0x800000 --change-section-address .eeprom-0x810000 ds18x20.elf ds18x20.cof
.............................................
    gdzie tutaj jest jakiś błąd lub ostrzeżenie dotyczące błędnego wektora ? AvrSide ani piśnie.
  • REKLAMA
  • #12 1790141
    zumek
    Poziom 39  
    Posty: 3352
    Pomógł: 695
    Ocena: 52
    GienekS :!: coś kręcisz :wink:
    Poświęciłem 1h , by otrzymać log identyczny z Twoim i za żadne skarby , nie mogę uzyskać poprawnej kompilacji projektu.Jak wstawię jakiś nieznany SIGNAL , to w logu zaraz mam warning o tym zdarzeniu.Jedyna możliwość jaka mi przychodzi do głowy , to że błędny SIGNAL umieszczony jest w pliku , który nie należy do kompilowanego projektu , pomimo iż znajduje się w katalogu projektu.Załączam skompilowany projekt z błędnym SIGNAL-em w pliku uart.c .Jak Ci się skompiluje bez ostrzeżenia , to ... wyrzuć komputer he he he.

    Pozdrawiam
    Piotrek
    Załączniki:
    • ds18x20_demo.zip (145.64 KB) Musisz być zalogowany, aby pobrać ten załącznik.
  • #13 1790636
    GienekS
    Poziom 32  
    Posty: 1971
    Pomógł: 139
    Ocena: 15
    Taki jest wynik kompilacji twojego projektu
    I co ty na to ??
    Gdzie robię błąd ?
    Załączniki:
    • MyTest3.zip (195.15 KB) Musisz być zalogowany, aby pobrać ten załącznik.
    • [ATtiny2313 AVR-gcc] ATtiny2313 AVR-gcc: Przerwania nie zmieniają stanu portu B, co poprawić? wynik.gif (14.87 KB) Musisz być zalogowany, aby pobrać ten załącznik.
  • #14 1791436
    zumek
    Poziom 39  
    Posty: 3352
    Pomógł: 695
    Ocena: 52
    GienekS napisał:
    Taki jest wynik kompilacji twojego projektu
    I co ty na to ??
    Gdzie robię błąd ?

    Powiem , jak na spowiedzi - skończyły mi sie pomysły :|
    Takie zwykłe NIC ...
    Kod: text Rozwiń Zaznacz wszystko Kopiuj do schowka
    
#include <avr/io.h>
#include <avr/signal.h>
#include <avr/interrupt.h>
SIGNAL(BYLECO)//(SIG_UART_RECV)
{;}
int main(void)
{;}

    ... i mam warning ...

    Piotrek
  • #15 1795708
    owca2002
    Poziom 11  
    Posty: 30
    Widze ze dyskusja rozgorzala :))

    a ja mam kolejny problem :/ tym razem z rs-em kabelek zrobliem tak jak na zdjeciu http://owca20002.w.interia.pl/max_182.jpg, mam XP-ka i do komunikacji uzywam hyper terminala. Niestety nie nawiazuje mi polaczenia :( i nie wiem czy cos zle zlutowalem cy moze cos zle pisze, albo moze mam cos zle ustawione w kompie ?? moze w biosie??

    Dlatego mialbym prosbe :) jesli ktos moglby napisac mi prosty programik w C, ktory po odebaniu czegokolwiek z kompa zapali diode (diody mam na porcie B), moj uC to ATtiny 2313, a kwarc 8Mhz. Jak bede miala progrmik, ktory bede wiedzial ze na pewno jest dobry to bede kombinowal dalej :) albo moze ktos tez mial juz takie problemy, to prosze o dopowiedz co i jak zle robie :)
    Moderowany przez Light-I:

    Czy funkcja "szukaj" (Forum) u Ciebie nie działa ?

  • #16 1828634
    owca2002
    Poziom 11  
    Posty: 30
    mam kolejne pytanie :)

    napisalem kilka programikow, kompilator nie wywala bledow, ale i tak nie dzialaja i pewnie gdzies znowu mam jakis blad :( przejzalem dokumentacje juz chyba ze 100 razy i nie wiem co jest zle :/ moze ktos pomoze :D (predkosc 38400, kwarc 8MHz)

    #include <avr/io.h>
    #include <avr/signal.h>
    #include <avr/interrupt.h>
    #include <progmem.h>
    #include <stdlib.h>

    int main( void )
    {

    DDRB = 0xff;
    PORTB =0xff;
    DDRD = 0x02;
    PORTD = 0x02;
    UBRRL = 0x0c;
    UCSRB = (1<<RXCIE) | (1<<RXEN) ;

    while(1)
    {
    while ( !(UCSRA & (1<<RXC)) );
    PORTB ^=0xff;
    delayms(1000);
    }
    return 0;
    }

    --------------------------------------------------------
    #define SWITCH_1 (PIND&(1<<2)) //s1
    #define SWITCH_2 (PIND&(1<<3)) //s2

    unsigned char volatile flaga=0;
    char znak=0,*ptr;

    SIGNAL (SIG_USART0_TX)
    {
    char temp;
    temp=*ptr++;
    if(temp!=0)
    {
    UDR=temp;
    }
    else
    {
    cbi(UCSRB,TXEN);
    }
    }

    void sendtext(char *text)
    {
    ptr=text;
    sbi(UCSRB,TXEN);
    UDR=*ptr++;
    }

    int main(void)
    {
    char *info[1]={PSTR("nacisnieto przycisk")};

    DDRB = 0xff;
    PORTB =0xff;
    DDRD = 0x02;
    PORTD = 0x02;
    UBRRL = 0x0c;
    UCSRB = (1<<TXCIE) ;
    sei();

    while(1)
    {
    if(SWITCH_1==0) sendtext(info[1]);
    if(SWITCH_2==0) sendtext(info[1]);
    }
    return 0;
    }
    ------------------------------------------

    unsigned char volatile flag=0;
    unsigned char znak=0;

    SIGNAL (SIG_USART0_RX)
    {
    znak=UDR;
    flag=1;
    }
    int main( void )
    {

    DDRB = 0xff;
    PORTB =0xff;
    DDRD = 0x02;
    PORTD = 0x02;
    UBRRL = 0x0c;
    UCSRB = (1<<RXCIE) | (1<<RXEN) ;
    sei();

    while(1)
    {
    if(flag==1)
    {
    PORTB ^=0xff;
    delayms(1000);
    }
    }
    return 0;
    }
  • REKLAMA
  • #17 1830645
    GienekS
    Poziom 32  
    Posty: 1971
    Pomógł: 139
    Ocena: 15
    Od początku:
    W pierwszym programiku zauważyłem że włączasz przerwania od odbiornika ale nie masz napisanej obsługi tego przerwania. Czy mam rację ?
  • #18 1830939
    owca2002
    Poziom 11  
    Posty: 30
    Tak, byla tam wlaczona obsluga przewan, to pozostalosc po bardziej rozbudowanej wersji. Najpierw zrobilem wszystko na przerwaniach, a poniewaz nie dzialalo to chcialem uproscic i zapomnialem tego skasowac :/ ale niestety nadal nie dziala :( uklad zachowuje sie tak, jakby flaga od odbiornika sie nigdy nie pojawiala :(
  • #19 1832783
    GienekS
    Poziom 32  
    Posty: 1971
    Pomógł: 139
    Ocena: 15
    Zobacz oscyloskopem albo sondą logiczną czy coś przychodzi do procka po RX
  • #20 1832906
    owca2002
    Poziom 11  
    Posty: 30
    GienekS napisał:
    Zobacz oscyloskopem albo sondą logiczną czy coś przychodzi do procka po RX


    tylko chodzi o to ze do pazdziernika nie mam takiej mozliwosci :/ i myslalem ze to tylko blad w programie, ale chyba jednak cos z lutowaniem skopalem :(

    ale jakbys mial jeszcze jakies uwagi co jest zle w programach to czekam, kazda rada sie przyda :)
  • #21 10096997
    konel83
    Poziom 15  
    Posty: 177
    Pomógł: 2
    Ocena: 8
    Witam, wiem że powinienem dostać łopatę za wykopalisko sprzed kilku lat, ale jak wpisuje w google attiny2313 przerwania to wyskakuje jako pierwsze, znalazłem stronkę która może się przydać wielu innym osobom, a są tam opisane problemy dotyczące nazw przerwań praktycznie dla każdego AVR'a. W tym wątku był problem związany z nazewnictwem dlatego wklejam Link
Odpowiedz | Nowy temat
Zgłoś naruszenie prawa

Podsumowanie tematu

✨ Problem dotyczył niezmieniania stanu portu B w mikrokontrolerze ATtiny2313 podczas obsługi przerwania przepełnienia timera0 w środowisku AVR-GCC. Przyczyną błędu była niepoprawna nazwa wektora przerwania – użyto SIGNAL(SIG_OVERFLOW0) zamiast poprawnego SIGNAL(SIG_TIMER0_OVF) dla ATtiny2313. Kompilator AVR-GCC nie zawsze sygnalizuje błędne nazwy wektorów przerwań, co utrudnia diagnozę. Zalecano sprawdzenie logów kompilatora, które mogą zawierać ostrzeżenia o błędnych nazwach sygnałów. Dodatkowo podkreślono konieczność zapoznania się z plikiem nagłówkowym ioXXX.h dla danego mikrokontrolera, gdyż nazwy rejestrów i przerwań różnią się między modelami. W dalszej części dyskusji pojawiły się problemy z komunikacją szeregową (UART) i obsługą przerwań RX, gdzie brakowało implementacji procedury obsługi przerwania, a także wątpliwości dotyczące poprawności połączeń sprzętowych. Wskazano na potrzebę testów sygnałów przy pomocy oscyloskopu lub sondy logicznej. Na koniec podano link do strony z opisem nazw przerwań dla różnych mikrokontrolerów AVR, co może pomóc w unikaniu podobnych błędów.
Wygenerowane przez model językowy.
REKLAMA