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

[AT90CAN128][C]UART - błędy w transmisji

kasprzak 25 Kwi 2011 14:15 2602 10
REKLAMA
  • #1 9437815
    kasprzak
    Poziom 10  
    Witam,
    mam problem z prostą obsługą RS232. Występują błędy transmisji (screen z błędami w trzecim poście). Nie wiem dlaczego. Kable sprawdzone 3x. Może coś przeoczyłem w dokumentacji, ale sprawdzałem kilkakrotnie. Podobnie z ustawieniami płyty testowej. Inne programy przykładowe jak sterowanie zapalaniem diód chociażby sprawnie śmigają po kontrolerze.

    UART ustawiony zgodnie z opisem (wariant 1 tzn. uruchomiony UART0, UART1 nieaktywny, wykorzystane piny Tx0 - Pin 2 Rx0 - Pin 3 )

    Rezonator ustawiony jako zewnętrzny 8MHz.

    :arrow: Plik PDF z datasheetem od AT90CAN128: http://atmel.com/dyn/resources/prod_documents/doc7679.pdf
    :arrow: Plik PDF z user guidem płytki testowej z kontrolerem: http://www.efo.ru/ftp/pub/atmel/_C51_and_AVR_..._CAN/CAN_CD_June_2005/pdf/DVK90CAN1_Guide.pdf

    Do sprawdzenia portu używam Docklight'a.

    Kod: text
    Zaloguj się, aby zobaczyć kod
  • REKLAMA
  • #2 9437819
    tadzik85
    Poziom 38  
    Kod: C / C++
    Zaloguj się, aby zobaczyć kod
    to zwraca ci poprawną wartość? sprawdź wpisując wartość na sztywno w datashecie powinna być odpowiednia tabelka.
  • REKLAMA
  • #3 9438043
    kasprzak
    Poziom 10  
    Tak, sprawdzałem.
    Obliczałem wg tej tabelki z wzorami (wartosc w typie calkowitym: 51):
    [AT90CAN128][C]UART - błędy w transmisji,
    zatem potwierdza się ze sztywno podanymi w tabeli:
    [AT90CAN128][C]UART - błędy w transmisji

    a tutaj screen z docklight'a z błędami w transmisji.
    [AT90CAN128][C]UART - błędy w transmisji

    Dodam, że jak resetuję kontroler przyciskiem RST na płycie to wychodzą śmieci, natomiast jak odpinam i podłączam zasilanie (albo pstrykając switchem od zasilania płyty) to linia z main'a:
    uart_puts("AT90CAN128 RS-232 test\r\n");

    wysyła się poprawnie.

    Wewnątrz while(), czyli procedura odesłania tego co przysłane, odsyła to z błędami - po zresetowaniu pstrykiem pierwsze dane przychodzą dobrze, czasem z jednym błędem, natomiast następne wysyłanie z PC na kontroler celem uzyskania takiej samej treści odpowiedzi kończy się ze zwiększaniem błędów transmisji. W przypadku resetowania przyciskiem RST, liczba błędów jest taka jak po kilku naciśnięciach wysyłania na kontroler z PC.

    Może coś z bitem stopu, czy też z buforem i w momencie wyłączenia go przyciskiem zwalniany jest.

    Dodałem zatem jeszcze funkcję opróżniającą bufor odebranych danych

    Kod: text
    Zaloguj się, aby zobaczyć kod

    i wywołują ją przed wysłaniem i po wysłaniu czegokolwiek, ale niczym to nie skutkuje, w sensie, że poprawy nie ma.
  • REKLAMA
  • #4 9438737
    kamyczek
    Poziom 38  
    Parzystość ,bit stopu,długość prawidłowa ? Większość błędów w pracy uarta to różne ustawienie parametrów wysyłanej informacji, źle ustawione źródło częstotliwości zegarowej (dzielnik lub RC) lub odebranie śmieci z bufora odbiorczego które znajdują się tam po resecie mikrokontrolera.Patrząc na to co odbiera terminal brak sterowania przepływem transmisji. Nadpisuje się bufor odbiorczy i (lub) bufor nadawczy w efekcie czego wychodzą śmieci proszę wysłać 1 bajt i odebrać jeden a przed transmisja wysłać np trzy razy FF z mikrokontrolera i trzy razy odebrać z bufora odbiorczego w celu opróżnienia go ze śmieci...
  • #5 9438888
    kasprzak
    Poziom 10  
    kamyczek napisał:
    Parzystość ,bit stopu,długość prawidłowa ? Większość błędów w pracy uarta to różne ustawienie parametrów wysyłanej informacji, źle ustawione źródło częstotliwości zegarowej (dzielnik lub RC) lub odebranie śmieci z bufora odbiorczego które znajdują się tam po resecie mikrokontrolera.Patrząc na to co odbiera terminal brak sterowania przepływem transmisji. Nadpisuje się bufor odbiorczy i (lub) bufor nadawczy w efekcie czego wychodzą śmieci proszę wysłać 1 bajt i odebrać jeden a przed transmisja wysłać np trzy razy FF z mikrokontrolera i trzy razy odebrać z bufora odbiorczego w celu opróżnienia go ze śmieci...

    Napisałem wyżej, że sprawdziłem:
    -procesor ustawiony na zewnętrzny rezonator - 8MHz
    - parametry transmisji zostały zabrane z przykładowego kodu oraz ustawiane po swojemu. Bez sktuku.
    - bez parzystości

    rejestr ustawiony tak
    	UCSR0C = (0<<UMSEL0) | (0<<UPM0) | (0<<USBS0) | (3<<UCSZ0)


    Męczy mnie ten fakt, że jak go uruchamiam i jest zasilony to początkowo dane idą elegancko, wysle i odesle tez dobrze, dopiero drugie wysłanie paczki danych i odbiór się sypią.
    Albo gdzieś nie kończy się transmisja, albo bufor się nie opróżnia. Jakie jeszcze pomysły ? :(
  • REKLAMA
  • #6 9439909
    Andrzej__S
    Poziom 28  
    kasprzak napisał:

    Męczy mnie ten fakt, że jak go uruchamiam i jest zasilony to początkowo dane idą elegancko, wysle i odesle tez dobrze, dopiero drugie wysłanie paczki danych i odbiór się sypią.

    Tak naprawdę to nie wiesz, czy problem leży po stronie odbiorczej, czy nadawczej. Być może odczyt flag FE0 (w szczególności) oraz DOR0 z rejestru UCSR0A pomoże zlokalizować problem. Należy pamiętać by odczytywać je po odebraniu znaku (RXC0=1), ale przed odczytaniem UDR0.
    Skoro twierdzisz, że na początku jest OK, spróbuj może wysłać swój napis na początku w jakiejś pętli for przykładowo 100 razy, by zobaczyć czy po dłuższej transmisji też jest wszystko w porządku. Będziesz miał względną pewność, czy nadawanie jest poprawne.
  • #7 9439957
    kasprzak
    Poziom 10  
    Pierwsze wysłanie jest ok. Napis wyświetlił się poprawnie do ok. połowy iteracji, potem liczba błędów transmisji wzrasta.
  • #8 9440064
    Andrzej__S
    Poziom 28  
    Zdaje się, że masz tam możliwość odłączenia pinów RXD0 i TXD0 mikrokontrolera od MAX3232. Proponowałbym utworzyć pętlę loopback, czyli odłączyć piny mikrokontrolera od MAX3232, a piny MAX3232 do których były podłączone piny mikrokontrolera zewrzeć między sobą. Wtedy komputer powinien odbierać to, co sam wysyła, bez udziału mikrokontrolera. Można wysłać jakiś większy pakiet danych z komputera, odebrać i sprawdzić, czy samo połączenie i MAX3232 działają poprawnie.
  • #9 9440072
    michalko12
    Specjalista - Mikrokontrolery
    Zacznij od sprawdzenia napięć na konwerterze TTL/RS232 (U2)
  • #10 9440097
    kamyczek
    Poziom 38  
    Zmień rezonator kondensatory i sprawdź bity cksel może kwarc się rozjeżdża dodatkowo między odsyłanymi bajtami proponuje dodać oczekiwanie o długości jednego bitu transmisji . Ja używam analizatora TTL w celu podpatrzenia czy mikrokontroler prawidłowo wysyła dane. Zazwyczaj wina jest w tym że jest zbyt mała przerwa między wysyłanymi bajtami i programy nie identyfikują bitu starty zaraz po bicie stopu wymagając przynajmniej jednego bitu przerwy ...
  • #11 9451811
    kasprzak
    Poziom 10  
    Okazało się, że układ (płyta testowa) miał za małe napięcie - 5V, po podaniu 9V wszystko wróciło do normy
REKLAMA