Elektroda.pl
Elektroda.pl
X
Elektroda.pl
Proszę, dodaj wyjątek dla www.elektroda.pl do Adblock.
Dzięki temu, że oglądasz reklamy, wspierasz portal i użytkowników.

Wykrycie startu ramki CAN

05 Sie 2011 10:32 2465 13
  • Poziom 10  
    Witam,

    w ramach edukacyjnych tworzę układ symulujący magistralę CAN oraz możliwe uszkodzenia, jakie można spotkać w tejże magistrali. Całość oparta jest na procku P80C592 i transceiverze 82C250. Sprawa dotyczy symulacji uszkodzeń. Otóż układ ma mieć możliwość wystąpienia uszkodzenia w różnych miejscach ramki - pole identyfikatora, długości danych, w polu danych, w polu CRC itd. Uszkodzenia będą symulowane w trybie pracy ręcznej - po wybraniu miejsca uszkodzenia ustawiane są dane do transmisji i jest wysyłana jedna ramka. I tu dochodzimy do sedna problemu - jak wyliczyć w którym momencie zasymulować uszkodzenie.
    Pomysł jest taki, że na osobny procek zajmujący się tylko sumulowaniem uszkodzeń, będzie sobie zliczał czas, jaki upłynął od startu transmisji (prędkość z góry narzucona, więc znany jest czas trwania bitu). Problemem jest wykrycie startu transmisji - z procesora P80C592 po ustawieniu bitu żądania transmisji CAN podaję info na procek od symulowania uszkodzeń, ale trzeba będzie też fizycznie wykryć, kiedy nastąpi zmiana stanu z recesywnego do dominującego - start ramki CAN. Czy ktoś mógłby podpowiedzić, jak to zrealizować?
  • Poziom 19  
    Pewnie najprościej i najpewniej będzie się podpiąć jakimś GPIO pod pin Rx CANa i włączyć przerwanie zewnętrzne z '1' na '0'. Patrząc na parametry czasowe ramki (obojętnie 'A' czy 'B'):
    http://en.wikipedia.org/wiki/Controller_area_network
    to na końcu leci EOF czyli siedem jedynek. Jakbyś odpalił to przerwanie zewnętrzne na dwa zbocza i zaprzągł timer to możesz wykrywać czas kiedy co najmniej wystąpiło 7 bitów '1' i byś potem wiedział, że następne zbocze opadające to SOF.

    EDIT:
    chociaż z tymi jedynkami to się rozpędziłem bo w środku przecież w danych też mogą wystąpić :)
  • Poziom 35  
    nibbit napisał:
    chociaż z tymi jedynkami to się rozpędziłem bo w środku przecież w danych też mogą wystąpić

    Nie, nie mogą. Po to jest bit stuffing, zeby nie wystąpiły.

    Te jedynki na koncu ramki to nie EOF, tylko interframe space.

    Temat jest prosty - z stanu recesywnego który trwa "interframe space", SOF jest pierwszą zmianą stanu recesywnego na dominujący. Procesor, który wprowadza zakłócenia na magistralę, musi software'owo emulować kontroler CAN, aby być w synchronizacji bitowej z wysyłanymi danymi, tak, aby potencjalne uszkodzenie móc precyzyjnie "wstrzelić" w konkretne TQ.

    Posiłkuj się specyfikacją bezposrednio od Bosha CAN2.0B, nie wikipedią...
  • Poziom 19  
    Jakby nie patrzeć w nocie Boscha:
    END OF FRAME
    Each DATA FRAME and REMOTE FRAME is delimited by a flag sequence consisting of seven 'recessive' bits.
    Dopiero potem jest interframe space.

    A z tym stuffingiem dobrze wiedzieć. Nigdy tak głęboko nie wnikałem, nie miałem potrzeby robienia zderzacza, tych no .... bitów :)
  • Poziom 35  
    Racja, tam idzie siedem bitów recesywnych przed interframe space ;]
  • Poziom 10  
    [quote="nsvinc"]
    nibbit napisał:

    Temat jest prosty - z stanu recesywnego który trwa "interframe space", SOF jest pierwszą zmianą stanu recesywnego na dominujący. Procesor, który wprowadza zakłócenia na magistralę, musi software'owo emulować kontroler CAN, aby być w synchronizacji bitowej z wysyłanymi danymi, tak, aby potencjalne uszkodzenie móc precyzyjnie "wstrzelić" w konkretne TQ.


    Czyli tak(jeśli dobrze kminię), najprościej będzie wykryć SOF z wejścia TxD transceivera a później na drugim procku zaemulować transmisję ramki CAN, której dane (ID,DLC,RTR,data) wcześniej przesłałem np przez RS? Tak w sumie nie myślałem, bo cały czas myślałem jak wykryć SOF będąc wpiętym bezpośrednio do magistrali pod CAN H i CAN L.
  • Poziom 35  
    Mam wrazenie ze zupełnie poplątałeś. Aby robić takie testy o których piszesz, musisz mieć DWA urządzenia gadające ze sobą CANem. To, czy te dwa urządzenia będą miały kontroler sprzętowy czy nie, to ogólnie wszystko jedno (zalezy od ciebie co chcesz badać - jedno z nich może mieć kontroler emulowany).
    Na linię po której gadaja sobie powyższe DWA urządzenia, podłączasz TRZECIE - zakłócacz, który musi mieć emulowany kontroler, aby prawidłowo niszczyć i przekłamywać transmisję.
  • Poziom 19  
    Cytat:
    z procesora P80C592 po ustawieniu bitu żądania transmisji CAN podaję info na procek od symulowania uszkodzeń, ale trzeba będzie też fizycznie wykryć, kiedy nastąpi zmiana stanu z recesywnego do dominującego - start ramki CAN.


    Jak na moje przekombinowane albo źle zrozumiałem. W urządzeniu od symulowania uszkodzeń podpiąć się prościej pod Rx (niech sobie sam wykryje kiedy się zaczęła nadawana ramka przez inne urządzenie).

    Druga sprawa to pamiętaj, że jak nadajesz jednym urządzeniem po CANie to tym Twoim "uszkadzaczem" nic przez CANa nie wyślesz. Po tam tam jest arbitraż i wykrywanie kolizji na warstwie sprzętowej. Możesz jedynie wykryć tym testerem początek transmisji i jakimś dodatkowym układem elektronicznym ustawić stan dominujący (0) na linii.
  • Poziom 35  
    Nie aż tak. Wstrzeliwać stany dominujące można gdziekolwiek. O to chodzi, aby niszczyć transmisję, przynajmniej tak rozumiem bieżący temat.
    W przeciętnej ramce masz kilkanaście TQ na bit okazji na zakłócenie stanu linii. Arbitraże i inne zabezpieczenia powinny wykryć niespójne dane i transmisję przerwać, po jakimś czasie w końcu generujac active bus error. Nie ma sensu przekłamywać stanu TQ-ów na początku ramki, bo wtedy kontroler po prostu to oleje i przestanie nadawać.

    Dodatkowo, software'owy kontroler CAN w "zakłócaczu" nie musi żadnego arbitrażu ani wykrywania kolizji obsługiwać, powinien jedynie na siłę wbijać stan dominujący na siłę w momentach "losowych" dla aktualnie nadającego.
  • Poziom 10  
    nsvinc napisał:
    Mam wrazenie ze zupełnie poplątałeś. Aby robić takie testy o których piszesz, musisz mieć DWA urządzenia gadające ze sobą CANem. To, czy te dwa urządzenia będą miały kontroler sprzętowy czy nie, to ogólnie wszystko jedno (zalezy od ciebie co chcesz badać - jedno z nich może mieć kontroler emulowany).
    Na linię po której gadaja sobie powyższe DWA urządzenia, podłączasz TRZECIE - zakłócacz, który musi mieć emulowany kontroler, aby prawidłowo niszczyć i przekłamywać transmisję.


    Może źle sformułowałem problem, mam oczywiście kilka węzłów, które się z sobą komunikują, każda transmisja jest wyzwalana przez użytkownika, przewidziany będzie też tryb, żeby układ pracował ciągle (wysyłał i odbierał dane bez potrzeby inicjowania ze strony użytkownika, poza rozpoczęciem pracy ciągłej). Symulowanie uszkodzeń myślałem zastosować dla trybu nazwijmy go ręcznego.

    nibbit napisał:
    W urządzeniu od symulowania uszkodzeń podpiąć się prościej pod Rx (niech sobie sam wykryje kiedy się zaczęła nadawana ramka przez inne urządzenie).


    Myślałem o generowaniu uszkodzeń tylko gdy transmija będzie z tego konkretnego węzła, do którego układ zakłócający będzie podłączony, ale w sumie można i tak :)

    nsvinc napisał:

    Dodatkowo, software'owy kontroler CAN w "zakłócaczu" nie musi żadnego arbitrażu ani wykrywania kolizji obsługiwać, powinien jedynie na siłę wbijać stan dominujący na siłę w momentach "losowych" dla aktualnie nadającego.


    Chodzi o symulowanie uszkodzeń typu zwarcie do GND/Vcc, przerwa na CAN L/CAN H - tutaj myślę o wykorzystaniu buforów trójstanowych 74LS126 z wyjściem podłączonym bezpośrednio do szyn magistrali, a przerwę chyba najprościej będzie zasymulować tranzystorem - podczas wstępnego testowania tego rozwiązania wszystko działało.
  • Poziom 10  
    Muszę odkurzyć temat, symulowanie transmisji ramki gotowe, jednak o ile z symulowaniem zwarcia do masy/napięcia zasilającego jest ok, mam problem z zasymulowaniem przerwy na linii. Pomysł z wykorzystaniem klucza na tranzystorze działa tylko połowicznie - w zależności od tego, jak podłącze źródło i dren, ramki są albo wysyłane albo odbierane. Gdy zastosuję drugi tranzystor włączony przeciwnie pomysł całkiem upada - ramki są wysyłane i odbierane niezależnie od poziomu sygnału sterującego. Czy ktoś pomoże, jak ten problem ugryźć?

    Wykrycie startu ramki CAN
  • Poziom 33  
    Może jakiś klucz dwustronny w stylu CD4066 w wersji niskoomowej?

    N.
  • Poziom 10  
    Nawigator napisał:
    Może jakiś klucz dwustronny w stylu CD4066 w wersji niskoomowej?

    Dzięki za podpowiedź, pewnie to będzie działać, sprawdzę niestety dopiero w poniedziałek.

    Edit - niestety, w teorii powinno działać, w praktyce jednak nie. Po zasileniu układu tym samym napięciem co transceiver, po podaniu logicznej 1 na wejścia kontrolne komunikacji brak. Gdy podłączę klucz tylko do jednej linii - CAN H lub CAN L, komunikacja jest.