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

Mi bus CAN funciona a 125 kbit/s y utiliza exclusivamente formato de trama extendida. Me gustaría saber cuál es la tasa máxima de tramas CAN que puedo enviar. Suponga que la longitud de los datos es siempre de ocho bytes.

De acuerdo con esta página de Wikipedia , cada cuadro tiene una longitud máxima de cuadro de (1+11+1+1+18+1+2+4+64+15+1+1+1+7) = 128bits:

Ingrese la descripción de la imagen aquí

Teniendo en cuenta un espacio entre tramas mínimo de tres bits , la tasa máxima de paquetes por debajo de 125 kbit/s debe ser: 125000 / ( 128 + 3) = 954tramas por segundo.

Pero en mi prueba, no pude llegar tan alto. La velocidad de fotogramas máxima que puedo lograr (con los datos de ocho bytes) es de alrededor de 850 fotogramas por segundo.

¿Qué está mal aquí, mi cálculo o mi método de prueba?

Mírelo con un alcance y vea lo que realmente está obteniendo. Quizás su hardware no esté listo para transmitir un nuevo marco inmediatamente después de haberlo enviado. Además, ¿estás teniendo en cuenta el tiempo de ACK? Su suma de bits no etiquetada no es útil para decirnos qué es exactamente lo que está contando.
En la práctica, es difícil obtener una utilización del bus del 100 % durante un tiempo prolongado en un bus CAN, debido a la necesidad de tiempos de ACK y espacio entre tramas. Es posible que su controlador CAN no pueda admitir la utilización del bus al 100 % durante un período de tiempo prolongado.
Dependiendo exactamente de los datos que envíe, el relleno de bits puede aumentar el tamaño de su marco hasta en un 10%.
@WhatRoughBeast ¿Quiere decir que el espacio entre cuadros cambia según el contenido del paquete? ¿Tienes un enlace para algún detalle?
@OlinLathrop \@TristanSerifert: dado que ACK es solo un campo de bits de un campo de cuadro CAN, ¿cómo puede afectar el tiempo de transmisión?
@xiaobai: no, la longitud del campo de datos cambia. En cuanto a un enlace, ya lo proporcionaste. Lea toda la página. Si sus pruebas envían todos ceros o todos unos, eso explicaría muchas cosas.
ACK puede afectar el tiempo de transmisión si no lo tiene en cuenta. Una vez más, su lío sin etiquetar de números sumados no nos dice lo que realmente está sumando y, por lo tanto, lo que podría estar perdiendo.
@Qué: Buen punto. Debería hacer de eso una respuesta, tal vez con algunos antecedentes sobre el relleno de bits. Parece que el OP ni siquiera sabe que existe, y admito que lo había olvidado.
@WhatRoughBeast Tengo entendido que si se envía una ejecución de cuatro bits consecutivos del mismo valor, se agrega un bit adicional de polaridad opuesta para crear un borde que los controladores pueden usar para la temporización de bits. ¿Ese relleno de bits se aplica solo a los datos o a todo el marco? Usted dice 10%, pero si el relleno se aplica a todo el marco, entonces el aumento no sería de hasta un 20% (ya que se pueden rellenar hasta 1 de cada 5 bits). Aunque esperaría que el promedio fuera mucho menor.
@ user4574: para CAN, son 5 bits, no 4. Y se aplica a todos los bits. Entonces, en principio, podría obtener casi un 20% de aumento en el tamaño del paquete. Y tampoco es del todo aleatorio, ya que puede elegir sus patrones de identificación para evitar el problema, y ​​eso puede evitar el relleno en una sección de 31 bits.

Respuestas (4)

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

CAN usa la codificación NRZ y, por lo tanto, no está contento con las series largas de unos o ceros (pierde la noción 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 unos o ceros sucesivos, inserta un bit de la otra polaridad, y al recibir, si encuentra 5 unos o ceros sucesivos, ignora el bit siguiente (a menos que el bit sea el mismo que el anterior). bits, en cuyo caso emite un indicador de error).

Si está enviando todos ceros o todos unos para sus datos de prueba, una cadena de 64 bits idénticos dará como resultado la inserción de 12 bits rellenos. Esto aumentará la longitud total de los cuadros a 140 bits, con una tasa de cuadros en el mejor de los casos de 874 cuadros por segundo. Si los bits de datos son los mismos que el MSB del CRC, obtendrá otro bit relleno allí y la velocidad de fotogramas bajará a 868 fotogramas/seg. Si el CRC tiene series largas 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 fotogramas ideal de 850,3 fotogramas por segundo, por lo que debe tenerlo en cuenta. Una prueba rápida sería usar datos de prueba con bits alternos y ver qué sucede con su velocidad de fotogramas.

Sí, en mi prueba original hay muchos ceros en la carga útil y la ID. Después de asegurarme de que no hay 5 ceros sucesivos ni en los datos ni en el ID, ahora puedo obtener 940 fotogramas por segundo, muy cerca del límite calculado. Muchas gracias por la gran respuesta.

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

El baudio máximo para CANBus 2.0a/b es 1Mbit.
A 1 Mb/S, un solo bit (dominante/recesivo) tiene una longitud de 1 uS, es decir. 0.000'001 S
Entonces, un marco de 67 bits [el marco teórico más pequeño de 2.0b] tardará 67 uS en transmitirse, antes de que se pueda transmitir otro marco (67 bits).
1'000'000 / 67 da 14.925 fotogramas completos (+ 25 bits del siguiente fotograma)

Como corre a 1/8 de esa velocidad, puede obtener como máximo 1/8 de los paquetes
14'925 / 8 = 1'865 cuadros/Segundo @125Kb

En el momento en que esté utilizando todos los 64 bits (8 bytes) de datos, y ASUMIENDO que no ha desencadenado "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 bus de lata está hecho de cable UTP de 120 ohmios y está desacoplado capacitivamente en ambos extremos? ¿O algún cable al azar 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 máximo teórico.

Olin tiene razón con su descripción del relleno de bits y cómo eso puede afectar negativamente el rendimiento teórico de CAN. Otra cosa que puede degradar aún más el rendimiento real del teórico es la latencia. Incluso si su controlador CAN puede lograr una utilización del bus del 100%, 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.

Otra pregunta interesante desde la perspectiva de un receptor sería

¿Cuál es la frecuencia máxima de transferencia de tramas en el peor de los casos?

Para este caso, los bits de relleno probablemente se pueden ignorar, ya que hacen que la frecuencia sea más baja.

.

Mirando solo a los marcos de identificación estándar:

Para la longitud de datos 1, tendría que calcular con

55 Bits (sobrecarga mínima + 8 bits de datos + 3 espacios de interfase)

--> la frecuencia máxima de fotogramas para 1 Mbit es de aproximadamente 18181,8/s (1/0,000055)

Para la longitud de datos 0 (también puede ser una información) tendría que calcular con

47 Bits (sobrecarga mínima + 3 espacios de interfame)

--> la frecuencia máxima de fotogramas para 1 Mbit es de aproximadamente 21276,6/s (1/0,000047)

¿Cuál es la velocidad máxima de tramas (mensajes) del bus CAN a 125 kbit/s?
RespuestasAquíPolítica de privacidad1y, 0v