Witam.
Przeczytałem i przemyślałem jeszcze raz odcinek kursu o podejściu zdarzeniowym. Widzę w tym roziązaniu duże mozliwości i podejrzewam jego wykorzystanie w kolejnych częściach kursu. Dlatego obmyslając rozwiązanie buforowania przesyłu danych przez UART postanowiłem wykorzystać zaproponowany mechanizm zdarzeń. Mam trzy pomysły na rozwiązanie (dotyczy odbioru danych).
1. Nowy rodzaj zdarzenia dotyczący odebranego znaku i kolejka zbudowana na podobieństwo kolejki komunikatów.
2. N zdarzeń i odczyt N-tej pozycji bufora. N to wielkość bufora, jakieś 8 może 16. Po odczytaniu byłaby ustawiana zmienna z której dokonany był odczyt i na tej podstawie można wykryć przepełnienie.
3. Trochę sliska ale najprostsza metoda. Po komunikacie do kolejki wstawiany byłby przesłany bajt. Nie ma koneczności stosowania dodatkowej tablicy na dane, ale psuje to ideę. Miesza dane z komunikatami.
Dla wysyłania danych nie prewiduję kolejkowania a może jedynie komunikat o zwolnieniu bufora nadawania, takie powielenie przerwania sprzętowego.
Moje pytanie (do autora kursu) jest takie: w którym kierunku pójdzie rozwój komunikatów? Jeśli w żadnym z zaproponowanych to w jakim innym? Chciałbym kombinować w odpowiednim kierunku i nie zmieniać w grudniu czy styczniu swojego podejścia do zagadnienia.
Jeśli mój przekaz jest nieczytelny proszę o sygnał, zdaję sobie sprawę że kiepsko tłumaczę.
Koncepcja jest tylko obmyslana, nie realizowałem jej jeszcze więc może są jakieś minusy których nie widzę.
Najlepszego, Jejek.
8/06 Kurs C - zdarzenia.
Witam
Nieczęsto tutaj zaglądam, dlatego jeśli chcecie odemnie szybkiej odpowiedzi na temat który mnie dotyczy proszę o wiadomość na pw.
Sprawa jest taka, co już może widać po rozwoju kursu, że kolejka komunikatów została zaprezentowana jako pewna technika. Temat ten nie będzie drążony. Czeka nas jeszcze kilka ciekawych zagadnień ale jednocześnie kurs będzie już zmierzał do zakończenia. Dlatego też zamierzam zawsze pokazywać coś nowego aby nie przynudzać powtarzaniem czegoś o czym już mówiłem.
Jeśli chodzi o przesyłanie danych wraz z kolejką - nie ma problemu. Można w tym celu jednak stworzyć inny typ komunikatu. Jestem w trakcie tworzenia urządzenia (jednak nie jest to procesor ARM a raczej prostszy procesor umieszczony w FPGA) gdzie kolejka oprócz 8 bitowego pola na komunikat zawiera 32bitowe pole na dane. Daje to dodatkowe możliwości. W prostszych wersjach nic nie stoi na przeszkodzie aby dane były 16 albo nawet 8bitowe. Wbrew pozorom nie psuje to idei a raczej ją rozszerza.
Z drugiej strony użyta przeze mnie konstrukcja wiąże się przede wszytkim z koniecznością przesyłania wiadomości o naciśnięciu danego miejsca ekranu. Można to potraktować jako zdarzenie systemowe warte oddzielnego komunikatu. Jednak samą transmisję poprzez UART proponuję buforować oddzielnie. Można w tym celu stworzyć komunikat ogólnego zdarzenia od urządzenia IO i jeśli wystąpi sprawdzić co się dzieje.
Odradzam umieszczanie danych zaraz za komunikatem. Cała kolejka może się posypać jeśli na przykład nastąpi jej przepełnienie po wpisaniu niepełnych danych.
Nieczęsto tutaj zaglądam, dlatego jeśli chcecie odemnie szybkiej odpowiedzi na temat który mnie dotyczy proszę o wiadomość na pw.
Sprawa jest taka, co już może widać po rozwoju kursu, że kolejka komunikatów została zaprezentowana jako pewna technika. Temat ten nie będzie drążony. Czeka nas jeszcze kilka ciekawych zagadnień ale jednocześnie kurs będzie już zmierzał do zakończenia. Dlatego też zamierzam zawsze pokazywać coś nowego aby nie przynudzać powtarzaniem czegoś o czym już mówiłem.
Jeśli chodzi o przesyłanie danych wraz z kolejką - nie ma problemu. Można w tym celu jednak stworzyć inny typ komunikatu. Jestem w trakcie tworzenia urządzenia (jednak nie jest to procesor ARM a raczej prostszy procesor umieszczony w FPGA) gdzie kolejka oprócz 8 bitowego pola na komunikat zawiera 32bitowe pole na dane. Daje to dodatkowe możliwości. W prostszych wersjach nic nie stoi na przeszkodzie aby dane były 16 albo nawet 8bitowe. Wbrew pozorom nie psuje to idei a raczej ją rozszerza.
Z drugiej strony użyta przeze mnie konstrukcja wiąże się przede wszytkim z koniecznością przesyłania wiadomości o naciśnięciu danego miejsca ekranu. Można to potraktować jako zdarzenie systemowe warte oddzielnego komunikatu. Jednak samą transmisję poprzez UART proponuję buforować oddzielnie. Można w tym celu stworzyć komunikat ogólnego zdarzenia od urządzenia IO i jeśli wystąpi sprawdzić co się dzieje.
Odradzam umieszczanie danych zaraz za komunikatem. Cała kolejka może się posypać jeśli na przykład nastąpi jej przepełnienie po wpisaniu niepełnych danych.
Dzięki za Twoje uwagi.
Ja też myślałem o kolejce z polem na dane, ale skoro ich nie zastosowałeś to zrozumiałem że nie są potrzebne w dalszej części kursu a kolejka tak już będzie wyglądała. Stąd moje kombinacje. Co do wstawiania danych do tej samej kolejki to oczywiście trzeba to robić sprawdzając ilość miejsca wolnego i podpierając się jakąś synchronizacją procedur wpisujących i odczytujących. Chodziło mi o mechanizm.
Skoro nie zamierzasz rozbudowywać kolejki to już ja to zrobię po swojemu
Dzięki za odpowiedź, najlepszego!
Jejek
Ja też myślałem o kolejce z polem na dane, ale skoro ich nie zastosowałeś to zrozumiałem że nie są potrzebne w dalszej części kursu a kolejka tak już będzie wyglądała. Stąd moje kombinacje. Co do wstawiania danych do tej samej kolejki to oczywiście trzeba to robić sprawdzając ilość miejsca wolnego i podpierając się jakąś synchronizacją procedur wpisujących i odczytujących. Chodziło mi o mechanizm.
Skoro nie zamierzasz rozbudowywać kolejki to już ja to zrobię po swojemu
Dzięki za odpowiedź, najlepszego!
Jejek