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

Transmisja szeregowa, ATmega32, jak to udoskonalić?

megaman123 28 Gru 2008 19:58 1825 10
REKLAMA
  • #1 5915118
    megaman123
    Poziom 13  
    Witam

    Otóż od niedawna walczę z pewnym zadaniem i nie mogę tego sfinalizować . Otóż pobieram sobie porcje danych z komputera PC do mikrokontrolera ( ATmega32 ) gdzie są lekko obrabiane a następnie wyrzucane przez spi do pamięci EEPROM . Otoz BARDZO potrzebuje wysokiej szybkości więc stwierdziłem ,ze 500000 kbps powinno zdać sprawę i pojawil sie problem buforowania . Otoz :

    - Bez bufora , kiedy przy odbiorze bajtu jest on z miejsca przetwarzany i przesłany przez spi działa - wszystko super sprawnie do pewnego czasu . Po ktorejs "paczce " danych gdzies jest wyciek ( prawdopodobnie zbyt szybka transmisja i bezpośrednie przetwarzanie ) i gubie bajty czego efektem jest katastrofa .

    - Żeby byc bardziej pewnym postanowiłem cala paczkę dzielic na ok 100 mniejszych i po odbiorze jednej , następowało przetwarzanie , wysyłanie i odpowiedz uP do PC o poprawności , i kolejna cząsteczka ... Aczkolwiek przy takim spoboie niesamowicie straciłem na szybkości ( nie za bardzo wiem w sumie dlaczego ) .

    Ma ktoś inny pomysł może? A może ktoś się z takim problemem już borykał ? Przesyłane paczki wahają się w okolach 8 - 14 kB

    Dzieki za wszelkie wskazówki .
  • REKLAMA
  • #2 5915183
    mirekk36
    Poziom 42  
    W takich przypadkach korzysta się ze sprzętowej bądź programowej kontroli przepływu danych przez RS232. No jakoś musisz dopasować obydwie strony ;) W RS232 masz przecież sygnały typu RTS, CTS, DTR itp - poczytaj do czego one są i je wykorzystaj w przypadku zapełniania bufora do końca oraz po jego ponownym zwolnieniu do odpowiedniej wielkości.
  • REKLAMA
  • #3 5916982
    tomasz_wilko
    Poziom 14  
    Cytat:
    - Bez bufora , kiedy przy odbiorze bajtu jest on z miejsca przetwarzany i przesłany przez spi działa - wszystko super sprawnie do pewnego czasu . Po ktorejs "paczce " danych gdzies jest wyciek ( prawdopodobnie zbyt szybka transmisja i bezpośrednie przetwarzanie ) i gubie bajty czego efektem jest katastrofa .


    Tutaj możliwe ,że przez dużą szybkość transmisji twoje taktowanie Uartu się rozstraja. Miałem kiedyś podobny problem z MSP'kiem gdzie rozstrajał się Boud Rate- bo był mało dokładnie nastawiony.
    -jest coś takiego jak bitowa stopa błędu dla każdego bitu w paczce.
    Na analizatorze stanów zaobserwowałem, że dane są wysyłane prawidłowo, ale niestety rozsynchronizowanie jednej z częstotliwości niweczy wszystko.

    -zaradzić, hmm mi się to udało przez bardzo dokładne dobranie wartości rejestrów Boud Rate.


    hmm, dużo danych przesyłasz...
  • REKLAMA
  • #4 5917032
    megaman123
    Poziom 13  
    Dzięki za odpowiedzi !

    Rzeczywiście tutaj może być problem . Patrząc dokładniej w HyperTerminalu nie ma do wybrania dokładnie opcji 500k - Ja do transmisji ożywam aplikacji napisanej przezemnie gdzie BAUD'a ustawiam ręcznie - z noty AT32 wcześniej wyczytałem , że dla 16 Mhz stopa błędu przy 500k wynosi 0 % więc myślałem ,że będzie w porządku . Czy jest możliwość , że błąd jest właśnie od strony "nie możliwości" utworzenia prędkości równej 500k od strony PC ?
  • #5 5917098
    Konto nie istnieje
    Poziom 1  
  • #6 5917931
    tomasz_wilko
    Poziom 14  
    Cytat:
    Czy jest możliwość , że błąd jest właśnie od strony "nie możliwości" utworzenia prędkości równej 500k od strony PC ?


    hmm , wydaje mi się ,że bardziej procesor nie jest stabilny niż PC
    (chociaż nie jestem ekspertem w tych sprawach)
    , a masz możliwość sprawdzenia ile dokładnie wynosi twój BoudRate od procesora? Może się okazać że to nie jest 500k, a 495k..
    tak jak to było w moim przypadku.
    Sprawdź na wszelki wypadek, np. w programie Terminal V1.9 czy odbierasz dobrze dane przy 500k, potem przestaw na 495k-505k
    i zobacz jak się zachowuje-czy dane są nadal gubione?.

    Nie wiem z jakiego kwarcu korzystasz, i jakiego PLL używasz, może problem z jego stabilnością też mieć znaczenie.
  • #7 5919218
    megaman123
    Poziom 13  
    "Wydaje mi sie ze nie wyciagniesz wiecej niz 230400 kbps... "

    Możesz kontynuować myśl ?

    "Sprawdź na wszelki wypadek, np. w programie Terminal V1.9 czy odbierasz dobrze dane przy 500k, potem przestaw na 495k-505k
    i zobacz jak się zachowuje-czy dane są nadal gubione?. "

    A to dziwne , bo dla każdej z tych prędkości wydaje być w porządku ( linia tx i rx została zwarta , i pzesylany plik tekstowy nie gubi nic ) , wiec już nie wiec cholera co może nawalać :/ . A wracajac do pytania , czy potwierdzenie po takich paczkach , serio moze transmisje tak spowolnić ? ( około dwukrotnie )
  • REKLAMA
  • #8 5919280
    skynet_2
    Poziom 26  
    megaman123 napisał:
    A wracajac do pytania , czy potwierdzenie po takich paczkach , serio moze transmisje tak spowolnić ? ( około dwukrotnie )


    Może twój program do odbierania potwierdzenia[µC->PC] ma błąd i zamiast wysyłać od razu następną paczkę musi czekać, np. jak detekcję odbierania zrobiłbyś na pętli z funkcją Sleep(np. 10) wtedy program musi odczekać 10ms i dopiero wtedy wyślę następną paczkę.
  • #9 5919544
    mirekk36
    Poziom 42  
    megaman123 napisał:
    A wracajac do pytania , czy potwierdzenie po takich paczkach , serio moze transmisje tak spowolnić ? ( około dwukrotnie )


    to wszystko zależy jak napisałeś swój program. Jednak nie byłeś łaskaw napisać w czym programujesz. Zakładając więc (może mylnie), że w Bascomie - to zainteresuj się jak ci już wspominałem poleceniem

    Config Serialin - oraz możliwością sprzętowej realizacji RTS , CTS - czyli masz tam możliwość zdefiniowania pinów dla sprzętowej kontroli wymiany danych bez najmniejszego problemu. Może się to okazać dla ciebie zbawienne - ponieważ nie będziesz musiał pisać własnych procedur dzielących dane na paczki oraz optymalizować całości.

    a jeśli programujesz w czymś innym np C lub Asm to zorganizowanie tej sprzętowej kontroli tym bardziej nie powinno stanowić problemu
  • #10 5919992
    kemot55
    Poziom 31  
    Wysyłałem paczki 10kB (kilobajtów) z prędkością 0.5MBod bez problemów.
    Sprzęt ATMEGA128 + FTDI (obsługa z użyciem bibliotek DLL producenta, bez sprzętowej kontroli przepływu) + PC (Core2Duo). Problemy zaczynały mi się gdzieś przy 0.75..1MBod.
    Wydaje mi się, że głównie należy tu sprawdzić procedurę odbioru w PC.
    Poza tym czy transmisja PC->uC działa OK (możesz to sprawdzić)?
  • #11 5922498
    megaman123
    Poziom 13  
    Dziękuje wszystkim za zaangażowanie :)

    A więc przepraszam ,że nie napisałem wcześniej : Program pisany dla mikro kontroler jest pisany w C , a aplikacja na PC pisana jest w C# .
    I wysyłanie zwrotnych bajtów jest w momencie przechwycenia zdarzenia odebrania jednego bajtu z portu szeregowego.

    Wczoraj postanowiłem to sprawdzić jeszcze inaczej :

    Miałem kiedyś pewien wyświetlacz od jakiegoś telefonu ( wymiary to powiedzmy 100 / 60 i pisałem dla niego program . Bitmapy ( a w zasadzie ich postac hexowa ) zajmuje podobnie dużo pamieci jak moja jedna paczka więc postanowiłem przerobić mój program ,zeby odebrany bajt zamiast przez SPI do pamięci zewnętrznej , szedł do pamięci wyświetlacza i wszystko ładnie jest wyświetlane do chyba 5 bitmapy kiedy już zaczyna bzikować i wyświetlać głupoty . W metodzie drugiej z potwierdzaniem wszystko przechodzi zawsze do konca , nic gubione nie jest za to ewidentnie widać już postępy rysowania ( w pierwszym przypadku bmp było wyświetlane w zasadzie automatycznie )
REKLAMA