Protocolo geral para transferência de dados de um sistema para outro?

18

Qual é o protocolo geral para enviar informações de um sistema para outro? Por exemplo, digamos que temos algumas informações coletadas do microcontrolador por um período de tempo que queremos enviar para outro microcontrolador. Ouvi falar de interfaces SPI e I2C, mas não estou claro quando você usa um método sobre outro e como implementá-lo. Existem outros métodos além do SPI e I2C que são comuns? O processo de implementação é semelhante para diferentes microcontroladores? É basicamente analisando bytes de dados que estou fazendo no microcontrolador receptor?

i2c spi data

— O_O
fonte

4

Qual é a coisa concreta que você quer fazer?

— starblue

Pensando em como fazer com que diferentes partes de um sistema passem dados entre si em uma caixa pequena, é possível supor que a distância seja muito curta. A razão para ter diferentes peças numa caixa é simplificar as funções de modo que cada peça tem a sua própria função (espero que faz sentido ..)

— O_O

2

não é isso que as pessoas normalmente chamam de sistema. Esses são mais o que eu definiria como subsistemas. Eles fazem parte do que você poderia considerar como um único sistema realizando um único conjunto de tarefas. É semântica, mas acho que muitas de suas respostas são muito amplas, porque elas não têm uma idéia perfeita do que você está procurando na pergunta.

— Kortuk

11

seguindo as linhas do que Kortuk disse, ajuda a definir o problema. Uma pergunta importante a ser feita é se você pretende substituir subsistemas individuais por implementações diferentes da mesma função ou se esse é um projeto único. Se você usar um barramento real e expor os detalhes de implementação dos subsistemas ao seu processador, uma alteração no subsistema exigirá uma mudança de / w para o seu controlador, enquanto que se você usar uma interface de comunicação, não importa como você implementa um (substituto). ), desde que atenda ao mesmo protocolo de mensagens.

— JustJeff

Não é mais simples dividir a funcionalidade em vários dispositivos por nenhum outro motivo, a não ser separar tarefas. As comunicações e a sincronização são mais complexas do que ter dois processos no mesmo micro. Agora, se esses processos tiverem perfis de latência particularmente incompatíveis (um deve ser atualizado rapidamente enquanto o outro pode levar algum tempo para concluir uma parte), PODE haver um motivo válido para dividi-los. Mesmo assim, a solução mais comum é usar interrupções ou encontrar uma maneira de dividir ainda mais a tarefa mais longa. Com o que você descreveu, estou inclinado a pensar que deveria repensar isso.

— darron

10

O SPI e o I2C são semelhantes, pois são realmente mais usados para conectar dispositivos periféricos a um controlador ou CPU, do que para transferir dados entre sistemas. USB é outra interface que as pessoas parecem querer tratar como um sistema de comunicação, que na verdade é um barramento de conexão periférica.

A comunicação entre sistemas não é exatamente como conectar um dispositivo a um barramento. A conexão de barramento permite que o processador bata diretamente nos registros de um dispositivo, enquanto uma interface de comunicação permite enviar / receber fluxos de dados. Um dispositivo conectado a um barramento geralmente precisa de um driver de dispositivo, enquanto que nas comunicações realmente não importa o que está conectado na outra extremidade, no que diz respeito ao computador host.

Obviamente, isso está se tornando um limite mais perigoso o tempo todo. Coisas como PCI e ISA são ônibus indisputavelmente; I2C, SPI, USB são sem dúvida barramentos; enquanto RS232, RS485 e ethernet são definitivamente interfaces de comunicação. Mas existem coisas como o barramento CAN e o 1553, que são definitivamente sobre a movimentação de dados, mas de uma maneira muito envolvente.

— JustJeff
fonte

O CANbus está muito envolvido e a Ethernet não está? O CAN é muito simples para começar a trabalhar com mensagens simples para frente e para trás. Eles são chips dedicados e a maioria das famílias suporta internamente seus microcontroladores.

— Kortuk

@ Kortuk - na medida em que algo como 232 tem uma espécie de simetria ponto a ponto, enquanto 1553 ou CAN pode impor uma relação mestre / escravo, sim. Não acredito que tenha dito que a Ethernet é simples, mas que não impõe uma distinção entre controlador / dispositivo de barramento nos pontos finais.

— 9118 JustJeff

Além disso, divulgação completa - minha opinião sobre a CAN é inteiramente de exposição tangencial; foi um periférico opcional não utilizado em vários sistemas em que trabalhei, mas após centenas de passagens pela documentação, você absorve um pouco das opções não utilizadas apenas por osmose. Então, estou trabalhando com a suposição de que CAN é um tipo de arquitetura de controlador / dispositivo controlado.

— JustJeff

Eu acho que ônibus tem significados diferentes em contextos diferentes. Do nível esquemático, qualquer interface com múltiplos sinais pode ser considerada um barramento. À medida que você avança para níveis mais altos com mais abstração, o barramento muda de significado. Um pouco mais alto, o barramento geralmente significa que há ou pode haver vários dispositivos envolvidos. O multiponto RS485 é definitivamente um barramento, por exemplo. Muito mais acima, do ponto de vista de um dispositivo Linux, o RS485 se torna uma interface de comunicação novamente e é rebaixado de um barramento ... até você adicionar sua própria camada de protocolo em cima dela, transformando-a novamente em um barramento. Em cada nível é tem significados diferentes.

— darron

11

Não há uma maneira de enviar dados, há muitas maneiras diferentes de se comunicar, dependendo da distância, taxa de dados, ambiente, aplicativo ...

A camada mais baixa é a camada física , que realmente move os bits.

SPI e I²C são para pequenas distâncias dentro de um dispositivo, onde não há muito ruído que possa atrapalhar a transmissão.
Para uma comunicação não muito rápida em distâncias de até algumas dezenas de metros, a comunicação serial via RS-232 é uma boa opção.
Se houver mais ruído ou sinais diferenciais de distância maior forem usados, por exemplo, no RS-485. Para uma transmissão de dados mais rápida, há a Ethernet, que está se tornando cada vez mais popular.
Depois, há também vários padrões sem fio.

No topo da camada física, há mais camadas organizando como os dados são enviados, para detectar e corrigir erros na transmissão, roteamento em uma rede e muitas outras coisas. Por exemplo, o protocolo da Internet é uma pilha bastante complexa de várias camadas, geralmente em cima do protocolo Ethernet.

— starblue
fonte

7

Um UART serial simples pode ser usado (uma linha Tx e uma linha Rx sem relógio discreto) e pode ser facilmente adaptado para cruzar entre diferentes potenciais (mesmo circuitos primários e secundários) com optoisoladores ou isoladores magnéticos .

No que diz respeito aos protocolos, qualquer coisa com bytes de comando definidos e algum tipo de esquema de soma de verificação funcionará bem. Realmente não existe um protocolo padrão abrangente que se adapte a todos os tipos de comunicação. O I2C possui padrões de sinalização (definição de endereçamento, paradas, partidas etc.), mas o protocolo do que está sendo realmente comunicado depende apenas do desenvolvedor.

O PMBus , por exemplo, é um protocolo de comunicação da fonte de alimentação que usa o I2C como meio físico.

— Adam Lawrence
fonte

6

Realmente não existe um protocolo "geral", o que você acaba usando depende muito do aplicativo. Para que possamos lhe dar uma resposta melhor, precisamos entender um pouco melhor suas necessidades. Você mencionou que gostaria de ter microcontroladores separados conversando entre si como subsistemas.

Algumas perguntas sobre este aplicativo:

Haverá mais de 2 microcontroladores neste projeto?
Quais são os seus requisitos de velocidade e taxa de transferência? Com que rapidez as informações precisam chegar lá e com que frequência você está enviando / recebendo dados?

Se você respondeu NÃO à pergunta 1:

Se houver apenas 2 microcontroladores neste projeto, você pode definitivamente usar o UART entre eles. Se os dois precisarem iniciar a comunicação, use o controle de fluxo; caso contrário, será trivial enviar dados em uma direção. Na maior parte, deve ser "rápido o suficiente", pois você seleciona uma das taxas de transmissão mais altas. I2C e SPI normalmente são bons apenas para arquitetura mestre / escravo.

Se você respondeu SIM (mais de 2 controladores) à pergunta 1:

Se houver mais de 2 microcontroladores em seu projeto, qual deles inicia a comunicação? Será apenas um controlador mestre (ou seja, arquitetura mestre-escravo)? Ou algum dos subsistemas seria capaz de falar a qualquer momento?
Existe a necessidade de algum dos subsistemas se comunicar? por exemplo: para dispositivos A, B e C: A pode enviar para B e C, e B pode enviar para A e C, etc.

Portanto, agora você precisa de algo mais escalável, onde possa colocar dispositivos endereçáveis em um barramento comum. A resposta para essas perguntas de acompanhamento o ajudará a decidir entre I2C e SPI (mestre-escravo) ou algo como CAN (multi-mestre).

Seu microcontrolador provavelmente possui um periférico UART, os outros (especialmente o CAN) podem estar disponíveis apenas em chips mais avançados. Em qualquer um dos casos, deve haver muita documentação sobre como usar esses periféricos para mover bytes.

— Jon L
fonte

5

Como observou @Jon, um problema na seleção de uma interface de comunicação é se uma entidade sempre será responsável por iniciar as comunicações ou se mais de uma entidade pode ser responsável. Uma questão relacionada é se uma entidade estará sempre pronta para receber comunicações não solicitadas. O SPI é freqüentemente usado em aplicativos em que um lado estará sempre pronto para receber comunicação. Algo como um registro de turno 74HC595, por exemplo, nunca está "ocupado". Embora o SPI seja bom para a comunicação entre um microcontrolador e o hardware que o micro deve controlar, ele não é realmente bom para a comunicação entre dois microcontroladores. Quando dois processadores com hardware I2C o estão usando para se comunicar, o software pode levar o tempo que quiser (com restrições muito generosas) para lidar com o que está acontecendo, sem causar perda de dados. Se um processador levasse 100 microssegundos para processar cada byte recebido, isso limitaria severamente a taxa de transferência, mas o remetente diminuiria a velocidade o suficiente para o receptor acompanhar. A única maneira que geralmente pode acontecer com o SPI é se houver um fio separado para o aperto de mão.

O I2C é realmente um protocolo maravilhoso. As maiores limitações que o impedem de ser o protocolo mais perfeito que se possa imaginar são:

Sua velocidade é um pouco limitada; O SPI pode ir muito mais rápido, e até os UARTs às vezes podem ser um pouco mais rápidos
(2) Embora seja muito conveniente que o I2C precise apenas de dois fios, ambos devem ser capazes de comunicação bidirecional de coletor aberto. Isso dificulta o envio de I2C via repetidores.

Pessoalmente, gostaria que os fornecedores de controladores suportassem uma variante de SPI de três fios, que incluía handshake. No entanto, não conheço nenhum controlador que faça isso.

— supercat
fonte

Engraçado que você deve mencionar isso ... Estou tendo que transformar uma interface SPI em uma interface I2C não bidirecional (o primeiro byte é um endereço) para permitir que muito mais dispositivos participem no barramento do que o que o chip seleciona. . Funciona se os seus dispositivos escravos forem todos FPGAs. :) Eu também desejei que houvesse algo entre esses dois principais padrões síncronos.

— darron

Ah, acho que devo esclarecer que a saída permitida aos escravos não é declarada até que seja recebido o byte de endereço e eles permanecem ativos até que a seleção de um único chip seja desativada ... então é obviamente um pouco diferente do SPI + alto nível normal protocolo. No entanto, é totalmente compatível com o SPI padrão do ponto de vista do dispositivo mestre. (como um microprocessador)

— darron

@ Darron: Legal. Eu me pergunto o que teria que acontecer para a indústria começar a usar um barramento de comunicações de três fios de padrão aberto, onde os fios são ativamente acionados alto e baixo? Eu acho que há um pequeno conflito entre evitar flexões passivas e permitir que qualquer dispositivo sinalize uma interrupção, embora isso possa ser remediado adicionando um pino de interrupção que poderia ser conectado ao mestre ou não para a conveniência dos escravos (minha atual implementação de o protocolo possui apenas um escravo, para que possa usar o fio de retorno de dados para sinalizar de forma assíncrona quando quiser receber manutenção).

— Supercat

@ Darron: Para evitar o uso de um pino de seleção de chip, o mestre sinaliza o início do comando enviando duas arestas ascendentes no fio de dados enquanto o relógio está baixo; os escravos podem indicar se seu último byte de dados foi válido emitindo um valor de status quando o relógio e os dados estiverem baixos (inativos); caso contrário, eles indicam que querem atenção quando o relógio está baixo e os dados estão altos. Se eu estivesse projetando hardware mestre para esse protocolo, acrescentaria a capacidade de enviar 8 pulsos de relógio onde o fio de dados espelhava o relógio, e no hardware escravo incluem uma contagem assíncrona do número de arestas crescentes durante ...

— supercat

@arron: ... um byte de dados. Se cinco ou mais, o byte seria ignorado (o escravo assumiria que o mestre estava interessado em receber um byte de dados, mas não tinha nada que realmente quisesse dizer). Porém, isso não seria tão significativo quanto ter o escravo relatando o status de último byte quando o relógio estivesse baixo (o que, se o dispositivo escravo fosse um processador, permitiria ao mestre saber que o escravo não estava pronto e tinha perdido a última 'oportunidade de transação'.

— supercat

3

Em nenhuma ordem específica, as instâncias da camada física mais populares para 2 CPUs na mesma caixa parecem ser:

SPI de ligação em cadeia (como usado pelo JTAG)
SPI de seleção por fio por escravo
"RS-232 de nível TTL", também conhecido como "comunicação serial assíncrona de start-stop" (conectando diretamente o pino UART TX de uma CPU ao pino UART RX de outra CPU)
I2C
Dados de 8 bits + strobe (como a porta paralela da porta da impressora IEEE 1284)
memória compartilhada (apenas uma CPU dirige o endereço / dados / barramento de controle por vez)

Essas instâncias da camada física (assim como outras instâncias da camada física para 2 CPUs em caixas separadas) geralmente fornecem um fluxo de bytes ao software que implementa os níveis mais altos do sistema de comunicação.

Programadores inteligentes escrevem o software de tal maneira que, quando o técnico decide separar uma instância da camada física e substituí-la por uma instância da camada física completamente diferente, eles precisam apenas reescrever algumas funções para alimentar o fluxo de bytes de saída para o hardware e leia de volta um fluxo de bytes do hardware, e todo o protocolo de nível superior continua funcionando inalterado.

O protocolo para enviar informações de uma CPU para outra CPU quase sempre envolve a interpretação do fluxo de bytes como uma série de pacotes:

preâmbulo
cabeçalho
dados serializados (possivelmente escapados)
reboque

Algumas pessoas parecem gostar de criar protocolos totalmente novos, personalizados e incompatíveis misturando e combinando (2) um dos muitos tipos de estrutura de cabeçalho com (3a) um de muitos tipos de serialização de dados com (3b) um dos muitos tipos de escapando desses dados serializados com (4) um dos muitos tipos de trailer.

Alguns dos protocolos mais simples para encapsular dados em um pacote incluem:

Protocolos ligeiramente mais complicados para encapsular dados em um pacote incluem:

Há uma longa lista de protocolos em

Você pode ler "Folclore de Design de Protocolo", de Radia Perlman, que descreve como o design de protocolo pode dar errado.

— davidcary
fonte

3

Nenhum protocolo 'geral' único. A escolha pode (por exemplo) depender de:

distância
taxa de transferência necessária
disponibilidade de periféricos especiais
nível de ruído
necessidade de isolamento óptico
criticidade (taxa de falha tolerável)
CPU avialable em ambas as extremidades
pinos de E / S disponíveis nas duas extremidades

Em muitos casos, você deve desitar a camada física (níveis de sinal) da camada de enlace de dados (+/- a maneira como os dados são codificados) (verifique o modelo OSI, abaixe 2 ..4 camadas). Possíveis camadas phyiscal são, por exemplo:

simples 5V ou 3.3V ou mesmo 1.8V TTL
qualquer um dos itens acima, mas coletor aberto, em vez de push-pull
sinalização de tensão lov balanceada (freqüentemente usada com FPGAs)
volge equilibrado do higer (RS485, RS432)
tensão mais alta de extremidade simples (RS232)
acoplado a trafo balanceado (várias versões Ethernet, áudio PDIF)
óptico (ethernet óptico, toslink)

Você pode usar uma linha para transportar dados e informações do relógio ou dividi-las em várias linhas. Este último costumava ser popular, mas hoje em dia a maioria dos protocolos novos / rápidos tendem a usar uma linha (ou um par de linhas atuando como uma).

Existem várias maneiras de codificar dados e relógio em uma linha. Tradicionalmente, o RS232 usa NRZ, existe a codificação Machester e os vários formatos usados em discos rígidos com nomes curiosos na linha 2.7 RLL.

Resumindo: há um milhão de maneiras de se comunicar entre sistemas. E eu nem mencionei conectores ou aspectos de nível superior, como detecção e recuperação de erros, codificação de dados, compactação e criptografia ...

— Wouter van Ooijen
fonte