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
http://www.hobbyarea.pl/model_f8_tech.html . 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ł.
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ć ;-)
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.
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ą.
Polytechforum.com is a website by engineers for engineers. It is not affiliated with any of manufacturers or vendors discussed here.
All logos and trade names are the property of their respective owners.