logo elektroda
logo elektroda
X
logo elektroda
Szukanie Zaawansowane
logo elektroda
Myślisz o drukarce 3D?
Myślisz o drukarce 3D? Ostatnie dni promocji »
REKLAMA
Dostępna jest polska wersja

Czy wolisz polską wersję strony elektroda?

Nie, dziękuję Przekieruj mnie tam
Adblock/uBlockOrigin/AdGuard mogą powodować znikanie niektórych postów z powodu nowej reguły.

USART w ATtiny2313: Niepoprawne dane przy połączeniu z PC przez MAX232

michalmily 12 Paź 2007 20:33 3131 13
Zgłoś naruszenie prawa
Odpowiedz | Nowy temat
  • #1 4372855
    michalmily
    Poziom 13  
    Posty: 139
    Ocena: 4
    Witam, mam problem z poprawnością działania USART'u w ATtiny 2313, mikrokontroler jest podłączony do komputera poprzez MAX'a 232, z kondensatorami 2,2uF. Układ wysyła do komputera dane ale nie są one poprawne - po prostu krzaki. Próbowałem z różnymi konfiguracjami jednak za każdym razem to samo. ATtiny działa na zewnętrznym kwarcu 12Mhz. Podłączałem wyjscie portu COM z komputera przez maxa do jego wejścia i wówczas transmisja działała, zatem zakładam, że max nie stwarza problemu. Fuse bits wszystkie na 1 (wg ISP Prog). Dołączam program w Asemblerze:

    Kod: text Rozwiń Zaznacz wszystko Kopiuj do schowka
    
.INCLUDE    "tn2313def.inc"     

.DSEG
.CSEG 					
.ORG 0x0000 			
rjmp Reset

.ORG 0x0013 				
Reset:					
ldi		r16, low(RAMEND)		
out		spl, R16

ldi r16, 0b00000010
out ddrd, r16
ldi r16, 0b00000011
out portd, r16

ldi r16, 77
out UBRRL, r16
ldi r17, 0b00000000
out UBRRH, r17

ldi r16, (1<<RXEN)|(1<<TXEN)
out UCSRB, r16

ldi r16, (3<<UCSZ0)
out UCSRC, r16

sei						

ldi r16, 30
Petla_glowna:
	USART_transmit:
		sbis UCSRA, UDRE
		rjmp USART_transmit
		out UDR, r16
		inc r16

	ldi r18, 255                                             
	rcall czekaj
rjmp Petla_glowna

Czekaj:
   push r29
   mov r31, r18                                            
   P:                                                      
   ldi r30, 10
   P0:                                                     
   ldi r29, 200
   P1:
   nop
   dec r29
   brne P1                                               
   dec r30
   brne P0                                                 
   dec r31
   brne P                                                  
   pop r29
ret


    Za pomoc z góry dziękuję i pozdrawiam....
  • #2 4373300
    mirekk36
    Poziom 42  
    Posty: 9195
    Pomógł: 964
    Ocena: 2289
    piszesz, że masz zewn kwarc 12MHz - a skąd wziąłeś albo jak sobie ustaliłeś wartość którą zapisujesz do UBRRx - od której zależy prędkość transmisji RS232 i dokładnie jaką prędkość ustawiłeś?

    po drugie odblokowujesz przerwania a w miejscu gdzie są wektory obsługi przerwań masz "pustkę" zamiast chociażby samych rozkazów reti dzięki czemu już z tego powodu program może lecieć w przysłowiowe "maliny" gdy zgłaszane jest jakieś przerwanie przez USART

    gdy już zrobisz porządek z obsługą przerwań to proponuję ci zastosować sobie jakiegoś kwarca bardziej "RS232-friendly" tzn przynajmniej jakiegoś o wartości, która jest podana w nocie PDF procka - albo chociaż wewn oscylatora 8MHz i dla tej wartości ustawić UBRR wartością, która tam jest podana dla wybranej przez ciebie prędkości RS232 gdzie będą odpowiednio niskie błędy. Gdy to ci ruszy to będziesz już wiedział o co chodzi i wtedy zrozumiem, że już sam będziesz wiedział jak sobie tę wartość obliczać dla innych wartości kwarców
  • #3 4373719
    michalmily
    Poziom 13  
    Posty: 139
    Ocena: 4
    Witam, dziekuję za odpowiedź Prędkość transmisji ustaliłem na 9600bps, zgodnie ze wzorem UBRR=(tosc/(16*BAUD))-1 = 77,125. Co do przerwań - nie sądzę, żeby miało to jakieś znaczenie, po starcie układ od razu skacze do etykiety RESET, która znajduje się za wektorem przerwań, uruchomienie systemu przerwań też raczej nie ma wpływu, przerwanie od USART'a nie jest zgłaszane, gdyż to nie zostało ustawione w UCSRB. Jeszcze jedno mnie ciakawi. Podczas symulacji w AVR studio ta operacja:
    Kod: text Rozwiń Zaznacz wszystko Kopiuj do schowka
    
ldi r16, (3<<UCSZ0)
out UCSRC, r16

    powoduje wpisanie do rejestru UBRRh wartości 6, podczas gdy wcześniej wpisałem 0. Postaram się zmienić kwarc na jakieś 11,0592Mhz i dam znać co i jak. Pozdrawiam....
  • #4 4373943
    mirekk36
    Poziom 42  
    Posty: 9195
    Pomógł: 964
    Ocena: 2289
    zastanów się co robi twój rozkaz

    Cytat:
    ldi r16, (3<<UCSZ0)


    powinno się pisać (1<<UCSZ0) co oznacza ustawienie bitu o wartości 1 na pozycji UCSZ0

    czyli u ciebie powinno to być podobnie jak napisałeś powyżej

    Cytat:
    ldi r16, (1<<UCSZ1)|(1<<UCSZ0)


    co do prędkości - dobrze obliczyłeś i prawie powinno działać nawet przy tym 12MHz - więc może tylko to że nie ustawiła się transmisja na 8 bitów jest problemem w twoim przypadku
  • #5 4378526
    michalmily
    Poziom 13  
    Posty: 139
    Ocena: 4
    Witam, poprawiłem to, jednak nic się nie zmieniło. Ciagle przesyła krzaki. Wartości rejestrów wg AVR Studio ładowane są poprawnie, jednak ciągle w momencie zapisu rejestru UCSRC on zapisuje UBRRh Pozdrawiam....
  • #6 4378713
    mirekk36
    Poziom 42  
    Posty: 9195
    Pomógł: 964
    Ocena: 2289
    hmm na początek jeszcze się przyznam że tak jak ty napisałeś czyli ldi r16, (3<<UCSZ0) też można bo tak jest w nocie aplikacyjnej PDF

    ale tak się zastanawiam jeszcze nad tym że przed wejściem do pętli głównej ustawiasz wartość R16 na 30 a potem ciągle go zwiększasz inc R16

    proponuję ci dać przed wejściem do pętli ldi R16, 65
    czyli znak A

    i podaruj sobie to inc R16 - czyli będzie tak że cały czas do portu będziesz wysyłał literkę A bo tak zwiększasz R16 i wysyłasz rzeczywiście cały zestaw znaków ASCII ale również znaki spoza zakresu a co najgorsze gdy R16 się przepełni to wysyłasz znaki od kodu 0 - co powoduje że wysyłasz znaki sterujące do terminala np 8 czy podobne

    to co robisz powinno działać - ale jeśli nie to spróbuj jeszcze z innym kwarcem np tym 11.0592

    ... aha i ustaw może tak jeszcze dla pewności, że pin oznaczony Tx jest jako port wyjściowy
  • #7 4379139
    michalmily
    Poziom 13  
    Posty: 139
    Ocena: 4
    Witam, zrobiłem jak mówiłeś jednak nic sensownego nie przesyła. Dziwi mnie, że jeszcze nigdy nie pojawił mi się w oknie terminala pojedynczy bajt, za każdym razem idą 3 lub nawet 6. Jutro postaram się sprawdzić inny kwarc lub procesor. Dam znać co i jak, dzięki i pozdrawiam....
  • #8 4379696
    Mr_T_
    Poziom 15  
    Posty: 205
    Pomógł: 1
    Ocena: 23
    Witam. Jak obsługiwałem Attiny2313 w c i dane z RS-a odbierałem w przerwaniu. Nie mogłem dojść do ładu dlaczego to nie działa. Jak zacząłem szukać to okazało sie ze ten uC ma problemy właśnie z przerwaniami i usartem. Zmieniłem procek i ten sam kod zostawiłem tylko inny plik nagłówkowy wrzuciłem i wszystko było oki.

    Przepraszam, że to nie jest w sumie dobra rada jak rozwiązać ten problem, ale ja po tygodniu męczarni i konsultacji z osobami zajmującymi się programowaniem uC poddałem się i zmieniłem procek.
  • #9 4379758
    mirekk36
    Poziom 42  
    Posty: 9195
    Pomógł: 964
    Ocena: 2289
    Mr_T_ -> ja z kolei zrobiłem z powodzeniem na ATtiny2313 obsługę RS232 a nawet RS485 i to w pełni z użyciem przerwań i buforem cyklicznym dla nadawania i odbioru - dzięki czemu wysyłanie czy odbieranie już z poziomu własnej aplikacji sprowadzało się tylko do wpisania czegoś do bufora lub odczytu stamtąd po sygnalizacji odpowiednim przerwaniem. Wszystko pisałem akurat w asemblerze i naprawdę nie miałem i nie mam do dzisiaj najmniejszego problemu z USARTem w tym procku
  • #10 4379831
    Mr_T_
    Poziom 15  
    Posty: 205
    Pomógł: 1
    Ocena: 23
    Wszystko może przez to, że ja pisałem w c. Znalazłem sporo opinii, że czasem właśnie te uC są problemowe. Może źle instrukcje jakoś były tłumaczone na asm. Nie wiem dlaczego zmiana procka, odrazu biblioteki pomogła. Kod programu nie był zmieniany.
  • #11 4381906
    michalmily
    Poziom 13  
    Posty: 139
    Ocena: 4
    Witam ponownie, sprawdziłem na ATmega128 i USART działa, co prawda nie przesyła wszystkich znaków- gdy każę mu wypisać wszystkie od 0 do 255, przeskakuje co jakiś czas o kilka znaków. Co tym razem? Pozdrawiam....
  • #12 4381959
    Mr_T_
    Poziom 15  
    Posty: 205
    Pomógł: 1
    Ocena: 23
    Przecież wszystkich znaków nie wyśle. Poszukaj tablicy kodów ASCII np. http://www.kryptografia.com/algorytmy/ascii.html
    Znaki dopiero zaczynają się od liczby chyba 32 (tak jak jest w tabeli).

    A co do przeskakiwania, to może jednak być niedokładne skonfigurowanie prędkości USART-a wraz z PC.
  • #13 4385218
    Michał_z1
    Poziom 16  
    Posty: 190
    Pomógł: 13
    Ocena: 2
    witam
    A wyłączyłeś wewnętrzny podział częstotliwości kwarcu w Attinie??
    pozdro.
  • #14 4386834
    michalmily
    Poziom 13  
    Posty: 139
    Ocena: 4
    Witam ponownie, USART w ATmega128 działa, ale z ATtiny ciągle mam problem. Wewnętrzny podział częstotliwości wyłączyłem. Pozdrawiam....
Odpowiedz | Nowy temat
Zgłoś naruszenie prawa

Podsumowanie tematu

✨ Problem dotyczy niepoprawnej transmisji danych przez USART w mikrokontrolerze ATtiny2313 podłączonym do komputera za pomocą układu MAX232 z kondensatorami 2,2uF. Mikrokontroler pracuje na zewnętrznym kwarcu 12 MHz, a prędkość transmisji ustawiono na 9600 bps z wartością UBRR=77. W kodzie asemblerowym pojawia się problem z zapisem rejestru UCSRC, który zamiast ustawiać parametry transmisji, nadpisuje rejestr UBRRH. Próby zmiany kwarcu na 11,0592 MHz oraz poprawki w konfiguracji bitów UCSZ0 nie przyniosły poprawy. Dyskusja wskazuje na możliwe błędy w obsłudze przerwań, choć autor twierdzi, że przerwania USART nie są włączone. Zwrócono uwagę na konieczność prawidłowego ustawienia pinów portu (Tx jako wyjście) oraz na potencjalne problemy z mikrokontrolerem ATtiny2313 w kontekście USART i przerwań. Jeden z uczestników potwierdził poprawne działanie USART w ATtiny2313 z użyciem przerwań i bufora cyklicznego, co sugeruje, że problem może leżeć w implementacji kodu. Testy na ATmega128 wykazały działanie USART, choć z drobnymi problemami przy wysyłaniu pełnego zakresu znaków. Wskazano również na konieczność wyłączenia wewnętrznego podziału częstotliwości kwarcu w ATtiny. Ostatecznie problem z transmisją w ATtiny2313 pozostaje nierozwiązany, a autor planuje dalsze testy z innymi kwarcami lub procesorami.
Podsumowanie wygenerowane przez AI na podstawie treści dyskusji.
REKLAMA