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.

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.

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.

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 ?

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