Protokół LIN

Jak mogliśmy się przekonać, interfejs CAN jest bardzo dobrym rozwiązaniem do realizacji względnie szybkiej transmisji danych pomiędzy równoprawnymi węzłami. Tak rozbudowany protokół nie jest jednak zawsze konieczny, na przykład odczytywanie stanu czujników rozmieszczonych w samochodzie przez komputer pokładowy można zrealizować znacznie prościej. Do takich potrzeb opracowano interfejs LIN (Local Interconnect Network), stanowiący uzupełnienie CAN-a. Daje się go zrealizować znacznie prostszymi środkami, wystarczy do tego celu choćby tani mikrokontroler dysponujący interfejsem UART. W specyfikacji LIN można doszukać się podobieństw z poznanymi już protokołami UART i I²C, jednak istotną różnicę stanowi wykorzystanie tylko jednej linii transmisyjnej. Do wad należy zaliczyć dość niewielką prędkość transmisji, dochodzącą zaledwie do 20 kb/s. Przy tak małych prędkościach nie ma jednak problemów z zachowaniem synchronizacji, nawet przy zastosowaniu prostych oscylatorów. Do ich budowy nie są nawet konieczne rezonatory kwarcowe, wystarczą ceramiczne. Transmisja jest asynchroniczna synchronizowana na ramkach.

Protokół LIN, podobnie jak SPI czy I²C wymaga podziału kompetencji wśród dołączonych urządzeń. W tzw. klastrze dopuszcza się występowanie co najwyżej 16 węzłów, tworzy go więc jeden Master (obowiązkowo) oraz do 15 Slave’ów. Po wyposażeniu Slave’a w zwielokrotniony interfejs fizyczny może on jednak pracować w kilku klastrach. Master realizuje zarówno swoje zadania (master task), jak i zadania Slave’a (slave task). Magistrala LIN ma budowę jak na rys. 9.

Rys. 9. Magistrala LIN

Ramka protokołu LIN składa się z nagłówka będącego zadaniem Mastera i odpowiedzi generowanej przez Slave’a (rys. 10). Z kolei w nagłówku wyróżnia się komunikaty (pola) „Synch Break”, „Sync Field” i „Ident Field”. Komunikat „Synch Field” zawiera sekwencję synchronizującą informującą urządzenia o prędkości transmisji. Poprzedza go przerwa synchronizująca trwająca co najmniej 13 bitów. Komunikat „Ident Field” zawiera identyfikator wiadomości, po którym dołączone do magistrali urządzenia rozpoznają czy przesyłane po nagłówku dane są adresowane do nich czy do innych urządzeń. W poprawnie zaprojektowanej magistrali LIN nie występują konflikty, ponieważ wszystkie węzły Slave tylko odpowiadają na zapytania  Mastera. Nie przewidziano arbitrażu na przykład w przypadkach jednoczesnej odpowiedzi kilku Slave’ów. Jeśli tak się stanie, musi być sygnalizowany błąd. Do wykrywania błędów wykorzystywana jest m.in. suma kontrolna przesyłana w każdym polu danych. Ponadto każdy nadajnik na bieżąco sprawdza czy stan linii odpowiada wysyłanej informacji i reaguje natychmiast, jeśli wykryje niezgodność.

Rys. 10. Ramka protokołu LIN

Wszystkie komunikaty oprócz synchronizujących mają budowę przypominająca ramkę protokołu UART. Składają się więc z bitu startu, 8 bitów informacyjnych i bitu stopu. Dane są przesyłane od najmłodszego do najstarszego bitu. Jak widać, nie ma tu wyróżnionego bitu parzystości, ale w polu identyfikacyjnym przekazującym informację o nadawcy, odbiorcy (jednym lub wielu), celu ramki i długości pola danych, dwa ostatnie bity pełnią taką funkcję. Na samą treść pozostaje więc 6 bitów. Znając już cel transmisji określany przez Mastera w identyfikatorze, odpowiednie urządzenia Slave przesyłają odpowiedź składającą się z pola danych (1, 2, 4 lub 8 bajtów) i sumy kontrolnej.

Specyfikacja LIN zakłada ponadto możliwość usypiania urządzeń dołączonych do magistrali. Jest to realizowane przez przesłanie ramki usypiającej. Wyłączenie wyjść wszystkich urządzeń dołączonych do magistrali powoduje, że na linii panuje stan recesywny. Urządzenia budzą się po wystawieniu stanu dominującego (o czasie trwania odpowiadającym 8 bitom) przez dowolny węzeł dołączony do magistrali. Sygnał budzenia musi wyprzedzać najbliższą ramkę o czas odpowiadający 4…64 bitów.

Pomiary interfejsu LIN

Jak zwykle pomiary rozpoczynamy od ustawienia parametrów badanego interfejsu, w tym przypadku LIN. Po naciśnięciu przycisku PROTOCOL na ekranie zostaje wyświetlona zakładka przedstawiona na rys. 11. W polu „Bit rate” należy wprowadzić prędkość transmisji badanego interfejsu. Może to być dowolna wartość wpisana ręcznie lub jedna z opcji widocznych na liście rozwijanej. Oprogramowanie analizatora protokołów uwzględnia kilka wersji specyfikacji LIN, którą można wybrać z listy „LIN standard”. W większości pomiarów można skorzystać z automatycznego rozpoznawania standardu (opcja „Auto”). Pozostaje jeszcze wybranie wersji napięciowej części elektrycznej interfejsu. Tu również można skorzystać z predefiniowanych standardów dostępnych przez listę rozwijaną. Próg logiki jest też ustawiany ręcznie, gdyby badane były nietypowe rozwiązania sprzętowe. Po tych czynnościach analizator jest już gotowy do pracy.

Rys. 11. Zakładka konfiguracyjna dla protokołu LIN

Pomiary najczęściej polegają na sprawdzeniu czy w badanym systemie występują określone zdarzenia. Tak jak w poprzednich przykładach, i teraz najlepiej jest korzystać z odpowiednio dobranych zdarzeń wyzwalających. Pozwolą one jednoznacznie i stabilnie uchwycić interesujący nas stan interfejsu. Może też okazać się, że po ustawieniu układu wyzwalania w tryb „Normal” oscyloskop nie będzie wyzwalany, a jest to też jest informacja, mówiąca o tym, że określone zdarzenie nie występuje w badanym układzie. Powinno nas to szczególnie zadowolić, gdy poszukiwane będą błędy.

Opcje wyzwalania są dostępne po naciśnięciu przycisku TRIGGER (rys. 12). Teraz trzeba się zdecydować, która z opcji listy rozwijanej „Type” będzie najlepsza w konkretnym przypadku. Pamiętamy o ustawieniu trybu wyzwalania „Normal”, który w większości przypadków będzie bardziej odpowiedni niż „Auto”. Po wybraniu zdarzenia wyzwalającego „Start of frame (Sync)” prawdopodobnie obraz nie będzie w pełni stabilny, gdyż będą na nim wyświetlane początki coraz to innych ramek. Opcja ta jest przydatna, gdy na magistrali LIN nie ma zbyt dużego ruchu.

Rys. 12. Zakładka wyboru zdarzeń wyzwalających dla protokołu LIN

Znacznie efektywniejsze będzie wyzwalanie na ramce o określonym identyfikatorze („Identifier”). Nie musi to być zresztą konkretna wartość, można zastosować również którąś z relacji: różny, mniejszy, większy, z zakresu, spoza zakresu. Po zdekodowaniu komunikatu identyfikacyjnego spełniającego wybrany warunek oscylogram zostaje stabilnie wyświetlony na ekranie (rys. 13). Jeśli w rekordzie wyświetlania oscyloskopu znajdzie się kilka ramek o tym samym identyfikatorze przyjętym do wyzwolenia, wyzwolenie nastąpi na pierwszej takiej ramce. Opcja „Identifier OR” pozwala natomiast monitorować do czterech ramek o zdefiniowanych przez użytkownika identyfikatorach. Wyzwolenie nastąpi na pierwszej ramce spełniającej jeden z tych warunków. Cyfry wyświetlane przy opcjach na zakładce wyzwalania (rys. 12) nie mają więc znaczenia praktycznego. Każdą z czterech pozycji można za to zaznaczać lub odznaczać, przez co wybierane są tylko te identyfikatory, które mają być monitorowane.

Rys. 13. Wyzwolenie po zlokalizowaniu ramki o identyfikatorze 3Dh