Protokół portu szeregowego (RS232): wymagania

Już kiedyś pisałem o porcie szeregowym przy okazji modułu bluetooth HC-05. W tamtym wpisie w bardzo prosty sposób (wysyłanie literek r, g, b, o) sterowałem diodami LED. Jednak dla bardziej zaawansowanych czynności taki "protokół" się nie sprawdzi. Na przykład w pierwszej linii wyświetlacza LCD trzeba wyświetlić tekst? Jak To zrobić? Co wysłać? Jak odebrać? W tym i następnych wpisach, spróbuję przekazać jak sobie w takiej sytuacji poradzić.

Przez ostatnie kilka lat naoglądałem się różnych protokołów. Jeśli nie chcecie wymyślać koła do wozu to polecam stronę Embedded Systems/Common Protocols. Może akurat któryś się nada. Szczególnie należy sprawdzić protokół Modbus. Chociaż uważam, że nie jest on najlepszy, bo detekcja ramek bazuje na czasach przerwy w transmisji (RTU). Jeśli jednak już sami będziemy wymyślać protokół, to według mnie należy przestrzegać następujących reguł:

•  (ten punkt miał być na końcu, ale przeniosłem go na początek, bo jest najważniejszy)
  
  w dokumentacji protokołu, dajemy przykłady całych ramek, bajt po bajcie. Jeśli ramki występują w sekwencji, to dajmy przykłady bajt po bajcie całych sekwencji. Taka dokumentacja pomoże w napisaniu testów jednostkowych
• ramka transmisyjna powinna zaczynać się specjalnym znacznikiem początku, a kończyć specjalnym znacznikiem końca
• jeśli ramka nie jest stałej długości powinna zawierać informację o długości - alternatywą jest byte stuffing/escaping, ale ja osobiście bym tego unikał.
• w systemach gdzie niedozwolone jest przekłamanie w danych polecenia (prawie wszędzie), ramka powinna zawierać CRC, a w pozostałych przypadkach (zabawy) można dodać sumę kontrolną
• ramka powinna być jak najprostsza i jak najkrótsza
• powinniśmy unikać konstrukcji "user frendly" np. przesyłania komend czy parametrów tekstem tylko po to, aby ramka ładnie się wyświetlała w konsoli podczas debugowania
• jeśli przesyłać będziemy znaczne ilości danych np. obrazy BMP powinniśmy zadbać o kompresję np. RLE
• każda komenda powinna być zakończona odpowiedzią, nawet jeśli komenda jest błędna lub nieobsługiwana
• jeśli komenda przestawia jakąś wartość, to powinna też być komenda, która tą wartość pobiera
• należy unikać komend, które przełączają; lepszym rozwiązaniem jest włączanie i wyłączanie