125kbit / s의 최대 CAN 버스 프레임 (메시지) 속도는 얼마입니까?

CAN 버스가 125kbit / s로 실행 중이며 확장 프레임 형식을 독점적으로 사용하고 있습니다. 보낼 수있는 CAN 프레임의 최대 속도가 얼마인지 알고 싶습니다. 데이터 길이가 항상 8 바이트라고 가정하십시오.

이 Wikipedia 페이지 에 따르면 각 프레임의 최대 프레임 길이는 (1+11+1+1+18+1+2+4+64+15+1+1+1+7) = 128다음과 같습니다.

여기에 이미지 설명을 입력하십시오

최소 3 비트 인터 프레임 간격 을 고려하면 125kbit / s 미만의 최대 패킷 속도는 125000 / ( 128 + 3) = 954초당 프레임 수입니다.

그러나 내 시험에서 나는 그것을 높이 얻을 수 없었다. 내가 달성 할 수있는 최대 프레임 속도 (8 바이트 데이터 모두)는 초당 약 850 프레임입니다.

내 계산 또는 테스트 방법에 문제가 있습니까?

communication can speed

— Penghe Geng
소스

범위와 함께 그것을보고 실제로 무엇을보고 참조하십시오. 아마도 당신의 하드웨어는 새로운 프레임을 보낸 직후에 새로운 프레임을 전송할 준비가되지 않았을 것입니다. 또한 ACK 시간을 고려하고 있습니까? 레이블이없는 비트의 합은 정확히 무엇을 계산하는지 알려주는 데 도움이되지 않습니다.

— Olin Lathrop

실제로, ACK 시간과 인터 프레임 간격이 필요하기 때문에 CAN 버스를 통해 연장 된 시간 동안 100 % 버스 이용률을 얻기가 어렵습니다. CAN 컨트롤러가 장시간 동안 100 % 버스 사용률을 지원하지 못할 수 있습니다.

— Tristan Seifert

전송하는 데이터에 따라 비트 스터핑으로 프레임 크기를 최대 10 % 늘릴 수 있습니다.

— WhatRoughBeast

@xiaobai-아니요, 데이터 필드의 길이가 변경됩니다. 링크는 이미 제공했습니다. 전체 페이지를 읽으십시오. 테스트가 모두 0을 보내거나 모두 0을 보내면 많은 설명이 필요합니다.

— WhatRoughBeast

ACK는 설명하지 않으면 전송 시간에 영향을 줄 수 있습니다. 다시 말하지만, 레이블이없는 합산 된 숫자는 실제로 무엇을 더하고 있는지, 따라서 무엇을 놓치고 있는지 알려주지 않습니다.

— Olin Lathrop

답변:

Olin Lathrop의 제안에 따라 비트 스터핑을 확장하겠습니다.

CAN은 NRZ 코딩을 사용하므로 1 또는 0의 긴 실행에 만족하지 않습니다 (클록 에지가 있어야하는 위치를 잃음). 비트 스터핑으로이 잠재적 문제를 해결합니다. 전송할 때 연속 된 1 또는 0의 런을 만나면 다른 극성의 비트를 삽입하고 수신 할 때 연속적인 1 또는 0을 겪으면 후속 비트를 무시합니다 (비트가 이전과 동일하지 않은 경우) 비트,이 경우 에러 플래그를 발생시킵니다).

테스트 데이터에 대해 모두 0 또는 1을 모두 보내는 경우 64 개의 동일한 비트 문자열은 12 개의 채워진 비트를 삽입합니다. 이 경우 총 프레임 길이가 140 비트로 증가하고 874 프레임 / 초의 최상의 프레임 속도가 유지됩니다. 데이터 비트가 CRC의 MSB와 동일하면 다른 비트가 채워지고 프레임 속도는 868 프레임 / 초로 떨어집니다. CRC에 1 또는 0의 긴 실행이 있으면 프레임 속도가 훨씬 더 줄어 듭니다. 식별자에도 동일한 고려 사항이 적용됩니다.

총 16 개의 스터프 비트는 초당 850.3 프레임의 이상적인 프레임 속도를 생성하므로 고려해야합니다. 빠른 테스트는 교대로 비트가있는 테스트 데이터를 사용하여 프레임 속도에 어떤 영향이 있는지 확인하는 것입니다.

— WhatRoughBeast
소스

예, 원래 테스트에서 실제로 페이로드와 ID에는 많은 제로가 있습니다. 데이터 또는 ID에 5 개의 연속 0이 없는지 확인한 후 계산 된 한계에 매우 가까운 940 프레임 / 초를 얻을 수 있습니다 . 큰 답변을 주셔서 감사합니다.

— Penghe Geng

Olin은 비트 스터핑에 대한 설명과 이것이 이론적 인 CAN 처리량에 어떻게 악영향을 미칠 수 있는지에 대해 잘 알고 있습니다. 이론적으로 실제 처리량을 추가로 저하시킬 수있는 또 다른 사항은 대기 시간입니다. CAN 컨트롤러가 100 % 버스 사용률을 달성 할 수 있더라도 호스트 프로세서는 해당 속도로 Tx 및 / 또는 Rx를 처리하지 못할 수 있습니다. CAN 스택을 구현하는 느린 프로세서 및 / 또는 비효율적 인 펌웨어의 결과 일 수 있습니다.

— 트렌트 위버
소스

당신이 만들 수있는 가장 작은 2.0A (표준) 프레임 ... 작은 2.0B 47bits 당신이 구축 할 수 있습니다 (확장) 프레임이 그 프레임 간 간격의 3 비트를 포함 ... 67bits이며, 제외가에서 ... 때우는 비트 이론 우리는 결코 채우지 않을 프레임을 만들 수 있습니다. 실제로 비트 스터핑은 상당히 많이 일어날 것입니다!

CANBus 2.0a / b의 최대 전송 속도는 1Mbit입니다.
1Mb / S에서 단일 (우성 / 열성) 비트 길이는 1uS입니다. 0.000'001 S
따라서 67 비트 프레임 [가장 작은 이론적 2.0b 프레임]은 다른 6767 프레임이 전송되기 전에 67uS를 전송해야합니다.
1'000'000 / 67은 14,925 개의 완전한 프레임을 제공합니다 (다음 프레임의 25 비트 이상)

해당 속도의 1/8 속도로 실행하면
14'925 / 8 = 1'865 프레임 / 초 @ 125Kb의 최대 1/8 패킷을 얻을 수 있습니다.

64 비트 (8 바이트)의 모든 데이터를 사용하고 가정 할 때 연속 1 또는 0의
1'000'000 / (67 + 64) = 7'633
7 ' 의 문자열을 가짐으로써 비트 스터핑 "오류"를 트리거하지 않았습니다. 633/8 = 954

그리고 그것은 당신의 배선이 완벽하다고 가정합니다. 캔 버스는 120ohm UTP 케이블로 만들어졌으며 양쪽 끝에서 용량이 분리되어 있습니까? 아니면 한쪽 끝에 120ohm 저항을 가진 임의의 와이어가 있습니까?

전반적으로 이론상 최대 처리량의 90 %를 달성하기 위해 꽤 잘하고 있다고 말하고 싶습니다.

— 블루칩
소스