ATNEL tech-forum

Re: Bufor cykliczny - proste pytanie

2018-07-09T17:58:17+01:00

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

Statystyki: Napisane przez mirekk36 — 9 lip 2018, o 17:58

Re: Bufor cykliczny - proste pytanie

2018-07-09T15:13:42+01:00

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ę

Statystyki: Napisane przez MateuszS — 9 lip 2018, o 15:13

Re: Bufor cykliczny - proste pytanie

2018-07-09T14:40:39+01:00

MateuszS napisał(a):

Head załaduje pierwszą wartość do UART_TxBuf[1]

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ć

[syntax=c]default : UART_RxBuf[UART_RxHead] = data; UART_RxHead = tmp_head;[/syntax]

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

[syntax=c]ATOMIC_BLOCK( ATOMIC_RESTORESTATE ) {
// zwracamy bajt pobrany z bufora jako rezultat funkcji
data = UART_RxBuf[UART_RxTail];
// obliczamy i zapamiętujemy nowy indeks „ogona węża” (może się zrównać z głową)
UART_RxTail = (UART_RxTail + 1) & UART_RX_BUF_MASK;
}[/syntax]

aha i jeszcze przerwanie ISR( USART_UDRE_vect)

w nim też trzeba byłoby nieco przemeblować

[syntax=c]if ( UART_TxHead != UART_TxTail ) {
// zwracamy bajt pobrany z bufora jako rezultat funkcji
#ifdef UART_DE_PORT
UART_DE_NADAWANIE;
#endif
UDR = UART_TxBuf[UART_TxTail];
// obliczamy i zapamiętujemy nowy indeks ogona węża (może się zrównać z głową)
UART_TxTail = (UART_TxTail + 1) & UART_TX_BUF_MASK;
} else {[/syntax]

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

Statystyki: Napisane przez mirekk36 — 9 lip 2018, o 14:40

Re: Bufor cykliczny - proste pytanie

2018-07-09T14:21:04+01:00

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

Statystyki: Napisane przez MateuszS — 9 lip 2018, o 14:21

Re: Bufor cykliczny - proste pytanie

2018-07-09T13:46:52+01:00

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

[syntax=c]// sprawdzamy, czy wąż nie zacznie zjadać własnego ogona
if ( tmp_head == UART_RxTail ) {
// tutaj możemy w jakiś wygodny dla nas sposób obsłużyć błąd spowodowany
// próbą nadpisania danych w buforze, mogłoby dojść do sytuacji gdzie
// nasz wąż zacząłby zjadać własny ogon
} else {[/syntax]

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.

Statystyki: Napisane przez mirekk36 — 9 lip 2018, o 13:46

Bufor cykliczny - proste pytanie

2018-07-09T12:48:26+01:00

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:
[syntax=c]#define UART_RX_BUF_SIZE 8 // definiujemy bufor o rozmiarze 8 bajtów
#define UART_RX_BUF_MASK ( UART_RX_BUF_SIZE - 1) // definiujemy maskę dla naszego bufora
volatile char UART_RxBuf[UART_RX_BUF_SIZE];

volatile uint8_t UART_RxHead; // indeks oznaczający „głowę węża”
volatile uint8_t UART_RxTail; // indeks oznaczający „ogon węża”[/syntax]

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:
[syntax=c]ISR( USART_RXC_vect ) {

uint8_t tmp_head;
char data;

data = UDR; //pobieramy natychmiast bajt danych z bufora sprzętowego

// obliczamy nowy indeks „głowy węża”
tmp_head = ( UART_RxHead + 1) & UART_RX_BUF_MASK; // <<<<<<<<<<<<-------- Najważniejsza linijka

// sprawdzamy, czy wąż nie zacznie zjadać własnego ogona
if ( tmp_head == UART_RxTail ) {
// ew obsluga problemu
} else {
UART_RxHead = tmp_head; // zapamiętujemy nowy indeks
UART_RxBuf[tmp_head] = data; // wpisujemy odebrany bajt do bufora
}[/syntax]

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.

Statystyki: Napisane przez MateuszS — 9 lip 2018, o 12:48