Skocz do zawartości

ATMega 8 USART utrata danych


davidpi

Pomocna odpowiedź

Witam.

Mam pytanie odnośnie USARTu w ATMega 8. Mam połączone dwie ATMegi. Z pierwszej wysyłam jedna po drugiej kilka danych. Druga te dane odbiera. Moje pytanie jest następujące. Czy istnieje taka możliwość aby druga ATMega, zajęta obsługą innych procedur, nie zdążyła odebrać przysyłanych danych i któreś z tych danych zostały utracone (nadpisane w buforze odbiorczym)? Ewentualnie jak się przed taką sytuacją bronić?

Odbiór danych przez USART nie może być realizowany przez przerwanie, lecz w ciele funkcji main().

Z góry dziękuje za pomoc

Link do komentarza
Share on other sites

Generalnie najlepiej wykorzystać przerwanie do tego. Wtedy będziesz miał pewność że nic się nie straci. A jest to bardzo prawdopodobne. Jak się przed tym bronić? wykorzystując przerwanie;) tak w zasadzie najlepiej. Możesz też sprawdzać bufor "na piechotę"co jakiś czas ale to chyba trochę ryzykowne.

Link do komentarza
Share on other sites

Jeśli odbiór nie może być realizowany przerwaniem, musisz sprawdzać czy pojawiły się nowe dane w tak wielu miejscach programu, jak to tylko możliwe. Generalnie jeśli jeden obrót pętli głównej trwa maksymalnie i tak krócej niż czas odebrania jednego bajtu, to nie ma się czego obawiać. Zawsze możesz spowolnić komunikację.

BTW: do komunikacji między prockami nie lepszy SPI? No chyba, że w komunikacji oba procki mają być równorzędne.

Link do komentarza
Share on other sites

Hmm. Dzięki za pomysły. Chodzi mi o to, że jeżeli użyje przerwania od USART ( a w programie mam już przerwanie od Timer2) , i przyjdzie taka sytuacja, że przerwania się nałożą, to jedno z nich zostanie zakłócone przez drugie. Zależy mi na tym aby oba pracowały beż przeszkód, czyli aby nie wystąpiła sytuacja, że przerwania występują w tym samym momencie. Przerwanie od Timer2 steruje serwem, więc jego zakłócenie popsuje pracę serwa. I odwrotnie - jeżeli przerwanie od Timer2 zakłóci przerwanie od USART ( sam nie wiem które ma wyższy priorytet) to nie odbiorę całej sekwencji danych. Najlepszym rozwiązaniem to by było, gdyby jedno przerwanie było obsługiwane całkowicie sprzętowo, a więc niezależnie od tego co robi reszta mikrokontrolera.

Link do komentarza
Share on other sites

Zarejestruj się lub zaloguj, aby ukryć tę reklamę.
Zarejestruj się lub zaloguj, aby ukryć tę reklamę.

jlcpcb.jpg

jlcpcb.jpg

Produkcja i montaż PCB - wybierz sprawdzone PCBWay!
   • Darmowe płytki dla studentów i projektów non-profit
   • Tylko 5$ za 10 prototypów PCB w 24 godziny
   • Usługa projektowania PCB na zlecenie
   • Montaż PCB od 30$ + bezpłatna dostawa i szablony
   • Darmowe narzędzie do podglądu plików Gerber
Zobacz również » Film z fabryki PCBWay

Skoro używasz timera to może lepiej wykorzystać PWM? Albo skorzystać z ISR_NOBLOCK (http://www.nongnu.org/avr-libc/user-manual/group__avr__interrupts.html), tylko się trzeba pilnować, można doprowadzić do przepełnienia stosu lub ponownego wejścia w to samo przerwanie (co jest generalnie rzecz biorąc złe, bo w C nie ma rekurencji i trudno ocenić co się stanie, możliwe, że będzie operować na tych samych zmiennych, ale parę razy, co też jest złe).

Możesz też UART obsługiwać przerwaniem, a sterowanie serwem w funkcji main, ale to trochę kłopotliwe rozwiązanie.

Link do komentarza
Share on other sites

Można też spróbować zrobić to na przerwaniach w następujący sposób:

Podczas przerwania od timer2 wyłączyć przerwanie od UART. Tylko że w tym przypadku przerwanie od timera musiałoby trwać krócej niż odbiór żeby bufor nie nadpisał nieobrobionej danej a na koniec przerwania znowu włączyć przerwanie od UART.

Nie wiem na ile to u Ciebie możliwe ale zawsze jakiś pomysł😉

Link do komentarza
Share on other sites

od timera 2 ma wyższy priorytet niż od USART czyli pracy serwa nie zakłóci no i oczywiście po wysterowaniu serwa odbierze dane nie blokując ponownego przerwania z TIMER2 także myślę że sytuacja jest ci na rękę bo dane nie przepadają

Link do komentarza
Share on other sites

Hmm dzięki za wszystkie pomysły. Postanowiłem, że w przerwaniu od Timer2 ustawię tylko jakąś flagę. A resztę obsługi przerwania przeniosę do pętli głównej. Wtedy jeżeli przyjdzie nawet przerwanie od USART, a jego obsługa trwa krótko, to niewiele zakłóci to pracę serwa. Przetestuje to po południu i dam znać.

Pozdrawiam

Link do komentarza
Share on other sites

Nie jestem pewien ale mam wrażenie, że uważasz iż jeżeli w trakcie przerwania nastąpi kolejne to dane przepadają czyli poprzednie przerwanie straci dane. Tak nie jest przerwanie zawsze jest dokończone. Sytuacja z przerwania zostanie zapisana w pamięci i po zakończeniu tego z wyższym priorytetem powróci do tego z mniejszym priorytetem. Jeżeli ustawisz flagę to nie będzie to przerwanie co równy odstęp czasu, będzie zależało od zawartości pętli głównej także średni efekt

Link do komentarza
Share on other sites

Witam ponownie.

Przetestowałem wszystkie pomysły. W przerwaniu od Timer 2 ustawiłem flagę, a resztę robiłem w main(). Odbieranie przez USART zrobiłem na przerwaniu i działało dobrze. Poza jednym drobiazgiem. Serwo w takim przypadku drgało raz na jakiś czas (tak raz na dwie sekundy,w zależności od tego jak często wysyłałem z drugiego procka dane).

Natomiast w sytuacji gdy zarówno cały Timer2 jak i Usart robiony jest na przerwaniach tego problemu nie ma. Zapewne, jak już ktoś powiedział, Timer2 ma wyższy priorytet przerwania niż USART i odbiór nie zakłóca serwa. Być może w takim przypadku jakieś dane giną po drodze, ale na oko działa to dobrze. Z drugiej Atmegi dane są wysyłane z częstotliwością 50Hz więc nie ma problemu. Dlatego zdecydowałem się na ten drugi wariant.

Dziękuje wszystkim za zainteresowanie i pozdrawiam

Link do komentarza
Share on other sites

Bądź aktywny - zaloguj się lub utwórz konto!

Tylko zarejestrowani użytkownicy mogą komentować zawartość tej strony

Utwórz konto w ~20 sekund!

Zarejestruj nowe konto, to proste!

Zarejestruj się »

Zaloguj się

Posiadasz własne konto? Użyj go!

Zaloguj się »
×
×
  • Utwórz nowe...

Ważne informacje

Ta strona używa ciasteczek (cookies), dzięki którym może działać lepiej. Więcej na ten temat znajdziesz w Polityce Prywatności.