Elektroda.pl
Elektroda.pl
X
Please add exception to AdBlock for elektroda.pl.
If you watch the ads, you support portal and users.

[Solved] [C, AVR] UART TX przerwanie na koniec nadawania

x-fly 21 Sep 2022 14:52 474 14
  • #1
    x-fly
    Level 10  
    Cześć, czytam DS'a do Atmegi48 i trafiłem na takie zagadnienie do wyjaśnienia.
    Code: c
    Log in, to see the code

    Mam również aktywne przerwanie
    Code: c
    Log in, to see the code

    W programie robię tak
    Code: c
    Log in, to see the code

    Czy przerwanie TX będzie zgłoszone 3x ?
  • #2
    tmf
    Moderator of Microcontroller designs
    x-fly wrote:
    Czy przerwanie TX będzie zgłoszone 3x ?

    Nie, będzie zgłoszone tylko raz - po opróżnieniu bufora nadajnika.
  • #3
    x-fly
    Level 10  
    :)
    tmf wrote:
    Nie

    Zgadza się, zrobiłem znacznik na osobnym pinie i w analizatorze wyszło że tylko raz.. ALE DLACZEGO ?

    Przecież w pewnych momentach bufor nadawczy jest pusty -> warunek while to gwarantuje. Czy to chodzi o to że proc po prostu nie ma chwili żeby sprawdzić pustość bufora bo nadawanie idzie ciągiem ?

    Naszły mnie obawy że może przypadkiem u mnie tak jest dlatego pytam bo przypadkowość działania programu to mnie jednak nie pociesza.

    Jakby co to chcę to przerwanie użyć do przejścia układu MAX485 z powrotem w stan nasłuchiwania po nadaniu np 12 bajtów.
  • #4
    tmf
    Moderator of Microcontroller designs
    x-fly wrote:
    Zgadza się, zrobiłem znacznik na osobnym pinie i w analizatorze wyszło że tylko raz.. ALE DLACZEGO ?

    Dlatego, że przerwanie jest zgłaszane w chwili, kiedy jest pusty rejestr nadajnika oraz bufor nadajnika. Ponieważ ładujesz 3 bajty, więc dopiero po ich przesłaniu ten warunek jest spełniony.
  • #5
    x-fly
    Level 10  
    tmf wrote:
    przerwanie jest zgłaszane w chwili, kiedy jest pusty rejestr nadajnika oraz bufor nadajnika

    A rejestr nadajnika i bufor nadajnika to co innego ?? Jaką wielkość ma w takim razie bufor? Jak zrobię w pętli 200 razy nadanie znaku jeden za drugim to bufor się nie wyczerpie /zapcha?

    Czyli wrzucam jeden znak za drugim do bufora komendą UDR= a proc przerzuca to po kolei do rejestru nadawczego i wykonuje i opróżnia sukcesywnie w ten sposób bufor ? Mniej więcej to by się zgadzało że wystawiane jest przerwanie po wypróżnieniu się bufora. Jaki jest duży ten bufor? Jestem w stanie go przepełnić? Czy może jest to sprzętowo dopasowane że F_CPU jest na tyle duże a BAUD względem niego na tyle mniejsze (jest przecież wzór) że atmuśka daje radę się wyrabia i nigdy bufora nie zamulę.

    Jak to jest zorganizowane ?
    Proszę w wolnej chwili o kapke rozjaśnienia.
    Pozdrawiam
  • Helpful post
    #6
    Menuet
    Level 18  
    Witam,
    Bufor nadawczy jest o rozmiarze jednego wysyłanego znaku (tak na prawdę jest to rejestr przesuwny samego UARTu). Zapisując dane do UDR jeśli bufor nadawczy jest pusty to od razu jest przepisywana do niego dana i rozpoczęcie transmisji. W innym przypadku jeśli w UDR są nowe dane a nie wszystko zostało wysłane to sprzęt czeka aż się wyślę i przepisze dane do bufora. W tym przypadku nie jest generowane przerwanie, bo bufor tak na prawdę nigdy nie jest pusty (zapisany od razu nową wartością). Zapisując wiele danych do UDR, jedna po drugiej zostanie wysłana tylko ostatnia zapisana wartość lub wartość występująca tam w chwili przepisywania danych do bufora nadawczego.

    Pozdrawiam,
    Menuet
  • #7
    x-fly
    Level 10  
    Menuet wrote:
    jeśli w UDR są nowe dane a nie wszystko zostało wysłane to sprzęt czeka aż się wyśle
    Czyli to jest ten warunek while

    Menuet wrote:
    nie jest generowane przerwanie, bo bufor tak na prawdę nigdy nie jest pusty
    Czyli procesor między tymi dwoma liniami
    Code: c
    Log in, to see the code
    nie jest w stanie sprawdzić pustości.

    Jak jest zrealizowane sprawdzanie pustości bufora ?
    Jakiś osobny układzik jest w Atmedze? Na jakiej podstawie on to zaczyna sprawdzać? Jeżeli między te dwie linie kodu włożę delaja np 500ms to wtedy wystąpi przerwanie ? (oczywiście zakładając że wcześniej UDR coś w sobie już miał) Kiedy proc znajduje ten moment żeby sprawdzić pustość? Przecież kod w programie wykonywany jest cały czas i Atmega załóżmy nie ma ani chwili spokoju z mojej strony więc sprawdzanie pustości musi być niezależne..

    UWAGA
    Zrobiłem serię testów
    Wysłałem 3x pod rząd to samo czyli
    Code: c
    Log in, to see the code
    wyszło że do tej wartości delaja przerwanie będzie zgłoszone tylko raz po trzecim UDRze, a tuż zaraz powyżej 250us zaczyna być zgłaszane 3x

    Jak i kiedy Atmega sprawdza pustość bufora nadawczego? A jak zamiast delaja wstawię coś innego żeby to nie były nop'y to będzie ten sam efekt ?
  • Helpful post
    #8
    tmf
    Moderator of Microcontroller designs
    Menuet wrote:
    Bufor nadawczy jest o rozmiarze jednego wysyłanego znaku (tak na prawdę jest to rejestr przesuwny samego UARTu).

    To nie jest prawda. Nadajnik składa się z rejestru nadajnika (1 bajt) oraz w zależności od procesora 1-2 bajtów bufora.
    Dane zapisywane są do rejestru nadajnik jeśli jest on pusty i od razu nadawane, jeśli jest pełny to do bufora, skąd potem sprzętowo trafiają do rejestru nadajnika. W efekcie zazwyczaj 1-3 bajtów można wpisać do UART od razu, czekanie następuje dopiero po przekroczeniu tej liczby i zapełnieniu bufora.
    Przerwanie jest generowane w chwili, kiedy rejestr nadajnika oraz bufory są puste. Czylu UART nie ma nic do wysłania.
    x-fly wrote:
    Jak jest zrealizowane sprawdzanie pustości bufora ?
    Jakiś osobny układzik jest w Atmedze? Na jakiej podstawie on to zaczyna sprawdzać?

    Właśnie tak jak w pokazanym kodzie. Odpowiednia flaga sygnalizuje, że coś jeszcze można upchnąć.
    x-fly wrote:
    Jeżeli między te dwie linie kodu włożę delaja np 500ms to wtedy wystąpi przerwanie ?

    Wystąpi jeśli w tym casie wszystko zostanie nadane (zależy to od szybkości transmisji).
    x-fly wrote:
    Jak i kiedy Atmega sprawdza pustość bufora nadawczego? A jak zamiast delaja wstawię coś innego żeby to nie były nop'y to będzie ten sam efekt ?

    Masz od tego odpowiednią flagę w rejestrze stanu - while (! (UCSR0A & (1 << UDRE0))); - to właśnie jest odpowiedzialne za sprawdzanie.
  • Helpful post
    #9
    ex-or
    Level 27  
    Przerwania nadawcze są dwa - TX Complete oraz UDRE empty. Przerwanie "USART_TX_vect" to przerwanie Complete generowane flagą TXCIE lub (w wypadku wyłączonego przerwania) testowane flagą TXC. Natomiast flaga UDRE w powiązaniu z flaga UDRIE generuje przerwanie Empty.
  • #10
    x-fly
    Level 10  
    ☺ jasna dupa i 100 milicjantów, ale się narobiło, czyli przerwanie TX_vect nie jest związane tylko z pustym rejestrem UDR ale też z pustym buforem nadawczym, to by wyjaśniło sprawę że dopiero wypróżnione oba wywołują TX_vect no i moje obawy że pusty przez moment UDR wcale nie musi wywołać od razu TX_vect bo bufor może coś jeszcze trzymać.

    Jeszcze jedno, o ile nie jest to zbyt skomplikowane. Jak te flagi działają. Procesor je przestawia w wolnej chwili czy jest to niezależne od obciążenia moim programem. Dałbym radę tak zamęczyć Atmulkę że np flaga TXC nigdy by się nie zmieniła lub z dużym opóźnieniem?
  • #11
    mpier
    Level 28  
    Witam
    pewnie ktoś powinien na początku napisać, żebyś zajrzał do dokumentacji, ale chyba nie jest za późno. Zajrzyj do dokumentacji. Tam są opisane te flagi i przerwania o które pytasz.

    Jeśli utkniesz w przerwaniu, to może uda Ci się "zamulić" mikrokontroler, tak, że nie będzie mógł wykorzystać ustawionej flagi, ale też nie konieczne.

    "Atmulki" nie zmęczysz.

    Pozdrawiam.
  • #12
    x-fly
    Level 10  
    Zacząłem ten temat od tego że właśnie czytam DS'a (nie po raz pierwszy) ale to prawda że gdybym się bardziej wczytał to co nieco o tych rejestrach bym doczytał choć nie tak jak to przedstawili koledzy tmf i ex-or którym dziękuje za chęci do rozwiewania różnych zagadnień. Być może nie tylko ja z tego skorzystam. Poza tym życzę wszystkim owocnych i ciekawych projektów.

    Interesowało mnie jeszcze jak te flagi są skonstruowane od strony sprzętowej, czy to są po prostu układziki /tranzystory które zmieniają swoje stany = bity = flagi niezależnie od programu głównego.

    Moje Atmusie bidaczki jedne ☺ Tak wiele osób przesiadłszy się na SUVa potrafi spoglądać na nie jak na malucha. A ja się ich nie wyprę i jestem z nich dumny ☺ Takie trochę pokraczki ale lubię je.

    Pozdrawiam
    Michał
  • #13
    tmf
    Moderator of Microcontroller designs
    x-fly wrote:
    Interesowało mnie jeszcze jak te flagi są skonstruowane od strony sprzętowej, czy to są po prostu układziki /tranzystory które zmieniają swoje stany = bity = flagi niezależnie od programu głównego.

    Od strony sprzętowej to pewnie są przerzutniki RS. Ale dla programisty to bez znaczenia. Dla ciebie ważne jest, że flaga jest sprzętowo, a więc niezależnie od wykonywanego programu ustawiana w chwili zajścia określonego zdarzenia. Program może jej stan odczytać w dowolnej chwili.
  • #14
    x-fly
    Level 10  
    tmf wrote:
    dla programisty to bez znaczenia
    I tak i nie. Łatwiej pewne sprawy ogarnąć jak ma się pełniejsze pojęcie o danym zjawisku. Jakoś tak lżej człowiekowi na duszy jak wie jak coś działa a nie tylko ŻE działa. Nie dotyczy to wszystkich tematów bo bym zwariował. Trochę wiedzy trochę rozrywki i do przodu ☺

    Spokojnego dzionka,
    Jeszcze raz pozdrawiam i do usłyszenia
    Michał
  • #15
    x-fly
    Level 10  
    Muszę wpisać jak rozwiązałem problem:
    Fachowcy udzielili dość wyczerpujące odpowiedzi,
    dziękuje pozdrawiam