Uważam bufor cykliczny ma sens tylko wtedy gdy:
- przez względnie dłuższy czas „napełnia się” bajtami z innego mikrokontrolera,
- potem bardzo szybko kawałek naszego programu opróżnia bufor cykliczny (czytając go)

Czy zarys ewentualnego programu jest prawidłowy?
Albo inaczej - czy zależności czasowe między get(c) a ISR(USART_RXC_vect) mogą być np. takie?
….. tu program robi różne
….. rzeczy nie związane
….. z RS232C
Przeczytaj 17 bajtów z innego mikrokontrolera tu program wpada na pomysł przeczytania 17 bajtów z innego mikrokontrolera. Wysyła więc żądanie po RS do innego mikrokontrolera i dalej robi swoje.
A teraz proszę Państwa po pewnym czasie zaczyna się dziać, gdyż inny mikrokontroler rozpoczął nadawanie 17 bajtów.
ISR(USART_RXC_vect) przerwanie bo przyszedł pierwszy z 17 bajtów W buforze cyklicznym pokaże się „jednobajtowy” wąż składający się tylko z głowy.
ISR(USART_RXC_vect) przerwanie bo przyszedł drugi z 17 bajtów W buforze pokaże się „dwubajtowy” wąż
ISR(USART_RXC_vect)przerwanie bo przyszedł trzeci z 17 bajtów W buforze pokaże się „trzybajtowy” wąż
…..
…..
ISR(USART_RXC_vect) przerwanie bo przyszedł ostatni z 17 bajtów W buforze pokaże się „siedemnastobajtowy” wąż

getc() pierwsza instrukcja opróżniająca bufor cykliczny
zapisz_gdzieś
getc() druga instrukcja opróżniająca bufor cykliczny
zapisz_gdzieś…..
…...
getc() ostatnia instrukcja opróżniająca bufor cykliczny
zapisz_gdzieś
Bufor cykliczny jest znowu pusty i 17 bajtów zostało gdzieś zapisane
Oczywiście instrukcje ISR pojawiają się w tle. (nie piszemy ich 17 razy!) „Między nimi” program może robić różne inne rzeczy. 17 instrukcji getc() i 17 zapisz_gdzieś jest zwykle zawarte w jednej instrukcji czytającej całego stringa. Przerwanie od pierwszego z 17 bajtów powstanie bezproblemowo – przecież UDR UART-u na początku jest puste!
Milcząco przyjąłem też założenie, że inny mikrokontroler dosyła nowe bajty stosunkowo wolno w porównaniu do szybkości zapisywania bufora cyklicznego. Czyli zanim przyjdzie następny bajt z innego mikrokontrolera to poprzedni bajt zostanie błyskawicznie przepisany z UDR do bufora cyklicznego. Nie ma to nic wspólnego z getc()!
Powstaje pytanie. Skąd program ma wiedzieć kiedy zrobić pierwsze get(c)? Na pewno nie poprzez zapełnienie do końca bufora cyklicznego. Przecież ma on odebrać 17 a nie 32 bajty. Idealnie byłoby przerwanie od ostatniego 17 bajtu. A może informacja że inny mikrokontroler zakończył transmisję?
Tak czy owak to wszystko pomiędzy Przeczytaj 17 bajtów z innego mikrokontrolera a ostatnim getc() powinno być zawarte w jednej instrukcji która przeczyta 17 bajtów z innego mikrokontrolera.

Ja bym powiedział zdecydowanie inaczej. Bufor cykliczny ma zawsze sens, jest potrzebny w 99,999999999999% przypadków a ten, 0,0000000000000001% przypadków możemy pominąć w naszych rozważaniach.

Przy czym ważna rzecz - mówię tu o buforze cyklicznym ODBIORCZYM ... !!! WAŻNE !!! ... bo nadawczy rzeczywiście w wielu przypadkach możemy pominąć.

Dalsze twoje rozważania odnośnie działania opisanego mechanizmu są poprawne...

Na koniec zadajesz typowe pytanie po przeczytaniu I-szej książki, ponieważ nagle urywa się opis transmisji UART, o ile jest i ładnie działa nadawanie to już z odbieraniem wielu ludzi ma problem. Na szczęście są dwa rozwiązania:

1. tu na forum już kilku kolegów się pokusiło i z moją lekką pomocą napisali sobie odbieranie stringów ... jak znajdę ten wątek to go tutaj wkleję

2. w II-giej książce - jest to już ABSOLUTNIE i pięknie do końca opisane jak odbierać stringi

ale pytasz - skąd procesor ma wiedzieć, że już może zrobić uart_getc() ?

no może zrobić kiedy mu się tylko spodoba ale trzeba sobie to dalej już jakoś właśnie oprogramować - bo tego pierwsza książka nie opisuje. Kończę w niej na wyjaśnieniach tak istotnych rzeczy jak prawidłowe podejście do odbioru w przerwaniach do buforów cyklicznych - co bardzo ładnie opisałeś swoimi słowami/przykładami

a teraz podpowiedź - gdybyś dalej chciał sam tworzyć odbiór stringów - bo tak polecam podejść.

1. Pomyśl sobie - skoro mowa o stringu np wysłanym z terminala to zwykle zakończony on będzie znakiem CR (enter)

2. skoro wpadnie 17 bajtów do bufora to 17 albo 18 będzie właśnie Enter

3. można więc już na etapie przerwania odbiorczego zliczać sobie ilość Enterów które wpadły do bufora cyklicznego a w programie głównym sprawdzać. I jak jest ich więcej niż 0 to pobierać całą linię z bufora za pomocą getc() aż do znaku ENTER, który trzeba pominąć.

Dzięki takiemu mechanizmowi - nie musisz się martwić przestojami w programie głównym - bo gdyby był czymś zajęty i nie zdążył odebrać jednego stringa i nagromadziłoby się ich tam (w zależności oczywiście od wielkości bufora cyklicznego) kilka czy kilkanaście - to jak w końcu się dorwiesz to możesz naraz je wszystkie obsłużyć

Pisałeś też że inny mikrokontroler wolno nadaje ....

to nie wynika z mikrokontrolera i jego chęci, bo tak samo może być z terminala. To wynika z prędkości baudrate, które są o wiele wiele wolniejsze niż możliwości wykonywania w tym samym czasie niezliczonych operacji przez mikrokontroler.

_________________
zapraszam na blog: http://www.mirekk36.blogspot.com (mój nick Skype: mirekk36 ) [ obejrzyj Kurs EAGLE ] [ mój kanał YT TV www.youtube.com/mirekk36 ]

Dzięki
Czyli z grubsza szedłem właściwą drogą.
Mam jeszcze jedno pytanie. Czy można zrobić doświadczenie np. takie że nadawany jest stan klawisza jednego mikrokontrolera który będzie odbierany przez drugi mikrokontroler i będzie zapalał diodę. Oczywiście że można. Ale np nie chcę się bawić w montaż drugiej płytki z 644p z kwarcem,fusebitami itd? Czy jest sens zasymulowania tego na 2 UART-ach tego samego 644p? Tzn. czy można traktować że sygnał wyjdzie na "zewnątrz" z jednego UART-u i i wejdzie do drugiego? I czy ten drugi UART będzie się zachowywał tak jakby był w osobnym 644p?

No ale przede wszystkim czy nie łatwiej te testy wykonać pomiędzy prockiem i terminalem w windows ? na to samo wyjdzie

_________________
zapraszam na blog: http://www.mirekk36.blogspot.com (mój nick Skype: mirekk36 ) [ obejrzyj Kurs EAGLE ] [ mój kanał YT TV www.youtube.com/mirekk36 ]

W zasadzie można , ale to trochę takie bezcelowe jest ... przecież wygodniej jest testować połączenie AVR->PC
a i wygoda większa

_________________
[b]San Escobar! Patria mia! Tu eres como la salud.[/b]