Apakah MCP2551 merupakan konverter UART-to-CAN?


12

Saya ingin membuat sniffer bus CAN untuk 250 kbit / s menggunakan komputer saya. Setelah beberapa penelitian saya menemukan bahwa MCP2551 adalah semacam regulator level tegangan untuk lapisan fisik CAN. Dengan mengingat hal itu, saya ingin tahu apakah pengaturan ini dapat berfungsi. Saya hanya ingin merekam pesan yang dipertukarkan untuk tujuan pengujian otomatis, bukan menjadi bagian dari komunikasi:

PC <-> USB-UART (mungkin CP2102, bacause saya sudah memilikinya) <-> MCP2551 <-> BISA bus

Jika tidak, sinyal apa yang harus masuk MCP2551 untuk membuat saya menjadi bagian dari bus?

Jawaban:


14

Anda dapat melakukannya, tetapi apa yang akan Anda dapatkan di bus CAN Anda adalah UART menggunakan level tegangan CAN. Anda harus menyediakan MCP2551 dengan pesan protokol CAN jika Anda ingin berkomunikasi dengan perangkat CAN di bus Anda. Sama untuk mendengarkan: Pesan CAN sangat berbeda dari format UART sehingga UART tidak akan tahu apa yang harus dilakukan dengannya. Anda akan memiliki setidaknya kesalahan bingkai sepanjang waktu, dan Anda tidak akan mendapatkan konten pesan.
Gambar ini menunjukkan struktur pesan CAN:

masukkan deskripsi gambar di sini

Ada banyak mikrokontroler di sekitar yang memiliki antarmuka BISA, tanpa transceiver. Untuk inilah MCP2551 dirancang. Di masa lalu kami telah menggunakan NXP LPC2294, yang memiliki 4 antarmuka CAN. Masing-masing dari mereka membutuhkan MCP2551 untuk terhubung ke bus CAN. Kontroler yang lebih baru dari NXP termasuk keluarga LPC1800 , di mana semua anggota mendukung CAN.


Saya benar-benar lupa tentang bit start / stop UART dan mungkin beberapa situasi CAN "start / top bits". Saya mungkin akan mencoba untuk menemukan solusi menggunakan CAN stack pada PC menggunakan FTDI sebagai gpio yang pada akhirnya akan mentransmisikan ke MCP2551
rnunes

3
@rnunes - Ini bukan hanya bit start / stop. Tanpa itu, transmisi UART hanya 8 byte. Pesan CAN jauh lebih rumit, dengan mengatasi, memprioritaskan dan memeriksa kesalahan. Anda tidak dapat membandingkan keduanya.
stevenvh

Tetapi dengan menggunakan FTDI saya akan bekerja sedikit demi sedikit (pada dasarnya, ini adalah USB yang sangat cepat <-> GPIO), bukan byte demi byte seperti halnya dengan UART. Saya sudah mencari MCU BISA itu, tapi saya lebih suka menghabiskan uang untuk saat ini (ini adalah proyek hobi siswa) dan saya sudah memiliki FTDI. Jika saya menyimpulkan dengan penelitian saya bahwa FTDI tidak akan dapat melakukan ini, saya akan mencoba menggunakan CAN MCU.
rnunes

Tumpukan akan bertanggung jawab untuk menangani semuanya (mis. Isian bit) dan mengirimkannya sedikit demi sedikit ke MCP2551. Satu-satunya masalah yang saya alami saat ini adalah latensi FTDI, karena saya membutuhkannya cepat dan teratur, tetapi saya akan mengukurnya nanti.
rnunes

1
@rnunes - Tapi apa yang keluar dari CP2102 (SiLabs, bukan FTDI) adalah byte , bukan bit. Anda tidak dapat menghentikannya setelah satu bit. Anda akan membutuhkan kedua CP2102 untuk antarmuka mikrokontroler Anda dengan USB, dan mikrokontroler yang mendukung CAN + the MCP2551. Atau mikrokontroler yang juga dapat bertindak sebagai perangkat USB. Maka Anda tidak perlu CP2102.
stevenvh

7

Saya telah membuat antarmuka USB / CAN menggunakan FT2232H dalam mode MPSSE (lupa UART), MCP2515 dan MCP2551. MCP2515 adalah bagian kunci yang Anda lewatkan di sini. Pelajarilah dengan baik apa yang dilakukannya. Ini adalah pengontrol CAN yang sebenarnya yang melakukan pembingkaian, ACK, pembuatan checksum dan verifikasi, pemfilteran pesan dan hal-hal lain yang kurang jelas yang harus dilakukan oleh node CAN oleh standar. Jika Anda menginginkan sniffer, MCP2515 memiliki mode hanya mendengarkan yang tidak menjamin transmisi di bus. MCP2551 hanyalah sebuah adaptor lapisan fisik yang bodoh, mirip dengan MAX232 untuk RS-232 atau ADM485 untuk RS-485.

Sekarang arsitektur ini jauh dari sempurna karena teknologi FTDI MPSSE pada dasarnya tidak memiliki dukungan untuk interupsi (saya percaya ini hanya menggunakan transfer USB massal di belakang layar), jadi saya harus sering polling controller untuk pesan baru. Ini menempatkan banyak beban pada pengontrol host USB tetapi masih tidak menjamin bahwa tidak ada pesan yang hilang (MCP2515 dapat menyimpan hingga 2 pesan yang diterima secara internal jika Anda mengaktifkan "mode overflow", hanya satu jika Anda tidak). Solusi yang jauh lebih baik adalah mikrokontroler yang tepat dengan builtin CAN dan periferal USB seperti STM32F105 (103 tidak dapat menggunakan USB dan CAN pada saat yang sama). Lihat proyek ini untuk implementasi yang tepat dari ide ini. LPC18xx seperti yang disarankan oleh stevenh akan bekerja juga, tetapi LPC17xx mungkin lebih murah dan lebih mudah ditemukan.


Dalam hal ini, menggabungkan itu bukan masalah tapi ya, solusi ideal akan menggunakan MCU dengan kontroler CAN yang berfungsi sebagai buffer pesan CAN. Mulai sekarang saya akan mencoba menggunakan pengaturan pertama yang Anda tulis. Terima kasih
runes

+1 Menggunakan chip FTDI untuk berbicara langsung ke pengontrol CAN tanpa UC yang rapi. Sayangnya FTDI keluar FT221X, yang merupakan USB khusus untuk jembatan SPI. (Ada model yang berbeda untuk USB ke I2C juga.)
Nick Alexeev

2

Karena Anda ingin mendengarkan bus CAN yang ada saat saya memahami pertanyaannya, Anda benar-benar tidak dapat menggunakan UART sama sekali. Siganlling CAN dan UART benar-benar berbeda.

Secara teori Anda bisa melihat garis CAN CAN yang keluar dari MCP2551 dan mendekode lalu lintas CAN. Itu tidak akan mudah, tetapi secara teori dimungkinkan. Tanpa perangkat keras CAN khusus, Anda harus mengambil sampel beberapa kali lebih cepat daripada bit rate CAN dan mendekode bit stream tersebut dalam perangkat lunak nanti. Anda mungkin perlu merekam sekitar 1 Mbit / s untuk memecahkan kode 250 kbit / s CAN.

Menggunakan mikrokontroler akan jauh lebih mudah. PIC 18F2580 dan prosesor serupa lainnya memiliki perangkat CAN bawaan. Perangkat keras melakukan semua decoding level bit dan menerima seluruh frame CAN. Prosesor kemudian dapat mengirimkan frame CAN yang diterima melalui UART-nya ke PC Anda.

Dengan menggunakan situs kami, Anda mengakui telah membaca dan memahami Kebijakan Cookie dan Kebijakan Privasi kami.
Licensed under cc by-sa 3.0 with attribution required.