Czy MCP2551 jest konwerterem UART na CAN?


12

Chcę zrobić sniffer magistrali CAN dla prędkości 250 kbit / s za pomocą mojego komputera. Po kilku badaniach odkryłem, że MCP2551 jest rodzajem regulatora poziomu napięcia dla warstwy fizycznej CAN. Mając to na uwadze, zastanawiam się, czy ta konfiguracja mogłaby działać. Chcę tylko nagrywać wymieniane wiadomości do celów automatycznego testowania, a nie być częścią komunikacji:

PC <-> USB-UART (być może CP2102, ponieważ mam już jeden) <-> MCP2551 <-> CAN bus

Jeśli nie, to jakie sygnały muszą wejść do MCP2551, aby zostać częścią autobusu?

Odpowiedzi:


14

Możesz to zrobić, ale to, co dostaniesz na swojej magistrali CAN, będzie UART przy użyciu poziomów napięcia CAN. Jeśli chcesz komunikować się z urządzeniami CAN na swojej magistrali, musisz dostarczyć MCP2551 z komunikatami protokołu CAN. To samo dotyczy nasłuchiwania: wiadomości CAN różnią się tak bardzo od formatu UART, że UART nie będzie wiedział, co z nimi zrobić. Przez cały czas będą pojawiać się co najmniej błędy ramki i nie dostaniesz się do treści wiadomości.
Ten obraz pokazuje strukturę komunikatu CAN:

wprowadź opis zdjęcia tutaj

Wokół jest wiele mikrokontrolerów z interfejsem CAN, bez transceivera. Właśnie dla nich zaprojektowano MCP2551. W przeszłości korzystaliśmy z NXP LPC2294, który ma 4 interfejsy CAN. Każdy z nich potrzebuje MCP2551, aby połączyć się z magistralą CAN. Nowsze sterowniki NXP obejmują rodzinę LPC1800 , której wszyscy członkowie obsługują CAN.


Zupełnie zapomniałem o bitach start / stop UART i prawdopodobnie niektórych sytuacjach „start / top bit” CAN. Prawdopodobnie postaram się znaleźć rozwiązanie przy użyciu stosu CAN na PC, używając FTDI jako gpio, które zakończy transmisję na MCP2551
rnunes

3
@rnunes - To nie tylko bity start / stop. Bez nich transmisja UART jest tylko 8-bitowym bajtem. Komunikat CAN jest znacznie bardziej złożony, z adresowaniem, priorytetem i sprawdzaniem błędów. Nie możesz ich porównać.
stevenvh

Ale używając FTDI będę działał krok po kroku (w zasadzie jest to naprawdę szybki USB <-> GPIO), a nie bajt po bajcie, jak w przypadku UART. Już szukam tych CAN MCU, ale wolałbym na razie wydawać jakieś pieniądze (jest to projekt hobby studenckiego) i już mam FTDI. Jeśli zakończę z moimi badaniami, że FTDI nie będzie w stanie tego zrobić, spróbuję użyć CAN MCU.
rnunes

Stos będzie odpowiedzialny za obsługę wszystkiego (np. Wypychanie bitów) i przesyłanie go krok po kroku do MCP2551. Jedyny problem, jaki mam teraz, to opóźnienie FTDI, ponieważ muszę być szybki i regularny, ale zmierzę go później.
rnunes

1
@ rnunes - Ale to, co wychodzi z CP2102 (SiLab, nie FTDI), to bajty , a nie bity. Nie możesz tego zatrzymać po chwili. Będziesz potrzebował zarówno CP2102 do połączenia mikrokontrolera z USB, jak i mikrokontrolera obsługującego CAN + MCP2551. Lub mikrokontroler, który może również działać jako urządzenie USB. Zatem nie potrzebujesz CP2102.
stevenvh

7

Zrobiłem USB / CAN użyciu FT2232H w trybie MPSSE zapomnieć (UART), MCP2515 i MCP2551. MCP2515 to kluczowy element, którego tutaj brakuje. Studiuj dobrze, co robi. Jest to rzeczywisty kontroler CAN, który zajmuje się tworzeniem ramek, potwierdzeniami ACK, generowaniem i weryfikacją sum kontrolnych, filtrowaniem wiadomości i innymi mniej oczywistymi czynnościami, które węzeł CAN musi wykonywać zgodnie ze standardem. Jeśli potrzebujesz sniffera, MCP2515 ma tryb tylko nasłuchiwania, który gwarantuje brak transmisji w magistrali. MCP2551 to po prostu głupi adapter warstwy fizycznej, podobny do MAX232 dla RS-232 lub ADM485 dla RS-485.

Teraz ta architektura jest daleka od ideału, ponieważ technologia FTDI MPSSE zasadniczo nie obsługuje przerwań (uważam, że wykorzystuje tylko masowe transfery USB za sceną), więc muszę często sondować kontroler w poszukiwaniu nowych wiadomości. To powoduje duże obciążenie kontrolera hosta USB, ale nadal nie gwarantuje, że żadne wiadomości nie zostaną utracone (MCP2515 może przechowywać do 2 odebranych wiadomości wewnętrznie, jeśli włączysz „tryb przepełnienia”, tylko jeden, jeśli nie zrobisz tego). O wiele lepszym rozwiązaniem byłby właściwy mikrokontroler z wbudowanymi urządzeniami peryferyjnymi CAN i USB, takimi jak STM32F105 (103 nie może jednocześnie korzystać z USB i CAN). Zobacz ten projekt, aby uzyskać działającą implementację dokładnie tego pomysłu. LPC18xx, jak sugeruje stevenh, też będzie działać, ale LPC17xx są prawdopodobnie tańsze i łatwiejsze do znalezienia.


W tym przypadku łączenie nie jest problemem, ale tak, idealnym rozwiązaniem byłoby użycie MCU ze sterownikiem CAN, który działa jako bufor komunikatów CAN. Od teraz spróbuję użyć pierwszej konfiguracji, którą napisałeś. Dzięki
rnunes

+1 Użycie układu FTDI do bezpośredniej rozmowy z kontrolerem CAN bez interfejsu użytkownika jest fajne. Najwyraźniej FTDI wyszedł FT221X, który jest dedykowanym mostkiem USB na SPI. (Istnieje również inny model dla USB niż I2C.)
Nick Alexeev

2

Ponieważ chcesz nasłuchiwać na istniejącej magistrali CAN, tak jak rozumiem pytanie, naprawdę nie możesz w ogóle używać UART. Siganlling CAN i UART są zupełnie inne.

Teoretycznie możesz spojrzeć na linię odbierania CAN wychodzącą z MCP2551 i dekodować ruch CAN. To nie będzie łatwe, ale jest teoretycznie możliwe. Bez specjalistycznego sprzętu CAN będziesz musiał próbować kilka razy szybciej niż szybkość transmisji CAN i dekodować ten strumień bitów w oprogramowaniu później. Prawdopodobnie będziesz musiał nagrywać z prędkością około 1 Mbit / s, aby zdekodować 250 kbit / s CAN.

Korzystanie z mikrokontrolera będzie znacznie łatwiejsze. PIC 18F2580 i inne podobne procesory mają wbudowane urządzenie peryferyjne CAN. Sprzęt wykonuje dekodowanie na poziomie bitowym i odbiera całe ramki CAN. Procesor może następnie wysyłać odebrane ramki CAN przez swój UART na komputer.

Korzystając z naszej strony potwierdzasz, że przeczytałeś(-aś) i rozumiesz nasze zasady używania plików cookie i zasady ochrony prywatności.
Licensed under cc by-sa 3.0 with attribution required.