Qual é a taxa máxima de quadros (mensagens) do barramento CAN em 125 kbit / s?

Meu barramento CAN está rodando a 125 kbit / se está usando exclusivamente o formato de quadro estendido. Gostaria de saber qual é a taxa máxima de quadros CAN que posso enviar. Suponha que o comprimento dos dados seja sempre oito bytes.

De acordo com esta página da Wikipedia , cada quadro tem um tamanho máximo de (1+11+1+1+18+1+2+4+64+15+1+1+1+7) = 128bits:

Digite a descrição da imagem aqui

Levando em conta um espaçamento entre quadros mínimo de três bits , a taxa máxima de pacotes abaixo de 125 kbit / s deve ser: 125000 / ( 128 + 3) = 954quadros por segundo.

Mas no meu teste, eu não conseguia chegar tão alto. A taxa máxima de quadros que posso atingir (com todos os dados de oito bytes) é de cerca de 850 quadros por segundo.

O que há de errado aqui - meu cálculo ou meu método de teste?

communication can speed

— Penghe Geng
fonte

Olhe para ele com um escopo e veja o que você está realmente recebendo. Talvez o seu hardware não esteja pronto para transmitir um novo quadro imediatamente após o envio do mesmo. Além disso, você está levando em consideração o tempo de confirmação? Sua soma de bits não rotulada não é útil para nos dizer exatamente o que você está contando.

— Olin Lathrop

Na prática, é difícil obter 100% de utilização do barramento por um período prolongado em um barramento CAN, devido à necessidade de tempos de confirmação e espaçamento entre quadros. Seu controlador CAN pode não ser capaz de suportar 100% de utilização do barramento por um longo período de tempo.

— Tristan Seifert

Dependendo exatamente dos dados que você está enviando, o preenchimento de bits pode aumentar o tamanho do quadro em até 10%.

— WhatRoughBeast

@xiaobai - Não, o comprimento do campo de dados muda. Quanto a um link, você já o forneceu. Leia a página inteira. Se seus testes estiverem enviando todos os zeros ou todos, isso explicaria muito.

— WhatRoughBeast

O ACK pode afetar o tempo de transmissão se você não prestar contas. Novamente, sua bagunça não marcada de números somados não nos diz o que você realmente está somando e, portanto, o que pode estar faltando.

— Olin Lathrop

Respostas:

De acordo com a sugestão de Olin Lathrop, vou expandir o recheio de bits.

O CAN usa a codificação NRZ e, portanto, não fica satisfeito com longas execuções de zeros ou zeros (perde a noção de onde as bordas do relógio deveriam estar). Ele resolve esse problema em potencial preenchendo os bits. Ao transmitir, se encontrar uma série de 5 zeros ou zeros sucessivos, ele insere um pouco da outra polaridade e, ao receber, se encontrar 5 zeros ou zeros sucessivos, ignora o bit subsequente (a menos que o bit seja o mesmo que o anterior). bits, caso em que emite um sinalizador de erro).

Se você estiver enviando todos os zeros ou todos os seus dados de teste, uma sequência de 64 bits idênticos resultará na inserção de 12 bits empalhados. Isso aumentará o comprimento total de quadros para 140 bits, com uma taxa de quadros no melhor dos casos de 874 quadros / s. Se os bits de dados forem os mesmos que o MSB do CRC, você receberá outro bit recheado e a taxa de quadros cairá para 868 quadros / s. Se o CRC tiver séries longas ou zeros, isso reduzirá ainda mais a taxa de quadros. A mesma consideração se aplica aos seus identificadores.

Um total de 16 bits empacotados produzirá uma taxa de quadros ideal de 850,3 quadros / s, então você deve considerar isso. Um teste rápido seria usar dados de teste com bits alternados e ver o que acontece com sua taxa de quadros.

— WhatRoughBeast
fonte

Sim, no meu teste original, de fato, existem muitos zeros na carga útil e no ID. Depois de garantir que não haja 5 zeros sucessivos nos dados ou no ID, agora posso obter 940 quadros / s, muito próximo do limite calculado. Muito obrigado pela ótima resposta.

— Penghe Geng

Olin está certo com sua descrição do preenchimento de bits e como isso pode afetar adversamente o rendimento teórico da CAN. Outra coisa que pode degradar ainda mais o rendimento real da teoria é a latência. Mesmo que seu controlador CAN consiga atingir 100% de utilização do barramento, o processador host pode não ser capaz de lidar com Tx e / ou Rx nessa taxa. Isso pode ser o resultado de um processador lento e / ou firmware ineficiente que implementa a pilha CAN.

— Trent Weaver
fonte

O menor quadro de 2.0a (padrão) que você pode criar é de 47 bits ... O menor quadro de 2.0b (estendido) que você pode criar é de 67 bits ... Isso inclui 3 bits de espaçamento entre quadros e exclui preenchimento de bits ... Em teoria nós podemos construir uma moldura que nunca irá encher; Na realidade, um pouco de recheio vai acontecer bastante!

O baud máximo para o CANBus 2.0a / b é de 1Mbit.
Em 1Mb / S, um único bit (dominante / recessivo) tem 1uS de comprimento, ou seja. 0.000'001 S
Portanto, um quadro de 67 bits [o menor quadro teórico de 2.0b] precisará de 67uS para transmitir - antes que outro quadro (67 bits) possa ser transmitido.
1'000'000 / 67 fornece 14.925 quadros completos (+ 25 bits do próximo quadro)

Como você está rodando a 1/8 dessa velocidade, é possível obter no máximo 1/8 dos pacotes
14'925 / 8 = 1'865 quadros / segundo a 125Kb

No momento em que você está usando todos os 64 bits (8 bytes) de dados, e ASSUMINDO que você não acionou "erros" de preenchimento de bits por ter cadeias de 1 ou 0 consecutivos
1'000'000 / (67 + 64) = 7'633
7 ' 633/8 = 954

E isso também assumindo que sua fiação é perfeita. O seu barramento de lata é feito de cabo UTP de 120 ohm e desacoplado capacitivamente nas duas extremidades? Ou algum fio aleatório com um resistor de 120ohm em uma extremidade?

No geral, eu diria que você está indo muito bem para obter 90% do rendimento máximo teórico.

— Chip azul
fonte