CAN Bus Implementation

UM ROTEIRO DE IMPLEMENTAÇÃO DE UMA REDE CAN (CONTROLLER AREA NETWORK)
ALEXANDRE DE ALMEIDA GUIMARÃES1,2, PROFº DR. ANTÔNIO MAURO SARAIVA2
1
GENERAL MOTORS DO BRASIL LTDA
2
ESCOLA POLITÉCNICA DA USP
RESUMO
O protocolo CAN (Controller Area Network) tem sido amplamente utilizado na implementação de
diversos sistemas eletrônicos embarcados. Pode-se encontrar, com relativa facilidade, diversas
publicações relacionadas, especialmente, aos conceitos fundamentais do protocolo, suas normas e
componentes eletrônicos existentes. Entretanto, experiências objetivas sobre o desenvolvimento de
uma rede completa não estão ao alcance de todos os interessados nesta tecnologia, especialmente
no Brasil. Considerando-se este cenário, este artigo procura relacionar as informações que devem ser
observadas durante a implementação de uma rede CAN genérica, possível de ser utilizada, por
exemplo, em aplicações experimentais ou de pesquisa e desenvolvimento. Considerando-se uma
aplicação hipotética, serão explicados os passos necessários para o desenvolvimento do hardware e
do software requeridos por sua rede de comunicação de dados.
1. INTRODUÇÃO: ELETRÔNICA EMBARCADA E ARQUITETURAS ELETRO-ELETRÔNICAS
O termo Eletrônica Embarcada representa todo e qualquer sistema eletro-eletrônico montado em
uma aplicação móvel, seja ela um automóvel, um navio ou um avião. Há muitos anos, a indústria
automotiva tem feito uso de sistemas eletro-eletrônicos no controle das várias funções existentes
em automóveis de passeio e comerciais.
Observa-se nos veículos atualmente comercializados, que boa parte destes sistemas de controle
foi desenvolvida de forma independente e isolada, de forma que cada um passa a ser
responsável por um determinado tipo de função no veículo. Por outro lado, o verdadeiro domínio
e maximização da utilização dos diversos dados eletrônicos disponíveis em um automóvel, só é
conseguida através da utilização de sistemas eletro-eletrônicos interligados, cada qual
responsável por uma parte do veículo, mas compartilhando informações entre si. A partir destas
duas condições, pode-se definir os dois principais conceitos de arquiteturas eletro-eletrônicas
existentes: Arquitetura Centralizada e Arquitetura Distribuída.
Vale reforçar que, as formas como os diversos sistemas de controle são implementados e
interconectados em uma aplicação embarcada são chamadas de Arquiteturas EletroEletrônicas (ou simplesmente Arquiteturas Elétricas).
1.1. Arquitetura Centralizada
Quando se analisa uma determinada aplicação e se encontra uma única ECU (Electronic Control
Unit) responsável por receber todos os sinais de entrada (como os sensores e chaves de
comando), processá-los e comandar as respectivas saídas de controle do sistema (como as
válvulas e relés), classifica-se seu conceito de Arquitetura Elétrica como Centralizado. A figura 1
representa este conceito de arquitetura.
Figura 1 – Arquitetura Centralizada
Como vantagens desta arquitetura podem-se destacar:
•
Simplicidade do Hardware utilizado na implementação do sistema, sendo constituído
basicamente pelos sensores e atuadores, uma ECU para o devido controle do sistema e,
obviamente, o cabeamento que os conecta.
•
Todos os dados de entrada estarão disponíveis à ECU durante toda a operação do
sistema, não sendo crítica a lógica de varredura e coleta de informações de cada um dos
sensores existentes.
Como desvantagens podem-se destacar:
•
Grande quantidade de cabeamento requerido para conectar os sensores e atuadores à
ECU, especialmente em grandes aplicações, o que dificulta a manufatura do veículo e a
sua eventual manutenção.
•
Limitação das possibilidades de expansão do sistema, uma vez que qualquer alteração
na ECU significará a modificação de seu Hardware e/ou Software e, eventualmente, na
condição de trabalho das funções originais do sistema.
1.2. Arquitetura Distribuída
Existe a possibilidade de se utilizar, em um mesmo sistema de controle, várias ECU´s
interligadas, dividindo entre si a execução das diversas funções existentes no veículo. A figura 2
representa este conceito de arquitetura.
Figura 2 – Arquitetura Distribuída
As ECU´s 1, 2 e 3 são responsáveis pela leitura direta das entradas do sistema, enquanto que as
ECU´s 4 e 5 são responsáveis pelo comando das saídas. Além disso, no diagrama apresentado,
qualquer uma das ECU´s, dependendo das funções existentes neste sistema de controle, poderá
participar do processamento dos dados e da atuação das saídas.
Como vantagens desta arquitetura podem-se destacar:
•
Quantidade reduzida de cabeamento do sistema, uma vez que, tendo-se várias ECU´s
disponíveis, pode-se instalá-las bem próximas aos sensores e atuadores, reduzindo o
cabeamento mais pesado da implementação, formado basicamente por pares e pares de
fios utilizados na conexão das entradas e saídas nas ECU´s.
•
Menor tempo de manufatura do veículo (exatamente pela menor quantidade de
cabeamento necessário).
•
Maior robustez do sistema de controle, por se ter reduzido as possibilidades de quebra de
um dos circuitos ou o aparecimento de mal contato em determinado conector (novamente
pela menor quantidade de cabeamento necessário).
•
Permite a ampliação do sistema com significativa facilidade, garantindo que alterações
em uma determinada função do veículo, impactem somente em uma ou em parte das
ECU´s.
•
Facilita a criação do software de aplicação de cada ECU, uma vez que possibilita a sua
modularização e distribuição de responsabilidades entre elas.
•
Possibilita a modularização do projeto do sistema e da execução dos testes de validação,
aumentando a confiabilidade da implementação e reduzindo os prazos envolvidos no
desenvolvimento.
Como desvantagens podem-se destacar:
•
Obriga a utilização de um meio de comunicação entre as ECU´s, meio este comumente
chamado de Protocolo de Comunicação.
•
Implica na existência de um software de controle para a rede de comunicação que
interliga as ECU´s, cuja dificuldade de desenvolvimento depende diretamente da escolha
do protocolo de comunicação.
•
Difícil determinação da taxa de transmissão ideal para uma dada aplicação, o que
impacta diretamente nos tempos internos do software de controle e na escolha dos
componentes eletrônicos a serem utilizados no projeto das ECU´s.
Explicadas as vantagens e desvantagens fundamentais dos dois conceitos de arquitetura
normalmente utilizados, deve-se acrescentar que a decisão de escolha de uma delas para uma
dada aplicação móvel, depende da ponderação de diversos fatores. Dentre eles podem-se
destacar:
•
A complexidade do sistema a ser controlado (quantidade de variáveis de entrada e saída
e o tamanho físico do sistema).
•
A disponibilidade dos componentes eletrônicos requeridos à montagem das ECU´s e à
medição e atuação no sistema.
•
A robustez, mecânica (como às vibrações) e elétrica (como às interferências eletromagnéticas), requerida pelo sistema a ser controlado.
•
O tempo necessário à implantação da arquitetura (projeto, construção de protótipos e
validação).
•
O custo desejado do sistema final (limitações inerentes ao orçamento).
O relacionamento entre estes fatores é que determinará o conceito de arquitetura mais
apropriado ao sistema a ser controlado.
Tal desafio é enfrentado quase que diariamente pelas empresas montadoras de veículos, onde
uma das maiores dificuldades do seu corpo de engenheiros é determinar a arquitetura elétrica de
um novo modelo; garantindo o mínimo de funções desejadas pelos futuros clientes, dentro dos
limites de custo de projeto e produto final determinados pela empresa.
As figuras 3 e 4 ilustram, respectivamente, um exemplo de aplicação automotiva para a
Arquitetura Centralizada e um exemplo para a Arquitetura Distribuída.
No exemplo que trata da Arquitetura Centralizada (figura 3), pode-se perceber o fato de não
existirem redes de comunicação de dados entre os diversos módulos eletrônicos de controle
mostrados.
Por outro lado, no exemplo que ilustra a Arquitetura Distribuída (figura 4), pode-se visualizar a
existência de três redes de comunicação de dados interligando as cinco ECUs mencionadas no
diagrama. Fica evidente neste caso o compartilhamento das informações lidas, por exemplo, pelo
BCM1, com os demais módulos do sistema.
Figura 3 – Exemplo de Aplicação: Arquitetura Centralizada
Figura 4 – Exemplo de Aplicação: Arquitetura Distribuída
2. PROTOCOLO DE COMUNICAÇÃO: O CAN BUS
Considerando, a partir deste momento, o conceito de Arquitetura Distribuída para a continuidade
das discussões neste artigo, pode-se afirmar com segurança que boa parte das dificuldades de
implementação existentes estão relacionadas ao chamado Protocolo de Comunicação.
Um Protocolo de Comunicação é um conjunto de regras que orienta a comunicação entre duas
ou mais ECUs. O CAN Bus, barramento Controller Area Network, considerando-se uma aplicação
móvel, é o que tem as melhores características técnicas e as mais robustas condições de
operação.
Foi desenvolvido pela empresa alemã Robert BOSCH e disponibilizado em meados dos anos 80.
Sua aplicação inicial foi realizada em ônibus e caminhões. Atualmente, é utilizado na indústria,
em veículos automotivos, navios e tratores, entre outros.
2.1. Conceituação
O CAN é um protocolo de comunicação serial síncrono. O sincronismo entre os módulos
conectados a rede é feito em relação ao início de cada mensagem lançada ao barramento
(evento que ocorre em intervalos de tempo conhecidos e regulares).
Trabalha baseado no conceito multi-mestre, onde todos os módulos podem se tornar mestre em
determinado momento e escravo em outro, além de suas mensagens serem enviadas em regime
multicast, caracterizado pelo envio de toda e qualquer mensagem para todos os módulos
existentes na rede.
Além disso, é fundamentado no conceito CSMA/CD com NDA (Carrier Sense Multiple Access /
Collision Detection with Non-Destructive Arbitration), o que significa que todos os módulos
verificam o estado do barramento, analisando se outro módulo está ou não enviando mensagens
com maior prioridade. Caso isto seja percebido, o módulo cuja mensagem tiver menor prioridade
cessará sua transmissão e o de maior prioridade continuará enviando sua mensagem deste
ponto, sem ter que reiniciá-la.
Como mencionado anteriormente, todos os módulos podem ser mestre e enviar suas mensagens.
Para tanto, o protocolo utiliza-se de uma arbitragem bit a bit não destrutiva, a qual pode ser
exemplificada analisando o comportamento de dois módulos enviando, ao mesmo tempo,
mensagens diferentes. Após enviar um bit, cada módulo analisa o barramento e verifica se outro
módulo na rede o sobrescreveu (vale acrescentar que um bit Dominante sobrescreve
eletricamente um Recessivo). Um módulo interromperá imediatamente sua transmissão, caso
perceba que existe outro módulo transmitindo uma mensagem com maior prioridade (quando seu
bit recessivo é sobrescrito por um dominante). Este módulo, com maior prioridade, continuará
normalmente sua transmissão.
Outro conceito bastante interessante é o NRZ (Non Return to Zero), onde cada bit (0 ou 1) é
transmitido por um valor de tensão específico e constante.
Considerando-se fios elétricos como meio de transmissão dos dados, existem três formas de se
constituir um barramento CAN, dependentes diretamente da quantidade de fios utilizada: através
de 1, 2 ou 4 fios. As redes com 2 e 4 fios trabalham com os sinais de dados CAN_H (CAN High) e
CAN_L (CAN Low). No caso dos barramentos com 4 fios, além dos sinais de dados, um fio com o
VCC (alimentação) e outro com o GND (referência) fazem parte do barramento, levando a
alimentação às duas terminações ativas da rede. As redes com apenas 1 fio têm este, o fio de
dados, chamado exclusivamente de linha CAN.
Considerando o CAN fundamentado em 2 e 4 fios, seus condutores elétricos devem ser
trançados e não necessariamente blindados. Os dados enviados através da rede devem ser
interpretados pela análise da diferença de potencial entre os fios CAN_H e CAN_L. Por isso, o
barramento CAN é classificado como Par Trançado Diferencial. Este conceito atenua fortemente
os efeitos causados por interferências eletro-magnéticas, uma vez que qualquer ação sobre um
dos fios será sentida também pelo outro, causando flutuação em ambos os sinais para o mesmo
sentido e com a mesma intensidade. Como o que vale para os módulos que recebem as
mensagens é a diferença de potencial entre os condutores CAN_H e CAN_L (e esta permanecerá
inalterada), a comunicação não é prejudicada.
No protocolo CAN, os dados não são representados por bits em nível “0” ou nível “1”. São
representados por bits Dominantes e bits Recessivos, criados em função da condição presente
nos fios CAN_H e CAN_L. A figura 5 ilustra os níveis de tensão em uma rede CAN, assim como
os bits Dominantes e Recessivos.
Figura 5 – Bits Dominantes e Recessivos
A velocidade de transmissão dos dados em uma rede CAN é inversamente proporcional ao
comprimento do barramento. A maior taxa de transmissão especificada é de 1Mbps
considerando-se um barramento de 40 metros. A figura 6 representa a relação entre o
comprimento da rede (barramento) e a taxa de transmissão dos dados.
Figura 6 – Relação entre o Comprimento da Rede e a Velocidade de Transmissão
2.2. Formatos das Mensagens
Existem dois formatos de mensagens no protocolo CAN:
CAN 2.0A – Mensagens com identificador de 11 bits, com os quais pode-se ter até 2048
mensagens.
Percebe-se que esta quantidade limitada de mensagens pode caracterizar uma limitação em
determinadas aplicações. A figura 7 apresenta o quadro de mensagem do CAN 2.0A.
Figura 7 – Quadro de Mensagens: CAN 2.0A
CAN 2.0B – Mensagens com identificador de 29 bits, com os quais pode-se ter,
aproximadamente, 537 milhões de mensagens.
Percebe-se neste caso que a limitação em virtude da quantidade de mensagens não mais existe.
Por outro lado, o que pode ser observado em alguns casos é que, os 18 bits adicionais no
identificador aumentam o overhead da mensagem, o que pode caracterizar um problema em
determinadas aplicações que trabalhem em tempo-real. A figura 8 apresenta o quadro de
mensagem do formato CAN 2.0B.
Figura 8 – Quadro de Mensagens: CAN 2.0B
2.3. Padrões Existentes
Os fundamentos do CAN são especificados por duas normas: a ISO11898 e a ISO11519-2. A
primeira, ISO11898, determina as características de uma rede trabalhando com alta velocidade
de transmissão de dados (de 125Kbps a 1Mbps). A segunda, ISO11519-2, determina as
características de uma rede trabalhando com baixa velocidade (de 10Kbps a 125Kbps).
Ambos os padrões especificam as camadas Física e de Dados, respectivamente 1 e 2 se
considerado o padrão de comunicação OSI de 7 camadas (ISO7498). As demais camadas, da
3 a 7, são especificadas por outros padrões, cada qual relacionado a uma aplicação específica.
Existem diversos padrões fundamentados no CAN, dentre os quais podem-se destacar:
•
NMEA 2000: Baseado no CAN 2.0B e utilizado em aplicações navais e aéreas.
•
SAE J1939: Baseado no CAN 2.0B e utilizado em aplicações automotivas, especialmente
ônibus e caminhões.
•
DIN 9684 – LBS: Baseado no CAN 2.0A e utilizado em aplicações agrícolas.
•
ISO11783: Baseado no CAN 2.0B e também utilizado em aplicações agrícolas.
Estes padrões especificam o equivalente às camadas de Rede (3), Transporte (4), Sessão (5),
Apresentação (6) e Aplicação (7), do padrão OSI, incluindo-se as mensagens pertinentes ao
Dicionário de Dados de cada aplicação em especial.
3. IMPLEMENTAÇÃO DE UMA REDE CAN
Considerando-se uma determinada aplicação, a primeira atividade que deve ser realizada durante
o projeto de sua rede de comunicação de dados é a determinação da sua arquitetura.
3.1. Determinação da Arquitetura Eletro-Eletrônica
Neste momento pode-se enfrentar duas situações: ter que estabelecer uma rede de comunicação
entre ECUs prontas e que não trabalhem em rede ou, ter que projetar totalmente as ECUs,
considerando a leitura das entradas, seus devidos processamentos e atuações nas saídas, além
da troca de dados através da rede propriamente dita.
Tomando-se como ponto de partida uma aplicação onde as ECUs estejam prontas, a
responsabilidade o engenheiro será, fundamentalmente, disponibilizar as informações de cada
ECU no formato determinado pelo Protocolo CAN, além de estabelecer as conexões necessárias
à comunicação de dados entre as próprias ECUs. Este cenário pode ser complexo de se lidar
uma vez que nem todas as ECUs, da forma como foram originalmente projetadas, serão capazes
de, facilmente, fornecer as informações sob sua responsabilidade para que o devido
empacotamento no formato CAN seja realizado. De qualquer forma o trabalho é possível.
Considerando-se uma aplicação onde somente o escopo do sistema que se deseja controlar
esteja disponível, pode-se projetar as ECUs já considerando os controladores capazes de,
facilmente, estabelecer uma comunicação fundamentada no protocolo CAN. Este artigo, a partir
deste ponto, considera esta condição: o projeto das ECUs e a sua interligação através do CAN.
A aplicação sobre a qual este estudo tratará é simples. A figura 9 apresenta a arquitetura
proposta.
Figura 9 – Diagrama Esquemático da Aplicação: Arquitetura Proposta
Esta arquitetura mostra-se extremamente simples, uma vez que considera duas ECUs
conectadas por uma rede de comunicação CAN Bus, ambas com as mesmas responsabilidades:
•
•
•
•
•
Ler algumas entradas digitais;
Empacotar estes dados no formato determinado pelo CAN;
Transmitir estes dados pela rede CAN à outra ECU;
Receber dados da outra ECU, enviados pela rede CAN, e
Processar estes dados, comandando as saídas necessárias.
Através de uma linha de comunicação serial RS232 e um PC, pode-se programar e monitorar o
funcionamento de cada ECU.
3.2. Determinação do Dicionário de Dados
O Dicionário de Dados (ou D.D.) de uma aplicação pode ser descrito como uma tabela que
relaciona as mensagens existentes nesta aplicação (seus identificadores e dados) e as ECUs
responsáveis por sua transmissão e recepção.
A tabela 1 mostra as informações necessárias ao Dicionário de Dados da aplicação tratada por
este artigo.
Tabela 1 – Dicionário de Dados da Aplicação
Analisando-se a tabela 1 percebe-se que, neste Dicionário de Dados:
•
•
•
•
•
A mensagem “1” é chamada de “Estado das Entradas da ECU #1”;
Ela é transmitida pela ECU #1 (TX) e recebida pela ECU #2 (RX);
Seu Identificador (ID) tem valor igual a “12345678 hex”;
Seus Bytes de Dados, excluindo-se o Byte “D #1”, são iguais a “00 hex”;
Seu Byte de Dados “D #1” depende de algumas regras específicas, onde:
! “XX” será “31 hex” caso uma determinada entrada digital seja igual a “1”
! “XX” será “30 hex” caso esta determinada entrada digital seja igual a “0”
Para as demais mensagens, vale a mesma análise. A única observação que deve ser feita é que
cada Byte de Dados da tabela que tiver seu valor igual a “XX”, possuirá uma regra específica,
assim como explicado para o Byte de Dados “D #1” da mensagem “1”.
Apesar deste D.D. parecer simples, e realmente é, ele demonstra o que efetivamente ocorre em
uma aplicação real. Analisando-se uma aplicação automotiva por exemplo, percebe-se a
existência de mensagens relacionadas ao funcionamento do motor, dos freios ABS e dos
sistemas de travamento das portas e alarme, entre outras. Além disso, pela complexidade dos
sistemas envolvidos no controle das funções do automóvel, não somente um byte de dados por
mensagem será utilizado (como feito na aplicação tratada por este artigo, onde é indicada apenas
a alteração do estado de uma determinada entrada) e sim, todos os 8 bytes existentes.
Estabelecido o Dicionário de Dados pertinente à esta aplicação, resta agora a sua implementação
efetiva, que se dá através de um software instalado dentro de cada ECU. Este software é
conhecido como firmware.
Antes de tratar do firmware necessário, deve-se considerar o projeto do hardware das ECUs.
3.3. Projeto do Hardware das ECUs
Este artigo considera ambas as ECUs sendo baseadas no mesmo projeto de hardware, contendo
a mesma quantidade de Entradas e Saídas, uma porta de comunicação serial RS232 e uma porta
de comunicação CAN Bus.
Quando se projeta uma ECU para a sua utilização em uma rede de comunicação de dados
baseada no Protocolo CAN Bus, tem-se duas alternativas tecnológicas em relação à execução do
processamento. A primeira, mais antiga, utilizando-se um Micro-Controlador (sem CAN)
conectado a um Controlador CAN (o que caracteriza dois CIs distintos e interligados). A segunda,
tecnologicamente mais atual, utilizando-se um Micro-Controlador com CAN incorporado.
Quando se utiliza um Micro-Controlador sem CAN (conectando-o a um Controlador CAN
específico), este fica responsável pelo tratamento das entradas e saídas, trocando informações
por portas de comunicação específicas com o Controlador CAN, responsável pelo
empacotamento dos dados no formato do Protocolo (além da sua transmissão e recepção).
Quando se utiliza um Micro-Controlador com CAN incorporado, este CI passa a ser responsável
não só pela leitura e tratamento das entradas e o acionamento das saídas, como também pelo
empacotamento dos dados no formato CAN (além da sua transmissão e recepção).
O que determina a utilização de um conceito ou do outro é, basicamente, a disponibilidade e o
custo dos componentes envolvidos. Do ponto de vista da implementação, acredita-se que a
utilização de um Micro-Controlador com CAN incorporado seja mais simples, rápida e segura do
ponto de vista técnico (especialmente em relação à Compatibilidade Eletro-Magnética).
Além do Micro-Controlador, uma ECU com capacidade de comunicação via CAN precisa ter o
chamado Transceiver ou Transmissor-Receptor. Este componente é responsável pela
compatibilização dos níveis elétricos requeridos pela rede CAN com os níveis elétricos
necessários ao trabalho do Micro-Controlador e vice-versa.
O projeto apresentado neste artigo considera o Micro-Controlador com CAN incorporado
P87C591 (Philips) e o Transceiver PCA82C250 (Philips).
Obviamente, na implementação efetiva de cada uma das ECUs, serão necessários outros
componentes eletrônicos além dos dois anteriormente mencionados – Micro-Controlador e
Transceiver. A figura 10 mostra o diagrama elétrico das ECUs.
Figura 10 – Diagrama Elétrico das ECUs
Por se tratarem de ECUs destinadas ao aprendizado do Protocolo CAN, optou-se pelo projeto
onde a execução de seus programas ocorre nas memórias EPROM e RAM, ao invés da memória
interna do Micro-Controlador (neste caso um OTP). Na memória EPROM grava-se um programa
de uma categoria conhecida como Monitor, enquanto que, na memória RAM, gravam-se os
programas Principais de cada uma das ECUs.
A figura 11 mostra a foto de uma ECU construída considerando-se o projeto de hardware
apresentado anteriormente.
Figura 11 – Foto de uma ECU baseada no projeto descrito neste artigo
3.4. Projeto do Firmware (Software das ECUs)
São dois os tipos de firmware utilizados neste projeto:
•
O primeiro é chamado de Monitor É gravado na memória EPROM a partir do endereço
0000hex e passa a ser executado toda vez que a ECU é reinicializada. A função principal
deste programa Monitor é possibilitar a gravação e a operação do programa Principal da
ECU em sua memória RAM. Isto é possível através da operação de comandos do
programa Monitor. Para tanto, a ECU precisa estar conectada a um PC via RS232 e, por
exemplo, utilizando o aplicativo Hyper Terminal do MS WindowsR, pode-se transferir o
programa Principal da ECU para a sua memória RAM. Qualquer programa Monitor para
Micro-Controladores similares ao 8051 pode ser utilizado neste projeto. Os testes neste
desenvolvimento específico consideraram o monitor PAULMON, disponível na internet
(www.pjrc.com/tech/8051/ - acesso em: 20 Out 2001).
•
O segundo é chamado de Principal. É gravado na memória RAM pelo processo descrito
anteriormente e passa a ser executado por um dos comandos existentes no programa
Monitor, (este comando desvia a execução do Micro-Controlador para a primeira posição
de memória ocupada pelo programa Principal – neste caso, o endereço 8000hex). Este
programa Principal é responsável pela leitura e o processamento das entradas, ativação
das saídas, controle da linha de comunicação serial RS232 e da linha de comunicação
CAN Bus.
A figura 12 mostra a distribuição dos vários programas mencionados e os endereços de início e
término das memórias EPROM e RAM.
Figura 12 – Memórias RAM e EPROM e seus respectivos Programas
Ainda sobre o programa Principal, é necessário o desenvolvimento de algumas rotinas que
responderão pelas seguintes operações:
•
•
•
•
•
•
Inicialização da Porta de Comunicação Serial RS232;
Inicialização da Porta de Comunicação CAN Bus (Baud Rate e os Filtros de Aceitação de
Mensagens);
Rotinas de Transmissão e Recepção via RS232;
Rotinas de Transmissão e Recepção via CAN Bus;
Rotina de leitura de uma Entrada Digital;
Rotina de acionamento de uma Saída Digital.
As rotinas acima mencionadas podem ser escritas em linguagem C e o programa final que as
contêm, pode ser compilado com o auxílio de qualquer compilador C para micro-controladores
similares ao 8051. Neste projeto utilizou-se o SDCC – Small Device C Compiler, disponível na
internet (www.sdcc.sourceforge.com - acesso em: 21 Nov 2001).
Alguns exemplos de rotinas programadas em C são mostradas a seguir:
• Início do Programa:
#include "87C591.h"
#define BYTE unsigned char
#define WORD unsigned int
#define IN P1_2
#define OUT P3_2
• Definição da estrutura da mensagem CAN:
typedef struct {
BYTE INFO;
BYTE ID[4];
BYTE BUF[8];
}
PDU;
/* Byte com informações relacionadas a mensagem CAN */
/* 4 bytes de Identificador */
/* 8 bytes de dados */
• Inicialização da Porta RS232:
void init_serial() {
PCON = 0x80;
TMOD = 0x20;
TCON = 0x40;
TH1 = 0x0FD;
SCON = 0x52;
}
/* SMOD1=1 e SMOD0=0 => Baud Rate dobrado */
/* Timer 1 autoload */
/* Inicia o Timer 1 */
/* Taxa de transmissão: 19200*2=38400 */
/* SM0=0 e SM1=1 => Modo 1 */
• Transmissão via CAN Bus:
void TX_CAN (PDU *ptxb) {
BYTE length;
BYTE i;
length = ptxb->INFO;
while (!(CANSTA & 0x04));
CANADR = 0x70;
CANDAT = length;
for (i=0;i<4;i++)
/* CAN Data Length Code */
/* index */
/* Aponta para o TX Frame Information */
/* Coloca o DLC no CANDAT */
CANDAT = ptxb->ID[i];
/* Coloca os 4 bytes do ID no CANDAT */
for (i=0;i<length;i++)
CANDAT = ptxb->BUF[i];
/* Coloca os 8 bytes de Dados no CANDAT */
CANCON = 0x01;
/* Solicita transmissão */
}
• Recepção via CAN Bus:
int RX_CAN (PDU *prxb) {
BYTE length;
BYTE i;
if (CANSTA & 0x01)
{
CANADR = 0x60;
length = CANDAT & 0x0F;
prxb->INFO = length;
/* CAN Data Length Code */
/* index */
/* Analisa o RBS - Receive Buffer Status */
/* Aponta para o RX Frame Information */
/* Coloca o DLC na variável length */
/* Coloca o DLC no prxb */
for (i=0;i<4;i++)
prxb->ID[i] = CANDAT;
/* Coloca os 4 bytes do ID no prxb */
for (i=0;i<length;i++)
prxb->BUF[i] = CANDAT;
/* Coloca os 8 bytes de Dados no prxb */
CANCON = 0x0C;
return (1);
} else
return (0);
}
3.5. Montagem da Rede CAN Bus: Barramento e Terminadores
Barramento é o termo técnico que representa os condutores elétricos das linhas de comunicação
e a forma como eles são montados. Apesar de parecer simples, o ato de interligar os módulos
requer bastante atenção.
Sobre o cabeamento necessário, considerando-se uma aplicação CAN de dois fios, deve-se
utilizar par trançado onde a secção transversal de cada um dos fios deve ser de no mínimo
0,35mm².
As duas terminações (resistores de aproximadamente 120 ohms), do ponto de vista teórico,
podem ser instaladas nas extremidades do chicote, diretamente nos fios de dados CAN_H e
CAN_L. Do ponto de vista prático isto é extremamente complexo. O que deve ser feito é adicionar
as terminações nas duas ECUs conectadas aos extremos da rede. Se as ECUs forem montadas
dependendo dos opcionais do veículo, deve-se procurar instalar as terminações nas ECUs que
sempre estiverem presentes nele (veículo). As terminações são mandatórias numa rede CAN.
No momento de se projetar o roteamento do barramento, algumas regras em relação ao
comprimento dos chicotes devem ser observadas pois, o sincronismo das operações das ECUs
no CAN é fundamentado no tempo de propagação física das mensagens dentro dos condutores
elétricos. Assim, a relação do comprimento de determinados intervalos do chicote no barramento
são fundamentais ao bom funcionamento da rede.
A figura 13 mostra um diagrama que ilustra as medidas que devem ser observadas no
desenvolvimento do chicote.
Figura 13 – Geometria do Barramento
Destaca-se que, após o barramento ter sido montado, caso seja necessário qualquer retrabalho
no mesmo, é aconselhável a troca do chicote elétrico danificado. Emendas poderão alterar a
impedância característica da rede e com isso afetar o seu funcionamento.
CONCLUSÕES
Este artigo procurou explicar, de maneira simplificada, todos os conceitos relacionados a aplicação do
protocolo CAN Bus. Foram abordados aspectos ligados à determinação da Arquitetura, Centralizada
ou Distribuída, explicados os conceitos fundamentais do protocolo CAN Bus e relacionados os passos
importantes no momento de se implementar efetivamente uma rede de comunicação de dados
baseada no CAN.
Como pôde ser observado, a implementação de um barramento CAN envolve conceitos de hardware
e software. O primeiro, hardware, é fortemente dependente da estratégia de utilização do microcontrolador pelo engenheiro projetista. O segundo, software, agrega o controle das operações
realizadas pelas ECUs.
Sobre a montagem do barramento físico de uma rede CAN, percebeu-se que não deve ser
desconsiderada e tratada como uma etapa simples da implementação do sistema. Existem regras e
boas práticas que garantem o bom funcionamento da rede.
LISTA DE ABREVIAÇÕES
ACK: Acknowledgement.
CAN Bus: Barramento Controller Area Network.
CI: Circuito Integrado.
CD: Collision Detection.
CRC: Cyclic Redundant Check.
CSMA/CD: Carrier Sense Multiple Access.
EA: External Access.
ECU: Electronic Control Unit.
EEPROM: Electrical Erasable and Programmable ROM.
EPROM: Electrical Programmable ROM.
I/O: Input/Output.
ISO: International Organization for Standardization.
Kbps: Kilo bits por segundo.
Mbps: Mega bits por segundo.
NDA: Non-Destructive Arbitration.
NRZ: Non-Return to Zero.
OSI: Open System Interconnection.
OTP: One Time Programmable.
PC: Personal Computer.
RAM: Random Access Memory.
ROM: Ready Only Memory.
SAE: Society of Automotive Engineers.
REFERÊNCIAS
• Guimarães, A.A. Eletrônica Embarcada em Automóveis – Parte 1, Revista SABER
Eletrônica – N°363, Abril 2003, ISSN 0101-6717, São Paulo, 2003, pg 40-43.
• Guimarães, A.A. Eletrônica Embarcada em Automóveis – Parte 2, Revista SABER
Eletrônica – N°364, Maio 2003, ISSN 0101-6717, São Paulo, 2003, pg 20-24.
• Guimarães, A.A. Eletrônica Embarcada em Automóveis – Parte Final, Revista SABER
Eletrônica – N°365, Junho 2003, ISSN 0101-6717, São Paulo, 2003, pg 18-22.
• Guimarães, A.A.; Saraiva, A.M. O Protocolo CAN: Entendendo e Implementando uma Rede
de Comunicação Serial de Dados baseada no Barramento “Controller Area Network”, SAE
paper nº 2002-01-3569. São Paulo, 2003.
• Guimarães, A.A. O Protocolo CAN Bus nas Aplicações Off-Road: Uma Análise Comparativa
entre os Padrões Existentes, SAE paper nº 2001-01-3853. São Paulo, 2001.
• Guimarães, A.A. Análise da norma ISO11783 e sua utilização na implementação do
barramento do implemento de um monitor de semeadora. 2003. 98p. Dissertação
(Mestrado) – Escola Politécnica, Universidade de São Paulo. São Paulo, 2003.
• Fredriksson, L.B. Controller Area Networks and the protocol CAN for machine control
systems, Mechatronics, v.4 n.2, p.159-92, 1994.
• Zuberi K.M.; Shin K.G. Real-time decentralized control with CAN. In: IEEE Conference on
Emerging Technologies and Factory Automation, 1996. Proceedings. IEEE, 1996. p.93-9.
• Controller Area Network (CAN) - Module 6., BOSCH - Powertrain University, 2000.
• ISO 11898 - Road vehicles-Interchange of digital information-Controller area network
(CAN) for high-speed communication, 1993.
• Data Dictionary for V-Bus applications, Issue 1.3, 2001, GM proprietary documentation.
• Phillips Web Site, www.semiconductors.philips.com, consultado em Março de 2002.
• Strauss, C. Implementação e Avaliação de uma Rede Experimental baseada em CAN para
Aplicações Agrícolas, Dissertação de Mestrado, EPUSP, 2001.
REFERÊNCIAS ADICIONAIS
• Guimarães, A.A.; Saraiva, A.M. As Aplicações Agrícolas e o Protocolo CAN: Uma Aplicação
a um Monitor de Semeadora. In: 3º Congresso da SBI-Agro, Foz do Iguaçu. Anais. SBI
Agro. Lavras. 2002. p.35-42.
• Hofstee, J.W.; Goense, D. Simulation of a Controller Area Network-based Tractor-Implement
Data Bus according to ISO 11783, J. Agric. Engng Res. (1999) 73, 383-394.
• Sigrimis, N.; Hashimoto, Y.; Munack, A.; De Baerdemaeker, J. Prospects in Agricultural
Engineering in the Information Age, CIGR-Ejournal, invited paper, 1998.
• Strauss, C.; Cugnasca, C.E.; Saraiva, A.M. Protocolos de Comunicação para Equipamentos
Agrícolas, CONAI, 1998.
• ISO11783 Workshop, Agrithecnica 99, http://isotc.iso.ch/livelink/livelink, 1999.
• Fredriksson, L.B. Distributed Embedded Control Systems in Robotics – Ten Years of
Development, KVASER AB, 1997.
• Stone, M.L. Dynamic Address Configuration in SAE J1939, Biosystems and Agricultural
Engineering, Oklahoma State University.
• Stone, M.L. High Speed Networking in Construction and Agricultural Equipments,
Department of Biosystems and Agricultural Eng'g, 1994,
www.agen.okstate.edu/home/mstone/.
• Axelson, J. Serial Port Complete, ISBN 0-9650819-2-3, Lakeview Research, 1998.
• Why CAN, KVASER Web Site, www.kvaser.se/can/index.htm, 2000.
• HLPs: SAE J1939, KVASER AB, 2000.
• Stone, M.L.; Zachos, M. Application of J1939 Networks in Agricultural Equipments,
Oklahoma State University Dearborn Group.
• Controller Area Network – Background Information, How CAN works, Implementation,
Application Layer. www.omegas.co.uk/CAN/, 2000.
• Stepper, M. R. J1939 High Speed Serial Communications, The Next Generation Network for
Heavy Duty Vehicles, SAE paper nº 931809, 1993.
• Alvarenga, C. Multiplexing in Automobiles – An Application Example of the CAN Protocol,
SAE paper, Multiplexing and Networking pág. 503 – 514.
• Dietmayer, K.; Overberg, K. W. CAN Bit Timing Requirements, SAE paper nº 970295, 1997.
• Buehring, P. CAN Controller Architecture Optimized for SAE-J1939 Applications, SAE paper
nº 940361, 1994.
• Samuel, J. Developing Diagnostics on KWP 2000 and CAN, SAE paper nº 981112, 1998.