Implementowanie warstwy protokołu CAN w oprogramowaniu

12

tło

Opracowuję projekt, który będzie wymagał skromnych specyfikacji mikrokontrolera:

  • 8 12-bitowych przetworników ADC 10 kHz
  • 1kB pamięci RAM
  • 48-QFN lub mniejszy rozmiar
  • Protokół komunikacyjny odporny na zakłócenia i korekcję błędów 20 kb / s

Wymagania dotyczące przetwarzania sygnału są dość niskie i większość z nich można wyeksportować do głównego procesora w systemie. Pierwsze trzy specyfikacje są łatwe do spełnienia i można je wykonać za mniej niż 2 USD w ilości. Jednak komunikacja będzie się odbywać w bardzo hałaśliwym środowisku elektrycznym, więc sieci wrażliwe na zakłócenia, takie jak LIN i I2C, są niedostępne. Dodatkowym argumentem przeciwko LIN jest to, że chciałbym uruchomić całość przy 5 V lub 3,3 V, a nadajniki-odbiorniki LIN wymagają 12 V, a więc wymagałyby dodatkowego regulatora lub przewodu na płytkę czujnika. Początkowo wybrałem CAN do tego zadania. Jednak sterowniki CAN generują znaczne koszty i jestem ciekawy, czy można to zrobić w oprogramowaniu.

Warstwa fizyczna CAN

Specyfikacja CAN określa warstwy danych i warstwy fizyczne modelu referencyjnego sieci OSI. Istnieje wiele niedrogich 8-pinowych układów scalonych, takich jak NXP TJA1040 / 50 , Maxim MAX3058 / 59 , Microchip MCP2551 i TI SN65HVD1050 . Wdrożenie warstwy fizycznej za pomocą przetworników D / A lub wzmacniaczy operacyjnych byłoby trudne, jeśli nie niemożliwe, więc te układy scalone są warte 1 USD lub więcej, więc kosztują.

CAN Data Link / Protocol Layer

W przypadku warstwy łącza danych niektóre mikrokontrolery dodają moduły protokołu CAN do podstawowych warstw komunikacyjnych UART, I2C i SPI. Są one jednak znacznie droższe niż podstawowe układy.

Badanie kosztów modułów protokołu CAN

Aby uzasadnić to twierdzenie, oto kilka popularnych mikrofonów w wersjach CAN i innych niż CAN:

  • ATmega16 - ATMEGA16M1 (z CAN): 3,87 USD, ATMEGA168A (bez CAN): 3,23 USD
  • dsPIC - DSPIC33FJ64MC802 (z CAN): 6,14 USD, DSPIC33FJ64GP202 (bez CAN): 5,48 USD
  • PIC18 - PIC18F2480 (z CAN): 6,80 USD, PIC18F24J10 (bez CAN): 2,10 USD
  • Cortex-M3 - STM32F103C4T6A (z CAN): 6,50 USD, STM32F100C4T6B (bez CAN): 2,73 USD

Szczerze mówiąc, porównałem tylko mikrokontrolery o równoważnych rozmiarach pamięci, jednak wiele wersji innych niż CAN jest dostępnych z mniejszymi rozmiarami pamięci za mniej. Zewnętrzne kontrolery CAN, takie jak Microchip MCP2515 , kosztują prawie 2 USD, więc oczywiście bardziej opłacalne jest zintegrowanie CAN z mikrokontrolerem, jeśli masz taką opcję.

Co ciekawe, część ATmega jest zdecydowanie najtańszą częścią wyposażoną w CAN w ekwipunku Digikey.

Funkcja warstwy protokołu CAN

Moduł CAN znaleziony w mikrokontrolerach dsPIC wykonuje następujące czynności:

Moduł magistrali CAN składa się z silnika protokołu i buforowania / sterowania wiadomościami. Silnik protokołu CAN obsługuje wszystkie funkcje odbierania i przesyłania komunikatów na magistrali CAN. Wiadomości są przesyłane przez załadowanie najpierw odpowiednich rejestrów danych. Status i błędy można sprawdzić, czytając odpowiednie rejestry. Każda wiadomość wykryta na magistrali CAN jest sprawdzana pod kątem błędów, a następnie dopasowywana do filtrów, aby sprawdzić, czy powinna zostać odebrana i zapisana w jednym z rejestrów odbiorczych.

Wydaje się to dość wykonalne w oprogramowaniu.

Pytanie

Czy można zastosować warstwę protokołu oprogramowania do implementacji specyfikacji CAN z jedynie niedrogim mikrokontrolerem wyposażonym w UART i transceiverem CAN? Jeśli tak, to czy istnieją jakieś implementacje typu open source?

Alternatywnie, czy transceivery CAN mogą być używane z UART do implementacji niestandardowego protokołu? Nic mi nie jest z topologią jednego wzorca; Rozumiem, że arbitraż może być trudny do uzyskania w niestandardowym protokole.

Kevin Vermeer
źródło
CAN ma również napięcie 12 V, ponieważ został opracowany do użytku motoryzacyjnego.
kenny,
@Kenny - Poziomy napięcia stosowane w powyższych transiwerach wynoszą 5 V.
Kevin Vermeer
Jeśli zamierzasz rozważyć serię STM32F, czy mogę zasugerować również tę część NXP? Jest to rdzeń Cortex-M0. search.digikey.com/scripts/DkSearch/...
Jon L
@Jon - Te niekoniecznie były brane pod uwagę, a M0 byłby idealny do tego przypadku użycia - Jednak weź pod uwagę części Nuvoton M052LAN są również Cortex-M0 i mniej więcej połowę ceny (1,21 USD vs. 2,35 USD), ale nie ma modułu CAN. Taka różnica w cenie jest moją motywacją.
Kevin Vermeer
możesz również rozważyć ocenę operacyjną. Większość części ze wsparciem CAN będzie przemysłowych lub samochodowych w porównaniu do wersji innych niż CAN.
Mark

Odpowiedzi:

11

Myślę, że implementacja protokołu CAN tylko w oprogramowaniu sprzętowym będzie trudna i zajmie trochę czasu, zanim się poprawi. To nie jest dobry pomysł.

Twoje ceny są jednak wysokie. Właśnie sprawdziłem, a dsPIC 33FJ64GP802 w pakiecie QFN sprzedaje się za 3,68 USD na microchipdirect za 1000 sztuk. Cena będzie niższa dla rzeczywistych wielkości produkcji.

Sprzętowe urządzenie peryferyjne CAN robi dla ciebie prawdziwe rzeczy, a przyrost ceny nie jest bliski żądanej wartości.

Dodany:

Ponieważ wydaje się, że jesteś zdeterminowany, aby wypróbować trasę oprogramowania układowego, oto kilka oczywistych problemów, które przychodzą mi do głowy. Najprawdopodobniej wystąpią inne problemy, które jeszcze mi się nie zdarzyły.

Chcesz wykonać CAN przy 20 kbit / s. To bardzo wolne tempo dla CAN, które wzrasta do 1 Mb / s przez co najmniej 10s metrów. Aby dać ci jeden punkt danych, standard sygnalizacji na statku NMEA 2000 jest nakładany warstwowo na CAN przy prędkości 200 kb / s, i to ma być przenoszone z jednego końca dużego statku na drugi.

Możesz myśleć, że wszystko czego potrzebujesz to jedno przerwanie na bit i możesz zrobić wszystko, czego potrzebujesz w tym przerwaniu. To nie zadziała, ponieważ w każdym czasie CAN dzieje się kilka rzeczy. W szczególności należy wykonać dwie rzeczy na poziomie podbitów. Pierwszy wykrywa kolizję, a drugi dostosowuje szybkość transmisji w locie.

Istnieją dwa stany sygnalizacji na magistrali CAN: recesywna i dominująca. Recesywne dzieje się, gdy nic nie jedzie autobusem. Obie linie są połączone razem o 60 Ω. Normalna magistrala CAN zaimplementowana przez wspólne układy, takie jak MCP2551, powinna mieć terminatory 120 Ω na obu końcach, a zatem łącznie 60 Ω ciągnie pasywnie dwie linie różnicowe. Stan dominujący występuje wtedy, gdy obie linie są aktywnie odrywane, gdzieś około 900mV od stanu recesywnego, jeśli dobrze pamiętam. Zasadniczo jest to jak otwarta magistrala kolektorowa, z tym wyjątkiem, że jest implementowana za pomocą pary różnicowej. Magistrala znajduje się w stanie recesywnym, jeśli CANH-CANL <900mV i dominuje, gdy CANH-CANL> 900mV. Stan dominujący sygnalizuje 0, a recesywny 1.

Ilekroć węzeł „zapisuje” 1 do magistrali (pozwala mu odejść), sprawdza, czy jakiś inny węzeł zapisuje 0. Gdy znajdziesz magistralę w stanie dominującym (0), gdy myślisz, że wysyłasz, a bieżący bit, który wysyłasz, to 1, oznacza to, że ktoś też wysyła. Zderzenia mają znaczenie tylko wtedy, gdy dwóch nadawców się nie zgadza, a reguła jest taka, że ​​ten, który wysyła stan recesywny, wycofuje się i przerywa swoją wiadomość. Węzeł wysyłający stan dominujący nawet nie wie, że tak się stało. Tak działa arbitraż na magistrali CAN.

Reguły arbitrażu magistrali CAN oznaczają, że musisz obserwować autobus w połowie drogi za każdym razem, gdy wysyłasz jako 1, aby upewnić się, że ktoś nie wysyła 0. Ta kontrola jest zwykle wykonywana około 2/3 drogi do bitów , i jest podstawowym ograniczeniem długości magistrali CAN. Im wolniejsza prędkość bitów, tym więcej czasu ma najgorszy przypadek propagacji z jednego końca magistrali na drugi, a zatem im dłuższa może być magistrala. Ta kontrola musi być wykonywana za każdym razem , gdy uważasz, że jesteś właścicielem magistrali i wysyłasz 1 bit.

Kolejnym problemem jest regulacja przepływności. Wszystkie węzły na szynie muszą zgadzać się co do szybkości transmisji, ściślej niż z RS-232. Aby zapobiec kumulacji się niewielkich różnic zegara w znacznych błędach, każdy węzeł musi być w stanie wykonać odrobinę dłuższy lub krótszy niż jego nominał. W przypadku sprzętu jest to realizowane przez uruchamianie zegara około 9x do 20x szybciej niż szybkość transmisji. Cykle tego szybkiego zegara nazywane są kwantami czasu. Istnieją sposoby na wykrycie, że początek nowych bitów wędruje w odniesieniu do tego, gdzie twoim zdaniem powinny być. Implementacje sprzętowe następnie dodają lub pomijają kwanty jednorazowe w celu ponownej synchronizacji. Istnieją inne sposoby realizacji tego, o ile można dopasować się do małych różnic w fazie między oczekiwanymi czasami bitów a rzeczywistymi zmierzonymi czasami bitów.

Tak czy inaczej, mechanizmy te wymagają wykonania różnych czynności w różnych momentach w krótkim czasie. Ten rodzaj synchronizacji będzie bardzo trudny w oprogramowaniu układowym lub będzie wymagał bardzo wolnego działania magistrali. Załóżmy, że wdrażasz system kwanty czasu w oprogramowaniu układowym przy prędkości 20 kb / s. Przy minimum 9 kwantach czasu na bit wymagałoby to przerwania 180 kHz. Z pewnością jest to możliwe w przypadku czegoś takiego jak dsPIC 33F, ale pochłonie znaczną część procesora. Przy maksymalnej częstotliwości instrukcji wynoszącej 40 MHz otrzymujesz 222 cykli instrukcji na przerwanie. Nie powinno to potrwać tak długo, aby wykonać wszystkie sprawdzenia, ale prawdopodobnie 50-100 cykli, co oznacza, że ​​25-50% procesora zostanie wykorzystane do CAN i że będzie musiał wyprzedzić wszystko, co jest uruchomione. To zapobiega wielu aplikacjom, które te procesory często działają, jak puls przez sterowanie impulsowe zasilacza impulsowego lub sterownika silnika. Opóźnienie cyklu 50-100 przy każdym innym przerwaniu byłoby kompletnym ograniczeniem dla wielu rzeczy, które zrobiłem z takimi chipami.

Więc zamierzasz wydać pieniądze, aby zrobić jakoś CAN. Jeśli nie w dedykowanym sprzętowym urządzeniu peryferyjnym przeznaczonym do tego celu, to uzyskanie większego procesora do obsługi znacznego narzutu oprogramowania wewnętrznego, a następnie radzenie sobie z nieprzewidywalnym i możliwym dużym opóźnieniem przerwania dla całej reszty.

Potem jest inżynieria z góry. Urządzenie peryferyjne CAN po prostu działa. Z twojego komentarza wynika, że ​​koszt przyrostowy tego urządzenia peryferyjnego wynosi 0,56 USD. To wydaje mi się okazją. Jeśli nie masz produktu o bardzo dużej objętości, nie ma sposobu, aby odzyskać znaczny czas i koszty, które trzeba poświęcić na wdrożenie CAN tylko w oprogramowaniu układowym. Jeśli twoje wolumeny są tak wysokie, ceny, o których wspominaliśmy, i tak nie są realistyczne, a różnica między dodaniem sprzętu CAN będzie niższa.

Naprawdę nie widzę sensu.

Olin Lathrop
źródło
Doceniam twoją opinię, ale jestem ciekawy, dlaczego nikt nie próbował obejść trudności - każdy projekt będzie miał takie problemy! Dam ci znać, jak to się skończy, jeśli skończę.
Kevin Vermeer
W ilości 1000 znajduję cenę 3,12 USD za dsPIC33FJ64GP202 firmy microchipdirect - łączna różnica wartości wynosi 560 USD! Warto przynajmniej spróbować. I cytował ceny za każdy po prostu dlatego, że łatwiej było uzyskać numery poszczególnych sztuk bez konieczności martwienia się o motania, standardowej wielkości opakowania itd.
Kevin Vermeera
2
@Kevin, niskie ceny ilościowe nie zawsze są proporcjonalne do cen dużych ilości. Nie wiem, ile z tych rzeczy planujesz zrobić, ale 560 USD nie zacznie płacić za inżynierię do wykonania CAN w oprogramowaniu układowym. Dodam do może wyjaśnić niektóre trudności, które napotkasz.
Olin Lathrop,
WTF !? Właśnie dodałem kilka rzeczy do mojej odpowiedzi i większość ustępów ustała. W oknie edycji, które wpisywałem, były zdecydowanie puste linie.
Olin Lathrop,
1
Odpowiedź brzmi: tak, ale zgadzam się całkowicie z Olinem tutaj. Właściwie pracuję na pełnym etacie w tej dziedzinie. Używam układu dsPIC33FJ256. Czas spędzony na pisaniu rzeczy w podejściu bit-bang po prostu pozbawia przewagę kosztową posiadania sprzętu, który robi to za ciebie i wymyślasz koło. Nie wspominając już o tym, że wszystko, co robisz w sprzęcie, musiałoby być starannie zaplanowane. Zastanawiam się także, czy analizujesz inne protokoły wyższego poziomu, takie jak ISO14229 lub OSEK / Autosar NetworkManagement?
Eric M
2

Używamy PIC18F25K80 . Chociaż nie ma DSP, jest w ilości ~ 2 USD. To prawie bezpośredni substytut wspomnianego PIC18F2480. Używamy kompilatora CCS i stosu oprogramowania dla CAN, który prawdopodobnie jest przeniesiony z Microchip. Działa dobrze do wszystkiego, czego potrzebowałem i próbowałem.

Kenny
źródło
Nie szukałem ECAN. Głupia nazwa Microchip, ale następnym razem będę musiał przeczytać ją bliżej! Jak powiedziałem, moje potrzeby w zakresie przetwarzania sygnału są niskie, więc nie sądzę, że potrzebuję rzeczywistego DSP.
Kevin Vermeer
2

Jeśli dobrze to rozumiem, brzmi to tak, jakbyś chciał użyć funkcji CAN bit-bash przy użyciu tylko UART i sprytnego oprogramowania. Zaufaj mi, to nigdy nie zadziała - sugeruję przeczytanie dobrego tekstu na temat zawiłości CAN lub CANopen. Zlikwidujesz wszelkie oszczędności, których szukasz, idąc tą drogą.

Chciałbym albo użyć mikrokontrolera z modułem CAN i przekazać dodatkowe 2 dolary, albo zastanawiałeś się nad innym protokołem kompatybilnym z UART, takim jak Modbus przez RS-485 ?

BullBoyShoes
źródło
Dobrze to czytasz. Dokładnie przeczytałem broszurę szkoleniową Vector na CAN. Wygląda na to, że każda wiadomość będzie wymagała wstępnego przetwarzania dla CRC, ale reszta pakietu powinna być taka sama i po prostu będę musiał sprawdzać linię odbiorczą pod kątem konfliktu. To naprawdę nie wydaje się tak trudne, jak się wydaje, ale zdecydowanie wezmę pod uwagę twoją radę.
Kevin Vermeer
Jednak podoba mi się pomysł Modbus over RS485. Wygląda na to, że większość z tych nadajników-odbiorników jest również zasilana napięciem 5 V. Miałem wrażenie, że wymaga napięcia wejściowego +/- jak RS232. Będę musiał to sprawdzić.
Kevin Vermeer,
bit banging z pewnością zadziała! Nie jest to trywialne, jak wspomina Olin, ale można to zrobić. Osobiście ściągnąłem go zarówno z serii PIC18F, jak i serii dsPIC33 micro. Mogę przesłać źródło PIC18F, jeśli naprawdę chcesz je zobaczyć. Nie mogę jednak podać źródła dsPIC, ponieważ jest to część komercyjnego projektu, nad którym pracuję. W obu przypadkach używamy MCP2551, a ja również mam kod LIN. LIN jest nieco prostszy w warstwie protokołu, ale implementacja harmonogramów LIN jest nieco trudniejsza ...
Eric M
1
@EricM - Jaka była szybkość transmisji i czy udało Ci się wdrożyć pełną specyfikację CAN w oprogramowaniu? Chciałbym kochać , aby zobaczyć kod PIC18F do tego.
Rocketmagnet
Tak, zaimplementowano pełną specyfikację CAN, aby nie powielała modułu ECAN na dsPIC, który zajmuje się wieloma aspektami. W implementacji PIC18 zmieniłem bit bit na pełną specyfikację i później, a ten kod będzie działał na dsPIC wykorzystującym linie GPIO. Zaktualizuję za kilka dni link do kodu.
Eric M
0

Zastanawiam się także nad bit-protokołu CAN na PIC µC, więc proszę EricM, jeśli naprawdę to zrobiliście, proszę odpowiedzieć i powiedzieć przynajmniej, jaką bitrate przy jakiej częstotliwości podstawowej PIC18F lub DSPic macie. Dzięki!

Zasadniczo: RS 485 byłby rozwiązaniem dla pierwotnie zadawanego problemu, ale byłoby również możliwe zastosowanie transceiverów CAN- (lub nawet FlexRay) z komunikacją UART niepełnego dupleksu (punkt 2 punkt) jako wszystkich tych protokołów użyj kodowania NRZ.

Ale w UART / V24 / RS232 najczęściej używany jest pełny dupleks bez szczegółowego zastanawiania się, więc być może będziesz musiał wprawić mózg w superpętlę lub statemachine twojej aplikacji ...

Ale wracając do bitbangingu CAN: pracuję z CAN od wielu lat i nigdy nie widziałem implementacji bitbangingu, ale o ile mi się wydaje, powinno to działać dla taktowania bitów do tp 100kBit z nowoczesnym µC, takim jak DSPic lub ARM itp. (posiadające rdzenie o częstotliwości 80 MHz lub wyższej ...)

Przynajmniej, jeśli weźmie się pod uwagę tylko odczyt zwrotny ... Wysyłanie oznaczałoby pewien narzut związany z przygotowaniem struktur bitowych, tak aby nie było osiągalne nie 100% obciążenia magistrali, ale w CAN więcej niż 65% jest w ogóle rzadkie ...

roby111
źródło
2
Witamy w StackExchange w inżynierii elektrycznej. Pierwsza część twojej odpowiedzi wcale nie jest odpowiedzią, więc zadajesz nowe pytanie, czy tego właśnie chcesz. OP zapytał konkretnie o implementację oprogramowania protokołu CAN, a twoja odpowiedź wydaje się wędrować bez odpowiedzi na to pytanie; spróbuj pozostać na temat pytania.
Joe Hass