Neste post vamos explorar vários protocolos de comunicação que são usados por microcontroladores, microprocessadores e ICs para comunicação com diversos sensores, drivers eletrônicos, dispositivos de entrada e saída.
Veremos:
- Por que existem protocolos de comunicação em eletrônica?
- Protocolo UART.
- Protocolo I2C ou IIC ou “Eu quadrado C”.
- Protocolo SPI ou Interface Periférica Serial.
- CAN – Protocolo de rede de área de controlador.
Por que existem protocolos de comunicação em eletrônica?
Na eletrônica, vários protocolos de comunicação são desenvolvidos e padronizados para que sensores, drivers e vários dispositivos de entrada e saída possam se comunicar perfeitamente entre si.
Se não houver protocolos de comunicação padronizados, diferentes fabricantes podem fabricar sensores, drivers, periféricos etc. à sua maneira e dificilmente serão compatíveis com as especificações de outros fabricantes e desenvolver um produto e depurar / corrigi-los em tal cenário será uma tarefa tediosa.
Cada protocolo mencionado em eletrônica é estabelecido para fins e circunstâncias específicas e um desenvolvedor de produtos pode escolher um ou mais de acordo com suas necessidades e especificações.
Neste post estaremos explorando cerca de quatro protocolos de comunicação mainstream que serão encontrados por todos os desenvolvedores e programadores de sistemas incorporados.
Transmissor-receptor assíncrono universal (UART):
UART é um protocolo de comunicação serial que transmite e recebe dados um pouco de tempo de bit menos significativo para bit mais significativo.
Precisamos de dois dispositivos para estabelecer uma comunicação UART e é duplex completo, o que significa que os dados podem ser transmitidos e recebidos simultaneamente.
A comunicação UART requer dois fios (ônibus); Tx – transmita, Rx- receber e um terreno comum para completar o circuito entre os dois dispositivos. O Tx de um dispositivo será conectado ao Rx do outro dispositivo e da mesma forma o Rx de um dispositivo está conectado ao Tx de outro dispositivo.
A velocidade com que os dados são transmitidos ou recebidos é chamada de taxa de baud que é essencialmente bits por segundo. As taxas comuns de baud são 9600, 115200 etc.
Níveis de tensão:
Os dados UART são transmitidos e recebidos em dois níveis diferentes de tensão e existem dois padrões chamados RS-232 e RS-485. A RS-232 opera a 12V e a RS-485 opera a 5V.
Enquadramento de dados para UART:
O quadro de dados ou diagrama de tempo é um aspecto importante de qualquer protocolo de comunicação porque descreve como os bits de dados são transmitidos, recebidos e sincronizados em um barramento de comunicação.
Um desenvolvedor de programas de firmware escreve um código de programa baseado no diagrama de tempo para comunicação adequada entre sensores, microcontroladores e periféricos.
- Durante o estado ocioso, as linhas Tx e Rx são puxadas altas e podemos ver no diagrama de tempo acima.
- Quando a transmissão de dados começa, ela sempre começa com um “bit de partida”, aqui o start-bit é transmitido puxando a linha de transmissão para LOW por algum tempo e depois disso os bits de dados reais são transmitidos.
- D0 a D8 são os bits de dados e esse comprimento de dados pode variar dependendo da exigência. O comprimento mínimo é de 5 bits (D0 a D4) e pode se estender até 9 bits (até D8). De D0 a D8 os bits podem ser altos ou baixos dependendo do que você está enviando e é por isso que o diagrama é mostrado com linhas altas e baixas simultaneamente. Na maioria das aplicações, lSB ou bits menos significativos são transmitidos primeiro.
- Um bit de paridade opcional pode ser transmitido e este bit opcional é verificar a integridade dos dados na extremidade receptora.
- A próxima parte é chamada de “stop bit” e esta parte de parada pode ser de um ou dois bits de comprimento.
- Após a parada, a linha de transmissão é puxada para cima até que o próximo quadro de dados seja transmitido.
O tempo de um pouco é determinado pela taxa de baud e é tempo crítico. Antes de transmitir alguns dados de um dispositivo para outro é obrigatório definir a taxa de baud de ambos os dispositivos o mesmo.
Erros na comunicação UART:
Qualquer comunicação entre dois pontos /dispositivos é propensa a erros / ruídos e uart não é exceção. Aqui está a lista de erros que podem ocorrer em uma transmissão de dados UART e o UART é capaz de detectar tais erros.
- Erro de enquadramento:
O UART gerará erros de enquadramento quando não detectar um bit de parada na posição de bit de parada esperada no quadro de dados.
- Erro de paridade:
O erro de paridade é gerado quando o número de bits “1” no quadro de dados não concorda com o bit de paridade especificado. O erro de paridade só é gerado se a verificação de paridade estiver ativada no código.
- Condição de ruptura:
A condição de quebra ocorre quando o receptor recebe sinal LOW por um período mais longo de tempo, normalmente por mais de um tempo de caractere. Quando ocorrer uma condição de ruptura, também teremos erro de quadro, pois nenhum sinal de parada é recebido.
Alguns equipamentos deliberadamente enviam “quebra” quando as taxas de baud são incompatíveis e podem iniciar um passo significativo para corresponder à taxa de baud novamente como redefinir o dispositivo.
- Erro de sobrecarga:
O erro de sobrecarga é gerado quando outro byte de dados chega antes que os dados anteriores na memória buffer são lidos pelo processador.
- Erro de underrun:
O erro de underrun é gerado no UART quando o buffer de transmissão está vazio ou concluído transmitindo um byte. Na UART isso NÃO é tratado como um erro. Este erro é levado a sério na comunicação USOT.
Isso conclui o protocolo UART.
Protocolo de comunicação I2C:
I2C também é conhecido como circuito interconteligado, é muitas vezes chamado de “I ao quadrado C” em suma. O protocolo I2C foi desenvolvido pela Philips Semiconductors em 1982. O barramento de comunicação I2C é usado principalmente para comunicação entre ICs, sensores e periféricos, etc. a uma curta distância dentro de uma placa de circuito.
É uma comunicação de dois fios que envia e recebe dados em série; as duas linhas de ônibus são SDA – dados de série e SCL – relógio serial.
O modo de comunicação é meio duplex, o que significa comunicação bidirecional, mas apenas um dispositivo pode enviar dados e outro deve receber e o receptor não pode enviar dados para o outro simultaneamente.
No I2C, os dados são sincronizados usando um barramento de relógio, o que garante que os dados são enviados e recebidos corretamente.
O I2C utiliza configuração de coletor aberto/ drenagem aberta, o que significa que o barramento I2C só pode ser puxado PARA BAIXO, mas não pode puxar HIGH, por isso precisamos conectar dois resistores externos em linhas SDA e SCL que variam de 4,7K a 10K, dependendo das especificações.
O barramento I2C pode ter vários dispositivos mestres e vários dispositivos escravos no mesmo ônibus de dois fios.
O limite máximo do número de dispositivos que podem ser conectados ao barramento depende dos modos de endereço (comprimento).
Se o I2C usar um endereço de 7 bits para reconhecer um dispositivo mestre ou escravo, então o máximo de 128 dispositivos pode ser conectado, se ele usar endereço de 10 bits, então 1024 dispositivos podem ser conectados em um mesmo barramento.
Velocidade do ônibus I2C:
- Modo padrão: 100 Kb/s.
- Modo de velocidade total: 400 Kb/s.
- Modo rápido: 1 Mb/s.
- Modo de alta velocidade: 3,2 Mb/s.
Nota: Todos os dados em bits.
Enquadramento de dados do I2C e diagrama de tempo:
- A comunicação começa com uma condição inicial; a condição de início é satisfeita quando a SCL está em ALTA e o SDA muda de ALTO para BAIXO, você pode ver no diagrama de tempo destacado em amarelo (no lado esquerdo).
- O próximo pedaço de dados é o endereço do dispositivo. Cada dispositivo I2C tem um endereço (7 ou 10 bits) para que possamos escrever ou ler dados desse dispositivo I2C em particular.
- Os endereços do dispositivo são transferidos como bits individuais, assim como qualquer outro protocolo, um pouco é permitido mudar de ALTO para BAIXO ou BAIXO para HIGH somente quando o SCL estiver em LOW (destacado em azul). Um pouco é lido pelo receptor quando o SCL está em HIGH – destacado em verde, isso é o mesmo para todos os pedaços de dados. Por favor, note que no I2C os bits de dados são transmitidos de MSB para LSB.
- A próxima parte é chamada de leitura/gravação, o mestre decide se os dados precisam ser escritos ou lidos a partir do dispositivo escravo: 1 é para leitura de escravo, 0 é para escrever dados sobre salve.
- Um bit de reconhecimento é enviado ao dispositivo mestre por um escravo indicando que a comunicação foi bem sucedida e o dispositivo escravo pretendido existe no ônibus I2C.
- O próximo pedaço de dados é 1 byte de dados (8 bits) em qualquer direção (por mestre ou escravo) dependendo da bit R/W.
- Após o byte de dados, um bit de reconhecimento é enviado pelo dispositivo recebido (mestre ou escravo). Para cada byte de dados que sucede em qualquer direção, um bit de reconhecimento é enviado pelo dispositivo receptor.
- Uma vez concluída a transmissão de dados, uma condição de parada é iniciada. A condição de parada é iniciada quando o SCL está em ALTA, o SDA passa de LOW para HIGH. A condição de parada é monitorada por todos os mestres em um ônibus para que eles possam iniciar uma nova comunicação com um dispositivo escravo no mesmo ônibus.
Arbitragem:
Todos os dispositivos principais monitoram o ônibus I2C para condição de parada e nenhum mestre enviará dados para um escravo quando o ônibus estiver ocupado.
Quando os dispositivos mestres detectam condições de parada, vários mestres podem tentar acessar o mesmo barramento, isso cria disputa entre dispositivos mestres.
Para evitar tais disputas nos ônibus I2C, foi estabelecida uma política de arbitragem.
O dispositivo mestre que envia ‘0’ no endereço do dispositivo primeiro no quadro de dados ganha a arbitragem e o resto dos dispositivos principais esperam no barramento I2C.
Alongamento do relógio:
O alongamento do relógio ocorre quando qualquer dispositivo no barramento I2C mantém a linha de sinal de relógio (SCL) para LOW depois de receber um byte e ainda processa os dados e não está pronto para receber a próxima bit. Isso força o dispositivo de remetente a esperar até que o dispositivo receptor complete o processamento dos dados.
O dispositivo receptor pode manter a linha SCL pelo tempo necessário e não há condições de tempo limite especificadas no protocolo I2C.
Isso conclui o protocolo de comunicação I2C.
Protocolo de comunicação SPI:
SPI significa Interface Periférica Serial; foi desenvolvido pela Motorola na anos 1980. É uma comunicação serial síncronenta, o que significa que requer um sinal de relógio para sincronizar dados entre dispositivos mestre e escravo e é full-duplex, o que significa que pode enviar e receber dados simultaneamente.
O protocolo SPI é um protocolo multi-escravo mestre único, o que significa que haverá apenas um dispositivo mestre e pode ter dois ou mais dispositivos escravos. O SPI também é conhecido como um ônibus serial de quatro fios.
Protocolo SPI de interfacção:
Mestre e escravo:
O protocolo SPI precisa de quatro fios para interagir e operar entre o mestre e o dispositivo escravo.
- SCLK – Relógio serial – saída do dispositivo mestre.
- MOSI – Mestre escravo em – saída de dados do dispositivo mestre.
- MISO – Mestre em slave out – entrada de dados do dispositivo salve.
- SS / CS – seleção de escravos / seleção de chip. O seleto escravo é ativo de baixa linha e pode ser qualquer objetivo geral pino de I/O de um microcontrolador.
Transmissão de dados no SPI:
- Para iniciar a comunicação SPI, o mestre começa a gerar um sinal de relógio compatível com o dispositivo escravo, geralmente na faixa de alguns MHz.
- O próximo passo é puxar a linha de seleção de chip do dispositivo escravo para LOW. Se houver vários dispositivos escravos, o dispositivo mestre puxará para baixo uma linha de seleção de chip de escravo em particular.
- Agora o mestre envia dados via MOSI para escravo e o escravo responde ao mestre via MISO. Os dispositivos escravos cujas linhas não são puxadas para baixo devem ignorar os dados e o relógio no ônibus.
- Uma vez que a comunicação seja concluída, a linha do relógio ficará ociosa.
Polaridade do relógio e fase do relógio no SPI:
Sempre que escrevemos um código de programa para comunicação SPI, devemos mencionar a polaridade do relógio e a fase do relógio, só então a comunicação adequada é estabelecida.
- Polaridade do relógio ou CPOL determina qual será o estado de polaridade ociosa da linha do relógio. Quando o CPOL estiver definido como 0, então o estado ocioso da linha do relógio será puxado para baixo. Quando o CPOL estiver definido como 1, o estado ocioso da linha do relógio será puxado para cima.
- A fase do relógio ou CPHASE determina em qual fase do relógio (borda ascendente ou borda caindo) do sinal do relógio, a bit de dados transmitido pode ser alternada (de ALTA para BAIXA ou BAIXA para ALTA) e em qual fase do relógio os dados transmitidos podem ser lidos pelo receptor.
Diagrama de tempo da comunicação SPI:
Existem quatro modos de comunicação SPI:
Consulte o diagrama de tempo acima durante a leitura da explicação abaixo.
- CPOL = 0 & CPHASE = 0:
MODO 0: Quando o CPOL é definido como 0, o estado ocioso do relógio é BAIXO e quando o CPHASE (CPHA) é definido como 0, os dados serão lidos quando o relógio estiver em borda crescente e a broca de dados é permitida a alterar quando o relógio está caindo.
- CPOL = 0 & CPAHSE = 1
MODO 1: Quando o CPOL é definido como 0, o estado do relógio ocioso é BAIXO e quando o CPHASE (CPHA) é definido como 1, os dados serão lidos quando o relógio estiver em queda e a broca de dados é permitida a mudar quando o relógio na borda ascendente.
- CPOL = 1 & CPAHSE = 0
MODO 2: Quando o CPOL é definido como 1, o estado do relógio ocioso é ALTO e quando o CPHASE (CPHA) é definido como 0, os dados serão lidos quando o relógio estiver em queda e a broca de dados é permitida a mudar quando o relógio na borda ascendente.
- CPOL = 1 & CPAHSE = 1
MODO 3: Quando o CPOL é definido como 1, o estado do relógio ocioso é ALTO e quando o CPHASE (CPHA) é definido como 1, os dados serão lidos quando o relógio estiver em borda ascendente e a broca de dados é permitida a alterar quando o relógio estiver em queda.
Isso conclui o protocolo de comunicação SPI.
Protocolo CAN:
CAN significa rede de área controladora, desenvolvida por Robert Bosch em 1983 e lançada em 1986 na Society of Automotive Engineers, Michigan, EUA.
O protocolo CAN foi desenvolvido para veículos automotivos para simplificar a comunicação entre vários sensores, drivers e periféricos etc. CAN é um ônibus multi-mestre e não há dispositivos escravos e todos os nós agem como um mestre.
Ele envia e recebe dados serialmente e o modo de comunicação é meio duplex e assíncrona. Uma vez que a comunicação é assíncroda, a taxa de bits de todos os dispositivos CAN deve ser a mesma em um ônibus.
CAN também é um sistema de transmissão de mensagens, o que significa que o envio de dados sobre o barramento CAN não é direcionado (do dispositivo A ao dispositivo B como I2C ou SPI), em vez disso, os dados transmitidos serão lidos por todos os dispositivos CAN e se os dados enviados forem relevantes para um dispositivo CAN, ele processará os dados mais adiante e outros dispositivos CAN simplesmente desconsiderarão as informações.
Ao contrário do I2C, onde existe um endereço de dispositivo, os dispositivos CAN não têm um endereço de dispositivo, mas têm um identificador.
O identificador transmite a importância da mensagem (prioridade) e também usada para o gerenciamento de arbitragem quando vários dispositivos CAN começam a se comunicar no barramento simultaneamente.
Especificação de hardware e elétrica do protocolo CAN:
CAN é um protocolo de dois fios, seus fios são par torcido e sem bobina. As duas extremidades do ônibus são terminadas com 120 resistores ohm. Os dois fios do ônibus CAN são CAN HIGH e CAN LOW.
- No protocolo CAN, a LÓGICA ‘1’ é chamada de recessiva e a LÓGICA ‘0’ é chamada de dominante.
- Diz-se que o ônibus é lógico ‘1’ ou recessivo quando o CANH e CANL são aplicados com 2,5V e a tensão diferencial dessas duas linhas são 0V.
- Diz-se que o ônibus é lógico ‘0’ ou dominante quando o CANH é puxado para 3,5V e o CANL puxado para 1,5V e a tensão diferencial entre as linhas é de 2V, é assim que os bits são transmitidos através de um barramento CAN.
- Quando um dos dispositivos CAN impulsiona o ônibus dominante, seria eletricamente impossível para os outros dispositivos CAN dirigir o mesmo ônibus para recessivo.
Quadro de dados do barramento padrão CAN:
- O início do quadro é um único bit dominante (0).
- A próxima parte é o identificador, o que significa a prioridade da mensagem que tem 11 bits de largura. Um “bit de enxalha” está incluído no identificador para manter a sincronização; o receptor vai destoizar ou remover a broca de sincronização.
- RTR – A solicitação de transmissão remota significa se os dados são para transmitir ou solicitar informações de outros dispositivos CAN. Recessivo (1) é enviado quando um dispositivo CAN está solicitando dados e dominante (0) é enviado ao transmitir dados.
- IDE – A extensão do identificador, de 1 bit de comprimento, deve ser a bit dominante para um quadro de dados identificador de 11 bits.
- r0 – Parte reservada para melhorias futuras, deve ser um pouco dominante.
- DLC – Código de comprimento de dados, de 4 bits de largura contém informações sobre quantos bytes de dados estão sendo enviados.
- Dados – As informações reais no quadro a serem recebidos por outros dispositivos CAN. Até 64 bits podem ser transmitidos.
- CRC – verificação de redundância cíclica para verificar erros de dados, 16 bits de largura.
- ACK – Reconhecimento de 2 bits de largura. Quando um dispositivo CAN receptor recebe a mensagem com precisão, o receptor grava este bit como dominante (0); se esse bit for deixado recessivo (acontece quando os dispositivos receptores não receberam bits de dados corretos) o remetente ressarcirá os dados novamente. Outro bit na ACK é delimitador e deve ser recessivo.
- EOF – Fim do quadro – 7 bits de largura, todos os bits devem ser recessivos.
- IFS – Espaço de quadro inter, de 3 bits de largura para atraso entre a corrente e o próximo quadro, para que os dispositivos recebidos possam processar os dados.
Quadro de dados estendido para barramento CAN:
Se estivermos usando o quadro de dados CAN estendido, aqui estão as diferenças:
- SRR – solicitação remota substituta, deve ser um bit recessivo.
- O IDE deve ser um bit recessivo para significar que este é um quadro de dados estendido.
- r1 – bit de reserva adicional.
Quadro remoto:
O quadro remoto é o mesmo que o quadro de dados padrão, mas há duas diferenças:
- A broca RTR é definida como recessiva.
- Não haverá nenhum quadro de dados.
O objetivo do quadro remoto é solicitar dados de outros dispositivos CAN no mesmo barramento.
Arbitragem:
Quando vários dispositivos CAN tentarem acessar o ônibus haverá conluio, para evitar tais erros de dados no ônibus, a arbitragem é estabelecida. No ônibus CAN o dispositivo com maior prioridade ganha a arbitragem.
Um dispositivo que envia o identificador como “00000000001” terá alta prioridade em comparação com um dispositivo que envia “00000000100” porque o dispositivo com identificador “00000000001” dirigiu o ônibus com bits dominantes (0) mais longos que o outro. O dispositivo perdido a arbitragem tentará novamente quando o ônibus não estiver ocupado.
No mundo real, os identificadores em equipamentos de veículos automotivos como airbag ou transmissão ou ABS serão mais priorizados do que um sistema de música ou ar condicionado. Isso conclui o protocolo BASICS CAN.
Hashtags: #ProtocolosComunicaçãoMicrocontroladores
Nota: Este conteúdo foi traduzido do Inglês para português (auto)
Pode conter erros de tradução
Olá, se tiver algum erro de tradução (AUTO), falta de link para download etc…
Veja na FONTE até ser revisado o conteúdo.
Status (Ok Até agora)
Se tiver algum erro coloque nos comentários