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

ATMEGA32 - Niewłaściwe odbieranie szybszych strumieni danych

bisz 01 Kwi 2014 09:56 1485 9
REKLAMA
  • #1 13464256
    bisz
    Poziom 18  
    Witam. Borykam się pewnym nowym i nie spotykanym dotąd przeze mnie problemem z dość błahą czynnością jaką jest odbiór danych przez uart poprzez przerwanie.

    Obsługuję to najprościej jak się da, w taki oto sposób:

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



    Prędkość transmisji u mnie to 9600, ale nie ma żadnej różnicy również na 2400.

    Problem wygląda tak że gdy w programie Br@y terminal++ gdzie mam ustawione makra, lub gdy po enterze chce wysłać coś dłuższego niż 5 znaków, dajmy na to słowo "abecadlo"
    to w debugu widzę tylko "abeo", czyli zawsze pierwsze 3 litery i ostatnia.
    Czyżby bufor nie wyrabiał z prędkością ? Korzystałem już z tej metodyki mnóstwo razy i dopiero teraz mam taki dość dziwny problem.
  • REKLAMA
  • #2 13464277
    tmf
    VIP Zasłużony dla elektroda
    Obstawiam kłopot z wykonaniem funkcji uart_printf. Na czas jej wykonania masz blokowane wszystkie przerwania. Sprawdź flagę stanu USART - pewnie masz błąd buffer overrun.
    Jeśli potrzebujesz szybkości dużo wyższych niż 9600bps, to pomyśl też o XMEGA, w której odbiór danych z USART możesz zrealizować przez DMA, dzięki temu i kilka Mbps nie jest problemem.
  • REKLAMA
  • REKLAMA
  • #4 13464341
    bisz
    Poziom 18  
    Kod: C / C++
    Zaloguj się, aby zobaczyć kod


    Chyba nie ma specjalnej różnicy.
  • #5 13464345
    BlueDraco
    Specjalista - Mikrokontrolery
    Wywołując nadawanie długiego ciągu znaków przez UART w przerwaniu odbioru gwarantujesz gubienie odbieranych danych. Wyrzuć uart_printf z przerwania, a problem zniknie,
  • #6 13464350
    dondu
    Moderator na urlopie...
    bisz napisał:
    Kod: C / C++
    Zaloguj się, aby zobaczyć kod


    Chyba nie ma specjalnej różnicy.



    Cytat:
    There are currently two different styles present for naming the vectors. One form uses names starting with SIG_, followed by a relatively verbose but arbitrarily chosen name describing the interrupt vector. This has been the only available style in avr-libc up to version 1.2.x.

    Starting with avr-libc version 1.4.0, a second style of interrupt vector names has been added, where a short phrase for the vector description is followed by _vect. The short phrase matches the vector name as described in the datasheet of the respective device (and in Atmel's XML files), with spaces replaced by an underscore and other non-alphanumeric characters dropped. Using the suffix _vect is intented to improve portability to other C compilers available for the AVR that use a similar naming convention.

    The historical naming style might become deprecated in a future release, so it is not recommended for new projects.
  • #7 13464976
    bisz
    Poziom 18  
    Witam,
    Czy mógłbym kogoś prosić o pomoc w zbudowaniu instrukcji dającej mi w języku C wartość ostatnich dwóch zmiennych na stosie ?
    Problem z jakim się borykam wygląda tak, że gdy program zbytnio 'zmęcze' danymi przychodzącymi, to przestaje wywoływać pętlę główną i skacze gdzies... niewiem gdzie. Lecz obsługa przerwania od odebrania znaku cały czas jest aktywna i działa poprawnie. Zakładam że adres powrotu z przerwania wskazuje na jakąś bezsensowną przestrzeń programu i chciałbym to zweryfikować. Do tego celu potrzebowałbym sprawdzić w obsłudze przerwania co leży na stosie lecz nie bardzo wiem jak poprawnie poskładać taką procecdurę aby parametry z instrukcji pop, skierować do mojej wybranej zmiennej w języku C.
  • REKLAMA
  • #9 13465404
    BlueDraco
    Specjalista - Mikrokontrolery
    Zacznij od usunięcia oczywistego błędu, o którym pisałem - wysyłania łańcucha w przerwaniu odbioru.
  • #10 13751348
    bisz
    Poziom 18  
    Pomogło, dzięki!
REKLAMA