Pedro Miguel dos Reis Caldeira - web.fe.up.ptee99058/projecto/relatorios/relatorio_n.pdf · Este projecto tem como objectivo a implementação de uma rede CAN com características

Autoria:

Pedro Miguel dos Reis Caldeira ([email protected])

Roberto Manuel dos Santos Fernandes ([email protected])

Orientação:

Prof. Artur Cardoso ([email protected])

Colaboração:

Eng. José Azevedo ([email protected])

Dezembro de 2001

PPRREEFFÁÁCCIIOO

No curso de Engenharia Electrotécnica e Computadores, vertente de Automação,

Produção e Electrónica Industrial, ministrado pela Faculdade de Engenharia da

Universidade do Porto, são leccionados assuntos vastos entre eles conceitos e

implementação de aplicações de sistemas distribuídos e redes industriais. Na tomada de

decisão para a escolha do trabalho a realizar no âmbito da disciplina Projecto Final de

Curso, considerou-se um factor primordial o aprofundar de conhecimentos nesta área,

dado o forte desenvolvimento das tecnologias de comunicação e sua aplicabilidade na

indústria.

Este projecto tem como objectivo a implementação de uma rede CAN com características

funcionais destinadas a satisfazer os requisitos do cliente, a empresa Microprocessador

S.A. do grupo Efacec. Este projecto continua outro, executado no ano lectivo anterior,

tomando como ponto de partida o hardware do Nó CAN projectado e construído nesse

projecto, e desenvolvendo o software (firmware) para implementar o controlo das

comunicações, o controlo de várias funções do Nó como o teclado e o écran de cristais

líquidos, bem como uma aplicação de demonstração das capacidades de um sistema de

controlo baseado nesta rede.

A troca de informação não deverá ser restringida aos Nós da rede, pelo que, outro grupo

de trabalho desenvolverá software para interface da rede CAN para Ethernet baseado no

protocolo TCP/IP, permitindo o controlo remoto do sistema e a sua monitorização.

Importante salientar o facto deste trabalho ter a participação da empresa

Microprocessador no desenvolvimento deste projecto, a qual poderá utilizar os

resultados obtidos na concepção do produto para solidificar a sua implantação nesta área

de negócio.

Os mais sinceros agradecimentos ao professor Artur Cardoso pela orientação e

dedicação, e ao Eng. José Azevedo, da empresa Microprocessador pelo apoio dado à

evolução do trabalho.

GGLLOOSSSSÁÁRRIIOO

CCAANN –– CCOONNTTRROOLLLLEERR AARREEAA NNEETTWWOORRKK

LLAANN –– LLOOCCAALL AARREEAA NNEETTWWOORRKK

PPLLCC –– PPRROOGGRRAAMMMMAABBLLEE LLOOGGIICC CCOONNTTRROOLLLLEERR

MMAAPP –– MMAANNUUFFAACCTTUURRIINNGG AAUUTTOOMMAATTIIOONN PPRROOTTOOCCOOLL

TTCCPP –– TTRRAANNSSMMIISSSSIIOONN CCOONNTTRROOLL PPRROOTTOOCCOOLL

IIPP –– IINNTTEERRNNEETT PPRROOTTOOCCOOLL

BBRRPP –– BBIITT RRAATTEE PPRREESSCCAALLEERR

MMCCUU –– MMIICCRROO CCOONNTTRROOLLLLEERR UUNNIITT

PPPPII -- PPRROOGGRRAAMMMMAABBLLEE PPOORRTT IINNTTEERRFFAACCEE

SSCCII –– SSEERRIIAALL CCOOMMMMUUNNIICCAATTIIOONNSS IINNTTEERRFFAACCEE

SSPPII –– SSEERRIIAALL PPEERRIIPPHHEERRAALL IINNTTEERRFFAACCEE

ÍÍNNDDIICCEE

RREEDDEESS DDEE CCAAMM PPOO .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. 88

NÍVEIS DE UMA REDE INDUSTRIAL .................................................................. 8

REDES LOCAIS INDUSTRIAIS ........................................................................ 9

REDES DE CAMPO ..................................................................................... 9

REDES DEDICADAS ................................................................................... 10

PPRROOTTOOCC OOLLOO CCAANN .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. 1100

AREAS DE APLICAÇÃO ............................................................................... 11 UTIL IZAÇÃO EM AUTOMÓVEI S . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11 APL ICAÇÕES INDUSTRI AI S . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11

PRINCÍPIOS DE TROCA DE INFORMAÇÃO .......................................................... 12 ARBITRAGEM NÃO DESTRUTI VA DOS B IT S . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12

FORMATO DAS TRAMAS CAN........................................................................ 13 FORMATO STANDARD 2.0A .. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14 FORMATO EXTEND IDO 2.0B .. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15 COMPATIB IL IDADE ENTRE 2.0A E 2.0B .. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16

BIT TIMING ........................................................................................... 16 TEMPO DE B IT . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16 S INCRONIZAÇÃO . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17

ERROS ................................................................................................. 19 DETECÇÃO DE ERROS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19 CONF INAMENTO DE ERROS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20

DDEESSCCRRII ÇÇÃÃOO DDOO TTRRAABBAA LLHHOO .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. 2211

PLANO DE TRABALHOS ............................................................................... 21

MATERIAL UTILIZADO ............................................................................... 22 HARDWARE . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22 SOFTWARE . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22

IDEALIZAÇÃO DE UMA MAQUETA (ÁREA DE APLICAÇÃO) ......................................... 22

EESSTTUUDD OO DD OO MMII CCRROO CCOO NNTTRROO LLAADD OORR MMCC6688HHCC 770055CC99AA .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. 2266

INTERRUPÇÕES ....................................................................................... 27

PORTOS E/S ......................................................................................... 29

TIMER ................................................................................................. 29

COMUNICAÇÃO SCI .................................................................................. 30

COMUNICAÇÃO SPI .................................................................................. 30

EESSTTUUDD OO DD OO CCOO NNTTRROO LLAADD OORR DDEE CCAANN MMCCPP22551100 .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. 3311

FUNCIONALIDADE .................................................................................... 31

MODOS DE OPERAÇÃO ............................................................................... 33

BIT TIMING .......................................................................................... 33

TRANSMISSÃO DE MENSAGENS...................................................................... 36

RECEPÇÃO DE MENSAGENS .......................................................................... 36

INTERRUPÇÕES ....................................................................................... 37

EESSTTRRUUTTUURRAAÇÇ ÃÃOO DD OO CCÓÓ DDII GGOO .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. 3388

AAPPLLIICCAAÇÇ ÃÃOO EEMM LLAABBVVIIEE WW PPAA RRAA CC OONN FF IIGGUURRAA ÇÇ ÃÃOO DDOO MMCCPP22551100 .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. 4411

PROBLE MAS DETECTA DOS............................................................................ 42

PROPOSTAS PARA ME LHORIAS/A LTERAÇÕES FUTURAS............................................ 42

CCOONNCC LLUU SSÕÕEE SS .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. 4433

RREEFFEERRÊÊNNCC IIAA SS .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. 4444

AANNEEXXOO SS .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. 4444

MANUAL DO UTILIZADOR ............................................................................ 44

FACULDADE DE ENGENHA RIA DA UNIVERSIDA DE DO PORTO

Pag. 7 de 44

LLIISSTTAA DDEE FFIIGGUURRAASS

Figura 1: Níveis de uma rede industrial 9

Figura 2: Método de Arbitragem 13

Figura 3: Frame Standard (2.0A) 15

Figura 4: Frame Estendida (2.0B) 15

Figura 5: Alargamento do tempo de bit 16

Figura 6: Alargamento do tempo de bit 18

Figura 7: Encurtamento do tempo de bit 18

Figura 8: Estados de Erro de um Nó CAN 20

Figura 9: Esquema de ligações dos Nós CAN da Microprocessador 23

Figura 10: Esquema de ligações do driver da ventoinha 24

Figura 11: Esquema do sensor de temperatura e da conversão A/D do sinal 24

Figura 12: Maqueta de simulação do controlo de um edifício. 25

Figura 13: Arquitectura do MCU MC68HC705C9A 27

Figura 14: Tabela de interrupções 28

Figura 15: Arquitectura do MCP2510 32

Figura 16: Interface do software MCP2510 Bit Time Calculator 34

Figura 17: Configurações Possiveis para o bit timing 35

Figura 18: Tabela dos identificadores utilizados 37

Figura 19: snapshot do ambiente de simulação ICS05CZ 39

Figura 20: Interface principal da aplicação LabView 41

DESENVOLVIMENTO DE SOFTWA R E DE APLICA ÇÃO PA RA REDES CAN

Pag. 8 de 44

RREEDDEESS DDEE CCAAMMPPOO

Uma rede industrial consiste numa variedade notável de domínios. Um deles pode

representar uma fábrica de produção de determinado artigo, outro uma fábrica de

produção de produtos alimentares, outros supervisão de máquinas, etc. No entanto, todos

eles são potenciais utilizadores das redes de campo, mesmo que a sua necessidade de

utilização se justifique mais nuns do que noutros - para alguns, as redes de campo estão

embebidas na configuração da produção. Assim, a abordagem às redes de campo deve ter

em conta todas estas diferentes necessidades.

Uma vez que o presente trabalho é feito sobre uma rede de CAN, apenas serão

mencionadas algumas redes e de uma forma muito superficial.

NÍVEIS DE UMA REDE INDUSTRIAL

Numa rede industrial coexistem equipamentos e dispositivos de todo o tipo, os quais

podem ser agrupados hierarquicamente para estabelecer ligações mais adequadas para

cada área. Desta forma, podem ser definidos quatro níveis dentro de uma rede

industrial:

• Nível de gestão: é o nível mais elevado e é responsável por integrar os níveis

seguintes na estrutura de uma fábrica. As máquinas aqui ligadas podem ser

estacões de trabalho que fazem ponte entre o processo produtivo e a área de

gestão, na qual se monitoram vendas, stocks, etc.. Aqui, utiliza-se uma rede do

tipo LAN ou WAN.

• Nível de controlo: encarrega-se de enlaçar e dirigir as distintas zonas de trabalho.

A este nível, situam-se os autómatos de alta gama e computadores dedicados ao

desenho, controlo de qualidade, programação, etc.. Pode, aqui, implementar-se

uma rede do tipo LAN.

• Nível de campo e de processo: encarrega-se da integração de pequenos

automatismos (autómatos compactos, multiplexadores de e/s, controladores PID,

etc..) dentro de sub-redes ou "ilhas". Num nível mais elevado destas redes,

podemos encontrar um ou mais autómatos modulares, actuando como mestres da

rede ou mestres flutuantes. Aqui empregam-se redes de campo.

• Nível de E/S: é o nível mais próximo do processo. Aqui encontram-se os sensores

e actuadores, encarregados de manejar o processo produtivo e de tomarem as

medidas necessárias para uma correcta automação e supervisão. Aqui empregam-se

redes de campo.


Pag. 9 de 44

FIGURA 1: NÍVEIS DE UMA REDE INDUSTRIAL

Note-se que esta estrutura não é universal, existindo casos onde se encontram mais ou

menos níveis, dependendo da dimensão do processo e da própria indústria.

REDES LOCAIS INDUSTRIAIS

São as redes mais elevadas hierarquicamente. Os standards mais conhecidos são dois:

MAP - nasceu como um produto desenvolvido especialmente para os ambientes

industriais, o que fez dele o maior êxito nas redes locais industriais. Foi impulsionado

pela General Motors e normalizado pelo IEEE. Não actua a nível das redes de campo, mas

estabelece uma ligação entre estas por intermédio de terminais. Permite ainda uma

integração das redes WAN. Este standard abrange todas as camadas do modelo OSI.

TCP/IP/ETHERNET – são compatíveis com o modelo OSI nos Níveis 1, 2 e 3 (este ultimo

nível através de pontes - Bridges). Permite uma topologia em bus ou árvore com

comunicações half-duplex. As velocidades variam desde os 10 Mbits/s aos 100 Mbits/s na

Fast-Ethernet. É um dos standards de rede que mais rapidamente evoluiu devido ao seu

uso massivo em redes de escritório.

REDES DE CAMPO

Este nível agrupa todas as redes que permitem a transmissão de tramas com o tamanho

de cerca de 12 a 256 bytes. A resposta temporal é da ordem dos mili-segundos aos

décimos de segundo.

As redes de campo são as redes de nível mais baixo numa hierarquia e destinam-se por

isso a ligar essencialmente sensores e actuadores.


Pag. 10 de 44

Uma vez que os Nós funcionam conjuntamente, na maior parte dos casos, um Nó

coordena e distribui tarefas, uma das razões pelas quais as redes de campo são

construídas à volta de uma hierarquia mestre-escravo ("master-slave"): o mestre

controla operações e comunicações através de, ciclicamente, questionar os escravos -

"polling"- que lhe podem responder apenas se ele lhes permitir. Este modo de

procedimento elimina qualquer confusão na rede, uma vez que o protocolo permite

apenas que um Nó possa transmitir dados de cada vez. No entanto, esta estrutura rígida

possui também um "tendão de Aquiles": se um Nó mestre pára de trabalhar

correctamente, tudo deixa de funcionar. A maior parte das redes de campo actuais, tais

como a Profibus FMS ou a nova BitBus (IEEE-1118), é capaz de comutar o papel de

mestre para outro Nó se tal for necessário, ou se um mestre estiver inactivo.

REDES DEDICADAS

Este tipo de redes pode ser mais subdividido em função das áreas de aplicação,

correndo-se o risco de as definir com constituição de apenas uma única linha de

comunicação. Por outro lado, as redes dedicadas não são confundidas com as redes

proprietárias, para as quais apenas existe um fornecedor. As aplicações deste tipo de

redes são variadas, destacando-se, por exemplo:

• controlo do movimento, particularmente no posicionamento de motores nos eixos

das máquinas de ferramentas;

• iluminação de edifícios, onde o fluxo de informação é reduzido a poucos bits, mas o

custo por Nó é um factor crítico;

• automação de veículos, o campo originário da rede CAN;

• técnicas de teste e de medição;

• Forças Militares que possuem requisitos mais estritos de confiabilidade;

PPRROOTTOOCCOOLLOO CCAANN

A rede CAN surgiu de modo a satisfazer a crescente necessidade de segurança, conforto e

comodidade existentes no mercado automóvel, associada às, cada vez maiores, exigências

governamentais no que respeita à diminuição de poluição e consumo, aumento da

segurança, etc. Como tal, a indústria automóvel começou a desenvolver e a integrar cada

vez mais componentes electrónicos, como sejam o "Anti Blocking System”, controlo de

tracção, o controlo do ar condicionado, fecho centralizado de portas entre outros. A

complexidade destes sistemas de controlo e a necessidade de trocar informação entre eles,

significavam cada vez mais cablagem e linhas de controlo dedicadas. Além do custo da

cablagem necessária para ligar todos os componentes, o tamanho físico do sistema e a

complexidade que daí advém tornam esta solução incomportável. Os custos exagerados e o

número crescente de ligações comprometia seriamente a confiança, segurança e tolerância

a falhas do sistema.


Pag. 11 de 44

A Bosch apresentou em meados de 80 a sua solução para o problema, a rede CAN. Este

protocolo, que mais tarde se tornou em norma internacional ISO 11898 e ISO 11519, e foi

licenciado um certo número de empresas de modo a permitir o desenho e produção de

controladores, microcontroladores e outros dispositivos, compatíveis com a norma CAN. Ao

adoptar o protocolo CAN, os controladores, sensores e actuadores podem comunicar entre

si em tempo real podendo atingir taxas de transmissão de 200kBit/s até 1Mbit/s. da

ordem de 1 MB/s, utilizando um par de condutores entrançados como linha de dados série.

Além disso o protocolo CAN tem mecanismos que permitem o funcionamento em ambientes

electromagneticamente agressivos. Este protocolo possui um mecanismo de detecção

automática de erros.

AREAS DE APLICAÇÃO

UTILIZAÇÃO EM AUTOMÓVEIS

Num automóvel existem 4 aplicações principais que necessitam de comunicação série,

tendo cada uma delas diferentes requisitos e objectivos: Controladores para o motor,

transmissão, chassis e travões.

Os dispositivos de rede no chassis controlam, por exemplo, o controlo as luzes, o

controlo do ar condicionado, o fecho centralizado de portas, a regulação eléctrica do

assento e do espelho. Os valores típicos da taxa de transmissão para estes dispositivos

rondam os 50kBits/s.

Ao nível da segurança são utilizados dispositivos de controlo de tracção e o Anti

Blocking System.

Os dispositivos de controlo situados no motor permitem obter um melhor rendimento

do motor, uma vez que está sujeito a um controlo mais apertado, diminuindo assim,

tanto o consumo, como o nível de poluição.

APLICA ÇÕES INDUSTRIAIS

Uma comparação entre os requisitos e constrangimentos de um sistema em rede de um

automóvel e os requisitos necessários a qualquer rede de sensores/actuadores de

aplicação industrial, revela semelhanças, nomeadamente: o baixo custo de instalação e

manutenção, a capacidade de operar em condições e ambientes adversos, as

necessidades de comunicação de tempo real e a facilidade de utilização.

A utilização standard do protocolo CAN em todos os automóveis da classe "S" da

Mercedes-Benz e a adopção do CAN pelos construtores Americanos de veículos

comerciais e todo-o-terreno fez com que os restantes fabricantes lhe começassem a

prestar a devida atenção. Não foram somente os fabricantes de automóveis,

maquinaria agrícola e náutica que escolheram o CAN. Essa foi também a escolha dos

fabricantes de aparelhos médicos, de máquinas têxteis, controlo de elevadores e do

campo da maquinaria hidráulica.


Pag. 12 de 44

A indústria têxtil foi uma das pioneiras do CAN, começando a primeira fábrica a equipar

os teares em 1990, o primeiro tear era composto por um sistema de controlo modular

que comunicava através de uma rede CAN em tempo real. Entretanto muitos

fabricantes de maquinaria têxtil uniram-se formando o CAN Textile Users Group, que

por sua vez faz parte do grupo internacional de fabricantes, CAN in Automation. Além

da segurança e do alto débito do CAN, o baixo preço dos dispositivos de ligação à rede

foram sem dúvida um argumento decisivo a favor do CAN. Em aplicações onde o preço

é um factor crítico, é essencial que exista no mercado disponível uma grande variedade

de chips. Mais uma vez, o tamanho, a robustez e o facto de serem bastante compactos

foram elementos de especial importância a favor do CAN.

PRINCÍPIOS DE TROCA DE INFORMAÇÃO

Quando são transmitidos dados no CAN, nenhum Nó é endereçado directamente, sendo o

conteúdo da mensagem (e.g. RPM ou temperatura do motor) definido por um

identificador único em toda a rede que estabelece a prioridade da mensagem, facto muito

importante na arbitragem do acesso ao bus quando mais do que um Nó tenta aceder ao

mesmo tempo.

Se o CPU de um determinado Nó decide enviar uma mensagem a um ou mais Nós, tudo o

que tem que fazer é facultar ao seu chip CAN os dados a serem transmitidos e os seus

identificadores. Assim, a mensagem é construída e enviada pelo chip CAN logo que o chip

tenha a rede alocada. Em seguida, todos os outros Nós da rede tornam-se receptores da

mensagem. Cada Nó da rede depois de ter recebido a mensagem correcta, efectua um

teste de aceitação de modo a verificar se os dados recebidos são relevantes. Se estes

dados forem relevantes para o Nó, são processados, caso contrário, descartados.

Em função deste esquema de endereçamento orientado ao conteúdo consegue-se uma

maior flexibilidade, sendo bastante simples adicionar ou retirar Nós da rede sem

qualquer alteração física ou conceptual.

ARBITRAGEM NÃO DESTR UTIVA DOS B ITS

Para se conseguir processar dados em tempo real é necessário que a troca de

mensagens se faça rapidamente. Isto não requer somente uma transferência de dados

da ordem do 1Mbit/s, mas também que a alocação da rede seja feita de uma forma

rápida e eficaz, especialmente quando existe mais do que um Nó a tentar enviar

mensagens ao mesmo tempo.

No processamento em tempo real, a urgência das mensagens a serem trocadas pode

diferir grandemente, pois em qualquer sistema existem parâmetros que variam mais

rapidamente que outros, como por exemplo as rotações por minuto (que variam muito

mais rapidamente que a temperatura do motor). Assim, é mais provável que os

parâmetros que têm mais oscilações sejam transmitidos com mais frequência. Como

tal, é imperativo que também tenham maior prioridade. As prioridades são definidas

durante a especificação do sistema e não podem ser alteradas dinamicamente. São


Pag. 13 de 44

escritas sob a forma de valor binário, onde o menor valor corresponde à maior

prioridade.

Os conflitos no acesso à rede são resolvidos através da arbitragem bit a bit dos

identificadores das mensagens. Cada Nó observa a rede bit a bit utilizando o

mecanismo "wired and", em que o estado dominante (0 lógico) se sobrepõe ao estado

recessivo (1 lógico). A competição pela alocação da rede é perdida por todos os Nós

que queiram enviar um bit recessivo, em favor dos que queiram transmitir um bit

dominante.

De referir ainda que todos os Nós perdedores se tornam imediatamente receptores da

mensagem com maior prioridade, e não fazem mais nenhuma tentativa enquanto a

rede não estiver livre. O método utilizado na arbitragem é baseado no CSMA/CD, mas

com a capacidade de não destruir a mensagem a enviar sempre que se verifica uma

colisão. Só assim se consegue que o sistema tenha um comportamento determinístico,

e se atinjam velocidades que permitam atingir o tempo real.

FIGURA 2: MÉTODO DE ARBITRAGEM

Como conclusão pode-se dizer que o CAN implementa uma alocação da rede

dependente do tráfico que permite, através duma política de acesso não destrutiva e de

um controlo de acesso descentralizado, atingir grandes taxas de transmissão com uma

utilização eficiente da rede. A eficiência do algoritmo de arbitragem aumenta pelo facto

da rede só ser utilizada por estações com mensagens pendentes. Todas as mensagens

são transmitidas seguindo a sua importância, o que se torna bastante relevante em

situações de sobrecarga do sistema.

FORMATO DAS TRAMAS CAN

O CAN utiliza pequenas mensagens (tramas) com um máximo de dados de 94 bits. Não

tem qualquer endereço explícito nas mensagens, sendo através do seu identificador que


Pag. 14 de 44

a estação receptora reconhece a mensagem. Este mecanismo denomina-se de

endereçamento orientado ao conteúdo.

O Can suporta dois tipos de tramas de Mensagens:

• O formato standard (versão 2.0A)

• O formato extendido (versão 2.0B)

Quase todos os controladores transmitem e recebem somente mensagens do tipo 2.0A,

no entanto existem alguns (conhecidos como 2.0B passivo) que recebem mensagens 2.0B

e se limitam a ignorá-las. Todos os controladores 2.0B podem receber e enviar

mensagens 2.0A e 2.0B.

FORMATO STANDAR D 2.0A

O formato da trama de mensagens standard é composto por sete campos principais.

Uma mensagem do tipo standard começa com o campo início de trama, um bit

dominante (0 lógico) que identifica o início da trama seguido pelo campo de

arbitragem que contém o identificador de 11 bits e o bit RTR (pedido de transmissão

remota), que indica se é uma trama de dados (se o bit for dominante), ou uma trama

de pedido (trama remota, se o bit for recessivo). Uma trama remota é emitida sempre

que um Nó necessita de informação de outro, não contendo qualquer informação no

campo de dados.

O campo de controlo contém o bit IDE (identificador de extensão), que indica se a

trama tem o formato standard (dominante), ou o formato extendido (recessivo),

seguido de um bit reservado para futuras extensões do formato. Os últimos 4 bits, DLC

(tamanho do dados), indicam o número de bytes no campo de dados. O campo de

dados contém a informação propriamente dita e varia de tamanho entre 0 e 8 bytes, é

seguido pelo campo de CRC. Este campo tem um tamanho de 15 bits e é usado para

detecção de erros. O campo ACK é constituído por dois bits. O primeiro bit é

transmitido com o valor recessivo, e o subsequentemente com o valor dominante por

todos os Nós que receberam a mensagem correctamente, independentemente do

resultado do teste de aceitação. O fim da mensagem é indicado pelo campo EOF que

consiste em sete bits recessivos.


Pag. 15 de 44

FIGURA 3: FRAME STANDARD (2.0A)

No final de cada trama são enviados 3 bits recessivos, designados intermissão, de

modo a separar duas tramas consecutivas, se nenhuma estação quiser aceder à rede,

ela fica inactiva.

FORMATO EXTENDIDO 2.0B

O formato de tramas extendido proporciona identificadores de 29 bits em oposição aos

11 bits do formato standard. Este novo identificador é constituído pelos 11 bits já

existentes (identificador base), seguido de uma extensão de 18 bits (extensão do

identificador), permitindo assim, o protocolo CAN com a coexistência dos dois

formatos.

A distinção entre os dois formatos é conseguida usando o bit IDE que é transmitido

dominante no caso da trama ter o formato standard e recessivo se a trama for do tipo

estendida. O bit RTR é substituído pelo bit SRR, sempre transmitido com o valor

recessivo de modo a assegurar a prioridade das tramas standard no caso da arbitragem

entre duas tramas de formato diferente e com o mesmo identificador base. Ao contrário

da versão 2.0A, na versão 2.0B o bit IDE é seguido pelo identificador de extensão de

18 bits, pelo bit RTR e por um bit reservado RB1. Todos os campos seguintes são

idênticos aos do da versão 2.0A.

FIGURA 4: FRAME ESTENDIDA (2.0B)


Pag. 16 de 44

COMPATIBILIDADE ENTRE 2.0A E 2.0B

O Protocolo CAN existe em duas versões, CAN 1.0 e CAN 2.0, O CAN 2.0 é

completamente compatível com a versão 1.0. A versão 2.0 tem duas variantes, a 2.0A

(standard) e a 2.0B (extensão). Tanto na versão 1.0 como na 2.0A os identificadores

têm 11 bits de comprimento, e na versão 2.0B podem ter tanto identificadores de 11

bits como identificadores de 29 bits. Por forma a manter a compatibilidade com as

versões anteriores, o 2.0B pode ser tanto do tipo passivo como activo.

A versão 2.0B passiva ignora todas as tramas do tipo extendido (com 29 bits de

identificador). Se for activa, permite o envio e recepção de qualquer mensagem

estendida, existindo algumas regras de compatibilidade:

• Os controladores CAN do tipo 2.0B activo podem enviar e receber tanto tramas

com o formato standard como com o formato extendido.

• Os controladores CAN 2.0B passivos enviam e recebem tramas standard,

ignorando as estendidas.

• Os controladores CAN 1.0 geram erros sempre que recebam uma trama com

formato extendido.

BIT TIMING

TEMPO DE B IT

Definido na norma ISO 11898, o tempo nominal de cada bit de uma mensagem é

composto por 4 segmentos de tempo não sobrepostos, como o apresentado na figura 5.

FIGURA 5: ALARGAMENTO DO TEMPO DE BIT

Sync-seg é o segmento usado para fazer a sincronização dos Nós da rede. É esperada

uma transição de recessivo para dominante durante este segmento.

Prop-seg é um período de tempo usado para compensar o atraso resultante do meio

físico da rede.

Phase-seg1 é um segmento buffer que pode ser alongado durante a re-sincronização,

de modo a compensar o impulso do oscilador e a diferença de fase positiva entre os

osciladores do transmissor e do receptor.


Pag. 17 de 44

Phase-seg2 é outro segmento de buffer que pode ser encurtado durante a

resincronização de modo a compensar os erros de fase negativa e o impulso do

oscilador.

O ponto de amostragem (sample) ocorre sempre no final do segmento phase-seg1,

sendo neste momento lida a rede e interpretado o valor do bit corrente.

Quer seja a transmitir ou a receber, todos os Nós têm o mesmo tempo de bit nominal,

o tempo de cada bit é programado em cada Nó da rede e é calculado em função do

oscilador local de cada Nó (valor que é introduzido no registo “BRP” do controlador de

cada Nó) e do número de "time quanta” por bit.

O registo “BRP” (Bit Rate Prescaler) é um dos requisitos da norma ISO 11898, e tem

que ser programado pelo utilizador com um valor inteiro entre 1 e 32.

Ao programarmos registos “BRP” individuais e o "time quanta” por bit com os valores

correctos, podemos ter Nós com osciladores a operar com frequências diferentes, a

funcionarem todos com o mesmo tempo de bit nominal.

Cada um dos 4 segmentos de tempo de um bit tem comprimento de um, ou mais "time

quanta”, pois a especificação da Bosch CAN2 refere:

Sync-seg é sempre programado com um "time quanta".

Prop-seg é programado com um valor entre 1 e 8.

Phase-seg1 é programado com um valor entre 1 e 8.

Phase-seg2 é programado com o valor máximo entre Phase-seg1 e o tempo de

processamento da informação.

S INCRONIZAÇÃO

Quando um qualquer Nó recebe uma trama de dados, é necessário que o receptor se

sincronize com o emissor. Como não existe nenhum impulso de clock explícito que o

CAN possa usar como referência, são utilizados dois mecanismos para manter a

sincronização:

Sincronização Dura - Ocorre dentro de cada controlador quando este está em modo

de recepção (e é detectada uma transição, de recessivo para dominante - falha no

campo de SOF).

Re-sincronização - de modo a compensar o impulso do oscilador e as diferenças de

fase entre o transmissor e o receptor, a re-sincronização aumenta ou diminui

automaticamente o tamanho do tempo de bit, dependendo de onde ocorre a transição

recessivo-dominante. O tamanho máximo que o tempo de bit pode ser alargado ou


Pag. 18 de 44

encurtado é definido pelo "time quanta", também conhecido como largura do salto de

sincronização - SJW.

Se a transição ocorrer tardiamente, isto é, se ocorrer depois do Sync-seg e antes do

ponto de amostragem, então o Phase-seg1 do bit é alargado tal como demonstrado na

figura 6.

FIGURA 6: ALARGAMENTO DO TEMPO DE BIT

Se a transição ocorrer demasiado cedo, isto é, se ocorrer durante o Phase-seg2 do

bit, o Phase-seg2 do bit corrente passa a ser encurtado tal como se demonstra na

figura 7.

FIGURA 7: ENCURTAMENTO DO TEMPO DE BIT


Pag. 19 de 44

ERROS

DETECÇ ÃO DE ER ROS

O tratamento dos erros foi implementado dentro do protocolo CAN e é de grande

importância para a performance final da rede. O objectivo do tratamento dos erros é

simplesmente a detecção de erros possíveis de ocorrer nas mensagens que aparecem

na rede, de modo a que o Nó transmissor possa retransmitir a mensagem corrigida.

Qualquer controlador presente na rede tenta encontrar erros na mensagem. Se for

descoberto algum erro, o Nó que o encontrou começa a transmitir uma trama de erro,

destruindo o tráfego existente na rede. Os outros Nós, por sua vez, vão detectar o erro

causado pela trama de erro e tomam a acção correcta, isto é, ignoram a mensagem

corrente.

A rede CAN tem 5 mecanismos de detecção de erros, 3 ao nível das mensagens e 2 ao

nível do bit.

Teste de redundância cíclico (CRC) - o CRC protege a informação da trama

acrescentando-lhe bits redundantes no final da transmissão, exactamente 15 bits.

Teste de Trama - existem certos bits com valores pré-definidos que têm que ser

transmitidos em certos pontos de uma mensagem CAN. Este mecanismo verifica se a

estrutura da trama a ser transmitida está correcta, efectuando comparações entre os

campos da trama e o formato fixo das mensagens CAN. Este tipo de erros são

designados por erros de formato.

Erros de confirmação - O protocolo CAN não utiliza mensagens de confirmação. Em

vez disso, assinala os erros que ocorrem. Assim, as tramas recebidas correctamente

são confirmadas por todos os Nós que as receberam através de uma confirmação

positiva. Nenhuma estação modifica o valor recessivo do bit de ACK. No caso de o

transmissor não receber nenhuma confirmação, é gerado um erro que pode ser devido

aos Nós receptores terem identificado um erro, ao campo ACK ter sido corrompido, ou

ao facto de não existirem quaisquer outras estações na rede.

Erros de monitorização - A capacidade do transmissor detectar erros é baseada na

monitorização da rede. Cada Nó ao transmitir um bit observa também o nível da rede

de modo a detectar diferenças entre o valor emitido e o valor recebido. Isto permite

uma detecção segura de todos os erros globais e locais ao transmissor.

Erros de bit stuffing - A codificação individual dos bits é testada ao nível do bit. A

representação escolhida pelo CAN (codificação NRZ) garante a máxima eficiência na

codificação dos bits, sendo as transições de sincronização geradas através da

introdução de um bit suplementar, a seguir a 5 bits consecutivos (todos do mesmo

valor) com o valor complementar ao do conjunto dos bits.

Se um, ou mais, erros forem descobertos por pelo menos uma estação usando os

mecanismos acima descritos, a transmissão actual é abortada e é enviada uma "error


Pag. 20 de 44

flag". Isto impede que outras estações aceitem uma mensagem errada e garante a

consistência dos dados ao longo de toda a rede.

CONFINAMENTO DE ERROS

O confinamento de erros é um mecanismo, até agora unicamente utilizado no CAN, que

permite discriminar erros temporários dos erros permanentes. Os erros temporários

podem ser causados por exemplo por fontes de tensão externas e picos de corrente. Os

erros permanentes têm causa mais provável nas más ligações, nos cabos partidos, e

nos transmissores ou receptores deficientes.

Cada Nó mantém 2 contadores de erros: o contador de erros ocorridos durante uma

transmissão e o contador de erros ocorridos durante uma recepção. Por cada erro

ocorrido durante a recepção é incrementada uma unidade ao contador de erros de

recepção, no entanto para os erros ocorridos durante a transmissão, são incrementadas

8 unidades ao contador de erros de transmissão, isto porque é mais provável ocorrer

um erro na estação que transmite a mensagem do que nas estações receptoras.

Os Nós funcionam num modo habitualmente conhecido como "error active". Nestas

condições, os Nós estão completamente funcionais, situando-se o valor de qualquer um

dos contadores, obrigatoriamente abaixo das 128 unidades.

Se qualquer um dos contadores exceder as 127 unidades, entra no modo "error

passive" - estado de alerta. Os Nós no modo "error passive" podem ainda transmitir

e receber mensagens, sendo, no entanto restringido o modo como estas fazem a

sinalização dos erros que detectam, uma vez que também é possível que sejam elas

próprias a origem do problema. Se mensagens correctas subsequentes fizerem o

contador baixar das 128 unidades, o Nó passa de novo para o modo "error active".

FIGURA 8: ESTADOS DE ERRO DE UM NÓ CAN

Se uma condição de erro persistir de modo a que o contador de erros de transmissão

atinja o valor de 255 unidades, a estação entra no modo "bus off", isto é, o dispositivo

cessa voluntariamente a sua actividade, sendo mantido o restante sistema em

funcionamento, embora com alguma degradação decorrente da indisponibilidade do Nó.


Pag. 21 de 44

DDEESSCCRRIIÇÇÃÃOO DDOO TTRRAABBAALLHHOO

As anteriores atribuições deste trabalho resultaram na escolha dos componentes a utilizar,

adequação das potencialidades do Nó face as expectativas e necessidades do cliente

considerando as possíveis aplicações, e a construção do mesmo incluindo a realização do

circuito impresso.

Partindo deste ponto definiu-se o objectivo de alcançar a troca de mensagens entre Nós

ligados ao barramento CAN, o qual necessitou da garantia de bom funcionamento do

hardware, para ser alcançado.

A satisfação deste requisito levou a uma revisão das ligações e a uma sequência de testes,

que embora já realizados no projecto anterior com o desenvolvimento de algumas rotinas

dedicadas ao teste de cada periférico, foram consideradas vantajosas pelo facto de ajudar

a compreensão da arquitectura do código existente facilitando desse modo a sua

adaptação ao código a desenvolver. Contudo, a comunicação com o controlador CAN

MCP2510 necessitou de uma maior atenção dado o grau de complexidade do seu

funcionamento.

A fase seguinte compreendeu a utilização de conhecimentos adquiridos nas primeiras

etapas para a implementação do protocolo CAN, as quais passaram pelos requisitos do

protocolo, pelo controlador CAN MCP2510 e funcionamento do microcontrolador utilizado

para gestão da informação e controlo dos Nós bem como dos seus periféricos.

Importante salientar o facto deste projecto promover a interacção de dois grupos de

trabalho com um objectivo comum que consiste em fazer a troca de informação entre a

rede CAN e a rede Ethernet baseada no protocolo TCP/IP, permitindo o controlo remoto do

sistema e a sua monitorização. Esta interacção obriga a que as soluções idealizadas para

cada um dos trabalhos (distintos) sejam compatíveis, nomeadamente a atribuição de

identificadores bem como a sequência de acções a tomar face ao significado da informação

contida nas mensagens.

PLANO DE TRABALHOS

• Estudo das especificações do protocolo CAN

• Estudo dos Nós da rede existentes

• Estudo da arquitectura do microcontrolador MC68HC705C9A

• Estudo da arquitectura do controlador CAN MCP2510

• Concepção de uma aplicação exemplificativa

• Desenvolvimento de código para implementação do protocolo

• Desenvolvimento de uma aplicação em LabView para configuração do MCP2510

• Proposta de soluções para optimização do sistema


Pag. 22 de 44

MATERIAL UTILIZADO

HARDWAR E

• Nós da empresa Microprocessador e Nos Evaboard do conjunto StarterKIT da

empresa I+ME

• Placa de simulação da Motorola M68HC705CICS

• Computador

• Analisador lógico Philips 3580

• Osciloscópio

• Multímetro digital

• Fonte de alimentação regulável

SOFTWARE

• Compilador Assembly CASM05Z

• Software Ultra Edit ou WinIDE para edição dos programas assembly

• Software ICS05CZ para controlar a placa de simulação

• LabView

IDEALIZAÇÃO DE UMA MAQUETA (ÁREA DE APLICAÇÃO)

Na concepção de uma aplicação com a finalidade de demonstrar a implementação do

protocolo CAN e o seu funcionamento, considerou-se a facilidade de representação em

maqueta bem como o nível de percepção do funcionamento do sistema. A decisão incidiu

sobre a domotica, salientando-se o facto de o protocolo CAN não ser propriamente

adequado para este tipo de aplicação, no entanto uma simulação sobre esta área facilita a

percepção da leitura e do controlo de variáveis analógicas e digitais.

As variáveis digitais presentes na maqueta são: alarme de incêndio, alarme de inundação,

alarme de intrusão, caixa de correio, humidade do jardim, iluminação interior e iluminação

exterior. Quanto a variáveis analógicas podem-se enumerar a temperatura, a luminosidade

exterior e velocidade da ventoinha.


Pag. 23 de 44

FIGURA 9: ESQUEMA DE LIGAÇÕES DOS NÓS CAN DA MICROPROCESSADOR

As variáveis digitais foram implementadas sob a forma de interruptores do tipo ON/OFF e

LED’s para visualização do estado da iluminação e funcionamento do sistema de rega.

Quanto às variáveis analógicas, o sensor de luminosidade foi implementado com um

potenciómetro existente no Nó A, a ventoinha foi ligada numa saída do tipo PWM

disponível no Nó B sendo necessário a implementação de um driver baseado em

transístores num circuito Darlington afim de minimizar o consumo de corrente, dado que

este sinal PWM provém directamente do microcontrolador do Nó CAN evitando-se o risco de

danificar o dispositivo.


Pag. 24 de 44

PWM do No B

Motor DC

12V

+

-

Q12N6427

30K

FIGURA 10: ESQUEMA DE LIGAÇÕES DO DRIVER DA VENTOINHA

A funcionalidade prevista para a monitorização da temperatura de um compartimento do

edifício necessitou da implementação de um sensor de temperatura e respectiva conversão

da grandeza analógica para digital.

O sensor implementado baseia-se no LM335, devendo-se referir que a montagem utilizada

visa simplesmente obter um sinal cuja sua tensão varia em função da temperatura, não

sendo do âmbito deste projecto a calibração do sensor e o estabelecimento adequado da

relação entre a temperatura e a tensão do sinal.

Para a conversão do sinal optou-se por uma montagem em que o resultado da conversão

esteja sempre disponível e actualizado num processo independente, utilizou-se por isso um

ADC0804 a funcionar em modo de conversão continua ‘free-running’ o qual gera um sinal

de interrupção que poderia ser aproveitado para que o MCU executasse uma rotina de

leitura.

20K

BC547B

5,6K

15V

Drive (x8)

<Value>

5V

10K

LM335

2K

238

12

Vin No CAN

150pF

5V

ADC0804

67

9

1112131415161718

19

20

4

51

23

+IN-IN

VREF/2

DB7DB6DB5DB4DB3DB2DB1DB0

CLKR

VCC/VREF

CLKIN

INTRCS

RDWR

20K

FIGURA 11: ESQUEMA DO SENSOR DE TEMPERATURA E DA CONVERSÃO A/D DO SINAL


Pag. 25 de 44

Seguiu-se a montagem da figura 11 onde /INTR activa o sinal /WR obrigando ao início de

uma nova conversão, ou seja, a conversão inicia-se logo após o termino da conversão

anterior sem necessidade de fornecer os sinais de controlo utilizados em modo normal,

sendo o valor binário à saída do dispositivo actualizado no fim de cada conversão.

O resultado das montagens referidas em conjunto com os nos e o respectivo bus CAN foi a

maquete apresentada na figura seguinte

FIGURA 12: MAQUETA DE SIMULAÇÃO DO CONTROLO DE UM EDIFÍCIO.


Pag. 26 de 44

EESSTTUUDDOO DDOO MMIICCRROOCCOONNTTRROOLLAADDOORR MMCC6688HHCC770055CC99AA

O microcontrolador MC68HC705C9A é um membro da família M68HC05 da Motorola, e

suporta as seguintes funcionalidades:

• interface de comunicação série (SCI)

• interface série para periféricos (SPI)

• timer de 16 bit com captura/comparação

• temporizador watchdog

• modos de funcionamento para economia de energia

• configuração do Porto B como pullups e interrupções

• 16 Kbytes de EPROM e 352 bytes de RAM

• 32 linhas bidireccionais de E/S, com capacidade de fornecer/absorver maiores

correntes no pino PC7

Este dispositivo possui o registo MOR2 que permite configurar as opções e funções para

emular o MC68HC705C9A ou o MC68HC05C12A. Optou-se pelo funcionamento original.

Quanto ao funcionamento do Porto B, configurou-se como porto E/S normal sem Pullup e

interrupções, no registo MOR1.

O registo OR (Option register) faz parte dos registos base que devem ser configurados de

forma a definir o funcionamento do dispositivo, neste caso escolhe-se as áreas de memória

da RAM e da EPROM dentro do conjunto de hipóteses predefinidas, configurando-se ainda o

tipo de sensibilidade do pino /IRQ. A configuração de memória escolhida foi RAM @ [$50,

$FF], ROM @ [$20,$4F] U [$0100,$3EFF] e o pino /IRQ sensível ao nível e aos flancos

ascendente e descendente do pulso fornecido para atendimento da interrupção externa

gerada.


Pag. 27 de 44

FIGURA 13: ARQUITECTURA DO MCU MC68HC705C9A

INTERRUPÇÕES

Este MCU pode ser interrompido por 5 fontes de interrupção diferentes, 4 delas

mascaráveis:

• Sinal externo no pino /IRQ ou nos pinos do Porto B

• Timer programável de 16 bits

• SPI

• SCI

• Instrução de interrupção por software (SWI)


Pag. 28 de 44

Quando terminada a execução de uma instrução o processador verifica todas as

interrupções de hardware pendentes. Se as interrupções não estão mascaradas, ou seja,

se o bit I do registo CCR está limpo, e se o correspondente bit de interrupção está

activo, o processador executa o processamento da interrupção, caso contrário procura a

próxima instrução e executa-a.

As interrupções são atendidas por ordem de prioridade associada a cada fonte de

interrupção, como se mostra na figura 14. Além de representadas, a fonte de interrupção

e a sua prioridade, estão as máscaras locais e globais de cada fonte de interrupção e o

respectivo endereço do vector de interrupção.

A vectorização da interrupção consiste em direccionar a interrupção para a rotina de

serviço à interrupção especificada pelo conteúdo dos dois bytes de endereço do

respectivo vector, por exemplo, a interrupção SCI será vectorizada para a ISR SCINT

porque esta foi especificada no conteúdo dos endereços $3FF6 e $3FF7 da memória, os

quais correspondem ao Vector SCI.

FIGURA 14: TABELA DE INTERRUPÇÕES

Neste trabalho foram utilizadas as interrupções de comunicação SCI e do Timer cujo a

sua descrição é feita no capítulo da estruturação do código. Quanto à interrupção SPI

nesta aplicação, não faz sentido ser utilizada, pois a comunicação processa-se a um

débito elevado, não se rentabilizando o processamento de outras tarefas em simultâneo.

Em relação à possível utilização das restantes fontes de interrupção, encontram-se

algumas considerações no capítulo de observações finais.


Pag. 29 de 44

PORTOS E/S

Os portos A, B e C são constituídos por 8 linhas de E/S cuja direcção pode ser

configurada nos registos DDRA, DDRB e DDRC. A configuração por defeito, atribuída

durante o RESET, define todos os pinos como entradas.

O Porto B tem capacidades de sensibilidade a interrupções e funcionamento como Pullup,

o Porto C tem capacidade de fornecer/absorver elevadas correntes no pino 7.

O Porto A foi atribuído às ligações com o teclado e o pino PA7 ao Chip Select da EEPROM

ficando PA0..3 e PA7 configurados como saídas, e os pinos PA4..6 como entradas. O

Porto B tem os pinos PB0..5 configurados como entradas para receber o estado das

variáveis associadas a cada um dos Nós, PB6 e PB7 como saídas para um LED presente

na placa de circuito impresso e para o Chip Select do MCP2520, respectivamente.

Os pinos do Porto C foram totalmente configurados como saídas, nomeadamente PC0..3

saídas do Nó e PC4..6 para fornecer os sinais de controlo, RS, R/W e E ao LCD, o pino

PC7 fornece o sinal de Strobe para a Latch.

Quanto ao Porto D também pode ser configurado como E/S excepto o pino 6 que serve

para gerar sinais quando se verifica igualdade na comparação do Timer. É neste porto

que se encontram os pinos dedicados às funcionalidades de comunicação oferecidas por

este microcontrolador, a comunicação SPI e SCI.

Os pinos dedicados à comunicação SCI devem ser configurados:

• PD0 (RDI) = entrada

• PD1 (TDO) = saída

do mesmo modo para a comunicação SPI tem-se que:

• PD2 (MISO) = entrada

• PD3 (MOSI) = saída

• PD4 (SCK) = saída

• PD5 (/SS) = entrada

• PD7 = entrada

TIMER

Este MCU possui funcionalidades de enorme utilidade a nível de temporização. O timmer

consiste num contador de 16 bit em free running, resolução do Timer com um cristal de

4 MHz é de 2 µs. O overflow do contador ocorre após 262144 ciclos de relógio interno.

A captura e comparação do Timer providenciam meios de se conhecer o instante a que

ocorrem eventos externos, de medir e gerar formas de onda ( ex. PWM ) e temporizar

atrasos.

A função de captura é um meio de guardar nos registos de captura o tempo a que

ocorreu um evento externo cuja polaridade do flanco do sinal pode ser programada. A


Pag. 30 de 44

captura em instantes de flancos com a mesma polaridade permite medir o período de um

sinal, e captura em instantes de flancos com polaridade diferente o que permite medir a

largura do pulso do sinal.

Por outro lado, a função de comparação permite efectuar uma temporização ou gerar um

sinal quando o valor do contador iguala o valor colocado nos registos de comparação.

Deste modo, quando ocorre uma igualdade o valor do bit OLVL presente no registo TCR é

colocado no pino TCMP.

Esta função pode ser utilizada na rotina de serviço à interrupção TIMINT de modo a

conseguir uma temporização mínima comum a todas as actividades temporizadas a

executar durante o funcionamento do sistema, criando deste modo uma base de tempo

que permite o processamento em simultâneo de actividades em background.

COMUNICAÇÃO SCI

A SCI (Serial Communications Interface) permite comunicação serie, full-duplex,

assíncrona, RS232 ou RS422 entre o MCU e dispositivos remotos incluindo outros MCUs.

Nesta aplicação utilizou-se a funcionalidade SCI para comunicar com um computador que

executa uma aplicação em LabView destinada a configurar o MCP2510 no que respeita

aos filtros e máscaras, Bit Timing e à divisão de frequência do oscilador do MCP2510 que

alimenta o microcontrolador. Importante referir que a dependência existente entre a

alteração da frequência do clock e a comunicação SCI (Baud Rate) obriga a que a

operação de alteração de frequência de clock altere também a configuração da

comunicação SCI quanto ao Baud Rate.

O registo BAUD permite seleccionar um dos 32 baud rates para a transmissão e

recepção.

A transmissão de dados é iniciada no momento em que se escreve um byte de dados

para o registo SCDR, activando o bit TDRE do registo SCSR quando SCDR estiver vazio

gerando também uma interrupção de transmissão.

Quando o registo SCDR é lido, contém o último byte recebido e a flag RDRF do SCSR é

activada para indicar que um byte de dados foi transferido para o registo SCDR. Também

pode ser gerada uma interrupção quando RDRF activa através do estado do respectivo bit

no registo SCCR2.

Se ocorrer algum erro na recepção de dados as flags de erro OR, NF ou FE presentes no

registo SCSR.

Na configuração utilizada escolheu-se a transmissão e recepção de mensagens, com 8

bits de dados @ 4800 bps, e permissão para interrupção de recepção.

COMUNICAÇÃO SPI

A comunicação SPI (Serial Peripheral Interface) é uma interface que permite a

comunicação série síncrona em Full-Duplex entre vários dispositivos na mesma placa de


Pag. 31 de 44

circuito impresso. Neste caso cada Nó comporta o MCU, uma latch, uma EEPROM e o

MCP2510 que comunicam via SPI.

Neste formato o sinal de clock é fornecido em separado das linhas de sinal de dados. Um

sistema SPI pode ser configurado como tendo um Mestre e vários Escravos, ou num

sistema em que o MCU é capaz de se comportar como mestre e como escravo.

O Bit Rate utilizado foi de 250 Kbps por ser suficiente para as comunicações a efectuar,

dado que esta medida depende da frequência de clock interno do MCU poder-se-ia

alcançar um máximo de 1 Mbps com um cristal de 4 MHz. A configuração desta

funcionalidade não englobou a permissão de interrupção pelo motivo referido no capitulo

das interrupções.

EESSTTUUDDOO DDOO CCOONNTTRROOLLAADDOORR DDEE CCAANN MMCCPP22551100

FUNCIONALIDADE

O MCP2510 é um Full Controller Área Network do tipo ‘Stand-Alone’, implementando a

especificação CAN V2.0 A/B. Possui três buffers de transmissão e dois de recepção, duas

máscaras de aceitação e um total de seis filtros de aceitação de mensagens.

A comunicação com o microcontrolador é implementada via SPI com taxas de

transmissão que podem atingir até 5 Mb/s. É com base neste protocolo que se efectuam

a leitura e escrita de todos os registos do controlador de CAN.

O MCP2510 é constituído por três blocos principais:

• Motor do protocolo CAN

• Lógica de controlo e registos SRAM, usados para configurar o dispositivo e o seu

modo de operação.

• Protocolo SPI


Pag. 32 de 44

FIGURA 15: ARQUITECTURA DO MCP2510

O motor do protocolo CAN assegura as funções para a transmissão/recepção de

mensagens bem como as funcionalidades de detecção/gestão de erros e lógica para

implementação do Bit Timing. Esta lógica proporciona segmentos de tempo programáveis

afim de compensar o tempo de atraso na propagação do sinal e shifts de fase, define

ainda o ponto de amostragem no intervalo de tempo que representa o tempo de bit.

Qualquer mensagem detectada no barramento CAN é inspeccionada para detecção de

erros, e comparada com os critérios de aceitação dos filtros, definidos pelo utilizador,

sendo movida para o buffer de recepção em questão se estes se verificarem. Para a

transmissão de mensagens é necessário carregar o buffer e configurar o respectivo

registo de controlo.

Este dispositivo está provido de pinos de interrupção que conferem uma melhoria de

flexibilidade do sistema. Dois pinos de interrupção específicos para cada registo de

recepção que podem ser usados para indicar quando uma mensagem válida é recebida e

carregada para um dos buffers de recepção, de outra forma poderia ser utilizado um pino

de interrupção geral que aliado ao acesso via SPI do registo Status permite determinar a

chegada de uma mensagem válida.


Pag. 33 de 44

MODOS DE OPERAÇÃO

O MCP2510 tem cinco modos de funcionamento seleccionados através dos bits REQOP do

registo CANCTRL, que se resumidos de seguida:

• Configuração – é automaticamente seleccionado após o Power-up ou Reset, para

se conseguir a partir de outro estado é necessário configurar os bits

RECOP=100. Existem registos cujo acesso está restringido a este modo, sendo

importante enumerar os registos dos filtros e máscaras de aceitação e os

registos de configuração do Bit Timing ( CNF1, CNF2, CNF3 ).

• Normal – é o estado de operação standard, no qual o dispositivo monitoriza

activamente todas as mensagens no barramento CAN e gera bits de

Aknowledge, frames de erro, etc. A transmissão de mensagens apenas é

possível neste modo.

• Sleep – é um modo de economia de energia através da paralisação do oscilado

interno. Este não pode ser utilizado, sob pena de se provocar uma paralisação

geral do sistema, dado no designa do circuito eléctrico do Nó se ter concebido

que o clock do sistema seria fornecido pelo MCP2510.

• Escuta – proporciona uma maneira de o MCP2510 receber todas as mensagens

incluindo mensagens com erros. Pode ser usado para aplicações de

monitorização da rede ou determinação de baud rate, sendo necessário que

outros dois Nós estejam a comunicar entre si.

Este pode ser designado por modo silencioso, porque o dispositivo não envia

qualquer mensagem, incluindo flags de erro ou sinais de Aknowledge.

• Loopback – permite a transmissão interna de mensagens dos buffers de

transmissão para os buffers de recepção, sem que a mensagem seja realmente

transmitida para o barramento. É utilizado nas fases de desenvolvimento e teste

de projectos.

BIT TIMING

O Bit Timing é implementado pelos registos CNF1, CNF2 e CNF3. Os bits BRP<5:0> do

registo CNF1, controlam o divisor de baud rate, ou seja, estes bits definem o

comprimento de Tq em relação à frequência do oscilado, sendo o mínimo comprimento de

Tq dois ciclos de relógio. Os bits SJW<1:0> seleccionam a largura do salto de

sincronização em termos de número de Tq’s.

No registo CNF2 encontram-se os bits PRSEG<2:0> que definem o número de Tq que

representam o segmento de propagação. O comprimento do segmento de fase 1 é

determinado pelos bits PHSEG1<2:0>, o bit SAM controla o número de vezes que o pino

RXCAN é amostrado. O bit BTLMODE controla como o segmento de fase 2 é

determinado.


Pag. 34 de 44

Quanto ao registo CNF3, é constituído pelos bits PHSEG2<2:0> que determinam o

comprimento do segmento de fase 2 em unidades de Tq.

O cálculo dos vários segmentos do tempo de bit e do factor de divisão da frequência de

clock para se obter a taxa de transmissão pretendida com base na frequência do

oscilador, é uma tarefa com uma certa complexidade. Felizmente começam a surgir

aplicações que facilitam de um modo considerável essa tarefa, não só calculando o bit

time, como fornecendo adicionalmente uma estimativa da taxa de erros na comunicação.

FIGURA 16: INTERFACE DO SOFTWARE MCP2510 BIT TIME CALCULATOR

O software utilizado foi ‘MCP2510 Bit Timing Calculator’ da empresa Intrepid Control

Systems, Inc. disponível em www.intrepidcs.com. Através deste encontraram-se várias

configurações possíveis dos registos CNF1, CNF2, CNF3 para os diferentes taxas de

transmissão descritas na figura 17.


Pag. 35 de 44

FIGURA 17: CONFIGURAÇÕES POSSIVEIS PARA O BIT TIMING

Importante referir que o bit time utilizado foi de 75 Kbs pois é o máximo suportado pelos

Nós CAN Evaboard, daí que os testes realizados para as restantes taxas de transmissão

tenham sido realizados sem a presença dos mesmos.


Pag. 36 de 44

TRANSMISSÃO DE MENSAGENS

Cada buffer de transmissão está associado a 14 bytes mapeados na memória do

dispositivo e que representam os registos de controlo, os registos dos identificadores de

mensagens standard e extendidas e os possíveis bytes de dados da mensagem a

transmitir.

Para que o MCU tenha acesso ao buffer de transmissão é necessário que o bit TXREQ do

registo de controlo TXBnCTRL esteja limpo, indicando que não existem mensagens

pendentes a serem enviadas. No mínimo é imprescindível que os registos TXBnSIDH,

TXBnSIDL e TXBnDLC sejam carregados para se processar uma mensagem standard. Se

a mensagem a enviar utiliza um identificador extendido, os registos TXBnEIDm devem

ser carregados e o bit EXIDE do registo TXBnSIDL setado.

A transmissão é iniciada por meio dos pinos que activam a transmissão (TXnRTS) ou por

alteração dos bits apropriados do registo de controlo, acessíveis via SPI.

Quando existem mensagens a transmitir pendentes, o buffer que será enviado primeiro é

determinado pelo esquema de prioridades definido pelos bits TXP<1:0> do registo

TXBnCTRL. Se dois buffers tem o mesmo grau de prioridade, o buffer com de índice

maior será enviado primeiro.

O MCU pode pedir o cancelamento do envio de uma mensagem a qualquer buffer

bastando limpar o respectivo bit TXBnCTRL.TXREQ. Também se pode pedir o

cancelamento de todas as mensagens setando o bit CANCTRL.ABAT, surgindo deste

modo uma flag ABTF no mesmo registo.

RECEPÇÃO DE MENSAGENS

Os dois buffers recebem as mensagens que satisfazem os critérios de aceitação dos

filtros, originando que a flag CANINTF.RxnIF seja activada. Esta tem a finalidade de

indicar que a mensagem está pronta a ser processada pelo MCU e também evita que esta

seja sobreposta, sendo necessário que o MCU limpe esta flag no fim de processamento

para possibilitar a recepção de nova mensagem.

O número reduzido de filtros associados ao RXB0 torna-o mais restritivo e implica ma

maior prioridade para este buffer. O registo CANCTRL pode ser configurado de modo a

que se o buffer 0 já contém uma mensagem e chega uma nova mensagem válida, não

ocorra erro de sobreposição e a nova mensagem será movida para a o buffer RXB1

independentemente dos critérios de aceitação dos filtros do buffer RXB1.

Este dispositivo possui os pinos /RX0BF e /RX1BF que podem ser usados para indicar

que uma mensagem válida foi carregada para o RXB0 e RXB1 respectivamente.


Pag. 37 de 44

FIGURA 18: TABELA DOS IDENTIFICADORES UTILIZADOS

A figura x representa a atribuição de identificadores para cada mensagem utilizada na

aplicação, obtida em concordância com o grupo ‘Gateway CAN’. Esta atribuição seguiu o

critério de menor identificador para a mensagem de maior importância pelas razões

expostas na breve abordagem ao protocolo CAN.

Foram também definidos os filtros de aceitação correspondentes a cada mensagem, assim

como os buffers de transmissão.

INTERRUPÇÕES

O MCP2510 tem oito fontes de interrupção, cuja permissão de ocorrência é configurada

individualmente no registo CANINTE, estas são relativas:

• Transmissão – ocorre quando o respectivo buffer fica vazio e disponível para ser

carregado por uma nova mensagem.

• Recepção – ocorre quando uma mensagem é recebida com sucesso e transferida

para o respectivo buffer de recepção.

• Erro - é activada quando ocorrem erros de transmissão ou recepção de

mensagens.

• Actividade do barramento – quando o MCP2510 está no modo Sleep e a

actividade no barramento interrompe esse estado.


Pag. 38 de 44

• Erro de interrupção –ocorre quando se verifica uma situação de overflow ou

alteração do estado do transmissor ou do receptor, a informação relativa ao

estado encontra-se no registo EFLG.

• Acknowledge – as interrupções estão associadas a um ou mais flags de estado

presentes no registo CANINTF. Estas ficam pendentes enquanto uma flag esteja

activa. Após uma flag de interrupção activada, esta não pode ser limpa pelo

MCU enquanto a condição que gerou a interrupção não seja retirada.

O registo CANINTF contém as respectivas flag’s para cada fonte de interrupção, e no

registo CANSTAT é indicado qual a fonte de interrupção de maior prioridade que está

pendente, através dos bits ICOD.

Quando ocorre uma interrupção o pino /INT é colocado ao nível lógico 0 e permanecerá

nesse estado até que a interrupção seja limpa pelo MCU. Contudo, a interrupção não

poderá ser limpa se a respectiva condição prevalece.

É recomendado que se utilize a instrução Bit Modify para limpar a flag de interrupção no

registo CANINTF.

EESSTTRRUUTTUURRAAÇÇÃÃOO DDOO CCÓÓDDIIGGOO

Para a implementação das acções de controlo e monitorização dos periféricos, a efectuar

pelo microcontrolador, utilizou-se a linguagem de programação Assembly. A emulação do

código objecto resultante da assemblagem conseguida com CASM05 (fornecido pela

Motorola), é feita apartir da placa de simulação M68HC705CICS.

A placa M68HC705CICS é comandada pela interface de simulação ICS05CZ (In-Circuit

Simulator Interface), apresentada na figura 18, a qual se tornou imprescindível no

desenvolvimento do software para as aplicações baseadas no microcontrolador

MC68HC705C9A da família HC05 da Motorola. Em simultâneo pode concluir-se que ao nível

de hardware, a simulação In-Circuit é problemática dado não haver qualquer tipo de

isolamento entre os sinais presentes no circuito ‘Alvo’ e os microcontroladores da placa de

simulação, podendo o mau funcionamento do mesmo circuito danificar a placa de

simulação.


Pag. 39 de 44

FIGURA 19: SNAPSHOT DO AMBIENTE DE SIMULAÇÃO ICS05CZ

De seguida são enumeradas as rotinas utilizadas nesta aplicação, acompanhadas de uma

breve descrição, sendo possível consultar o respectivo fluxograma bem como excertos do

código no Manual do Utilizador em anexo.

FFUUNNÇÇÃÃOO NNOOMMEE DDEESSCCRRIIÇÇÃÃOO

Rotina de inicialização

do MCU ‘INI.asm’

Inicializa a direcção dos portos e o estado, Timer,

SPI, SCI, EEPROM, LCD, variáveis utilizadas no

programa e define o modo de inicialização do

MCP2510.

Rotina principal

‘MAIN_X.asm’

‘MAIN_Y.asm’

Invoca a sub-rotina de detecção de erros na

recepção, verifica se o estado das variáveis alterou,

envia mensagens com a detecção de erros na

transmissão e verifica teclado.


Pag. 40 de 44

Rotinas de Serviço a

Interrupções

‘TIMINT.asm’

‘SCINT.asm’

TIMINT pode ser utilizada para criar uma base de

tempo. A rotina SCINT implementa a comunicação

entre o MCU e um PC para transferir a informação

utilizada na configuração do MCP2510, armazenada

na EEPROM X25138.

Leitura / Escrita da

EEPROM X25138

‘R_E2PROM.asm’

‘W_E2PROM.asm’

Rotinas utilizadas para a troca de dados entre o

MCU e a EEPROM, sob a forma de dois bytes de

endereçamento do registo de oito bits e um byte de

dados.

Operação do controlador

de CAN MCP2510

‘INI_MCP.asm’

‘TBL2MCP.asm’

‘BIT_MDFY.asm’

‘R_MCP.asm’

‘W_MCP.asm’

Durante a execução da inicialização do INI.asm é

seleccionado um dos modos de configuração do

MCP2510, INI_MCP.asm configuração apartir da

EEPROM ou TBL2MCP.asm para configuração apartir

do MCU. As restantes rotinas implementam a troca

de informação entre o MCU e o MCP2510,

nomeadamente a leitura e escrita de registos e a

instrução Bit Modify altera um dado bit do registo.

Recepção de mensagens

CAN

‘MSG_RCV_B0.asm’

‘MSG_RCV_B1.asm’

Definem as acções a tomar quando se recebe uma

mensagem através de um filtro dos buffers de

recepção 0 e 1, respectivamente.

Envio de mensagens

CAN ‘MSG_SEND.asm’

Envia mensagens CAN, onde o identificador e os

dados são definidos em variáveis bem como o buffer

que transmite a mensagem.

Detecção de erros

‘RXERR_DET.asm’

‘TXERR_DET.asm’

Consultam os resultados da operação do mecanismo

de detecção de erros do protocolo CAN e imprimem

uma mensagem de erro no LCD.

Operação do LCD ‘SEND2ROWS.asm’ Imprime uma mensagem de 32 caracteres no LCD,

dispostos em duas linhas de 16 caracteres.

Comunicação SPI ‘SPI.asm’

Implementa a funcionalidade de comunicação série

síncrona entre os periféricos contidos na placa de

circuito impresso.

Comunicação SCI

‘GETDATA.asm’

‘SENDATA.asm’

Implementa a funcionalidade de comunicação série

assíncrona entre o MCU e um PC .

Gestão do teclado ‘KEYPAD.asm’

Executa a detecção e descodificação de tecla

premida, atribuindo um valor para a sua posição na

matriz.


Pag. 41 de 44

AAPPLLIICCAAÇÇÃÃOO EEMM LLAABBVVIIEEWW PPAARRAA CCOONNFFIIGGUURRAAÇÇÃÃOO DDOO MMCCPP22551100

Esta aplicação foi idealizada com o intuito de facilitar a configuração do controlador CAN de

um Nó ligado à rede e em funcionamento, através da comunicação série assíncrona com o

microcontrolador, nomeadamente:

• Modo de configuração • Filtros • Transmissão

• Bit Timming • Mascaras • Recepção

• Selecção do Clockout • Interrupção

FIGURA 20: INTERFACE PRINCIPAL DA APLICAÇÃO LABVIEW

Depois de estabelecida a ligação e de se iniciar a execução da aplicação o microcontrolador

recebe os primeiros caracteres entrando na rotina de serviço a interrupção da comunicação

série SCINT.

Durante toda a configuração a informação recebida sob a forma par endereço-valor é

guardado na memória EEPROM externa. O fim de configuração é anunciado com os

caracteres especiais, sendo confirmada a saída com o caracter ‘@’ enviada no termino da

aplicação.


Pag. 42 de 44

OOBBSSEERRVVAAÇÇÕÕEESS FFIINNAAIISS

No funcionamento dos Nós CAN da empresa Microprocessador é evidente uma relação de

dependência entre o controlador CAN e o MCU, dado que este efectua uma constante

monitorização do MCP2510, resultando na degradação da performance.

Dado a diversidade de equipamentos que incorporam vários tipos de sensores e

actuadores, seria interessante projectar um Nó CAN com uma configuração base e que

seja flexível na interligação com módulos de características variadas no ponto de vista

funcional, por exemplo módulos que ofereçam a funcionalidade de conversão de sinal A/D e

D/A.

PROBLEMAS DETECTADOS

Quando o Nó CAN está completamente fechado o circuito de alimentação dos circuitos

integrados deixa de funcionar correctamente devido ao calor gerado pela potência

dissipada no regulador de tensão 7805. O aumento da temperatura leva a um

abaixamento de tensão de saída do regulador, originando a paralisação do Nó CAN.

PROPOSTAS PARA MELHORIAS/ALTERAÇÕES FUTURAS

Aproveitar os sinais descritivos do estado do MCP (INT, TXnRTS, RXnBF) afim de criar

independência entre o MCU e o MCP2510, conseguindo um aumento das performances do

sistema ao nível das funcionalidades dos Nó CAN. Se fôr crítica a disponibilidade de

sinais E/S no MCU pode-se recorrer a utilização latch SPI ou a uma PPI (Programable

Port Interface).

Uma funcionalidade interessante do Porto B é o facto de os seus pinos poderem ser

configurados individualmente como fontes de interrupção, os quais poderiam ser

associados aos sinais de interrupção presentes no sistema, nomeadamente os sinais do

controlador CAN.

Ainda no capítulo das performances, no seu sentido directo, pode-se referir que a

melhoria de desempenho passa pelo aumento da frequência de clock para 4 MHz, através

da configuração apropriada do controlador CAN, e que seria o próximo passo a realizar

no desenvolvimento do software da aplicação.

Dado que o MCU funciona como master não haverá necessidade de ser identificado como

slave, pois no sistema nenhum outro dispositivo funcionará como master, então o pino

/SS pode ser seleccionado para funcionar como saída setando o bit 5 do DDR do porto D.

O circuito que gera o sinal de RESET deveria incluir um interruptor de modo a fornecer o

sinal que efectua a reinicialização do sistema sem necessidade de desligar a alimentação.


Pag. 43 de 44

CCOONNCCLLUUSSÕÕEESS

Este projecto proporcionou o aprofundar de conhecimentos sobre redes de campo em

especial sobre o CAN, bem como Internet e aplicações de controlo remoto baseadas nesta.

Permitiu também o estudo e aplicação de diferentes linguagens de programação como o

Assembly e LabView.

A utilização dos diferentes componentes que constituem o hardware, tais como: o

controlador CAN Microchip MCP2510, o microcontrolador Motorola MC68HC705C9A, a

memória Xilinx X25138, proporcionou uma visão alargada das implementações existentes

no mercado.

O CAN revelou-se uma ferramenta bastante poderosa, com possibilidades de expansão e

com uma implementação no mercado que nos fez acreditar que será a primeira escolha

para aplicações de Automação.

Foi interessante trabalhar num grupo de pessoas provenientes de dois ramos da nossa

licenciatura (APEL e TEC), com ambas as equipas a caminhar para um objectivo comum,

que pensamos ter sido atingido.


Pag. 44 de 44

RREEFFEERRÊÊNNCCIIAASS

http://www.can-cia.com.....................CAN Protocol

http://www.Kvaser.com

http://www.cankingdom.com

http://www.odva.com

http://www.Vector.com

http://www.interpidcs.com..................MCP2510 (Bit Timing)

http://www.microchip.com..................MCP2510 (Data Sheet / Application Notes)

http://www.mot.com..........................MC68HC705C9A (Data Sheet / Application Notes)

AANNEEXXOOSS

MANUAL DO UTILIZADOR

Documents

Pedro Miguel dos Reis Caldeira - web.fe.up.ptee99058/projecto/relatorios/relatorio_n.pdf · Este projecto tem como objectivo a implementação de uma rede CAN com características