Hej,

wyposażyłem się w BB i ogólne działanie bufora cyklicznego rozumiem, natomiast mam problem z wizualizacją tego/wyobrażeniem sobie poruszania się tych wskażników Head i Tail.
Z góry proszę o wyrozumiałość, jeżeli popełniam straszny błąd. Trochę nad tym już siedzę i nie umiem tego do końca pojąć
Fragment zapisu danych do bufora w przerwaniu odbiorczym z BB:


zakładam dla prostoty, że bufor ma 8bajtów, czyli:



Początkowo zarówno Head i Tail są równe(bufor jest pusty), czyli wskazują na np. UART_RxBuf[0]. Jeżeli zostaje coś zapisane do bufora to wykonuje się ta znana funkcja:


Moje rozumowanie: Jeżeli zostanie załadowany jakiś bajt do bufora to zostanie on załadowany do UART_TxBuf[1], ze względu na zwiększony o +1 indeks Head. Gdy zostanie załadowany nie jeden, a siedem bajtów to załadowane zostaną te bajty do:
UART_RxBuf[1], UART_RxBuf[2],UART_RxBuf[3].....UART_RxBuf[7]. Rozumiem działanie maskowania, które spowoduje, że przy próbie załadowania kolejnego bajtu wskaźnik nam powróci na początek i będzie wskazywał na UART_RxBuf[0].

PYTANIE: Załóżmy, że pętla główna programu była ciągle zajęta i program nie zdążył odczytać żadnego bajtu z bufora, więc wskaźnik TAIL stale wskazuje na UART_RxBuf[0]. Wydaje się, że w tym momencie wskazują na to samo miejsce w tablicy bufora, więc nie będzie można załadować tego kolejnego bajtu, ale przecież załadowaliśmy tylko 7 bajtów do bufora 8 bajtowego pozostawiając UART_RxBuf[0] pusty. Oznacza to, że tak naprawdę możemy załadować tylko 7 bajtów do bufora 8 bajtowego? Gdzie w moim rozumowaniu jest błąd?



Dla dopełnienia dodam tylko, że funkcja odbiorcza pierwsze co robi to sprawdza, czy Head i Tail sa sobie rowne - jeżeli tak, to uważa, że bufor jest pusty.

A widział kolega w Bluebooku fragment kodu z przerwania? ten dokładnie





on spowoduje, że Head NIGDY się nie przesunie na TAIL i trzeba sobie ew samemu to oprogramować - bo inaczej po prostu kolejne nadsyłane bajty pójdą w kosmos. OCZYWIŚCIE bufor pomieści 8 bajtów tak jak sam to rozpisałeś - a nie 7 Przecież nawet na twoim rysunku widać, że upchałeś tam 8 bajtów za to 9-ty już nie wlezie

Dlatego też wielkość bufora należy dobierać do potrzeb, czyli tak aby mieścił on MINIMALNIE jedną ramkę którą chcesz przesyłać, ale jeśli te ramki mają szybko sobie że tak powiem popierniczać ... no to może zabraknąć tego bufora prawda ? czyli co dalej zrobić ?

1. albo zwiększyć bufor tak aby zmieściło się N-ramek więcej (to w zależności od tego ile masz wolnego RAM'u)
2. albo stosować krótsze ramki

albo trzecie wyjście - stosować na raz dwa punkty wyżej

------------------------ [ Dodano po: 6 minutach ]

krótko mówiąc tak trzeba projektować swój system wymiany danych aby zoptymalizować ilość i czas przesyłanych danych w stosunku do możliwości jak chodzi o przeznaczenie iluś tam bajtów pamięci RAM.

No i bodajże NAAAJWAŻNIEJSZE - stosując to podejście NIGDY ale to NIGDY nie można już stosować blokującego sposobu pisania funkcji. Wszystko MUSI BYĆ NIEBLOKUJĄCE.

Dla typowych komend AT - no powiedzmy o długości do kilkunastu bajtów, jak ustawisz wielkość bufora na np 64 albo na 128 i masz wszystko ładnie nieblokująco napisane to możesz spać spokojnie. Jeśli ramki (komendy AT będą dużo dłuższe np kilkadziesiąt znaków - to daj sobie bufor 256) a jeśli i ten będzie za mały bo ramki będą z jakiegoś urządzenia GPS np grubo ponad 100 bajtów no to wtedy musisz przerobić sobie całą obsługę tak aby bufor cykliczny mógł liczyć sobie więcej bajtów niż 256 jak w tym wypadku.

No ale to takie gdybanie - lepiej jak byś napisał co konkretnie chcesz uzyskać - wtedy byłoby łatwiej pomóc.

A zakładając że tylko pytałeś żeby zrozumieć - to mam nadzieję, że ten fragment kodu i wyjaśnienie na początku dało ci jakiś lepszy ogląd sytuacji.

_________________
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 za odpowiedź i dodatkowe przykłady.
Natomiast według tego co opisałem(moje rozumowanie) i co umieściłem na rysunku - w tablicy 8 bajtowej zostaje zawarte tylko 7 bajtów. Head załaduje pierwszą wartość do UART_TxBuf[1], a po zrobieniu pętli(czyli załadowaniu siedmiu bitów) nie będzie mógł załadować 8 bajtu do UART_TxBuf[0], ze względu na kod, który umieściłeś. Tutaj gdzieś leży problem w moim rozumowaniu i wierze Ci na słowo, że się da - nie chodzi mi o to żeby się kłócić broń Boże :]

ale ja się nie kłócę - a też tak troszkę z pamięci piszę, ale masz rację, zapisanych zostanie 7 bajtów do bufora a nie 8 chyba trzeba byłoby lekko ten kod przerobić czyli w przerwaniu dać




ale w odczycie (przy pobieraniu znaku z bufora w funkcji uart_getc() ) też trzeba byłoby lekko zmienić, np tak:



aha i jeszcze przerwanie ISR( USART_UDRE_vect)

w nim też trzeba byłoby nieco przemeblować





ale to też teraz tak piszę na szybko i z głowy ... i cieszę się, że zasygnalizowałeś ten problem - dziękuję. Jeśli akurat jesteś przy tym kodzie i możesz to sprawdzić to byłoby super. Ja sprawdzę nieco później i jeśli będzie ok - to dodam to gdzieś do uaktualnień do książki na stronie atnel

_________________
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 ]

Nie do końca rozumiem jak miałbym dokonać zmian na podstawie tego kodu, który napisałeś na szybko, więc raczej test będę musiał zostawić Tobie ;/. Natomiast dziękuje za odpowiedź, bo już wyrywałem sobie włosy z głowy. Wracam do dalszego analizowania bufora, bo dopiero się tego uczę

no ale taka nauka w twoim wydaniu to coś pięknego ... podoba mi się takie analityczne podejście a jeszcze na dodatek umiejętne zadawanie pytań itp

_________________
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 ]