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

[ATMEGA16A] ATMEGA16A AVR-GCC UART wysyła powtarzalne śmieci przy 115200 bps, 8N1

kapw 18 Maj 2012 15:02 2269 7
REKLAMA
  • #1 10910178
    kapw
    Poziom 12  
    Witam,
    mam tablice 50cio-elementową, którą chcę wysłac uartem.
    Procek ma wysyłać tablice do 2giego procka na odległość 10 cm.
    Niby prosta sprawa, ale wysyła śmieci. Co ciekawsze te śmieci są jakby powtarzalne
    115200, 8bit, 1stop, bez parzystości.

    Może ktoś spojrzy "świerzym" okiem ....

    Program główny
    Kod: C / C++
    Zaloguj się, aby zobaczyć kod



    uart.h
    Kod: C / C++
    Zaloguj się, aby zobaczyć kod


    uart.c
    Kod: C / C++
    Zaloguj się, aby zobaczyć kod
  • REKLAMA
  • #2 10910402
    tmf
    VIP Zasłużony dla elektroda
    A jak wygląda kod odbiornika? Wiesz, że twoja funkcja inicjująca USART odblokowuje tylko nadajnik, odbiornik pozostaje zablokowany? Kolena rzecz - wywal to FILE - jak widzę nie korzystasz ze strumieni, więc po co ci to?
    Jak są taktowane oba procesory? Z generatorów wewnętrznych RC? Czy kwarców? Jeśli z wewnętrznych generatorów RC to może być problem, zastosuj wtedy tryb synchroniczny USART.
  • REKLAMA
  • #3 10911887
    kapw
    Poziom 12  
    Witam,
    ja mam tylko nadawać, oba procki 16MHz tak samo zainicjowana transmisja.
    Procek odbierający reaguje TYLKO na taki ciąg liczb.
    To ze lecą śmieci zobaczyłem podpinając mój "nadajnik" do PCta przez maxa232.
    FILE niczemu nie przeszkadza bo jest niewykorzystywany
  • #4 10912249
    krru
    Poziom 33  
    Przy takiej "masowej" transmisji RS (w sensie, że kolejny bajt jest nadawany bez przerwy po poprzednim) odbiornik może mieć problem z synchronizacją początku i końca bajtu. Spróbuj wysyłać co jakiś czas (co wysłanie tablicy) jeden lub dwa bajty o wartości 0xFF.
  • REKLAMA
  • #5 10918366
    Konto nie istnieje
    Poziom 1  
  • REKLAMA
  • #6 10918443
    Konto nie istnieje
    Konto nie istnieje  
  • #7 10918479
    krru
    Poziom 33  
    atom1477 napisał:
    To raczej nie pomoże bo nadal będzie wysyłany bit startu. Trzeba by raczej dodawać normalne opóźnienie. Ale nie sądzę żeby to było to.


    No i właśnie te same bity startu umożliwiają odzyskanie synchronizacji bitowej. Jeśli trafi się 0xFF, kolejne bajty zostaną już odebrane poprawnie.
    Oczywiście może to nie być ten przypadek, szczególnie jeśli zostanie zapewnione, że odbiornik jest włączony przed nadajnikiem, ale i tak przyda się takie zabezpieczenia na przyszłość, o ile faktycznie będzie używana tak intensywna transmisja.
  • #8 10918676
    tmf
    VIP Zasłużony dla elektroda
    krru napisał:
    atom1477 napisał:
    To raczej nie pomoże bo nadal będzie wysyłany bit startu. Trzeba by raczej dodawać normalne opóźnienie. Ale nie sądzę żeby to było to.


    No i właśnie te same bity startu umożliwiają odzyskanie synchronizacji bitowej. Jeśli trafi się 0xFF, kolejne bajty zostaną już odebrane poprawnie.
    Oczywiście może to nie być ten przypadek, szczególnie jeśli zostanie zapewnione, że odbiornik jest włączony przed nadajnikiem, ale i tak przyda się takie zabezpieczenia na przyszłość, o ile faktycznie będzie używana tak intensywna transmisja.


    Ale co z tego skoro kolejne bity i tak się odbiorą źle, bo częstotliwości pracy po obu stronach są różne?
    RS232 nie wymaga żadnych opóźnień pomiędzy znakami - po to są właśnie bity startu.
REKLAMA