transmisja UART AVR PC, w terminalu 00 C0 C0 00 itd

Question

Zgłaszam problem, ponieważ mimo przeszukania forum nie znalazłem odpowiedzi. Chodzi o to, że wysyłam z mikroprocesora ATMega48 jakiś dowolny znak. Jednak w terminalu zamiast tego czego oczekuje (cały czas tej samej wartości) pojawia się ciąg znaków 00 C0 C0 00 C0 C0 00 C0 C0 itd. Nawet jeśli...

adasb · Answer

Aby sprawdzić poprawność dzialania MAXa musisz odpiąc linie TxD i RxD od mikroprocesora i wtedy zewrzyj R1out z T1in (wyprowadzenie 11 i 12 układu MAX232). Takie coś pomoże ci sprawdzić ci czy MAX poprawnie odbiera i nadaje dane. Wtedy wysyłając coś z terminala otrzymujesz spowrotem to samo co wysłałeś. Wtedy bedziesz wiedział że komunikacja z MAXem działa prawidłowo i musisz szukać błędu w programie (to znaczy masz żle skonfigurowany Uart lub żle ustawione porty mikroprocesora).
Mam nadzieje że coś ci pomogłem.
Pozdrawiam.

_Robak_ · Answer

w tym temacie dalem programy na PCta i na ATmege16, mozesz sprawdzic czy dostajesz echo, jesli tak to maxa masz sprawnego jesli nie to znaczy ze cos z podlaczeniami masz nie tak.

Adam_Z · Answer

Dziękuję za podpowiedź. Przeprowadziłem zasugerowany test i wygląda jakby układ MAX232 działał prawidłowo. Niestety małe to pocieszenie dla mnie bo ostatnia rzecz którą podejrzewałem o nieprawidłowe działanie jest sprawna. Proszę zatem o podpowiedzi odnośnie programu, chociaż uważam, że niewiele da się tu pokombinować. Może zna ktoś receptę na mój problem?

_Robak_ · Answer

A terminala masz dobrze ustawionego?

Adam_Z · Answer

TAK, terminal mam ustawiony zgodnie z tym co wpisuje na procku (jeśli chodzi o program asemblerowy). Nie do końca wiem jak to jest w BASCOM, czy tez trzeba wszystko definiować (baud rate, ramke).

_Robak_ · Answer

A mozesz pokazac program w asm?

Adam_Z · Answer

Kod: text Rozwiń Zaznacz wszystko Kopiuj do schowka .include m48def.inc .def temp = r16 .def dane = r23 .org $000 rjmp INIT START_T:  lds temp,UCSR0A; sprawdzenie UDREn andi temp,0x20 breq START_T sts UDR0,dane TEST:     lds temp,UCSR0A; czekaj aż zostanie wysłany znak andi temp,0x40   breq TEST ldi temp,0x40; wyzerowanie TXCn przez ustawianie sts UCSR0A,temp ret INIT:        ldi temp,high(RAMEND) out SPH,temp ldi temp,low(RAMEND) out SPL,temp ldi temp,0x01; sygnalizacja diodą out DDRB,temp out PORTB,temp ldi temp,0x00 ; poczatkowe wartosci rejestru sts UBRR0H,temp;  ustawienie BAUD na 9600 ldi temp,0x2F sts UBRR0L,temp ldi temp,0x06; ustawienie ramki  sts UCSR0C,temp ldi temp,0x08; rozpoczecie transmisji sts UCSR0B,temp   ldi dane,5 SKOK:     cbi PORTB,0 rcall START_T rjmp SKOK

_Robak_ · Answer

Zamiast wpisywac wartosci do rejestrow lepiej pisac tak:

Cytat:

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

przynajmniej za 2 tygodnie bedziesz wiedzial o co chodzi w programie;)

a w petli nie powinno byc? :


START_T:  lds temp,UCSR0A; sprawdzenie UDREn 
      andi temp,0x20 
      cmpi temp,0x20/***/
      bne START_T /***/

      sts UDR0,dane

Adam_Z · Answer

Znam ten sposób wpisu, z przyzwyczajenia używam wpisów do rejestru (rzeczywiście po czasie można zapomnieć ale po to są komentarze). Co do tej pętli to wystarcza andi temp,0x20 bo to ustawia lub nie znacznik zera. Ale spróbuje to zmienić.

_Robak_ · Answer

i jeszcze powinno byc chyba bne zamiast breq, wysylac mozna jesli UDRE jest 1, a w twojej petli jesli sie nie myle czeka az bedzie 0

Adam_Z · Answer

Pętla jest prawidłowo, ale o tej porze mogę się mylić

.


START_T:  lds temp,UCSR0A; sprawdzenie UDREn
                andi temp,0x20; maskowanie bitu UDRE
                                      ;jeśli jest 0 po maskowaniu to znaczy ze UDRE=0
                                      ;więc sprawdza dalej (skok do START_T)
                breq START_T; jeśli było by brne to przy UDRE=0 przeszedł by   
                                        dalej

_Robak_ · Answer

Tez juz troche zmeczony jestem;) ale przeanalizujmy;) Jesli UDRE jest 1 to mozna wyslac znak, po zmaskowaniu jesli zostanie 0x20 to w twojej petli wroci do START_T, bo jest breq START_T, i nie wpisuje sie nic do UDR, jesli byloby brne to jesli po zmaskowaniu zostanie 0x20(czyli mozna slac) nie idzie do START_T bo jest brne, UDR zostaje zapisany i ramka jesy wysylana:) Wiec wydaje mi sie ze tutaj jest poblem;)

Adam_Z · Answer

breq jest skok dla znacznika Z=1, wtedy gdy w temp jest 0 po maskowaniu
brne jest skok dla Z=0, wtedy gdy w temp jest 0x20 po maskowaniu

andi ustawia lub zeruje znacznik zera

Pętlę tą już wypróbowałem w AVR STudio i funkcjonuje jak powinna, przed chwilą jeszcze raz sprawdziłem i jest ok.

Adam_Z · Answer

Po kolejnych testach z różnymi rodzajami kwarców wydaje mi się, że błąd wynika z procka. Wygląda na to, że nie jest to część programowa więc trzeba będzie wymienić układ i wtedy spróbować. Będę informował o swoich postępach.

_Robak_ · Answer

Sprawdzilem te petle i obie wersje sa poprawne:)

kaczepa · Answer

Zmień jak poniżej START_T: sbis UCSR0A,UDRE0 rjmp START_T out udr0,dane TEST: ......... Pozdrawiam

mirekk36 · Answer

proponuję ci sprawdź to: clr R16 out UCSR0A, R16 ldi R16, 0x00 out UBRR0H, R16 ldi R16, 0x2F out UBRR0L, R16 ldi R16, (1

Samuraj · Answer

A może procek nie chodzi na kwarcu tylko na generatorze wewnętrznym

Adam_Z · Answer

To stwierdzenie Samuraj-a może być prawdziwe. Przyczyną może być kwarc wewnętrzny. Tylko jak zmienić fuse bity w ATMega48. Spróbowałem za pomocą ISP Programmer i procek kompletnie mi nie odpowiada (wpisałem na fuse-y 0110 i nacisnąłem program). Na szczęście mam dwa jeszcze. Pytanie moje jest o zmianę fuse bitów, jak to zrobić. Jakie ustawienie zastosować? Czy da się w jakiś sposób uratować ten zaprogramowany procek?
Dziękuje za bieżące odpowiedzi.

mirekk36 · Answer

jeśli poprzez złe zaprogramowanie fuse bitów ustawiłeś go na generator zewnętrzny to żaden problem żeby go ożywić

ja tak raz zrobiłem sobie z ATTiny2313. Później dołączyłem prosty generatorek kilkadziesiąt KHz na kilku bramkach TTL i znowu mogłem go przeprogramować - więc spokojnie

- a jak zaczynałem z RSem to też właśnie miałem ten sam problem co ty - tzn nie działał mi RS bo uC chodził na wewn oscylatorze

i przy pierwszej w życiu próbie zmiany fusebitów go załatwiłem

ale po reanimacji wszystko ruszyło i o dziwo wszystkie procedury do komunikacji RS też ruszyły odrazu

Mam na sprzedaż:
13.11.2007 Wyświetlacz PLED(OLED) 2x16 WINSTAR WPI1602B-Y-JCS

Samuraj · Answer

Dla sprawdzenia mogłeś napisać program migacza diodą i odłączyć kwarc zewnętrzny. Wtedy byś wiedział czy chodzi na wewnętrznym generatorze czy na kwarcu.
Nie wiem jak go ustawiłeś ale poczytaj o zablokowanych prockach,wiele o tym było.
Rozwiązanie pewne i sprawdzone programator równoległy, tymczasowe i doraźne generator na TTL'ach (czasami pomaga - to zależy od tego jak bardzo namieszamy).
Ja choć sam nie programuje w Bascomie (bo mam na jego temat swoje zdanie) to ustawiam nim fusebity, chyba nie widziałem narzędzia co łatwiej było by napisane co zmieniamy.

Promuję tematy:
21.03.2019 Emulator ZX Spectrum 48 na STM32F407

kaczepa · Answer

Odpaliłem Twój program na Atmega32 (nie mam pod ręką Atmega48).Oczywiście pozmieniałem niektóre ustawienia (USART).Program zaczął pracować dopiero po wprowadzeniu zmiany opisanej w moim poprzednim poście i wysyła 5-teczki przez RS. Pozdrawiam

Adam_Z · Answer

Dziękuje wszystkim, którzy pomagali w rozwiązaniu problemu. W szczególności Samurajowi i kaczepie. W końcu transmisja zaczęła działać prawidłowo. Główny problem tkwił w zmianie fuse bitów. Po przestawieniu na zewnętrzny rezonator kwarcowy i wyłączeniu dzielnika zegara przez 8 mikrokontroler zaczął funkcjonować. Okazało się także że po pierwszej zmianie fuse bitów mikrokontroler był ok, jedynie kwarc został źle przylutowany. Ostatnia zmiana jaką wprowadziłem (naprowadzony przez kaczepę) to zlikwidowanie dwóch linijek.


ldi temp,0x40
sts UCSR0A,temp

Temat uważam za rozwiązany. Chyba że ktoś ma jeszcze jakieś pytania.
Pozdrawiam.
Adam_Z

transmisja UART AVR > PC, w terminalu 00 C0 C0 00 itd

Post #1

Post #2

Post #3

Post #4

Post #5

Post #6

Post #7

Post #8

Post #9

Post #10

Post #11

Post #12

Post #13

Post #14

Post #15

Post #16

Post #17

Post #18

Post #19

Post #20

Post #21

Post #22

Post #23

Post #24

Podsumowanie tematu