UNIVERSIDADE DO ESTADO DE SANTA CATARINA – UDESC CENTRO DE CIÊNCIAS TECNOLÓGICAS – CCT DEPARTAMENTO DE ENGENHARIA ELÉTRICA – DEE PÓS-GRADUAÇÃO EM AUTOMAÇÃO INDUSTRIAL – PGAI Formação: Mestrado em Automação Industrial DISSERTAÇÃO DE MESTRADO OBTIDA POR Ste

Livre

0
0
207
1 year ago
Preview
Full text

  

UNIVERSIDADE DO ESTADO DE SANTA CATARINA – UDESC

CENTRO DE CIÊNCIAS TECNOLÓGICAS – CCT

DEPARTAMENTO DE ENGENHARIA ELÉTRICA – DEE

PốS-GRADUAđấO EM AUTOMAđấO INDUSTRIAL Ố PGAI

  

Formação: Mestrado em Automação Industrial

DISSERTAđấO DE MESTRADO OBTIDA POR

  

Stefano Romeu Zeplin

DESENVOLVIMENTO DE UMA REDE CAN UTILIZANDO

DSPS

  Apresentada em 30/04/2004 perante a Banca Examinadora: Prof. Dr. Antônio Heronaldo de Sousa – Orientador – CCT/UDESC

  • – Cesar Albenes Zeferino CTTMar/ UNIVALI Prof. Dr.

  Prof. Dr. Alcindo do Prado Júnior – CCT/UDESC Prof. Dr. Marcello Mezaroba – CCT/UDESC

  

UNIVERSIDADE DO ESTADO DE SANTA CATARINA – UDESC

CENTRO DE CIÊNCIAS TECNOLÓGICAS – CCT

DEPARTAMENTO DE ENGENHARIA ELÉTRICA – DEE

PốS-GRADUAđấO EM AUTOMAđấO INDUSTRIAL Ố PGAI

  

DISSERTAđấO DE MESTRADO

Mestrando: STEFANO ROMEU ZEPLIN – Engenheiro Eletricista

Orientador: Prof. Dr. ANTONIO HERONALDO DE SOUSA – CCT/UDESC

  

DESENVOLVIMENTO DE UMA REDE CAN

UTILIZANDO DSPS

  Dissertação submetida à Universidade do Estado de Santa Catarina como parte dos requisitos para a obtenção do grau de Mestre em Automação Industrial.

  

Joinville

  UNIVERSIDADE DO ESTADO DE SANTA CATARINA - UDESC CENTRO DE CIÊNCIAS TECNOLÓGICAS – CCT COORDENAđấO DE PốS-GRADUAđấO - CPG

"Desenvolvimento de uma rede CAN utilizando DSPs"

  por

  

Stefano Romeu Zeplin

Essa dissertação foi julgada adequada para a obtenção do título de

  MESTRE EM AUTOMAđấO INDUSTRIAL área de concentração em "Automação e Informática Industrial", e aprovada em sua forma final pelo

  CURSO DE MESTRADO EM AUTOMAđấO INDUSTRIAL CENTRO DE CIÊNCIAS TECNOLÓGICAS DA

  UNIVERSIDADE DO ESTADO DE SANTA CATARINA

  Dr. Antônio Heronaldo de Sousa (presidente) Banca Examinadora: Joinville, 30 de Abril de 2004

  Dr. Cesar Albenes Zeferino (UNIVALI) Dr. Alcindo do Prado Júnior FICHA CATALOGRÁFICA

  NOME: ZEPLIN, Stefano Romeu DATA DA DEFESA: 30/04/2004 LOCAL: Joinville, CCT/UDESC

NÍVEL: Mestrado Número de ordem: 16 – CCT/UDESC

FORMAđấO: Automação Industrial ÁREA DE CONCENTRAđấO: Automação e Informática Industrial TÍTULO: Desenvolvimento de uma Rede CAN Utilizando DSPs PALAVRAS - CHAVE: Rede CAN; DSP. NÚMERO DE PÁGINAS: xvii, 223 p. CENTRO/UNIVERSIDADE: Centro de Ciências Tecnológicas da UDESC PROGRAMA: Pós-Graduação em Automação Industrial - PGAI CADASTRO CAPES: ORIENTADOR: Dr. Antônio Heronaldo de Sousa PRESIDENTE DA BANCA: Dr. Antônio Heronaldo de Sousa MEMBROS DA BANCA: Dr. Cesar Albenes Zeferino

  Dr. Alcindo do Prado Júnior Dr. Marcello Mezaroba

  Resumo da Dissertação apresentada à UDESC como parte dos requisitos necessários para obtenção do grau de Mestre em Automação Industrial.

  

DESENVOLVIMENTO DE UMA REDE CAN UTILIZANDO DSPS

Stefano Zeplin

  Abril/2004 Orientador: Antônio Heronaldo de Sousa, Dr.

  Área de Concentração: Automação e Informática Industrial. Palavras-chave: Rede CAN, DSP, AGV. Número de Páginas: 223

  Nos últimos anos, cresceu a adoção da tecnologia dos processadores digitais de sinais (DSPs) em uma variedade de aplicações de controle embarcado. Além do poder de processamento, a tecnologia de automação moderna é caracterizada também pelo crescimento da descentralização do processamento de dados. Mas, a necessidade de comunicação entre os diferentes sistemas tem levado também ao desenvolvimento de meios de comunicação mais eficientes, como a Rede CAN (Controller Área Network), que foi inicialmente criada pela empresa Bosch, no meado dos anos 80, como um sistema para propiciar uma comunicação serial robusta para aplicações automotivas.

  Neste trabalho discute-se o desenvolvimento da comunicação entre sistemas embarcados baseados nas duas camadas da rede CAN. Para tanto, foi desenvolvida uma rede CAN utilizando-se DSPs, onde o modelo utilizado já tem um controlador CAN incorporado, e, para validação do trabalho, foi desenvolvida uma aplicação da rede para utilização em um Veículo Guiado Automaticamente (Automatic Guidance Vehicles - AGV). Para essa aplicação foram selecionadas algumas funções mais elementares de um AGV, as quais foram emuladas na rede formada por DSPs através do desenvolvimento de bibliotecas específicas. Abstract of Dissertation presented to UDESC as a partial fulfillment of requirements for the degree of Master in Industrial Automation.

  

DEVELOPMENT OF A CAN NETWORK USING DSPS

Stefano Zeplin

  April/2004 Advisor: Antônio Heronaldo de Sousa, Dr.

  Area of Concentration: Industrial Informatics and Automation. Keywords: CAN Network; DSP, AGV. Number of Pages: 223

  In recent years, there has been a major adoption of digital signal processors (DSPs) technology in a variety of embedded control applications. Typical industrial applications include high-performance servo drivers in applications like machine tools and robotics. Beyond the processing power, modern automation technology is characterized by increasing decentralization of data processing. But, the necessity of communication between the different systems has also led to the development of medias more efficient as Controller Area Network (CAN Network), that was initially created by Robert Bosch in the mid-1980s for automotive applications as a method for enabling robust serial communication.

  In this work, the development of the communication between embedded systems based in the two layers of CAN network is argued. For in such a way, a CAN network using DSPs was developed and, for validation of the work, an application of the network in Automatic Guidance Vehicles (AGVs) was developed. Where some of its more elementary functions, which had been emulated in the net formed for DSPs, through the development

  Toda grande caminhada começa com o primeiro passo.

  (Gandhi)

  O êxito começa no exato momento em que o homem decide o que quer e começa a trabalhar para conseguí-lo.

  A Deus,

à minha esposa Marciléia,

aos meus pais, e

  

Agradecimentos

Agradeço a Deus por me guiar durante toda a minha trajetória e permitir a lucidez

necessária para aprender com as dificuldades que enfrentamos todo o dia;

  Agradeço, também, ao professor Antônio Heronaldo de Sousa, por sua orientação, paciência, e principalmente por sua confiança no trabalho desenvolvido; Aos colegas da UDESC, em especial aos do Departamento de Engenharia Elétrica e do

curso de Automação Industrial pela convivência e companheirismo;

  À minha esposa, Marciléia Volkmann Zeplin, por sua compreensão, paciência e cujo companheirismo tornou esta jornada possível ;

Agradeço ao bolsista Rodrigo Gastaldi pelas contribuições durante a elaboração do

projeto.

  

Sumário

  

1 Introdução .......................................................................................................................... 1

  1.1 Evolução dos sistemas digitais .................................................................................. 1

  1.2 Necessidade de comunicação em sistemas embarcados ............................................. 2

  1.4 Desenvolvimento de protocolos baseados nas duas camadas da rede CAN ............... 2

  1.5 Formulação do Problema ............................................................................................ 3

  1.5 Organização da Dissertação........................................................................................ 5

  

2 Rede CAN ........................................................................................................................... 6

  2.1 Introdução ................................................................................................................... 6

  2.2 Histórico ..................................................................................................................... 6

  2.3 Estrutura da rede CAN .............................................................................................. 7

  2.3.1 Princípio de funcionamento da rede CAN .................................................... 8

  2.4 O padrão de comunicação ISO/OSI ......................................................................... 11

  2.5 Camada de Enlace .................................................................................................... 13

  2.5.1 Tipos de Mensagens ................................................................................... 13

  2.5.2 Tratamento de erros na rede CAN .............................................................. 21

  2.6 Camada Física ............................................................................................. 22

  2.6.1 Configuração de um nó de um barramento CAN ....................................... 23

  2.6.2 Características do Meio Físico ................................................................... 24

  2.6.3 Transceiver CAN ........................................................................................ 26

  2.6.4 Controlador CAN ....................................................................................... 27

  2.6.5 Representação do Bit .................................................................................. 29

  2.6.6 Temporização e Sincronização do Bit ........................................................ 29

  

3 Processador Digital de Sinal ............................................................................................ 31

  3.1 Introdução ................................................................................................................ 31

  3.2 Evolução e Características dos DSPs ....................................................................... 31

  3.5 Critérios para a Seleção de um DSP ......................................................................... 33

  3.6 Famílias de DSPs da Texas Instruments .................................................................. 35 3.7 O DSP TMS320LF2407 ...........................................................................................

  35

  3.7.1 Arquitetura do DSP TMS320F2407 ........................................................... 36

  3.7.2 Interrupção .................................................................................................. 55

  3.8 Programação do TMS320LF2407 ............................................................................ 58

  3.8.1 Etapas de Desenvolvimento de um Programa ............................................ 58

  3.8.2 Estrutura de um Programa em Assembly ................................................... 59

  3.8.3 Modos de Endereçamento .......................................................................... 60

  3.9 Controlador CAN do DSP TMS320LF2407 ............................................................ 63

  3.9.1 Arquitetura do controlador CAN ................................................................ 63

  3.9.2 Mapa de Memória do Controlador CAN .................................................... 64

  3.9.3 Registradores do Controlador CAN ........................................................... 65

  3.9.4 Mailbox ....................................................................................................... 67

  

4 Montagem e Testes Básicos cam a rede CAN ................................................................ 70

  4.1 Introdução ................................................................................................................ 70

  4.2 Plataforma de Desenvolvimento ............................................................................... 70

  4.3 Configuração do DSP ............................................................................................... 73

  4.4 Montagem de um Nó ................................................................................................ 76

  4.5 Processo de Configuração de Parâmetros da Rede CAN ......................................... 77

  4.6 Processo de Transmissão de Dados .......................................................................... 80

  4.6.1 Algoritmo para Carga de Dados em Mailbox ............................................ 80

  4.6.2 Algoritmo para Transmissão de Dados em Mailbox ................................. 83

  4.7 Processo de Recepção de Dados .............................................................................. 85

  4.7.1 Configura Mailbox para Recepção ........................................................... 85

  4.7.2 Recepção de Mensagens ............................................................................ 88

  4.8 Testes para Validação Inicial da Rede CAN ........................................................... 89

  5.2 Veículo Guiado Automaticamente...... ..................................................................... 99

  5.2.1 Componentes de um AGV ....................................................................... 101

  5.3 Definição das Características do Sistema Poroposto .............................................. 105

  5.4 Geração de Mensagens ........................................................................................... 109

  5.4.1 Critérios para obtenção das mensagens .................................................. 109

  5.5 Agrupamento de Mensagens .................................................................................. 110

  5.6 Geração dos bits identificadores de cada Mensagem ............................................ 112

  5.7 Detalhamento das Mensagens Recebidas e Enviadas por cada Nó ..................... 116

  5.8 Obtenção da máscara de cada nó .......................................................................... 116

  5.9 Desenvolvimento do Algoritmo para cada nó ...................................................... 117

  5.9.1 Nó 1 – Sensor de Segurança ................................................................... 118

  5.9.2 Nó 2 – Nível de Bateria .......................................................................... 123

  5.9.3 Nó 3 – Acionamento ............................................................................... 129

  5.9.4 Nó 4 – Navegação ................................................................................... 133

  5.9.5 Nó 5 – Módulo de Gerenciamento ......................................................... 139

  5.10 Testes para Validação do Conjunto Final .............................................................. 145

  

6 Conclusões e Trabalhos Futuros ................................................................................... 153

  6.1 Propostas de Trabalhos Futuros ............................................................................. 155

  

A Detalhamento das Mensagens ....................................................................................... 157

B Programas de Teste Padrão ......................................................................................... 164

C Programas de cada nó .................................................................................................. 173

Referências Bibliográficas .................................................................................................. 221

  Lista de Figuras

  2.1 Componentes da rede CAN ............................................................................................. 7

  2.2 Princípio de funcionamento da rede CAN ...................................................................... 8

  2.3 Acesso de um nó a rede ................................................................................................. 10

  2.4 Modelo de camadas ISO/OSI ....................................................................................... 11

  2.5 Camadas da Rede CAN ................................................................................................ 12

  2.6 Campos da mensagem de dados ................................................................................... 14

  2.7 Campo de identificação da parte A .............................................................................. 14

  2.8 Campo de identificação da parte B .............................................................................. 15

  2.9 Campo de controle para parte A ................................................................................... 15

  2.10 Campo de controle para parte B ................................................................................... 16

  2.11 Campo de dados ........................................................................................................... 17

  2.12 Campo do CRC ............................................................................................................ 17

  2.13 Campo de ACK ............................................................................................................ 18

  2.14 Fim de mensagem ......................................................................................................... 18

  2.15 Mensagem remota .......................................................................................................... 19

  2.16 Mensagem de erro ......................................................................................................... 19

  2.17 Mensagem de sobrecarga ............................................................................................. 20

  2.18 Estrutura típica de um nó da rede CAN ....................................................................... 23

  2.19 Componentes da rede CAN ......................................................................................... 25

  2.20 Níveis de tensão da rede CAN .................................................................................... 26

  2.21 Esquema de um transceiver ........................................................................................ 27

  2.22 Segmentos do “BIT TIME” ......................................................................................... 29

  3.1 Arquitetura do DSP TMS320F2407 .............................................................................. 37

  3.2 Barramento de Memória .............................................................................................. 38

  3.5 Registradores Auxiliares .............................................................................................. 42

  3.6 Registradores de Estado ............................................................................................... 43

  3.7 Conversor A/D .............................................................................................................. 46

  3.8 Módulo SPI .................................................................................................................. 47

  3.9 Formato de mensagem SPI ........................................................................................... 48

  3.10 Formato de mensagem SCI .......................................................................................... 50

  3.11 Módulo SCI .................................................................................................................. 51

  3.12 Gerenciador de Eventos .............................................................................................. 54

  3.13 Interrupção .................................................................................................................... 57

  3.14 Etapas para programação do DSP ............................................................................... 58

  3.15 Divisão de seções do programa ................................................................................... 60

  3.16 Paginação de memória ................................................................................................ 62

  3.17 Controlador CAN ........................................................................................................ 63

  3.18 Mapa de memória do controlador CAN ...................................................................... 65

  4.1 Placa de desenvolvimento de projetos ......................................................................... 70

  4.2 Exemplo do ambiente de trabalho ................................................................................ 71

  4.3 Esboço da placa PL1 ...................................................................................................... 72

  4.4 Foto da placa PL1 ........................................................................................................... 73

  4.5 Algoritmo da função de inicialização do DSP .............................................................. 74 4.6 . Função para inicialização do DSP .............................................................................. 74

  4.7 Esquema de ligação para obtenção de um nó da rede .................................................. 76

  4.8 Esquema de ligação entre dois nós ................................................................................ 77

  4.9 Algoritmo para inicialização dos parâmetros ............................................................... 78

  4.10 Função de inicialização da rede CAN .......................................................................... 79

  4.11 Algoritmo para carregar dados no mailbox 5 ................................................................ 81

  4.12 Função de carga de dados no mailbox 5 ........................................................................ 82

  4.13 Algoritmo para transmissão de mensagem pelo mailbox 5 ........................................... 84

  4.14 Função para transmissão do mailbox 5 ......................................................................... 85

  4.17 Algoritmo para recepção da mensagem .......................................................................... 88

  4.18 Recepção de dados pelo mailbox 0 .................................................................................. 89

  4.19 Montagem para teste inicial de algoritmos ...................................................................... 89

  4.20 Sinal do barramento CAN ............................................................................................... 90

  4.21 Bits de comando no barramento CAN ............................................................................. 92

  4.22 Função para transmissão com mailbox 4 ........................................................................ 94

  4.23 Função para transmissão com mailbox 3 ........................................................................ 94

  4.24 Função para transmissão com mailbox 2 ........................................................................ 94

  4.25 Função para recepção com mailbox 3............................................................................. 95

  4.26 Função para recepção com mailbox 2............................................................................. 95

  4.27 Função para recepção com mailbox 1............................................................................. 95

  4.28 Rotina para verificação da interrupção por mensagens ................................................... 98

  5.1 Primeiro AGV ............................................................................................................. 100

  5.2 Um AGV em uma aplicação típica na indústria .......................................................... 100

  5.3 Campo magnético gerado pelo cabo condutor ............................................................ 101

  5.4 Exemplo de aplicação do laser em um AGV .............................................................. 102

  5.5 Sensores de segurança típico ....................................................................................... 103

  5.6 Esboço da rede implementada ..................................................................................... 105

  5.7 Disposição dos bits identificadores ............................................................................. 113

  5.8 Algoritmo principal do nó 1(parte 1) ........................................................................... 119

  5.9 Algoritmo principal do nó 1 (parte 2) .......................................................................... 120

  5.10 Algoritmo para tratamento da interrupção INT1 do nó 1............................................. 122

  5.11 Algoritmo principal para o nó 2 (parte 1) .................................................................... 125

  5.12 Algoritmo principal para o nó 2 (parte 2) .................................................................... 126

  5.13 Algoritmo para tratamento da interrupção INT 1 do nó 2............................................ 127

  5.14 Algoritmo principal para o nó 3 (parte 1) .................................................................... 130

  5.15 Algoritmo principal para o nó 3 (parte 2) .................................................................... 131

  5.16 Algoritmo para tratamento da interrupção INT 1 do nó 3............................................ 132

  5.19 Princípio de funcionamento do sistema ótico ............................................................ 136

  5.20 Algoritmo para tratamento da interrupção INT 1 do nó 4............................................ 138

  5.21 Algoritmo principal para o nó 5 (parte 1) .................................................................... 140

  5.22 Algoritmo principal para o nó 5 (parte 2) .................................................................... 141

  5.23 Algoritmo da interrupção 1 do nó 5 (parte 1) .............................................................. 142

  5.24 Algoritmo da interrupção 1 do nó 5 (parte 2) .............................................................. 143

  5.25 Conjunto completo para testes ..................................................................................... 145

  Lista de Tabelas

  2.1 Codificação do número de bytes da mensagem ............................................................ 16

  3.1 Categorias de aplicação de DSP .................................................................................... 32

  3.2 Estimativa de crescimento do mercado de DSPs .......................................................... 33

  3.3 Participação no mercado de DSPs ................................................................................ 33

  3.4 Nomenclatura dos Registradores ................................................................................... 44

  3.5 Registradores associados a cada mailbox ....................................................................... 68

  3.6 Endereços da memória de cada mailbox ....................................................................... 69

  4.1 Testes com variação do número de bytes enviados ...................................................... 93

  4.2 Teste de máscara de recepção ........................................................................................ 97

  5.1 Grupo de mensagens ................................................................................................... 112

  5.2 Bits identificadores para cada grupo de mensagens .................................................... 114

  5.3 Definição dos bits identificadores para cada mensagem ............................................. 115

  5.4 Máscara das mensagens recebidas .............................................................................. 117

  5.5 Relação das ações programadas para o nó 1 ............................................................... 123

  5.6 Relação das ações programadas para o nó 2 ............................................................... 128

  5.7 Relação das ações programadas para o nó 3 ................................................................ 133

  5.8 Relação entre velocidade dos motores e atuação dos sensores ................................... 137

  5.9 Relação das ações programadas para o nó 4 ................................................................ 137

  5.10 Relação das ações programadas para o nó 5 ................................................................ 144

  5.11 Teste dos bits identificadores ....................................................................................... 146

  5.12 Mensagem do nó 1 para eventos internos .................................................................... 147

  5.13 Eventos de resposta do nó 1 ......................................................................................... 147

  5.14 Mensagem do nó 2 para eventos internos .................................................................... 148

  5.15 Eventos de resposta do nó 2 ......................................................................................... 148

  5.17 Eventos de resposta do nó 3 ......................................................................................... 149

  5.18 Mensagem do nó 4 para eventos internos .................................................................... 150

  5.19 Eventos de resposta do nó 4 ......................................................................................... 150

  5.20 Mensagem do nó 5 para eventos internos .................................................................... 151

  5.21 Eventos de resposta do nó 5 ......................................................................................... 152

  

CAPÍTULO 1

  INTRODUđấO 1.1 EVOLUđấO DOS SISTEMAS DIGITAIS.

  O desenvolvimento da eletrônica permitiu o surgimento de microcontroladores de baixo custo, ampliando as aplicações a que eram destinados. A aplicação de microcontroladores permitiu também o surgimento de sistemas mais complexos, ditos mais “inteligentes”, pela aplicação de algoritmos de controles mais sofisticados, cuja aplicação através de sistemas analógicos não era viável, seja por questões econômicas ou técnicas.

  Como exemplo pode-se citar a evolução dos sistemas embarcados em automóvel. Sendo um mercado extremamente competitivo, o mercado automobilístico sempre impulsionou a tecnologia em seus diversos aspectos, seja nos meios de produção, pelo desenvolvimento da tecnologia com o intuito de garantir uma produção de automóveis de qualidade a baixo custo, seja pela aplicação de tecnologia aplicada diretamente no produto, pela incorporação de diversos sistemas eletrônicos, como por exemplo, para o controle de emissão de poluentes e de consumo, de sistemas de segurança, como contra colisões ou para manter a estabilidade do automóvel em situações adversas, ou mesmo para comodidade, para permitir um controle mais uniforme da temperatura no automóvel.

  Inicialmente estes avanços levaram a uma descentralização do comando. O que era feito por uma única unidade de controle passou a ser feita por unidades distribuídas pelo veículo, pois, caso contrário, haveria a necessidade utilização de um número elevado de conexões dos sensores para a unidade de controle centralizada. Além do custo envolvido, havia o problema de interferências que determinado sinal poderia sofrer. O controle distribuído passou então a ser uma alternativa atraente, pois permitia a aplicação local de módulos eletrônicos para a realização de uma atividade específica.

1.2 NECESSIDADE DE COMUNICAđấO EM SISTEMAS EMBARCADOS

  Ao mesmo tempo que os novos sistemas trouxeram novas possibilidades de aplicação, trouxeram consigo um outro problema, pois os módulos distribuídos geralmente precisam algum tipo de comunicação, havendo a necessidade de troca de informações entre eles.

  Isso levou ao surgimento de uma rede de comunicação serial desenvolvido pela empresa alemã Bosch no início dos anos 80. Essa rede foi chamada de rede CAN (Controller Area Network).

  A rede CAN é uma rede multi-mestre, baseada em mensagens, e não em endereçamento, utilizando-se de bits identificadores para diferenciar uma mensagem de outra. Além do mais, possui um sistema de priorização de mensagens, utilizando para isso os próprios bits identificadores, bem como um mecanismo eficiente de detecção de erro [Bosch, 1991] também foi incorporado. Essa rede atende à especificação das duas camadas iniciais, física e de enlace, do modelo ISO/OSI de comunicação de redes.

  Essas características levaram sua aplicação também para diversas áreas, como a industrial, médica, militar e náutica. A disseminação de seu uso levou o surgimento de diferentes protocolos de comunicação que utilizam a rede CAN como base [Etschberger, 2001], como por exemplo a rede DeviceNet e CANopen, tipicamente para aplicações industriais, ou mesmo a SAE J1939, para aplicações em veículos .

  

1.3 DESENVOLVIMENTO DE PROTOCOLOS BASEADOS NAS DUAS

CAMADAS DA REDE CAN

  Apesar do surgimento de diversos protocolos mais elaborados, baseados na rede CAN, existem aplicações específicas em sistemas embarcados. Por exemplo, no controle em tempo real, onde a latência do sistema é crucial. A aplicação desses protocolos exigirá

  Uma opção a ser considerada é o desenvolvimento de protocolos específicos para uma determinada aplicação, baseada nas duas camadas da rede CAN. Como vantagem pode-se citar ganhos com resposta do sistema, desenvolvimento do protocolo com as particularidades específicas para determinado sistema, além de não exigir tanto de cada processador, barateando o custo. Além do mais, atualmente diversos processadores já trazem controladores incorporados ao processador. Como desvantagem pode-se citar que a aplicação em si não terá um contato direto com os demais protocolos, sendo que, havendo a necessidade, pode ser desenvolvida uma interface específica para isso.

1.4 FORMULAđấO DO PROBLEMA

  A Sociedade Educacional de Santa Catarina (SOCIESC) possui um Sistema Flexível de Manufatura (FMS) didático em seus laboratórios, utilizados na atividade de ensino e pesquisa. Este sistema é composto por:

  • Um Sistema de Armazenamento: para armazenamento das peças brutas a serem usinadas, assim como, o armazenamento de peças já acabadas. Para isso, este sistema possui um software supervisório que permite a programação das peças que serão confeccionadas, conforme programação pré-estabelecida, onde toda a informação é armazenada em um banco de dados, controlando toda a movimentação de peças pela FM
  • Duas máquinas operatrizes: Uma freza e um torno, ambas com controle feito por

  Comando Numérico Computadorizado (CNC). Cuja função é a fabricação de peças mecânicas conforme a programação no CNC. Atualmente esta programação ainda tem que ser manual, mas no futuro, com a integração completa do sistema o objetivo é que o programa possa ser transmitido remotamente, até mesmo pela Internet;

  • Um robô: utilizado para manipulação de materiais, para abastecer e retirar peças das máquinas operatrizes.

  áreas ligadas à automação da manufatura. Em parceria com a Universidade Federal de Santa Catarina (UFSC), em particular com o Grupo de Comando Numérico (GRUCON), do Departamento de Engenharia Mecânica teve um projeto de pesquisa aprovado pelo CNPQ, em 2002 , cujo objetivo é o estudo e desenvolvimento de uma estrutura que permita a fabricação remota de peças via Internet na FMS.

  Por outro lado, um grupo de professores, ligados ao curso de tecnologia em automação industrial, no intuito de expandir os recursos existentes nesse sistema, iniciou estudos para o desenvolvimento de um veículo auto-guiado (AGV). O objetivo deste veículo é o transporte de peças, acabadas ou não, entre as unidades dentro da FMS. Nesse sentido, foram produzidos diversos trabalhos de conclusão de curso, principalmente nas áreas de acionamentos industriais, estudos sobre a escolha e carga de baterias, e projetos estruturais mecânicos. Como particular, podemos considerar que os diversos trabalhos são subsistemas de um sistema mais complexo, que é o AGV.

  Como o objetivo da dissertação é contribuir para o desenvolvimento de um AGV e, ao mesmo tempo o estudo da comunicação em sistemas embarcados, optou-se por fazer um estudo na integração do sistema, visto que, não havia nenhum trabalho voltado na integração do sistema.

  Em tratando-se da integração de subsistemas a primeira etapa é a necessidade da comunicação entre os mesmos. Para isso, pesquisou-se os diferentes sistemas, procurando encontrar uma solução já consolidada para avaliar a sua aplicação no AGV. Como exemplo, encontrou-se a utilização da rede CAN na indústria automobilística e em outras aplicações industriais, conforme já discutido nas seções anteriores.

  Uma segunda etapa foi da escolha da plataforma de desenvolvimento que seria utilizada para o desenvolvimento da rede CAN. Nesta etapa, verificou-se que a utilização de Processadores Digitais de Sinais (DSPs) no controle de acionamentos elétricos, além dos aplicação. Como, em particular, tanto na SOCIESC como na UDESC, possuem plataformas de desenvolvimento doadas pela Texas Instruments, baseadas no processador TMS320F2407, resultou como escolha lógica a utilização destas plataformas para o desenvolvimento do trabalho. Assim, a escolha do processador não foi por motivação técnica mas sim, apenas pela utilização de recursos existentes nas duas instituições.

1.5 ORGANIZAđấO DA DISSERTAđấO

  No capítulo 2 será apresentada em maiores detalhes a rede CAN, procurando-se apresentar os conceitos básicos para sua correta utilização. No capítulo 3 tem-se a apresentação do DSP utilizado, bem como do controlador CAN incorporado ao mesmo. No capítulo 4 são apresentados os primeiros resultados obtidos, bem como a estrutura básica de um nó da rede CAN desenvolvida. No capítulo 5 são apresentadas as etapas para o desenvolvimento de um protocolo de comunicação baseado nas duas camadas da rede CAN. Para isso apresenta-se uma plataforma mínima que emula o comportamento em alguns aspectos de um AGV. No capítulo 6 são apresentadas as conclusões e trabalhos futuros.

  

CAPÍTULO 2

REDE CAN

  2.1. INTRODUđấO

  Neste capítulo serão abordados os principais aspectos da rede CAN, como os tipos e formato de mensagens existentes, principais características elétricas e mecanismos de detecção de erro e definição de prioridade de mensagens.

  2.2. HISTÓRICO

  A aplicação crescente de sistemas eletrônicos na indústria automobilística proporcionou o surgimento de sistemas especialistas divididos em módulos, em diferentes partes do automóvel. Mas, em virtude disso, geralmente havia uma necessidade comum, a da comunicação de informações obtidas nos diferentes módulos, como por exemplo de sensores de velocidade e temperatura para outros módulos, não necessariamente próximos aos anteriores. A primeira solução adotada foi a do acréscimo de um número cada vez maior de cabos interligando os diferentes módulos. Uma segunda alternativa foi o do desenvolvimento de uma rede que possibilita-se a comunicação entre os módulos, de forma rápida e segura.

  Neste contexto surgiu a rede CAN. Ela foi desenvolvida pela empresa Robert Bosch GmbH, na Alemanha, em 1986, quando se necessitava desenvolver um sistema de comunicação entre três unidades de controle eletrônico para um veículo da Mercedes Benz.

  O primeiro chip controlador CAN foi fabricado em 1987 pela Intel. Atualmente

  • Fujitsu
  • >Hit
  • Intel •

  Mitsubishi

  • National semicondu
  • NEC
  • Philips Semiconductors •

  SGS Thomson

  • Infineon • Texas Instruments

  Em 1991 a Bosch publicou uma alteração da norma [Bosch, 1991] onde foi incluída uma segunda parte, conhecida como parte B. Em 1993, a rede CAN tornou-se padrão ISO 11898 , com a primeira modificação ocorrendo em 1995.

2.3. ESTRUTURA DA REDE CAN

  A rede CAN é um barramento serial multi-mestre que usa transmissores para enviar para todos os nós da CAN, podendo alcançar a velocidade de transmissão de dados de até 1Mbit/s. Além do mais, possui um sistema de detecção de erros muito sofisticado e robusto [Bosch, 1991]. Os componentes básicos de uma rede CAN encontram-se na figura 2.1.

  Módulo Eletrônico Módulo Eletrônico

  Rt Rt Estes componentes básicos são:

  Módulo eletrônico: Consiste de um sub-sistema responsável pela aquisição do sinal

  local desejado, como leitura de sensores, e enviar o dado através da rede. Este módulo pode ou não ser microprocessado, contendo ainda um controlador CAN, que é um chip que implementa efetivamente a norma para condicionamento do dado e um transceiver, que é um chip transmissor/receptor para adequar o sinal digital para os níveis elétricos adequados à rede. Este conjunto de componentes, ou módulo, é conhecido como um NÓ da rede CAN;

  Cabo: este cabo é o meio físico para o transporte de dados, sendo geralmente

  utilizado um cabo entrelaçado, apesar da norma não especificar o meio físico, pois pode ser utilizado qualquer outro meio, como por exemplo, um cabo de fibra ótica;

  Resistores terminais: estes são resistores colocados no final na rede para satisfazer a adequação da rede quanto a sua especificação elétrica.

2.3.1. Princípio de funcionamento da rede CAN

  Para tornar mais fácil o entendimento do funcionamento da rede CAN será abordado um exemplo simples de sua utilização no automóvel, que se encontra na figura

2.2. Erro!

  Sensor de Sensor de Velocidade Temperatura Controlador

  

o

  ( RPM ) ( C ) do Motor Nó A Nó B Nó C

  Mensagem: Mensagem: Mensagem:

  o o

  RPM C

  C, RPM No exemplo de utilização da rede CAN em um automóvel serão considerados três sub-sistemas independentes: o medidor de velocidade do automóvel (Nó A), da temperatura do motor (Nó B) e o controlador do motor (Nó C). O medidor de velocidade informa a rede constantemente a velocidade atual do motor, sendo que esta mensagem ocupa o barramento e está disponível para todos os sub-sistemas conectados ao barramento. Através da filtragem, a mensagem somente é aceita pelo sub-sistema que utiliza a informação, neste caso o controlador do motor. Ainda acoplado a esta rede está o medidor de temperatura do motor, que envia para o barramento a informação da temperatura, e como essa informação somente interessa ao controlador do motor, a mesma somente é aceita por este dispositivo.

  Quando são transmitidos dados na CAN, nenhum nó é endereçado diretamente, sendo o conteúdo da mensagem definido por um identificador único em toda a rede que estabelece a prioridade da mensagem.

  Se um nó decide enviar uma mensagem, tudo o que tem que fazer é fazer a coleta dos dados e enviá-los para o controlador CAN, do próprio nó, onde então a mensagem é construída e enviada ao barramento, logo que lhe for autorizado o acesso ao mesmo.

  Quando este nó tiver o controle da rede, todos os outros nós tornam-se receptores da mensagem. Cada nó da rede, depois de ter recebido a mensagem, faz um teste de validação para verificar se o conteúdo da mensagem lhe interessa, nesse caso processando-os, caso contrário serão descartados. Existe a possibilidade de que cada nó aplique filtros de mensagens, onde um ou mais bits dos identificadores de mensagens são mascarados, ou seja, são desconsiderados no teste de validação, possibilitando que determinado nó receba um grupo de mensagens.

  Os conflitos de acesso à rede são resolvidos através da arbitragem bit a bit dos identificadores das mensagens. Cada estação observa bit a bit a rede, 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 todas as estações que queiram enviar um bit recessivo, em esteja livre novamente. Mesmo não obtendo o acesso à rede, a mensagem não é destruída, permanecendo armazenada até a possibilidade de envio. Na figura 2.3 encontra-se um exemplo do instante em que três nós tentam o acesso à rede. A medida que um dos nós envia um bit recessivo ele deixa de enviar para se tornar um ouvinte.

Figura 2.3 . Acesso de um nó a rede

  Existem dois formatos de mensagem da Rede CAN, um é conhecido como parte A, que é a versão 2.0 A , e a outra, conhecida como parte B, que é a versão 2.0 B. A principal diferença é que a versão 2.0 A utiliza 11 bits identificadores de mensagem, enquanto a versão 2.0 B utiliza 29 bits identificadores, permitindo um número muito maior de tipos de mensagens que podem ser transmitidas. Cabe ao projetista analisar a necessidade de utilização de uma ou outra.

  A norma original deu origem à norma ISO 11898 parte 1, ou simplesmente, ISO 11898-

  1. Como essa norma não especifica o meio de comunicação, podem haver problemas para a conexão de dispositivos de diferentes sistemas. A ISO ( International Standardization Organization) em conjunto com a SAE (Society of Automotive Engineers) definiram alguns protocolos adicionais, onde além de outros parâmetros, incluem a definição do meio

  2001], para aqueles que desejam fornecer equipamentos para serem incorporados aos seus próprios veículos.

  Por tratar apenas das duas camadas inferiores a rede CAN possibilitou o surgimento de outras plataformas que foram desenvolvidas com diferentes finalidades, utilizando geralmente a camada de aplicação. Dentre as mais conhecidas pode-se ressaltar:

  • CAL ( CAN Application Layer)
  • CANOpen
  • DeviceNet
  • SAE J1939 Uma abordagem mais detalhada sobre as características desses protocolos é apresentada em [Etschberger, 2001].

2.4. O PADRấO DE COMUNICAđấO ISO/OSI

  A comunicação de sistemas em rede utiliza uma arquitetura dividida em camadas. Essa arquitetura levou a criação pela ISO de um modelo de referência conhecido como Modelo de Referência ISO/OSI para Comunicação de Dados, onde a sigla OSI vem de Open Systems Interconnection. Na figura 2.4 tem-se a representação do modelo.

  Aplicação Apresentação

  Sessão Transporte

  Rede Enlace

  Física Nesse modelo cada camada fornece serviço à camada superior. A vantagem disso é que a camada superior não precisa se preocupar em conhecer os detalhes da camada anterior.

  O protocolo de comunicação CAN trabalha nas duas camadas inferiores, a de Enlace e a Física. Na especificação inicial, a mídia de transmissão foi deixada de fora para permitir uma maior flexibilidade para os usuários escolherem entre as diferentes tecnologias disponíveis, seja par trançado, coaxial, fibra ótica ou rádio freqüência.

  

Cada camada possui uma série de serviços que são responsáveis pela adequação da mensagem para os níveis posteriores. Na figura

2.5, tem-se um maior detalhamento das funções de cada camada.

  Camada de Enlace Camada de Enlace Controle Lógico do Enlace ( LLC )

  • Filtragem de mensagens
  • Notificação de sobrecarga

  Supervisor

  • Gerenciamento de restabelecimento

  Controle de Acesso ao Meio ( MAC )

  • Encapsulamento/Desencapsulamento de dados

  Contenção de

  • Codificação da mensagem

  Erro

  • Detecção e sinalização de erros
  • Reconhecimento de mensagens
  • Serialização/Deserialização
  • Gerenciamento de Acesso ao Meio

  Camada Física Camada Física

  • Codificação/Decodificação de Bits

  Gerenciamento

  • Sincronização/Temporização de Bits

  de Falha do

  • Características do Driver de

  Barramento

  Recepção/Transmissão

Figura 2.5 Camadas da Rede CAN

  A camada de Enlace é o núcleo do protocolo CAN, onde ocorre o encapsulamento /desencapsulamento da mensagem, a detecção e sinalização de erros de mensagens e disponibiliza à camada superior a mensagem recebida e os erros encontrados. Por sua vez recebe da camada superior a mensagem a ser transmitida, o identificador da mensagem e o número de bytes da mensagem.

  A camada Física é responsável pela recepção/transmissão da mensagem através do meio físico utilizado, assim como a sincronização de bit, entre outras funções.

  O Supervisor faz o tratamento dos erros gerados nas duas camadas e no barramento.

2.5. CAMADA DE ENLACE

2.5.1 Tipos de Mensagens

  Para comunicação entre os diferentes nós da rede tem-se quatro tipos de mensagens:

  • Mensagem de Dados: são as mensagens que enviam as informações sobre o processo monitorado;
  • Mensagem Remota: é uma solicitação de informação que um nó faz à rede. O nó que tiver a informação irá devolver a mensagem com os dados solicitados;
  • Mensagem de Erro: é um tipo de mensagem que indica que algum tipo de erro que ocorreu;

  Mensagem de Sobrecarga: esta mensagem indica que determinado nó está sobrecarregado de informações e não

  • conseguiu processá-las ainda, solicitando um atraso maior entre as transmissões.

2.5.1.1 Mensagem de Dados

  Como já mencionado, a mensagem de dados possui dois tipos:

  • Padrão, conhecido como 2.0 A;
A mensagem de dados é composta por sete campos principais, conforme encontra- se na figura 2.6 e descrita a seguir: Início da

  Fim da Campo de Campo de Campo de Campo do Campo mensagem de mensagem

  Identificação Controle Dados CRC ACK

Figura 2.6 Campos da mensagem de dados

  a) Início da mensagem: utilizado para indicar o início da mensagem, composta por um único bit dominante ;

  b) Campo de Identificação: este campo é composto pelos bits de identificação da mensagem. A largura desse campo pode ser igual a 11 bits ( 2.0 A) ou 29 bits (2.0 B); Na figura 2.7 encontram-se os bits que compõe o campo de identificação para a parte A.

  11 bits identificadores RTR

Figura 2.7 Campo de identificação da parte A

  Além dos 11 bits identificadores tem-se ainda o bit RTR:

  • RTR (Remote Transmission Request): este bit serve para identificar se a mensagem é uma mensagem de dados ou uma mensagem remota, que é uma solicitação para receber uma determinada informação enviada à rede por um nó. Se o bit estiver em 0 a mensagem é de dados, se estiver em 1 a mensagem é uma mensagem remota.

  Para a mensagem de dados da parte B o campo de identificação encontra-se na figura 2.8.

  11 bits identificadores SRR

  IDE 18 bits identificadores RTR

  • SRR (Substitute Remot Request): Este bit é recessivo (=1), substituindo o bit
  • IDE (Identifier Extension): Este bit é recessivo na parte B e serve para identificar que a mensagem é de formato estendido.
  • RTR (Remote Transmission Request): tem a mesma função que na parte A.

  IDE r0 DLC3 DLC2 DLC1 DLC0 Neste padrão tem-se ao todo 29 bits identificadores, separados em dois blocos, o primeiro, idêntico ao anterior, de 11 bits, e o segundo bloco, de 18 bits. Além dos bits identificadores tem-se os bits:

  RTR do padrão 2.0 A;

  c) Campo de Controle: é composto por seis bits, utilizado para informar o número de bytes da mensagem. Para a parte A tem-se a representação do bytes de controle na figura 2.9

Figura 2.9 Campo de controle para parte A

  Os 6 bits são divididos em:

  • IDE (Identifier Extension): apesar da localização em campos diferentes o objetivo é o mesmo, de informar a existência de formato estendido ou não. Unicamente que neste caso ele é dominante.
  • r0 : É um bit de reserva, sendo que este bit deve ser dominante(=0).

  • DLC3...0 ( Data Lenght Code ): é um conjunto de bits utilizado para informar o número de bytes da mensagem, válido tanto para o formato padrão como o estendido, conforme a tabela 2.1;

Tabela 2.1. Codificação do número de bytes da mensagem

  Nr Bytes DLC3 DLC2 DLC1 DLC0

  1

  1

  2

  1

  3

  1

  1

  4

  1

  5

  1

  1

  6

  1

  1

  7

  1

  1

  1

  8

  1 Para a parte B tem-se a alteração somente do primeiro bit, conforme a figura 2.10 r1 r0 DLC3 DLC2 DLC1 DLC0

Figura 2.10 Campo de controle para parte B

  Os mesmos 6 bits são divididos em: - r0 e r1 : São bits de reserva, sendo que estes bit devem ser dominantes(=0).

  • DLC3...0 (Data Lenght Code): é o conjunto de bits utilizado para informar o número de bytes da mensagem, e a tabela 1 também é válida para esse formato.

  d) Campo de Dados: consiste dos dados que serão transmitidos, podendo variar entre zero através de alteração de parâmetros de determinados controladores é possível alterar essa seqüência; Byte 0 Byte 1 Byte 2 Byte 3 Byte 4 Byte 5 Byte 6 Byte 7

Figura 2.11 Campo de dados

  e) Campo do CRC: utilizado para verificar a integridade da mensagem. É dividido em dois campos, a seqüência CRC e o delimitador CRC, conforme demonstra a figura 2.12; Seqüência CRC Delimitador

  CRC

Figura 2.12 Campo do CRC

  A seqüência CRC é formada por 15 bits e armazena o valor segundo o código de redundância cíclica (CRC – Cyclic Redundancy Ciclic ) onde torna possível verificar a integridade da mensagem, sendo que esse valor é comparado por cada receptor e havendo qualquer diferença é gerada uma mensagem de erro.

  O delimitador CRC é somente um bit recessivo utilizado para indicar o fim deste campo.

  f) Campo ACK (Acknowledge) : Este campo é utilizado pelas unidades receptoras para indicar que uma mensagem foi recebida. Ele é composto por dois bits:

  • ACK Slot : Este bit é enviado recessivo(=1) pelo transmissor. Qualquer receptor que confirmar o recebimento de uma mensagem irá alterar este bit para dominante(=0).
  • ACK Delimiter (Delimitador ACK): Este bit é recessivo é utilizado para indicar o fim do campo de ACK.

  ACK Slot

  ACK Delimiter

  Na figura 2.13 tem-se a representação do campo de ACK.

Figura 2.13 Campo de ACK

  g) Fim da mensagem: utilizado para indicar o final da mensagem, composta por sete bits recessivos, conforme demonstra a figura 2.14.

Figura 2.14 Fim de mensagem

2.5.1.2 Mensagem Remota

  Utilizada para solicitar alguma informação, ou seja, quando algum módulo necessita determinada informação, ele faz uma solicitação ao barramento e assim o sistema que tiver a informação envia para o barramento.

  O formato da mensagem é idêntico ao de dados, tanto para o formato padrão como o estendido, havendo apenas dois pontos que não são comuns:

  Fim de Mensagem

  • Não existe o campo de dados;

  Início da mensagem Campo de Identificação

  Campo de Controle

  Campo do CRC

  Campo de ACK

  Fim da mensagem Na figura 2.15 tem-se a representação da mensagem remota.

Figura 2.15 Mensagem remota

2.5.1.3 Mensagem Erros

  Sempre que for detectada alguma falha na integridade da mensagem, é gerada uma mensagem de erro. Essa mensagem consiste de dois campos, um denominado de Superposição do Flag de Erro e o outro campo denominado de Delimitador de Erro (Error Delimiter) , conforme pode ser observado na figura 2.16.

Figura 2.16 Mensagem de erro

  Essa mensagem é formada pelos campos:

  Superposição do flag de erro Delimitador de Erros

  Flag de erro

  • Flag de Erro (Error Flag): que é composto por seis bits consecutivos dominantes, neste caso chamado como Flag de Erro Ativo, ou de seis bits recessivos , neste caso chamado de Flag de Erro passivo. Depois dos primeiros seis bits enviados pelo nó que identificou o erro, os demais nós identificam um erro de “ bit stuff” , pois seis bits consecutivos de mesmo nível lógico acabam por provocar este erro nos demais nós. No segundo intervalo os outros nós escrevem a mensagem de erro, podendo assim esta mensagem completar os
  • Delimitador de Erro (Error Delimiter): utilizado para finalizar a mensagem de erro, sendo composto por oito bits recessivos .

2.5.1.4 Mensagem de Sobrecarga

  A mensagem de sobrecarga gera um atraso para possibilitar o processamento da informação pelos nós. O formato da mensagem é idêntico ao da mensagem de erro, sendo formado também por dois campos, como pode ser observado na figura 2.17

  Superposição do flag de Delimitador

  Sobrecarga de Flag de

  Sobrecarga Sobrecarga

Figura 2.17 Mensagem de sobrecarga

  Os dois campos são:

  • Superposição do Flag de Sobrecarga: Nesta região tem-se os seis bits dominantes do flag de sobrecarga (Overload Flags), seguidos de bits dominantes dos outros nós, chegando até a seis bits dominantes.
  • Delimitador de Sobrecarga (Overload Delimiter): são oito bits recessivos que marcam o final da mensagem.

2.5.2. Tratamento de erros na rede CAN

  Qualquer controlador que detectar algum erro na mensagem começa a transmitir uma mensagem de erro, destruindo o tráfego da rede. Os outros nós detectam o erro e ignoram a mensagem que vinha sendo transmitida.

  • Teste de Redundância Cíclica (CRC) : Utilizada para testar a mensagem, verificando sua integridade;
  • Teste da Mensagem: Através de alguns bits que tem que assumir determinados estados, recessivos ou dominantes, assim podendo-se verificar se a estrutura da mensagem esta correta. Este tipo de erro é denominado de erro de formato.
  • Erro de Confirmação: O protocolo CAN não utiliza mensagens de confirmação.

  Em vez disso, assinala os erros que ocorrem. Assim, as mensagens recebidas corretamente 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 a: os nós receptores terem identificado um erro, ao campo ACK ter sido corrompido, ou ao fato de não existirem quaisquer outras estações na rede.

  • Erros de Monitoramento: Cada transmissor monitora a própria mensagem comparando com aquilo que transmite com o conteúdo atual da rede.
  • Erro de bit: A codificação individual dos bits é testada ao nível do bit. A representação escolhida pelo CAN 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 atual é abortada e é enviada uma mensagem de erro. Isso impede que outras estações aceitem uma mensagem errada e garante a

  Depois da transmissão de uma mensagem errada ter sido abortada, o emissor tenta re-transmitir automaticamente a mensagem. No entanto, pode haver competição pela alocação da rede. Como regra geral, a emissão começa 23 períodos de bit depois da detecção.

  Os mecanismos descritos, apesar de eficientes e corretos podem, no entanto, no caso de uma estação estar com problemas, levar à degradação do sistema, abortando mensagens corretas e bloqueando o funcionamento da rede. Assim, foram implementados novos mecanismos que permitem distinguir entre erros esporádicos e erros permanentes, e a localização da estação avariada. Isso é conseguido com base em avaliações estatísticas da situação das várias estações.

  Tratando-se de uma questão importante, uma avaliação mais criteriosa sobre os mecanismos de detecção de erro, sua performance e respostas no tempo são abordados em alguns artigos, onde pode-se destacar [Charzinski , 1997] e [Punnekkat , 2000].

2.6. CAMADA FÍSICA

  A camada física é responsável pela transferência de bits entre os diferentes nós da rede. Ela define os níveis elétricos, o esquema de sincronização a impedância do cabo e a codificação.

  O barramento é composto por dois cabos, habitualmente utilizando par entrelaçado, mas também podendo ser utilizado o par liso (fio de telefone), apesar de gerar mais ruído e ser mais susceptível a fontes externas de ruído.

2.6.1 Configuração de um nó de um barramento CAN

  Cada nó no barramento CAN é interpretado como uma estação, podendo apresentar diferentes possibilidades. A configuração de um sistema de rede CAN permite diferentes possibilidades, mas na figura 2.18 tem-se um exemplo da configuração típica seguida da explicação do

  Processador Controlador CAN

  

Transceiver

Figura 2.18 Estrutura típica de um nó da rede CAN

  Pode-se identificar os seguintes componentes:

  • Processador : é o processador que utiliza a mensagem que circula no barramento. É ele que utiliza ou gera informações passando as mesmas para o controlador. Existe a possibilidade de se eliminar os processadores utilizando-se controladores CAN conhecidos como SLIO (Serial Linked I/O), onde a configuração e o controle é feita por um nó mestre que obtém o acesso aos sinais de entrada/saída do nó que possui um SLIO. Mas com o aumento de processadores que possuem controladores CAN incorporados, esta tem-se tornado uma solução mais adequada para muitos casos;
  • Controlador CAN: O controlador CAN é que faz a filtragem das mensagens que circulam pelo barramento, verifica erros, formata a mensagem do processador de acordo com o padrão CAN. O tratamento das informações é feito neste módulo, ficando reservado para CPU somente o tratamento da informação;

  • Transceiver da CAN: Sua principal função é a adaptação do sinal digital para os padrões da rede;
  • Meio físico: Composto, neste caso, por dois fios trançados com resistores terminais no final de cada ponta do cabo. O meio físico não é especificado pela norma pois depende da tecnologia existente.

2.6.2 Características do meio físico

  De acordo com a ISO 11898-2 estabelece algumas características da rede física, onde os aspectos principais são:

  • Taxa de transmissão acima de 1 Mbit/s
  • Impedância de linha de 120 ohms
  • Comprimento máximo de 40 metros com taxa de transmissão de 1 Mbit/s
  • Atraso de propagação de sinal de 5 ns/m Os dois cabos são identificados pelos nomes de CAN_H e CAN_L, conforme pode-se observar na figura 2.19.

  120 Ω

  120 Ω

  Nó 1 Nó 2 Nó 3 CAN_H

  CAN_L d Todos os nós devem ser ligados ao barramento obedecendo especificação de saída de seus transceivers nos terminais CAN_L e CAN_H. Cada nó é separado de outro por uma distância d, que pode variar de poucos milímetros até dezenas de metros. Essa distância influi diretamente como um dos aspectos limitadores da seleção de velocidade do barramento, pois existe um tempo de propagação do sinal no barramento.

  A velocidade máxima de uma rede CAN é de 1Mbit/segundo, com um cabo com comprimento máximo de 40 metros, porque o esquema de arbitragem necessita que a onda se propague até ao nó mais remoto e volte antes de ser amostrada.

  Outros valores máximos para o comprimento dos cabos são:

  • 100 metros a 500 kbits/segundo
  • 200 metros a 250 kbits/segundo
  • 500 metros a 125 kbits/segundo
  • 6 quilômetros a 10 kbits/segundo A faixa de variação da tensão nos nós é de 1,5 até 3,5 volts. Para que ocorra o nível lógico 1 (recessivo) os dois nós estarão com a tensão igual a aproximadamente 2,5 volts, e no caso do nível lógico 0 (dominante) o terminal CAN_H estará com 3,5 volts e o terminal CAN_L estará com 1,5 volts, conforme tem-se na figura 2.20

  2,5 3,5 1,5

  4 - 3 - 2 - 1 -

  Recessivo (lógica 1)

  Recessivo (lógica 1)

  Dominante (lógica 0)

  CAN_H CAN_L

2.6.3 Transceiver CAN O transceiver CAN tem a função de acoplar o controlador CAN ao barramento.

  É composto por um transmissor e receptor. Serve para proteger o controlador de eventuais curtos ou sobre-tensões da rede, além de adaptar a tensão do controlador, ao padrão da rede. Na figura 2.21, tem-se o esquema básico de um transceiver CAN.

  Além disso esses transceivers devem apresentar algumas características próprias:

  • Taxa de transmissão acima de 1 Mbit/s;
  • Proteção contra sobrecarga;
  • Proteção contra curto-circuito para terra como para a fonte;
  • Total compatibilidade com a norma ISO 11898-2 - Baixo consumo de corrente em modo de repouso. Estas características são discutidas em maiores detalhes por [Corrigan, 2002].

  Controlador CAN

Figura 2.21 Esquema de

  um

  transceiver

2.6.4 Controlador CAN

  Transceiver A função dos

  CAN_H controladores de

  120 Ω

  120 Ω

  CAN é da CAN_L implementação das características da rede, procurando atender, tanto a 1ª como a 2ª camada do padrão ISO/OSI. Assim, como resultado, resta apenas o corpo da mensagem a ser transferida que pode ser obtida do controlador, ou então, fornecer ao controlador a mensagem que será enviada, pois o mesmo incorpora todas as características necessárias.

  Para isso existem diferentes controladores oferecidos no mercado, que podem ser adaptados a diferentes configurações. As principais configurações utilizadas são:

  • fisicamente de um processador;
  • Processadores com controladores integrados: Neste caso, os próprios processadores já trazem incorporados o controlador CAN;
  • Circuitos integrados para aplicações específicas: estes são circuitos integrados para aplicações específicas que já vem com as funções de controlador CAN incorporadas.

  Controladores isolados: onde os controladores são componentes isolados

2.6.4.2 Funções de um controlador CAN

  Indiferente ao tipo de controlador CAN utilizado, ele deve implementar as funções da primeira e segunda camada, dentre as quais pode-se destacar:

  • Encapsulamento da mensagem que será transmitida;
  • Disponibilizar a mensagem que foi recebida, se a mesma for do interesse do referido nó;
  • Fazer o cálculo de CRC;
  • Detecção e sinalização de erros;
  • Inserir e apagar os “bit stuff”;
  • Gerar e detectar o bit de reconhecimento da mensagem; - Sincronização do “bit time”. Além disso, uma outra característica relevante no controlador CAN é a filtragem das mensagens, visto que todas as mensagens do barramento estão acessíveis a todos os nós, mas não necessariamente interessa aos mesmos. Assim, um processo de filtragem das mensagens é muito importante.

2.6.5. Representação do bit

  As mensagens da rede CAN são enviadas por uma seqüência de bits. Assim, a menor unidade da rede é o bit. E para representá-lo utiliza-se um método conhecido como NRZ (Non-Return-to-Zero ), onde o nível lógico do bit permanece o mesmo, seja nível lógico 0 ou 1, durante todo o tempo de um bit. Ou seja, durante o intervalo de tempo destinado para um bit não tem-se a variação do nível lógico.

  O protocolo CAN utiliza a comunicação síncrona em vez da assíncrona, o que, por um lado permite a utilização, na transmissão de dados, de maneira mais eficiente, mas em contrapartida leva a necessidade de utilização de métodos de sincronização do bit mais sofisticados.

  Como já visto, a característica da mensagem do protocolo CAN é a de possuir apenas um start bit no início do mensagem, o que, geralmente não é suficiente para manter o sincronismo do ponto de amostragem do receptor como do emissor durante toda a mensagem. Para amenizar esse problema, utiliza-se um artifício de resincronização durante as alterações dos pulsos de borda do frame de mensagem.

  Na figura 2.22 tem-se a representação de um “BIT TIME” , com os diferentes segmentos que o compõe: Segmento de Segmento de Segmento Segmento sincronização propagação de fase1 de fase2

  Amostragem do sinal

Figura 2.22 Segmentos do “BIT TIME”

  Os componentes de um bit são:

  • Segmento de sincronização: Durante este segmento espera-se que a sincronização da rede ocorra através da borda de descida ou subida do bit.
  • Segmento de atraso de propagação: Este segmento é responsável por fazer a compensação do atraso que a rede proporciona no envio e recepção do sinal.
  • Segmento de fase 1 e 2: Estes segmento estão localizados antes e depois, respectivamente, do ponto de amostragem do sinal sendo responsáveis pelo deslocamento do ponto de amostragem durante o processo de resincronização - Amostragem do sinal: Este é o ponto em que o sinal é amostrado.

  O dimensionamento dos segmentos é determinado pelas necessidades do sistema de comunicação. Fatores como o comprimento da rede, taxa de transmissão e tempo de atraso devem ser levados em conta no cálculo dos segmentos da rede. Uma abordagem mais detalhada sobre a configuração da temporização do bit da rede CAN é apresentada por [Hartwich, 1999].

  Como o processo de sincronização ocorre quando tem-se uma alteração do estado lógico, passando de nível 0 para 1, ou vice-versa, durante a mensagem, existe a possibilidade de que pode-se ter vários bits no mesmo nível lógico, o que poderia acarretar um erro de sincronismo. Para auxiliar no processo de sincronização foi implementado um solução conhecida com “Bit Stuff”. Nesse processo, quando tem-se 5 bits de mesmo estado lógico, insere-se um outro bit, de nível lógico contrário aos anteriores, fazendo assim que, no máximo por um período de 5 bits não se terá alteração no nível lógico. Nos nós receptores, a mensagem recebe o tratamento retirando os bits que foram incluídos na transmissão.

  

CAPÍTULO 3

PROCESSADOR DIGITAL DE SINAL

  3.1. INTRODUđấO

  Neste capítulo será apresentado o processador digital de sinais (DSP) que é o processador utilizado no desenvolvimento experimental. Serão discutidos aspectos relativos a arquitetura do processador, periféricos presentes e características funcionais. Será dada ênfase a discussão a um periférico em particular, que é o controlador CAN, pois o mesmo implementa as camadas 1 e 2 do protocolo de comunicação CAN.

  3.2. EVOLUđấO E CARACTERễSTICAS DOS DSPS

  Aplicações envolvendo tratamento de sinal, como filtros digitais, envolvem operações de multiplicação e soma de valores, exigindo uma maior performance de processamento para implementar muitos destes algoritmos. Esta necessidade levou aos fabricantes de chip ao desenvolvimento de um novo processador, com uma arquitetura mais adequada para as necessidades das aplicações envolvidas, conhecido como DSP (Digital Signal Processor – Processador Digital de Sinal). realizar uma multiplicação em apenas um ciclo de clock, o que melhorou consideravelmente a performance dos algoritmos para processamento digital de sinais.

  Nos microprocessadores, o programa e os dados compartilham o mesmo barramento do processador, utilizando-se de uma configuração conhecida como Von Neumann. Para permitir a realização de instruções de multiplicação e soma em um único ciclo, uma arquitetura de memória diferente foi utilizada. Conhecida como Harvard, nesta arquitetura o programa e os dados ocupam barramentos distintos, com um barramento para acessar os dados e outro para acessar o programa, levando uma melhoria na performance do processador.

  3. 3. APLICAđỏES PARA DSPS

  Os processadores DSPs são utilizados em uma gama muito grande de aplicações, de sistemas de radar até aparelhos eletrônicos domésticos, apesar de que, considerando-se o volume financeiro por aplicação, a maior aplicação atualmente são os telefones celulares, controladores de disco rígido e áudio players. Mas para poder identificar que tipo de DSP é o mais adequado para determinada aplicação é necessário levar em consideração vários fatores, como performance, custo, integração, facilidade de desenvolvimento, consumo de potência.

  Na tabela 3.1 tem-se algumas das aplicações para um DSP divididos em categorias.

Tabela 3.1. Categorias de aplicação de DSP

  Categoria Exemplos de aplicações

  Sistemas embarcados de baixo custo Modems, detetor de radar, pagers, telefones celulares, telefones sem fio, acionamentos de disco rígido, controle em tempo real em automóveis, controle de motores

  Aplicações de alta performance Radar, sonar, processamento de imagem Aplicações multimídia para Modems, voice mail, sintetizadores de música, compressão e computadores descompressão de voz

  Uma discussão mais detalhada sobre as aplicações e aspectos gerais sobre o DSP pode ser encontrada em [Lapsley , 1997] a [Marven , 1996].

  3. 4. EXPECTATIVAS ECONÔMICAS E FABRICANTES DE DSPS

  Conforme o último relatório da Forward Concepts [Forward Concepts , 2003] no mundo todo a venda dos chips de DSP alcançou no ano de 2002 a cifra de US$ 4,86 bilhões. O que representa um crescimento de 14,1% sobre os US$ 4,26 bilhões em 2001. Para o ano de 2003, apesar do cenário mundial conturbado pode-se observar que existe uma estimativa de crescimento em torno 15%. Na tabela 3.2 tem-se a projeção para os próximos anos do comportamento de mercado para o DSP.

Tabela 3.2 Estimativa de crescimento do mercado de DSPs

  Ano

  02

  03

  04

  05

  06 07 02 – 07 Valor US$ 4.855 5.826 7.749 9.918 12.398 14.877 23,8 % * ( milhões )

  • Forward Concepts – Electronic Market research

  Os maiores fabricantes

  No mercado de DSP, apesar de haver atualmente inúmeros fabricantes, o fornecimento de chip está concentrado em um número reduzido de fabricantes, com o domínio da Texas Instruments. Também baseado no relatório da Forward Concepts [Forward Concepts ,2003] tem-se a seguir a tabela 3.3 com os maiores fabricantes de DSP e do percentual de sua participação no mercado.

Tabela 3.3. Participação no mercado de DSPs

  Empresa 2001 2002 Crescimento Anual

  Texas Instruments 40.0 % 43.2 % 23.2 % Motorola 12.0 % 14.1 % 33.6 %

  Analog Devices 8.2 % 8.9 % 23.7 % Outros 23.7 % 19.9 % - 4.1 %

  Total ( US$ milhões ) 4.256 4.855 + 14.1 % 3. 5. CRITÉRIOS PARA A SELEđấO DE UM DSP

  A escolha de um processador é sempre uma tarefa difícil para o engenheiro projetista, mas alguns itens que devem ser observados na sua escolha. Para auxiliar na comparação de diferentes processadores existem trabalhos que apresentam comparativos entre processadores de diferentes famílias. Neste comparativo geralmente utiliza-se algoritmos próprios, como filtros FIR e FFT, além de outros. Um detalhamento da metodologia utilizada nestes testes pode-se encontrar no trabalho de Lennartsson e Nordlander [Lennartsson - Nordlander , 2002], onde vários algoritmos são apresentados e discutidos. Além disso existem institutos que apresentam relatórios, como é o caso da Berkeley Design Technology, Inc , que disponibiliza vários artigos sobre o assunto que discutem a questão da seleção de processadores e apresenta os resultados dos testes realizados por eles [Eyre,

  TM 2000 ], [BDTImark200 , 2002] e [Berkeley, 2000].

  Alguns dos critérios que devem ser levados em conta são:

  1. Capacidade do Processador Devendo-se considerar o conjunto de instruções do processador, arquitetura de memória, velocidade de execução das instruções, ponto fixo X ponto flutuante, capacidade de endereçamento, consumo de potência, tamanho, presença de periféricos no próprio chip;

  2. Ferramentas de desenvolvimento e suporte técnico Compiladores, plataformas para desenvolvimento, linguagens de alto nível e bibliotecas adicionais;

  3. Custo

  5. Maturidade do processador Especificamente para o desenvolvimento desta dissertação, a escolha do processador se deve somente pelo mesmo já possuir incorporado a sua arquitetura um controlador CAN, assim não foi feito nenhuma avaliação técnica que resultasse na escolha do mesmo em detrimento de qualquer outro. Como o DSP utilizado foi o TMS320F2407, da Texas Instruments Inc , a discussão até o final deste capítulo será baseada nas características do mesmo.

  3.6 . FAMÍLIAS DE DSP DA TEXAS INSTRUMENTS

  A Texas Instruments trabalha com três grandes famílias de DSPs :

  • C6000 - para alta performance

  Tem como aplicação principal a infra-estrutura para comunicação de terceira geração, DSL e a cabo, além de aplicações que necessitem intensivo poder de processamento como digitalização de imagem, aplicações profissionais na automação industrial e de áudio.

  • C5000 - baixo consumo de potência

  Otimizada para aplicações portáteis como CD players, telefones celulares de terceira geração, câmeras digitais assim como sistemas portáteis para manipulação de dados e voz.

  • C2000 – controle digital

  Sua principal aplicação é o controle digital, sendo que para isso foram incorporados ao seu hardware periféricos como conversor A/D, temporizadores e comparadores para geração de PWM, rede CAN e outros.

  3.7 . O DSP TMS320F2407

  O DSP TMS320F2407 é uma evolução da família otimizada para controle de motores ‘C24X, com melhorias em performance e com algumas alterações em determinados periféricos.

  Os DSPs TMS320F2407 incluem as mesmas vantagens que os microcontroladores, mas também oferecem alta velocidade, alta resolução, e capacidade de implementar algoritmos matemáticos complicados com baixo custo. A alta velocidade é obtida principalmente devido ao duplo barramento da arquitetura Harvard assim como a realização das instruções de multiplicação e adição em um ciclo de máquina. Um barramento é usado para dados e o outro é usado para instruções do programa. Isto economiza tempo porque pode-se utilizá- los simultaneamente.

  As principais características do DSP TMS320F2407 são:

  • Ponto Fixo de 16 bits;
  • Multiplicador de 16 X 16 bits;
  • Acumulador de 32 bits
  • Conjunto de instruções otimizadas, incluindo multiplicação/soma em um único

  ciclo;

  • Oito registradores auxiliares de 16 bits com unidade aritmética dedicada;
  • Conjunto de periféricos incorporados ao próprio chip;

3.7.1. Arquitetura do DSP TMS320F2407

  A seguir será apresentado uma visão da arquitetura do DSP, sendo maiores detalhes podem ser encontrados no manual do fabricante [Texas Instruments , 1999]. Na figura 3.1 tem-se uma visão da arquitetura do DSP TMS320F2407.

  A arquitetura interna do DSP é baseada no modelo de Harvard, com barramentos separados para o programa e dados, permitindo que haja acesso simultâneo dos dados e às instruções de programa, além disso, tem-se um terceiro barramento para acesso da CPU aos periféricos.

  Barramento de Dados JTAG ROM ou flash DARAM

  DARAM EEPROM B0 B1/B2 Interface para memória externa Barramento de Programa

  Controle da Memória

  C2xx

  Gerador de

  Controlado Registrado

  Estados de

  CPU

  Interrupções Espera p/

  r r

  Memória

  do Instrução

  Inicialização

  Programa

  Deslocador de Multiplicador

  ARAU

  Entrada Registradores Controle/Status

  Gerenciador de

  TREG

  Eventos

  ALU

  Registradores Auxiliares

  PREG Acumulado Temporizadores

  Registradores de uso geral Deslocador de

  r

  Mapeamento Deslocador de Produto(Shifter) Saída

  Memória

  Unidades de Comparação QEP

  Módulo de CLOCK

  Interface do Sistema Barramento dos Periféricos

  Watchdog

SCI SPI CAN

  Módulo do Sistema

  CPU DARAM

B0

  Registradores de Memória

  Barramento Externo de Endereços Barramento Externo de Dados

  PRDB DRDB DWEB PAB DRAB DWAB ROM ou Flash EEPROM

  DARAM B1/B2

Figura 3.1 Arquitetura do DSP TMS320F2407

  A figura 3.1 pode ser dividida em três blocos básicos: Memória, Núcleo da CPU e Periféricos.

3.7.1.1 Memória Na figura 3.2 tem-se o bloco de memória em maiores detalhes.

Figura 3.2 Barramento de Memória

  A memória é composta pela memória não volátil, ROM ou Flash , utilizada para armazenar o programa, uma memória volátil, RAM ( B1/B2) utilizada para armazenar memórias de duplo acesso, onde é possível executar duas operações, por exemplo escrita e leitura, em um ciclo do clock da CPU.

  Além disso, cada um dos barramentos, o de endereço e o de dados, é dividido em três barramentos, perfazendo um total de seis barramentos, isto ocasionará a melhora da performance do DSP pois permitirá a troca de informação dos bancos de memória para os diferentes módulos no mesmo instante.

  Os seis barramentos são:

  PAB - o barramento de endereçamento do programa provê o endereço tanto para escrita como para a leitura na memória do programa. DWAB – o barramento de endereçamento provê o endereço para a escrita da informação na memória de dados . PRDB – o barramento de leitura do programa transporta o código da instrução e

  operadores imediatos, assim como dados para tabelas, da memória do programa para a CPU.

  DRDB – o barramento de leitura dos dados, que transporta dados da memória para a

  unidade de lógica e aritmética central (CALU) e para a unidade registradora auxiliar aritmética (ARAU). Na figura 3.3 com a representação do mapa de memória do DSP TMS320F2407.

  Programa Dados Entrada/Saída

  Vetores de Registradores Interrupção Mapeados na

  Memória Código de segurança

  DARAM B2 Flash

  Externa

  DARAM B0 Flash DARAM B1 Flash

  SARAM 2k SARAM

  (DON=1) Interno (PON=1) Interno

  (DON=0)Reservado (PON=0)Externo

  Ilegal

  Registrador de Externa

  Controle da Flash Reservada(CNF=1)

  Externa Externa(CNF=0)

  Registrador de Controle da

  On-Chip DARAM Geração de

  a)

  b)

  c)

Figura 3.3 Mapa de memória

  Cada bloco de memória possui 64 Kwords endereçáveis que estão dividindo da seguinte forma:

  • Memória do programa - o espaço inicial da memória (0000h – 003Fh) tem-se a tabela

  de interrupções e logo após o espaço reservado para o programa (0040h – 7FFFh), depois tem-se o espaço reservado para memória externa ( 8000h – FDFFh ), se for necessário utilizar uma EPROM, e depois tem-se o bloco B0 que será utilizado para a memória de programa se o bit CNF for igual a 1.

  Existem outros espaços reservados para os registradores dos periféricos e memória externa.

  • Memória de Entrada/Saída - Este espaço é utilizado para mapear periféricos externos

  e registradores para controlar a memória Flash. Além do mais será necessário a utilização do gerador de estados de espera para trabalhar com a memória externa, cujos registradores também se encontram neste bloco de memória.

3.7.1.2. Unidade Central de Processamento

  A Unidade Central de Processamento (CPU) é o cérebro do sistema, onde todo processamento matemático e lógico acontece. Ela é composta de três blocos principais : a seção de Deslocamento Escalar, a seção de Multiplicação e a seção da Unidade Central de Lógica e Aritmética e Acumulador. Na figura 3.4 encontra-se uma representação da mesma.

  • Deslocamento Escalar – Serve para enviar o dado para o acumulador. Além disso, esta

  unidade converte o dado de 16 bits para os 32 bits do acumulador, possibilitando ainda fazer o deslocamento de bits, utilizando o shifter, diretamente com o dado antes mesmo dele ser armazenado pelo acumulador.

  • Multiplicação – é composta pelos registradores TREG e PREG, e ainda do

  multiplicador de 16 X 16 bits. O dado armazenado no registrador TREG é multiplicado por um dado vindo do barramento de memória, podendo ser uma constante ou variável, e o resultado, agora com 32 bits, é armazenado no registrador PREG. O conteúdo de PREG é enviado para o acumulador passando por um Shifter (deslocamento) que poderá ser utilizado para fazer o deslocamento de bits.

  • Unidade Central de Lógica e Aritmética ( CALU ) e Acumulador - Esta unidade recebe

isto o dado é enviado para o acumulador, aguardando novas instruções, ou mesmo o envio do dado para ser armazenado na memória.

  DWEB DRDB PRDB

  1

  1

  1

  1

  1 TREG

  6

  6

  6 MUX

  6 MUX

  6 Multiplicador

  1

  1

  16 X 16

  6 31 16 15 0

  6 Multiplicação

  PREG

  Input Shifter (32 bits)

  3 Deslocament

  2

  3 Product Shifter (32 bits) o Escalar

  2 MUX

  3 Unidade Central de

  3

  2 Lógica e Aritmética e

2 CALU Acumulador

  3

  2 Acumulador

  C

  Output Shifter (32 bits)

  1

  6 Figura 3.4 Unidade Central de Processamento

  Unidade Aritmética dos Registradores Auxiliares

  O DSP TMS320F2407 possui oito registradores auxiliares (AR0 – AR7) que podem ser utilizados para armazenar endereços de memória, como contadores, armazenar valores e comparações para realizar saltos condicionais e ,além disso, também podem ser realizados operações entre os registradores através da Unidade Aritmética dos Registradores Auxiliares, que podem ser visualizar na figura 3.5.

  16

  AR6 3 ARAU DWAB AR7 AR5 AR4 AR3 AR2 AR1 AR0 ARP ARB Registrador Instrução

  8

  16 DWEB DRAB MUX

  3

  3

  3 DRDB

  MUX Dos oito registradores somente um será o registrador corrente, que será dado pelo

  Apontador dos Registradores Auxiliares (ARP), e que, para utilizar um registrador auxiliar deve-se sempre carregar o novo registrador, já o anterior será armazenado no Buffer do Registrador Auxiliar ( ARB ).

Figura 3.5 Registradores Auxiliares

  Registradores de Estado ST0 e ST1

  Os registradores de estado contém os bits de controle e estado do DSP TMS320F2407, que podem ser carregados da memória de informação, permitindo que o estado da máquina possa ser salvo e restaurado por subrotinas. a)

  

b)

Figura 3.6 Registradores de Estado

  Na tabela 3.4 tem-se a designação de cada um dos bits dos registradores de estado ST0 e ST1.

Tabela 3.4 Nomenclatura dos Registradores

  Nome Descrição ARB Armazenador do apontador do registro auxiliar.

  ARP Apontador do registro auxiliar. C Bit de transporte ( Carry ). 15 14 13 12 11 10 09 08 07 06 05 04 03 02 01 00

  

DP

  INT M OV M OV ARP ST0

  15 14 13 12 11 10 09 08 07 06 05 04 03 02 01 00

  ARB CNF TC SX

  M

  C

XF PM ST1

  DP Apontador da página de dados

  INTM Bit do modo de interrupção. OV Bit de indicação de excesso (overflow). OVM Bit do modo de excesso (overflow). PM Modo do deslocador do produto. SXM Bit do modo de sinal estendido. TC Bit de teste/controle.

  XF Bit do estado do pino XF.

3.7.1.3. Periféricos

  Os periféricos comunicam-se com a CPU através de um barramento específico, pois um grande número de periféricos poderia comprometer a performance do barramento de dados da CPU do DSP TMS320F2407.

  Para isso o barramento de periféricos é independente e opera a uma freqüência menor que a do barramento da CPU. Todos os periféricos, com exceção do gerenciador de eventos, são anexados a este barramento. Para incrementar a performance o gerenciador de eventos é conectado diretamente ao barramento de dados da CPU.

  A seguir tem-se os principais periféricos existentes no DSP TMS320F2407 [Texas Instruments,2001]. No caso do controlador CAN, serão apresentados maiores detalhes em uma seção a parte mais adiante no capítulo.

  Conversor A/D

  O DSP TMS320F2407 possui apenas um conversor Analógico/Digital de 10 bits, de aproximação sucessiva, sendo possível selecionar entre as 16 entradas multiplexadas qual O tempo de amostragem e conversão é de 375 ns. Além disso, o início de conversão pode ocorrer por software, ou então, iniciar uma conversão através de algum evento do gerenciador de eventos (EV) assim como de sinal externo. Existem ainda 16 registradores que são utilizados para armazenar o resultado da conversão da entrada equivalente

  Existem duas possibilidades de seqüenciamento para o conversor, em modo cascata, como mostrado no diagrama funcional da figura 3.7, e modo dual onde tem-se dois seqüenciadores com capacidade para selecionar 8 entradas cada um. Da figura 3. 7 destacam-se os seguintes componentes :

  : Este módulo controla a operação dos

  Selecionador de seqüência de conversão

  demais. Envia para o módulo de entrada a seqüência de seleção da entrada programada, além disso, envia o sinal para o início de conversão ( SOC ) para o conversor analógico/digital e recebe do mesmo o sinal de fim de conversão ( EOC ). Também é responsável pela seleção para qual dos 16 registradores o sinal convertido será enviado. O início do processo de conversão pode ocorrer através de software, de algum evento de qualquer um dos gerenciadores de eventos ( EVA ou EVB ) ou mesmo de um sinal externo ( pino ADCOC ).

  

Multiplexador Analógico : Utilizado para fazer a multiplexação das 16 entradas analógicas

  de acordo com a seleção programada, enviando o sinal correspondente para o próximo estágio, de amostra e retenção; : Unidade que faz a amostragem e

  Unidade de Amostragem e retenção e conversão A/D

  retenção do sinal analógico e converte a informação para digital de 10 bits, em um tempo estimado de 375 ns. Este processo ocorre depois de receber o sinal de início de conversão ( SOC), quando finda, a mesma envia de fim de conversão ( EOC ) para o selecionador de seqüência de conversão.

  Registradores do resultado de conversão : São registradores de 16 bits utilizados para

  armazenar o resultado da conversão da entrada correspondente. Sendo os registradores de 16 bits o resultado, de 10 bits, é armazenado nos 10 bits mais significativos, B15 até B06.

  Multiplexador Multiplexador p/ Analógico Selecionar Destino

  ADCIN RESULT ADCIN Unidade S/H e

  1 ADCIN Conversor A/D RESULT

  2 .

  RESULT .

  . . . . ADCIN1

  RESULT

MUX Selecionador

  5 Auto-

  seqüênciador MAX_CONV

  Chave Sel. 0 Chave Sel. 1 Chave Sel. 2 Chave Sel. 3 .

  . .

  Chave Sel. 15 Software EVA EVB Pino

Figura 3.7 Conversor A/D

  Módulo SPI

  O padrão de comunicação serial SPI ( Serial Peripheral Interface ) foi desenvolvido pela Motorola e atualmente se encontra presente em diversos processadores. Ele opera em modo full duplex, ou seja, a comunicação se processa em ambas as direções simultaneamente. Este tipo de protocolo é muito útil para comunicação com periféricos como EEPROM, conversor Digital/Analógico e Analógico/Digital, assim como mostradores digitais.

  O módulo SPI se comunica utilizando o modelo Mestre/Escravo, sendo que o Mestre inicia a mensagem selecionando um dispositivo, dados podem ser transferidos em ambas as direções. Na figura 3.8 encontra-se um diagrama funcional do módulo SPI do DSP TMS320F2407.

  SPI Mestre SPI Escravo SPISISMO SPISISMO

  Buffer de Buffer de

  Entrada Entrada

  SPISTE SPISTE (SPIRXBUF) (SPIRXBUF)

  Registrador Registrador SPISOMI SPISOMI de de

  Deslocament Deslocament SPICLK SPICLK

  

Buffer de Buffer de

Transmis Transmis

  Processador Processador

Figura 3.8 Módulo SPI

  • SPISIMO : entrada SPI escrava, saída mestre;
  • >SPISOMI : saída SPI escrava, entrada mes
  • SPICLK : pulso do CLOCK;
  • SPISTE : transmissão da habilitação do escravo

  As etapas de funcionamento para a comunicação entre o mestre e o escravo são as seguintes:

  • O mestre envia um sinal de habilitação através de SPISTE;
  • Tem-se o surgimento, então do sinal de clock no pino SPICLK. Através do

  registrador CLOCK_POLARITY é possível selecionar se a transmissão ocorre na subida ou descida do sinal de clock;

  • Assim de acordo com o sinal do clock a informação armazenada em SPIDAT

  inicia a transmissão através do pino SPISIMO, com o bit mais significativo primeiro.

  • Ao mesmo tempo a informação chega ao escravo através do pino SPISOMI armazenando em SPIDAT do escravo.
  • >Quando o último bit for carregado a informação é armazenada no registrador SPIBUF, onde fica disponível para a
  • Neste instante a interrupção, SPI INT FLAG, é ativa, indicando para a CPU que o dado já está disponível.

  Na figura 3.9 tem-se o formato do dado que é transmitido. Como é síncrono a mensagem não tem outros bits de verificação, simplesmente são os dados que serão enviados.

  Módulo SCI

  O módulo SCI ( Serial Communications Interface ) é o módulo de comunicação assíncrona entre o DSP TMS320F2407 e outros periféricos.

  Através do módulo de comunicação SCI possibilita a transmissão utilizando o transmissor/receptor universal assíncrono (UART), possibilitando sua comunicação com diversos periféricos, como o próprio computador, através da RS-232.

  O módulo de comunicação dos DSP TMS320F2407 possui algumas características:

  • • O Comprimento da palavra de dados é programável entre 1 e 8 bits;

  • >Bits de parada ( stop bit ) programável de 1 ou dois b
  • Transmissão de dados em half ou full duplex;
  • Velocidade de transmissão programável;

  O formato da mensagem varia dependendo do modo de operação, o IDLE ou ADRESS, sendo que segundo modo tem-se um bit a mais indicando se a mensagem é o endereço do receptor ou se é simplesmente um dado. Na figura 3.10 encontra-se o formato da mensagem, com os bits divididos em:

  • Start bit: bit de partida, indicando o início da mensagem;
  • >Os 8 bits de mensagem, do menos significativo (LSB) até o mais significativo (M
  • O bit de paridade, sendo que este bit é opcional, podendo ser habilitado ou
  • O stop bit, que é bit que indica o final da mensagem.

Figura 3.10 Formato de mensagem SCI

  A conexão entre os módulos é feita através de dois pontos, conforme pode-se observar na figura 3.11.

  Os pinos de conexão são: SCITXD: É a pino para a saída de dados da SCI; SCIRXD: É o pino para a entrada de dados da SCI;

  Além disso, pode-se identificar os seguintes blocos na figura 3.11 : SCITXBUF : é o registrador para armazenamento dos dados a serem transmitidos.

  A CPU do DSP salva os dados neste registrador para que o mesmo possa ser enviado futuramente; TXSHF: é o registrador de deslocamento que faz a transmissão dos dados. Ele recebe os dados do registrador SCITXBUF enviando os mesmos através do pino SCITXD RXSHF: é o registrador de deslocamento que faz a recepção dos dados. Ele recebe

  Registrador de Deslocamento Transmissor (TXSHF)

  Registrador para Transmissão de Dados (SCITXBUF)

  SCITXD SCIRXD Dispositivo SCI 1

  SCITXD SCIRXD Dispositivo SCI 2

  Registrador de Deslocamento Receptor (RXSHF)

  Registrador para Recepção de Dados (SCIRXBUF)

  Registrador de Deslocamento Transmissor (TXSHF)

  Registrador para Transmissão de Dados (SCITXBUF)

  Registrador de Deslocamento Receptor (RXSHF)

  Registrador para Recepção de Dados (SCIRXBUF)

  SCIRXBUF: é o registrador para armazenamento do dado recebido, ficando disponível para a CPU do DSP fazer a leitura.

Figura 3.11 Módulo SCI

  O tratamento de erros é feito através de quatro mecanismos:

  • Erro de paridade: ocorre quando tem-se alguma falha na transmissão

  detectada pela diferença entre o número de bits em nível lógico 1 em relação ao seu bit de paridade transmitido;

  • Erro de overrun : este erro ocorre quando um novo dado é recebido e

  transferido para o registrador SCIRXBUF sem que a CPU tenho lido totalmente o dado do registrador. O novo dado sobrescreve o anterior, perdendo-se a informação anteriormente recebida;

  • Erro de mensagem : ocorre quando o bit de parada esperado não é

  encontrado. Apenas o primeiro bit de parada é verificado;

  • Erro de quebra: este erro ocorre quando o pino de entrada permanece em nível lógico baixo por pelo menos dez bits, após a falha do bit de parada.

  Módulo Watchdog

  O watchdog é um temporizador que monitora as operações de software e hardware e implementa as funções de reset do sistema. Principalmente em processos críticos onde a parada por falhas no programa possa acarretar conseqüências desagradáveis, a utilização do watchdog é essencial. Particularmente no caso do DSP TMS320F2407 sua utilização é importante pois poderá proteger em aplicações de controle de motores, tanto o motor quanto o módulo de potência, se a CPU entrar em loop infinito, pois fará com que o DSP entre reinicialize, e assim as saídas PWM entrarão em estado de alta impedância, cortando todos os sinais que vão para o módulo de potência.

  Sendo habilitado, o temporizador do watchdog irá começar a contar imediatamente após a inicialização. Com o clock do watchdog (WDCLK) de 78.125 Hz, tem-se uma faixa selecionável entre 3,28 ms até 209,7 ms para monitorar o programa.

  Gerenciador de Eventos

  O gerenciador de eventos (Event Manager - EV) é um módulo especialmente desenvolvido para controle digital de motores elétricos sendo que suas principais características são:

  • • Possui temporizadores que fornecem a base de tempo para os comparadores e para a

  unidade QEP além da possibilidade de serem utilizados para gerar um período de amostragem do sistema;

  • Unidades Comparadoras são utilizadas para gerar sinal de PWM para disparo de chaves de potências que controlarão os moto
  • • Geração de tempo morto para evitar que duas chaves de potências sejam acionadas ao

  mesmo tempo, gerando assim um curto-circuito entre fases;

  • Unidades especiais para aplicação de controle vetorial;
  • • Unidades de captura que podem ser utilizadas para, por exemplo, iniciar o conversor

  A/D; Unidade QEP (Quadrature Encoder Pulse) são entradas especiais para adquirir o sinal

  • proveniente de um encoder.

  Estes recursos especialmente desenvolvidos para o DSP TMS320F2407 o tornam bastante flexível e ideal para aplicação no controle de motores.

  O DSP TMS320F2407 possui dois gerenciadores de eventos EVA e EVB que são idênticos. Na figura 3.10 tem-se um diagrama em blocos do gerenciador de eventos EVA.

  Reset

  INT 2,3,4 TCLKINA/TDIRA

  Registradores de Controle do ADC

T1CMP/TIPWM

  Comparador do Temporizador Lógica de

  Temporizador GP 1 Saída

  PWM1

  Unidade de Comparação 1 Circuitos Lógica de

  PWM2 PWM3

  Unidade de Comparação 2 Circuitos Lógica de

  PWM4 PWM5

  Unidade de Comparação 3 Circuitos Lógica de

  PWM6 T2CMP/T2PWM

  Comparador do Temporizador Lógica de

  Temporizador GP 2 Saída

  CLK Circuito

  MUX DIR QEP CAP1/QEP1

  CAP2/QEP2 Unidades de

  CAP3 Captura

Figura 3.12 Gerenciador de Eventos

  Na figura 3.12 tem-se os seguintes componentes:

  

Bloco de Registradores de Controle e Lógica : Estes registradores controlam a operação do

  gerenciador de eventos, enviam as interrupções habilitadas para a CPU do DSP, envia o sinal de partida para o conversor analógico/digital; : existem temporizadores de uso geral (GP

  Temporizadores de Uso Geral (GP Timer)

  Timer 1 e 2) que servem de base de tempo para as unidades de comparação e associadas aos circuitos PWM geram as saídas PWM, além o GP Timer 2 fornece a base e tempo para o módulo de leitura de sinal de encoder, Unidade QEP, e as unidades de captura;

  

Saída PWM Simples : Em cada Gerenciador de Eventos tem-se duas saídas de PWM

  simples, independentes, onde cada um fornece somente um sinal de PWM, T1PWM e T2PWM, onde a base de tempo para o primeiro é somente o GP Timer1, mas para o segundo é possível selecionar qualquer um dos dois temporizadores. Ainda fazendo parte deste conjunto tem-se um bloco lógico de saída onde, além de outras coisas, pode selecionar a saída ativa em alto ou em baixo e habilitar o sinal de saída;

  

Saída PWM Completa : Este conjunto fornece seis saídas PWM para aplicações, por

  exemplo, de inversores trifásicos. Com o mesmo princípio de funcionamento do anterior, este módulo possui três módulos de comparação independentes, além do adicional de um módulo interno para geração do tempo morto entre os chaveamentos, um módulo para facilitar a aplicação em controle vetorial, um módulo para selecionar diferentes modos de operação de PWM, seja simétrica ou assimétrica, além do mesmo bloco lógico do anterior, mas agora para as seis saídas;

  : Cada Gerenciador de Eventos tem três entradas em seu módulo de

  Unidades de Captura

  captura. Este módulo serve para medir o intervalo de tempo entre dois eventos (mudança de nível lógico), pois a cada evento o valor do temporizador de referência é carregado em um registrador de dois níveis, assim, com dois eventos tem-se o registrador carregado com o registro de tempo de cada evento.

  

Unidade de Leitura de Encoder : Esta unidade serve para fazer a leitura do sinal de um

  encoder incremental, fornecendo a CPU o valor da freqüência e sentido de rotação, horário ou anti-horário, poupando assim tempo de processamento para interpretação do sinal.

3.7.2. Interrupção

  A interrupção é uma suspensão do ciclo de execução normal do software. Através da interrupção pode-se evitar a necessidade de constantemente ter que, por exemplo, monitorar um dos terminais de entrada do DSP. Habilitando a interrupção adequada, quando tem-se a alteração do nível lógico do terminal de entrada, ocorrerá uma interrupção para uma subrotina adequada. Além do mais, existem várias interrupções no DSP que estão associadas a eventos no funcionamento seja da CPU, como dos diferentes periféricos.

  O DSP TMS320F2407 possui dois sinais não mascaráveis ( RS e NMI ) , que não podem ser desabilitadas, e seis mascaráveis (INT1 à INT6), que podem ser programadas.

  O sinal

  • de RS ocorre quando um sinal externo solicita que o DSP seja reiniciado ou então pelo contagem do watchdog, indicando que o mesmo passou do tempo estipul
  • A interrupção associada a NMI ocorre quando tem-se um endereçamento incorreto na programação.
  • Os sinais de interrupção INT1 à INT6 são associados a diferentes fontes de sinas de

  interrupção, sejam elas internas ou externas. Na figura 3.11 tem-se um esquema básico das entradas associadas para cada interrupção.

  Devido ao número de interrupções existentes, há um controlador de interrupções, conhecido como Peripheral Interrupt Expansion (PIE - Expansão das Interrupções dos Existem dois grupos básicos de interrupção:

  • Interrupção associada ao Gerenciador de Eventos (EV): Neste grupo estão as

  diversas interrupções geradas pelo Gerenciador de Eventos, através de seus temporizadores, comparadores e unidades de captura. Além disso, para cada um dos Gerenciadores de Evento (EVA e EVB) um sinal externo (PDPINTA e PDPINTB) que pode ser utilizado, por exemplo, para o sinal de sobrecorrente do módulo de potência controlado pelo sinal de PWM de algum dos gerenciadores. Este sinal externo controla diretamente a habilitação da saída PWM, levando as mesmas ao estado de alta impedância quando o mesmo estiver presente, diminuindo o tempo de resposta do DSP.

  • Interrupção não associada ao Gerenciador de Eventos (Não EV) : Estas

  interrupções são geralmente associadas aos periféricos do DSP, ou então a dois sinais externos (XINT1 e XINT2). Este sinal ainda é dividido em alta e baixa prioridade. Isto é feito para ampliar o leque de opções e possibilitará a níveis diferentes de interrupção.

Figura 3.13 Interrupção

  PIE CPU Comparadores Comparadores 1,2,3 4,5,6 Temporizador 1 Temporizador 3 Temporizador 2 Temporizador 4 EV Unidade de Unidade de Captura 1,2,3 Captura 4,5,6 PDPINTA

  PDPINTB

  XINT1 1,2 (Alta Prioridade) SPI,SCI,CAN, ADC (Alta Prioridade )

  XINT1 1,2 (Baixa Prioridade) Não ADC (Baixa Prioridade ) EV SPI,SCI,CAN (Baixa Prioridade)

  Quanto a latência da interrupção deve-se considerar três fatores:

  • • A sincronização, que é o intervalo de tempo desde a solicitação de uma interrupção

  por algum periférico, devido a algum evento que a ocasionou , até que a solicitação é reconhecida pelo controlador PIE e convertida em uma solicitação à CPU;

  • • O tempo necessário para que a CPU reconheça a interrupção e inicie a captura da

  primeira instrução da tabela de interrupção da CPU; • E ainda o tempo necessário para obter o código específico da interrupção desejada. Uma discussão mais detalhada sobre o princípio de operação da interrupção, registradores envolvidos e fluxograma de operação encontra-se em [Texas Instruments, 2001].

3.8. PROGRAMAđấO DO TMS240F24X

3.8.1. Etapas para o desenvolvimento de um programa

  A programação dos DSPs introduziram um conceito chamado de COFF (Common Object File Format), onde o programa é dividido em seções, permitindo assim que diferentes times de desenvolvedores de software possam trabalhar em diferentes partes do programa, e no momento apropriado estes programas são ligados.

  A estrutura básica para elaboração de um programa para o DSP da Texas Instruments pode ser observada na figura 3.14.

  Plataforma de Desenvolvimento .cmd

  .obj .out .asm

  Editor de DSPA DSPLNK Debug

  Texto .c

  .lst .map

  DSPCL

Figura 3.14 Etapas para programação do DSP

  Os blocos que compõe as diferentes etapas de obtenção do arquivo executável para o DSP são descritos a seguir:

  • Editor de texto : o programa é digitado no editor de texto, cabendo ao

  usuário escolher a programação em assembly, salvando o arquivo com extensão .asm, ou então em linguagem C, salvando o programa com extensão .c ;

  • DSPCL : Através deste aplicativo o programa em linguagem C é

  compilado passando para assembly;

  • DSPA : Através deste bloco o programa em assembly é montado,

  verifica-se os erros como de sintaxe. Não havendo erros gera-se um arquivo objeto em linguagem de máquina, com extensão .obj;

  • DSPLNK : Através deste bloco os diferentes arquivos objetos são

  ligados junto ao arquivo com extensão .cmd que identifica os recursos existentes no processador e onde as diferentes seções de cada módulo são alocadas. Como resultado obtém-se um único arquivo executável, com extensão .out, que é carregado no DSP pela ferramenta de desenvolvimento para assim poder executar o programa. Para programação do DSP TMS320F2407 pode-se optar por fazer sua programação em assembly ou em linguagem C. A facilidade de programação em linguagem de alto nível, com a linguagem C, tem tornado a escolha mais lógica pelos programadores, mas a programação em assembly é o ideal para aplicações em tempo real. O problema é que o desenvolvimento em assembly consome muito mais tempo de programação, além da necessidade de se conhecer profundamente a arquitetura do DSP, assim, muitas vezes opta- se por desenvolver o aplicativo em linguagem C e alguns pontos críticos utilizar rotinas em assembly .

3.8.2. Estrutura de um Programa em Assembly

  Um programa em assembly pode ser dividido em três seções principais: apropriada. Para se definir uma seção deve-se utilizar uma diretiva, que é um comando em assembly, e para este caso deve-se utilizar a diretiva .text. A seção definida por esta diretiva é enviada para a memória do programa.

  • Dados inicializados : são as constantes do programa mas que também podem ser

  utilizadas como valores iniciais para variáveis. Assim como no caso anterior também deve-se definir uma seção de constantes através de uma diretiva, no caso a diretiva .data, e depois, reservar-se uma área na memória utilizando outra diretiva, por exemplo, pode-se utilizar a diretiva .int. Esta seção também é armazenada na memória de programa.

  • Dados não-inicializados: São as variáveis do programa, que poderão ser alteradas

  pela execução do programa. Para reservar uma área na memória também deve-se utilizar uma diretiva, neste caso, a diretiva .bss. O espaço é reservado na memória de dados do DSP. Na figura 3.15 pode-se observar a divisão das diferentes seções para suas respectivas áreas de memória

  Memória de Programa Memória de Dados Flash

  RAM

  .bss .data

  .text

Figura 3.15 Divisão de seções do programa

3.8.3. Modos de Endereçamento

  Para o acesso a memória do DSP existem diferentes modos de acesso, cabe ao programador selecionar o modo adequado para as diferentes situações.

  Os três modos de endereçamento são:

  • Modo de Endereçamento Imediato - Modo de endereçamento Direto - Modo de Endereçamento Indireto

  Modo de Endereçamento Imediato

  No modo de Endereçamento Imediato utiliza-se diretamente as constantes, que podem ser endereçamento imediato curto ou longo.

  No caso endereçamento imediato curto a constante tem 8, 9 ou 13 bits, e a instrução requer apenas um registro de instrução, assim será realizada em apenas um ciclo de clock. No caso de endereçamento imediato longo a constante tem 16 bits sendo necessário dois registros de instrução que terão que ser enviados, assim serão necessários dois ciclos de clock. ADD #08h ADD #2543h

  Modo de Endereçamento Direto divididos em 512 páginas de 128 palavras, com índices de 0 até 511, como pode-se observar na figura 3.16. A página que estiver sendo utilizada é determinada pelo apontador da página de dados (Data Page Pointer – DP), de 9 bits que se encontra no registrador de status ST0.

  Pag.

  512

  511 Páginas

  Pag. 2 Pag. 1 Pag. 0 128 Words

Figura 3.16 Paginação de memória

  Assim, se houver a necessidade de acessar determinada página é necessário carregar inicialmente a página, para depois utilizar o offset na posição desejada.

  Para carregar a página utiliza-se a instrução LDP (Load Data Page Pointer) pelo menos uma vez, e deverá ser carregada toda vez que for necessário mudar de página. O

  

offset para a posição desejada é dada pelos 7 bits menos significativos do registrador IR

(Instruction Registrer).

  Endereçamento Indireto

  Para o endereçamento Indireto de memória são utilizado os oito Registradores Auxiliares AR0, AR1 . . . AR7, e para o DSP saber qual dos registradores utilizar é utilizado o apontar de registrador auxiliar (Auxiliar Register Pointer - ARP) de três bits do

  Para carregar o Registrador Auxiliar com determinado endereço da memória utiliza-se a instrução LAR (Load AR).

3.9. CONTROLADOR CAN DO DSP TMS320F2407

  O controlador CAN do DSP TMS320F2407 é o dispositivo que implementa as camadas 1 e 2 do protocolo de comunicação CAN. Dentro de suas características pode- se destacar as principais:

  • Possibilidade de implementação do padrão 2.0 A ou 2.0 B

    • Seis mailbox, registradores para armazenar os dados a serem enviados ou recebidos,

  com comprimento programável de 0 até 8 bytes. Dois registradores para transmissão, dois para recepção e dois programáveis tanto para transmissão ou recepção e mensagens;

  • Filtros para recepção de mensagens individuais para cada mailbox de recepção;
  • Retransmissão de mensagens automática ;

  Diagnóstico de erro, seja na mensagem ou no barramento CAN;

  • Modo de auto-teste;

3.9.1. Arquitetura do controlador CAN A arquitetura do controlador CAN dos DSP está representada na figura 3.17.

Figura 3.17 Controlador CAN

  O sistema é composto pelos seguintes componentes:

  • CPU Interface/ Memory Management Unit: responsável para a comunicação com a

  CPU do processador e gerenciamento da unidade de memória;

  • Control/status Registers Interrupt Logic: onde se localizam os registradores de status e controle do sistema, além da lógica que gera as devidas interrupções;
  • Transmit Buffer: Buffer de transmissão de dados, onde os dados são armazenados temporariamente aguardando serem transmitidos;
  • CAN Core: é o núcleo do modulo de comunicação da rede, que se comunica com o chip que faz a interface com a rede;
  • Temporary Receive Buffer: é o buffer de recebimento das mensagens, onde as mesmas são analisadas para verificar sua validade;
  • Acceptance Filter: é o filtro utilizado para verificar se as mensagens recebidas interessam ou não ao processador;
  • CAN Transceiver Chip: é o chip responsável para adequação do sinal do

  • Mailbox RAM: banco de memória de 16 bits onde ficam armazenadas as informações que serão enviadas ou recebidas;

3.9.3 Mapa de memória do controlador CAN

  Registradores

  CAN

  Área Reservada

  Mailbox 0 Mailbox 1 Mailbox 2 Mailbox 3 Mailbox 4 Mailbox 5

  CANMDER CANTCR CANRCR CANMCR CANBCR1 CANBCR2 CANESR CANGSR CANCEC CAN_IFR

  CAN_IMR CANLAM0H CANLAM0L CANLAM1H CANLAM1L Reservado

  MSG_ID5L MSG_ID5H MSG_CTRL0 Reservado

  MBOX5A MBOX5B MBOX5C MBOX5D

  Os registradores para rede CAN estão mapeados na memória de dados do DSP TMS320F2407 entre os endereços 7100h e 7230h, com distribuição conforme a figura 3.18.

  Figura. 3.18 Mapa de memória do controlador CAN Além disso, cada mailbox tem associado um conjunto de registradores utilizados para armazenar os identificadores de cada mensagem além dos bytes de compõe a mensagem a

3.9.4. Registradores do controlador CAN

  O modulo CAN contém 15 registradores de 16 bit, divididos em:

  • Registradores de controle
  • Registradores de status
  • Registradores de interrupção
  • Registradores de liberação local

  A seguir será apresentado um resumo da função de cada um, um maior detalhamento de cada um pode ser encontrado em [Texas Instruments, 2001].

  Registradores de Controle

  • MDER (Mailbox Direction/Enable Register): para habilitar ou desabilitar cada

  mailboxes e para configurar as mailboxes 2 e 3 quanto a sua utilização para

  transmissão ou recepção;

  • TCR (Transmission Control Register): utilizada para controlar o processo de

  transmissão de mensagens. Para cada mailbox que pode transmitir tem-se um bit associado que indica se a mensagem foi enviada com sucesso ou se foi abortada. O início da solicitação de transmissão de um mailbox é feito através deste registrador.

  • RCR (Receive Control Register): utilizada para controlar o processo de recepção

  de mensagens. A recepção ou perda de mensagem de cada mailbox é sinalizada por este registrador. Além disso a sinalização de sobrescrita de mensagem, e de sua proteção também é feito aqui.

  • MCR (Master Control Register): para alterar o comportamento do núcleo do
possibilidade de controlar se o controlador desliga depois de enviar a mensagem, além da ordem de envio dos bytes de mensagem de um mailbox;

  • BCR1 e BCR2 (Bit Configuration Register): utilizado para configurar a

  temporização do bit da rede CAN. Com este registrador controla-se a velocidade da rede, além dos ajustes para sincronização da mensagem;

  Registradores de status

  • ESR (Error Status Register): Através deste registrador os diferentes tipos de erros

  como, de forma, de bit, CRC, stuff , entre outros, são sinalizados. Mas somente o primeiro erro é sinalizado, com a ocorrência dos outros não tem-se a alteração do registrador.

  • GSR (Global Status Register): Com este registrador é possível por exemplo, se o

  módulo está recebendo ou transmitindo uma mensagem além disso se é possível alterar a configuração dos registradores BCR, além de outras funções.

  • CEC (CAN Error Counter Register): Este registrador é o contador de erros seja de

  transmissão ou recepção, com o limite de 128 para cada um deles;

  Registradores de Interrupção

  • IFR (Interrupt Flag Register): Este registrador sinaliza se qualquer uma das enviou ou recebeu corretamente, além de servir como flag (sinalizador)

  mailboxes

  para as interrupções de erros como erro de recepção de mensagem, erro de escrita no mailbox, além de outros;

  Registrador de liberação local

  • LAM0H e LAM0L (Local Acceptance Mask Register): Através destes

  registradores é possível mascarar os bits identificadores para recepção, permitindo a recepção de grupos de mensagens. Estes registradores controlam a recepção dos

  mailboxes 0 e 1;

  • LAM1H e LAM1L (Local Acceptance Mask Register): Assim como o anterior,

  estes registradores são utilizados para mascarar os bits identificadores para recepção, permitindo a recepção de grupos de mensagens. Mas estes registradores controlam a recepção dos mailboxes 2 e 3;

3.9.5. Mailbox

  O controlador CAN utiliza o mailbox como registradores temporários para transmissão e recepção de dados, tendo ao todo 6 mailboxes. Para transmissão utiliza os

  

mailboxes 4 e 5, e para a recepção os mailboxes 0 e 1. Os mailboxes 2 e 3 são

configuráveis, ou seja, estão disponíveis tanto para transmissão quanto para recepção.

  Cada mailbox tem a estrutura apresentada na tabela 3.5, onde n pode variar entre 0 e 5.

  Tabela. 3.5 Registradores associados a cada mailbox MSG_IDnL MSG_IDnH

  MSG_CTRLn Reservado MBOXnA MBOXnB MBOXnC MBOXnD

  • MSGIDnL e MSIDnH (Message Identifier for Low and High Word) : Estes registradores contém o identificador do mailbox, podendo ser o padrão, com 11 bits, ou o estendido, com 29 b
  • MSGCTRLn (Message Control Filed) : Contém o número de bytes da

  mensagem, para transmitir ou receber, e a identificação se a mensagem é de dados ( Data Frame) ou é uma mensagem de resposta (Remote Frame);

  • MBOXnA até MBOXnD contém os dados. Os dados são divididos em quatro palavras ou oito bytes.

  Na tabela 3.6 tem-se os endereços dos registradores associados a cada mailbox.

Tabela 3.6 Endereços da memória de cada mailbox

  Mailboxes

Registradores MBOX_0 MBOX_1 MBOX_2 MBOX_3 MBOX_4 MBOX_5

  MSG_IDnL 7200 7208 7210 7218 7220 7228 MSG_IDnH 7201 7209 7211 7219 7221 7229 MSG_CTRLn 7202 720A 7212 721A 7222 722A

  Reservada MBOXnA 7204 720C 7214 721C 7224 722C MBOXnB 7205 720D 7215 721D 7225 722D MBOXnC 7206 720E 7216 721E 7226 722E MBOXnD 7207 720F 7217 721F 7227 722F

  Cada registrador MBOXnA até MBOXnD tem 16 bits, armazenando a informação de dois bytes de mensagem, totalizando os oito bytes de comprimento máximo da mensagem a ser transmitida.

  

CAPÍTULO 4

MONTAGEM E TESTES BÁSICOS COM A REDE CAN

  4.1 INTRODUđấO

  Neste capítulo serão abordados os primeiros passos para elaboração de uma rede CAN utilizando DSPs. Serão apresentados os algoritmos básicos que foram implementados para configuração do DSP e do controlador CAN do DSP, assim como as bibliotecas básicas criadas as com diferentes funções que permitiram trabalhar com os diferentes periféricos existentes no DSP.

  4.2 PLATAFORMA DE DESENVOLVIMENTO

  Para permitir o desenvolvimento da aplicação foi utilizada a plataforma de desenvolvimento da Texas Instruments, que consiste em conjuntos conhecidos como

  starter kits DSK. Foi utilizado um kit denominado de eZdspTM LF2407, que consiste

  de uma placa, conforme a figura 4.1 e de um software, conhecido como Code Composer, que permite a programação e depuração de programas na placa de teste.

  As características básicas da placa são:

  • Processador DSP TMS320LF2407;
  • Velocidade 30 MIPS;
  • Memória RAM de 64 K words;
  • Memória Flash on-chip de 32 K words;
  • Oscilador 7,3728 MHz;
  • Controlador JTAG IEEE 1149.1 incorporado;

  Através da consulta da documentação da placa [Spectrum Digital, 2000] pode-se ter maiores informações para a utilização da mesma.

  Como comentado, o software utilizado para o desenvolvimento do projeto é o Code Composer, que é um ambiente de programação que trabalha cada programa como um projeto, como pode ser visto na figura 4.2.

  Através da filosofia de desenvolvimento de projeto é possível compor a programação que se utiliza com os diversos programas necessários além do arquivo fonte do programa, como, por exemplo, o arquivo dos vetores de interrupção, bem como, dos registradores do DSP.

  Além das placas de DSP, foram utilizadas placas adicionais que permitiram a conexão do DSP ao barramento CAN e também com chaves e leds, que foram utilizadas para simular diferentes funções no projeto. Tem-se na figura 4.3 um esboço da placa PL1.

  C1

  Placa PL1

  CHAVES LEDS Transceiv er CAN

  C2

Figura 4.3 Esboço da placa PL1

  Do esboço da placa PL1 pode-se identificar alguns componentes:

  • Conector C1: Utilizado para fazer a conexão da placa com a placa do DSP;
  • Conector: Saída da placa PL1 para a conexão com a rede CAN;
  • Barramento de leds : É um conjunto de 8 leds que estão conectadas à PORT E do DSP, através do conector C1;

  • Transceiver CAN : É o circuito integrado responsável pela adaptação do sinal CAN TTL do DSP para as características elétricas do barramento CAN; Na figura 4.4 tem-se uma foto da placa PL1.

Figura 4.4 Foto da placa PL1

  4. 3. CONFIGURAđấO DO DSP

  Para iniciar a operação do DSP é necessário informar ao compilador alguns requisitos para que o mesmo possa fazer as alterações de parâmetros necessárias no processador através do programa gerado. Para facilitar o uso na programação da rede CAN, foi criada uma função de inicialização genérica do DSP, chamada ini_dsp ( ). Assim, sendo necessária a alteração de algum parâmetro, seja habilitar algum periférico ou alterar o CLOCK de trabalho do processador, nesta função estão os parâmetros para fazer as alterações desejadas. Na figura 4.5 tem-se o algoritmo da função com os

  INICIALIZAđấO DO DSP ini_dsp ( ) INÍCIO

  INTM=1 WDCR=06h WSGR=00h Configurar SCR1 MCRA, MCRB MCRC Inicializar FIM

  Figura 4. 5. Algoritmo da função de inicialização do DSP Como principais etapas do processo de inicialização do DSP pode-se ressaltar:

  a) Desabilitar a interrupção do DSP fazendo que o bit INTM seja levado ao valor unitário. IsSo é muito importante para que as interrupções somente ocorram a partir do instante que, tanto o processador, quanto os periféricos, estejam programados, tento-se assim o tratamento da interrupção adequado; b) Desabilitar o watchdog ;

  c) Alterar o registrador SCR1, que é responsável pelo fator de multiplicação da freqüência interna a ser utilizada pelo DSP, e por ativar os periféricos. Assim, inicialmente é necessário habilitar o módulo do periférico da rede CAN. Depois gerenciador de eventos, para trabalhar com os temporizadores, ou com sinal PWM, é necessário alterar novamente o registrador SCR1;

  d) Como não será utilizada nenhuma memória externa pode-se zerar o valor do registrador WSGR, que gera os atrasos para acesso ao barramento externo; e) Como opcional, foi incluída, ainda, nesta função, a parametrização das entradas e saídas digitais do sistema. E, como no caso anterior, se for utilizada alguma entrada analógica ou saída PWM, será necessário fazer as devidas alterações na configuração deste registrador. Na figura 4.6 tem-se a função de inicialização do DSP, já com os valores atribuídos para a configuração desejada.

  void ini_dsp(void)

  { asm (" setc INTM"); /*Desabilita todas as interrupções */

  • WDCR= 06Fh;

  /* Desabilita o watchdog */

  • SCSR1= ((CLKSRC<<14)+(LPM<<12)+(CLK_PS<<9)+(ADC_CLKEN<<7)+

  (SCI_CLKEN<<6)+(SPI_CLKEN<<5)+(CAN_CLKEN<<4)+ (EVB_CLKEN<<3)+(EVA_CLKEN<<2)+ILLADR);

  /* Neste registrador faz-se a seleção do CLOCK utilizado, além da habilitação de cada um dos periféricos */ WSGR = 0000h; /* Ajusta waitstates – Não utiliza memória externa */

  /* Configuração das entradas/saídas digitais */

  • MCRA = 0000h; /* Inicializa MCRA (Master Control Register A ) */
  • MCRB = 00C3h; /* Inicializa MCRB (Master Control Register B ) */
Algumas observações podem ser feitas em relação a função de inicialização da figura 4.6.

  Para desabilitar a interrupção utilizou-se uma instrução em assembly do bit

  • INTM do registrador ST0; • Como não está prevista a utilização do watchdog, o mesmo foi desabilitado.

  Com uma consulta à [Texas Instruments, 1999] pode comprovar os valores atribuídos;

  • No registrador SCR1 habilitam-se os diferentes periféricos. Como em alguns

  casos utiliza-se a entrada analógica convencionou-se que ficarão ligados, além do controlador CAN , o módulo de A/D e gerenciadores de eventos A e B;

  • Como não será utilizada a memória externa, o tempo de espera, waitstate, foi

  zerado; Como padrão as saídas foram configuradas para o acesso as saídas, através de

  • MCRA, MCRB e MCRC, para a rede CAN, a PORT A do DSP como entrada e a PORT E como saída.

  4. 4. MONTAGEM DE UM NÓ

  Para se obter um nó, foram ligados, através de um cabo, o conector P8 da placa de DSP e o conector C1 da placa PL1, conforme tem-se na figura 4.7.

  Placa de P8 C1

  Placa PL1 C2

Figura 4.7 Esquema de ligação para obtenção de um nó da rede Como o transceiver se encontra na placa PL1, a placa de DSP envia o sinal digital para a placa PL1, e está por sua vez conecta-se à rede através do conector C2. Na figura 4.8 tem-se o esquema de ligação entre dois nós, formando o esquema básico de uma rede CAN com dois nós, que será utilizado futuramente para o teste dos primeiros algoritmos.

  Placa de Placa de P8 P8 C1 C1

  Placa PL1 Placa PL1

C2 C2

Figura 4.8 Esquema de ligação entre dois nós

  Após a montagem do esquema anterior a parte de montagem física da rede está completa. Pode-se passar para a próxima etapa, que é da elaboração do software para configuração do DSP e implementação de algoritmos de teste da rede CAN.

  4. 5. PROCESSO DE CONFIGURAđấO DE PARÂMETROS DA REDE CAN

  O processo de configuração da rede CAN consiste da alteração de parâmetros da rede CAN. Mas, para qualquer alteração desses parâmetros, faz-se necessário que o controlador CAN entre em modo de alteração de parâmetros, o que somente pode ser obtido através de uma seqüência de alteração do valor de determinados registradores. Para isso, tem-se na figura 4.9 o algoritmo para alteração desses parâmetros.

  Pode-se observar que a etapa para alteração dos registradores BCR1 e BCR2, que altera a configuração de velocidade da rede CAN, pode ser dividida nos principais pontos:

Figura 4.9 Algoritmo para inicialização dos parâmetros

  a) Escreve-se 1 no registrador CCR. Através deste comando ocorre uma solicitação ao controlador CAN para entrar em modo de alteração de parâmetros; b) É necessário aguardar um intervalo de tempo para que o controlador CAN reconheça a solicitação e libere a alteração de parâmetros sinalizando através da alteração do registrador CCE para o valor unitário;

  INICIALIZAđấO DA CAN ini_can ( ) INÍCIO

  CCR = 1 Configurar BCR2, BCR1 CCE==1 CCR = 0 CCE==0 FIM N

S

S N INICIALIZA AS MATRIZES DOS MAILBOXES d) Após a alteração de dados deve-se retornar ao modo de operação normal e para isto escreve-se o valor nulo no registrador CCR, solicitando ao controlador para sair do modo de alteração de parâmetro;

  e) Novamente é necessário aguardar que a solicitação seja atendida pelo controlador, que acontecerá quando este alterar o valor do registrador CCE para um valor nulo.

  void ini_can(void)

  { unsigned int i; for (i=0;i<6;i++){ /* programacão dos ponteiros para as mailboxes */

  CANMSGIDL[i] = (unsigned int *)(0x7200 +i*8); CANMSGIDH[i] = (unsigned int *)(0x7201 +i*8);

  CANMSGCTRL[i] = (unsigned int *)(0x7202 +i*8); CANDATA0[i] = (unsigned int *)(0x7204 +i*8); CANDATA1[i] = (unsigned int *)(0x7205 +i*8); CANDATA2[i] = (unsigned int *)(0x7206 +i*8); CANDATA3[i] = (unsigned int *)(0x7207 +i*8);

  } /* Inicialização do registrador MCR ( Master Control Registers ) */

  • CAN_MCR |= ((CAN_SUSP<<13)+(CAN_CCR<<12)+(CAN_PDR<<11)+

  (CAN_DBO<<10)+(CAN_WUBA<<9)+(CAN_CDR<<8)+ (CAN_ABO<<7)+(CAN_STM<<6)+CAN_MBNR ); while((*CAN_GSR & 0x0010) == 0 );

  /* Espera para confirmação da habilitação de CCR para alteração de parâmetros

  • /
  • CAN_BCR2 = CAN_BRP;
  • CAN_BCR1 = ((CAN_SBG<<10)+(CAN_SJW<<8)+(CAN_SAM<<7)+

  (CAN_TSEG1<<3)+(CAN_TSEG2)); /* Inicialização de BCR2 e BCR1 */

Figura 4.10. Função de inicialização da rede CAN

  Da figura 4.10, pode-se observar que na função de inicialização da rede CAN foram criadas matrizes que mapeiam todos os mailboxes existentes, tornando a função mais flexível, pois na eventualidade de se utilizar todos os mailboxes e havendo a necessidade de enviar 8 bytes, a função já está adaptada.

  Além disso, foi utilizada uma função while para monitorar a alteração de determinado bit, para somente depois disso passar para o estágio seguinte.

  4. 6. PROCESSO DE TRANSMISSÃO DE DADOS

  O processo de transmissão de um dado através da rede CAN ocorre em duas etapas:

  • Carga do dado no mailbox. Nesta etapa o dado é carregado no mailbox, define- se o número de bytes da mensagem e o valor do identificador da mensagem.
  • Transmissão. Nesta etapa é feita uma solicitação de transmissão do mailbox

  desejado. O controlador CAN confirma a solicitação da transmissão e aguarda até que o barramento esteja livre e obtenha o controle do mesmo. Quando terminar a transmissão sinaliza o término do processo. Para os testes iniciais para transmissão de uma mensagem utilizou-se o mesmo esquema de ligação proposto na figura 4.8, elaborando-se os dois algoritmos para carga e transmissão da mensagem.

  4. 6.1 Algoritmo para Carga de Dados em Mailbox.

  Para facilitar a utilização durante as diferentes etapas do programa, foi desenvolvido o algoritmo da figura 4.11, de carga de dados no mailbox 5. Havendo a necessidade de se utilizar mais de um mailbox para transmitir, a mesma função pode ser utilizada, bastando-se para isso adequar os endereçamentos dos registradores. a) Solicitação de entrada em modo de alteração de parâmetros. Como na inicialização do controlador, para qualquer alteração do conteúdo dos registradores, é necessário entrar neste modo de operação, caso contrário um erro irá ser gerado no instante em que se for tentar escrever na mailbox; b) Aguardar confirmação de liberação de escrita na mailbox. Se não houver um retorno da liberação, corre-se o risco de, como no caso anterior, gerar um erro por tentativa de escrita;

  CARREGA MAILBOX 5 can_mailbox5 ( ) CCR = 1 INÍCIO CCE==1 N Configurar identificador Escrever dado no MAILBOX e CTRL S

  CCR = 0 CCE==0 N MDER IMR S FIM

  Figura 11. Algoritmo para carregar dados no mailbox 5 c) Nesta etapa tem-se a alteração de parâmetros propriamente dita. Alteram-se os valores dos bits identificadores, dos registradores de controle do mailbox e dos dados a serem transmitidos;

  d) Após a alteração dos parâmetros tem-se a solicitação para entrar em modo de operação, para possibilitar o envio de mensagens; e) Finalizando, faz-se a habilitação do mailbox e da interrupção equivalente; O algoritmo gerou uma função intitulada can_mailbox5( ), da figura 4.12.

  void can_mailbox5(void)

  {

  • CAN_MCR |= 0x0100; /* habilita o acesso ao campo de dados (CAN_MCR-bit 8 = 1) */ /********************************************************/ /* carrega parâmetros do mailbox 5 */
  • CANMSGIDH[5]=((MB5_IDE<<15)+(MB5_AME<<14)+(MB5_AAM)+ (MB5_ID_STD<<2));
  • CANMSGIDL[5]= MB5_ID_EXTL; /**** bits de identificação da mensagem *****/
  • CANMSGCTRL[5]=0x0001;

  /* Bit 4 : RTR = 0 : define que é um data frame */ /* Bits 3-0 : DLC = 0001 = 1 Byte a ser transmitido */

  • CANDATA0[5] = 0x00aa; /* DADO A SER TRANSMITIDO */ /********************************************************/ /* desabilitar o acesso ao campo de dados(CAN_MCR bit 8 = 0) */
  • CAN_MCR &= 0xFEFF ;

Figura 4.12. Função de carga de dados no mailbox 5

  • Na habilitação do registrador MCR deve-se utilizar uma função OU com o próprio

  registrador, preservando, com isso, dados presentes, pois pode-se ter um outro bit ativo anteriormente em outra situação;

  • Pode-se observar o reflexo da flexibilização durante a configuração dos

  registradores CAN, pois agora para salvar algum valor em um dos mailbox basta salvar na matriz, com o índice adequado;

  • Um fato que deve ser observado é na definição do número de bytes a ser

  transmitido, feita no registrador CANMSGCTRL;

  • Também nos bytes a serem transmitidos, deve-se fazer a alteração no registrador

  CANDATA0 , e até adicionando ou outros registradores, se for necessário enviar mais dados;

  • Também na habilitação do mailbox e de sua respectiva interrupção, faz-se

  necessário utilizar uma função lógica OU com o próprio registrador, preservando alterações passadas.

4.6.2 Algoritmo para Transmissão de Dados do Mailbox 5.

  O processo de transmissão de uma mensagem pelo mailbox, após os dados terem sido carregados, é feito uma solicitação ao controlador CAN para que determinado nó tenha acesso ao barramento. Quando este atende a solicitação, inicia-se a disputa do controle do barramento pelo nó em questão, que vai depender do identificador da mensagem a ser transmitida. Após o término da transmissão, o nó é informado se a transmissão foi feita com sucesso. Na figura 4.13 tem-se o algoritmo para transmissão do mailbox 5.

  Através do algoritmo pode-se identificar as seguintes etapas: a) Inicialmente tem-se a solicitação para a transmissão de um dado, colocando o bit equivalente no registrador TRS em 1; b) Como segunda etapa é necessário aguardar a liberação para transmissão por parte do controlador; c) Após o reconhecimento da solicitação de transmissão inicia-se o processo de negociação da mensagem com a rede CAN, onde irá prevalecer as mensagens de maior prioridade. Quando esta etapa for finalizada, o flag equivalente do mailbox no registrador IFR será ativado; d) Finalizando, deve-se zerar a interrupção associada ao mailbox;

  TRANSMITE MAILBOX 5 TRSn = 1 can_transmit5 ( ) INÍCIO TCR==1 S S N

  IFR==0 TA = 1 FIM N

Figura 4.13 Algoritmo para transmissão de mensagem pelo mailbox 5

  Do algoritmo resulta em uma função de transmissão do mailbox 5, can_transmit ( ), utilizar a mesma seqüência, bastando apenas ajustar os bits para a mailbox desejada [Texas Instruments, 2000].

  Na função de transmissão, na figura 4.14, pode-se observar a utilização de dois laços while onde tem-se, inicialmente aguardando a resposta do processador, a solicitação de transmissão de uma mensagem, e a outra, aguardando a confirmação que a mensagem foi enviada. Deve-se observar ainda que, quando for feito o reset, um outro flag do registrador pode estar ativo, por isso, novamente foi utilizado uma função OU, preservando o restante dos dados. Se for utilizado o processo de polling para a transmissão de dados não se utiliza o flag de transmissão [Texas Instruments, 2000].

  void can_transmit5(void)

  {

  • CAN_TCR = 0x0080; /* Solicitação de transmissão(TRS)mailbox#5 */ while((*CAN_TCR & 0x8000) ==0); /* espera ACK de transmissão */

  /* mailbox #5 : Bit 15 = 1 */ while((*CAN_IFR &= 0x2000)==0); /* espera por Flag do mailbox5 --> MIF5= 1 */

  • CAN_TCR |= 0x8000; /* Reset TA e flag de interrupção associado */

Figura 4.14 Função para transmissão do mailbox 5

4.7. PROCESSO DE RECEPđấO DE DADOS

  Assim como no processo de transmissão, tem-se duas etapas a cumprir. Inicialmente é necessário que seja feita a configuração do mailbox com os parâmetros adequados para a recepção da mensagem, para, posteriormente, quando a interrupção por mensagem recebida for ativada, fazer a transferência do conteúdo dos registradores de dados do mailbox para variáveis utilizadas para tal fim.

4.7.1 Configura Mailbox para Recepção

  Nesta etapa de configuração da mailbox de recepção, faz-se a atualização dos bits identificadores de recepção de mensagens, além da definição se será ou não utilizada uma máscara de recepção, e também a definição se a interrupção associada ao mailbox será de baixa ou alta prioridade.

  Na figura 4.15 tem-se o algoritmo com as etapas para configuração do mailbox 0.

  CONFIGURA MAILBOX 0 - RECEPđấO ini_mailbox0 ( ) Configurar INÍCIO

  LAM0_H, LAM0_L Desabilitar mailbox Identificador Configurar CCR=1 Habilitar mailbox CCR = 0 Habilitar Interrupção FIM

Figura 4.15. Configuração do mailbox 0

  As principais etapas do algoritmo de configuração são: b) Desabilitar o mailbox. Esta etapa é necessária para evitar que eventualmente uma mensagem possa ser recebida indevidamente no processo de configuração, e depois isto é necessário para permitir o acesso aos parâmetros de configuração do mailbox;

  c) Entrar com o bits identificadores da mensagem de recepção e também a quantidade de bytes a ser recebido; d) Finalizada a fase de configuração pode-se desabilitar o acesso aos parâmetros de configuração e habilitar o respectivo mailbox; e) Habilitar a interrupção do respectivo mailbox. Na figura 4.16 tem-se a função de configuração do mailbox 0 para recepção. void ini_mailbox0( ) {

  /* prepara máscara de aceitação local para mailbox 0 */

  • CAN_LAM0_H = 0xFFFF;
  • CAN_LAM0_L = MB0_LAML; /* desabilita todas as mailboxes */
  • CAN_MDER = ((CAN_MD<<6)+CAN_ME); /* habilita o aceso ao campo de dados (MCR-bit 8 = 1) */
  • CAN_MCR |= 0x0100; /* prepara mailbox 0 para receber os bits identificadores da mensagem */
  • CANMSGIDH[0]=((MB0_IDE<<15)+(MB0_AME<<14)+(MB0_AAM<<13)+

  (MB0_ID_STD<<2));

  • CANMSGIDL[0]= MB0_ID_EXTL;

  /* desabilita o acesso ao frame de dados (MCR bit 8 = 0) */

  • CAN_MCR &= 0xFEFF ; /* habilita o mailbox #0 como receptor */
  • CAN_MDER|=0x0001;
Figura 4.16 Função para inicialização do mailbox 0

  Pode-se observar pela função de inicialização da figura 4.16, que os parâmetros de configuração necessários são os bits identificadores, assim como a definição de que tipo de mensagem ele poderá receber, somente o formato padrão, ou mesmo o estendido. Além disso a habilitação dos mailboxes desejados também é feita por esta função.

4.7.2 Recepção de Mensagens

  Após uma mensagem válida ter sido recebida por determinado mailbox, existe a necessidade desta mensagem ser transferida para uma variável destinada a este fim, antes que uma nova mensagem sobrescreva a anterior, ocasionando a perda da mesma. Assim, foi desenvolvida uma função utilizada somente para este fim, o de transferir a informação contida na mailbox para uma variável, cujo algoritmo se encontra na figura

  4.17. CARREGA DADOS DO MAILBOX can_receive ( ) INÍCIO

RMPn==1

S

N N

  

MIF0==0

RMPn=1 S

CARREGA OS

DADOS

FIM Para a transferência dos dados contidos no mailbox muita vezes utilizam-se matrizes, pois facilitam a manipulação dos diferentes bytes de mensagens. Com isso obteve-se uma função utilizada para carregar os dados que se encontram nos registradores de recepção de mensagem, que se encontra na figura 4.18, no caso particular da função ela utiliza o mailbox 0 para a recepção de dados.

Figura 4.18 Recepção de dados pela mailbox 0

  

VALIDAđấO

  Nesta primeira etapa procurou-se fazer a validação dos algoritmos iniciais elaborados, seja de configuração, recepção e transmissão, e, além disso, as diferentes características da rede CAN. Para isso, foi montado o conjunto formado por dois nós, conforme a figura 4.19.

  P8 Placa de

  C1

  Placa PL1

  P8 Placa de

  C1

  Placa PL1

  void can_receive0(void) { while((CAN_RCR & 0x0010) ==0);

  /* espera por recepção de mensagens pendentes */ /* mailbox #0 : Bit 4 = 1 */ while((CAN_IFR &= 0x0100)==0); /* espera por MIF0= 1 */

  CAN_RCR |= 0x0010; /* Reseta RA e o flag de interrupcão */ id= *CANMSGIDH[0]>>2; dado0= *CANDATA0[0];

  }

4.8 TESTES PARA

INICIAL DA REDE DESENVOLVIDA

Figura 4.19 Montagem para teste inicial de algoritmos

  Cada nó é composto por uma placa da Texas Instruments, modelo eZdspTMLF2407, e cada placa foi carregada com um programa padrão que se encontra no apêndice B. Este programa é um programa genérico para comunicação utilizando a rede CAN, incorporando as funções de inicialização, transmissão e recepção através da rede CAN. Algumas outras funções como leitura da entrada analógica e tratamento de interrupções também foram incluídas. Para cada um dos testes descritos a seguir o programa de determinado nó pode sofrer alterações, que são comentadas em cada teste quando tal fato ocorre. Deve-se ressaltar que a seguir tem-se a descrição dos testes mais relevantes aplicados, visto que, diversos outros foram aplicados mas por sua própria simplicidade não são mencionados aqui.

  1) Teste dos bits identificadores da mensagem de dados: Objetivo: Avaliar os bits identificadores que fazem parte da mensagem de dados conforme a seção 2.5.1.1;

  Inicialmente o nó transmissor foi programado para o padrão 2.0 A, com 11 bits identificadores. Para facilitar a identificação e algumas outras características, como provocar a inserção do “bit stuff”, todos os bits identificadores foram programados com nível lógico 1, ou seja, o valor de 07ff foi armazenado no respectivo registrador. Para o teste inicial não foi enviado nenhum dado, ou seja, os bits DLC estão todos em 0 , e com isso obteve-se a curva da figura 4.20. a b c d e f

Figura 4.20. Sinal do barramento CAN

  Os pontos identificados nesta figura são:

  a) SOF (Start of Frame) : Início da mensagem, sempre em nível zero;

  b) São cinco bits ( D10 – D6) dos bits identificadores, todos em nível lógico 1;

  c) É um “ stuff bit” , pois após cinco bits seguidos terem o mesmo nível lógico é inserido um bit com nível lógico oposto aos antecessores. Lembrando que para o padrão de mensagem 2.0 A podemos ter até 23 “stuff bit” ;

  d) Mais cinco bits ( D5 – D1) dos bits identificadores, também em nível lógico 1;

  e) Mais um “stuff bit “ ; f) O último bit identificador ( D0 ), também em nível lógico 1.

  Pode-se observar, pela figura 4.19, que com todos os bits identificadores com nível lógico 1, no envio da mensagem o controlador CAN insere alguns “bit stuff” na mensagem, o que vem comprovar uma das características da rede CAN, conforme apresentado na seção 2.6.7.

  2) Verificação dos bits de controle da mensagem de dados Objetivo: Comprovar o comportamento dos bits de controle, conforme seção 2.5.1.1, no envio de um byte de mensagem. Após os bits identificadores temos os seguintes bits: RTR (1 bit ): em 0 caracteriza uma mensagem de dados, em 1 uma solicitação de mensagem;

  IDE (1 bit): em 0 a mensagem é padrão 2.0 A, com 11 bits de identificação, em 1 a mensagem é padrão 2.0 B, padrão estendido com 29 bits de identificação; R0 (1 bit): reservado, sempre em 0; DLC (4 bits): indica quantos bytes ( 0 até 8 ) serão transmitidos, podendo variar entre 0000 até 1000.

  Fazendo o envio de apenas um byte, com todos em nível alto, com isso tem-se DLC=0001, obtém-se o sinal no barramento conforme a figura 4.21.

  Bits “Stuff Bit”

  Identificadores Bits de Bits de

  SO Controle Dados

Figura 4.21. Bits de controle no barramento CAN

  Da mesma forma, pode-se observar na figura 4.21 a inclusão de um “stuff bit” entre os bits de controle, visto que os bits de controle RTR,IDE e R0 estão todos em 0, e o DLC está com 0001 (0000001), o que levaria a termos 6 bits seguidos em nível lógico 0, assim após os cinco bits em 0, foi introduzido um bit em nível lógico 1, para depois termos o sexto bit nulo e o último bit do DLC. Depois disso, tem-se na seqüência os bits da mensagem

  3) Envio de mais bytes de mensagem Nesta etapa implementou-se o envio de um número maior de bytes na mesma mensagem. Para chegar a enviar até 8 bytes basta alterar a informação armazenada nos bits do DLC e conseqüentemente armazenar os dados nos registradores equivalentes. Para isso foi utilizado o mesmo programa e para cada situação foi acrescentado o número de bytes enviados, conforme a tabela 4.1.

  5

  8

  0Fh

  1 FFh FFh FFh

  1

  1

  7

  1 FFh FFh FFh 00h

  1

  6

  0Fh 00h

  1 FFh FFh

  1

  1 FFh FFh 00h 00h

Tabela 4.1 Testes com variação de nr de bytes enviados

  4

  0Fh 00h 00h

  1 FFh

  1

  3

  1 FFh 00h 00h 00h

  2

  0Fh 00h 00h 00h

  1

  1

  DLC3 DLC2 DLC1 DLC0 MBOX5A MBOX5B MBOX5C MBOX5D 00h 00h 00h 00h

  Nr Bytes

  1 FFh FFh FFh FFh Deve-se observar que não basta trocar o programa de transmissão, mas na recepção é necessário prover as alterações necessárias para que as informações enviadas sejam processadas. A pesar que estas alterações podem ser simplesmente aumentar o número de variáveis destinadas para o armazenamento da informação, conforme foi efetuado. Este

  4) Teste de transmissão de mensagens com diferentes mailboxes Como apresentou-se na seção 3.9.5, os mailboxes 4 e 5 são unicamente para a transmissão, mas os mailboxes 3 e 2 podem ser programados para servirem como transmissores ou receptores, para isto basta alterar o registrador MDER, através dos bits 7 e 6, respectivamente, deste registrador. Além disso é necessário que, para sua utilização, determinado mailbox deva ser habilitado, o que, neste caso, é feito no mesmo registrador MDER. Para carregar os dados em uma das novas mailboxes desejadas, pode-se utilizar a função da figura 4.14, alterando basicamente os valores relativos aos valores para o mailbox desejado, conforme o mapa de memória da tabela 3.6.Para a função de transmissão, obteve-se três novas funções, conforme as figuras 4.22 à 4.24.

  • CAN_TCR = 0x0040; /* Solicitação de transmissão(TRS)mailbox#4 */ while((*CAN_TCR & 0x4000) ==0); /* espera ACK de transmissão */
  • CAN_TCR |= 0x4000; /* Reset TA e flag de interrupção associado */

  4.22 Função para transmissão com mailbox 4

  void can_transmit4(void)

  {

  /* mailbox #4 : Bit 14 = 1 */ while((*CAN_IFR &= 0x1000)==0); /* espera por Flag do mailbox4 --> MIF4= 1 */

  void can_transmit3(void)

  {

  • CAN_TCR = 0x0020; /* Solicitação de transmissão(TRS)mailbox#3 */ while((*CAN_TCR & 0x2000) ==0); /* espera ACK de transmissão */

  /* mailbox #3 : Bit 13 = 1 */ while((*CAN_IFR &= 0x0800)==0); /* espera por Flag do mailbox3 --> MIF3= 1 */

  • CAN_TCR |= 0x2000;

  void can_transmit2(void)

  {

  • CAN_TCR = 0x0010; /* Solicitação de transmissão(TRS)mailbox#2 */ while((*CAN_TCR & 0x1000) ==0); /* espera ACK de transmissão */

  /* mailbox # : Bit 12 = 1 */ while((*CAN_IFR &= 0x0400)==0); /* espera por Flag do mailbox2 --> MIF2= 1 */

  • CAN_TCR |= 0x1000; /* Reset TA e flag de interrupção associado */

  4.24 Função para transmissão com mailbox 2 5) Teste de recepção de mensagens com diferentes mailboxes

  Da mesma forma como o teste anterior, os mailboxes 3 e 2 podem ser programados para servirem como receptores, enquanto os mailboxes 0 e 1 são unicamente receptores, sendo necessário, como da vez anterior alterar o registrador MDER, através dos bits 7 e 6, bem como é necessário a habilitação do mailbox em que deseja fazer a recepção, também neste registrador. Para a configuração dos mailboxes receptores pode-se utilizar a função da figura 4.16, bastando alterar a informação relativa a identificação da mensagem, conforme a tabela 3.6.

  Assim como no caso da transmissão, o teste para recepção de mensagens por outros mailboxes gerou três novas funções, que são apresentadas nas figuras 4.25 à 4.27, a seguir. void can_receive3(void) { while((CAN_RCR & 0x0080) ==0);

  /* espera por recepção de mensagens pendentes */ /* mailbox #3 : Bit 7 = 1 */ while((CAN_IFR &= 0x0800)==0); /* espera por MIF3= 1 */

  CAN_RCR |= 0x0010; /* Reseta RA e o flag de interrupcão */ id= *CANMSGIDH[3]>>2; dado3= *CANDATA0[3];

  } void can_receive2(void) { while((CAN_RCR & 0x0040) ==0);

  /* espera por recepção de mensagens pendentes */ /* mailbox #0 : Bit 6 = 1 */ while((CAN_IFR &= 0x0400)==0); /* espera por MIF4= 1 */

  CAN_RCR |= 0x0040; /* Reseta RA e o flag de interrupcão */ id= *CANMSGIDH[2]>>2; dado2= *CANDATA0[2];

  }

  4.26 Função para recepção com mailbox 2 void can_receive1(void) { while((CAN_RCR & 0x0020) ==0);

  /* espera por recepção de mensagens pendentes */ /* mailbox #0 : Bit 5 = 1 */ while((CAN_IFR &= 0x0200)==0); /* espera por MIF1= 1 */

  CAN_RCR |= 0x0020; /* Reseta RA e o flag de interrupcão */ id= *CANMSGIDH[1]>>2; dado0= *CANDATA0[1];

  }

  4.27 Função para recepção com mailbox 1 6) Teste de filtragem de mensagens

  Para este teste não foi enviado nenhum dado, mas simplesmente foram atribuídos diferentes valores para os identificadores do transmissor e alterou-se a máscara dos

  No transmissor a alteração necessária é somente a alteração dos registradores MSG_ID5L e MSG_ID5H,que são responsáveis pelo armazenamento dos bits identificadores do mailbox 5.

  Para o nó receptor os testes foram realizados utilizando os diferentes mailboxes receptores, isto é, os mailboxes de 0 até 3. Assim, para os mailboxes 0 e 1 é necessário alterar o valor dos registradores CANLAM0H e CANLAM0L, e para os mailboxes 2 e 3 é necessário alterar o valor dos registradores CANLAM1H e CANLAM1L. Além disso, para ambos os casos é necessário habilitar a utilização das máscaras, o que é feito atribuindo o valor 1 para o bit AME, no registrador MSGIDnH, onde o “n” refere-se ao

  

mailbox utilizado. O teste ocorreu com sucesso, onde os valor utilizados tanto no

  mailbox transmissor quanto no mailbox receptor estão na tabela 4.2. Lembrando que, quando um determinado bit da máscara estiver em nível lógico nulo (=0) o bit correspondente, tanto do transmissor quanto do receptor, devem ser os mesmos, se determinado bit da máscara estiver em nível lógico alto (=1) não existe uma verificação daquele bit.

Tabela 4.2 Teste da máscara de recepção

  ID do mailbox 5

  ID do mailbox Máscara utilizada Status (transmissor) receptor 00000000000 11111111111 00000000000 Mensagem não aceita

  00000000011 00000000000 11111111111 Mensagem aceita 00000011111 00000011000 00000000111 Mensagem aceita 00000011111 00000011000 00000000011 Mensagem não aceita 11000000000 11100000000 11100000000 Mensagem aceita 11000000000 11100000000 00100000000 Mensagem aceita 00000110000 11111111111 11111001111 Mensagem aceita 00000110000 11111111111 00000000000 Mensagem não aceita 01010101010 01010101011 00000000000 Mensagem não aceita 01010101010 01010101011 00000000001 Mensagem aceita

  Os valores apresentados na tabela foram aplicados para cada um dos mailboxes de recepção, e os resultados apresentados sempre foram positivos, não havendo nenhum instante em alguma mensagem, onde os bits identificadores do nó transmissor e do receptor não coincidiram, tivesse sido aceita e não houvesse um bit da máscara para permitir que tal fato viesse a acontecer. 7) Teste de utilização de interrupção para leitura da mensagem

  Para os testes realizados até o momento no processo de recepção sempre se utilizou a técnica de polling, ou seja, periodicamente fazia-se a verificação se alguma mensagem havia chegado. Este método muitas vezes não é recomendado pois existe a necessidade de constantemente ter que interromper o programa e fazer esta verificação, o que, se tivermos uma seqüência de mensagens sendo recebidas pode até ocasionar a perda de alguma das mensagens. Assim, na maioria dos casos recomenda-se a utilização da interrupção para fazer a recepção de mensagens, isto é, quando uma determinada mensagem é recebida por uma determinada mailbox, o controlador CAN do DSP dispara a interrupção equivalente. Após o tratamento da interrupção o DSP poderá voltar a execução normal do programa.

  Para a teste utilizou-se a INT 1, cuja habilitação deve ser feita através do registrador

  IMR, e, além disso é necessário habilitar a interrupção equivalente do próprio controlador CAN, feita no registrador CAN_IFR.

  Além disso, é preciso que se faça a verificação, dentro do tratamento da interrupção se esta foi ocasionada pela rede CAN, e não por algum outro evento associado a essa interrupção. Isto pode ser feito fazendo-se a verificação do código da interrupção gerada, feito no registrador PIVR. Assim, obteve-se a função para o tratamento da rede CAN da figura 4.28.

Figura 4.28 Rotina para verificação da interrupção por mensagens

  Deve-se observar que, depois do tratamento da interrupção, é necessário habilitar novamente a interrupção da rede CAN, preparando para receber uma nova mensagem, feito através do registrador CAN_RCR.

  interrupt void c_recep(void) {

if((PIVR == 0x0040) && (CAN_RCR & 0x0010))

  { can_receive(); }

  IFR=0x00ff; CAN_RCR |= 0x0010; }

  

CAPÍTULO 5

DESENVOLVIMENTO DE ALGORITMOS

5.1. INTRODUđấO

  Neste capítulo será apresentada a filosofia abordada por [Etschberger, 2001] para o desenvolvimento de uma aplicação baseada nas duas camadas da rede CAN. Os conceitos da rede CAN serão aplicados em um AGV (Automatic Guidance Vehicle) emulado. Para tanto, a rede CAN, desenvolvida no capítulo anterior, foi ampliada e atribui-se diferentes funções para cada nó, permitindo-se simular o comportamento do AGV, de forma limitada.

  Inicialmente será vista uma breve abordagem sobre o AGV, em particular aos modelos industriais, procurando apresentar seus principais blocos, para em seguida formular a proposta de um sistema que simule algumas de suas funções básicas. Em seguida, será apresentada em detalhes a metodologia proposta por [Etschberger, 2001] para o desenvolvimento de aplicações para a rede CAN aplicadas ao AGV. Finalizando, serão apresentados e discutidos os algoritmos implementados para cada nó.

  

5.2. VEÍCULO GUIADO AUTOMATICAMENTE (Automatic Guidance

Vehicle-AGV)

  Um AGV é um veículo utilizado em sistemas de manufatura para fazer a movimentação automatizada de materiais. Ele opera fazendo a carga e descarga de material, geralmente através de esteiras. [Kondlatsch, 2002]

  O primeiro AGV foi produzido pela empresa norte-americana Barrett Electronics, em 1953, tendo como base um trator industrial que puxava uma carreta que continha o material a ser transportado, que pode ser observado na figura 5.1

  2 Figura 5.1 Primeiro AGV Apesar de sua aplicação estar muito voltada para a indústria, existem aplicações também na área hospitalar, em aeroportos, na agricultura, em entretenimento, na área militar e espacial e em portos marítimos.

  Na figura 5.2 tem-se um AGV em sua aplicação típica, na indústria automobilística para o transporte de matéria-prima para a produção.

5.2.1 Componentes de um AGV

  Apos estudo realizado em AGVs [Kondlatsch, 2002] utilizados em uma indústria local, pode-se dividir o AGV em algumas estruturas básicas:

  5.2.1.1. Sistema de navegação O sistema de navegação é utilizado para orientação do “caminho a seguir” pelo AGV.

  Atualmente existem algumas opções utilizadas para os sistemas de navegação, sendo que, na indústria, as principais são: a) Sistema indutivo O sistema indutivo é baseado na leitura de um campo magnético gerado pela corrente que passa por um cabo condutor, em uma determinada freqüência, embutido sob o piso. No

  AGV, uma antena capta o sinal gerado, que varia de acordo com o deslocamento do veículo, necessitando fazer uma correção da trajetória seguida pelo AGV, conforme pode ser observado na figura 5.3.

  Geralmente o problema deste sistema é a falta de flexibilidade, pois existe a necessidade de se definir toda a trajetória e a construção da canaleta para acomodar o cabo.

  b) Sistema a laser Neste sistema, um laser é colocado em um dispositivo rotativo na parte superior do

  AGV. Nas paredes por onde o AGV deve percorrer sua trajetória são dispostos espelhos refletores do sinal, que por sua vez são captados novamente pelo AGV.

  Na figura 5.4 tem-se um exemplo da triangulação do sinal feito em uma aplicação típica para determinação da trajetória, entre os pontos A e B

Figura 5.4 Exemplo de aplicação do laser em um AGV

  A vantagem deste sistema é a flexibilidade da mudança de trajetória dentro do ambiente fabril.

  5. 2.1.2 Sistema de segurança Sendo um veículo móvel dentro de um ambiente industrial, aplican-se normas de colisões. Normalmente utilizam-se sensores de diferentes tipos, sejam indutivos, ultrasônicos ou infravermelho para monitoramento de segurança no AGV. Na figura 5.5 tem-se a indicação dos diversos sensores de segurança encontrados em um AGV típico.

Figura 5.5 Sensores de segurança típico

  5. 2.1.3 Sistema de comunicação Em virtude da necessidade da informação de onde o AGV tem que coletar o material e para onde o mesmo deve ser transportado existe a necessidade do AGV possuir um sistema de comunicação. Os sistemas mais usuais são via ondas de rádio ou infravermelho. 5. 2.1.4 Sistema de energia

  Sendo um veículo móvel, existe a necessidade do AGV incorporar um conjunto de baterias para fornecer a energia para todo o sistema, tanto para o sistema eletrônico como também, para os motores elétricos, responsáveis pelo deslocamento do AGV.

  Além disso, existe a necessidade de recarregar essas baterias, podendo o sistema eletrônico de potência estar incorporado ao próprio AGV, ou então, em um painel externo. Através de um sistema de gerenciamento de energia, pode-se acompanhar o ritmo de descarga e determinar o instante em que existe a necessidade de recarregar novamente as baterias.

  O deslocamento do AGV é feito por um conjunto de motores projetados para tal. Normalmente são utilizados AGVs com três rodas. Duas normalmente que tem um motor acoplado e uma terceira que é conhecida como “roda solta”.

  Tradicionalmente encontra-se duas topologias [Jonas, 2003] de disposição dos motores utilizadas para este fim:

  • Sistema com um motor para deslocamento e outro para direção: Com este sistema tem-se um motor de maior potência, responsável pelo deslocamento e outro motor responsável para a direção do
  • - Sistema com dois motores para tração e direção : Neste caso utiliza-se a velocidade

  diferencial dos dois motores, cada um acoplado a uma roda, aplicando-se o algoritmo de controle adequado determina-se a direção e o deslocamento do AGV.

  5. 2.1.6 Sistema de comando central.

  Devido aos diversos sistemas envolvidos em um AGV existe a necessidade de estar presente um controlador central para processar as informações e tomar decisões. Para isso muitas vezes são utilizados controladores lógicos programáveis ou então placas eletrônicas especialmente desenvolvidas para este fim.

  Algumas das atividades desenvolvidas por este comando central são:

  a) Agendamento das atividades;

  b) Monitoramento do tráfego; c) Monitoramento do status dos veículos.

  

5.3 DEFINIđấO DAS CARACTERễSTICAS DO SISTEMA

PROPOSTO

  A primeira etapa da metodologia apresentada por [Etschberger, 2001] é a definição das características do sistema, indicando o número de nós e uma descrição das características de cada nó, com o número e tipo de entradas e saídas, além de uma descrição básicas das ações previstas por cada nó em relação ao seu comportamento com mensagens que poderá gerar ou receber.

  Para possibilitar o estudo da utilização da rede CAN em um AGV e, uma vez que não existe na UDESC nenhum para poder ser utilizado, foi necessário montar um sistema mínimo que possibilite a simulação do comportamento de um AGV.

  Dentro dos componentes básicos apresentados anteriormente, devem ser selecionados alguns deles e fazer a interligação através da rede CAN. Além do mais, para cada um dos módulos que serão selecionados para compor a rede, deverá ser previsto um certo número de funções, que permitirá que se obtenha uma diversidade de mensagens que circulará pela rede, permitindo uma melhor aproximação de um AGV.

  Na figura 5.6 apresenta-se um esboço do sistema proposto.

  Nó 1 Nó 2 Nó 3

Nó 5 Nó 4 Para implementar cada nó foi utilizada a configuração discutida no capítulo anterior, onde tem-se os seguintes elementos em cada nó: a) Um placa com DSP;

  b) Uma placa de interface com a rede; Eventualmente, foi atribuída uma característica particular de algum nó, podendo haver o acréscimo de algum outro componente específico.

  5.3.1.1. Nó 1 – Sensores de segurança (SS) Como o próprio nome já revela, o objetivo deste nó é emular o comportamento dos sensores de segurança do AGV. Algumas das características que este nó deverá possuir são:

  a) Serão utilizadas as chaves de entrada para emular os sensores, considerando-se que o acionamento de qualquer uma das chaves corresponderá ao acionamento de um sensor de segurança do AGV, tornando-se necessário que o nó informe à rede o ocorrido;

  b) Deve-se prever a criação de um mecanismo que envia uma mensagem quando algum dos sensores for atuado; c) Enviar para a rede uma mensagem informando quando os sensores deixarem de ser atuados, voltando ao estado inicial; d) Responder uma solicitação da rede relativa à informação do estado dos sensores.

  5.3.1.2. Nó 2 – Nível de tensão na bateria (BAT) Este nó será utilizado para permitir a emulação de um sistema de gerenciamento de energia do AGV, onde a variação do nível de tensão da bateria do AGV será feita através da variação da resistência de um potenciômetro acoplado a uma entrada analógica do DSP. a) De acordo com nível de tensão previamente estipulado, ele deverá gerar uma mensagem de alerta para a rede; b) Entrando a tensão da bateria em um nível crítico, apenas uma mensagem deve ser enviada à rede, evitando que uma sobrecarga da rede ocorra por um eventual excesso de mensagens;

  c) Deve-se prever que o nó deva fornecer uma resposta de uma mensagem solicitando o nível atual da tensão na bateria.

  5.3.1.3. Nó 3 – Acionamento de motores ( A M ) Como não poderia faltar em um sistema móvel, existe a necessidade de se implementar um sistema de acionamento de motores. Para isso será utilizada uma configuração de acionamento diferencial no AGV proposto, onde tem-se um motor acoplado a cada gerenciador de eventos do DSP.

  As características previstas para este nó são:

  a) A informação relativa à velocidade de cada motor será fornecida pela rede;

  b) Será implementada a simulação de um sinal de segurança, cuja função será indicar alguma falha, seja no motor ou módulo de potência. A implementação será feita utilizando-se as chaves acopladas às entradas digitais do DSP, onde será feito esse monitoramento e, conseqüentemente, a respectiva geração da mensagem.

  5.3.1.4. Nó 4 – Sistema de navegação ( S N ) Como mencionado anteriormente, a indisponibilidade de sistemas de navegação como um sistema laser ou indutivo, levou a procura de uma solução alternativa para permitir a implementação desta função na rede proposta.

  Assim, o princípio a ser utilizado é o dos sensores óticos, onde o sistema de navegação é composto por um conjunto de sensores óticos, dispostos em uma fileira, onde os mesmos são utilizados para monitorar um caminho pré-definido por uma fita adesiva, por exemplo, estando atuadas, servirão para indicar o acionamento do um sensor ótico correspondente. Um algoritmo para permitir a leitura das chaves e gerar com isso uma velocidade de referência para os dois motores deverá ser previsto.

  5.3.1.5. Nó 5 – Módulo de Gerenciamento ( MG ) A função deste nó é gerenciar as informações que circulam pela rede e tomar as ações cabíveis de acordo com o conteúdo delas. Algumas das características deste nó devem ser: a) Este nó será responsável pela leitura de potenciômetros acoplados às suas entradas analógicas que servirão como uma referência alternativa para a velocidade dos motores.

  b) Controle do “estado” em que se encontrará cada nó, que implicará na alteração de seu comportamento, o que terá que se prever no instante da elaboração dos algoritmos. Esse estado é o seu modo de operação que, no caso, foram divididos em três estados: b.1) Estado de espera: o nó que estiver neste estado não envia nenhuma informação para a rede e nem estará desempenhando nenhuma das funções de verificação rotineiras. Esse estado ocorre geralmente quando tem-se alguma mensagem de erro que foi enviada à rede, como por exemplo, quando no AGV algum sensor de segurança for acionado. Somente o nó MG está ativo e no comando. O restante dos nós aguarda uma mensagem do MG para entrar em operação; b.2) Estado automático: Neste estado, considera-se que o AGV esteja em funcionamento pleno, e todas as funções de monitoramento estão operantes. Este modo é utilizado quando o AGV está operando normalmente no transporte de material através da linha de produção. b.3) Estado manual: No modo manual, somente o nó de navegação fica em modo de espera, mas os outros operam como no modo automático, pois nesse modo, a informação conduz o mesmo para uma determinada operação, que pode ser de uma falha durante o trajeto normal, ou mesmo para levá-lo para manutenção.

5.4. GERAđấO DE MENSAGENS

  Nesta segunda etapa tem-se a geração das mensagens que irão circular pela rede. Mas antes serão apresentados alguns critérios que foram estabelecidos para permitir a geração de mensagens de forma mais uniforme.

5.4.1 Critérios para Obtenção das Mensagens

  Para se obter as mensagens utilizou-se os seguintes critérios:

  a) Inicialmente foram analisadas todas as mensagens que cada nó poderia gerar, de acordo com o modo de operação, com as características e funções incorporadas a cada nó, bem como, para quem interessa as informações geradas por determinado nó. Deve-se observar ainda os eventos que podem levar a geração das mensagens e a peridiocidade das mesmas; b) Posteriormente foram analisadas as mensagens que cada nó necessita para operar nos diferentes modos de operação, e quais informações ele precisa para poder trabalhar conforme as especificações atribuídas a ele;

  c) Após isso, houve um estudo para poder identificar as informações gerais de inicialização do sistema e para o gerenciamento da rede, procurando identificar quais as mensagens que precisam circular pela rede e os nós que precisam delas, bem como, qual a resposta gerada por eles; d) Finalizando, houve um cruzamento das informações de todos os nós, gerando-se um grupo de mensagens, identificando o emissor e os receptores, a presença ou não de dados e) Deve-se ainda, observar a possibilidade de agrupar-se diferentes mensagens em uma mesma mensagem, diminuindo a diversidade de informações que circulam pela rede. Neste caso é preciso verificar antes qual a finalidade, a quem possa interessar o conteúdo da mensagem.

  Finda esta etapa as mensagens obtidas foram agrupadas em uma tabela no apêndice 1.

5.5. AGRUPAMENTO DE MENSAGENS

  Após a etapa de elaboração das mensagens que irão circular pela rede é preciso definir os identificadores. Mas, como comenta [Etschberger, 2001], a fim de facilitar a alocação de identificadores, criam-se grupos e aloca-se as mensagens nesses grupos de acordo com as características de cada um dos grupos.

  A quantidade de grupos que irão ser gerados depende muito da quantidade e diversidade de mensagens criadas. No caso em estudo, foram criados os seguintes grupos: 1) Segurança Para este grupo serão os eventos mais importantes que possam envolver aspectos de segurança. Este grupo de mensagens será o de maior prioridade.

  2) Coloca a rede CAN em modo automático Este grupo indica o modo em que todo o sistema está operando em funcionamento, com o trânsito automático de informações pelas rede. Em um sistema real será o instante em que o AGV está em plena operação, fazendo o transporte de material.

  3) Coloca a rede CAN em modo manual Ocorre quando o comando dos motores é feito pelos potenciômetros. Em uma situação real ocorre quando um operador direciona o AGV, seja durante uma inicialização do

  4) Coloca a rede CAN em modo de espera Neste grupo os nós ficam aguardando um comando do MG. Pode acontecer tanto após à inicialização como quando houve algum problema em algum dos nós, seja alguns dos sensores de segurança que tenha sido atuado, ou mesmo algum problema no acionamento.

  5) Processo de inicialização Envolve as mensagens de inicialização da rede CAN para verificação do status de cada nó.

  6) Envio de informação É utilizado para o envio de informações solicitadas, geralmente fora do ciclo normal de envio, quando algum nó solicita uma informação.

  7) Solicitação de informação Este grupo solicita à rede uma determinada informação. Muitas vezes pode ser utilizado para a confirmação de algum problema, como o nível de tensão da bateria, ou mesmo para monitoramento remoto.

  8) Sai do estado de espera É utilizado para informar ao MG que voltou ao estado normal, não havendo mais o problema que ocasionou a parada do sistema. Esta mensagem é gerada quando, por exemplo, os sensores de segurança do AGV voltaram à posição normal, não estando mais atuados.

  Posteriormente, organizou-se as mensagens em grupos, conforme a classificação feita e obteve-se a tabela 5.1.

Tabela 5.1 Grupo de mensagens

  Grupo de Tipo de Mensagem mensagem

  1

  c, n, s, 2 l, 3 u,

  4

  h, m, v,

  5

  a, b,

  6

  f, g, k, p, r, w

  7

  e, i, o, q,

  8

  d, j, t,

5.6. GERAđấO DOS BITS IDENTIFICADORES DE CADA MENSAGEM

  Após o organização das mensagens em grupo, é necessário fazer uma classificação das mesmas em relação a prioridade dos bits identificadores. A alocação dos bits identificadores, conforme sugere [Etschberger, 2001], pode ser feita dividindo-se os grupos de mensagens em dois grandes grupos, o de maior prioridade e o de menor prioridade, levando-se em conta fatores como qual a importância da mensagem em relação ao modo de operação. Eventualmente, devido a quantidade e diversidade de mensagens que possam existir, um terceiro grupo, intermediário, poderia ser acrescentado. Assim, após análise das condições de cada grupo chegou-se a seguinte divisão:

  Grupo de mensagens de maior prioridade: 1) Segurança 4) Coloca a rede CAN em modo de espera

  Grupo de mensagens de menor prioridade: 2) Coloca a rede CAN em modo automático 3) Coloca a rede CAN em modo manual 5) Processo de inicialização 8) Sai do estado de espera Após a divisão em grupos de mensagens faz-se a alocação dos bits identificadores.

  Para isso optou-se por fazer a divisão dos bits identificadores em dois conjuntos: os bits identificadores do grupo de mensagens e o grupo de bits identificadores de sub- mensagens, que são todas as mensagens dentro de cada grupo. Uma outra opção que existe, é utilizar o primeiro byte da mensagem como um sub-índice, permitindo-se obter um número muito maior de combinações possíveis.

  No caso do sistema proposto para cada mensagem serão atribuídos 6 bits para identificar o grupo de mensagens e 5 bits para fazer a diferenciação entre as sub- mensagens dentro do um mesmo grupo. Com isso tem-se a disposição dos bits identificadores conforme a figura 5.7.

  10 09 08 07 06 05 04 03 02 01 00

Figura 5.7 Disposição dos bits identificadores

  Com isso, inicialmente é necessário atribuir um valor binário para cada grupo de mensagens. Para deixar o sistema flexível para expansões futuras procurou-se deixar um espaço considerável entre cada grupo de mensagens, obtendo-se a tabela 5.2.

Tabela 5.2 Bits identificadores para cada grupo de mensagens

  Com a definição dos bits identificadores de cada grupo é possível agora elaborar uma tabela considerando todas as mensagens propostas anteriormente. Identificando o emissor e os receptores e dividindo os grupos de mensagens chega-se a tabela 5.3.

  Para poder fazer a classificação dentro de cada grupo de mensagens optou-se pela análise individual da importância de cada mensagem dentro do mesmo grupo. Nesse caso, a classificação é um pouco mais difícil, pois, como elas já pertencem ao mesmo grupo, a diferenciação entre elas não é uma tarefa muito fácil, podendo gerar interpretações diferentes entre os projetistas.

  Um outro ponto a comentar é que, visando expansões futuras, também optou-se por deixar um intervalo entre uma mensagem e outra.

  Após a definição do bit identificador de cada mensagem fez-se a separação das mensagens que serão transmitidas e recebidas por cada nó, conforme a descrição na tabela

  5.3. Grupo de Mensagem

  Código atribuído Valor

  Binário 1 000000 4 2 000010

  6 6 000110

  7 10 001010

  3 30 011110

  2 40 101000

  8 50 110010

  5 60 111100

Tabela 5.3 Definição dos bits identificadores para cada mensagem

  40 L 5 1,2,3,4 001010 00000

  I

  5 2 101000 00010 O

  5 4 101000 00100 Q

  5 3 101000 01000

  3

  30 U 5 1,2,3,4 011110 00000

  2

  8

  10 E

  50 D

  1 5 110010 00000 J

  2 5 110010 00010 T

  3 5 110010 00100

  5

  60 A 5 1,2,3,4 111100 00000 B

  1 5 111100 01000 B

  2 5 111100 01001 B

  5 1 101000 00000

  7

  Grupo de Mensagem

  4

  Código atribuído Mensagem Nó

  Emissor Nó

  Receptor Valor

  Binário Complemento

  Binário

  1 C 1 2,3,4,5 000000 00000 S 3 1,2,4,5 000000 00010

  N 4 3,5 000000 00100

  2 H 2 1,3,4,5 000010 00000 M 5 1,2,3,4 000010 00010

  5 3 001000 10000

  V 5 1,2,3,4 000010 00100

  6

  8 F

  1 5 001000 00000 G

  2 5 001000 00010 K

  2 5 001000 00100 P

  4 5 001000 01000 R

  3 5 001000 01010 W

  3 5 111100 01010

  

5.7 DETALHAMENTO DAS MENSAGENS RECEBIDAS E ENVIADAS

POR CADA NÓ

  Nesta etapa faz-se o mapeamento das mensagens transmitidas e recebidas por cada nó, o que facilitará a obtenção da máscara para cada nó, na próxima etapa, assim como na própria elaboração do algoritmo de cada nó.

  Esta etapa não está prevista na proposta no trabalho de [Etschberger, 2001], mas após o desenvolvimento desta aplicação, constatou-se que a necessidade da inclusão da mesma para facilitar as etapas vindouras.

  O detalhamento de cada mensagem transmitida ou recebida está no anexo B.

5.8. OBTENđấO DA MÁSCARA DE CADA Nố

  A próxima etapa, após o detalhamento das mensagens que serão recebidas e enviadas por cada nó, é definir uma máscara para ser utilizada pelo controlador CAN. O objetivo da máscara é minimizar o número de mensagens indesejáveis recebidas por determinado nó, visto que, muitas vezes não é possível eliminar completamente a recepção das mesmas.

  Esta etapa não foi detalhada no trabalho Etschberger pois é uma particularidade do controlador CAN utilizado, apesar de ser uma característica muito comum hoje em dia. A obtenção da máscara ocorre através da comparação dos bits identificadores de todas as mensagens que serão recebidas, e com isso obtém-se os bits que podem ser controlados. Depois é necessário identificar o nível lógico destes bits, para carregar então o bit identificador do mailbox correspondente. Os demais bits não são comparados, assim o valor que assumem é indiferente. Através da tabela 5.4 pode-se obter os bits que são comuns a todas as mensagens recebidas e assim gerar o ID do mailbox:

Tabela 5.4. Máscara das mensagens recebidas

  Nó Máscara

  ID 1 00000111001 00000000000 2 00000111001 00000000000 3 00000100001 00000000000 4 00000110001 00000000000 5 00000110000 00000000000

  Através do levantamento, pode-se observar que entre as mensagens existe muita semelhança em relação aos bits que estão disponíveis para serem utilizados. Além disso, todos os elementos que são comuns são de nível lógico zero, assim o ID para elas poderia ser o mesmo, como demonstra a tabela. Em virtude disto optou-se por eliminar desta opção do sistema.

5.9. DESENVOLVIMENTO DO ALGORITMO PARA CADA NÓ

  Nesta etapa, após ter-se definido a estrutura de cada nó, gerado todas as mensagens que irão circular pela rede, dividido as mensagens em grupos e finalmente obtendo o bit identificador de cada mensagem, pode-se trabalhar na elaboração dos algoritmos para cada nó, criando assim as bibliotecas específicas para cada caso.

  Mas antes, deve-se definir algumas características comuns a todos os nós, como o seu comportamento, que acabará definindo alguns padrões em cada mensagem. Assim, seguem alguns comentários sobre estes padrões de comportamento para todos os nós, para que depois seja discutido o comportamento de cada nó individualmente.

  Na seqüência, tem-se a descrição dos algoritmos gerados para cada nó, com as rotinas de acordo com as suas particularidades. Apesar disso, algumas características são comuns a todos os nós e devem ser incorporados aos algoritmos, tais como: conectados à porta de saída. Após isto, deverá fazer um auto-teste no controlador CAN, e se estiver funcionando, ele entra em modo de espera.

  • Como padrão, a interrupção utilizada para a recepção de mensagens da rede CAN foi a INT 1.
  • No processo de inicialização, em todos os nós, os periféricos serão ativos, evitando a necessidade de utilização de diversas funções de inicialização para cada nó.
  • Em virtude dos kits utilizarem cristais com freqüência diferentes, alguns trabalham com freqüência de 14 MHz e outros com 20 MHz, existe a necessidade de se observar este fato durante a montagem da rede, para fazer as alterações necessárias no programa.

5.9.1. Nó 1 – Sensores de Segurança

  Para o nó de segurança tem-se os seguintes algoritmos:

  a) Algoritmo principal: responsável pela configuração do DSP, de fazer o teste do estado dos sensores de segurança e envio de mensagens.

  b) Algoritmo da interrupção INT 1: Como padrão este algoritmo irá tratar das interrupções geradas pela rede CAN.

  A seguir tem-se os algoritmos, seguidos de comentários sobre suas diferentes etapas.

  5.9.1.1. Algoritmo principal Este é o algoritmo inicial do DSP, responsável pela configuração e habilitação do processador e periféricos, onde as variáveis globais são definidas e, muitas vezes, são

  Tem-se nas figuras 5.8 e 5.9, o algoritmo principal, e logo a seguir os comentários relativos ao mesmo.

Figura 5.8 Algoritmo principal do nó 1(parte 1).

  As etapas do processo do algoritmo de inicialização são:

  f) Declaração de variáveis: Nesta etapa faz-se a declaração das variáveis globais utilizadas no programa, além de declarar as bibliotecas utilizadas e também a declaração das definições utilizadas no decorrer do programa;

Figura 5.9 Algoritmo principal do nó 1 (parte 2).

  g) Função ini_dsp( ): Chama a função que configura o DSP ;

  h) Função ini_can(): Chama a função que inicializa os registradores do controlador CAN, mapeados na memória de dados do DSP ; i) Função teste_can ( ) : Chama a função que faz um auto-teste da rede CAN ; seguida habilitar a máscara das interrupções desejadas, através de IMR, para em seguida habilitar a interrupção geral do DSP, através de INTM; Estas etapas, de a até e , por tratarem-se das etapas de configuração e inicialização de variáveis e registradores, são praticamente comuns a todos os nós. Assim, nos demais nós não irá se entrar em maiores detalhes, apenas ressaltando algum ponto que seja diferente em determinado nó. k) Nas duas etapas seguintes tem-se o teste do estado atual da variável SEL. Esta variável é alterada durante a recepção de mensagens, quando a rede solicita alguma informação; l) Na figura 5.9 inicia-se fazendo uma verificação de que modo o sistema está operando. Se ele estiver em estado parado (modo=0), não se faz nenhum teste dos sensores. Mas, estando em modo automático (modo=1) ou modo manual (modo=2) o sistema irá fazer os testes relativos ao estado dos sensores de entrada; m) Como próxima etapa, os testes com o estado atual dos sensores são efetuados. E se, por ventura, algum deles sofreu uma alteração, uma mensagem é enviada para a rede

  5.9.1.2 Algoritmo da interrupção INT 1 do nó 1.

  Mesmo que esta interrupção tenha sido reservada para o tratamento das interrupções geradas pela rede CAN, é necessário fazer a verificação se foi realmente ocasionada pela rede, pois diversos eventos podem ser associados a interrupção INT 1, sendo necessária a verificação, conforme pode-se observar na figura 5.10

  As etapas do processo do algoritmo da interrupção INT 1 são:

  !" # $ % $ & '' ' ()* +,(,-., $ "

  a) Consulta a tabela para identificar a origem da interrupção, através da consulta a tabela de interrupção de periféricos (PIVR). Se for um erro na rede CAN (PIVR=41h), chama a função para identificação de qual dos erros que ocorreu; b) Mas se foi ocasionada pela mailbox (PIVR=40h), se inicia o processo de recepção de mensagem. Se a interrupção ainda não foi ocasionada por nenhum destes dois eventos, é feito a sinalização através do barramento de leds;

  c) Chama a função de recepção de mensagens através do mailbox 0;

  d) Após a carga da mensagem é necessário identificar se a mensagem está dentro do grupo de mensagens que o nó em questão. Isto é feito comparando-se o identificador da mensagem recebida. Estas ações são conforme a tabela 5.5.

Tabela 5.5 Relação das ações programadas

  ID Ação 780 Carrega o mailbox, sem dado, e envia para a rede, com ID=788, colocando SEL=1 500 Carrega o mailbox com o estado dos sensores e envia para a rede, com ID=100, colocando SEL=2 140 Coloca o nó em modo automático

  042 Coloca o nó em modo de espera 004 Coloca o nó em modo de espera

  3C0 Coloca o nó em modo automático

  e) Após o tratamento da recepção de mensagens, tem-se a finalização do tratamento da interrupção colocando em zero o flag de recepção de mensagem (CAN_RCR). Como esta etapa é sempre a mesma para todas as interrupções esta observação será omitida durante a explicação das outras interrupções.

5.9.2. Nó 2 – Nível de Bateria

  alerta para o MG iniciar o procedimento para levar o AGV a carregar a bateria. Além disso, quando a tensão chegar a um valor menor que 75% uma mensagem é enviada para a rede, levando os nós entrem em modo de espera.

  Os seguintes algoritmos são utilizados:

  a) Algoritmo principal : responsável pela configuração do DSP pelo teste do nível de tensão da bateria, tomando as ações para cada caso.

  b) Algoritmo da interrupção INT 1: Como padrão este algoritmo irá tratar das interrupções geradas pela rede CAN.

  A seguir tem-se os algoritmos, seguidos de comentários sobre suas diferentes etapas.

  5.9.2.1. Algoritmo principal Como comentado na análise do nó 1, irá se fazer apenas algumas observações em relação a pontos que sejam diferentes em relação ao já mencionado na etapa inicial de configuração do DSP.

  No caso deste algoritmo, a diferença em relação ao do nó 1 é que, como este nó faz a leitura da entrada analógica, é necessário que a mesma seja configurada, indicando o modo de operação, bem como qual entrada será utilizada. Para isso foi incluída a função ini_analogica ( ).

  Na figura 5.11 pode-se observar que as etapas coincidem com as etapas vistas no nó 1, apenas tem-se a inclusão da etapa de configuração da entrada analógica, utilizada para fazer a aquisição do sinal e da alteração dos valores dos bits identificadores de mensagens utilizados para responder as mensagens solicitadas pela rede.

Figura 5.11. Algoritmo principal para o nó 2 (parte 1)

  Na segunda etapa do algoritmo, conforme a figura 5.12, inicialmente faz-se a identificação do modo de operação do nó, e, estando operando em modo automático ou manual faz-se a verificação do nível de tensão da bateria e de acordo com o mesmo, são enviadas mensagens para a rede.

  INÍCIO DECLARAđấO DE VARIÁVEIS Inicializa Registradores CAN ini_can( ) Inicializa Temporizadores ini_tempor( ) Inicializa DSP ini_dsp( ) CLRC INTM IFR = 0xFFFFh Habilita Interrupção

  MÓDULO DA BATERIA

PROGRAMA PRINCIPAL

  FAZ AUTO-TESTE DA REDE CAN teste_can( ) A SEL==1 SEL==2 can_transmit()

can_mailbox( )

ID= 789

can_transmit()

can_mailbox( )

ID= 104

SEL=0

  (MODO==1) || (MODO==2) A S N leitura_canal0 ( ) Canal0<75%

N var==0

S

S Canal0<90%

S

N S can_transmit5() can_mailbox5() ID= 040 N var==1 N can_mailbox5() can_transmit5() S

ID= 102

var==0 N can_mailbox5() ID= 102

can_transmit5()

  B WHILE(1) S FIM N

Figura 5.12. Algoritmo principal para o nó 2 (parte 1) 5.9.2.2 Algoritmo para tratamento da interrupção INT 1 do nó 2.

  Na figura 5.13 tem-se o algoritmo da interrupção INT 1 para este nó. As etapas do processo do algoritmo da interrupção INT 1 do nó 2 são:

  a) Novamente tem-se a necessidade de consulta a tabela para identificar a origem da interrupção através da consulta a tabela de interrupção de periféricos (PIVR). Se for um erro na rede CAN (PIVR=41h) chama a função para identificação de qual dos erros que ocorreu.;

  / ()* +,(,-., ' '' " # $ !" $ $

  % $

Figura 5.13 Algoritmo para tratamento da interrupção INT 1 do nó 2 As etapas do processo do algoritmo da interrupção INT 1 do nó 2 são:

  a) Assim como no caso anterior, faz-se a consulta da tabela para identificar a origem da interrupção através da consulta a tabela de interrupção de periféricos (PIVR). Se for um erro na rede CAN (PIVR=41h) chama a função para identificação de qual dos erros que ocorreu.; b) Se for a sinalização de que tenha sido o mailbox (PIVR=40h), se inicia o processo de recepção de mensagem, caso contrário se sinaliza também no barramento de leds, indicando que houve uma outra fonte de interrupção ;

  c) Chama a função de recepção de mensagens através do mailbox 0;

  d) Nesta etapa tem-se o tratamento de cada mensagem, de acordo com o seu bit identificador, que pode ser observado na tabela 5.6.

Tabela 5.6 Relação das ações programadas para o nó 2

  ID Ação 780 Carrega o mailbox, sem dado, e envia para a rede, com ID=789 502 Carrega o mailbox com o estado dos sensores e envia para a rede, com ID=104 140 Coloca o nó em modo automático 042 Coloca o nó em modo de espera 004 Coloca o nó em modo de espera

  3C0 Coloca o nó em modo manual 000 Coloca o nó em modo de espera 044 Coloca o nó em modo de espera

5.9.3. Nó 3 - Acionamento

  Neste nó, tem-se o controle de velocidade dos dois motores responsáveis pelo deslocamento do AGV. Este controle é feito através do valor de velocidade desejado para os dois motores que é fornecido pela rede CAN. Além disso, para simular falhas que possam ocorrer tanto no motor ou no módulo de potência do acionamento, tem-se um sinal para cada um dos módulos, e, em uma eventual falha, uma mensagem de emergência é enviada para a rede. Para possibilitar o monitoramento dos itens comentados acima foram desenvolvidos os seguintes algoritmos:

  a) Algoritmo principal : responsável pela configuração do DSP e da configuração dos registradores para geração do sinal PWM para cada motor, além do teste de verificação da segurança dos dois motores;

  b) Algoritmo da interrupção INT 1: Tratar das interrupções geradas pela rede CAN. A atualização da velocidade ocorre também dentro do tratamento desta interrupção.

  Tem-se a seguir cada um dos algoritmos implementado.

  5.9.3.1. Algoritmo principal do nó 3 Como já comentado, além de ser responsável pela configuração do DSP e do controlador CAN, neste nó é necessário se fazer a inicialização dos parâmetros do gerenciador de eventos para possibilitar a geração de sinal PWM para os dois módulos, A e B, deste DSP. Tem-se então o algoritmo principal na figura 5.14

  Pode-se notar neste algoritmo a presença de uma etapa a mais que chama a função de inicialização do gerenciador de eventos, além da função de inicialização dos temporizadores. Além disso, como vê-se no programa, tem-se a inicialização das variáveis específicas do gerenciados de eventos, como o registrador de comparação e do período do

  MÓDULO DE ACIONAMENTO DECLARAđấO INÍCIO PROGRAMA PRINCIPAL Registradores CAN DE VARIÁVEIS Inicializa DSP ini_dsp( ) Inicializa Inicializa gerenciador FAZ AUTO-TESTE de eventos A e B ini_pwm( ) ini_can( ) IFR = 0xFFFFh DA REDE CAN teste_can( ) B Habilita Interrupção CLRC INTM SEL==2 can_transmit() SEL==1 can_transmit() N N S can_mailbox( ) S

can_mailbox( )

ID= 78A

ID= 10A

A

SEL=0

Figura 5.14. Algoritmo principal para o nó 3 A figura 5.14 finaliza com o envio de mensagens conforme a solicitação da rede.

  A segunda etapa deste algoritmo pode ser observada na figura 5.15, onde inicialmente faz-se a verificação do modo de operação, para em seguida fazer a verificação se alguma das entradas dos sensores do motor foi acionado, enviando uma mensagem em caso afirmativo

Figura 5.15. Algoritmo principal para o nó 3

  5.9.3.2 Algoritmo do tratamento da interrupção INT 1 do nó 3 Tem-se na figura 5.16 o algoritmo para tratamento da interrupção INT 1. As etapas do algoritmo da interrupção 1 do nó 3 são: a) Como a etapa inicial de verificação se a interrupção é devida à interrupção ocasionada pela rede CAN, como nas interrupções anteriores, este comentário será suprimido;

  b) Tem-se aqui a seqüência de verificação do bit identificador da mensagem, com as

Figura 5.16 Algoritmo para tratamento da interrupção INT 1 do nó 3Tabela 5.7 Relação das ações programadas para o nó 3

  ID Ação 780 Carrega o mailbox, sem dado, e envia para a rede, com ID=78A 002 Atualiza a velocidade dos motores, atualizando os registradores comparadores 508 Carrega o mailbox com o estado dos sensores e envia para a rede, com ID=10ª 140 Coloca o nó em modo automático habilitando o GPTimer 1 042 Coloca o nó em modo de espera desabilitando o GPTimer 1 110 Atualiza a velocidade dos motores, atualizando os registradores comparadores

  3C0 Coloca o nó em modo manual habilitando o GPTimer 1 000 Coloca o nó em modo de espera desabilitando o GPTimer 1 044 Coloca o nó em modo de espera desabilitando o GPTimer 1

5.9.4. Nó 4 – Navegação

  Segundo a proposta do sistema, o módulo de navegação será responsável pela geração da informação relativa a velocidade dos dois motores utilizados para fazer a movimentação do AGV. Para isso são necessário os seguintes algoritmos:

  a) Algoritmo principal : Neste caso, tem-se como função a configuração do DSP e do controlador CAN e fazer o teste do estado dos sensores para determinação da velocidade de cada motor do AGV;

  b) Algoritmo da interrupção INT 1: Como nos casos anteriores, é responsável pelo tratamento das interrupções geradas pela rede CAN, e conseqüentemente resulta em uma

  5.9.4.1. Algoritmo principal do nó 4 Na figura 5.17 tem-se o algoritmo principal.

  Como nas discussões anteriores, nesta primeira etapa do algoritmo tem-se como objetivo a configuração e inicialização de variáveis do DSP. Logo em seguida tem-se o envio da mensagem de acordo com o que foi selecionado na recepção de mensagens.

Figura 5.17 Algoritmo principal do nó 4

  INÍCIO DECLARAđấO DE VARIÁVEIS Inicializa Registradores CAN ini_can( ) Inicializa DSP ini_dsp( ) Habilita Interrupções

  MốDULO DE NAVEGAđấO

PROGRAMA PRINCIPAL

  FAZ AUTO-TESTE DA REDE CAN teste_can( ) A SEL==1 SEL==2 can_transmit()

can_mailbox( )

ID= 78A

can_transmit()

can_mailbox( )

ID= 10A

SEL=0 B S N S N

Figura 5.18 Algoritmo principal do nó 4

  Na segunda etapa do algoritmo principal do DSP, na figura 5.18, tem-se a verificação do modo de operação do nó. Se o mesmo estiver em modo automático faz-se a verificação se houve alteração no sinal dos sensores de entrada,e, em caso afirmativo, o algoritmo para determinação da velocidade dos motores é ativado, para depois enviar a informação da velocidade dos dois motores para a rede.

  Este algoritmo é baseado na aplicação de uma tabela de proporcionalidade, onde, de acordo com o estado dos sinais de entrada cada motor terá uma velocidade proporcional.

  Na figura 5.19 tem-se um exemplo do princípio de funcionamento do sistema ótico.

Figura 5.19 Princípio de funcionamento do sistema ótico

  O sistema é composto, por oito sensores infravermelhos, que são formados na verdade de conjuntos de emissores e receptores, dispostos de tal forma que, o sinal do emissor é apontado para a superfície por onde o AGV está percorrendo, considerando que a mesma reflita o sinal, o receptor é montado de tal forma que deve ficar dentro do campo de reflexão do sinal, e, não havendo nenhum obstáculo o mesmo é atuado. Pode-se observar ainda na figura 5.19 que no centro encontra-se uma fita, que é o elemento utilizado para demarcar a trajetória do AGV, que deve ter uma cor que contraste com a cor da superfície para permitir que o AGV identifique a trajetória que deva seguir e fazer as correções quando necessárias. Este sistema é baseado no trabalho desenvolvido por [Kondlatsck, 2002].

  No sistema proposto foram considerados como entrada as 8 chaves que estão ligadas na PORTA A do DSP. Assim, através da variação da abertura e fechamento dos contatos será possível simular o comportamento de um sistema de navegação ótico, o que evitaria de se encontrar problemas relativos a variação da reflexão de acordo com as irregularidades e variações dos índices de reflexão da superfície, necessitando da implementação de algoritmos especiais para tratamento de eventuais imperfeições ocasionadas pelo sistema, que não interessa na abordagem desta dissertação.

  Estipulou-se para isso um comportamento conforme descrito na tabela 5.8; em qualquer outra situação a velocidade dos motores será nula. Para a velocidade dos motores considerou-se um percentual da velocidade nominal, variando de zero até 90% da velocidade nominal. Assim, em uma eventual troca de motores, basta fazer a modificação do fator de conversão, no próprio nó do acionamento.

  

A7 A6 A5 A4 A3 A2 A1 A0 HEX M1 (%) M2 (%)

  1 F3

  1 F9

  1

  1

  1

  1

  1

  40

  60

  1

  30

  1

  1

  1

  1

  50

  50

  1 EF

  1

  1

  70

  1

  1

  1

  ID Ação 780 Carrega o mailbox, sem dado, e envia para a rede, com ID=78A 504 Carrega o mailbox com o estado dos sensores e envia para a rede, com ID=108 140 Coloca o nó em modo automático 042 Coloca o nó em modo de espera 004 Coloca o nó em modo de espera

Tabela 5.9 Relação das ações programadas para o nó 4

  Nas etapa inicial, com nos casos anteriores, tem-se a verificação do evento que gerou a interrupção, através da verificação do registrador PIVR. Na seqüência tem-se a verificação de qual mensagem foi recebida e aplica-se a ação correspondente de acordo com a tabela 5.9.

  5.9.4.2 Algoritmo do tratamento da interrupção INT 1 do nó 4 Tem-se na figura 5.20 o algoritmo para tratamento da interrupção INT 1.

  10

  90

  1 FE

  1

  1

  1

  1

  1

  1

  20

  80

  1 FC

  1

  1

  1

  1

  1

  1

  1

  1

  1

  90

  10

  7F

  1

  1

  1

  1

  1

  1

  1

  1 FF

  1

  1

  1

  1

  1

  1

  1

  1

  60

  30

  40

  1 CF

  1

  1

  1

  1

  1

  70

  9F

  1

  1

  1

  1

  1

  1

  1

  80

  20

  3F

  3C0 Coloca o nó em modo manual 000 Coloca o nó em modo de espera

Figura 5.20. Algoritmo para interrupção 1 do nó 4

5.9.5. Nó 5 – Módulo de Gerenciamento

  O nó 5 é o módulo de gerenciamento ( MG) do sistema, que, de acordo com as informações que circulam pela rede, irá tomar algumas decisões. Apesar de preservar a característica multi-mestre da rede, várias decisões tomadas nos nós são relativas às informações que circulam pela mesma. Por exemplo, conforme já apresentado, tanto o nó dos sensores de segurança como o nó do acionamento podem levar a rede toda para o modo de espera, mas somente o nó MG é que poderá levar o sistema ao modo automático, pois o mesmo estará monitorando a situação de cada nó e esperando o comando para entrar neste modo. Além disso, uma série de comandos são disponíveis através do comando de chaves que estão conectadas com a PORTA A do DSP, permitindo, por exemplo, que várias informações sejam solicitadas à rede, como por exemplo, tensão da bateria e estado dos sensores de segurança. Para permitir estas diversas funções são necessários os seguintes algoritmos: a) Algoritmo principal : Como nos demais casos, é utilizado para configuração do DSP, do controlador CAN e teste do estado das chaves conectadas a PORTA A; b) Algoritmo da interrupção INT 1: Responsável pelo tratamento das interrupções geradas pela rede CAN, e das ações subseqüentes;

  5.9.5.1 Algoritmo principal Assim como os demais, o algoritmo principal é responsável pela configuração do DSP, assim como de seus periféricos. Neste caso, além da próprio controlador CAN, utiliza-se as entradas analógicas.

  O algoritmo pode ser visto nas figuras 5.21 e 5.22.

PROGRAMA PRINCIPAL

Figura 5.21 Algoritmo principal do nó 5

  As etapas iniciais do algoritmo da figura 5.21 são de configuração do DSP, e nas etapas descritas no algoritmo da figura 5.22 compõem-se da verificação se houve alguma alteração nos sinais das chaves, e, em caso afirmativo, faz-se uma verificação procurando-se identificar qual foi a chave que alterou o seu estado, com a ação correspondente.

  INÍCIO DECLARAđấO DE VARIÁVEIS Inicializa Registradores CAN ini_can( ) Inicializa DSP ini_dsp( )

  Habilita Interrupções

  MÓDULO DE GERENCIAMENTO

  FAZ AUTO-TESTE DA REDE CAN teste_can( ) A SEL==1 SEL==2 can_transmit() can_mailbox( ) ID= 78A can_transmit() can_mailbox( ) ID= 10A SEL=0 B

S

N

S

N Inicializa Entrada Analógica ini_analogica( )

Figura 5.22 Algoritmo principal do nó 5

  5.9.5.2 Algoritmo do tratamento da interrupção INT 1 do nó 5

  Como em todo o projeto, a interrupção 1 foi utilizada para o atendimento da interrupção causada pelo controlador CAN do DSP. Em virtude da quantidade de mensagens envolvidas, dividiu-se o algoritmo em dois, conforme observa-se nas figuras 5.23 e 5.23 ()* +,(,-., " $ % $ $ $ / 12 3 /

" &

Figura 5.23 Algoritmo da interrupção 1 do nó 5 (parte 1)

  / !"" 5 $ !" % !"2 $ 5 5 !"/ 5 $ 4 $

  4 5 5

  4 5 Figura 5.24 Algoritmo para tratamento da interrupção 1 ( parte 2)

  Pode-se dividir nas seguintes etapas: a) Como também discutido nos demais casos, a primeira etapa é de verificação se a interrupção foi ocasionada pelo controlador CAN; b) Em uma segunda etapa, tem-se a identificação do tipo de mensagem recebida. No caso particular do MG, a quantidade de mensagens é muito maior que as demais, e estão na tabela 5.10.

Tabela 5.10 Relação das ações programadas para o nó 5

  ID Ação 0000 Coloca o nó em modo de espera 0002 Coloca o nó em modo de espera 0004 Velocidade dos motores M1 e M2 0040 Nível de tensão menor que 75% da tensão nominal, colocar o sistema em modo de espera 0100 Estado atual dos sensores de segurança 0102 Tensão da bateria menor que 90%, alerta bateria fraca 0104 Tensão atual da bateria 0108 Estado atual dos sensores de navegação

  010A Velocidade atual dos motores 0640 Sensores de segurança voltam para zero 0642 Nível de tensão da bateria maior que 90% 0644 Sensores dos motores voltam para zero 0788 Nó 1 em ordem 0789 Nó 2 em ordem

  078A Nó 3 em ordem 078B Nó 4 em ordem c) A terceira etapa é utilizada para fazer a leitura das chaves da PORTA A do DSP. Realiza- se a verificação de cada botão para identificar seu estado e a ação correspondente, o que resultará levar o sistema em diferentes condições, como colocando-o em modo automático ou manual, ou mesmo transferindo a tensão dos potenciômetros, para servir como referencia de velocidade para os motores do acionamento.

5.10 TESTES PARA VALIDAđấO DO CONJUNTO FINAL

  Para esta etapa dos testes foi necessário montar o conjunto completo dos cinco nós, conforme descrição feita durante este capítulo. Obteve-se a configuração final conforme a figura 5.25.

  Nó 1 Nó 2 Nó 3 Nó 5 Nó 4

Figura 5.25 Conjunto completo para testes

  Nos testes iniciais cada nó foi carregado com o mesmo programa do apêndice B, para um melhor controle sobre as respostas do sistema. A seqüência de testes encontra-se descrita a seguir.

  O objetivo deste teste é fazer uma verificação do funcionamento geral da rede e dos bits identificadores de cada nó. Para isso, inicialmente um nó irá carregar um conjunto de bits identificadores, enquanto os outros nós irão trabalhar apenas como receptores. Como não havia a disponibilidade de conectar cada nó a um computador, para acompanhar o valor de seu registrador através do code composer, foi elaborada uma pequena sub-rotina onde, se a mensagem era aceita acenderia o primeiro led do barramento da PORT A, caso contrário, o segundo. Na tabela 5.11 tem-se a seqüência de valores atribuídos para o restante dos nós.

Tabela 5.11. teste dos bits identificadores

  2) Teste das funções individuas de cada nó O objetivo deste teste é avaliar as funções de cada nó, conforme discussão anterior neste capítulo, para permitir a emulação de um AGV. Nesta etapa cada nó em teste é carregado com o seu programa original que está no apêndice C, enquanto o restante dos nós permanece com o programa básico de comunicação do apêndice B, onde nenhum dos nós responde

  ID do mailbox transmissor

  ID dos mailboxes receptores Status 00000000000 11111111111 Mensagem não aceita

  00000000011 00000000011 Mensagem aceita 00000011111 00000011000 Mensagem não aceita 00000011111 00000011111 Mensagem não aceita 11000000000 11100000000 Mensagem não aceita 11000000000 11000000000 Mensagem aceita 00000110000 11111111111 Mensagem não aceita 00000110000 11111111111 Mensagem não aceita 01010101010 01010101011 Mensagem não aceita 01010101011 01010101011 Mensagem aceita do mesmo nó, e, em uma segunda etapa, testar a resposta do nó as mensagens recebidas. Nessa segunda etapa um dos outros nós gera mensagens controladas, para isso foi em sua maioria utilizado o nó 5, e acompanha-se a reação do nó em teste. Assim, cada nó é testado individualmente de acordo com a seqüência a seguir.

  2.1) Teste do nó 1 Para simular o efeito de sensores de segurança foram utilizadas chaves acopladas a PORT

  A do DSP. Nenhum algoritmo para prevenir acionamentos indesejados pela eventual oscilação ocasionado pela comutação da chave foram implementado, nos testes realizados não se observou nenhum disparo acidental, mas para aplicações futuras é interessante que se observe este fato. Os eventos internos estão na tabela 5.12

Tabela 5.12 Mensagem do nó 1 por eventos internos

  Tipo de Identificador Evento Relacionado Mensagem

  Transmissão 11001000000 Sensores segurança desativados Transmissão 00000000000 Alteração do nível lógico dos sensores

  Para as mensagens recebidas, tem-se um número maior de eventos, como pode-se observar na tabela 5.13

Tabela 5.13 Eventos de resposta do nó 1

  2.2 Teste do nó 2 Neste módulo, para simular a variação da tensão da bateria, colocou-se um potenciômetro na entrada 1 da PORT A do DSP, assim, variando-se o potenciômetro obteve-se uma variação da tensão da entrada. O valor da tensão nominal de entrada é de 3 volts, sendo assim, o valor

  Tipo de Mensagem

  Identificador Ação Realizada Recepção 00000000010 Colocar em modo espera Recepção 00001000010 Colocar em modo espera Recepção 00001000100 Colocar em modo espera Recepção 00101000000 Colocar em modo automático Recepção 01111000000 Colocar em modo manual Recepção 10100000000 Solicitação do estado dos sensores de segurança Recepção 11110000000 Solicitação do estado do nó Recepção 00001000000 Colocar em modo espera

  Transmissão 00100000000 Informa o estado atual dos sensores de segurança depois da solicitação recebida Transmissão 11110001000 Informa o estado do nó depois da solicitação recebida

Tabela 5.14 Mensagem do nó 2 por eventos internos

  Tipo de Identificador Evento relacionado Mensagem 00001111001

  Transmissão 00001000000 Tensão da bateria Vbat < 75% nominal Transmissão 00100000010 Tensão da bateria Vbat < 90% nominal Transmissão 11001000010 Tensão da bateria Vbat >90% nominal

  Quando o sistema opera em modo automático, o nó envia a informação da tensão da bateria quando ela ultrapassar determinadas faixas, conforme pode ser visto na tabela 5.14. Por outro lado, ele pode receber uma solicitação para informar o estado atual da bateria, conforme pode ser observado na tabela 5.15.

Tabela 5.15 Eventos de resposta do nó 2

  Tipo de Identificador Ação Realizada Mensagem 00001111001

  Recepção 00000000000 Colocar em modo espera Recepção 00000000010 Colocar em modo espera Recepção 00001000010 Colocar em modo espera Recepção 00001000100 Colocar em modo espera Recepção 11110000000 Solicitação do estado do nó Recepção 00101000000 Colocar em modo automático Recepção 01111000000 Colocar em modo manual Recepção 10100000010 Solicitação da tensão da bateria

  Transmissão 00100000100 Informa a tensão da bateria

  2.3 Teste do nó 3 Para o nó 3 a informação relativa a velocidade dos motores deve ser recebida constantemente, pois ,caso contrário, pode-se ter um erro na trajetória do AGV. Mas além disso, com intuito de simular uma supervisão de corrente e temperatura, foram colocadas duas chaves para cada motor, e quando houver algum eventos mencionados indica uma falha grave no AGV e o nó deve mandar uma mensagem para a rede com intuito de paralisar o AGV. Os eventos internos estão descritos na tabela 5.16.

Tabela 5.16 Mensagem do nó 3 por eventos internos

  Tipo de Identificador Evento relacionado Mensagem 00000100001

  Transmissão 00000000100 Sensores dos motores atuados Transmissão 11001000100 Sensores dos motores desatuados

  As mensagens relativas aos eventos externos encontram-se na tabela 5.17

Tabela 5.17 Eventos de resposta do nó 3

  2.4 Teste do nó 4 Na simulação dos sensores do nó 4, foi feita através do acionamento de chaves acopladas à

  PORT A do DSP. Deve-se observar que, não foi implementado nenhum filtro para prevenir o acionamento indevido de algum sensor, como apresenta [Kondlatsck, 2002]. Os eventos internos estão descritos na tabela 5.18.

  Tipo de Mensagem

  Identificador 00000100001

  Ação Realizada Recepção 00000000000 Colocar em modo espera Recepção 00000000100 Velocidade de referência Recepção 00001000010 Colocar em modo espera Recepção 00001000100 Colocar em modo de espera Recepção 00100010000 Referência de velocidade para os motores Recepção 00101000000 Colocar em modo automático Recepção 01111000000 Colocar em modo manual Recepção 10100001000 Solicitação da velocidade atual dos motores Recepção 11110000000 Solicitação do estado de todos os nós Recepção 00001000000 Colocar em modo espera

  Transmissão 00100001010 Informar a velocidade atual dos motores Transmissão 11110001010 Informar o estado do nó

Tabela 5.18 Mensagem do nó 4 por eventos internos

  O sistema de navegação somente informa a direção para cada motor quando a rede estiver operando no modo automático, pois quando estiver no modo manual esta informação vem do nó 5. As mensagens relativas aos eventos externos encontram-se na tabela 5.19

Tabela 5.19 Eventos de resposta do nó 4

  2.5 Teste do nó 5 Tipo de

  Mensagem Identificador

  00000110001 Evento relacionado

  Transmissão 00100001000 Informa a velocidade de cada motor após um intervalo de tempo

  Mensagem Tipo de Mensagem

  Identificador 00000110001

  Ação Realizada C Recepção 00000000000 Colocar em modo espera

  S Recepção 00000000010 Colocar em modo espera M Recepção 00001000010 Colocar em modo espera

  V Recepção 00001000100 Colocar em modo espera L Recepção 00101000000 Colocar em modo automático

  U Recepção 01111000000 Colocar em modo manual O Recepção 10100000100 Solicitação do estado dos sensores de navegação A Recepção 11110000000 Solicitação do estado do nó H Recepção 00001000000 Colocar em modo espera B Transmissão 11110001011 Informa o estado do nó O nó 5 gerencia toda a rede, sendo que somente ele é que pode colocar a rede em modo manual ou automático, além de outras funções. Os comandos de solicitação podem ser feitos através das chaves acopladas a PORT A do DSP, comandos estes que podem ser de uma solicitação da tensão da bateria ou velocidade dos motores, ou então após a inicialização uma solicitação do estado de cada nó. Os eventos internos estão descritos na tabela 5.20.

Tabela 5.20 Mensagem do nó 5 por eventos internos

  Além dos eventos internos o nó 5 tem uma série de mensagens que circulam pela rede em que ele recebe informações e, principalmente toma conhecimento dos alarmes em que alguns Tipo de

  Mensagem Identificador Evento relacionado

  Transmissão 00001000010 Botão8 = 0(coloca rede em modo de espera) Transmissão 00001000100 Botão4 = 1(coloca rede em modo de espera) Transmissão 10100000000 Botão1 = 1(solicita o estado dos sensores de segurança) Transmissão 00100010000 Em modo manual, após um determinado tempo, informa a velocidade de referência para os motores

  Transmissão 00101000000 Botão8 = 1(coloca rede em modo automático) Transmissão 01111000000 Botão5 = 1(coloca rede em modo manual) Transmissão 10100000010 Botão2 = 1(solicita a tensão da bateria) Transmissão 10100000100 Botão3 = 1(solicita o estado dos sensores de navegação) Transmissão 10100001000 Botão4 = 1(solicita a velocidade atual dos motores) Transmissão 11110000000 Após a inicialização solicita o estado dos nós

Tabela 5.21 Eventos de resposta do nó 5

  Como conclusão geral dos testes realizados nesta seqüência eles apresentaram um bom Mensagem Tipo de

  Mensagem Identificador Ação Realizada

  C Recepção 00000000000 Sensores segurança ativados (Colocar a rede em modo de espera)

  S Recepção 00000000010 Sensores dos motores ativados (Colocar a rede em modo de espera)

  N Recepção 00000000100 Velocidade de referência dos motores H Recepção 00001000000 Tensão da bateria Vbat < 75% nominal (Colocar a rede em modo de espera)

  F Recepção 00100000000 Estado dos sensores segurança G Recepção 00100000010 Tensão da bateria Vbat < 90% nominal (Levar AGV para carregar bateria)

  K Recepção 00100000100 Tensão da bateria P Recepção 00100001000 Estado dos sensores de navegação

  R Recepção 00100001010 Velocidade atual dos motores D Recepção 11001000000 Sensores segurança desativados

  J Recepção 11001000010 Tensão da bateria Vbat >90% nominal T Recepção 11001000100 Sensores dos motores desatuados B Recepção 11110001000 Estado do nó 1 B Recepção 11110001001 Estado do nó 2 B Recepção 11110001010 Estado do nó 3 B Recepção 11110001011 Estado do nó 4 ficar acompanhando com o osciloscópio a rede muitas vezes foi necessário implementar sub- rotinas para permitir visualizar os resultados. Infelizmente aconteceram alguns incidentes, que resultaram na queima de alguns transceivers, e uma saída CAN de um DSP.

  

CAPÍTULO 6

CONCLUSÕES E TRABALHOS FUTUROS

  Nesta dissertação apresentou-se o estudo e o desenvolvimento de um protocolo de comunicação entre DSPs, baseados nos serviços fornecidos pelas duas camadas do modelo

  ISO/OSI da rede CAN, segundo a metodologia proposta por Etschberger.

  Assim, como contribuição inicial desta dissertação, é o estudo e a documentação dos da rede CAN e do controlador CAN do DSP TMS320F2407. Além do mais uma série de algoritmos e funções foram implementadas, possibilitando a continuação de trabalhos por outros acadêmicos. Pode-se destacar o estudo e desenvolvimento de uma metodologia protocolo de comunicação CAN, em particular utilizando DSPs, criando uma estrutura que possibilitará expansões futuras.

  Ainda como contribuição principal, deve-se ressaltar o estudo e implementação voltados para a aplicação da rede CAN em um AGV. Com os testes iniciais foi possível verificar que existe a possibilidade da utilização da rede CAN para comunicação entre os módulos de um AGV, pensado certamente em uma arquitetura distribuída, pois foi possível observar que, durante o desenvolvimento desta rede, um série de detalhes relativos as características desses módulos, como previsão de alarmes, sensoriamento de segurança, onde a filosofia da rede CAN, de trabalhar com prioridade em mensagens, através da utilização de identificadores de mensagens, será bastante útil para a aplicação. Com isso, mensagens com maior prioridade poderão ser alocados para os sistemas mais críticos, evitando se trabalhar com uma arquitetura mestre-escravo, mas sim com a característica da rede CAN, que é trabalhar como uma rede multi-mestre.

  Quanto às interrupções encontrou-se uma dificuldade considerável para tratamento das mesmas, visto que, durante a dinâmica de troca de mensagens, o fato de habilitar as interrupções, tanto de envio como de recebimento de mensagens, trouxe alguns levado a zero, como é o mesmo para os dois eventos, o bit de sinalização de recebimento já estava ativo, assim a interrupção de recebimento não ocorria. Este problema foi solucionado utilizando-se pooling para a transmissão de mensagens, ficando a interrupção apenas para a recepção de mensagens. Ainda quanto a interrupção verificou-se que a possibilidade de selecionar se a interrupção se era de maior ou menor grau de prioridade possibilitará gerar uma maior flexibilidade no futuro, pois com um aumento do número de mensagens será possível selecionarmos uma maior prioridade para a recepção de mensagens.

  No momento, como o número de mensagens não foi muito grande, a recepção apenas por um mailbox revelou-se suficiente, mas um acréscimo no número de mensagens possivelmente levará a necessidade de se utilizar outras mailboxes. Nesse sentido, algumas experiências foram feitas utilizando-se as outras mailboxes, e nenhuma dificuldade adicional foi encontrada.

  Como caso particular, o desenvolvimento foi baseado em um DSP da família C2000 da Texas Instruments, devido ao interesse em particular de alguns professores do departamento de engenharia elétrica da UDESC pela sua aplicação em controle digital. Neste sentido alguns testes, com o gerenciador de eventos, utilizados para a geração de sinal PWM foram realizados.

  Uma das grandes dificuldades encontradas foram os testes dos algoritmos com mais de dois nós envolvidos, pois como não havia alguma forma de se monitorar o sinal na velocidade e seqüência de eventos que ocorreram, então houve a necessidade de se implementar algoritmos especificamente para o teste das diversas funções, o que acabou por ocupar grande parte do tempo utilizado durante a implementação do projeto. Como contribuições secundárias poderia se ressaltar:

  • Por se tratar de uma tecnologia cuja aplicação vem se desenvolvendo a cada dia, a

  utilização de DSPs revela-se como um marco para a UDESC, demonstrando sua documentar em detalhes o capítulo sobre o DSP, para que o mesmo possa servir de referência para futuros trabalhos acadêmicos;

  • A aplicação na automação industrial de protocolos de comunicação em arquiteturas

  descentralizadas vem crescendo a cada dia. Mas o enfoque geralmente dado é da utilização de protocolos comerciais consagrados. Assim o estudo da tecnologia de base, no desenvolvimento de protocolos de comunicação em tempo real muitas vezes fica relegado a um segundo plano, e através desta dissertação procura-se dar os subsídios necessários para o desenvolvimentos de trabalhos futuros nesta linha de pesquisa;

6.1 PROPOSTAS DE TRABALHOS FUTUROS

  Com recomendações para trabalhos futuros poderia-se destacar:

  • Estender os estudos para utilização dos novos processadores da linha C2000 da Texas

  Instruments, TMS320LF28X, de 32 bits. Que possuem capacidade de processamento muito maior que a anterior, e além disso, a plataforma de desenvolvimento, o Code Composer, em sua nova versão, já incorpora a possibilidade de utilização da linguagem C++. Com isso abre-se toda uma nova linha de trabalho, pois possibilitará o desenvolvimento orientado a objeto para cada nó, além de permitir a utilização de novas metodologias de modelagem, como a UML, que permitirá refinar a metodologia para elaboração de um protocolo de comunicação aqui apresentada. Aumentar o número de nós e implementar mais funções nos nós existentes. Com isso

  • possibilitará a criação de um número maior de mensagens que circularão pela rede, e assim avaliar o comportamento da estrutura propo
  • Fomentar o desenvolvimento de um AGV, pelo departamento de engenharia elétrica

  Fazer um estudo comparativo em relação a diferentes controladores CAN existentes no

  • mercado, procurando avaliar as suas características e possibilidades de uso e incorporação na rede elabor
  • • Aproveitar a estrutura e conhecimentos adquiridos para implementar uma estrutura

  fixa que permita aos acadêmicos do mestrado e alunos da graduação, o estudo e desenvolvimentos de trabalhos de pesquisa relativos a protocolos de comunicação, com aplicação em sistemas embarcados para comunicação em tempo real.

  REFERÊNCIA BIBLIOGRÁFICA .

  [Berkeley, 2000] Berkeley Design Technology. Choosing a DSP Processor. Berkeley Design Technology, Inc. 2000

  [Berkeley, 2001] Evaluating DSP Processor Performance. Berkeley Design Technology, Inc. 2001

  TM

  [Berkeley, 2002] The BDTImark200 : A Measure of DSP Execution Speed. Berkeley Design Technology, Inc. 2002

[Bosch, 1991] Robert Bosch GmbH. CAN Specification 2.0.

  1991 [Bosteels, 2002] Bosteels, Jan. Coordinated Multi-Axis Motion Control via CAN bus.

  8th International CAN Conference, 2002 [Charzinski, 1997] Charzinski, Joachim. Performance of the Error Detection Mechanisms

  

in CAN . 4th International CAN Conference, 1997

  [Corrigan, 2002] Corrigan, Steve. Introduction to the Controller Area Network. Texas Instruments Inc. 2002

  

[Craig, 1996] Craig Marven, Gillian Ewer. A Simple Approach

to Digital Signal Processing. Wiley-Interscience

  Publication. 1996

  [Dunne, 1998] Dunne, Alan, Dillon, Paul, Heffernan, Donald. , Stack, Paul. A CAN

  Based Emergency Light Test Nework . 5th International CAN

  Conference 1998 [Etschberger, 2001] Etschberger Konrad. Controller Area Network. Basic,Protocols, Chips and Applications.

  IXXAT Press, Germany 2001 [Eyre, 2000] Eyre, Jennifer; Bier, Jeff. The Evolution of DSP Processors. Berkeley

  Design Technology, Inc. 2000 [Ford, 2001] Ford Motor Company. Electronic Control Unit and Subsytem

  Requirements Specification. 2001 [Forward, 2003] Forward Concepts. Market Bulletin.2003 [Hartwich, 1999] Hartwich, Florian; Bassemir, Armin. The Configuration of the CAN Bit

  

Timing . 6th International CAN Conference 1999

  [Lapsley, 1997] Lapsley,Phil; Bier,Jeff; Shoham, Amit; Lee, Edward A. DSP Processor

  Fundamentals: Architecture and Features

  IEEE Press. 1997 [Lennartsson, 2002] Lennartsson, Per; Nordlander, Lars. Benchmarking a DSP processor.

  Master Thesis. Linköping, 2002.

  [Punnekkat, 2000] Punnekkat, Sasikumar; Hansson, Hans; Norströml, Christer. Response . 6th IEEE Real Time Technology

  Time Analysis under Erros for CAN

  and Applications Symposium, 2000 [Rufino, 2000] Rufino, José. Veríssimo, Paulo; Almeida, Carlos . Fault-Tolerant

  Broadcasts in CAN . Lisboa, 2000

  [Schnelle, 1995] Schnelle, O. CAN Networks in Ship Automation Systems. 2th International CAN Conference, 1995

  [Spectrum, 2000] Spectrum Digital Inc. , TMS320LF2407 DSK Technical Reference. 2000 [Texas, 1995] Texas Instruments Inc. TMS320C1x/ C2x/ C2xx/ C5x. Assembly

  Language Tools . 1995

  [Texas, 1999] Texas Instruments Inc. TMS320F/C24x. DSP Controllers CPU and

  Instruction Set . 1999

  [Texas, 2001] Texas Instruments Inc. TMS320F/C24x. DSP Controllers Systems and

  Peripherals . 2001

  [Texas, 1997] Texas Instruments Inc. TMS320 DSP Develpment Support. Reference . 1997

  Guide,

  [Tindell, 1999] Tindell, Ken. Guaranteeing Message Latencies on Control Area

  Network port. , York, 1999

  APÊNDICE A

  A seguir são apresentadas as tabelas com um detalhamento de quais são as mensagens recebidas ou enviadas, quem é o nó emissor e o receptor, além da identificação de qual é a mensagem para cada nó. Estas tabelas são muito úteis na elaboração dos algoritmos e na programação, pois disponibiliza de forma clara e sucinta as informações necessárias para o programador. Inicialmente tem-se a tabela geral de mensagens que foi desenvolvida, e na seqüência as mensagens de cada nó.

  Mensa- Descrição Nós Dado Evento Nós gem Emissores (Bytes) Receptores

  A Solicita o estado de

  5 Após inicialização 1,2,3,4,5

  todos os nós

  B 1,2,3,4

  5 Cada nó informa seu Enviada após receber a

  estado solicitação do nó 5

  C Sensores segurança

  1

  1 Alteração do nível lógico 2,3,4,5 ativados dos sensores

  D Sensores segurança

  1 Sensores desativados

  5

  desativados E Solicita o estado dos

  5 Botão1 = 1

  1 sensores de segurança

  F Estado dos sensores

  1

  1 Solicitação pelo nó 5

  5 segurança G Tensão da bateria

  2

  1 Tensão da bateria Vbat <

  5 Vbat < 90% nominal 90% nominal H Tensão da bateria

  2

  1 Tensão da bateria Vbat < 1,3,4,5 Vbat < 75% nominal 75% nominal

  I Solicita a tensão da

  5 Botão2 = 1

  2 bateria J Tensão da bateria

  2

  1 Tensão da bateria Vbat

  5 Vbat >90% nominal >90% nominal K Tensão da bateria

  2

  1 Solicitação pelo nó 5

  5 L Colocar em modo

  5 Botão8 = 1 1,2,3,4 automático M Colocar em modo

  5 Botão8 = 0 1,2,3,4 espera N Velocidade de

  4

  2 Intervalo de tempo 1,2,3,4,5 Mensa- Descrição Nós Dado Evento Nós gem Emissores (Bytes) Receptores P Estado dos sensores

  4

  1 Solicitação do nó 5

  5 de navegação Q Solicita a velocidade

  5 Botão4 = 1

  4 atual dos motores R Velocidade atual dos

  4

  2 Solicitação do nó 5

  5 motores S Sensores dos

  4

  1 Sensores dos motores 1,2,3,5 motores atuados atuados T Sensores dos

  4 Sensores dos motores

  5 motores desatuados desatuados U Colocar em modo

  5 Botão5 = 1 1,2,3,4 manual

  V Colocar em modo de

  5 Botão4 = 1 1,2,3,4 espera W Referência de

  5

  2 Intervalo de tempo

  5 velocidade para os motoes A.1 Nó 1 Tabela A.1 Relação de mensagens do nó 1

  Grupo de Mensagem

  Mensagem Tipo de Mensagem

  Identificador Hexadecimal

  1 S Recepção 00000000010 0002

  4 M Recepção 00001000010 0042

  4 V Recepção 00001000100 0044

  2 L Recepção 00101000000 0140

  3 U Recepção 01111000000

  03C0

  7 E Recepção 10100000000 0500

  5 A Recepção 11110000000 0780

  4 H Recepção 00001000000 0040

  8 D Transmissão 11001000000 0640

  6 F Transmissão 00100000000 0100

  1 C Transmissão 00000000000 0000

  5 B Transmissão 11110001000 0788 A.1 Nó 2 Tabela A.2 Relação de mensagens do nó 2

  Grupo de Mensagem

  3 U Recepção 01111000000

  8 J Transmissão 11001000010 0642

  6 K Transmissão 00100000100 0104

  6 G Transmissão 00100000010 0102

  4 H Transmissão 00001000000 0040

  7 I Recepção 10100000010 0502

  03C0

  2 L Recepção 00101000000 0140

  Mensagem Tipo de Mensagem

  5 A Recepção 11110000000 0780

  4 V Recepção 00001000100 0044

  4 M Recepção 00001000010 0042

  1 S Recepção 00000000010 0002

  1 C Recepção 00000000000 0000

  Valor Hexadecimal

  Identificador 00001111001

  5 B Transmissão 11110001001 0789 A.1 Nó 3 Tabela A.3 Relação de mensagens do nó 3

  Grupo de Mensagem Tipo de Identificador Hexadecimal Mensagem Mensagem 00000100001

  1 C Recepção 00000000000 0000

  1 N Recepção 00000000100 0004

  4 M Recepção 00001000010 0042

  4 V Recepção 00001000100 0044

  6 W Recepção 00100010000 0110

  2 L Recepção 00101000000 0140

  3 U Recepção 01111000000

  03C0

  7 Q Recepção 10100001000 0508

  5 A Recepção 11110000000 0780

  4 H Recepção 00001000000 0040

  1 S Transmissão 00000000100 0004

  6 R Transmissão 00100001010 010A

  8 T Transmissão 11001000100 0644

  5 B Transmissão 11110001010 078A A.1 Nó 4 Tabela A.4 Relação de mensagens do nó 4

  Grupo de Mensagem

  Mensagem Tipo de Mensagem

  Identificador 00000110001

  Hexadecimal

  1 C Recepção 00000000000 0000

  1 S Recepção 00000000010 0002

  4 M Recepção 00001000010 0042

  4 V Recepção 00001000100 0044

  2 L Recepção 00101000000 0140

  3 U Recepção 01111000000

  03C0

  7 O Recepção 10100000100 0504

  5 A Recepção 11110000000 0780

  4 H Recepção 00001000000 0040

  6 P Transmissão 00100001000 0108

  5 B Transmissão 11110001011 078B A.1 Nó 5 Tabela A.5 Relação de mensagens do nó 5

  Grupo de Mensagem Mensagem Tipo de Mensagem Identificador Hexadecimal

  5 B Recepção 11110001001 0789

  7 O Transmissão 10100000100 0504

  7 I Transmissão 10100000010 0502

  03C0

  3 U Transmissão 01111000000

  2 L Transmissão 00101000000 0140

  6 W Transmissão 00100010000 0110

  7 E Transmissão 10100000000 0500

  4 V Transmissão 00001000100 0044

  4 M Transmissão 00001000010 0042

  5 B Recepção 11110001011 078B

  5 B Recepção 11110001010 078A

  5 B Recepção 11110001000 0788

  1 C Recepção 00000000000 0000

  8 T Recepção 11001000100 0644

  8 J Recepção 11001000010 0642

  8 D Recepção 11001000000 0640

  6 R Recepção 00100001010 010A

  6 P Recepção 00100001000 0108

  6 K Recepção 00100000100 0104

  6 G Recepção 00100000010 0102

  6 F Recepção 00100000000 0100

  4 H Recepção 00001000000 0040

  1 N Recepção 00000000100 0004

  1 S Recepção 00000000010 0002

  7 Q Transmissão 10100001000 0508

  

APÊNDICE B

  Na seqüência é a apresentado o programa padrão que foi utilizado nos testes iniciais referentes ao capítulo 4.

  /*****************************************************************/ /* Programa para Teste Inicial */ /* */ /*****************************************************************/ #include "regs2407.h" /************* Definição das Entradas *************************/ /****************** MCRA **********************************/ #define MCRA15 0 /* 0 : IOPB7 1 : TCLKIN */ #define MCRA14 0 /* 0 : IOPB6 1 : TDIR */ #define MCRA13 0 /* 0 : IOPB5 1 : T2PWM */ #define MCRA12 0 /* 0 : IOPB4 1 : T1PWM */ #define MCRA11 0 /* 0 : IOPB3 1 : PWM6 */ #define MCRA10 0 /* 0 : IOPB2 1 : PWM5 */ #define MCRA9 0 /* 0 : IOPB1 1 : PWM4 */ #define MCRA8 0 /* 0 : IOPB0 1 : PWM3 */ #define MCRA7 0 /* 0 : IOPA7 1 : PWM2 */ #define MCRA6 0 /* 0 : IOPA6 1 : PWM1 */ #define MCRA5 0 /* 0 : IOPA5 1 : CAP3 */ #define MCRA4 0 /* 0 : IOPA4 1 : CAP2/QEP2 */ #define MCRA3 0 /* 0 : IOPA3 1 : CAP1/QEP1 */ #define MCRA2 0 /* 0 : IOPA2 1 : XINT1 */ #define MCRA1 0 /* 0 : IOPA1 1 : SCIRXD */ #define MCRA0 0 /* 0 : IOPA0 1 : SCITXD */ /****************** MCRB **********************************/ #define MCRB9 0 /* 0 : IOPD1 1 : XINT2/EXTSOC */ #define MCRB8 1 /* 0 : CKLKOUT 1 : IOPD0 */ #define MCRB7 1 /* 0 : IOPC7 1 : CANRX */ #define MCRB6 1 /* 0 : IOPC6 1 : CANTX */ #define MCRB5 0 /* 0 : IOPC5 1 : SPISTE */ #define MCRB4 0 /* 0 : IOPC4 1 : SPICLK */ #define MCRB3 0 /* 0 : IOPC3 1 : SPISOMI */ #define MCRB2 0 /* 0 : IOPC2 1 : SPISIMO */ #define MCRB1 1 /* 0 : BIO 1 : IOPC1 */ #define MCRB0 1 /* 0 : XF 1 : IOPC0 */ /****************** MCRC ************************************/ #define MCRC13 0 /* 0 : IOPF5 1 : TCLKIN2 */ #define MCRC12 0 /* 0 : IOPF4 1 : TDIR2 */ #define MCRC11 0 /* 0 : IOPF3 1 : T4PWM/T4CMP */

  #define MCRC7 0 /* 0 : IOPE7 1 : CAP4/QEP2 */ #define MCRC6 0 /* 0 : IOPE6 1 : PWM12 */ #define MCRC5 0 /* 0 : IOPE5 1 : PWM11 */ #define MCRC4 0 /* 0 : IOPE4 1 : PWM10 */ #define MCRC3 0 /* 0 : IOPE3 1 : PWM9 */ #define MCRC2 0 /* 0 : IOPE2 1 : PWM8 */ #define MCRC1 0 /* 0 : IOPE1 1 : PWM7 */ #define MCRC0 0 /* 0 : IOPE0 1 : CLKOUT */ /****************************************************************/ /*************** Programação do Watchdog - WDCR ****************/ #define WDDIS 1 /* 0 : Watchdog Habilitado 1: Desabilitado*/ #define WDCHK2 1 /* 0 : Reset 1: Normal */ #define WDCHK1 0 /* 0 : Normal 1: Reset */ #define WDCHK0 1 /* 0 : Reset 1: Normal */ #define WDSP 7 /* Escala do Watchdog 7 : dividido por 64 */ /****************************************************************/ /**************** Programação do SCSR1 **************************/ #define CLKSRC 0 /* 0 : Interno (20MHz) */ #define LPM 0 /* 0 :Modo de operação 0 se for para idle */ #define CLK_PS 3 /* 001 : PLL multiplicar por 2 */ #define ADC_CLKEN 1 /* 1 : Com ADC */ #define SCI_CLKEN 0 /* 0 : Sem SCI */ #define SPI_CLKEN 0 /* 0 : Sem SPI */ #define CAN_CLKEN 1 /* 0 : Com CAN */ #define EVB_CLKEN 0 /* 0 : Sem EVB */ #define EVA_CLKEN 0 /* 1 : Sem EVA */ #define ILLADR 1 /* 1 : Clear ILLADR durante inicialização */ /****************************************************************/ /**************** Programação de Estados de Espera - WSGR ******/ #define BVIS 0 /* 10-9 : 00 Barramento OFF */ #define ISWS 0 /* 8 -6 : 000 0 Waitstates para IO */ #define DSWS 0 /* 5 -3 : 000 0 Waitstates para dados */ #define PSWS 0 /* 2 -0 : 000 0 Waitstates códigos */ /****************************************************************/ /****************** Programação do IMR ********************/ #define INT6 0 /* 5 : Level INT6 mascarada */ #define INT5 0 /* 4 : Level INT5 mascarada */ #define INT4 0 /* 3 : Level INT4 mascarada */ #define INT3 0 /* 2 : Level INT3 mascarada */ #define INT2 0 /* 1 : Level INT2 mascarada */ #define INT1 1 /* 0 : Level INT1 mascarada */

/***********************************************************************/

/*********** Programação do Registrador MCR ( CAN Master Control)*******/

#define CAN_SUSP 0 /* 13 : Modo Soft : Para a CAN quando transmissão estiver*/ #define CAN_CCR 1 /* 12 : Acesso para configuração de registrador */ #define CAN_PDR 0 /* 11 : Trabalho normal ( sem power down ) */ #define CAN_DBO 1 /* 10 : Ordem dos bytes : 0,1,2,3,4,5,6,7 */

#define CAN_WUBA 0 /* 9 : Acorda do modo power down após escrever 0 em

  #define CAN_STM 0 /* 6 : não utiliza modo de auto-teste */ #define CAN_MBNR 0 /* 1-0: Número do Mailbox */ /***********************************************************************/ /**Programação do BCRn ( Bit Configuration Register - CA_BCAN_BCR1) ****/ #define CAN_BRP 14 /* Baud rate */

#define CAN_SBG 1 /* Sincronismo da rede CAN em as de subida e descida */

#define CAN_SJW 2 /* Syncronismo com jump */ #define CAN_SAM 0 /* Faz somente uma amostragem por bit */ #define CAN_TSEG1 10 /* Time Segment 1 */ #define CAN_TSEG2 7 /* Time Segment 2 */ /***********************************************************************/ /****** Programação do MDER (Mailbox Direction/Enable ) */ #define CAN_MD 0 /* 7-6 : 00 mailbox 2 and 3 são transmissores */ #define CAN_ME 0 /* 5-0 : mailbox 0 to 5 desabilitado */ /***********************************************************************/ /****** SETUP for the CAN MAILBOX # 5 ( transmit) */ #define MB5_IDE 0 /* 11-bit identificadores */ #define MB5_AME 0 /* mascara local habilitada */ #define MB5_AAM 0 /* não responde solicitação remota */ #define MB5_ID_EXTL 0x0000 /* extended identifier bits 15-0 */ /***********************************************************************/ /****** Programação do MAILBOX # 0 ( Receptor) */ #define MB0_IDE 0 /* somente 11-bit de identificadores */

#define MB0_AME 1 /* a máscara local de aceitação está habilitada */

#define MB0_AAM 0 /* não responde a solicitação de mensagem remota */ #define MB0_ID_STD 0x0160 /* Identificador de recepção padrão */ #define MB0_ID_EXTL 0x0000 /* Identificador estendido */ #define MB0_LAMI 1 /* Frames identificadores padrão e estendido são recebidos */

#define MB0_LAMH 0x0FFF /* filtro aplicado nos identificadores ID 11-0 */

#define MB0_LAML 0xFFFF /* máscara inferior não utilizada */ /****************************************************************/ /* Declaração de funções */ /****************************************************************/ void can_receive(void); void can_init(void); void c_dummy1(void); interrupt void c_recep(void); /****************************************************************/ /* Definição de Variáveis Globais */ /****************************************************************/ /* ponteiros para as seis mailboxes */ unsigned int *CANMSGIDL[6]; /*Identificador de mensagem-bits menos sig*/ unsigned int *CANMSGIDH[6]; /*Identificador de mensagem-bits mais sig */ unsigned int *CANMSGCTRL[6]; /* Controle da mensagem */ unsigned int *CANDATA0[6]; /* Byte de dados 0 das mensagems */ unsigned int sel=0,m,n,mensagem,id=0; unsigned int sensores=0; unsigned int modo=0;

  /*****************************************************************/ /* Inicialização da Rede CAN */ /*****************************************************************/ void can_init(void) { unsigned int i; for (i=0;i<6;i++){ /* programacão dos ponteiros para as mailboxes */

  CANMSGIDL[i] = (unsigned int *)(0x7200 +i*8); CANMSGIDH[i] = (unsigned int *)(0x7201 +i*8); CANMSGCTRL[i] = (unsigned int *)(0x7202 +i*8); CANDATA0[i] = (unsigned int *)(0x7204 +i*8); }

/* Inicialização do registrador MCR ( Master Control Registers ) */

  CAN_MCR |= ((CAN_SUSP<<13)+(CAN_CCR<<12)+(CAN_PDR<<11)+

(CAN_DBO<<10)+(CAN_WUBA<<9)+(CAN_CDR<<8)+

(CAN_ABO<<7)+(CAN_STM<<6)+ CAN_MBNR ); /* Espera para confirmação da habilitação de CCR */ while((CAN_GSR & 0x0010) == 0 ); /* Inicialização de BCR2 e BCR1 */ CAN_BCR2 = CAN_BRP; CAN_BCR1 = ((CAN_SBG<<10)+(CAN_SJW<<8)+(CAN_SAM<<7)+

  (CAN_TSEG1<<3)+(CAN_TSEG2)); CAN_MCR &= 0xEFFF; /* apaga CCR */

/* Espera até que o bit CCE do registrador GSR for setado */

while((CAN_GSR & 0x0010) != 0 );

  

/* prepara máscara de aceitação local para mailbox 0 */

CAN_LAM0_H = ((MB0_LAMI<<15)+(MB0_LAMH<<2)); CAN_LAM0_L = MB0_LAML; /* desabilita todas as mailboxes */ CAN_MDER = ((CAN_MD<<6)+CAN_ME); /* habilita o aceso ao campo de dados (MCR-bit 8 = 1) */ CAN_MCR |= 0x0100;

/* prepara mailbox 0 para receber os frames de mensagem */

  • CANMSGIDH[0]= (MB0_ID_STD<<2);
  • CANMSGIDL[0]= MB0_ID_EXTL;

    /* desabilita o acesso ao frame de dados (MCR bit 8 = 0) */

    CAN_MCR &= 0xFEFF ; CAN_IFR=0x0100;

  IFR=0x00ff; CAN_MDER = 0x0001; CAN_IMR = 0x0100;

  IMR=0x0001; }

/*********************************************************************/

/********************** TRANSMISSÃO ********************************/

/*********************************************************************/

void can_transmit5(void) { unsigned int l;

  IMR=0x0000; m=m+1; CAN_TCR = 0x0080; /* transmit request set (TRS)mailbox#5 */ while((CAN_TCR & 0x8000) ==0); /* espera por transmit ACK */

  /* mailbox #5 : Bit 15 = 1 */ while((CAN_IFR &= 0x2000)==0); /* espera MIF5= 1 */ CAN_TCR |= 0x8000; /* Reset TA and interrupt flag */ PEDATDIR = 0xFFAA;

  IFR=0x00ff; CAN_MDER = 0x0001; CAN_IMR = 0x0100;

  IMR=0x0001; } void can_mailbox5(unsigned int mess) { unsigned int l;

  /* habilitar acesso ao campo de dados (CAN_MCR-bit 8 = 1) */ CAN_MCR |= 0x0100; /* prepara mailbox #5 para transmissão */

  • CANMSGIDH[5]= (MB5_ID_STD<<2);
  • CANMSGIDL[5]= MB5_ID_EXTL;
  • CANMSGCTRL[5]=0x0001; /* Bit 4 : RTR = 0 : data frame 3-0 DLC = 0001 = 1 Byte */
  • CANDATA0[5] = mess; /* dado para ser transmitido */ /* habilita acesso campo de dados (CAN_MCR bit 8 = 0) */ CAN_MCR &= 0xFEFF ; /*CAN_IFR=0x2100;*/ CAN_MDER |= 0x0021; /* enable mailbox#5 */ CAN_IMR = 0x0000; /* enable mailbox#5 interrupt */

  }

/*********************************************************************/

/********************** RECEPđấO ***********************************/

/*********************************************************************/

void can_receive(void) { while((CAN_RCR & 0x0010) ==0);

  /* espera por recepção de mensagens pendentes */ /* mailbox #0 : Bit 4 = 1 */ dado0= *CANDATA0[0]; } /*********************************************************************/ /********************** Leitura Entrada Analógica********************/ /*********************************************************************/ void leitura(void)

  {

  • ADCTRL1 = 0x4000; /* Reseta o adc */
  • ADCTRL1 = 0x0010;

    /* Tira do reset e coloca no modo cascata de 16 estados de seqüência (SEQ1)

  • /
  • MAX_CONV = 0x0000;/* Habilita sequência para apenas um canal */
  • CHSELSEQ1 = 0x0000; /* Seleciona o canal 0 (ADCIN00) para a conversão */>ADCTRL2 = 0x4000; /* Reseta a sequência de conversão */
  • ADCTRL2 = 0x2000; /* Inicia a conversão */ asm(" NOP"); asm(" NOP"); asm(" NOP"); asm(" NOP"); while((*ADCTRL2 & 0x1000) == 4096) /* Faz, enquanto a seqüência de conversão não estiver concluída */ /* quando concluído bit12 vai para 1 */ DADO = *RESULT0; /* Armazena os 10bits resultantes da conversão do canal 0 em uma variá
  • /
  • PEDATDIR =(DADO >> 6); /* Shift DADO 6 vezes, porque o resultado da conversão esta nos */ /* bits mais significativos (15-6), e deseja-se que eles fiquem */ /* nos menos significativos (9-0); */ } }

  /*********************************************************************/ /********************** INTERRUPđấO ********************************/ /*********************************************************************/ void c_dummy1(void)

  { while(1); /*tratamento do ISR utilizada para o caso de interrupções não esperadas*/ } unsigned int j; if(PIVR == 0x0041) { /* ROTINA DE IDENTIFICAđấO DE ERRO */ } if((PIVR == 0x0040) && (CAN_RCR & 0x0010))

  { can_receive(); }

  IFR=0x00ff; CAN_RCR |= 0x0010; } /*********************************************************************/ /********************** PRINCIPAL ***********************************/ /*********************************************************************/ void main(void)

  { unsigned int j; unsigned int i,k; asm (" setc INTM"); /*Desabilita todas as interrupções */ asm (" clrc SXM"); /*Apaga bit SXM */ asm (" clrc OVM"); /*Reseta bit OVM */ asm (" clrc CNF"); /*Configura bloco B0 como memória de dados */ WDCR=((WDDIS<<6)+(WDCHK2<<5)+(WDCHK1<<4)+(WDCHK0<<3)+WDSP);

  /* Inicializa timer Watchdog */ SCSR1= ((CLKSRC<<14)+(LPM<<12)+(CLK_PS<<9)+(ADC_CLKEN<<7)+ (SCI_CLKEN<<6)+(SPI_CLKEN<<5)+(CAN_CLKEN<<4)+ (EVB_CLKEN<<3)+(EVA_CLKEN<<2)+ILLADR);

  

WSGR = ((BVIS<<9)+(ISWS<<6)+(DSWS<<3)+PSWS);/*Ajusta waitstates */

MCRB = ((MCRB9<<9)+(MCRB8<<8)+ (MCRB7<<7)+(MCRB6<<6)+(MCRB5<<5)+(MCRB4<<4)+ (MCRB3<<3)+(MCRB2<<2)+(MCRB1<<1)+MCRB0); /* Inicializa MCRB (Master Control Register B ) */ MCRA = ((MCRA15<<15)+(MCRA14<<14)+(MCRA13<<13)+(MCRA12<<12)+

  (MCRA11<<11)+(MCRA10<<10)+(MCRA9<<9)+(MCRA8<<8)+ (MCRA7<<7)+(MCRA6<<6)+(MCRA5<<5)+(MCRA4<<4)+ (MCRA3<<3)+(MCRA2<<2)+(MCRA1<<1)+MCRA0); /* Inicializa MCRA (Master Control Register A ) */ MCRC = ((MCRC13<<13)+(MCRC12<<12)+(MCRC11<<11)+(MCRC10<<10)

  • (MCRC9<<9)+(MCRC8<<8)+(MCRC7<<7)+(MCRC6<<6)
  • (MCRC5<<5)+(MCRC4<<4)+(MCRC3<<3)+(MCRC2<<2)
  • (MCRC1<<1)+MCRC0); /* Inicializa MCRB (Master Control Register B ) */
can_init(); /* Inicializa a rede CAN */

  IMR=0x0001; asm (" clrc INTM"); /* Habilita todas as interrupções mascaradas*/ PEDATDIR=0xFF00; /* apaga os LED's */ k=1; while(1) {

  MB5_ID_STD=0x0788; mensagem=0; can_mailbox5(mensagem); can_transmit5(); } /* while */ } /* main */

  APÊNDICE C

  Na seqüência são apresentados os programas desenvolvidos para implementar os algoritmos propostos do capítulo 5.

  C.1. Nó 1

/**********************************************************************/

/* Programa para Nó 1 - Sensores */ /* */

/**********************************************************************/

#include "regs2407.h" /************* Definição das Entradas *************************/ /****************** MCRA **********************************/ #define MCRA15 0 /* 0 : IOPB7 1 : TCLKIN */ #define MCRA14 0 /* 0 : IOPB6 1 : TDIR */ #define MCRA13 0 /* 0 : IOPB5 1 : T2PWM */ #define MCRA12 0 /* 0 : IOPB4 1 : T1PWM */ #define MCRA11 0 /* 0 : IOPB3 1 : PWM6 */ #define MCRA10 0 /* 0 : IOPB2 1 : PWM5 */ #define MCRA9 0 /* 0 : IOPB1 1 : PWM4 */ #define MCRA8 0 /* 0 : IOPB0 1 : PWM3 */ #define MCRA7 0 /* 0 : IOPA7 1 : PWM2 */ #define MCRA6 0 /* 0 : IOPA6 1 : PWM1 */ #define MCRA5 0 /* 0 : IOPA5 1 : CAP3 */ #define MCRA4 0 /* 0 : IOPA4 1 : CAP2/QEP2 */ #define MCRA3 0 /* 0 : IOPA3 1 : CAP1/QEP1 */ #define MCRA2 0 /* 0 : IOPA2 1 : XINT1 */ #define MCRA1 0 /* 0 : IOPA1 1 : SCIRXD */ #define MCRA0 0 /* 0 : IOPA0 1 : SCITXD */ /****************** MCRB **********************************/ #define MCRB9 0 /* 0 : IOPD1 1 : XINT2/EXTSOC */ #define MCRB8 1 /* 0 : CKLKOUT 1 : IOPD0 */ #define MCRB7 1 /* 0 : IOPC7 1 : CANRX */ #define MCRB6 1 /* 0 : IOPC6 1 : CANTX */ #define MCRB5 0 /* 0 : IOPC5 1 : SPISTE */ #define MCRB4 0 /* 0 : IOPC4 1 : SPICLK */ #define MCRB3 0 /* 0 : IOPC3 1 : SPISOMI */ #define MCRB2 0 /* 0 : IOPC2 1 : SPISIMO */ #define MCRB1 1 /* 0 : BIO 1 : IOPC1 */ #define MCRB0 1 /* 0 : XF 1 : IOPC0 */ /****************** MCRC ************************************/

  #define MCRC9 0 /* 0 : IOPF1 1 : CAP6 */ #define MCRC8 0 /* 0 : IOPF0 1 : CAP5/QEP3 */ #define MCRC7 0 /* 0 : IOPE7 1 : CAP4/QEP2 */ #define MCRC6 0 /* 0 : IOPE6 1 : PWM12 */ #define MCRC5 0 /* 0 : IOPE5 1 : PWM11 */ #define MCRC4 0 /* 0 : IOPE4 1 : PWM10 */ #define MCRC3 0 /* 0 : IOPE3 1 : PWM9 */ #define MCRC2 0 /* 0 : IOPE2 1 : PWM8 */ #define MCRC1 0 /* 0 : IOPE1 1 : PWM7 */ #define MCRC0 0 /* 0 : IOPE0 1 : CLKOUT */ /****************************************************************/ /*************** Programação do Watchdog - WDCR ****************/ #define WDDIS 1 /* 0 : Watchdog Habilitado 1: Desabilitado */ #define WDCHK2 1 /* 0 : Reset 1: Normal */ #define WDCHK1 0 /* 0 : Normal 1: Reset */ #define WDCHK0 1 /* 0 : Reset 1: Normal */ #define WDSP 7 /* Escala do Watchdog 7 : dividido por 64 */ /****************************************************************/ /**************** Programação do SCSR1 **************************/ #define CLKSRC 0 /* 0 : Interno (20MHz) */ #define LPM 0 /* 0 :Modo de operação 0 se for para idle */ #define CLK_PS 3 /* 001 : PLL multiplicar por 2 */ #define ADC_CLKEN 0 /* 0 : Sem ADC */ #define SCI_CLKEN 0 /* 0 : Sem SCI */ #define SPI_CLKEN 0 /* 0 : Sem SPI */ #define CAN_CLKEN 1 /* 0 : Com CAN */ #define EVB_CLKEN 0 /* 0 : Sem EVB */ #define EVA_CLKEN 0 /* 1 : Sem EVA */ #define ILLADR 1 /* 1 : Clear ILLADR durante inicialização */ /****************************************************************/ /**************** Programação de Estados de Espera - WSGR ******/ #define BVIS 0 /* 10-9 : 00 Barramento OFF */ #define ISWS 0 /* 8 -6 : 000 0 Waitstates para IO */ #define DSWS 0 /* 5 -3 : 000 0 Waitstates para dados */ #define PSWS 0 /* 2 -0 : 000 0 Waitstates códigos */ /****************************************************************/ /****************** Programação do IMR ********************/ #define INT6 0 /* 5 : Level INT6 mascarada */ #define INT5 0 /* 4 : Level INT5 mascarada */ #define INT4 0 /* 3 : Level INT4 mascarada */ #define INT3 0 /* 2 : Level INT3 mascarada */ #define INT2 0 /* 1 : Level INT2 mascarada */ #define INT1 1 /* 0 : Level INT1 mascarada */

/**************************************************************************

  • /

    /*********** Programação do Registrador MCR ( CAN Master Control)*********/

    #define CAN_SUSP 0 /* 13 : Modo Soft : Para a CAN quando transmissão estiver*/ #define CAN_CCR 1 /* 12 : Acesso para configuração de registrador */

  #define CAN_WUBA 0 /* 9 : Acorda do modo power down após escrever 0 em PDR */ #define CAN_CDR 0 /* 8 : não foi solicitado mudança no campo de dados /

#define CAN_ABO 0 /* 7 : após entrar em modo "bus off" retornas reset */

#define CAN_STM 0 /* 6 : não utiliza modo de auto-teste */ #define CAN_MBNR 0 /* 1-0: Número do Mailbox */

/*************************************************************************/

/******* Programação do BCRn ( Bit Configuration Register - CA_BCAN_BCR1)*/

#define CAN_BRP 14 /* Baud rate */

#define CAN_SBG 1 /* Sincronismo da rede CAN em as de subida e descida */

#define CAN_SJW 2 /* Syncronismo com jump */ #define CAN_SAM 0 /* Faz somente uma amostragem por bit */ #define CAN_TSEG1 10 /* Time Segment 1 */ #define CAN_TSEG2 7 /* Time Segment 2 */

/*************************************************************************/

/****** Programação do MDER (Mailbox Direction/Enable ) */ #define CAN_MD 0 /* 7-6 :00 mailbox 2 and 3 são transmissores*/ #define CAN_ME 0 /* 5-0 : mailbox 0 to 5 desabilitado */

/************************************************************************/

/****** SETUP for the CAN MAILBOX # 5 ( transmit) */ #define MB5_IDE 0 /* 11-bit identificadores */ #define MB5_AME 0 /* mascara local habilitada */ #define MB5_AAM 0 /* não responde solicitação remota */ #define MB5_ID_EXTL 0x0000 /* extended identifier bits 15-0 */

/*************************************************************************/

/****** Programação do MAILBOX # 0 ( Receptor) */ #define MB0_IDE 0 /* somente 11-bit de identificadores */

#define MB0_AME 1 /* a máscara local de aceitação está habilitada */

#define MB0_AAM 0 /* não responde a solicitação de mensagem remota */ #define MB0_ID_STD 0x0160 /* Identificador de recepção padrão */ #define MB0_ID_EXTL 0x0000 /* Identificador estendido */ #define MB0_LAMI 1 /* Frames identificadores padrão e estendido são recebidos */ #define MB0_LAMH 0x0FFF /*filtro aplicado nos identificadores ID 11-0 */ #define MB0_LAML 0xFFFF /* máscara inferior não utilizada */ /****************************************************************/ /* Declaração de funções */ /****************************************************************/ void can_receive(void); void can_init(void); void c_dummy1(void); interrupt void c_recep(void); /****************************************************************/ /* Definição de Variáveis Gloabais */ /****************************************************************/

  

unsigned int *CANMSGIDH[6]; /*Identificador de mensagem-bits mais sig */

unsigned int *CANMSGCTRL[6]; /* Controle da mensagem */ unsigned int *CANDATA0[6]; /* Byte de dados 0 das mensagems */ unsigned int sel=0,m,n,mensagem,id=0; unsigned int sensores=0; unsigned int modo=0; unsigned int MB5_ID_STD=0; unsigned int dado0; void can_init(void) { unsigned int i; for (i=0;i<6;i++){ /* programacão dos ponteiros para as mailboxes */

  CANMSGIDL[i] = (unsigned int *)(0x7200 +i*8); CANMSGIDH[i] = (unsigned int *)(0x7201 +i*8); CANMSGCTRL[i] = (unsigned int *)(0x7202 +i*8); CANDATA0[i] = (unsigned int *)(0x7204 +i*8); } /* Inicialização do registrador MCR (Master Control Registers) */

  CAN_MCR |= ((CAN_SUSP<<13)+(CAN_CCR<<12)+(CAN_PDR<<11)+ (CAN_DBO<<10)+(CAN_WUBA<<9)+(CAN_CDR<<8)+ (CAN_ABO<<7)+(CAN_STM<<6)+ CAN_MBNR ); /* Espera para confirmação da habilitação de CCR */ while((CAN_GSR & 0x0010) == 0 ); /* Inicialização de BCR2 e BCR1 */ CAN_BCR2 = CAN_BRP; CAN_BCR1 = ((CAN_SBG<<10)+(CAN_SJW<<8)+(CAN_SAM<<7)+

  (CAN_TSEG1<<3)+(CAN_TSEG2)); CAN_MCR &= 0xEFFF; /* apaga CCR */ /* Espera até que o bit CCE do registrador GSR for setado */ while((CAN_GSR & 0x0010) != 0 ); /*

  /* prepara máscara de aceitação local para mailbox 0 */ CAN_LAM0_H = ((MB0_LAMI<<15)+(MB0_LAMH<<2)); CAN_LAM0_L = MB0_LAML; /* desabilita todas as mailboxes */ CAN_MDER = ((CAN_MD<<6)+CAN_ME); /* habilita o aceso ao campo de dados (MCR-bit 8 = 1) */ CAN_MCR |= 0x0100; /* prepara mailbox 0 para receber os frames de mensagem */

  • CANMSGIDH[0]= (MB0_ID_STD<<2);

  CAN_MCR &= 0xFEFF ; CAN_IFR=0x0100; /* habilita o mailbox #0 como receptor */ CAN_RCR |= 0x0010;

  IFR=0x00ff; CAN_MDER = 0x0001; CAN_IMR = 0x0100;

  IMR=0x0001; }

/*********************************************************************/

/********************** TRANSMISSÃO ********************************/

/*********************************************************************/

void can_transmit5(void) { unsigned int l;

  IMR=0x0000; m=m+1; CAN_TCR = 0x0080; /* transmit request set (TRS)mailbox#5 */ while((CAN_TCR & 0x8000) ==0); /* wait for transmit ACK */

  /* mailbox #5 : Bit 15 = 1 */ CAN_TCR |= 0x8000; /* Reset TA and interrupt flag */ PEDATDIR = 0xFFAA;

  IFR=0x00ff; CAN_MDER = 0x0001; CAN_IMR = 0x0100;

  IMR=0x0001; } void can_mailbox5(unsigned int mess) { unsigned int l;

  /* habilitar acesso ao campo de dados (CAN_MCR-bit 8 = 1) */ CAN_MCR |= 0x0100; /* prepara mailbox #5 para transmissão */

  • CANMSGIDH[5]= (MB5_ID_STD<<2);
  • CANMSGIDL[5]= MB5_ID_EXTL;
  • CANMSGCTRL[5]=0x0001; /* Bit 4 : RTR = 0 : data frame 3-0 DLC = 0001 = 1 Byte */
  • CANDATA0[5] = mess; /* dado para ser transmitido */ /* habilita acesso campo de dados (CAN_MCR bit 8 = 0) */ CAN_MCR &= 0xFEFF ; /*CAN_IFR=0x2100;*/ CAN_MDER |= 0x0021; /* enable mailbox#5 */ CAN_IMR = 0x0000; /* enable mailbox#5 interrupt */

  for (l=0;l<65000;l++); }

/*********************************************************************/

/********************** RECEPđấO ***********************************/

/*********************************************************************/

  /* espera por recepção de mensagens pendentes */ /* mailbox #0 : Bit 4 = 1 */ while((CAN_IFR &= 0x0100)==0); /* espera por MIF0= 1 */ CAN_RCR |= 0x0010; /* Reseta RA e o flag de interrupcão*/ id= *CANMSGIDH[0]>>2; dado0= *CANDATA0[0];

  } void c_dummy1(void)

  { while(1);

/* tratamento do ISR utilizada para o caso de interrupções não esperadas */

} interrupt void c_recep(void) { unsigned int j; if(PIVR == 0x0041) {

  /* ROTINA DE IDENTIFICAđấO DE ERRO */ } if((PIVR == 0x0040) && (CAN_RCR & 0x0010)) { can_receive(); switch(id) { case 0x0004: modo=0; break; case 0x0042: modo =0; break; case 0x0140: modo =1; break; case 0x03C0: modo =2; break; case 0x0500: sel =2; break; case 0x0780: sel =1; break; } /* fim switch */

  }

  IFR=0x00ff; CAN_RCR |= 0x0010;

  void main(void) { unsigned int j; unsigned int i,k;

asm (" setc INTM"); /*Desabilita todas as interrupções */

asm (" clrc SXM"); /*Apaga bit SXM */ asm (" clrc OVM"); /*Reseta bit OVM */

asm (" clrc CNF"); /*Configura bloco B0 como memória de dados */

WDCR=((WDDIS<<6)+(WDCHK2<<5)+(WDCHK1<<4)+(WDCHK0<<3)+WDSP);

  /* Inicializa timer Watchdog */ SCSR1= ((CLKSRC<<14)+(LPM<<12)+(CLK_PS<<9)+(ADC_CLKEN<<7)+ (SCI_CLKEN<<6)+(SPI_CLKEN<<5)+(CAN_CLKEN<<4)+ (EVB_CLKEN<<3)+(EVA_CLKEN<<2)+ILLADR);

  

WSGR = ((BVIS<<9)+(ISWS<<6)+(DSWS<<3)+PSWS); /* Ajusta waitstates */

MCRB = ((MCRB9<<9)+(MCRB8<<8)+ (MCRB7<<7)+(MCRB6<<6)+(MCRB5<<5)+(MCRB4<<4)+ (MCRB3<<3)+(MCRB2<<2)+(MCRB1<<1)+MCRB0); /* Inicializa MCRB (Master Control Register B ) */ MCRA = ((MCRA15<<15)+(MCRA14<<14)+(MCRA13<<13)+(MCRA12<<12)+

  (MCRA11<<11)+(MCRA10<<10)+(MCRA9<<9)+(MCRA8<<8)+ (MCRA7<<7)+(MCRA6<<6)+(MCRA5<<5)+(MCRA4<<4)+ (MCRA3<<3)+(MCRA2<<2)+(MCRA1<<1)+MCRA0); /* Inicializa MCRA (Master Control Register A ) */ MCRC = ((MCRC13<<13)+(MCRC12<<12)+(MCRC11<<11)+(MCRC10<<10)

  • (MCRC9<<9)+(MCRC8<<8)+(MCRC7<<7)+(MCRC6<<6)
  • (MCRC5<<5)+(MCRC4<<4)+(MCRC3<<3)+(MCRC2<<2)
  • (MCRC1<<1)+MCRC0); /* Inicializa MCRB (Master Control Register B ) */

  IFR=0xFFFF; /* Reseta todas as interrupções */ can_init(); /* Inicializa a rede CAN */

  IMR=0x0001; asm (" clrc INTM"); /* Habilita todas as interrupções mascaradas

  • / PEDATDIR=0xFF00; /* apaga os LED's */ k=1; while(1) { if ( sel == 1) {
can_mailbox5(mensagem); can_transmit5(); sel=0; } else if ( sel==2) {

  MB5_ID_STD=0x0100; mensagem=sensores; can_mailbox5(mensagem); can_transmit5(); sel=0; } if((modo==1) || (modo==2)) { /* TESTE QUANDO OPERA EM MODO 1 OU 2 */ if((PADATDIR & 0x00FF)!= sensores) { /* houve alteração do sinal das chaves ? */ if((PADATDIR & 0x00FF)==0)

  { MB5_ID_STD=0x0640; /* A ENTRADA RETORNOU PARA ZERO */ mensagem=0; can_mailbox5(mensagem); can_transmit5(); } else if ( sensores == 0) {

  MB5_ID_STD=0x0160; mensagem = (PADATDIR&0x00FF); /* ENVIA ESTADO DOS SENSORES */ can_mailbox5(mensagem); can_transmit5(); }

  } /* IF - TESTE DE ALTERAđấO DE ESTADO */ }/* IF TESTE DO MODO */ sensores=PADATDIR & 0x00FF; } /* while */ } /* main */

Novo documento

Tags

Documento similar

UNIVERSIDADE DO ESTADO DE SANTA CATARINA – UDESC CENTRO DE CIÊNCIAS TECNOLÓGICAS – CCT DEPARTAMENTO DE ENGENHARIA ELÉTRICA – DEE MESTRADO EM ENGENHARIA ELÉTRICA SUZANA RIBAS DE ALMEIDA
0
1
116
UNIVERSIDADE DO ESTADO DE SANTA CATARINA – UDESC CENTRO DE CIÊNCIAS TECNOLÓGIAS – CCT DEPARTAMENTO DE ENGENHARIA ELÉTRICA – DEE PROGRAMA DE PÓS-GRADUAÇÃO EM ENGENHARIA ELÉTRICA – PPGEEL
0
0
137
UNIVERSIDADE DO ESTADO DE SANTA CATARINA – UDESC CENTRO DE CIÊNCIAS TECNOLÓGICAS – CCT DEPARTAMENTO DE ENGENHARIA ELÉTRICA – DEE PROGRAMA DE PÓS-GRADUAÇÃO EM ENGENHARIA ELÉTRICA
1
2
140
UNIVERSIDADE DO ESTADO DE SANTA CATARINA – UDESC CENTRO DE CIÊNCIAS TECNOLÓGICAS – CCT DEPARTAMENTO DE ENGENHARIA ELÉTRICA – DEE PROGRAMA DE PÓS-GRADUAÇÃO EM ENGENHARIA ELÉTRICA - PPGEEL
0
1
133
UNIVERSIDADE DO ESTADO DE SANTA CATARINA – UDESC CENTRO DE CIÊNCIAS TECNOLÓGICAS – CCT DEPARTAMENTO DE ENGENHARIA ELÉTRICA – DEE PROGRAMA DE PÓS-GRADUAÇÃO EM ENGENHARIA ELÉTRICA - PPGEEL
0
0
65
UNIVERSIDADE DO ESTADO DE SANTA CATARINA – UDESC CENTRO DE CIÊNCIAS TECNOLÓGICAS – CCT DEPARTAMENTO DE ENGENHARIA ELÉTRICA - DEE PROGRAMA DE PÓS-GRADUAÇÃO EM ENGENHARIA ELÉTRICA - PPGEEL
0
0
160
UNIVERSIDADE DO ESTADO DE SANTA CATARINA – UDESC CENTRO DE CIÊNCIAS TECNOLÓGICAS – CCT DEPARTAMENTO DE ENGENHARIA ELÉTRICA – DEE PROGRAMA DE PÓS-GRADUAÇÃO EM ENGENHARIA ELÉTRICA
0
1
302
UNIVERSIDADE DO ESTADO DE SANTA CATARINA – UDESC CENTRO DE CIÊNCIAS TECNOLÓGICAS – CCT PROGRAMA DE PÓS-GRADUAÇÃO EM ENGENHARIA ELÉTRICA – PPGEEL MESTRADO PROFISSIONAL EM ENGENHARIA ELÉTRICA
0
1
113
UNIVERSIDADE DO ESTADO DE SANTA CATARINA – UDESC CENTRO DE CIÊNCIAS TECNOLÓGICAS – CCT DEPARTAMENTO DE ENGENHARIA ELÉTRICA – DEE COORDENAÇÃO DO PROGRAMA DE PÓS-GRADUAÇÃO EM ENGENHARIA ELÉTRICA – PPGEEL Formação: Mestrado Profissional em Engenharia Elétric
0
0
147
UNIVERSIDADE DO ESTADO DE SANTA CATARINA – UDESC CENTRO DE CIÊNCIAS TECNOLÓGICAS – CCT DEPARTAMENTO DE ENGENHARIA ELÉTRICA – DEE PROGRAMA DE PÓS-GRADUAÇÃO EM ENGENHARIA ELÉTRICA - PPGEEL
0
0
156
UNIVERSIDADE DO ESTADO DE SANTA CATARINA – UDESC CENTRO DE CIÊNCIAS TECNOLÓGICAS – CCT DEPARTAMENTO DE ENGENHARIA ELÉTRICA – DEE PROGRAMA DE PÓS-GRADUAÇÃO EM ENGENHARIA ELÉTRICA - PPGEEL HORÁCIO BECKERT POLLI
0
1
111
UNIVERSIDADE DO ESTADO DE SANTA CATARINA – UDESC CENTRO DE CIÊNCIAS TECNOLÓGICAS – CCT CURSO DE ENGENHARIA ELÉTRICA
0
0
146
UNIVERSIDADE DO ESTADO DE SANTA CATARINA – UDESC CENTRO DE CIÊNCIAS TECNOLÓGICAS – CCT DEPARTAMENTO DE ENGENHARIA ELÉTRICA – DEE PROGRAMA DE PÓS-GRADUAÇÃO EM ENGENHARIA ELÉTRICA - PPGEE
0
1
190
UNIVERSIDADE DO ESTADO DE SANTA CATARINA – UDESC CENTRO DE CIÊNCIAS TECNOLÓGICAS – CCT DEPARTAMENTO DE ENGENHARIA ELÉTRICA – DEE MESTRADO PROFISSIONAL EM ENGENHARIA ELÉTRICA
0
0
152
UNIVERSIDADE DO ESTADO DE SANTA CATARINA – UDESC CENTRO DE CIÊNCIAS TECNOLÓGICAS – CCT DEPARTAMENTO DE ENGENHARIA ELÉTRICA – DEE MESTRADO EM ENGENHARIA ELÉTRICA DIOGO LUIZ LEMES DA CRUZ
0
0
101
Show more