O MCP2551 é um conversor de UART para CAN?

Quero fazer um sniffer de barramento CAN por 250 kbit / s usando meu computador. Após algumas pesquisas, descobri que o MCP2551 é algum tipo de regulador de nível de tensão para a camada física do CAN. Mantendo isso em mente, gostaria de saber se essa configuração poderia funcionar. Eu só quero gravar as mensagens trocadas para fins de teste automatizado, não fazer parte da comunicação:

PC <-> USB-UART (talvez CP2102, porque já tenho um) <-> MCP2551 <-> barramento CAN

Caso contrário, que tipo de sinal deve ser inserido no MCP2551 para que eu faça parte do barramento?

usb microchip can

— rnunes
fonte

Respostas:

Você pode fazer isso, mas o que você obterá no seu barramento CAN será o UART usando os níveis de tensão do CAN. Você deve fornecer ao MCP2551 as mensagens do protocolo CAN se desejar se comunicar com os dispositivos CAN do seu barramento. O mesmo para ouvir: as mensagens CAN são tão diferentes do formato UART que o UART não sabe o que fazer com elas. Você terá pelo menos erros de quadro o tempo todo e não obterá o conteúdo da mensagem.
Esta imagem mostra a estrutura de uma mensagem CAN:

insira a descrição da imagem aqui

Existem muitos microcontroladores por aí que possuem uma interface CAN, sem o transceptor. É para eles que o MCP2551 foi projetado. No passado, usamos o NXP LPC2294, que possui 4 interfaces CAN. Cada um deles precisa de um MCP2551 para conectar-se a um barramento CAN. Os controladores mais recentes do NXP incluem a família LPC1800 , da qual todos os membros suportam o CAN.

— stevenvh
fonte

Eu esqueci totalmente os bits de início / parada do UART e provavelmente algumas situações de "início / início dos bits" do CAN. Eu provavelmente vou tentar encontrar uma solução usando uma pilha CAN no PC usando FTDI como GPIO que vai acabar transmitindo para MCP2551

— rnunes

@ rnunes - Não são apenas os bits de início / parada. Sem esses, a transmissão UART é apenas um byte de 8 bits. Uma mensagem CAN é muito mais complexa, com endereçamento, prioridade e verificação de erros. Você não pode comparar os dois.

— Stevenvh 19/05

Mas, usando o FTDI, estarei trabalhando pouco a pouco (basicamente, é um USB muito rápido <-> GPIO), não byte a byte, como no UART. Eu já estou procurando aqueles CAN MCU, mas eu preferiria gastar algum dinheiro por enquanto (é um projeto de hobby para estudantes) e eu já tenho o FTDI. Se eu concluir com minhas pesquisas que o FTDI não será capaz de fazer isso, tentarei usar um CAN MCU.

— Rnunes 19/05/12

A pilha será responsável por lidar com tudo (por exemplo, enchimento de bits) e transmiti-la pouco a pouco para o MCP2551. O único problema que estou tendo agora é a latência do FTDI, porque preciso que seja rápido e regular, mas medirei mais tarde.

— Rnunes 19/05/12

@ rnunes - Mas o que sai do CP2102 (SiLabs, não FTDI) são bytes , não bits. Você não pode parar depois de um pouco. Você precisará do CP2102 para fazer a interface do seu microcontrolador com USB e de um microcontrolador que suporte CAN + o MCP2551. Ou um microcontrolador que também pode funcionar como um dispositivo USB. Então você não precisa do CP2102.

— Stevenvh 19/05/12

Eu fiz uma interface USB / CAN usando o FT2232H no modo MPSSE (esqueça UART), MCP2515 e MCP2551. MCP2515 é a peça chave que você está perdendo aqui. Estude bem o que faz. É o controlador CAN real que enquadra, ACKs, geração e verificação de soma de verificação, filtragem de mensagens e outras coisas menos óbvias que um nó CAN deve fazer pelo padrão. Se você deseja um sniffer, o MCP2515 possui um modo de escuta que não garante transmissão no barramento. O MCP2551 é simplesmente um adaptador de camada física estúpido, semelhante a um MAX232 para RS-232 ou ADM485 para RS-485.

Agora, essa arquitetura está longe de ser perfeita, pois a tecnologia FTDI MPSSE não tem suporte para interrupções (acredito que ela use apenas transferências USB em massa nos bastidores), por isso preciso pesquisar o controlador com frequência para novas mensagens. Isso carrega muita carga no controlador host USB, mas ainda não garante que nenhuma mensagem seja perdida (o MCP2515 pode armazenar até 2 mensagens recebidas internamente se você ativar o "modo de transbordamento", apenas uma se não o fizer). Uma solução muito melhor seria um microcontrolador adequado com periféricos CAN e USB embutidos, como o STM32F105 (103 não pode usar USB e CAN ao mesmo tempo). Veja este projeto para uma implementação de trabalho exatamente dessa ideia. O LPC18xx, como sugerido por stevenh, também funcionará, mas o LPC17xx provavelmente é mais barato e fácil de encontrar.

— Espinho
fonte

Nesse caso, o pool não é um problema, mas sim, a solução ideal seria usar um MCU com controlador CAN que funcione como um buffer de mensagem CAN. A partir de agora, tentarei usar a primeira configuração que você escreveu. Obrigado

— rnunes

+1 O uso do chip FTDI para conversar diretamente com um controlador CAN sem um uC é interessante. Aparentemente, o FTDI lançou o FT221X, que é uma ponte USB para SPI dedicada. (Existe um modelo diferente para USB para I2C também.)

— Nick Alexeev

Como você deseja ouvir um barramento CAN existente, como eu entendo a pergunta, você realmente não pode usar um UART. O CAN e o UART siganlling são totalmente diferentes.

Em teoria, você poderia observar a linha de recebimento do CAN que sai do MCP2551 e decodificar o tráfego do CAN. Isso não será fácil, mas é teoricamente possível. Sem o hardware CAN especializado, você terá que amostrar algumas vezes mais rápido que a taxa de bits CAN e decodificar esse fluxo de bits no software posteriormente. Você provavelmente precisará gravar a cerca de 1 Mbit / s para decodificar o CAN de 250 kbit / s.

Usar um microcontrolador será muito mais fácil. O PIC 18F2580 e outros processadores similares possuem um periférico CAN embutido. O hardware decodifica todo o nível de bits e recebe quadros CAN inteiros. O processador pode então enviar os quadros CAN recebidos via seu UART para o seu PC.

— Olin Lathrop
fonte