eGospodarka.pl
eGospodarka.pl poleca

eGospodarka.plGrupypl.misc.elektronikaPrzesyłanie większych ilości danych przez CAN
Ilość wypowiedzi w tym wątku: 13

  • 1. Data: 2014-03-29 13:39:14
    Temat: Przesyłanie większych ilości danych przez CAN
    Od: Atlantis <m...@w...pl>

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


  • 2. Data: 2014-03-29 14:01:59
    Temat: Re: Przesyłanie większych ilości danych przez CAN
    Od: Marek <f...@f...com>

    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


  • 3. Data: 2014-03-29 14:12:12
    Temat: Re: Przesyłanie większych ilości danych przez CAN
    Od: Atlantis <m...@w...pl>

    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.


  • 4. Data: 2014-03-29 22:31:54
    Temat: Re: Przesyłanie większych ilości danych przez CAN
    Od: Marek <f...@f...com>

    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


  • 5. Data: 2014-03-30 00:19:31
    Temat: Re: Przesyłanie większych ilości danych przez CAN
    Od: Atlantis <m...@w...pl>

    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.


  • 6. Data: 2014-03-30 13:55:56
    Temat: Re: Przesyłanie większych ilości danych przez CAN
    Od: Marek <f...@f...com>

    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


  • 7. Data: 2014-03-30 18:10:01
    Temat: Re: Przesyłanie większych ilości danych przez CAN
    Od: Atlantis <m...@w...pl>

    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.


  • 8. Data: 2014-03-30 20:45:57
    Temat: Re: Przesyłanie większych ilości danych przez CAN
    Od: RtB <radagast.SPAMOWI.@.NIE.onet.pl>

    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


  • 9. Data: 2014-03-30 21:57:53
    Temat: Re: Przesyłanie większych ilości danych przez CAN
    Od: Atlantis <m...@w...pl>

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


  • 10. Data: 2014-03-31 01:48:41
    Temat: Re: Przesyłanie większych ilości danych przez CAN
    Od: Marek <f...@f...com>

    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

strony : [ 1 ] . 2


Szukaj w grupach

Szukaj w grupach

Eksperci egospodarka.pl

1 1 1

Wpisz nazwę miasta, dla którego chcesz znaleźć jednostkę ZUS.

Wzory dokumentów

Bezpłatne wzory dokumentów i formularzy.
Wyszukaj i pobierz za darmo: