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

Pojemnosc rejestru przesuwnego w USART Atmega 16

wilk125 20 Sie 2009 12:14 3873 14
REKLAMA
  • #1 6912897
    wilk125
    Poziom 23  
    Witam
    Jaka jest pojemnosć, rejestru przesuwnego w USART w Atmega 16, wysyłam dane do atmegi i wychodzi mi, że rejestr ma pojemnośc 4 bajtów, pozniej jak nie odczytam UDR to znaki w rejestrze sa nadpisywane. Czy rejestr faktycznie ma pojemnośc 4 bajtów?
  • REKLAMA
  • #2 6913092
    mirekk36
    Poziom 42  
    Najciekawsze jest to - jak ty to obliczyłeś czy tam wydedukowałeś, że UDR to 4 bajty ? ;)

    oczywiście, że to 1 bajt (w uproszczeniu mówiąc, bo wiadomo, że ramka może mieć 9bitów i kilka bitów startu i stopu) - nie mniej jednak gdy używasz ramki np: 8,n,1 - to masz 1 bajt

    - a to, że przy odczycie zauważasz "zjawisko" nadpisywania się przylatujących znaków - to tylko wina tego, że nie stosujesz do obsługi RS232 przerwań ... przez co twoja procedura(-y) nie wyrabia się z odbiorem i UDR jest co chwilę nadpisywany kolejnym nadlatującym znakiem
  • #3 6913316
    wilk125
    Poziom 23  
    wiem ze UDR to jeden bajt, tylko zanim znak trafi do UDR to jest w tak zwanym rejestrze przesuwnym i chodziło mi o pojemnosc tego rejestru. A jak to sprawdzilem, odpalilem w debugu atmege i w petli czytałem odebrany bajty jeden krok petli to jeden odczytany bajt, z komputera wysłalem np. dwa zanki w momencie gdy atmega byla zatrzymana, potem kontunuacja pracy atmegi i odbieram jeden i drugi znak. Gdy w taki sam sposób wysłałem 4 zanki, to tez odebral wszystkie, natomiast jak wysłałem 5 znaków i wiecej to odebrał 3 pierwsze i ostatni wysłany, po tym wywnioskowałem, ze atmega jest w stanie odebrac 4 zanki, które przechowuje w rejestrze przesuwnym zanim je kolejno odczytam z rejestru UDR. Jeśli nadejdzie więcej niż 4 znaki, a ja nie zacznę ich odbioru to będe je tracił.

    dokładnie chodzi o tej rejestr
    Pojemnosc rejestru przesuwnego w USART Atmega 16
  • #4 6913357
    mirekk36
    Poziom 42  
    wilk125 napisał:
    ..... Gdy w taki sam sposób wysłałem 4 zanki, to tez odebral wszystkie, natomiast jak wysłałem 5 znaków i wiecej to odebrał 3 pierwsze i ostatni wysłany, po tym wywnioskowałem, ze atmega jest w stanie odebrac 4 zanki zanim je kolejno odczytam z rejestru UDR.


    nie, nie, nie - ;) nie wiem co to za debug ani jak on działa (widać u ciebie zrobił sobie jakiś mały pooling) - ale w rzeczywistym układzie nie ma takich dziwnych zachowań. Do UDR wpada znak wczytany z rejestru przesuwnego po zakończeniu transmisji ramki i czeka sobie na odczytanie. Jeśli go nie odczytasz - a w międzyczasie nadleci drugi znak - to przykryje on ten pierwszy itd itd itd

    dlatego najlepiej zawsze wykorzystywać system przerwań USART aby spokojnie i bez przeszkód wyrabiać się z operacjami odbioru - a do tego można wtedy zastosować własny bufor cykliczny - odbiorczy i wtedy wszystko działa - miodzio ;)
  • #5 6913500
    wilk125
    Poziom 23  
    Debug jest na JTAG ICE w AVR Studio
    Tak to przeanalizowałem i juz mi wyszło jakim cudem zaden z wysłanych 4 bajtów się nie starcił mimo tego ,ze odczytany był tylko jeden:
    Pierwszy odczytany bajt leci do mojej zmiennej, następnie drugi wpada do UDR, trzeci do rejestru przesuwnego, a czwarty jeszcze siedzi w Data Recovery, no i w sumie nazbierało sie 4 bajty
  • REKLAMA
  • #6 6913540
    szelus
    Poziom 34  
    Data Recovery to raczej dotyczy pojedynczego bitu. W każdym razie, nawet jak z testów wychodziłoby inaczej, to w programie nigdy bym nie liczył na więcej, niż podwójne buforowanie (rejest przesuwajacy + UDR) gwarantowane w specyfikacji.
  • #7 6913951
    BoskiDialer
    Poziom 34  
    atmega16.pdf napisał:
    A second Buffer Register has been added. The two Buffer Registers operate as a
    circular FIFO buffer.
    Therefore the UDR must only be read once for each incoming
    data! More important is the fact that the Error Flags (FE and DOR) and the 9th data
    bit (RXB8) are buffered with the data in the receive buffer. Therefore the status bits
    must always be read before the UDR Register is read. Otherwise the error status
    will be lost since the buffer state is lost.
    • The receiver Shift Register can now act as a third buffer level. This is done by
    allowing the received data to remain in the serial Shift Register (see Figure 69) if the
    Buffer Registers are full, until a new start bit is detected. The USART is therefore
    more resistant to Data OverRun (DOR) error conditions.
    The following control bits have changed name, but have same

    Czyli przy odbieraniu dwa bajty mogą się znaleźć w "UDR (receive)" a trzeci w buforze przesuwającym. Każdy kolejny przychodzący bajt będzie odrzucany aż do opróżnienia rejestru przesuwającego lub będzie powodował utratę trzeciego bajtu (nie chce mi się wczytywać a nie sprawdzałem).
  • REKLAMA
  • #8 6915135
    rpal
    Poziom 27  
    wilk125 napisał:
    Debug jest na JTAG ICE w AVR Studio
    Tak to przeanalizowałem i juz mi wyszło jakim cudem zaden z wysłanych 4 bajtów się nie starcił mimo tego ,ze odczytany był tylko jeden:
    Pierwszy odczytany bajt leci do mojej zmiennej, następnie drugi wpada do UDR, trzeci do rejestru przesuwnego, a czwarty jeszcze siedzi w Data Recovery, no i w sumie nazbierało sie 4 bajty

    Zwróć uwagę że czas potrzebny dla twojej reakcji i załapania o co chodzi przy debugowaniu JTAG-iem to przynajmniej 10-20 sekund natomiast dane napływajace do UART-a to idą w ułamki sekund. Debugowanie w czasie rzeczywistym nie przyniesie tobie wiele pożytku bo za nim "zalapiesz" będzie już po danych. Jeśli proces możesz zatrzymać tak jak to zachodzi podczas pracy krokowej to jest wszystko OK natomiast dane wpływające do UART są poza twoją kontrolą. Więc w tymprzypadku nei jest to rozwiązanie szczęśliwe, no chyba że poprzez okno terminala wysyłasz do UART-a dane bit po bicie wpisując je z ręki. Wówczas to ma jakiś sens.
  • #9 6915926
    wilk125
    Poziom 23  
    BoskiDialer napisał:

    Czyli przy odbieraniu dwa bajty mogą się znaleźć w "UDR (receive)" a trzeci w buforze przesuwającym. Każdy kolejny przychodzący bajt będzie odrzucany aż do opróżnienia rejestru przesuwającego lub będzie powodował utratę trzeciego bajtu (nie chce mi się wczytywać a nie sprawdzałem).


    Wiec jest tak jak mowilem tylko ,że w zamiast Data Recovery, 2 bajt jest w UDR. kolejny przychodzacy bajt nie bedzie odrzucany tylko spowoduję utratę tego poprzedniego (nadpisze go)

    rpal napisał:
    chyba że poprzez okno terminala wysyłasz do UART-a dane bit po bicie wpisując je z ręki. Wówczas to ma jakiś sens.


    Dane wysyłam bajt po bajcie wpisując z ręki i dzieki temu mozna zaobserwować ile bajtów jest w stanie przyjac atmega bez odczytania UDR, no i wychodzi ,że 3
  • #10 6919522
    rpal
    Poziom 27  
    Jakbyś nie kombinował to UART zmieści na raz 3 bajty reszta sie nadpisze. Odsyłam do lektury noty katalogowej tam dowiesz się czemu :) Koledzy radzą użyć przerwań do odczytu i to najlepszy pomysł jaki można podsunąć.
  • #11 7052452
    elkopyto
    Poziom 12  
    USART atmega16 posiada podwójny buffor odbiorczy ("two Buffer Registers operate as a circular FIFO buffer") oraz pojedynczy rejestr odbiorczy przesuwny ("receiver Shift Register can now act as a third buffer level"). W każdym rejestrze mieści się jeden bajt więc w układzie można przetrzymać 3 odebrane bajty.
  • #12 7076134
    epoxer
    Poziom 14  
    elkopyto nie wiem jak umieścisz te 3 bajty ;D mając dostęp do jedynie do rejestru danych UDR :)

    To co napisałeś... ;] że 2 bufory odbiorcze... ;] hmm a ja widzę po jednym na wejście i wyjście...

    Pojemnosc rejestru przesuwnego w USART Atmega 16

    co do Rejestru przesuwnego też są 2 :)
    Ale one uzależnione są od UDR

    Tak więc przy przesyłaniu danych metodą full duplex (odbieranie i nadawanie w jednym czasie) mamy do dyspozycji jedynie 2 rejestry 1 bajtowe UDR
    I więcej tam nie upchamy :)
    Pozdr.
  • REKLAMA
  • #13 8454878
    elkopyto
    Poziom 12  
    To proszę wysłać sobie 3 bajty z urządzenia podłączonego do mikrokontrolera i sprawdzić ile bajtów można odczytać przy pomocy rejestru UDR.
    "Podwójny rejestr" nie znaczy że są dwa rejestry odbiorcze, ale że jest on dwubajtowy.
  • #14 8456972
    namlooc
    Poziom 15  
    pomoge odgrzac kotleta :)

    [quote="mirekk36"]
    wilk125 napisał:

    dlatego najlepiej zawsze wykorzystywać system przerwań USART aby spokojnie i bez przeszkód wyrabiać się z operacjami odbioru - a do tego można wtedy zastosować własny bufor cykliczny - odbiorczy i wtedy wszystko działa - miodzio ;)


    Staram sie napisac program z analiza przewidzianych potwierdzen i nie przewidzanych zdarzen w module GSM(sms, ring itd.). W jaki sposob skonstrulowac bufor cykliczny i parsowanie odpowiedzi ? Moze zastosowac nieskonczony bufor, a odczytane i przeanalizowane dane kasowac i przesuwac wszystko w lewo ? Jak sie za to zabrac ?

    Kazda odpowiedz modemu wyglada tak:
    <CL><LF>odpowiez<CL><LF>
    . Zdarza sie ze sa dwie odpowiedzi.
  • #15 8457029
    gaskoin
    Poziom 38  
    namlooc napisał:


    Staram sie napisac program z analiza przewidzianych potwierdzen i nie przewidzanych zdarzen w module GSM(sms, ring itd.). W jaki sposob skonstrulowac bufor cykliczny i parsowanie odpowiedzi ? Moze zastosowac nieskonczony bufor, a odczytane i przeanalizowane dane kasowac i przesuwac wszystko w lewo ? Jak sie za to zabrac ?


    W przerwaniu zawartość rejestru UDR zapisuje się w tablicy i zwiększa się wskaźnik na jej komórkę. W pętli głównej sprawdza się tą tablicę po kolei i odpowiednio reaguje - to taki opis z grubsza :P
REKLAMA