Elektroda.pl
Elektroda.pl
X
Arrow Multisolution Day
Proszę, dodaj wyjątek www.elektroda.pl do Adblock.
Dzięki temu, że oglądasz reklamy, wspierasz portal i użytkowników.

[Atmega88] - USART, Realterm komunikacja RS232

nariox 16 Wrz 2015 13:35 1296 27
  • #1 16 Wrz 2015 13:35
    nariox
    Poziom 11  

    Witam !
    Na znanym portalu aukcyjnym zakupiłem przejściówkę USB<-> rs 232 ttl
    Potrzebuję zmontować działający układ komunikacyjny z atmega88 ( interfejs USART) a następnie spokojnie przeanalizować kod, zasadę działania i wreszcię połączyć się z RFM12B.
    Ustawiłem częstotliwość taktowania qc za pomocą fusów na 8MHz.
    W ustawienia portu w komputerze wprwowadziłem BAUDRate 9600
    bit danych 8, bit parzystosci brak , bity stopu 2 podobnie w realterm


    Kod który przepisałem do ATMEL Studio jest następujący(kompluje się bez warningów )

    Kod: text
    Zaloguj się, aby zobaczyć kod

    Do qc nie podłaczam zasilania , tylko postępuje tak samo jak na stronie z której przepisałem kod (schemat połączeń)
    Link

    Pytanie moje dotyczy również dataLen..wpisałem zamiast tego 8, czy dobrze?
    Zgodnie z moim kodem powiniem literke k w programie Realtem,
    Próbowałem również z programem Termite, ale również żadnej odpowiedzi .
    1. Jak sparwdzić poprawność połączeń (dysponuje prostym miernikiem cyfrowym/analogowym)
    2. Do czego służy echo? [Atmega88] - USART, Realterm komunikacja RS232

    0 27
  • Arrow Multisolution Day
  • #2 16 Wrz 2015 13:39
    kindlar
    Poziom 38  

    Zewrzyj tx z rx w przejściówce, wyślij cokolwiek i sprawdź czy odbierasz co wysłałeś.

    0
  • Arrow Multisolution Day
  • #3 16 Wrz 2015 13:43
    Steryd3
    Poziom 31  

    nariox napisał:
    Jak sparwdzić poprawność połączeń


    Samą przejściówkę sprawdzisz łącząc (np. na chwilkę wkrętakiem) piny 2 i 3 z złączu DB09 przejściówki. Po wysłaniu czegokolwiek powinieneś to samo odebrać.

    Podobną operację można zrobić przy miktokontrolerze zwierając za układem MAX232 Tx z Rx (trzeba wcześniej wyczyścić pamięć mikrokontrolera by nie sterował żadnym wyjściem).

    0
  • #4 16 Wrz 2015 14:22
    nariox
    Poziom 11  

    Przepraszam, ale wprowadziłem kolegów w błąd mój cały zestaw wygląda tak:

    [Atmega88] - USART, Realterm komunikacja RS232 [Atmega88] - USART, Realterm komunikacja RS232


    zwarłem na stałe tx i rx, wysyłam przy pomocy realterm cyfre 2, pali sie na zolto tx ale linia rx milczy
    adapter popodpieciu do usb swieci tylko czerwona dioda z lewej strony na dole, natomiast sterowniki zainstalowane i komputer widzi wszystko
    wzgledem masy zarowno tx jak i rx sa w stanie wysokim 5V zworka
    po zwarciu tx z masa wysyla dziwne szlaki w realterm, zapalasie break a po chwili error- wiec jakis kontakt jest


    EDIT: sprawdziłem przejściówke jak w tym wątku:
    Realterm nie odbiera danych

    i przejściówka działa,podobnie w programie Termite( o którym pisałem wyżej) zachowuje się tak samo jak na stronie, gdzie autor skonfigurował program, by wysyłał takie dane,jakie otrzymuje , pala się rownież diody nadawnia/odbierani.

    Problem zatem leży po stronie atmegi88

    0
  • #5 17 Wrz 2015 10:48
    nariox
    Poziom 11  

    Znalazłem jeden błąd w kodzie, jednak to nadal nie pomogło, mianowicie w funkcji

    usart_init(void)

    powinno być:
    UCSR0B=(1<<RXEN0)|(1<<TXEN0);

    hm...

    0
  • #6 17 Wrz 2015 21:57
    miro340
    Poziom 12  

    Witam.
    Tak się kończy bezmyślne przepisywanie programów nawet, gdy są przepisywane z dokumentacji procesora. Jeśli jesteś zupełnie początkujący, to powinieneś najpierw poczytać o USART i o przerwaniach. żeby stosować przerwania to jednak trzeba wiedzieć jak one działają i co je wywołuje. Tutaj mamy zlepek skopiowanego i wklejonego bez ładu i składu kodu. Zastanów się co to przerwanie robi i czy w tak napisanym kodzie ma ono jakiś sens. Pomijam już inne błędy. Najlepsze co można zrobić to napisać ten program na nowo ale w najprostszej formie próbując wysłać jeden lub serię znaków (np w pętli for) bez przerwań, z użyciem funkcji, którą już masz napisaną w swoim programie. Jeśli to zadziała to próbuj użyć przerwań o ile będą one konieczne.
    ...A te 2 bity stopu to musza być? standardowo daje się 1.

    0
  • #7 19 Wrz 2015 21:57
    jnk0le
    Poziom 18  

    nariox napisał:
    Witam !
    Na znanym portalu aukcyjnym zakupiłem przejściówkę USB<-> rs 232 ttl

    Czyli najprawdopodobniej podrobiony PL2303HX. Zgadłem ?

    1. Ustaw 1 bit stopu.
    2. Sprawdź w menadżerze urządzeń czy sterownik nie wywala kodu 5.
    3. Użyj jakiegoś bardziej normalnego terminala.

    -1
  • #8 20 Wrz 2015 13:53
    nariox
    Poziom 11  

    Witam!
    Idąc za radą użytkownika @miro340
    napisałem najprostszy program posługując się datasheet'em dla atmega88 i korzystając z porad zamieszczonych tutaj: avrfreaks

    Ostatecznie otrzymałem kod w najprostszej postac (który jak sądzę powinien wysyłać do komputera to co mu wyślę)

    Zmieniłem nazwy rejestrów, poczytałem trochę note katalogowa.
    I udało się uzyskać jakąś komunikację...
    niestety atmega jak i ja rozmawiamy ze soba za pomocą dziwnych znaczków [Atmega88] - USART, Realterm komunikacja RS232 [Atmega88] - USART, Realterm komunikacja RS232

    Przejsciowka sprawna.Czy to kwestia zasilania/ szybkosci transmisji?
    zdefiniowalem w AS 6 w projekcie w zakladce symbols F_CPU=8000000 .
    Ustawilem fuse bity, wylaczylem dzielenie wewnetrzego oscylatora.

    Code:


    #include <avr/io.h>
    #include <stdio.h>

    #include <util/delay.h>
    #include <avr/interrupt.h>
    #define USART_BAUDRATE 9600
    #define BAUD_PRESCALE (((F_CPU / (USART_BAUDRATE * 16UL))) - 1)

    int main (void)
    {
       
       _delay_ms(500);
       DDRD |=(1<<1);
       char ReceivedByte;

       UCSR0B = (1 << RXEN0) | (1 << TXEN0);   // Turn on the transmission and reception circuitry
       UCSR0C=(1<<USBS0) | (3<<UCSZ00) ;  // Use 8-bit character sizes

       UBRR0H = (BAUD_PRESCALE >> 8); // Load upper 8-bits of the baud rate value into the high byte of the UBRR register
       UBRR0L = BAUD_PRESCALE; // Load lower 8-bits of the baud rate value into the low byte of the UBRR register

       for (;;) // Loop forever
       {
          while ((UCSR0A & (1 << RXC0)) == 0) {}; // Do nothing until data have been received and is ready to be read from UDR
          ReceivedByte = UDR0; // Fetch the received byte value into the variable "ByteReceived"

          while ((UCSR0A & (1 << UDRE0)) == 0) {}; // Do nothing until UDR is ready for more data to be written to it
          UDR0 = ReceivedByte; // Echo back the received byte back to the computer
       }
       return 0;
    }   


    @jnk0le

    nie, to nie tania podróbka, przejściówka firmy FTDI -dałem 27 złotych za sztuke...
    zaraz zmienie ten bit stopu...
    sterownik nie wywala błedu, wszystko okej

    0
  • #9 20 Wrz 2015 14:13
    tronics
    Poziom 36  

    Kod: c
    Zaloguj się, aby zobaczyć kod

    3<<UCSZ00 ?

    0
  • #10 20 Wrz 2015 14:16
    nariox
    Poziom 11  

    tronics napisał:
    Kod: c
    Zaloguj się, aby zobaczyć kod

    3<<UCSZ00 ?



    To jest z kodu inicjalizującego z datasheet'u atmegi88

    0
  • #11 20 Wrz 2015 14:39
    tronics
    Poziom 36  

    Tak, wiem,tylko trochę dziwna konstrukcja biorąc pod uwagę, że z jednej strony chce się poprawiać czytelność kodu, a z drugiej za jednym zamachem ustawia 2 różne bity, których pozycje są zdefiniowane w nagłówkach ;)
    Wszystkie parametry w realterm muszą być takie jak ustawione w module uart mikrokontrolera. Wiele błędów jest właśnie ze stopem lub rozmiarem wysyłanego znaku - wtedy najczęściej przestawianie opcji w realterm pozwala znaleźć gdzie tkwi błąd.

    0
  • #12 20 Wrz 2015 17:50
    jnk0le
    Poziom 18  

    Jeśli rzeczywiście masz 8MHz i po ustawieniu wszystkiego prawidłowo nadal będą krzaki to raczej powinieneś zainwestować 1,50 CBLN w kwarc, najlepiej usart-friendly (18,432).

    0
  • #13 20 Wrz 2015 18:03
    tronics
    Poziom 36  

    Nie. Kwarc "okrągły" nie "uart-friendly" powoduje tylko okazjonalne błędy transmisji, względnie łatwe do wychwycenia i skorygowania. Jak dużo? Jest kalkulator do tego. Tutaj był inny problem.

    0
  • #14 20 Wrz 2015 18:33
    nariox
    Poziom 11  

    Mam zewnetrzny kwarc 8 mhz, wlutowqny do ppdstawki wiec wszystkie podlaczenia prawidlowe, zmienie ustawienia fuse bitow i dam znac wieczorem czy pojdzie, musze wtedy cos w programie dodawać jakas linijke?

    0
  • #15 20 Wrz 2015 19:36
    jnk0le
    Poziom 18  

    Najlepiej to całkowicie odkomentuj UCSRC. Domyślnie jest 8n1.

    0
  • #16 21 Wrz 2015 07:56
    miro340
    Poziom 12  

    Proszę bardzo w załączniku najprostszy działający kod sprawdzony na atmega168 ale to bez znaczenia bo na atmega88 też zadziała. Program kompilowany był w AVRStudio4, kwarc 8MHz, wyłączony wewnętrzny podział przez 8, terminal Br@y, przejścówka wykonana na MAX232. Jak to nie zadziała to radzę dobrze się przyjrzeć układowi, posiadanej przejściówce no i równie dobrze może być problem ze sterownikami.

    0
  • #17 21 Wrz 2015 13:51
    nariox
    Poziom 11  

    udało się ;)) i przesyłanie literki działa
    teraz probuje wysłać po sobie ciąg literek używając kilkakrotnie
    USART_Transmit('p');
    USART_Transmit('a');
    USART_Transmit('c');
    USART_Transmit('k');
    USART_Transmit('a');
    w pętli for;
    niestety atmega pluje dziwnymi znakami, dopiero gdy na klawiaturze trzymam jakis klawisz z literka obojetnie jaka to wtedy dopiero otrzymuje poprawne dane czyli w kolko: PACKAPACKAPACKAPACKA itd...

    miro340 napisał:
    terminal Br@y

    Ten program wyświetla mi Frame error gdy nie trzymam klawisza zadnego -
    mogę prosić o wskazówkę co powinienem z tym zrobić?
    próbowałem dodać opóźnienie, ale coś zostaje nadal w rejestrze UDR0

    0
  • #18 21 Wrz 2015 15:34
    miro340
    Poziom 12  

    Dziwne zachowanie. Ja do pętli for wrzuciłem to:
    USART_Transmit('p');
    USART_Transmit('a');
    USART_Transmit('c');
    USART_Transmit('k');
    USART_Transmit('a');
    USART_Transmit(' ');
    i wszystko działa jak należy bez wciskania żadnych klawiszy.
    [Atmega88] - USART, Realterm komunikacja RS232

    Jeśli Br@y tak dziwnie działa, to sprawdź w innym terminalu, a najlepiej w Putty

    0
  • #19 21 Wrz 2015 16:18
    jnk0le
    Poziom 18  

    Bity stopu, parzystość i kontrola przepływu ustawione tak jak być powinny?
    Sprawdź jak będzie działało z tą biblioteką.

    0
  • #20 21 Wrz 2015 18:12
    nariox
    Poziom 11  

    Coś na pewno jest nie tak ,gdyż pętla for pomimo ustawienia i<=10 wykonuje się cały czas nawet przy pojedynczej literce ( zła częstotliwość?) a z tego co widać gołym okiem powinna się wykonać 11 razy, spróbuje coś pokombinować jeszcze
    dodam że częstotliwość procka ustawiłem na 8MHZ wstawiając we właściwościach projektu w zakładce symbols->definied: F_CPU=8000000UL

    0
  • #21 21 Wrz 2015 18:52
    BlueDraco
    Specjalista - Mikrokontrolery

    Pokaż kod. Nie wysyłaj znaków bez przerwy - zrób jakąś przerwę po każdej serii znaków, czyli np. delay() w pętli.

    0
  • #22 21 Wrz 2015 18:56
    nariox
    Poziom 11  

    miro340 napisał:


    Jeśli Br@y tak dziwnie działa, to sprawdź w innym terminalu, a najlepiej w Putty


    wywala błedy jak program wali stek bzdur , gdy normalnie trzymam klawisz na klwaiaturze to wtedy jest Rx ok - więc program(Br@y) wporządku wg mnie- nie wiem tylko skąd te dziwne znaki się tam biorą ...

    @ BlueDraco kod programu to taki jak zamieścił miro340,dokładnie taki wklejam bez żadnych modyfikacji, fuse bity zaprogramowałem i układ dla pojedynczej literki działa ok ale śle ją w nieskończoność.
    przy probie wysłania wyrazu "packa" kilkukrotnie używając usart_transmit()
    program się krzaczy i dzieje się to o czym pisałem kilka postów wyżej

    0
  • #23 21 Wrz 2015 19:26
    BlueDraco
    Specjalista - Mikrokontrolery

    Prawdopodobnie mikrokontroler się resetuje - inaczej nie powtarzałby ciągle czegoś, co ma się wykonać określoną liczbę razy. Zamiast return 0 na końcu main napisz pętlę pustą for(;;); - tak na wszelki wypadek, gdyby się okazało że return (którego nie powinno być) powoduje restart.

    Podepnij linię reset przez rezystor np. 10k do plusa. Napisz pętlę, która wysyła kolejne znaki lub ciągi znaków, a potem czeka np. pół sekundy.

    0
  • #24 21 Wrz 2015 19:41
    nariox
    Poziom 11  

    Spróbuje jeszcze wstawić drugiego procka bo mam 2, może ten jest walnięty albo coś
    jeżelit o nie pomoże to wstawie atmege32 i napisze dla niej taki sam program, potem zobaczymy co z tego wyjdzie
    @BlueDraco - dzięki za podpowiedz ;)

    0
  • Pomocny post
    #25 21 Wrz 2015 19:43
    BlueDraco
    Specjalista - Mikrokontrolery

    To nie jest wina egzemplarza mikrokontrolera.

    0
  • Pomocny post
    #26 21 Wrz 2015 21:02
    miro340
    Poziom 12  

    Prawdopodobnie BlueDraco ma rację i przyczyną jest ciągły reset procka. Najlepiej pokaż schemat swojego układu ale bez uproszczeń tylko dokładnie zgodny z fizycznym układem. Czy układ RESETu masz podciągnięty do zasilania?

    0
  • #27 21 Wrz 2015 21:02
    nariox
    Poziom 11  

    udało się!!!!!!!!!!
    dzięki blueDraco, brakowało zasilania za pinie Vcc z przejściówki,podpiałem i działa ;))
    teraz będę mógł eksperymentować dalej
    na dowód załączam screena

    [Atmega88] - USART, Realterm komunikacja RS232

    0
  • #28 21 Wrz 2015 21:25
    miro340
    Poziom 12  

    No i potwierdziła się teoria, że najbzdurniejszy błąd potrafi sponiewierać bardziej niż te najpoważniejsze :)

    0