¿Cuál es la velocidad máxima de trama (mensaje) del bus CAN a 125 kbit / s?

Según la sugerencia de Olin Lathrop, ampliaré el relleno de bits.

CAN utiliza la codificación NRZ y, por lo tanto, no está contento con series largas de ceros o ceros (pierde la pista de dónde deberían estar los bordes del reloj). Resuelve este problema potencial mediante el relleno de bits. Al transmitir, si encuentra una serie de 5 sucesivos o ceros, inserta un poco de la otra polaridad, y cuando recibe, si encuentra 5 sucesivos o ceros, ignora el bit subsiguiente (a menos que el bit sea el mismo que el anterior). bits, en cuyo caso emite un indicador de error).

Si está enviando todos los ceros o ceros para sus datos de prueba, una cadena de 64 bits idénticos resultará en la inserción de 12 bits rellenos. Esto aumentará la longitud total de la trama a 140 bits, con una velocidad de trama de 874 cuadros / seg. Si los bits de datos son los mismos que los MSB del CRC, obtendrá otro bit relleno allí, y la velocidad de cuadros se reducirá a 868 cuadros / seg. Si el CRC tiene recorridos largos de unos o ceros, eso reducirá aún más la velocidad de fotogramas. La misma consideración se aplica a sus identificadores.

Un total de 16 bits rellenos producirá una velocidad de cuadro ideal de 850.3 cuadros / s, por lo que debe considerarla. Una prueba rápida sería usar datos de prueba con bits alternos y ver qué sucede con su velocidad de fotogramas.

Olin tiene razón con su descripción del relleno de bits y cómo puede afectar de manera adversa el rendimiento teórico de CAN. Otra cosa que puede degradar aún más el rendimiento real de la teoría es la latencia. Incluso si su controlador CAN puede alcanzar el 100% del uso del bus, es posible que el procesador host no pueda manejar Tx y / o Rx a esa velocidad. Esto podría ser el resultado de un procesador lento y / o un firmware ineficiente que implementa la pila CAN.

El marco 2.0a (estándar) más pequeño que puede generar es de 47 bits ... El marco 2.0b (extendido) más pequeño que puede generar es de 67 bits ... Eso incluye 3 bits de espaciado entre cuadros, y excluye el relleno de bits ... .En teoría podemos construir un marco que nunca se rellenará; En realidad, ¡el relleno de bits va a suceder bastante!

El máximo de baudios para CANBus 2.0a / b es de 1 Mbit.
En 1Mb / S, un bit único (dominante / recesivo) tiene una longitud de 1 uS, es decir. 0.000'001 S
Por lo tanto, una trama de 67 bits [la trama teórica 2.0b más pequeña] tomará 67uS para transmitir, antes de que se pueda transmitir otra trama (67 bits).
1'000'000 / 67 proporciona 14,925 fotogramas completos (+ 25 bits del siguiente fotograma)

A medida que se ejecuta a 1/8 de esa velocidad, puede obtener como máximo 1/8 de los paquetes
14'925 / 8 = 1'865 cuadros / Segundo a 125Kb

En el momento en que esté utilizando los 64 bits (8 bytes) de datos, y ASUMIENDO que no ha activado "errores" de relleno de bits al tener cadenas de 1 o 0 consecutivos. 1'000'000 / (67 + 64) = 7'633
7'633 / 8 = 954

Y eso también suponiendo que su cableado sea perfecto. ¿Su lata bus está hecha de cable UTP de 120 ohmios y está desacoplada capacitivamente en ambos extremos? ¿O algún cable aleatorio con una resistencia de 120 ohmios en un extremo?

En general, diría que lo está haciendo bastante bien para obtener el 90% del rendimiento teórico máximo.