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

[mega8][gcc] dziwny problem z portem szeregowym

bartekb3 20 Sty 2009 20:15 1067 8
REKLAMA
  • #1 6028535
    bartekb3
    Poziom 10  
    problem jest dość dziwny z tego względu że to co jak myśle powinno działać zawsze raz działa a raz nie:) mam taka procedurę

    
    void wyslij_dane_RX(void) {
        /* jesli pierwszym bajtem danych będzie 0x0F to znaczy ze transmisja dotyczy
           poleceń z uC
           jesli natomiast pierwszym bajtem bedzie 0xF0 znaczyc to będzie iz transmisja
           dotyczy danych do odebranych przez cc1000
           drugi bajt to ilość wysyłanych danych w bajtach
        */
        if(RXo>0) {
        USART_putchar(0xF0); //bajt początku
        USART_putchar(RXo);
        while (RXo) {
            USART_putchar(buforRx[RXo]);
            RXo--;
        }
        USART_putchar(0xF0); //bajt końca taki sam jak początku
        //zwolnij flage danych w buforze RX
            SET(PORT_FLAG,5);
        }
    }
    


    gdzie
    
    //bufory realizujace FIFO
    extern char buforTx[];
    extern char buforRx[];
    extern unsigned char RXo;
    extern unsigned char TXo;
    


    no i procedurka ogólnie działa z tym że linijka
     USART_putchar(0xF0); //bajt końca taki sam jak początku

    raz zwraca 0xF0 a raz 0x00 i za cho*** nie moge dojść dlaczego, może Wy macie jakiś pomysł...?
  • REKLAMA
  • #2 6028954
    dawid512
    Poziom 32  
    Jeżeli wysyłasz tylko jeden bajt to zawsze odbierasz go poprawnie? Wew. oscylator czy zew. kwarc?
  • #3 6031210
    bartekb3
    Poziom 10  
    wew oscylator... chciałem na zew spróbować ale atmega przestaje odp po przestawieniu fusebitow...

    a jeden bajt zawsze odbieram dobrze...
  • REKLAMA
  • #4 6031255
    BoskiDialer
    Poziom 34  
    Profilaktycznie można ustawić dwa bity stopu, co powinno dać możliwość zsynchronizowania się nawet w przypadku większego niedopasowania.

    Przy okazji podejrzana jest kolejność wysyłania bajtów w pętli while (dane wysyłane od końca, najpierw zostanie wysłany jeden bajt spoza buforu, a na końcu zostanie pominiety bajt z komórki zerowej).

    Pokaż kod funkcji USART_putchar, może tam jest jakiś błąd.

    Czym jest "PORT_FLAG" ?
  • #5 6031371
    bartekb3
    Poziom 10  
    no wiec z ta kolejnością wysyłanych danych to jest w porządku (tej konkretnej kolejnosci wymaga ramka) kod funkcji zamieszczam :
    
    void USART_putchar(char c)    // wysyła znak c na USART
    
    {
    
    
    
        UDR = c;        // wpisz c do rejestru UDR
    
        loop_until_bit_is_set(UCSRA,TXC);  // czekaj na zakończenie transmisji
    
        SET(UCSRA,TXC);      // ustaw bit TXC w rej. USR
    
    }


    co do konf usart to jest niesynchroniczny 8b danych 2b stopu odd parity 19200baud

    co ciekawe jesli w dowolnym miejscu programu wpisze
    
    USART_putchar(0x02);
     USART_putchar(0x00);
     USART_putchar(0xF0);
    

    to dwa bajty beda przesłane poprawnie a ostani nie:P ale jesli wpisze :
    
    USART_putchar(0x02);
     USART_putchar(DOWOLNY BAJT ROZNY OD 0x00 );
     USART_putchar(0xF0);

    to juz wszystko przechodzi poprawnie...

    nic z tego nie rozumiem:D
  • #6 6031480
    BoskiDialer
    Poziom 34  
    Zazwyczaj wysyłanie wygląda tak:
    void USART_putchar(char c)
    {
    	loop_until_bit_is_set(UCSRA, UDRE);
    	UDR = c;
    }

    Nie sprawdzałem zachowania się flagi TXC (zawsze działam w oparciu o UDRE).
    Mam pewne przypuszczenie, że procesor idzie zbyt szybko.

    edit: s/loop_until_bit_is_clear/loop_until_bit_is_set - nigdy nie lubiałem tych makr
  • REKLAMA
  • #7 6031618
    bartekb3
    Poziom 10  
    powinno być "loop_until_bit_is_set" :) zmieniłem i nie pomaga...

    poprobowalem troche i wychodzi na to że cała transmisja jest ok do momentu az nie wysle 0x00 po tym bajcie reszta juz jest przekłamana...
  • REKLAMA
  • #8 6031691
    BoskiDialer
    Poziom 34  
    Jest jeszcze jedna możliwość: program, którym odbierasz dane, przerywa odbiór po odebraniu bajtu równego zero. Co jest po drugiej stronie kabla?
  • #9 6031704
    bartekb3
    Poziom 10  
    po drugiej stronie gtkTerm czyli serial port terminal pod ubuntu...

    wgrałem ten sam kod na drugi uC i jest to samo;/

    hmmm w opcjach tego programu jest "send break" po nacisnieciu wysyła 00 na rs - moze to to;D

    okazało się że to wina programu dzieki za pomoc
REKLAMA