pedro miguel dos reis caldeira - web.fe.up.ptee99058/projecto/relatorios/relatorio_n.pdf · este...
TRANSCRIPT
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.
FACULDADE DE ENGENHA RIA DA UNIVERSIDA DE DO PORTO
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.
DESENVOLVIMENTO DE SOFTWA R E DE APLICA ÇÃO PA RA REDES CAN
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.
FACULDADE DE ENGENHA RIA DA UNIVERSIDA DE DO PORTO
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.
DESENVOLVIMENTO DE SOFTWA R E DE APLICA ÇÃO PA RA REDES CAN
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
FACULDADE DE ENGENHA RIA DA UNIVERSIDA DE DO PORTO
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
DESENVOLVIMENTO DE SOFTWA R E DE APLICA ÇÃO PA RA REDES CAN
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.
FACULDADE DE ENGENHA RIA DA UNIVERSIDA DE DO PORTO
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)
DESENVOLVIMENTO DE SOFTWA R E DE APLICA ÇÃO PA RA REDES CAN
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.
FACULDADE DE ENGENHA RIA DA UNIVERSIDA DE DO PORTO
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
DESENVOLVIMENTO DE SOFTWA R E DE APLICA ÇÃO PA RA REDES CAN
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
FACULDADE DE ENGENHA RIA DA UNIVERSIDA DE DO PORTO
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
DESENVOLVIMENTO DE SOFTWA R E DE APLICA ÇÃO PA RA REDES CAN
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ó.
FACULDADE DE ENGENHA RIA DA UNIVERSIDA DE DO PORTO
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
DESENVOLVIMENTO DE SOFTWA R E DE APLICA ÇÃO PA RA REDES CAN
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.
FACULDADE DE ENGENHA RIA DA UNIVERSIDA DE DO PORTO
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.
DESENVOLVIMENTO DE SOFTWA R E DE APLICA ÇÃO PA RA REDES CAN
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
FACULDADE DE ENGENHA RIA DA UNIVERSIDA DE DO PORTO
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.
DESENVOLVIMENTO DE SOFTWA R E DE APLICA ÇÃO PA RA REDES CAN
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.
FACULDADE DE ENGENHA RIA DA UNIVERSIDA DE DO PORTO
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)
DESENVOLVIMENTO DE SOFTWA R E DE APLICA ÇÃO PA RA REDES CAN
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.
FACULDADE DE ENGENHA RIA DA UNIVERSIDA DE DO PORTO
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
DESENVOLVIMENTO DE SOFTWA R E DE APLICA ÇÃO PA RA REDES CAN
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
FACULDADE DE ENGENHA RIA DA UNIVERSIDA DE DO PORTO
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
DESENVOLVIMENTO DE SOFTWA R E DE APLICA ÇÃO PA RA REDES CAN
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.
FACULDADE DE ENGENHA RIA DA UNIVERSIDA DE DO PORTO
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.
DESENVOLVIMENTO DE SOFTWA R E DE APLICA ÇÃO PA RA REDES CAN
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.
FACULDADE DE ENGENHA RIA DA UNIVERSIDA DE DO PORTO
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.
DESENVOLVIMENTO DE SOFTWA R E DE APLICA ÇÃO PA RA REDES CAN
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.
FACULDADE DE ENGENHA RIA DA UNIVERSIDA DE DO PORTO
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.
DESENVOLVIMENTO DE SOFTWA R E DE APLICA ÇÃO PA RA REDES CAN
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.
FACULDADE DE ENGENHA RIA DA UNIVERSIDA DE DO PORTO
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.
DESENVOLVIMENTO DE SOFTWA R E DE APLICA ÇÃO PA RA REDES CAN
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.
FACULDADE DE ENGENHA RIA DA UNIVERSIDA DE DO PORTO
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.
DESENVOLVIMENTO DE SOFTWA R E DE APLICA ÇÃO PA RA REDES CAN
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.
FACULDADE DE ENGENHA RIA DA UNIVERSIDA DE DO PORTO
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.
DESENVOLVIMENTO DE SOFTWA R E DE APLICA ÇÃO PA RA REDES CAN
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