System H U D w modelu lataj?cym

Witam

Interesuje mnie wszystko na temat obserwcji terenu nad którym lata mopdel Szukam zainteresowanych tematem.

Pozdrawiam

Reply to
marek.
Loading thread data ...

Zapraszam na

formatting link

Reply to
Marek

Panowie,

Prawdę mówiąc ja również jestem zainteresowany zabawą w taki projekt. Choć nie mnie chodzi o HUD, lecz o UAV. W zeszłym roku zrobiłem kontroler serwomechanizmów, który opisałem na stronie

formatting link
. Jest zakończony i sprawdzony (przy okazji mam 20 wolnych wydrukowanych płytek tego układu).

Teraz korzystam z pogody do latania, ale po zakończeniu sezonu wracam do tematu i będę robił główny moduł. Oczywiście na zrobienie płatowca braknie mi czasu. Więc szukam kogoś do połączenia sił.

Reply to
LukaszS

Obejrzałem i jakże sie cieszę widząc taki styl dokumentacji oraz sposób prezentacji i kontroli danych w programie. to jest to co lubię - kontrola nad każdym detalem. Tak trzymaj! Jedna mała uwaga odnośnie protokołu komunikacyjnego. Stosujesz bajt ETX do oznaczenia końca transmisji. Widziałem wiele trotokołów transmisji i sam napisałem kilka ale nie spotkałem się z czymś takim - po prostu ta informacja jest nadmiarowa. Jeżeli masz nagłówek i ilość danych to wiesz gdzie jest ich koniec. Ten bajt jest zbędny i niepotrzebnie wydłuża czas transmisji. Analogicznie po odebraniu ramki z PC wysyłasz ACK a potem ramkę z danymi. Moim zdaniem ACK jest zbędne. Ramka odpowiedzi jednoznacznie potwierdza otrzymanie polecenia. Polecałbym też rozważyć dodanie indentyfikatora ramki, wystarczy 2-3 bitowy numer. Mnie zdarzało się że przy dużym obciążeniu CPU nie zdążał odpowiedzieć na ramkę a już przychodziła następna, wysłana po timeoucie odbioru. Kontroler odpowiadał wtedy na pierwszą a PC myślał że to odpowiedź na drugą. Mając identyfikator ramki wiadomo co jest odpowiedzą na daną ramkę.

To jeszcze masz duuużo czasu. Ja już nie mam czasu nawet latać ;-)

Reply to
Piotr "Pitlab" Laskowski

Dzięki!

Poniżej skąd wzięły sie pewne rzeczy:

Faktycznie w tym wypadku szybkość ma znaczenie i chyba niepotrzebnie jest tutaj ETX. U mnie służy on do dodatkowej kontroli, czy ostatnim przysłanym bajtem wg LEN jest właśnie ETX. Jednak faktycznie mozna było z tego zrezygnować. No ale teraz jak to już działa, to... jak mówią amerykanie; "nie naprawić sprawnego" :)

To sie wzięlo stąd, że kod programu ma dwie warstwy: warstwę transportową odbierającą pakiety niezależnie od implementacji (u mnie funkcja nazywa się readPacket()). Jej zadaniem jest odebranie pakietu, sprawdzenie poprawności, w razie potrzeby przesłanie NAK lub ACK. W rezultacie przekazuje ona gotowy, nieuszkodzony pakiet drugiej warstwie interpretującej. Pokwitowanie ACK działa więc niezależnie od tego, co jest wewnątrz pakietu. Warstwa odbierająca nie wie, czy na pakiet będzie jakaś odpowiedź, czy nie. Dopiero druga warstwa w zalezności od tego, co jest w pakiecie wyśle odpowiedź lub nie.

Fakt. Rzeczywiście o tym zapomniałem.

Pozdrawiam,

Reply to
LukaszS

Na moje oko masz już 5-10% całości projektu. Na tym etapie zmiany jeszcze nie bolą ;-)

Wydaje mi się że wysyłanie danych niezależnie przez różne warstwy jest niewłaściwe. Moim zdaniem powinna być zachowana wyraźna hierarchia i jedna warstwa nie robi tego co inna. U siebie też mam kilka warstw (symetrycznie w firmware i aplikacji PC):

1) warstwa transportowa odbiera / wysyła dane i umieszcza je w buforach kołowych. Informuje o odebraniu znaku i opróżnieniu bufora. Działa w przerwaniach (pozostałe warstwy działają w pętli głównej). 2) warstwa protokołu, pakuje dane w ramki, wykrywa początki, końce, liczy CRC, przyjmuje dane do wysłania i zwraca dane odebrane. Informuje o wysłaniu i odebraniu fragmentu danych w ramce. Zarządza retransmisjami w przypadku błędu transmisji 3) warstwa poleceń dzieli dane z / do polecenia na ramki. Istotne gdy trzeba przesłać wiele danych, w więcej niż jednej ramce. Sprawdza poprawność wykonania poleceń inicjuje wysłanie informacji o błędzie. 4) warstwa aplikacji odbiera polecenie z interfejsu użytkownika (menu, przyciski itp) i interpretuje informacjem wyświetla komunikaty o błędach. W aplikacji PC każda warstwa jest osobną klasą, w firmware inną procedurą.
Reply to
Piotr "Pitlab" Laskowski

"Marek" snipped-for-privacy@hot.pl napisał(a):

Portal dostępny także - i przede wszystkim - jako

formatting link
(adres rc-cam.pl będzie czynny tylko jeszcze parę miesięcy)

M.

Reply to
marekm

PolyTech Forum website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.