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

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

Voldum 20 Gru 2019 21:25 915 22
  • #1 18351821
    Voldum
    Poziom 5  
    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.
  • #2 18351864
    BlueDraco
    Specjalista - Mikrokontrolery
    Przy braku danych funkcja USART_Get_Rx_Byte zwraca zera, którymi zamazujesz co się tylko da.
  • #3 18351893
    Voldum
    Poziom 5  
    W jaki sposób zablokować ten błąd nadpisywania danych, jest na to jakiś prosty sposób?
  • #4 18352046
    MOBIUS19
    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.
  • #5 18355070
    Voldum
    Poziom 5  
    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 / C++
    Zaloguj się, aby zobaczyć kod
  • #6 18355075
    MOBIUS19
    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?
  • #7 18355090
    Voldum
    Poziom 5  
    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 / C++
    Zaloguj się, aby zobaczyć kod
  • #8 18355128
    MOBIUS19
    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?
  • #9 18355140
    Voldum
    Poziom 5  
    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
  • #10 18355170
    MOBIUS19
    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.
  • #11 18355187
    Voldum
    Poziom 5  
    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?
  • #12 18355195
    MOBIUS19
    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.
  • #13 18355199
    Voldum
    Poziom 5  
    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 / C++
    Zaloguj się, aby zobaczyć kod



    Bufor cykliczny ATtiny4313 - brak możliwości pobrania danych
  • #14 18355774
    ex-or
    Poziom 28  
    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.
  • #15 18355788
    Voldum
    Poziom 5  
    Niestety link do dokumentacji jest już nieczynny. Zabieram się za próbę z tą biblioteką i zobaczymy czy uda się coś wskórać.
  • #16 18355844
    ex-or
    Poziom 28  
    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.
  • #17 18355853
    StaryVirus_e_Wiarus
    Poziom 21  
    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?
  • #18 18355868
    Voldum
    Poziom 5  
    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 / C++
    Zaloguj się, aby zobaczyć kod


    Oraz efekt w terminalu:
    Bufor cykliczny ATtiny4313 - brak możliwości pobrania danych
  • #19 18355887
    ex-or
    Poziom 28  
    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.
  • #20 18355984
    Voldum
    Poziom 5  
    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 / C++
    Zaloguj się, aby zobaczyć kod
  • #21 18356041
    ex-or
    Poziom 28  
    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
  • #22 18356136
    Voldum
    Poziom 5  
    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 / 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 / C++
    Zaloguj się, aby zobaczyć kod


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