logo elektroda
logo elektroda
X
logo elektroda
REKLAMA
REKLAMA
Adblock/uBlockOrigin/AdGuard mogą powodować znikanie niektórych postów z powodu nowej reguły.

Konwerter CAN - światłowód bez uC - czy to możliwe?

Svavo 24 Mar 2017 14:04 5079 6
REKLAMA
  • #1 16368191
    Svavo
    Poziom 23  
    Koledzy i Koleżanki,
    pytanie jak w temacie. Czy możliwe jest zbudowanie "biernego" (takiego bez mikrokontrolera) konwertera CAN - FO? Z konwersją z interfejsów RS232/RS422/RS485 na światłowód nie ma problemu ze względu na przesyłanie kompletnej ramki w jednym kierunku. W przypadku magistrali CAN, odsyłany jest bit potwierdzenia z węzła znajdującego się po drugiej stronie światłowodu. Poza tym transceivery CAN nie mają wyprowadzenia typu załączania nadajnika (dane są nadawane i odbierane "jednocześnie"). Jest wiele rozwiązań komercyjnych, ale mam wrażenie, że wszystkie są oparte o uC.
    Mam pewną, stosunkowo prosta koncepcję realizacji, nawet sprawdzonej i działającej, ale chciałbym wysłuchać Waszej opinii na ten temat. A może ktoś z Was coś takiego popełnił i mógłby podzielić się wiedzą?
  • REKLAMA
  • #2 16368322
    krisRaba
    Poziom 31  
    Hmm, ciekawe pytanie. Standardowy transceiver nie ma innych sygnałów niż D i R po stronie MCU, więc tak jak piszesz, to co wysyłasz na CAN odbierasz zawsze z powrotem. Wiadomo, że ten mechanizm jest wykorzystywany do sprzętowego wykrywania kolizji itp. Jeśli ma to być konwerter punkt-punkt, a po obu końcach CAN, to na logikę wystarczyłoby wyprowadzić D i R na nadajnik/odbiornik FO i po drodze zrobić krosowanie. Jeśli taka konwersja nie wprowadzi znaczących opóźnień, które mogłyby zakłamywać "read-back" danych, to brzmi, jak "no problem" ;)
    Nawet jeśli po drugiej stronie cokolwiek wysyła bit potwierdzenia itp., to i tak musi to być przetworzone na sygnały D i R, bo tylko takie trafiają do MCU z transceivera, a więc informacja taka byłaby również przesłana przez światłowód, który na tych sygnałach by bazował.

    Jeśli zwykle konwertery budowane są na bazie MCU, to może chodzi o uniezależnienie się od zależności czasowych (R względem D) między CAN a FO, na zasadzie buforów FIFO itp. Może też chodzić o filtrowanie ruchu, gdy część informacji chcesz zamknąć w jednej podsieci, część w drugiej, a interesuje Cię filtrowana wymiana pomiędzy konkretnymi urządzeniami.

    Ale to na logikę, nie z testów ;)
  • REKLAMA
  • #3 16368409
    krzysiek_krm
    Poziom 40  
    Witam,
    wydaje się, że powinno to działać, przy spełnieniu następujących warunków.

    Nadajnik i odbiornik muszą być optycznie sprzężone ze światłowodem.
    Odbiornik musi mieć wyjście typu OC lub OD, żeby możliwe było uzyskanie stanu "recessive" na "naszym" transceiverze.
    Na upartego można "przepuścić" sygnały odbiornika i nadajnika przez typowy transceiver CAN, między innymi dla dopasowania poziomów elektrycznych, jak również dla zapewnienia stanu "recessive" na "naszym" węźle.

    Jeżeli przez światłowód idzie jakiś strumień bitów, odbieramy go, jeżeli chcemy się wcisnąć na magistralę, przezwyciężamy stan "recessive" za pomocą "naszego stanu "dominant".

    Jedyny "szczur", jaki przychodzi mi do głowy to konieczność blokowania "naszego" odbiornika stanem "dominant" "naszego" nadajnika (plus jakieś małe ekstra opóźnienie) żeby "nasz" własny "dominant" nie trafiał do nas jakoś opóźniony via nadajnik - światłowód - odbiornik.

    Jeszcze chyba dopasowanie na końcach światłowodu żeby uniknąć odbić.

    Pozdrawiam
  • REKLAMA
  • #4 16368553
    krisRaba
    Poziom 31  
    Jeżeli na obu końcach FO mamy taki konwerter CAN/FO, to transceiver sam załatwia sprawę recessive/dominant, bo to jego broszka obsłużyć linię CAN. Natomiast faktycznie wymuszenie na linii stanu dominant wymusi wysterowanie TX nadajnika FO i stan dominant w CAN na drugim końcu, a ten z kolei wróci do nas po RX podtrzymując stan dominant po naszej stronie... i całość może się zatrzasnąć lub zrobić się generatorem pracującym na opóźnieniach ;-)
    Więc o ile echo między transceiverem a MCU jest pożądane, to na FO echo należałoby faktycznie tłumić.
  • #5 16369045
    Svavo
    Poziom 23  
    krisRaba napisał:
    Więc o ile echo między transceiverem a MCU jest pożądane, to na FO echo należałoby faktycznie tłumić.

    I dokładnie o to chodzi! @krzysiek_krm również to zauważył. Tylko ja nie wiedziałem jak to zrozumiale napisać ;).
    Dodałem układ logiczny, który "wycina" zapętlony telegram w transceiverze. Kolejny problem to opóźnienie między TX a RX transceivera (w moim przypadku ADUM3053) wynoszące ok. 300us. OK, dodałem linię opóźniającą aby zsynchronizować oba sygnały, ale tu z kolei pojawia się hazard (zbocza narastające i opadające nigdy nie będę idealnie się pokrywały) co skutkuje przedostawaniem się krótkich szpilek ok. 10ns. Mimo tego układ działa, ale to nie jest czyste rozwiązanie. Mogę jeszcze dodać układ wpływający na stałą czasową zależnie od zbocza, tym samym zwiększając margines błędu - wówczas powinno działać jak trzeba.
    Cały układ zamyka się w 3 kościach (bramki NAND i XNOR) i kilku elementach biernych, ale zastanawiam się jednak czy nie da się tego zrobić prościej / inaczej?
  • REKLAMA
  • #6 16369265
    krisRaba
    Poziom 31  
    Gorzej jeśli opisywane zależności będą pływać z temperaturą, długością połączenia FO, rozrzutem parametrów produkcyjnych itp. ;)
    Pytanie, czy jednak nie prościej zrobić to na jakimkolwiek najtańszym "gumiaku" MCU, nawet używając UARTa zamiast CANa, bo MCU z CANem zwykle są z trochę droższej półki. A jeśli MCU nie musi rozumieć transmisji, tylko przerzuca wszystko w jedną i w drugą stronę, to powinno wystarczyć. Kilka linii kodu i problem rozwiązany definitywnie. Z tym że jeśli chciałbyś to produkować seryjnie, to dochodzi jeden krok związany z podpięciem programatora...
  • #7 16369302
    Svavo
    Poziom 23  
    @krisRaba, zależności o których piszesz są rzeczywiście niepokojące - przesunięcie zdaje się być stałe (choć dokładnie tego nie badałem), ale trzeba je ustawić dość dokładnie. Są co prawda dedykowane scalaki przesuwające sygnał w fazie rzędu dziesiątek ns, ale drogie. Droższe niż uC z interfejsem CAN ;). Ze zrobieniem takiego konwertera z uC nie ma problemu, ale mi zależy na układzie bez niego. Wychodzi na to, że to sztuka dla sztuki. Chyba, że ktoś ma pomysł jak to zrobić inaczej.
REKLAMA