Przesyłanie większych ilości danych pr

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:

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

Reply to
Atlantis
Loading thread data ...

odbiorców

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

Reply to
Marek

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.

Reply to
Atlantis

zabezpieczyć

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?

Reply to
Marek

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.
Reply to
Atlantis

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.

Reply to
Marek

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.

Reply to
Atlantis

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

[...]

Widzę jeszcze jedno:

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

Reply to
RtB

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

Reply to
Atlantis

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.

Reply to
Marek

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

Reply to
Marek

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

Reply to
Atlantis

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

Reply to
Atlantis

ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.