Berapa tingkat maksimum frame bus CAN (pesan) pada 125 kbit / s?

Bus CAN saya berjalan pada 125 kbit / s dan menggunakan format frame diperpanjang secara eksklusif. Saya ingin tahu berapa tingkat maksimum bingkai CAN yang dapat saya kirim. Misalkan panjang data selalu delapan byte.

Menurut halaman Wikipedia ini , setiap frame memiliki panjang bingkai maksimum (1+11+1+1+18+1+2+4+64+15+1+1+1+7) = 128bit:

Masukkan deskripsi gambar di sini

Dengan mempertimbangkan jarak antarframe minimum tiga bit , kecepatan paket maksimum di bawah 125 kbit / dtk adalah: 125000 / ( 128 + 3) = 954frame per detik.

Tetapi dalam pengujian saya, saya tidak bisa mendapatkan setinggi itu. Frame rate maksimum yang dapat saya capai (dengan semua delapan byte data) adalah sekitar 850 frame per detik.

Apa yang salah di sini - perhitungan saya, atau metode pengujian saya?

communication can speed

— Penghe Geng
sumber

Lihatlah dengan cakupan dan lihat apa yang sebenarnya Anda dapatkan. Mungkin perangkat keras Anda belum siap untuk mengirim bingkai baru setelah segera setelah mengirimnya. Juga, apakah Anda memperhitungkan waktu ACK? Jumlah bit Anda yang tidak berlabel tidak membantu dalam memberi tahu kami apa yang sebenarnya Anda hitung.

— Olin Lathrop

Dalam praktiknya, sulit untuk mendapatkan utilisasi bus 100% untuk waktu yang lama melalui bus CAN, karena kebutuhan akan waktu ACK dan jarak antarframe. Pengontrol CAN Anda mungkin tidak dapat mendukung pemanfaatan bus 100% untuk waktu yang lama.

— Tristan Seifert

Bergantung pada data apa yang Anda kirim, isian bit dapat meningkatkan ukuran frame Anda hingga 10%.

— WhatRoughBeast

@xiaobai - Tidak, panjang bidang data berubah. Adapun tautan, Anda sudah menyediakannya. Baca seluruh halaman. Jika tes Anda mengirim semua nol atau semua yang, itu akan menjelaskan banyak hal.

— WhatRoughBeast

ACK dapat mempengaruhi waktu transmisi jika Anda tidak memperhitungkannya. Sekali lagi, kekacauan jumlah dijumlahkan yang tidak berlabel tidak memberi tahu kami apa yang sebenarnya Anda tambahkan, dan karena itu apa yang mungkin Anda lewatkan.

— Olin Lathrop

Jawaban:

Sesuai saran Olin Lathrop, saya akan mengembangkan bit-stuffing.

BISA menggunakan pengkodean NRZ, dan karenanya tidak senang dengan jangka panjang satu atau nol (Ini kehilangan jejak di mana tepi jam seharusnya). Ini memecahkan masalah potensial ini dengan bit-stuffing. Saat mentransmisikan, jika bertemu dengan 5 yang berurutan atau nol, ia menyisipkan sedikit polaritas lainnya, dan ketika menerima, jika berhadapan dengan 5 yang berurutan atau nol, ia mengabaikan bit berikutnya (kecuali bitnya sama dengan yang sebelumnya bit, dalam hal ini mengeluarkan flag kesalahan).

Jika Anda mengirim semua nol atau semua yang untuk data pengujian Anda, serangkaian 64 bit yang identik akan menghasilkan penyisipan 12 bit yang diisi. Ini akan meningkatkan panjang total frame menjadi 140 bit, dengan frame rate terbaik-case dari 874 frame / detik. Jika bit data sama dengan MSB CRC, Anda akan mendapatkan bit lainnya di sana, dan frame rate turun menjadi 868 frame / detik. Jika CRC memiliki jangka panjang satu atau nol, itu akan mengurangi frame rate lebih jauh. Pertimbangan yang sama berlaku untuk pengidentifikasi Anda.

Sebanyak 16 bit isian akan menghasilkan frame rate ideal 850,3 frame / detik, jadi Anda harus mempertimbangkannya. Tes cepat akan menggunakan data uji dengan bit bergantian, dan lihat apa yang terjadi pada frame rate Anda.

— WhatRoughBeast
sumber

Ya, dalam tes awal saya memang ada banyak nol di payload dan ID. Setelah saya memastikan tidak ada 5 nol berturut-turut baik dalam data atau ID, sekarang saya bisa mendapatkan 940 frame / detik, sangat dekat dengan batas yang dihitung. Terima kasih banyak atas jawabannya.

— Penghe Geng

Olin benar dengan deskripsinya tentang bit stuffing dan bagaimana hal itu dapat memengaruhi throughput CAN secara teoritis. Satu hal lagi yang dapat menurunkan throughput aktual dari teori adalah latensi. Bahkan jika pengontrol CAN Anda dapat mencapai utilisasi bus 100%, prosesor host mungkin tidak dapat menangani Tx dan / atau Rx pada tingkat itu. Ini bisa jadi hasil dari prosesor yang lambat dan / atau firmware yang tidak efisien yang mengimplementasikan stack CAN.

— Trent Weaver
sumber

Frame 2.0a (standar) terkecil yang dapat Anda buat adalah 47bits ... Frame 2.0b (extended) terkecil yang dapat Anda buat adalah 67bits ... Itu Termasuk 3bits dari jarak antar-frame, dan Tidak Termasuk memasukkan sedikit ... Secara teori kita bisa membangun bingkai yang tidak akan pernah bisa; Pada kenyataannya, bit stuffing akan terjadi cukup banyak!

Baud maksimum untuk CANBus 2.0a / b adalah 1Mbit.
Pada 1Mb / S, bit tunggal (dominan / resesif) adalah 1uS, yaitu. 0,000'001 S
Jadi frame 67bit [kerangka 2.0b teoritis terkecil ] akan membutuhkan 67uS untuk ditransmisikan - sebelum frame (67bit) lainnya dapat ditransmisikan.
1'000'000 / 67 memberikan 14.925 frame lengkap (+ 25 bit dari frame berikutnya)

Saat Anda menjalankan pada 1/8 kecepatan itu, Anda bisa mendapatkan paling banyak 1/8 dari paket
14'925 / 8 = 1'865 frame / Detik @ 125Kb

Pada saat Anda menggunakan semua 64 bit (8 bit) data, dan MEMASANG Anda belum memicu bit stuffing "kesalahan" dengan memiliki string 1's berturut-turut atau 0's
1'000'000 / (67 + 64) = 7'633
7 ' 633/8 = 954

Dan itu juga dengan asumsi kabel Anda sempurna. Apakah bis Anda dapat dibuat dari kabel UTP 120ohm dan dipisahkan secara kapasitif di kedua ujungnya? Atau kabel acak dengan resistor 120ohm di satu ujung?

Secara keseluruhan saya akan mengatakan Anda melakukan cukup baik untuk mendapatkan 90% dari throughput maksimum teoritis.

— Chip biru
sumber