fundo

Estou desenvolvendo um projeto que exigirá as modestas especificações do microcontrolador de:

• 8 ADCs de 12 bits e 10kHz
• 1kB de RAM
• Tamanho de 48 QFN ou menor
• Protocolo de comunicação resistente a ruído e correção de erros de 20kbps, encadeado em série

Os requisitos de processamento de sinal são bastante baixos e a maioria pode ser exportada para o processador mestre no sistema. As três primeiras especificações são fáceis de atender e podem ser feitas por menos de US $ 2 em quantidade. No entanto, a comunicação estará acontecendo em um ambiente eletricamente barulhento, de modo que redes vulneráveis ​​a ruído, como LIN e I2C, estão fora. Um argumento adicional contra o LIN é que eu gostaria de executar a coisa toda em 5V ou 3,3V, e os transceptores LIN exigem 12V e, portanto, exigiriam um regulador ou fio extra por placa de sensor. Inicialmente, escolhi o CAN para esta tarefa. No entanto, os controladores CAN adicionam um custo considerável, e estou curioso para saber se isso pode ser feito em software.

Camada física CAN

A especificação CAN define as camadas Data Link e Physical do modelo de referência de rede OSI. Existem muitos ICs baratos de 8 pinos, como o NXP TJA1040 / 50 , Maxim MAX3058 / 59 , Microchip MCP2551 e TI SN65HVD1050 para implementar a camada física. Implementar a camada física com conversores D / A ou amplificadores operacionais seria difícil, se não impossível, portanto esses ICs valem bem o valor de US $ 1 ou mais que custam.

Camada de protocolo / protocolo de dados CAN

Para a camada Data Link, alguns microcontroladores adicionam módulos de protocolo CAN às camadas básicas de comunicação UART, I2C e SPI. No entanto, estes são significativamente mais caros que os chips básicos.

Investigação do custo dos módulos do protocolo CAN

Para comprovar essa afirmação, aqui estão alguns micros populares nas versões CAN e não CAN, a partir de:

• ATmega16 - ATMEGA16M1 (com CAN): US $ 3,87, ATMEGA168A (sem CAN): US $ 3,23
• dsPIC - DSPIC33FJ64MC802 (com CAN): US $ 6,14, DSPIC33FJ64GP202 (sem CAN): US $ 5,48
• PIC18 - PIC18F2480 (com CAN): $ 6,80, PIC18F24J10 (sem CAN): $ 2,10
• Cortex-M3 - STM32F103C4T6A (com CAN): US $ 6,50, STM32F100C4T6B (sem CAN): US $ 2,73

Para ser justo, eu apenas comparei microcontroladores com tamanhos de memória equivalentes, no entanto, muitas das versões não CAN estão disponíveis com tamanhos de memória menores por menos. Controladores CAN externos, como o Microchip MCP2515 , custam quase US $ 2, portanto é obviamente mais econômico ter o CAN integrado ao microcontrolador, se você tiver a opção.

Curiosamente, a parte ATmega é de longe a parte mais barata equipada com CAN no inventário da Digikey.

Função da camada de protocolo CAN

O módulo CAN encontrado nos microcontroladores dsPIC faz o seguinte:

O módulo de barramento CAN consiste em um mecanismo de protocolo e buffer / controle de mensagem. O mecanismo do protocolo CAN gerencia todas as funções para receber e transmitir mensagens no barramento CAN. As mensagens são transmitidas carregando primeiro os registros de dados apropriados. Status e erros podem ser verificados lendo os registros apropriados. Qualquer mensagem detectada no barramento CAN é verificada quanto a erros e comparada com filtros para ver se deve ser recebida e armazenada em um dos registros de recebimento.

Isso parece bastante factível em software.

A questão

Uma camada de protocolo de software pode ser usada para implementar a especificação CAN apenas com um microcontrolador de baixo custo equipado com UART e um transceptor CAN? Em caso afirmativo, existem implementações de código aberto?

Como alternativa, os transceptores CAN podem ser usados ​​com UARTs para implementar um protocolo personalizado? Eu estou bem com uma topologia de mestre único; Entendo que a arbitragem pode ser difícil de acertar em um protocolo personalizado.

Eu acho que implementar o protocolo CAN apenas no firmware será difícil e levará um tempo para acertar. Não é uma boa ideia.

No entanto, seus preços são altos. Acabei de verificar e um dsPIC 33FJ64GP802 no pacote QFN é vendido por 3,68 USD no microchipdirect por 1000 peças. O preço será mais baixo para volumes de produção reais.

O periférico CAN do hardware faz algumas coisas reais para você, e o aumento de preço não é nem de longe o que você está reivindicando.

Adicionado:

Como você parece determinado a tentar a rota do firmware, aqui estão alguns dos problemas óbvios que vêm à sua mente. Provavelmente haverá outros problemas que ainda não me ocorreram.

Você quer fazer CAN a 20 kbit / s. Essa é uma taxa muito lenta para o CAN, que chega a 1Mbit / s por pelo menos 10s de metros. Para fornecer um ponto de dados, o padrão de sinalização a bordo do NMEA 2000 é aplicado no CAN a 200 kbits / s, o que significa ir de uma extremidade a outra de um navio grande.

Você pode pensar que tudo o que precisa é de uma interrupção por bit e pode fazer tudo o que precisa nessa interrupção. Isso não funcionará porque há várias coisas acontecendo a cada bit do CAN. Duas coisas em particular precisam ser feitas no nível sub-bit. O primeiro é detectar uma colisão e o segundo é ajustar a taxa de bits em tempo real.

Existem dois estados de sinalização em um barramento CAN, recessivo e dominante. Recessivo é o que acontece quando nada está dirigindo o ônibus. Ambas as linhas são unidas por um total de 60 Ω. Um barramento CAN normal, implementado por chips comuns como o MCP2551, deve ter terminadores de 120 at nas duas extremidades, portanto um total de 60 Ω unindo passivamente as duas linhas diferenciais. O estado dominante é quando as duas linhas são ativamente separadas, algo em torno de 900mV do estado recessivo, se bem me lembro. Basicamente, isso é como um barramento coletor aberto, exceto que ele é implementado com um par diferencial. O barramento está em estado recessivo se CANH-CANL <900mV e dominante quando CANH-CANL> 900mV. O estado dominante sinaliza 0 e o recessivo 1.

Sempre que um nó "grava" um 1 no barramento (solta), ele verifica se algum outro nó está gravando um 0. Quando você encontra o barramento no estado dominante (0) quando pensa que está enviando e o o bit atual que você está enviando é 1, então isso significa que outra pessoa está enviando também. As colisões só importam quando os dois remetentes discordam, e a regra é que aquele que envia o estado recessivo recua e anula sua mensagem. O nó que envia o estado dominante nem sabe que isso aconteceu. É assim que a arbitragem funciona em um barramento CAN.

As regras de arbitragem do barramento CAN significam que você deve observar o barramento no meio de cada bit enviado como 1 para garantir que alguém não esteja enviando um 0. Essa verificação geralmente é feita em cerca de 2/3 do bit , e é a limitação fundamental no comprimento do barramento CAN. Quanto mais lenta a taxa de bits, mais tempo há para a propagação do pior caso de uma extremidade do barramento para a outra e, portanto, mais longo o barramento pode ser. Essa verificação deve ser feita sempre que você achar que possui o barramento e enviar 1 bit.

Outro problema é o ajuste da taxa de bits. Todos os nós em um barramento devem concordar com a taxa de bits, mais próximo do que com o RS-232. Para evitar que pequenas diferenças de relógio se acumulem em erros significativos, cada nó deve poder fazer um pouco um pouco mais ou menos que o valor nominal. No hardware, isso é implementado executando um relógio em torno de 9x a 20x mais rápido que a taxa de bits. Os ciclos desse relógio rápido são chamados de quanta de tempo. Existem maneiras de detectar que o início de novos bits está vagando em relação a onde você acha que eles deveriam estar. As implementações de hardware adicionam ou pulam quanta de uma vez um pouco para sincronizar novamente. Existem outras maneiras de implementar isso, desde que você possa ajustar pequenas diferenças de fase entre os tempos de bits esperados e os tempos de bit medidos reais.

De qualquer maneira, esses mecanismos exigem que várias coisas sejam feitas em vários momentos dentro de um pouco. Esse tipo de tempo será muito complicado no firmware ou exigirá que o barramento seja executado muito lentamente. Digamos que você implemente um sistema de quanta de tempo no firmware a 20 kbits / s. No mínimo 9 quanta de tempo por bit, isso exigiria interrupção de 180 kHz. Isso certamente é possível com algo como um dsPIC 33F, mas consumirá uma fração significativa do processador. Na taxa máxima de instruções de 40 MHz, você obtém 222 ciclos de instruções por interrupção. Não deve demorar muito para fazer todas as verificações, mas provavelmente 50-100 ciclos, o que significa que 25-50% do processador será usado para CAN e que será necessário antecipar tudo o que estiver em execução. Isso evita muitos aplicativos que esses processadores geralmente executam, como pulso por controle de pulso de uma fonte de alimentação chaveada ou de um driver de motor. A latência de 50 a 100 ciclos em todas as outras interrupções seria uma parada completa para muitas das coisas que eu fiz com chips como este.

Então você vai gastar o dinheiro para fazer de alguma forma. Se não estiver no periférico de hardware dedicado para esse fim, obtenha um processador maior para lidar com a sobrecarga significativa do firmware e lide com a latência de interrupção grande e imprevisível e possível para todo o resto.

Depois, há a engenharia inicial. O periférico CAN simplesmente funciona. Pelo seu comentário, parece que o custo incremental desse periférico é de US $ 0,56. Isso parece uma pechincha para mim. A menos que você tenha um produto de volume muito alto, não há como recuperar o tempo e as despesas consideráveis ​​necessários para implementar o CAN apenas no firmware. Se o seu volume for tão alto, os preços que mencionamos não são realistas, e o diferencial de adicionar o hardware CAN será menor.

Realmente não vejo isso fazendo sentido.

Nós usamos o PIC18F25K80 . Embora não tenha um DSP, é de aproximadamente $ 2 em quantidade. É quase um substituto direto para o PIC18F2480 que você mencionou. Usamos o compilador CCS e sua pilha de software para CAN, que provavelmente é portada do Microchip. Funciona bem para tudo que eu precisava e tentei.

Se estou lendo isso corretamente, parece que você deseja basear a funcionalidade CAN usando apenas um UART e algum firmware inteligente. Confie em mim, isso nunca funcionará - sugiro ler um bom texto sobre os meandros do CAN ou CANopen. Você erradicou todas as economias que procurava ao seguir esse caminho.

Eu usaria um microcontrolador com um módulo CAN e repassaria os US $ 2 extras ou já pensou em um protocolo diferente que seja compatível com um UART, como o Modbus sobre RS-485 ?

Também estou pensando em trocar o protocolo CAN em um PIC µC, então, por favor, EricM, se você realmente fez isso, responda e diga pelo menos qual taxa de bits em que frequência de núcleo do PIC18F ou DSPic você obteve. Valeu!

Em geral: o RS 485 seria a solução para o problema principal solicitado, mas também seria possível usar os transmissores CAN- (ou mesmo FlexRay) com comunicações UART não full-duplex (ponto 2 ponto) como todos os protocolos use a codificação NRZ.

Mas, no UART / V24 / RS232, o full duplex é usado principalmente sem pensar em detalhes; talvez seja necessário colocar um pouco de cérebro no superloop ou na máquina de estado do seu aplicativo ...

Mas voltando ao CAN-bitbanging: estou trabalhando com o CAN por muitos anos e nunca vi uma implementação de bitbanging, mas tanto quanto posso pensar, isso deve funcionar para tempos de bits de até 100kBit tp até 100kBit com µC moderno como DSPic ou ARM etc. (tendo núcleos a 80 MHz ou superior ...)

Pelo menos se apenas a leitura for considerada ... O envio significaria alguma sobrecarga na preparação das estruturas de bits para que não fosse possível alcançar 100% de carga de barramento, mas no CAN mais de 65% é raro ...