Latar Belakang

Saya sedang mengembangkan sebuah proyek yang membutuhkan spesifikasi mikrokontroler sederhana:

• 8 12-bit, 10kHz ADC
• RAM 1kB
• 48-QFN atau lebih kecil
• 20kbps protokol komunikasi tahan-bising daisy-chainable dan mengoreksi kesalahan

Persyaratan pemrosesan sinyal cukup rendah, dan sebagian besar dapat diekspor ke prosesor utama dalam sistem. Tiga spesifikasi pertama mudah dipenuhi, dan dapat dilakukan dengan jumlah kurang dari $ 2. Namun, komunikasi akan terjadi di lingkungan yang sangat bising secara elektrik, sehingga jaringan yang rentan kebisingan seperti LIN dan I2C keluar. Argumen tambahan terhadap LIN adalah bahwa saya ingin menjalankan semuanya pada 5V atau 3.3V, dan transceiver LIN memerlukan 12V, dan karenanya akan membutuhkan regulator tambahan atau kawat per papan sensor. Awalnya saya memilih BISA untuk tugas ini. Namun, pengendali CAN dapat menambahkan biaya yang cukup besar, dan saya ingin tahu apakah ini dapat dilakukan dalam perangkat lunak.

BISA Lapisan Fisik

Spesifikasi CAN mendefinisikan Data Link dan lapisan Fisik model referensi jaringan OSI. Banyak IC 8-pin yang murah, seperti NXP TJA1040 / 50 , Maxim MAX3058 / 59 , Microchip MCP2551 , dan TI SN65HVD1050 ada untuk mengimplementasikan lapisan fisik. Menerapkan lapisan fisik dengan konverter D / A atau op-amp akan sulit, jika bukan tidak mungkin, sehingga IC ini bernilai $ 1 atau lebih sehingga harganya.

BISA Tautan Data / Lapisan Protokol

Untuk lapisan Data Link, beberapa mikrokontroler menambahkan modul protokol CAN ke lapisan komunikasi UART, I2C, dan SPI dasar. Namun, ini jauh lebih mahal daripada chip dasar.

Investigasi biaya modul protokol CAN

Untuk memperkuat klaim ini, berikut adalah beberapa micros populer dalam versi CAN dan non-CAN, dari:

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

Agar adil, saya hanya membandingkan mikrokontroler dengan ukuran memori yang setara, namun, banyak versi non-CAN tersedia dengan ukuran memori lebih kecil dengan harga lebih murah. Pengontrol CAN eksternal, seperti Microchip MCP2515 , hampir $ 2, jadi jelas lebih hemat biaya untuk mengintegrasikan CAN ke dalam mikrokontroler jika Anda memiliki pilihan.

Menariknya, bagian ATmega sejauh ini merupakan bagian termurah yang dilengkapi BISA dalam inventaris Digikey.

Fungsi lapisan protokol CAN

Modul CAN yang ditemukan dalam mikrokontroler dsPIC melakukan hal berikut:

Modul bus CAN terdiri dari mesin protokol dan penyangga / kontrol pesan. Mesin protokol CAN menangani semua fungsi untuk menerima dan mengirim pesan pada bus CAN. Pesan dikirimkan dengan terlebih dahulu memuat register data yang sesuai. Status dan kesalahan dapat diperiksa dengan membaca register yang sesuai. Setiap pesan yang terdeteksi pada bus CAN diperiksa untuk kesalahan dan kemudian dicocokkan dengan filter untuk melihat apakah itu harus diterima dan disimpan di salah satu register yang diterima.

Ini tampaknya cukup bisa dilakukan dalam perangkat lunak.

Pertanyaan

Dapatkah lapisan protokol perangkat lunak digunakan mengimplementasikan spesifikasi CAN hanya dengan mikrokontroler yang dilengkapi UART dan transceiver CAN? Jika demikian, apakah ada implementasi open-source?

Atau, bisakah transceiver BISA digunakan dengan UART untuk mengimplementasikan protokol khusus? Saya setuju dengan topologi master tunggal; Saya memahami bahwa arbitrase mungkin sulit dilakukan dengan benar pada protokol khusus.

Saya pikir menerapkan protokol CAN di firmware saja akan sulit dan akan memakan waktu cukup lama untuk memperbaikinya. Itu bukan ide yang bagus.

Namun, harga Anda tinggi. Saya baru saja memeriksa, dan 33FJ64GP802 dsPIC dalam paket QFN dijual seharga 3,68 USD pada microchipdirect seharga 1000 buah. Harga akan lebih rendah untuk volume produksi nyata.

Perangkat keras BISA melakukan beberapa hal nyata bagi Anda, dan kenaikan harga untuk itu tidak mendekati apa yang Anda klaim.

Ditambahkan:

Karena Anda tampaknya bertekad untuk mencoba rute firmware, berikut adalah beberapa masalah nyata yang muncul di benak Anda. Kemungkinan besar akan ada masalah lain yang belum terjadi pada saya.

Anda ingin melakukan CAN dengan kecepatan 20 kbit / s. Itu adalah laju yang sangat lambat untuk CAN, yang naik hingga 1Mbit / s untuk setidaknya 10 detik. Untuk memberi Anda satu titik data, standar pensinyalan kapal NMEA 2000 adalah layerd pada CAN dengan kecepatan 200 kbits / dtk, dan itu artinya pergi dari satu ujung kapal besar ke yang lain.

Anda mungkin berpikir bahwa semua yang Anda butuhkan adalah satu interupsi per bit dan Anda dapat melakukan semua yang Anda butuhkan dalam interupsi itu. Itu tidak akan berhasil karena ada beberapa hal yang terjadi dalam setiap waktu BISA. Dua hal khususnya perlu dilakukan pada level sub-bit. Yang pertama adalah mendeteksi tabrakan, dan yang kedua adalah menyesuaikan laju bit dengan cepat.

Ada dua status pensinyalan pada bus CAN, resesif dan dominan. Resesif adalah apa yang terjadi ketika tidak ada yang mengemudikan bus. Kedua garis ditarik bersama-sama dengan total 60 Ω. Bus CAN normal seperti yang diterapkan oleh chip umum seperti MCP2551, harus memiliki 120 "terminator di kedua ujungnya, sehingga total 60" menarik dua garis diferensial secara bersama-sama secara pasif. Keadaan dominan adalah ketika kedua garis secara aktif ditarik terpisah, sekitar 900mV dari keadaan resesif jika saya ingat benar. Pada dasarnya, ini seperti bus pengumpul terbuka, kecuali bahwa itu diterapkan dengan pasangan diferensial. Bus dalam keadaan resesif jika CANH-CANL <900mV dan dominan ketika CANH-CANL> 900mV. Sinyal dominan 0, dan resesif 1.

Setiap kali simpul "menulis" 1 ke bus (biarkan saja), ia memeriksa untuk melihat apakah beberapa simpul lain menulis 0. Ketika Anda menemukan bus dalam keadaan dominan (0) ketika Anda berpikir Anda mengirim dan bit saat ini yang Anda kirim adalah 1, maka itu berarti orang lain juga mengirim. Tabrakan hanya penting ketika kedua pengirim tidak setuju, dan aturannya adalah bahwa pengirim yang mengirim negara resesif mundur dan membatalkan pesannya. Node mengirimkan negara dominan bahkan tidak tahu ini terjadi. Beginilah cara arbitrasi bekerja di bus CAN.

Aturan arbitrase CAN bus berarti Anda harus mengawasi bus di tengah jalan melalui setiap bit yang Anda kirim sebagai 1 untuk memastikan orang lain tidak mengirimkan 0. Pemeriksaan ini biasanya dilakukan sekitar 2/3 dari jalan ke bit , dan merupakan batasan mendasar pada panjang bus CAN. Semakin lambat bit rate, semakin banyak waktu untuk propagasi kasus terburuk dari satu ujung bus ke yang lain, dan oleh karena itu semakin lama bus dapat. Pemeriksaan ini harus dilakukan setiap bit di mana Anda pikir Anda memiliki bus dan mengirimkan 1 bit.

Masalah lainnya adalah penyesuaian laju bit. Semua node pada bus harus menyetujui laju bit, lebih dekat daripada dengan RS-232. Untuk mencegah perbedaan jam kecil dari akumulasi menjadi kesalahan yang signifikan, setiap node harus dapat melakukan sedikit yang sedikit lebih lama atau lebih pendek dari nominalnya. Dalam perangkat keras, ini diterapkan dengan menjalankan jam di suatu tempat sekitar 9x hingga 20x lebih cepat dari bit rate. Siklus jam cepat ini disebut kuanta waktu. Ada cara untuk mendeteksi bahwa awal bit baru berkeliaran di mana Anda pikir mereka seharusnya. Implementasi perangkat keras kemudian tambahkan atau lewati satu kuanta waktu dalam sedikit untuk menyinkronkan kembali. Ada cara lain Anda bisa menerapkan ini selama Anda dapat menyesuaikan diri dengan perbedaan kecil dalam fase antara waktu bit yang diharapkan dan waktu bit aktual yang diukur.

Either way, mekanisme ini membutuhkan berbagai hal yang harus dilakukan pada waktu yang berbeda-beda dalam waktu sedikit. Waktu semacam ini akan menjadi sangat rumit dalam firmware, atau akan membutuhkan bus untuk berjalan sangat lambat. Katakanlah Anda menerapkan sistem kuanta waktu dalam firmware dengan kecepatan 20 kbits / s. Pada minimum 9 kali kuanta per bit, itu akan membutuhkan 180 kHz interupsi. Itu tentu mungkin dengan sesuatu seperti dsPIC 33F, tetapi akan memakan sebagian besar dari prosesor. Pada kecepatan instruksi maks 40 MHz, Anda mendapatkan 222 siklus instruksi per interupsi. Seharusnya tidak butuh waktu lama untuk melakukan semua pengecekan, tetapi mungkin 50-100 siklus, yang berarti 25-50% dari prosesor akan digunakan untuk CAN dan bahwa itu harus mendahului segala hal lain yang sedang berjalan. Itu mencegah banyak aplikasi yang sering dijalankan oleh prosesor ini, seperti pulsa demi kontrol pulsa catu daya switching atau driver motor. Latensi siklus 50-100 pada setiap interupsi lainnya akan menjadi penghenti acara lengkap untuk banyak hal yang telah saya lakukan dengan chip seperti ini.

Jadi Anda akan menghabiskan uang untuk melakukan CAN entah bagaimana. Jika tidak di perangkat keras khusus yang ditujukan untuk tujuan itu, maka dalam mendapatkan prosesor yang lebih besar untuk menangani overhead firmware yang signifikan dan kemudian berurusan dengan latensi interupsi besar yang tidak terduga dan kemungkinan besar untuk semua hal lainnya.

Lalu ada rekayasa di muka. Perangkat CAN hanya berfungsi. Dari komentar Anda, sepertinya biaya tambahan perangkat ini adalah $ 0,556. Itu tampak seperti tawar-menawar bagi saya. Kecuali jika Anda memiliki produk volume yang sangat tinggi, tidak ada cara Anda akan mendapatkan kembali waktu dan biaya yang diperlukan untuk mengimplementasikan CAN di firmware saja. Jika volume Anda setinggi itu, harga yang telah kami sebutkan tidak realistis, dan perbedaan untuk menambahkan perangkat keras CAN akan lebih rendah.

Saya benar-benar tidak melihat ini masuk akal.

Kami menggunakan PIC18F25K80 . Meskipun tidak memiliki DSP, itu adalah ~ $ 2 dalam jumlah. Ini hampir merupakan pengganti langsung untuk PIC18F2480 yang Anda sebutkan. Kami menggunakan kompiler CCS dan tumpukan perangkat lunak mereka untuk CAN yang mungkin porting dari Microchip. Ini bekerja dengan baik untuk semua yang saya butuhkan dan coba.

Jika saya membaca ini dengan benar, sepertinya Anda ingin fungsi bit-bash CAN hanya menggunakan UART dan beberapa firmware pintar. Percayalah, ini tidak akan berhasil - Saya sarankan membaca teks yang bagus tentang seluk-beluk CAN atau CANopen. Anda akan menghapus semua penghematan biaya yang Anda cari dengan menempuh rute ini.

Saya akan menggunakan mikrokontroler dengan modul CAN dan memberikan tambahan $ 2, atau apakah Anda memikirkan protokol lain yang kompatibel dengan UART, seperti Modbus over RS-485 ?

Saya juga berpikir tentang CAN-Protocol bit-banging pada PIC µC, jadi tolong EricM, jika Anda benar-benar melakukan itu, harap balas dan katakan setidaknya, bitrate apa pada frekuensi inti PIC18F atau DSPic yang Anda dapatkan. Terima kasih!

Secara umum: RS 485 akan menjadi solusi untuk masalah utama yang ditanyakan, tetapi juga dimungkinkan untuk menggunakan CAN- (atau bahkan FlexRay) -Penerima dengan komunikasi UART non-dupleks-penuh (poin 2 poin) karena semua protokol itu gunakan NRZ-coding.

Tetapi dalam UART / V24 / RS232 full duplex sebagian besar digunakan tanpa memikirkan secara detail, jadi mungkin Anda perlu menaruh otak pada superloop atau statemachine aplikasi Anda ...

Tetapi kembali ke CAN-bitbanging: Saya bekerja dengan CAN selama bertahun-tahun dan tidak pernah melihat implementasi bitbanging, tetapi sejauh yang saya bisa pikirkan, yang seharusnya bekerja untuk pengaturan waktu hingga tk 100kBit dengan μC modern seperti DSPic atau ARM dll. (memiliki Core pada 80MHz atau lebih tinggi ...)

Setidaknya jika hanya membaca kembali dianggap ... Mengirim akan berarti beberapa overhead dalam mempersiapkan struktur bit sehingga tidak 100% busload akan terjangkau, tetapi di BISA lebih dari 65% jarang terjadi sama sekali ...