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)?

do góry

On Sat, 29 Mar 2014 13:39:14 +0100, Atlantis <m...@w...pl>
wrote:
> 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 zauważyłem takiego problemu, jak odbieram ramkę z czujnika x to
sa dane czujnika x a nie innego.

--
Marek

do góry

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

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

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.

do góry

On Sat, 29 Mar 2014 14:12:12 +0100, Atlantis <m...@w...pl>
wrote:
> 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.

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

do góry

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

> 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?

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.

do góry

On Sun, 30 Mar 2014 00:19:31 +0100, Atlantis <m...@w...pl>
wrote:
> 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,

I bardzo słusznie.


> 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.

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

do góry

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

> 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

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.



> 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.

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.

do góry

W dniu 2014-03-29 13:39, Atlantis pisze:
[...]
> 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ę.
[...]

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

do góry

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. ;)

do góry

On Sun, 30 Mar 2014 18:10:01 +0200, Atlantis <m...@w...pl>
wrote:
> AT+LED=1,0/r/n

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

do góry