Comunicação entre vários microcontroladores

20

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.

user51166
fonte
2
Existem PICs com funcionalidade CAN e ferramentas oficiais gratuitas para programá-las com documentação.
AndrejaKo
O @AndrejaKo PIC realmente não possui um compilador de código aberto como AVRs ou pelo menos MSP430s. É verdade que eles geralmente oferecem mais recursos do que os MCUs listados acima pelo mesmo preço. Eu realmente não gosto dessas grandes diferenças entre as famílias 16/12/18/24/32 e algumas delas não têm um compilador gratuito (acho que é o PIC18).
user51166
2
Na verdade, o PIC18 possui um compilador gratuito e outros também. O principal bônus de outras famílias é que elas trabalham com o GCC. No campo de código aberto, há o compilador Small device C, que deve suportar dispositivos PIC 16 e PIC 18.
AndrejaKo
2
Se você ainda não conhece nenhum dos uCs mencionados, lembre-se de que o ARM é muito mais difícil de começar do que, por exemplo, PICs ou AVR, especialmente se você deseja usar o código aberto. Com o ARM, os fornecedores não projetam o núcleo e também geralmente não fornecem um IDE, o que pode tornar a coisa toda um pouco mais complexa. É bom que, por exemplo, a Microchip forneça e suporte tudo no caso de PICs.
precisa
@OliGlaser Bem ... embora seja verdade que as ferramentas de código aberto para ARM podem ser um pouco difíceis de usar (tentei uma placa STM32 Discovery e ela não funcionou muito bem), muitos fornecedores oferecem um IDE que é - com seus prós e contras - baseados no eclipse e com limite limitado: LPCXpresso (NXP) e Code Composer Studio (TI) por exemplo (não de código aberto, mas são suportados pelo menos). Por outro lado, os AVRs são muito bons no lado de código aberto, assim como no ATMEL STUDIO 6. Nenhuma experiência com o PIC. Codificado apenas AVR (assembler) e ARM (C, no NDS).
user51166

Respostas:

22

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.

Olin Lathrop
fonte
criar minha própria placa personalizada é útil ao integrar o MCU ao hardware que ele possui. Para fins de desenvolvimento, concordo que um kit de desenvolvimento é a melhor maneira. Meu motivo para evitar PICs é a falta de compiladores de código aberto (existem alguns gratuitos, mas não o PIC18, por exemplo), e não a falta de esquemas públicos disponíveis, embora eles ofereçam alguns recursos adicionais que você pode não encontrar em outros MCUs (Ethernet, PODE, ...). E I2C é um ônibus AFAIK.
user51166
@ user51166 - Existem compiladores PIC18 gratuitos fornecidos pelo microchip. Consulte a página do produto MPLAB XC Compilers . Ele também lista os compiladores para os 16 bits e 32 bits uC.
PetPaulsen
@ user51166 Também existe o compilador C18 gratuito .
AndrejaKo
@PetPaulsen Strange. Tenho certeza de que vi um mês atrás uma página que listava todos os compiladores disponíveis gratuitamente para download (PIC16 / 24/32), com exceção do PIC18, que não era por causa de algum problema de licenciamento. Provavelmente isso foi resolvido com a transição MPLAB C Compiler -> MPLAB XC Compiler, embora eu não tenha certeza. Além disso, eles "apenas" oferecem uma edição de freeware que não otimiza seu código, não um compilador de código aberto. Ainda assim, é melhor do que nada;) #
49568
@ Usuário: Eu acredito que todos os compiladores Microchip têm versões gratuitas que diferem apenas das versões completas, pois algumas das otimizações estão desativadas. O montador, bibliotecário, vinculador e simulador estão todos incluídos no pacote MPLAB gratuito. Realmente não há problema aqui.
precisa
6

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.

JeeShen Lee
fonte
Quais são as vantagens do CAN sobre Ethernet, por exemplo? Mais barato, provavelmente, mas fora isso, o que mais?
user51166
@ user51166 - CAN não é apenas mais barato, mas muito mais barato. Não é apenas mais fácil, mas muito mais fácil.
Rocketmagnet
@Rocketmagnet: por favor, explique um pouco mais. Na maioria dos casos, você precisa de um IC integrado de qualquer maneira (embora PICs, ARMs e outros? Frequentemente integrem o recurso CAN, eles são um pouco caros). Do ponto de vista do hardware, não vejo como isso pode ser muito mais barato, pois os CIs podem ser encontrados por 0,5-1,0 $ por peça. Suponho que você queira dizer mais fácil do ponto de vista do software, certo? A CAN tem uma distância máxima de ~ 500 metros, o que certamente é suficiente no meu caso, mas - apenas para informação - haveria alternativas semelhantes para distâncias mais longas (talvez fibra óptica)?
user51166
4

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.

AndrejaKo
fonte
Para não me preocupar com distâncias muito longas, não pretendo ultrapassar 100m no momento.
user51166
Por que hoje a BTW stackexchange não aceita @ <nome de usuário>? Cada vez que eu coloquei um, ele fica completamente eliminada (e não apenas o símbolo @) ...
user51166
@ user51166 - O criador da resposta é notificado automaticamente, então o "\ @ - noise" é removido automaticamente. (My \ @ user51166 não foi removido, porque você não é o criador desta resposta)
PetPaulsen
O interessante é que não recebi notificações para nenhum dos comentários aqui.
AndrejaKo
4

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:

Exemplo de mensagem

Bruno Ferreira
fonte
Alguma sugestão para bons transceptores, possivelmente baratos?
user51166
Além disso, como a @AndrejaKo sugeriu, o RS-485 parece não oferecer protocolo de resolução de conflitos.
user51166
A escolha dos transceptores depende da tensão que você pretende usar. A resolução de conflitos deve ser feita em software com verificação CRC, monitoramento de linha ou ambos.
Bruno Ferreira
Se você tiver um mestre, também poderá implementar algum tipo de endereçamento ou transmissão por turnos.
Bruno Ferreira
Não é realmente um mestre. Apenas o "servidor", que funciona como uma interface para o PC via USB. Os clientes têm de enviar mensagens para ele automaticamente no entanto ...
user51166
3

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.

Rocketmagnet
fonte
0

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 :-)

Drazen Cika
fonte
0

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

insira a descrição da imagem aqui

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.

Mehrad
fonte
-3

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.

vsz
fonte
3
OK, mas como isso resolve o problema do OP? A CII é um ônibus, mas realmente não é adequada para longas distâncias, como em uma casa. É de extremidade única e impedância relativamente alta. O SPI é um barramento, mas controlado por um único mestre com uma linha de seleção de escravos separada para cada dispositivo. Você pode implementar cada linha como um par diferencial com drivers e receptor de linha, mas ainda tem o ponto a ponto principal para emitir o problema de seleção de escravos. O UART é estritamente ponto a ponto. Não está claro como você pretende usá-los na situação do OP.
Olin Lathrop