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

[Rozwiązano] Bufor cykliczny ATtiny4313 - brak możliwości pobrania danych

20 Gru 2019 21:25 552 22
  • Poziom 3  
    Witam,

    Od kilku dni usilnie próbuję zmusić ATtiny do odbierania danych, które przekazuję poprzez terminal (RealTerm). Niestety, próby uruchomienia bufora cyklicznego kończą się fiaskiem. Za każdym razem program przy próbie przekazania danych wysyła dane, które niczym nie przypominają bajtów które próbuję przesłać. Pojedyncze znaki typu: b, v, a wysyłam w celu debugowania programu, ułatwia mi to znalezienie miejsca w którym program się blokuje.
    Z góry dziękuję za każdą pomoc i zainteresowanie.
  • Specjalista - Mikrokontrolery
    Przy braku danych funkcja USART_Get_Rx_Byte zwraca zera, którymi zamazujesz co się tylko da.
  • Poziom 3  
    W jaki sposób zablokować ten błąd nadpisywania danych, jest na to jakiś prosty sposób?
  • Poziom 11  
    Użyj dodatkowej zmiennej, w której będziesz zwracał informację czy odebrano bajt czy nie. Możesz zwracać int16_t, jeśli nie ma znaku zwracasz -1.
  • Poziom 3  
    Przy próbie odczytu danych przy wykorzystaniu podstawowej funkcji z noty katalogowej USART_Recive, nie jestem w stanie odebrać żadnego znaku przesłanego z RealTerm. Dopóki nie umieszczę przed pętlą while(1) pojedynczego wywołania funkcji USART_Transmit(), transmisja w ogóle nie rusza. A jeśli już ją umieszczę to przy próbie odczytu dostaję tylko błędne znaki na terminalu zamiast np. wartości 65.

    Kod: c
    Zaloguj się, aby zobaczyć kod
  • Poziom 11  
    W kodzie czekasz na dwa znaki, wypełniasz tablicę Data natomiast wysyłasz znaki do napotkania kodu 0. Nie czujesz, ze coś tu jest nie tak?
  • Poziom 3  
    Racja, frustracja nie pomaga mi przy myśleniu. Jednak dopóki nie uruchomię choć raz funkcji USART_Transmit(), transmisja stoi kompletnie nic się nie dzieje.

    Kod: c
    Zaloguj się, aby zobaczyć kod
  • Poziom 11  
    Voldum napisał:
    Za każdym razem program przy próbie przekazania danych wysyła dane, które niczym nie przypominają bajtów które próbuję przesłać.

    Gdzie i jak ustawiasz F_CPU?
  • Poziom 3  
    F_CPU jest zdefiniowane w ustawieniach projektu (korzystam z Atmel Studio). Efekt uruchomienia kodu jest taki jak na obrazku poniżej.
    Bufor cykliczny ATtiny4313 - brak możliwości pobrania danych


    Pomimo iż uruchamiam funkcję USART_Send_String tylko raz w terminalu dostaję napis TEST w taki sposób jakby był on w pętli nieskończonej.
    Jeśli w RealTerm wyślę choć jeden znak na terminalu dostaje same krzaki. Bufor cykliczny ATtiny4313 - brak możliwości pobrania danych
  • Poziom 11  
    Wysyłanie "TEST" jest poza pętlą główna, wygląda na to, ze CPU jest resetowany. Sprawdź w debugerze co jest przyczyna resetu.
  • Poziom 3  
    Niestety nie mam debuggera, ale w przerwaniu odbywa się cykliczne generowanie sygnału PWM, który widzę że ciągle pracuje.
    Więc to chyb nie reset procka?
  • Poziom 11  
    Voldum napisał:
    Niestety nie mam debuggera, ale w przerwaniu odbywa się cykliczne generowanie sygnału PWM, który widzę że ciągle pracuje.
    Więc to chyb nie reset procka?

    To skąd cykliczny napis TEST? Sprawdź oscyloskopem czy to faktycznie wychodzi z AVR.
  • Poziom 3  
    Jak na złość oscyloskop zostawiłem na stancji. Jeszcze raz sprawdzę kod i umieszczę rezultat.

    Dodano po 5 [minuty]:

    Bufor cykliczny ATtiny4313 - brak możliwości pobrania danych

    Problemem było umieszczenie cnt++ wewnątrz pętli for. Tablica miała rozmiar 2 elementów a ja ją dodatkowo inkrementowałem co prawdopodobnie powodowało błędy. Jednak teraz nic się nie dzieje w terminalu przy próbie nadania i odczytu danych.

    Dodano po 3 [godziny] 3 [minuty]:

    Korzystając z rady BlueDarco zmieniłem nieco pętlę główną jednak w wyniku tych zmian program zatrzymuje się całkowicie.

    Jeśli chodzi o wysyłanie danych na terminal to nie ma z tym najmniejszego problemu. Aktualnie przerobiłem trochę kod i wygląda on następująco:
    Kod: c
    Zaloguj się, aby zobaczyć kod



    Bufor cykliczny ATtiny4313 - brak możliwości pobrania danych
  • Poziom 23  
    Nic się nie pojawi bo funkcje UART_Transmit/Receive są oparte na polingu flag UDRE/RXC. Jednocześnie włączone są przerwania TXC/RXC, oraz włączona globalna flaga przerwań. Jeśli dochodzi do odebrania znaku procedura obsługi przerwania natychmiast przejmuje kontrolę i gasi flagę nie dając funkcji UART_Receive wyjść z pętli.
    Co do tej niby "biblioteki" UART - wywalił bym to "coś" w diabły i wziął coś sprawdzonego np. http://www.peterfleury.epizy.com/uartlibrary.zip (dokumentacja: http://www.peterfleury.epizy.com/doxygen/avr-gcc-libraries/group__pfleury__uart.html ). Kod stary ale jary.
  • Poziom 3  
    Niestety link do dokumentacji jest już nieczynny. Zabieram się za próbę z tą biblioteką i zobaczymy czy uda się coś wskórać.
  • Poziom 23  
    Voldum napisał:
    while(Data_Flag != 13)
    {
    for(uint8_t cnt = 0; cnt < 8; cnt++)
    {
    USART_PutInt(Data_Buffer[cnt], 10);
    }
    }


    Ta pętla w większości wypadków będzie nieskończona. Jeśli znaku o kodzie 13 można się spodziewać w tablicy to sprawdzianie trzeba przenieść do testu pętli for.
  • Poziom 13  
    Cześć
    Zapytam. Czy w terminalu nie trzeba czasem ustawić odbioru i nadawania z bitem parzystości, który zainicjowałeś w kodzie do USART'a?
  • Poziom 3  
    Niestety pomimo wgrania przykładowego kodu z biblioteki wciąż nie jestem w stanie uzyskać danych powrotnych z bufora, po raz kolejny otrzymuje liczbę 134 i znak CR w terminalu. W przypadku gdy wysyłam dane przez terminal jedynie przez ułamek sekundy zauważam pojawienie się danych jednak przypominają one krzaki...

    Kod programu:
    Kod: c
    Zaloguj się, aby zobaczyć kod


    Oraz efekt w terminalu:
    Bufor cykliczny ATtiny4313 - brak możliwości pobrania danych
  • Poziom 23  
    Procek ustawicznie się resetuje. Wyrzuć funkcje PWM_init i Timer1_init
    Attiny4313 ma tylko 256B RAM, wiec na pewno trzeba zmniejszyć wielkość buforów kołowych, a może nawet w ogóle zrezygnować z buforowanego UART. Pytanie czy w pozostałym kodzie nie ma czegoś pamięciożernego i nie następuje przepełnienie stosu.
  • Poziom 3  
    Niestety efekt jest wciąż ten sam, cały czas dostaje wartość 134 na terminalu. Nie mam pojęcia co innego mogło by go resetować.

    Dodano po 9 [minuty]:

    Aktualnie wszystko zajmuje zaledwie 27% pamięci SRAM, więc raczej nie dochodzi do nadpisywania danych. Jedynym zasobożernym kodem jest ten od USARTA.

    EDIT:
    Obserwując efekt PWM można by stwierdzić, że nie zachodzi resetowanie procesora, sygnały wydają się być generowane o odpowiedniej długości.

    Umieszczam również pełen kod programu:

    Kod: c
    Zaloguj się, aby zobaczyć kod
  • Poziom 23  
    W kodzie nic nie widać. Być może problem leży w przejściówce UART, programie RealTerm lub jeszcze gdzie indziej. Ciagłe resety mogą byc spowodowane przez watchdog, w kodzie nic nie ma ale moze by włączony fuse bitami. Oczywiście jeśli nie włączałes to same się nie włączyły a więc to hipotetyczna możliwość. To samo z układem BOR - może resetować µC przy wahaniach napięcia ale trzeba go najpierw włączyć. No i twierdzisz, że restów nie ma bo PWM dział. Z drugiej strony kiedy wstawić uart_puts przed while to resety jakby są. Ot, tajemnica Fatimska. Może przejściówka serial ma podłączoną linię sterującą pod pin reset a program terminalowy wykonuje jakiś, zamierzony lub nie, sprzętowy flow-control i chcąc niechcąc resetuje µC
  • Poziom 3  
    W celu upewnienia się że to nie wina sprzętu przerzuciłem sam kod obsługi UARTA na sterownik gdzie mam ATMega328P. Jednak efekt jest wciąż ten sam, po uruchomieniu transmisji w terminalu widoczne są napisy wysyłane przed pętlą while a gdy tylko wyślę np. znak ascii 65, dostaję komunikat o przepełnieniu bufora.

    Być może schemat układu będzie w stanie powiedzieć coś jeszcze:
    Bufor cykliczny ATtiny4313 - brak możliwości pobrania danych


    Efekt uruchomienia programu:
    Bufor cykliczny ATtiny4313 - brak możliwości pobrania danych


    Efekt wysłania ASCII: 65
    Bufor cykliczny ATtiny4313 - brak możliwości pobrania danych


    Kod z main.c

    Kod: c
    Zaloguj się, aby zobaczyć kod


    EDIT_2:
    Powróciłem do starego kodu, wstępnie umieszczam dane w buforze przy pomocy funkcji PutC, elementy tablicy których znam kody ASCII. Jednak na terminalu pojawiają się oprócz tego dodatkowe znaki, a po wykonaniu pętli while(1) cały program zatrzymuje się oraz inne przerwania również.

    Kod: c
    Zaloguj się, aby zobaczyć kod


    Bufor cykliczny ATtiny4313 - brak możliwości pobrania danych
  • Poziom 3  
    Jeden z układów MAX485 blokował odbiór danych na linii Rx. Modyfikacja układu pozwoliła na uruchomienie transmisji.