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

ATmega8/32 - USART - RS232 - błędy przy przesyłaniu ponad 570 bajtów

Mlotek 13 Paź 2014 20:40 1095 8
REKLAMA
  • #1 14038900
    Mlotek
    Poziom 10  
    Witam wszystkich.
    Korzystam z komunikacji przez RS232/USB ATmega8 lub ATmega32. Z uC przesyłam wektor bajtów do komputera. Od strony komputera wykorzystuję Delphi i COMport 4.11.
    Wszystko dobrze działa do ok. 570 bajtów. Powyżej tej ilości następuje zamiana części bajtów na zera. Dla obu uC problem jest taki sam.
  • REKLAMA
  • #2 14038936
    mickpr
    Poziom 39  
    Podaj częstotliwość kwarcu, wybraną prędkość (baudrate), oraz kod - którego używasz (po stronie Atmegi na początek).
  • #3 14039191
    BlueDraco
    Specjalista - Mikrokontrolery
    Nie wysyłaj jednym ciągiem tak dużej porcji danych - zrób odstęp, bo inaczej UART może mieć problemy z synchronizacją. Podejrzewam jednak, że problem może być dużo bardziej prozaiczny - czy jesteś pewny, że Twoje wysyłane/odbierane dane mieszczą się w pamięci?
  • REKLAMA
  • #4 14044247
    Mlotek
    Poziom 10  
    Witam, dziekuję.
    Mój program mierzy czas kolejnych impulsów prostokątnych o losowym czasie trwania. zapamiętuje czasy w wektorze, który jest wysyłany po zakończeniu serii pomiarów.
    Wyniki wysyłane są jako bajty. To działa do ok 187 liczb 3 bajtowych, zarówno w ATmega8 jak i w ATmega32.

    W międzyczasie sprawdziłem że mogę odebrać wektor pomiarów o długości 1500 Byte, wysłany przez mój program z uC za pomocą Realterm, wygląda że bezbłędnie.
    Mogę też wysłać z uC za pomocą Delphi ComPort i odebrać 1500 byte za pomocą innego programiku. W obu przypadkach nie występuje "urywanie" części transmisji i zastępowanie zerami.

    Dane transmisji: zegar 15360000Hz zewnętrzny oscylator, UBRR=24, 38400 baud

    Jeżeli dalej podejrzany jest program, to oczywiście mogę wysłać tekst.
  • REKLAMA
  • #5 14044824
    Piotr Piechota
    Poziom 22  
    Myślę, że brakuje RAM i nadpisujesz stos. Jak mieścisz wektor pomiarów o długości 1500 bajtów w ATmega8 ?

    Pozdrawiam
  • REKLAMA
  • #6 14045076
    TvWidget
    Poziom 38  
    W PC jest bufor do obierania bajtów. Domyślnie ma zapewne długość 512 bajtów.
    Jeśli aplikacja nie pobiera z niego wystarczająco szybko danych to się przepełnia.
  • #7 14045107
    michalko12
    Specjalista - Mikrokontrolery
    Mlotek napisał:
    Wszystko dobrze działa do ok. 570 bajtów.

    Umieść kod dla uC, bo w przeciwnym wypadku będziesz miał wątek dyskusyjny dla wróżek.
  • #8 14047106
    Mlotek
    Poziom 10  
    Wygląda na to, że możliwe, że jest to któreś z proponowanych rozwiązań.
    Co do bufora wejściowego to zwiększałem go do 4048 i nic. Bardziej wygląda to na coś z pamięcią i ze stosem, ale jak to sprawdzić?
    Oczywiście nie można zrobić wektora 1500 bajtów w ATmega8 - tam próbowałem różne wartości, mieszczące się w pamięci, tak aby po kompilacji był komunikat o zajętości pamięci nie więcej niż 80% .
    Spróbuję jeszcze wprowadzić opóźnienia w transmisji, jeżeli to nic nie da to oczywiście przyślę kod programu od uC, bo nie znam żadnej wróżki.
    Dziękuję za rady.

    Dodano po 2 [godziny] 13 [minuty]:

    Po wprowadzeniu opóźnienia 1 ms przy transmisji każdych 256 bajtów, transmisja jest prawidłowa od strony uC, wszystkie bajty są prawidłowo odbierane (1502bajty) ale tylko w trybie krokowego wykonania programu po stronie Delphi. To opóźnienie spowodowało nieprawidłowe działanie programu po stronie Delphi. Wygląda to tak, jakby kilkunastokrotnie odbierał tą samą transmisję. To chyba ma coś wspólnego z odczytem bufora wejściowego?
  • #9 14049884
    Mlotek
    Poziom 10  
    Problem został rozwiązany!
    Zainspirował mnie kol. TvWidget uwagami o buforze. Okazało się, że trzeba było ustawić we właściwościach ComPort Timeouts.Constant tak, aby wystarczyło czasu na odczyt bufora.
    Temat zamykam, wszystkim autorom dziękuję.
REKLAMA