Jak efektywnie przesyłać dane >8B przez magistralę CAN z wykorzystaniem ISO-TP?

Sat Mar 29, 2014 1:39 pm   

Kontynuuję temat, który już kiedyś tutaj poruszałem.
Jak wspominałem, potrzebuję rozwiązania, które umożliwiłoby mi
przesyłanie przez magistralę CAN danych o rozmiarze większym, niż
pozwala na to pojedyncza ramka (8 bajtów). Chciałbym skomunikować
urządzenia przy pomocy komend AT, przesyłać teksty do wyświetlenia na
zdalnym LCD itp.

Proste zapisywanie komend w jakimś buforze odbiorczym nie wchodzi w grę,
bo jak wiadomo magistrala CAN jest magistralą multimaster. Istnieje więc
możliwość, że w trakcie odbierania wiadomości od jednego urządzenia,
wtrąci się jakieś inne i poszczególne ramki przemieszają się w jednym
buforze odbiorczym. Stosowanie osobnego bufora dla każdego z odbiorców
nie wchodzi w grę w małych MCU, a więc widzę tutaj jedynie dwa rozwiązania:

1. Jakieś sprytne wydzielanie z bufora tylko tego, czego nam potrzeba,
już po stwierdzeniu odebrania końca wiadomości. Ramki składające się na
przychodzące wiadomości od niepasujących nadawców trzeba by wtedy
przepisywać do innych komórek, robiąc coś w rodzaju "defragmentacji",
uważając jednocześnie, by nic nie zostało nadpisane w momencie
jednoczesnego przyjścia przerwania RX.
2. Upewnienie się, że nic nie zacznie nadawać kolejnej wiadomości, zanim
nie skończymy odbierać obecnej. Innymi słowy urządzenie wysyła prośbę o
nawiązanie połączenia. Jeśli mamy wolną linię (i pusty bufor) wysyłamy
mu ACK. Od tego momentu do otrzymania końca wiadomości (albo timeoutu) w
buforze zapisywane są tylko ramki z tego adresu. Zapytania od innych
chętnych do nawiązania transmisji skutkują prośbą o chwilowe wstrzymanie
się.

Nie chciałbym wyważać otwartych drzwi, jeśli istnieje już jakieś
rozwiązanie. Ktoś kiedyś polecał standard ISO-TP. Znalazłem dzisiaj coś
takiego:

https://github.com/openxc/isotp-c

Wikipedia mówi, że ten standard pozwala na przesyłanie 4095 bajtów
danych. To znacznie więcej, niż potrzebuję (myślę, że 200 bajtów to aż
nadto). Jednak w opisie biblioteki trafiłem na fragment, który wyowłał u
mnie konsternację:

"The current version supports only single frame ISO-TP messages. This is
fine for OBD-II diagnostic messages, for example, but this library needs
some additional work before it can support sending larger messages."

Ktoś może mi powiedzieć o co chodzi? To chyba jakaś pomyłka? Po co
tworzyć taką bibliotekę, skoro koniec końców nie potrafiłaby ona
przesłać więcej danych, niż potrafi obsłużyć sprzętowo sam kontroler
CAN? Jeśli jednak przy pomocy tej biblioteki mógłbym wysyłać i odbierać
większe porcje danych, to czy istnieje szansa, że odpalę ją na jednym z
większych ośmiobitowych AVR-ów (Mega644, Mega128, AT90CAN128)?

Sat Mar 29, 2014 2:01 pm   

On Sat, 29 Mar 2014 13:39:14 +0100, Atlantis <marekw1986NOSPAM@wp.pl>
wrote:


Nie zauważyłem takiego problemu, jak odbieram ramkę z czujnika x to
sa dane czujnika x a nie innego.

--
Marek

Sat Mar 29, 2014 2:12 pm   

W dniu 2014-03-29 14:01, Marek pisze:


Bo cały czas mówisz o jednej ramce, która może zawierać maksymalnie 8
bajtów danych. Tutaj wszystko jest realizowane sprzętowo przez
kontroler. Mi chodzi o przesyłanie większej ilości danych, poprzez
ładowanie zawartości kolejnych nadchodzących ramek do dużego bufora
odbiorczego. W tym przypadku trzeba by już w jakiś sposób zabezpieczyć
się przed wzajemnym przemieszaniem ramek składających się na kilka
różnych wiadomości od kilku różnych nadawców.

Sat Mar 29, 2014 10:31 pm   

On Sat, 29 Mar 2014 14:12:12 +0100, Atlantis <marekw1986NOSPAM@wp.pl>
wrote:

Z tego co kojarzę szukasz magistrali do automatyki domowej, czy czego
Ci brakuje w CAN do realuiacji sterowania urządzeniami, czy czasem
nie za bardzo kombinujesz?

--
Marek

Sun Mar 30, 2014 12:19 am   

W dniu 2014-03-29 22:31, Marek pisze:


1) Jakoś nie lubię binarnego kodowania komend. Preferuję ASCII i coś na
wzór komend AT lub konsoli. Bardziej zbliżone do naturalnego języka,
łatwiejsze do analizy.
2) W przyszłości może się okazać, że do magistrali podłączę urządzenie
wymagające przesłania większej ilości danych (np. łańcuch tekstowy). I
co wtedy? Jeśli teraz zastosuję protokół umożliwiający wysyłanie dużych
pakietów, to potem nie będę miał takiego problemu.

Sun Mar 30, 2014 11:55 am   

On Sun, 30 Mar 2014 00:19:31 +0100, Atlantis <marekw1986NOSPAM@wp.pl>
wrote:

I bardzo słusznie.



Ok, tylko jak w przyszłości chcesz wysyłać duże pakiety to może CAN
już nie zabardzo jest rozwiązaniem idealnie pasującym do realizacji
założonych celów w zakresie tej komunikacji. Oczywiście można się
uprzeć i "pchać" to po CAN ale czyż to nie jest właśnie to
(prze)kombinowanie?
Tak próbuje sobie wyobrazić co można chcieć przesyłać między
urządzeniami wykonawczymi co by nie zmieściło się w 8 bajtach..., daj
jakiś konkretny przykład, tak z ciekawości pytam.

--
Marek

Sun Mar 30, 2014 4:10 pm   

W dniu 2014-03-30 13:55, Marek pisze:


Nie bardzo widzę tutaj jakąś alternatywę.
RS485? Brak sprzętowej obsługi trybu multimaster, wykrywania kolizji
transmisji oraz błędów. Trudność z programową implementacją powyższych
funkcji.
Ethernet? Niby idealne rozwiązanie, ale wymaga odpowiedniej
infrastruktury po drodze. Wystarczy, że ktoś wyjmie z gniazda zasilacz
jednego switcha, a jakiś fragment sieci leży, a razem z nim pada
fragment systemu automatyki. No i trzeba pamiętać, że tak czy inaczej
potrzebuję wyższych warstw stosu.
CAN ma tą zaletę, że wykorzystuje topologię magistrali. Wystarczy
pociągnąć kawałek kabla między urządzeniami i zamontować terminatory na
końcach.
Podobny efekt niby dałoby się osiągnąć starym Ethernetem na koncentryku,
ale to dopiero byłoby kombinowanie. Na dobrą sprawę w grę wchodziłoby
chyba tylko wykorzystanie starej karty ISA. Że nie wspomnę o mniejszej
odporności na zakłócenia.

Z dostępnych rozwiązań magistrala CAN wydaje się być najbardziej
odpowiednia.




Chociażby dłuższa komenda AT wraz z parametrami.
AT+LED=1,0/r/n

To już dwanaście znaków, a przecież nie jest specjalnie długa! Można
sobie wyobrazić dłuższe komendy. Nie wspominając już o sytuacji, kiedy
chciałbym przesłać ciąg tekstowy.

Sun Mar 30, 2014 6:45 pm   

W dniu 2014-03-29 13:39, Atlantis pisze:
[...]


Widzę jeszcze jedno:
3. Jeśli to jest system automatyki domowej, to i tak zapewne będzie miał
centralkę. Zorganizować komunikację tak, że węzły odpowiadają tylko na
zapytania centralki. Większość problemów rozwiązuje się sama w takim
układzie. Gdyby to nie było służbowe, mógłbym Ci podrzucić specyfikację
takiego rozwiązania - niestety, jest.

A ad. 1 - kontrolery CAN mają wbudowane filtry sprzętowo maskujące ID.
Wystarczy wykorzystać - po prośbie o nawiązanie połączenia ustawić filtr
i voila - słychać tylko żądany ID. Jednak w zależności od kontrolera CAN
może to mieć tę wadę, że do zmiany maski w filtrze potrzebne jest
chwilowe wyłączenie kontrolera (vide ECAN w PIC32).

I apropos ISO-TP - nie powinien być trudny do obsłużenia samemu. Nie
wiem, czy gdzieś na Sieci będą otwarte biblioteki do tego protokołu -
jego główne (jedyne?) zastosowanie jest w systemach automotive.

Pozdrawiam,

Piotr

Sun Mar 30, 2014 7:57 pm   

Tak na dobrą sprawę to wydaje mi się, że mógłbym nawet spróbować napisać
odpowiedni prosty "stos". Pierwszy bajt danych w ramce CAN przeznaczony
na wartość określającą typ pakietu. Jedna wartość oznaczałaby prośbę o
nawiązanie połączenia, inna zgodę lub odpowiedź odmowną. Potem szłyby
pakiety z kolejnymi porcjami danych, aż do otrzymania informacji o
zakończeniu transmisji.
Dodatkowo jakiś timer w razie czego ubijałby transmisję, która z
jakiegoś powodu nie doszła do skutku, zwalniając linię dla następnych
połączeń.

Po prostu zanim się za to zabiorę, stracę mnóstwo czasu i napiszę coś
bardzo prostego i mało funkcjonalnego, wolę się przekonać, czy ktoś już
tego nie zrobił lepiej.

Nie chce mi się wierzyć, że wszyscy jadą na tych ośmiobitowych ramkach.

Sun Mar 30, 2014 11:48 pm   

On Sun, 30 Mar 2014 18:10:01 +0200, Atlantis <marekw1986NOSPAM@wp.pl>
wrote:

Z 3 znaków iAT+) można od razu zrezygnować, po co je powtarzać skoro
zawsze wystepują?
Po co dwa znaki na terminowanie linii? Jeden wystarczy. A właściwie
po co terminowanie linii, fixed size packed rozwiąze problem
terminowania... itd. Format konunikatow AT nic nie wnosi oprócz tego
że ładnie wygląda dla człowieka a dość komplikuje komunikację.
Nie upierałbym się go stosowac przy komunikacji włącz/włącz.

--
Marek

Sun Mar 30, 2014 11:52 pm   

On Sun, 30 Mar 2014 21:57:53 +0200, Atlantis <marekw1986NOSPAM@wp.pl>
wrote:

Ale masz już chociaż że dwa dzialajace nody i testujesz komunikację
czy ciągle na etapie teoretycznych rozważan to jest?

--
Marek

Mon Mar 31, 2014 9:51 am   

W dniu poniedziałek, 31 marca 2014 01:48:41 UTC+2 użytkownik Marek napisał:


Te trzy znaki powinny zostać. Standardowo stosuje się je celem odróżnienia zapytania od odpowiedzi. Zwykle po wykonaniu polecenie przychodzi oś takiego:

+LED: 1,0



Masz rację. W tym przypadku faktycznie można z nich zrezygnować. W pakietach UDP też ich nie przesyłam, kończąc linię pojedynczym znakiem NULL. Znaczenie mają tylko w komunikacji RS232, gdzie trzeba jakoś wydzielić poszczególne linie.



Zgodziłbym się, gdybym musiał pisać ich obsługę od podstaw. Istnieją jednak całkiem fajne biblioteki, z których lubię korzystać. Dlatego zależy mi, żeby interfejs (w tym przypadku CAN) umożliwiał przesyłania danych w kompatybilnym formacie.

Osiem bajtów to po prostu za mało jak na wygodną obsługę komend AT. Nawet jeśli zrezygnuję ze standardowych trzech pierwszych znaków albo terminowania linii. Wystarczy, że trzeba będzie wysłać więcej wartości, albo wartość będzie zapisywana przy użyciu kilku cyfr ASCII (np. współczynnik wypełnienia PWM).

Mon Mar 31, 2014 9:55 am   

W dniu poniedziałek, 31 marca 2014 01:52:43 UTC+2 użytkownik Marek napisał:


Teoretyczne rozważania. To znaczy na tym etapie mam prosty "prototyp", na którym testuję podstawową koncepcję. On jednak nie jest wyposażony w magistralę CAN, jedynie Ethernet i port szeregowy. W tej chwili projektuję właściwe urządzenie, które zostanie zabudowane w obudowie na szynę DIN.

Tak czy inaczej wyposażę je w interfejs CAN, bo stosowany przeze mnie AT90CAN128 posiada sprzętowy kontroler.

Teraz po prostu chciałem się zorientować jak wygląda sytuacja z dostępnością bibliotek. Jeśli faktycznie nie uda mi się niczego znaleźć, spróbuję to jakoś oprogramować.