Comunicação entre vários microcontroladores

Gostaria de começar a implementar um sistema composto por N microcontroladores (N> = 2 MCUs), mas gostaria de saber as possibilidades de permitir que eles se comuniquem um com o outro.

Idealmente, os microcontroladores (N-1) são colocados dentro da casa, atuando como clientes, enquanto o último (o "servidor") é conectado a um PC via USB. Os problemas que tenho agora são como conectar esses microcontroladores (N-1) ao "servidor". Os MCUs dos clientes executam tarefas muito simples, portanto, pode não ser uma boa solução usar ARMs para executar tarefas simples, apenas porque eles fornecem CAN / PHY-MAC .

A comunicação não ocorrerá mais de uma vez a cada poucos minutos para a maioria dos dispositivos e sob demanda para outros. A velocidade não é muito crítica (a mensagem é curta): 1 Mbit / s acho que é um exagero para os meus propósitos.

Os MCUs que planejo usar são os seguintes.

• Atmel AVR Tiny / Mega
• TI MSP430
• ARM Cortex M3 / M4
• (Possivelmente Atmel AVR UC3 - 32 bits)

Eu gostaria de evitar os PICs, se possível (escolha pessoal), simplesmente porque há menos possibilidades de programá-los (todos os itens acima têm mais ou menos ferramentas de código aberto, além de algumas ferramentas oficiais).

Sei que alguns ARMs oferecem funcionalidade CAN e não tenho tanta certeza sobre os outros.

No momento, eu vim com essas possibilidades:

1. GPIO simples para enviar dados (digamos> 16 bits em ALTO para indicar o início da mensagem,> 16 bits em BAIXO para indicar o fim da mensagem). No entanto, ele deve estar em uma frequência padrão << (frequency_client, frequency_server) para poder detectar todos os bits. Precisa apenas de um cabo por MCU do cliente.
2. RS-232 : Acho que esse é de longe o protocolo de comunicação mais usado, mas não sei o quão bem ele é escalável. Estou considerando até 64 MCUs clientes agora (provavelmente mais tarde)
3. USB: o AFAIK é mais parecido com o RS-232, mas não acho que seja muito bom nesse caso (embora o USB suporte muitos dispositivos - 255 se bem me lembro - pode ser muito complicado para este aplicativo)
4. RJ45 / Ethernet: é isso que eu realmente adoraria usar, porque permite a transmissão por longas distâncias sem problemas (pelo menos com cabo blindado> Cat 6 ). O problema é o custo (PHY, MAC, transformador, ...). Eu não sei se você pode realmente soldá-lo bem em casa. Dessa forma, eu não precisaria de um MCU cliente
5. Wireless / ZigBee : os módulos são muito caros, embora possa ser o caminho a seguir para evitar "espaguete" atrás da mesa
6. Módulos / transceptores de RF: estou falando daqueles na faixa de 300 MHz - 1 GHz, portanto deve ser difícil soldar em casa. Os módulos são todos integrados, mas são tão caros quanto o ZigBee (pelo menos os módulos de RF na Mouser, na Sparkfun parecem haver módulos mais baratos).
7. PODE? Parece ser muito robusto. Mesmo que eu não pretenda usá-lo em aplicações automotivas, ainda pode ser uma boa alternativa.
8. I²C / SPI / UART ? Mais uma vez - melhor evitar "espaguete" com os cabos, se possível
9. PLCs não são realmente uma opção. O desempenho diminui muito rapidamente à medida que o comprimento aumenta e depende da carga de capacitância da rede elétrica. Eu acho que em termos de preço é o mesmo que Ethernet.

Além disso, qual protocolo seria "melhor" no caso de transmissões simultâneas (vamos assumir o raro caso de que no mesmo instante dois dispositivos comecem a transmitir: qual protocolo fornece o melhor "sistema de gerenciamento de conflitos" / "sistema de gerenciamento de colisões"?

Resumindo : eu gostaria de saber qual pode ser a melhor solução para um sistema cliente distribuído que faça comunicação de dados muito leve, considerando a flexibilidade (número máximo de dispositivos, sistema de gerenciamento de conflitos / colisões, ...), preço , fácil de fazer em casa (solda), ... eu gostaria de evitar gastar US $ 20 apenas no módulo de comunicação, mas ao mesmo tempo ter 30 fios atrás da mesa seria uma porcaria.

A solução que estou imaginando agora seria fazer uma comunicação básica entre MCUs próximas por GPIO ou RS-232 ( barato !) E usar Ethernet / ZigBee / Wi-Fi em um MCU por "zona" para se comunicar com o servidor ( caro , mas ainda é muito mais barato que um módulo Ethernet por cada MCU cliente).

Em vez de cabos, também pode ser possível usar fibras ópticas / fibras ópticas. Embora sejam necessárias conversões adicionais, não tenho certeza se seria a melhor solução nesse caso. Eu gostaria de ouvir detalhes adicionais sobre eles.

CAN parece o mais aplicável neste caso. As distâncias dentro de uma casa podem ser tratadas pelo CAN a 500 kbits / s, o que soa como largura de banda suficiente para suas necessidades. O último nó pode ser uma interface USB para CAN pronta para uso. Isso permite que o software no computador envie mensagens CAN e veja todas as mensagens no barramento. O resto é software, se você quiser apresentar isso ao mundo exterior como um servidor TCP ou algo assim.

CAN é o único meio de comunicação que você mencionou que, na verdade, é um barramento, exceto para o uso de linhas de E / S. Todos os outros são ponto a ponto, incluindo ethernet. A Ethernet pode ser feita para parecer logicamente como um barramento com comutadores, mas as conexões individuais ainda são ponto a ponto e a obtenção da topologia de barramento lógico será cara. A sobrecarga do firmware em cada processador também é consideravelmente maior que a CAN.

A parte legal do CAN é que as poucas camadas de protocolo mais baixas são tratadas no hardware. Por exemplo, vários nós podem tentar transmitir ao mesmo tempo, mas o hardware cuida de detectar e lidar com colisões. O hardware se encarrega de enviar e receber pacotes inteiros, incluindo geração e validação de soma de verificação CRC.

Suas razões para evitar PICs não fazem sentido. Existem muitos projetos para programadores por aí para criar o seu próprio. Um é o meu LProg , com o esquema disponível na parte inferior dessa página. No entanto, construir o seu próprio não será rentável, a menos que você valorize seu tempo em centavos / hora. Também é mais do que apenas o programador. Você precisará de algo que ajude na depuração. O Microchip PicKit 2 ou 3 são programadores e depuradores de custo muito baixo. Embora eu não tenha nenhuma experiência pessoal com eles, ouço falar de outras pessoas que os usam rotineiramente.

Adicionado:

Vejo algumas recomendações para o RS-485, mas essa não é uma boa ideia em comparação com o CAN. O RS-485 é um padrão somente elétrico. É um barramento diferencial, por isso permite vários nós e possui boa imunidade a ruídos. No entanto, a CAN também tem tudo isso, além de muito mais. O CAN também é geralmente implementado como um barramento diferencial. Alguns argumentam que o RS-485 é simples de interface elétrica. Isso é verdade, mas o CAN também. De qualquer maneira, um único chip faz isso. No caso do CAN, o MCP2551 é um bom exemplo.

Portanto, o CAN e o RS-485 têm praticamente as mesmas vantagens eletricamente. A grande vantagem do CAN está acima dessa camada. Com o RS-485, não há nada acima dessa camada. Você está por sua conta. É possível projetar um protocolo que lide com arbitragem de barramento, verificação de pacotes, tempos limites, novas tentativas, etc., mas realmente fazer isso é muito mais complicado do que a maioria das pessoas imagina.

O protocolo CAN define pacotes, somas de verificação, manipulação de colisões, tentativas, etc. Não apenas ele já está lá, foi pensado e testado, mas a grande vantagem é que ele é implementado diretamente em silício em muitos microcontroladores. O firmware faz interface com o periférico CAN no nível de envio e recebimento de pacotes. Para enviar, o hardware faz a detecção de colisão, retirada, nova tentativa e geração de soma de verificação CRC. Para receber, realiza a detecção de pacotes, o ajuste da inclinação do relógio e a validação da soma de verificação CRC. Sim, o periférico CAN precisará de mais firmware para dirigir do que um UART, como costuma ser usado com o RS-485, mas é necessário muito menos código no geral, pois o silicone lida com muitos detalhes do protocolo de baixo nível.

Em suma, o RS-485 é de uma época passada e faz pouco sentido para os novos sistemas atualmente. A questão principal parece ser as pessoas que usaram o RS-485 no passado se agarrando a ele e achando que a CAN é "complicada" de alguma forma. Os baixos níveis de CAN são complicados, mas também qualquer implementação competente do RS-485. Observe que vários protocolos conhecidos baseados no RS-485 foram substituídos por versões mais recentes baseadas no CAN. NMEA2000 é um exemplo de um padrão mais recente baseado em CAN. Há outro padrão automotivo J-J1708 (baseado no RS-485) que está praticamente obsoleto agora com o OBD-II e o J-1939 baseados em CAN.

Eu recomendaria o controlador com CAN, pois esse recurso foi feito exatamente para o propósito de rede do controlador.

O RS232 pode ser implementado facilmente, mas se tornará um verdadeiro desafio se você tentar implementar a comunicação em mais de 2 nós (porque não é construído para esse fim).

A Ethernet também pode ser uma opção interessante, pois você mencionou algumas interconexões de host e clientes, o que é natural para a implementação da Ethernet.

O RS-485 usando vários fios pode funcionar bem aqui, se houver a possibilidade de conectar a mesma linha a todos os dispositivos.

Se, por exemplo, for usado com um cabo de rede tradicional da categoria 5e, você poderá ter dois pares para trabalhar na transmissão de dados em ambas as direções (usando um módulo full duplex), um par ou até um único fio como ponto comum e o restante para negociar qual dispositivo vai transmitir em que momento. É um pouco mais complicado que o RS-232, mas os módulos são mais baratos que CAN e Ethernet e o limite de cabos é de 1200 m. A desvantagem é que você precisará criar seu próprio protocolo de resolução de conflitos. Talvez o dispositivo que deseja transmitir verifique um fio dedicado e veja se está alto. Se não estiver, leve-o para o alto e comece a se comunicar; se estiver, aguarde um período aleatório. Ainda não tenho certeza de como isso funcionaria em longas distâncias.

Eu escolheria um barramento RS-485 trabalhando com dados da Manchester Encoding .

RS-485 porque:

• É barato
• É fácil de implementar
• É usa lo poder
• Permite longas distâncias (até 1200 metros)
• Altas taxas de dados (até 10 Mbps)
• Alta imunidade a interferências
• Existem transceptores que permitem até 256 dispositivos no mesmo barramento
• Contagem baixa de peças

Codificação Manchester porque:

• É fácil de implementar
• É auto-sincronizável

Para integridade dos dados, a mensagem pode incluir um comprimento e um campo CRC.

Exemplo de uma função CRC:

unsigned char crc_calc(unsigned char buffer[], unsigned short size)
{
  unsigned long i;
  unsigned char crc;

  crc = CRC_INIT;

  for (i=0;i<size * 8;i++)
  {
    crc = (crc << 1) | (crc >> (7));

    if (buffer[i/8] & (0x80 >> (i%8)))
    {
      crc ^= CRC_POLY;
    }
  }

  return crc;
}

CRC_INITe CRC_POLYsão valores arbitrários usados ​​para calcular o CRC.

Exemplo de uma mensagem com campos CRC e comprimento:

Deixe-me comparar sua escolha preferida, Ethernet, com minha escolha preferida, CAN.

Componentes necessários:

• Ethernet: conector RJ45, magnetismo, chip Phy (a menos que esteja integrado ao MCU). Também precisa de switches e um cabo do switch para cada nó. Cada PCB precisa de alguns capacitores e resistores terminais, possivelmente ferrites também. Precisa de um bom design de PCB.
• CAN: Chip do transceptor (barato), qualquer conector e cabo barato pode saltar de um nó para o próximo em um loop pelo site. Precisa de apenas um capacitor para o transceptor e um resistor de terminação em cada extremidade do barramento.

Você está falando de microcontroladores de US $ 1. O custo do ônibus é muito maior do que o MCU. Você precisará somar o custo total de cada solução para saber qual é realmente mais barato. Some o custo do MCU, conectores, transceptores, componentes passivos, PCB, cabos, etc.

O LPC11C24 da NXP também possui o transceptor CAN integrado e o CANOpen suportado na ROM (não corroendo o Flash de dados de 32 K). A placa LPCXpresso 11c24 custa 20 EUR (forneceu espaço para o conector DB9), então você realmente adiciona fios :-)

Repost de outra pergunta semelhante. Comunicação simples de baixo custo entre dois microcontroladores

TLDR : ajuste não particularmente barato, mas confiável em alguns casos de uso.

Olhando para fora da caixa, pode haver outras soluções aqui, como o seguinte chip no qual eu encontrei recentemente. Claro, tudo depende do que você deseja fazer. Algo como o UART vem à mente se você tiver os dois MCUs na mesma placa ou mesmo planejando protegê-los contra ESD manualmente se separados.

Solução principal e de dispositivo para aplicativos IO-Link

L6360   Master
L6362A  Device

Quando você consideraria uma solução como esta:

1. Os chips de fronteira são totalmente protegidos, o que seria importante se você tivesse cada MCU em uma placa separada e lidando com pinos expostos, por exemplo, terminal de parafuso.
   • Polaridade reversa
   • Sobrecarga com função de corte
   • Acima da temperatura
   • Subtensão e sobretensão
   • Fio aberto GND e VCC
2. Interoperabilidade. Se alguém quiser projetar o outro lado, tudo o que precisa saber é canalizar os dados através do IO-Link.
3. Regulador integrado Vcc(in) 7~30v, Vdd(out) 3.3/5v

Pareceu-me interessante, então pensei em publicá-lo.

Depende da escala da sua aplicação e dos seus microcontroladores. Você mencionou o Atmel tiny / mega, eles são bem pequenos. No caso deles, o I2C / SPI / UART tem a vantagem de serem implementados em hardware e, portanto, fáceis de usar.