Projecto e Construção de um Sistema Embebido de Tempo-Real ...

Departamento

de Engenharia Electrotécnica

PPrroojjeeccttoo ee CCoonnssttrruuççããoo ddee uumm SSiisstteemmaa EEmmbbeebbiiddoo ddee

TTeemmppoo--RReeaall BBaasseeaaddoo eemm LLiinnuuxx

Trabalho de Projecto apresentado para a obtenção do grau de Mestre em

Automação e Comunicações em Sistemas de Energia

Autor

Adriano José Ribeiro Campos

Orientadores

Doutor Inácio Fonseca

Doutor Fernando Lopes

Instituto Superior de Engenharia de Coimbra

Coimbra, Dezembro 2011

Projecto e Construção de um Sistema Embebido de Tempo-Real Baseado em Linux AGRADECIMENTOS

Adriano José Ribeiro Campos i

AGRADECIMENTOS

A realização deste trabalho de projecto não seria exequível apenas com o meu esforço individual. Os resultados obtidos foram possíveis com o apoio de diversas pessoas e instituições e por isso gostaria de deixar aqui os meus agradecimentos às mesmas. Aos meus pais e aos meus irmãos pela paciência, apoio, encorajamento e confiança depositada em mim. Agradeço ainda aos meus pais pelo esforço que fizeram para que eu me tornasse um Engenheiro de Electrónica. Aos meus orientadores, Doutor Inácio Fonseca e Doutor Fernando Lopes, pelo apoio dado durante a realização do projecto e especialmente na escrita deste documento. Agradeço ainda por me terem dado a oportunidade de realizar este projecto que faz uso de conceitos e tecnologias de extrema actualidade, interesse e aplicabilidade. Ao Instituto Superior de Engenharia de Coimbra e aos seus funcionários pela infra-estrutura oferecida, e pela oportunidade de estudar numa das melhores instituições de ensino superior de Portugal. A todas as comunidades de software livre, especialmente às comunidades associadas aos projectos referidos neste trabalho, por toda a documentação e apoio personalizado que disponibilizam gratuitamente. Por fim, aos meus colegas que me apoiaram e acompanharam durante todas as etapas da minha formação académica e que, com certeza, não chegaria até aqui sem eles. Como é óbvio, não me esqueço também dos meus amigos que estiveram ao meu lado durante este percurso. A todos MUITO OBRIGADO

Projecto e Construção de um Sistema Embebido de Tempo-Real Baseado em Linux RESUMO

Adriano José Ribeiro Campos iii

RESUMO

Os sistemas embebidos são equipamentos electrónicos que incluem processamento de informação, normalmente desenvolvidos para uma aplicação específica. Estes dispositivos encontram-se presentes em praticamente todas as áreas da electrónica, desde os smartphones até aos equipamentos de automação industrial. Os sistemas embebidos podem ser projectados sobre diversas plataformas de hardware e firmware. Relativamente ao hardware, os sistemas embebidos podem ser implementados com diversas arquitecturas. Neste projecto optou-se pela utilização da arquitectura de 32 bits mais popular, a arquitectura ARM. Esta escolha deve-se ao bom desempenho e baixo consumo. O software pode ser especifico para a aplicação ou ser um sistema operativo genérico. Este projecto demonstra que a solução GNU/Linux é uma alternativa viável e segura para um sistema embebido. A utilização é gratuita e oferece facilidade de personalização para diversas plataformas de hardware. A par do desenvolvimento dos sistemas embebidos, os sistemas operativos de tempo-real apresentam actualmente um desenvolvimento muito forte, sendo uma característica ímpar para os sistemas embebidos. A característica de tempo-real permite construir sistemas com garantias temporais bem definidas, requisito importante em muitas das aplicações industriais. O kernel Linux não permite por si só construir um sistema de tempo-real, no entanto, encontram-se disponíveis vários pacotes de software, que permitem transformar um sistema GNU/Linux de forma a incluir características de tempo-real. As extensões seleccionadas neste projecto para este efeito foram as desenvolvidas pelos projectos Xenomai e ADEOS. No desenvolvimento de sistemas embebidos a emulação de hardware é actualmente uma técnica muito útil e prática, permitindo desenvolver, validar e trabalhar com o sistema, antes de este ser fisicamente implementado. Este projecto tem por objectivo o estudo e implementação de tecnologias emergentes associadas ao desenvolvimento de sistemas embebidos. Pretende-se projectar e desenvolver uma solução integrada que inclua características de tempo-real para aplicações de automação industrial. O projecto elaborado inclui todas a as etapas necessárias, desde a pesquisa e especificação até à validação e simulação, passando pelo projecto dos circuitos electrónicos, desenho do hardware e desenvolvimento do software.

Palavras-chave: Sistemas Industriais, Sistemas Embebidos, GNU, Linux, RTOS, ARM, Xenomai,

ADEOS, QEMU.

Projecto e Construção de um Sistema Embebido de Tempo-Real Baseado em Linux ABSTRACT

Adriano José Ribeiro Campos v

ABSTRACT

Embedded Systems are electronic devices that include information processing and are usually developed for a specific application. These devices are present in all electronics areas, fromsmartphones to industrial automation equipment. Embedded systems can be developed on different hardware and firmware platforms. Regarding the hardware, embedded systems can be implemented with different architectures. In this project we chose to use the most popular 32-bit architecture, the ARM architecture. This is mainly due to its good performance and low power consumption. The software can be specific to the application or based on a general purpose operating system. This project demonstrates that the GNU/Linux solution is a viable and safe alternative for an embedded system. It is free and offers easy customization for different hardware platforms. Alongside the development of embedded systems, real-time operating systems are currently under strong development, representing a unique feature for embedded systems. The characteristic of real-time allows building systems with well defined temporal guarantees, an important requirement in many industrial applications. The Linux kernel does not allow by itself to build a real-time system, however, there are several software packages available that can be used to transform a GNU / Linux system in order to include real-time characteristics. Extensions selected for this purpose in this project were developed by the ADEOS and Xenomai projects. In the development of embedded systems, the hardware emulation is now a very useful technique and practice, allowing developing, validating and working with the system before it is physically implemented. This project aims at studying and implementing emerging technologies associated with the development of embedded systems. It is intended to design and develop an integrated solution that includes features for real-time industrial automation applications. The presented project includes all the necessary steps, from research and specification to the validation and simulation, passing through the design of electronic circuits, hardware design and software development.

Keywords: Industrial Systems, Embedded Systems, GNU, Linux, RTOS, ARM, Xenomai,

ADEOS, QEMU.

Projecto e Construção de um Sistema Embebido de Tempo-Real Baseado em Linux ÍNDICE

Adriano José Ribeiro Campos vii

ÍNDICE

AGRADECIMENTOS ...................................................................................................... i

RESUMO .......................................................................................................................... iii

ABSTRACT ...................................................................................................................... v

LISTA DE FIGURAS ..................................................................................................... xi

SIMBOLOGIA ............................................................................................................... xv

ABREVIATURAS ........................................................................................................ xvii

1 INTRODUÇÃO ........................................................................................................ 1

1.1 Motivações ...................................................................................................................................... 1

1.2 Objectivos ........................................................................................................................................ 2

1.3 Organização do documento ............................................................................................................. 2

1.4 Considerações linguísticas ............................................................................................................... 3

2 ESTADO DA ARTE ................................................................................................. 5

2.1 Arquitectura ARM ............................................................................................................................ 5

2.1.1 Evolução histórica .................................................................................................................. 6

2.1.2 Diversas soluções da arquitectura ARM ................................................................................. 7

2.1.3 Mercado da tecnologia ARM .................................................................................................. 8

2.1.4 Principais características técnicas .......................................................................................... 9

2.1.5 Resumo das vantagens de usar ARM .................................................................................... 10

2.2 Sistemas embebidos ....................................................................................................................... 10

2.2.1 Desenvolvimento de um sistema embebido ......................................................................... 12

2.3 Soluções GNU/Linux ..................................................................................................................... 13

2.3.1 Vantagens e desvantagens das soluções baseadas em GNU/Linux ...................................... 13


viii

2.3.2 GNU/Linux em sistemas embebidos ..................................................................................... 13

2.4 Sistemas operativos de tempo-real (RTOS) .................................................................................... 14

2.4.1 Sistemas operativos de tempo-real baseados em Linux ........................................................ 15

2.5 Norma IEEE 1588 .......................................................................................................................... 16

2.6 Barramentos industriais ................................................................................................................. 17

2.6.1 Barramento CAN .................................................................................................................. 17

2.6.2 Norma RS485 ....................................................................................................................... 18

2.6.3 Barramento USB ................................................................................................................... 19

2.7 Conclusões ..................................................................................................................................... 20

3 DESENVOLVIMENTO DA PLATAFORMA DE HARDWARE ..................... 21

3.1 Desenho de circuitos impressos ..................................................................................................... 21

3.1.1 Interferências electromagnéticas .......................................................................................... 21

3.1.2 Descargas electrostáticas ...................................................................................................... 22

3.1.3 Desenho de placas de circuito impresso ............................................................................... 22

3.1.4 Debug de hardware .............................................................................................................. 23

3.2 Software de desenho de hardware (EDA) ...................................................................................... 23

3.2.1 Software “Altium Designer”................................................................................................. 24

3.2.2 Software “Altium Designer Viewer” .................................................................................... 25

3.3 Levantamento de requisitos ........................................................................................................... 25

3.4 Pesquisa de mercado ...................................................................................................................... 27

3.4.1 Soluções para integração ...................................................................................................... 27

3.4.2 Placas de desenvolvimento ................................................................................................... 30

3.5 Especificação ................................................................................................................................. 33

3.6 Arquitectura ................................................................................................................................... 33

3.6.1 Processamento ...................................................................................................................... 34

3.6.2 Memórias .............................................................................................................................. 37

3.6.3 IEEE1588 ............................................................................................................................. 38

3.6.4 Caixa .................................................................................................................................... 39

3.7 Desenvolvimento do módulo “MAIN BOARD” ............................................................................. 40

3.7.1 Fonte de alimentação ............................................................................................................ 40

3.7.2 Barramento ........................................................................................................................... 44

3.7.3 Entradas e saídas digitais com isolamento óptico ................................................................. 46

3.7.4 Cartão de memória ............................................................................................................... 47

3.7.5 Aspecto final da “MAIN BOARD”........................................................................................ 48


Adriano José Ribeiro Campos ix

3.8 Desenvolvimento do módulo “CPU BOARD” .............................................................................. 49

3.8.1 Microcontrolador AT91SAM9XE512 ................................................................................... 49

3.8.2 Sensor de temperatura .......................................................................................................... 55

3.8.3 Memórias ............................................................................................................................. 56

3.8.4 Ethernet segundo a norma IEEE1588 .................................................................................. 58

3.8.5 USB Host e USB Device ....................................................................................................... 59

3.8.6 Aspecto final da “CPU BOARD” ........................................................................................ 60

3.9 Produção das placas de circuito impresso ...................................................................................... 60

3.10 Especificações técnicas do equipamento .................................................................................. 63

3.11 Configurações do equipamento ................................................................................................. 64

3.12 Aspecto final do produto ........................................................................................................... 65

3.13 Conclusões ................................................................................................................................ 65

4 DESENVOLVIMENTO DA PLATAFORMA DE SOFTWARE ....................... 67

4.1 Conceitos de Virtualização ............................................................................................................ 67

4.2 Configuração do ambiente de trabalho .......................................................................................... 68

4.2.1 Virtual Box: Virtualização Nativa ........................................................................................ 68

4.2.2 QEMU: Emulador de hardware ........................................................................................... 69

4.3 Soluções baseadas em Linux4SAM ................................................................................................ 70

4.4 Desenvolvimento GNU/Linux para ARM ...................................................................................... 71

4.4.1 Toolchain ............................................................................................................................. 71

4.4.2 BuildRoot ............................................................................................................................. 72

4.4.3 RTOS para a plataforma desenvolvida ................................................................................. 77

4.4.4 Sistema operativo para a Plataforma versatilepb ................................................................. 78

4.4.5 Compilação cruzada de um programa .................................................................................. 79

4.5 Carga do sistema na plataforma desenvolvida ............................................................................... 80

4.5.1 Sequência de arranque do sistema ........................................................................................ 80

4.5.2 Bootloader Universal Das U-Boot ....................................................................................... 82

4.5.3 Ferramenta SAM-BA da ATMEL .......................................................................................... 83

4.6 Emulação de hardware com QEMU .............................................................................................. 85

4.6.1 Emular arquitectura x86 ....................................................................................................... 85

4.6.2 Emular arquitectura ARM ..................................................................................................... 86

4.6.3 Testar uma aplicação ARM. .................................................................................................. 89

4.7 Conclusões ..................................................................................................................................... 89


x

5 CONCLUSÕES ...................................................................................................... 91

5.1 Desenvolvimento de hardware ...................................................................................................... 91

5.1.1 Análise de custos do desenvolvimento do hardware ........................................................... 92

5.2 Desenvolvimento de firmware ....................................................................................................... 93

5.1 Conclusões gerais .......................................................................................................................... 94

5.2 Trabalho futuro .............................................................................................................................. 95

REFERÊNCIAS BIBLIOGRÁFICAS ......................................................................... 97

ANEXOS ....................................................................................................................... 101

Anexo 1. Esquema eléctrico "MAIN BOARD" ....................................................................................... 101

Anexo 2. Marcação dos componentes da placa "MAIN BOARD" .......................................................... 108

Anexo 3. Camada Top e Bottom da placa “MAIN BOARD” .................................................................. 109

Anexo 4. Lista detalhada de material da placa “MAIN BOARD” ......................................................... 110

Anexo 5. Esquema eléctrico da placa "CPU BOARD" .......................................................................... 113

Anexo 6. Marcação dos componentes da placa "CPU BOARD" ........................................................... 119

Anexo 7. Camada Top e Bottom da placa “MAIN BOARD” .................................................................. 120

Anexo 8. Camada interna 1 e 2 da placa “MAIN BOARD” .................................................................... 121

Anexo 9. Lista detalhada de material da placa “CPU BOARD” ............................................................ 122

Projecto e Construção de um Sistema Embebido de Tempo-Real Baseado em Linux LISTA DE FIGURAS

Adriano José Ribeiro Campos xi

LISTA DE FIGURAS

Figura 1 – Diferentes famílias da arquitectura ARM (ARM, 2011a). ............................................................. 8

Figura 2 - Evolução da utilização da arquitectura x86 e ARM (TECHSPOT, 2011). ..................................... 9

Figura 3 – Tendência do uso de sistemas operativos em sistemas embebidos. ............................................ 14

Figura 4 - Arquitectura de tempo-real implementada pelo projecto ADEOS. .............................................. 16

Figura 5 - Mensagem CAN. .......................................................................................................................... 18

Figura 6 - Tipos de conectores USB (Alecrim, E., 2011). ............................................................................ 19

Figura 7 - Ambiente integrado do software Altium Designer. ...................................................................... 25

Figura 8 – Esquema de uma plataforma modular em calha DIN. ................................................................. 26

Figura 9 - Módulo de integração "Micro2440". ........................................................................................... 27

Figura 10 - Módulo de integração "Netus G20". .......................................................................................... 28

Figura 11 - Módulo de integração " LPC-H3131". ....................................................................................... 28

Figura 12 - Módulo de integração "LPCEB2000-B". ................................................................................... 29

Figura 13 - Placa de desenvolvimento "909-CS-E9302". ............................................................................. 30

Figura 14 - Placa de desenvolvimento " Mini2440". .................................................................................... 30

Figura 15 - Placa de desenvolvimento " EB-SAM9G45". ............................................................................. 31

Figura 16 - Placa de desenvolvimento "EK_LM3S8962". ............................................................................ 31

Figura 17 - Diagrama do equipamento. ........................................................................................................ 34

Figura 18 – Módulos do microcontrolador SAM9XE da ATMEL. ................................................................ 35

Figura 19 - Família AT91SAM da ATMEL (Embest Info, 2011c). ................................................................ 35

Figura 20 – Gama de microcontroladores da série SAM9260/9XE da ATMEL (MSC, 2011). ..................... 36

Figura 21 - Diagrama de blocos da série AT91SAM9XE (MSC-GE, 2011). ................................................ 37

Figura 22 - Diagrama do driver físico para Ethernet DP83640. .................................................................. 39

Figura 23 - Caixa seleccionada para o equipamento. ................................................................................... 40

Figura 24 - Entrada de alimentação e protecções. ........................................................................................ 41

Figura 25 - Circuito da fonte comutada, saída 5 Volts. ................................................................................ 42

Figura 26 - Circuito do regulador linear, saída de 3.3Volts.......................................................................... 42

Figura 27 - Circuito do regulador linear, saída 1.8V e circuito da bateria de reserva (Backup). .................. 43

Figura 28 - Circuito do regulador bomba de carga, saída 1.8Volts. ............................................................. 43

Figura 29 - Circuito de controlo dos módulos de alimentação. .................................................................... 44

Figura 30 - Circuito do barramento. ............................................................................................................. 44

Figura 31 - Circuito para selecção do protocolo do barramento. .................................................................. 44

Figura 32 - Circuito da comunicação RS485. ............................................................................................... 45

Figura 33 - Circuito da comunicação RS232. ............................................................................................... 45

Figura 34 - Circuito da comunicação CAN. ................................................................................................. 46

Figura 35 - Circuito das entradas digitais com isolamento óptico. ............................................................... 47

Projecto e Construção de um Sistema Embebido de Tempo-Real Baseado em Linux LISTA DE FIGURAS

xii

Figura 36 - Circuito das saídas digitais com isolamento óptico. ................................................................... 47

Figura 37 - Circuito do cartão de memória. .................................................................................................. 48

Figura 38 - Aspecto Final da "MAIN BOARD". ............................................................................................ 48

Figura 39 - Circuito de alimentação do módulo conversor analógico – digital. ........................................... 50

Figura 40 - Circuito do oscilador principal. .................................................................................................. 51

Figura 41 - Circuito do oscilador secundário. ............................................................................................... 51

Figura 42 - Circuito para selecção do oscilador. ........................................................................................... 51

Figura 43 - Circuito do filtro PLL. ................................................................................................................ 52

Figura 44 - Circuito de reinício do microcontrolador. .................................................................................. 53

Figura 45 - Circuito de encerramento. .......................................................................................................... 53

Figura 46 - Circuito de inicialização. ............................................................................................................ 53

Figura 47 - Circuito JTAG. ........................................................................................................................... 54

Figura 48 - Circuito para apagar a memória FLASH. ................................................................................... 55

Figura 49 - Circuito do sensor de temperatura. ............................................................................................. 56

Figura 50 - Circuito da memória SDR SDRAM. ........................................................................................... 57

Figura 51 - Circuito da memória NAND FLASH. ......................................................................................... 57

Figura 52 - Circuito da Ethernet segundo a norma IEEE1588. .................................................................... 58

Figura 53 - Circuito do USB Host. ................................................................................................................ 59

Figura 54 - Circuito do USB Device. ............................................................................................................ 60

Figura 55 - Aspecto Final da "CPU BOARD". ............................................................................................. 60

Figura 56 - Aspecto final do produto sem caixa. .......................................................................................... 65

Figura 57 - Estrutura básica de virtualização de plataforma ......................................................................... 67

Figura 58 - Esquema do ambiente de trabalho .............................................................................................. 68

Figura 59 - Compilação cruzada para ARM (Free Electrons, 2010). ............................................................ 71

Figura 60 - Menu de configuração do Buildroot. .......................................................................................... 74

Figura 61 - Sequência de arranque da família AT91SAM9XXX. ................................................................... 82

Figura 62 - Software SAM-BA (ATMEL, 2010c). ........................................................................................ 84

Figura 63 - Janela Principal do software SAM-BA (ATMEL, 2010c). .......................................................... 84

Figura 64 -QEMU com ambiente gráfico ..................................................................................................... 88

Projecto e Construção de um Sistema Embebido de Tempo-Real Baseado em Linux LISTA DE TABELAS

Adriano José Ribeiro Campos xiii

LISTA DE TABELAS

Tabela 1 - Correspondência entre arquitecturas e famílias ARM. 8

Tabela 2 - Características do módulo para integração "Micro2440 (FriendlyARM, 2011a)". 27

Tabela 3 - Características do módulo para integração " Netus G20 (AcmeSystems, 2011)". 28

Tabela 4 - Características do módulo para integração "LPC-H3131 (OLIMEX, 2011a)". 28

Tabela 5 - Características do módulo para integração "LPCEB2000-B (Embest Info, 2011a)". 29

Tabela 6 - Características da placa de desenvolvimento "909-CS-E9302 (OLIMEX, 2011b)". 30

Tabela 7 - Características da placa de desenvolvimento "Micro2440 (FriendlyARM, 2011b)". 30

Tabela 8 - Características da placa de desenvolvimento "EB-SAM9G45 (Embest Info, 2011a)". 31

Tabela 9 - Características da placa de desenvolvimento "EK_LM3S8962 (TI, 2011)". 31

Tabela 10 - Tabela de especificações do equipamento. 33

Tabela 11 - Configuração da porta série de debug RS232 e RS232. 45

Tabela 12 - Ligações do conector JTAG (Rath, D., 2005). 54

Tabela 13 - LEDs indicadores do estado da comunicação Ethernet. 59

Tabela 14 - Características técnicas da placa de circuito impresso “MAIN BOARD”. 61

Tabela 15 - Lista das camadas da placa de circuito impresso "MAIN BOARD". 61

Tabela 16 - Características técnicas da placa de circuito impresso “CPU BOARD”. 62

Tabela 17 - Lista das camadas da placa de circuito impresso "CPU BOARD". 62

Tabela 18 - Especificações técnicas do equipamento. 63

Tabela 19 - Configuração dos Jumpers placa “MAIN BOARD”. 64

Tabela 20 - ConFiguração dos Jumpers da placa “CPU BOARD”. 64

Tabela 21 - Custos de produção do equipamento para 1 unidade e 100 unidades. 93

Projecto e Construção de um Sistema Embebido de Tempo-Real Baseado em Linux SIMBOLOGIA

Adriano José Ribeiro Campos xv

SIMBOLOGIA

hertz (símbolo: Hz) – É a unidade de frequência derivada do Sistema Internacional de Unidades (SI), para frequência. É expressa em termos de ciclos por segundo, a frequência de um evento periódico. KHz – Múltiplo do SI para Hz e representa 103 Hz. MHz – Múltiplo do SI para Hz e representa 106 Hz. GHz – Múltiplo do SI para Hz e representa 109 Hz. segundo (símbolo: s) – É a unidade de frequência derivada do Sistema Internacional de Unidades (SI), para medir intervalos de tempo. milisegundos (símbolo: ms) – Múltiplo do SI para segundos e representa 10-3 s. microsegundos (símbolo: µs) – Múltiplo do SI para segundos e representa 10-6 s. nanosegundos (símbolo: ns) – Múltiplo do SI para segundos e representa 10-9 Hz. Volt (símbolo: V) – É a unidade de tensão eléctrica do SI, que representa a diferença de potencial eléctrico entre dois pontos. milivolts (símbolo: mV) – Múltiplo do SI para volts e representa 10-3 V. amperes (símbolo: A) – É uma unidade de medida do SI de intensidade de corrente eléctrica. miliampere (símbolo: mA) – Múltiplo do SI para amperes e representa 10-3 A. microampere (símbolo: µA) – Múltiplo do SI para amperes e representa 10-6 A. Ohm (símbolo: Ω) – É a unidade de resistência eléctrica do SI. miliohm (símbolo: m Ω) – Múltiplo do SI para resistência e representa 10-3 Ω. graus celsius (símbolo: °C) – É uma unidade de medida de temperatura. A escala oficial, indicada pelo Sistema Internacional de Unidades, é a Kelvin . A conversão é realizada pela seguinte equação: t ºC = (t + 273) K. metro (símbolo: m) – É a unidade de medida de comprimento do SI. milimetro (símbolo: mm) – Múltiplo do SI para metro e representa 10-3. byte (símbolo: B) – É a codificação padronizada que foi definida como sendo de 8 bits. Pode ser representada por múltiplos, como KB (210B), MB (220B), GB (230B), TB (240B), etc. bit (símbolo: b) – É a simplificação para um dígito binário. Pode ser representada por múltiplos, como Kb (103), Mb (106) Gb (109) Tb (1012). byte por segundo (símbolo: Bps) É uma taxa de transferência de dados binários. bit por segundo (símbolo: bps) É uma taxa de transferência de dados binários

Projecto e Construção de um Sistema Embebido de Tempo-Real Baseado em Linux ABREVIATURAS

Adriano José Ribeiro Campos xvii

ABREVIATURAS

ADC – do Inglês, Analog-to-Digital Converter ADEOS – do Inglês, Adaptive Domain Environment for Operating Systems ARM – do Inglês, Advanced RISC Machine API – do Ingles, Application Programming Interface BOM – do Inglês, Bill Of Materials CAN – do Inglês, Controller–area network CMOS – do Inglês, Complementary Metal–Oxide–Semiconductor CPU – do Inglês, Central Processing Unit CISC – do Inglês, Complex Instruction Set Computer CDC – do Inglês, Communication Device Class DMA – do Inglês, Dynamic Memory Allocation DVD – do Inglês, Digital Versatile Disc DC – do Inglês, Direct Current DDR SDRAM – do Inglês, Double Data Rate Sincronous Dynamic Random Access Memory EDA – do Inglês, Electronic Design Automation E/S – Entradas e saídas FPGA – do Inglês, Field-Programmable Gate Array GPNVM – do Inglês, General Porpouse Nom Volatile Memory Bits IEEE – do Inglês, Institute of Electrical and Electronics Engineers

IEC – do Inglês, International Electrotechnical Commission I/O – do Inglês, Inputs / Outputs JTAG – do Inglês, Joint Test Action Group LQFP – do Inglês Low-profile Quad Flat Package LDO – do Inglês, Low Dropout MP3 – do Inglês, MPEG-1/2 Audio Layer 3 MII – do Inglês, Media Independent Interface NTRST – do Inglês, Test Reset Signal NRST – do Inglês, Microcontroller Reset Active a Low LED – do Inglês, Light Emitting Diode PMC – do Inglês, Power Management Controller PIO – do Inglês, Parallel Input / Output Controller PLL – do Inglês, Phase-Locked Loop or Phase Lock Loop PMC – do Inglês, Power Management Controller PTP – do Inglês, Precision Time Protocol PLD – do Inglês, Programmable Logic devices PCB – do Inglês, Printed Circuit Board GNU – do Inglês, GNU's Not Unix! GDB – do Inglês, GNU Project debugger GPS – do Inglês, Global Positioning System

Projecto e Construção de um Sistema Embebido de Tempo-Real Baseado em Linux ABREVIATURAS

xviii

SDRAM – do Inglês, Synchronous Dynamic Random Access Memory SDR SDRAM – do Inglês, Single Data Rate Sincronous Dynamic Random Access Memory SDR – do Inglês, Single Data Rate SPI – do Inglês, Serial Peripheral Interface SD CARD – do Inglês, Secure Digital Card SSC – do Inglês, Synchronous Serial Controller DIN – do Alemão, Deutsche Industrie Norm RAM – do Inglês, Random-Access Memory RMMI – do Inglês, Reduced Media Independent Interface RTOS – do Inglês, Real Time Operating System RTAI – do Inglês, Real Time Application Interface RTCK – do Inglês, Returned Test Clock RISC – do Inglês, Reduced Instruction Set Computer RTC – do Inglês, Real-Time clock RXD – do Inglês, Receive Data

TDI – do Inglês, Test Data In TMS – do Inglês, Test Mode Select TCK – do Inglês, Test Clock TXD – do Inglês, Transmit Data TWI – do Inglês, Two Wire Interfaces TDO – do Inglês, Test Data Out TAP – do Inglês, Test Access Port USB – do Inglês, Universal Serial Bus USART – do Inglês, Universal Asynchronous Receiver / Transmitter OSI – do Inglês, Open Systems Interconnection ISO – do Inglês, International Organization for Standardization

CAPITULO 1

Adriano José Ribeiro Campos 1

1 INTRODUÇÃO

Este capítulo apresenta uma introdução ao Trabalho de Projecto, descrevendo as motivações, os objectivos, a organização deste documento e ainda as considerações linguísticas usadas na escrita deste documento. Estes assuntos são abordados nos seguintes subcapítulos:

• Subcapítulo 1.1: Motivação para a realização deste projecto;

• Subcapítulo 1.2: Objectivos do projecto;

• Subcapítulo 1.3: Organização do documento;

• Subcapítulo 1.4: Considerações linguísticas.

1.1 Motivações

Com a evolução da tecnologia, uma diversificada gama de equipamentos electrónicos são diariamente colocados no mercado. Este crescimento atinge especialmente os sistemas embebidos, estando estes cada vez mais presentes na nossa vida diária. Consequentemente, o desenvolvimento de sistemas embebidos é, nos dias de hoje, uma actividade muito importante na economia de um país industrializado e moderno, devido especialmente ao impacto que este tipo de sistemas tem no desenvolvimento de equipamentos electrónicos, em todas as áreas, desde a indústria até ao entretenimento. A arquitectura ARM não é exactamente uma novidade, pelo contrário, criada em 1983, ela está prestes a completar três décadas de existência e vê agora as suas possibilidades ampliadas. A arquitectura ARM passou a ser nos últimos anos uma referência para sistemas embebidos, principalmente pela sua simplicidade, baixo consumo e por ser vendida como um IP (do Inglês, Intellectual Property), o que faz com que qualquer empresa possa produzir processadores com arquitectura ARM desde que adquira os respectivos direitos com a empresa inglesa ARM Lda. (Advanced RISC Machines). Os processadores com arquitectura ARM, desde que foram criados, alcançaram uma fatia expressiva de mercado, em cerca de 90% de todos os sistemas embebidos. Actualmente, mais de 98% de todos os telemóveis vendidos no mundo usam algum processador baseado na arquitectura ARM. Estes números mostram como esta tecnologia é uma opção válida e segura para um sistema embebido (GEEK, 2011). No caso do sistema embebido ser implementado com um sistema operativo genérico, um ponto importante são as licenças de utilização. Umas são fornecidas sobre licenças de software livre, outras ainda admitem a utilização com o pagamento de royalties sobre as unidades vendidas e outras sobre licenças de utilização pagas. Neste projecto pretende-se desenvolver uma plataforma utilizando ferramentas com licenças de software livre, proporcionando uma solução competitiva. Consequentemente este projecto, ao nível do software, será implementado com as soluções GNU/Linux e outras soluções disponibilizadas por outros projectos de software livre, como o projecto Xenomai e ADEOS. Estes dois últimos fornecem pacotes de software que permitem adaptar o kernel

INTRODUÇÃO

2

Linux para incluir com características de funcionamento em tempo-real. Um sistema embebido torna-se ainda mais interessante se funcionar com características de tempo-real.

1.2 Objectivos

Apesar de existir muita investigação na área dos sistemas embebidos e dos sistemas de tempo-real, não é muito comum encontrarmos projectos apresentando uma descrição da implementação de um equipamento personalizado para automação industrial, com essas características. O objectivo desde trabalho é projectar e construir um equipamento baseado num sistema embebido com um processador com arquitectura ARM, assente no kernel Linux, com alterações para funcionar com características de tempo-real e com as aplicações GNU, que seja funcionalmente compatível com os ambientes industriais. Para que este objectivo principal seja cumprido, foram criadas algumas metas no percurso deste projecto, sendo elas:

• Estudo das tecnologias envolvidas: Estudo do actual estado destas tecnologias emergentes e breve descrição das mesmas. Neste ponto serão utilizadas diversas referências e trabalhos de pesquisa e investigação na área, sendo sempre referenciados os seus autores;

• Desenvolvimento de uma plataforma de hardware: O desenvolvimento de uma plataforma de hardware adaptado a calha de automação, com uma caixa genérica e contendo um conjunto de interfaces de comunicação, como Ethernet, CAN, RS485, RS232 e USB. Os componentes escolhidos foram seleccionados tendo em conta os requisitos especificados e as várias condicionantes do projecto;

• Desenvolvimento de uma plataforma de software: Adaptação do kernel Linux para ter características de tempo-real, e para funcionar no hardware projectado. Após o firmware

adaptado, pretende-se colocar na plataforma de hardware desenvolvida neste projecto, o kernel Linux e algumas aplicações GNU. Neste ponto merecem especial atenção, a correcta integração do sistema operativo com todos os componentes do mesmo, a arquitectura escolhida e o arranque inicial do sistema;

• Caso de estudo: Demonstração de uma aplicação exemplo, na área de automação industrial onde sejam evidenciadas as potencialidades do sistema desenvolvido, em particular as características de um sistema de tempo-real.

1.3 Organização do documento

Este documento está organizado nos seguintes capítulos e anexos:

• Capítulo 1 – Introdução;

• Capítulo 2 – Estado da Arte;

• Capítulo 3 – Desenvolvimento da plataforma de hardware;

• Capítulo 4 – Desenvolvimento da plataforma de software;

• Capítulo 5 – Conclusões;

• Referências bibliográficas – Identificação das referências usadas neste projecto;

• Anexos – Esquemas eléctricos e ficheiros de configuração.

CAPITULO 1


1.4 Considerações linguísticas

Num documento sobre um projecto essencialmente técnico e especialmente na área que este se insere, é inevitável o recurso a alguns termos em língua estrangeira. Sempre que possível é usado o termo na língua portuguesa, quando não é possível o termo aparecerá no formato de texto Itálico, por exemplo, hardware ou firmware. Assim, os termos que serão utilizados em Inglês, são apresentados nos seguintes pontos, juntamente com uma pequena descrição:

• hardware: Dispositivo electrónico, desde circuitos integrados a componentes passivos, que disponibilizam a capacidade de processamento, de memória, de interface ao utilizador e a interacção com o mundo exterior, quer seja por accionamentos de dispositivos electromecânicos quer por interfaces com o utilizador.

• firmware: Programas e estruturas de dados que permitem a execução da tarefa para o qual o sistema foi construído. Em sistemas embebidos, usa-se o termo firmware em vez de software, visto que nestes sistemas o firmware é desenvolvido para aceder directamente ao hardware;

• jumpers: Em Português "ligação em ponte" é um pequeno conector que possibilita abrir ou unir uma determinada linha de uma placa de circuito impresso. São normalmente utilizados para configurações ou para técnicas de debug;

• debug: Em Português "depuração" é o processo de encontrar e reduzir ou eliminar defeitos em software e/ou hardware;

• interface: Dispositivo ou meio que controla a interligação entre dois dispositivos de hardware e/ou software e os ajuda a trocar dados de forma confiável e segura;

• upgrade: Normalmente designa o acto de troca de um hardware e/ou software por uma versão melhorada ou mais recente, com o objectivo de agregar novas funcionalidades, ou melhorar as existentes.

CAPITULO 2


2 ESTADO DA ARTE

Este capítulo apresenta as diversas tecnologias abordadas neste projecto, segundo as suas características básicas, a evolução histórica, a aceitação do mercado, entre outros pontos que se considerem importante referir. Assim, este capítulo descreve as tecnologias abordadas pela seguinte ordem de subcapítulos:

• Subcapítulo 2.1: Arquitectura ARM;

• Subcapítulo 2.2: Sistemas embebidos;

• Subcapítulo 2.3: Soluções GNU/Linux;

• Subcapítulo 2.4: Sistemas operativos de tempo-real (RTOS);

• Subcapítulo 2.5: Protocolo de rede Ethernet e a norma associada IEEE1588;

• Subcapítulo 2.6: Resumo sobre barramentos industriais, nomeadamente os que serão integrados neste projecto;

• Subcapítulo 2.7: Conclusões.

2.1 Arquitectura ARM

O primeiro ponto importante no que se refere à arquitectura ARM é que não se trata de um microcontrolador ou processador produzido por uma empresa. Na verdade, esta arquitectura define o núcleo funcional de um processador, ou seja, a sua arquitectura, os seus registos internos, o conjunto de instruções, algumas unidades funcionais, entre outras características. A empresa inglesa ARM Lda. (Advanced RISC Machines), responsável pelo desenvolvimento e licenciamento da arquitectura ARM, licencia este núcleo (do Inglês, core) para fabricantes que produzem microcontroladores, com processadores baseados nesta arquitectura ao nível do processador e com os periféricos que consideram mais importantes para atender ao seu mercado e a determinadas aplicações. Estes microcontroladores combinam uma vasta gama de periféricos com uma excelente relação custo/beneficio e processamento/consumo. Alguns exemplos de empresas multinacionais que obtiveram a licença ARM e fabricam produtos com esta tecnologia são: Alcatel-Lucent, Apple Inc., ATMEL, Broadcom, Cirrus Logic, Digital Equipment

Corporation, Freescale, Intel, LG, Marvell Technology Group, Microsoft, NEC, Nintendo, Nuvoton, Nvidia, Sony, NXP, Oki, ON Semiconductor, Qualcomm, Samsung, Sharp, STMicroelectronics,

Symbios Logic, Texas Instruments, VLSI Technology, Yamaha and ZiiLABS. É neste contexto que a tecnologia ARM aparece como o principal expoente em processadores para sistemas embebidos baseados em arquitecturas de 32 bits. Actualmente, processadores com a arquitectura ARM são usados em incontáveis projectos e a tecnologia ARM é encontrada facilmente em telemóveis, leitores de MP3, câmaras fotográficas e

ESTADO DA ARTE

6

dispositivos de navegação GPS, equipamentos da indústria automóvel, aplicações médicas e em aplicações de controlo industrial. O sucesso da arquitectura ARM resultou na criação da ARM Connected Community, a maior rede de indústrias de subcontratação de serviços, que fornecem ferramentas de desenvolvimento ARM. Assim pode-se dizer que a ARM tem o melhor suporte internacional dentro da categoria. Uma visão geral destas empresas pode ser verificada na seguinte hiperligação:

• www.arm.com/community A arquitectura ARM é ainda suportada por diversas ferramentas de código aberto (do inglês, open source), como por exemplo, o compilador GNU e a ferramenta de debugger GDB. Algumas empresas de ferramentas de desenvolvimento especializaram-se em aplicações baseadas em microcontroladores ARM, resultando em soluções completas (do Inglês, end-to-end) para desenvolvimento de software. É seguindo esta tendência de mercado, que se optou por esta tecnologia. Consequentemente este projecto abre boas oportunidades para que investigadores, possam estudar e avaliar soluções baseadas na tecnologia ARM que os colocarão em sintonia com as exigências actuais do mercado de sistemas embebidos, nomeadamente na área das aplicações industriais.

2.1.1 Evolução histórica

A história da tecnologia ARM começou nos anos 80, com a empresa Acorn Computers Ltd., fabricante de computadores Inglês, conhecido na altura por ter criado o computador BBC Micro, para a empresa de televisão BBC. Projectado com ênfase na educação, foi notável pela sua robustez e fiabilidade do sistema operativo, vendendo quase 2 milhões de unidades. Usava um processador de 8 bits, com a tecnologia 6502, fabricado pela empresa RockWell, com endereçamento de 16 bits e funcionando normalmente a 1 MHz. Este foi o mesmo processador usado nos computadores Apple I e Apple II, e variantes deste processador também foram usadas em vídeo jogos da época como o Atari 2600 e o NES da Nintendo. Com o sucesso da família de computadores BBC Micro, a Acorn Computers Ltd., sentiu a necessidade de equipar os seus computadores com maior capacidade de processamento, mas não encontrou no mercado um processador ao nível das suas exigências. Assim, os engenheiros da Acorn resolveram criar um processador do zero. Em 1985 nasce o primeiro ARM, projectado pela Acorn e fabricado pela empresa VLSI Technology (WIKIPEDIA, 2011a). O ARM1 foi desenvolvido como um RISC de 32 bits, baseado na arquitectura do 6502. No ano seguinte a empresa lança o ARM2, com melhorias no conjunto de instruções, tornando-as mais rápidas. Em 1987, a Acorn lança o seu primeiro computador pessoal com um processador ARM, o famoso Archimedes. Apesar do sucesso na altura, especialmente em Inglaterra, foi perdendo o mercado para os processadores x86 (IBM). No entanto, a empresa Acorn continuou a desenvolver o seu processador e em 1989 lança o ARM3 com um cache de 4k e funcionando a 25MHz. Na altura já começava a ser claro o mercado que a tecnologia ARM se destinaria: processadores RISC de alta performance, baixo consumo e excelente relação custo/beneficio, voltado para o uso em sistemas embebidos.

CAPITULO 2


Nos inícios dos anos 90, a empresa Acorn faz um acordo com a VLSI Technology Inc e a Apple

Computer e foi fundada a ARM Lda. (Advanced RISC Machines). O seu objectivo era dar continuidade ao desenvolvimento da arquitectura ARM, e o seu modelo de negócios mudou para o que conhecemos hoje, a venda de licenças da arquitectura ARM. O ARM6 foi o primeiro resultado da nova empresa, no começo de 1992, incorporando o PDA Newton da Apple. A ARM também trabalhou intensamente para disponibilizar ferramentas como compiladores, assemblers e emuladores para difundir o uso da arquitectura. Outras empresas começaram então a licenciar a arquitectura ARM. Nomeadamente a extinta DEC licenciou a arquitectura e lançou o microprocessador StrongARM, a Freescale o i.MX, a Nvidia o Tegra, a ST-Ericsson o Nova e NovaThor, a Qualcomm o Snapfragon, a Texas Instruments o OMAP, a Samsung o Hummingbird e a Apple A4 e A5. Até a Intel entrou nesta arquitectura, primeiro adquirindo o StrongARM à DEC para substituir o seu velho i960 e em seguida licenciou a arquitectura ARM e desenvolveu o XScale. Este foi vendido por mais de 600 milhões de dólares à empresa Marvell Technology Group e usado em diversos equipamentos nos anos seguintes, sendo ainda hoje usado em equipamentos militares.

2.1.2 Diversas soluções da arquitectura ARM

Desde a sua formação, a ARM tem desenvolvido um conjunto de núcleos de processadores para abranger diferentes necessidades de mercado, desde aplicações básicas de sensores e actuadores, a sistemas de tempo-real e dispositivos móveis como smartfones e netbooks. A Figura 1 apresenta as diversas famílias da arquitectura ARM. A arquitectura ARM7 foi a implementação com mais sucesso, com centenas de milhões de processadores vendidos. Em 2005 foram licenciados cerca de 1.600 milhões de núcleos ARM. O conjunto de instruções THUMB, introduzido pelo ARM7TDMI lançado em 1994, foi um dos factores de sucesso da arquitectura ARM, que possibilitou a economia de bastante memória e o seu uso em dispositivos com poucos recursos. Apesar de ainda termos muitos equipamentos a funcionar, o seu uso vem sendo substituído pela família Cortex-M. Os ARM7 e ARM9 são muito utilizados ainda hoje, em aparelhos mais simples e em produtos electrónicos diversos pois são processadores baratos, fáceis de programar e com bom desempenho. A família ARM11 acrescenta mais robustez ao núcleo e equipa os principais equipamentos construídos entre 2007 e 2009. Estas famílias devem ser substituídas gradualmente pela família Cortex. O Cortex-A5 foi o modelo de entrada da nova geração, criado para substituir os ARM7 e ARM9, sendo utilizado em sistemas mais baratos e simples. Cortex-A8 são circuitos electrónicos mais poderosos, com duplo processador, destinados a smartphones e outros dispositivos móveis que necessitem de mais poder computacional. Cortex-A9 são circuitos electrónicos com vários processadores de alto desempenho. Esta nova geração possibilita o uso de velocidades de processamento bem superiores às da primeira geração, podendo ultrapassar 1 GHz. Estes desempenhos estão a permitir a entrada da arquitectura ARM no universo da computação pessoal (Figura 1).

ESTADO DA ARTE

8

Figura 1 – Diferentes famílias da arquitectura ARM (ARM, 2011a).

Além de termos uma quantidade enorme de núcleos ARM, existem dezenas de fabricantes ARM licenciados, com os seus microcontroladores com múltiplas opções de periféricos e diferentes capacidades de memória. É muito fácil perder-se neste universo. A Tabela 1 apresenta a correspondência entre as diversas arquitecturas de núcleos ARM e as respectivas famílias.

Arquitectura Família

ARMv1 ARM1

ARMv2 ARM2, ARM3

ARMv3 ARM6, ARM7

ARMv4 StrongARM, ARM7TDMI,ARM9TDMI

ARMv5 ARM7EJ, ARM9E, ARM10E, XScale

ARMv6 ARM11

ARMv7 Cortex

Tabela 1 - Correspondência entre arquitecturas e famílias ARM.

2.1.3 Mercado da tecnologia ARM

Até Janeiro de 2011, responsáveis da ARM afirmaram que já tinham licenciado mais de 15 biliões de processadores baseados na arquitectura ARM. Actualmente a arquitectura ARM é usada em mais de 95% dos aparelhos móveis do mundo e mais de um quarto de todos os dispositivos electrónicos, segundo dados da própria empresa (ARM, 2011b). Ao contrário da Intel, que agora está correndo atrás do prejuízo com sua arquitectura Atom para entrar no mercado de sistemas embebidos, a ARM vêm sempre crescendo para começar a ocupar um reinado que tem sido da Intel durante muito tempo, nos computadores pessoais com a arquitectura x86 e x64.

CAPITULO 2


Actualmente já aparecem no mercado alguns netbooks com processador ARM, com uma distribuição Linux. Um exemplo, da passagem de Atom para ARM é o netbook da empresa Always Innovating, denominado Smart Book. Este netbook que também é um tablet tem um processador OMAP3, fabricado pelo Texas Instruments, que por sua vez, é constituído por um núcleo ARM Cortex-A8. As previsões de que os processadores ARM alcançarão uma fatia considerável do mercado de computadores pessoais nos próximos anos continuam com cada vez mais força, alimentadas pela confirmação da Microsoft de que a próxima versão do sistema operativo Windows, o Windows 8, funcionará também em processadores ARM. Segundo analistas da empresa iSuppli, em 2015, os processadores baseados na arquitectura ARM devem equipar cerca de 23% de todos os computadores portáteis (TECHSPOT, 2011), como podemos ver na Figura 2.

Figura 2 - Evolução da utilização da arquitectura x86 e ARM (TECHSPOT, 2011).

2.1.4 Principais características técnicas

Os processadores baseados na arquitectura ARM são processadores RISC (do Inglês, Reduced Instruction Set Computer). A outra possibilidade para processadores é o CISC (do Inglês, Complex

Instruction Set Computer). A estratégia das arquitecturas CISC é permitir que os programas fiquem mais pequenos, com elevada densidade de código, pois uma única instrução é capaz de realizar funcionalidades de alto grau de complexidade. Porém, para poder realizar estas instruções mais complexas, os núcleos dos processadores CISC são maiores e mais complexos. Por outro lado, os processadores RISC buscam um desempenho ligado à capacidade de execução de mais instruções por segundo, definindo instruções mais simples. O preço que estes processadores pagam é a necessidade de maior capacidade de armazenamento para os programas. No que diz respeito ao desempenho, as arquitecturas RISC têm-se mostrado mais eficientes, executando rotinas completas mais rapidamente. A arquitectura ARM não apresenta uma arquitectura RISC simples. Na verdade, combina a simplicidade do hardware baseado em ideias RISC e agrega algumas características essenciais do desempenho CISC, conseguindo assim melhor densidade de código que numa arquitectura RISC pura e maior velocidade e desempenho que numa arquitectura CISC. Isso proporciona ao ARM alto desempenho com um núcleo reduzido e grande eficiência no consumo de energia. O modo THUMB é um modo especial que transforma o processador ARM num núcleo de 16 bits, aumentando o espaço disponível na memória de programa. Essa mudança pode ser feita em tempo de

ESTADO DA ARTE

10

execução, dessa forma o ARM possui dois conjuntos de instruções, um de 32 bits e outro de 16 bits. O segundo conjunto é mais simples que o primeiro, mas continua a processar dados em 32 bit. Todos os registos no modo THUMB continuam a ser acessíveis como 32 bit.

2.1.5 Resumo das vantagens de usar ARM

Nos pontos anteriores foram apresentadas ao longo do texto várias vantagens de se usar a arquitectura ARM. Nos próximos tópicos são apresentas essas vantagens, de uma forma resumida. Assim, temos os seguintes benefícios em usar a arquitectura ARM:

• Popular: ARM é a mais popular arquitectura para núcleos de processadores de 32 bits;

• Flexibilidade: Elevada flexibilidade no desenho de projectos, devido a compatibilidade entre as diversas famílias de processadores disponíveis no mercado;

• Variedade: Grande variedade de processamento, desde 1 MHz até mais de 1 GHz;

• Extensões integradas: As extensões integradas permitem ainda um mais eficiente processamento. A extensão THUMB aumenta a densidade de código, a extensão DSP directamente no núcleo aumenta o desempenho no processamento de sinais digitais e em aplicações multimédia e a extensão Jazelle que permite que código Java seja executado mais rápido;

• Baixo consumo: Estes núcleos apresentam a melhor relação entre processamento e consumo do mercado dos 32 bits;

• Fácil acesso: Diversos fabricantes disponíveis no mercado;

• Rápido desenvolvimento: Um elevado número de sistemas operativos preparados para esta arquitectura, juntamente com a comunidade ARM, fornecem um excelente suporte de apoio ao desenvolvimento;

• Baixo custo: Processadores de 32 bits a preço de processadores de 8 bits.

2.2 Sistemas embebidos

Sistemas embebidos (do Inglês, embedded systems) são também designados por alguns autores da língua portuguesa como sistemas embutidos ou sistemas embarcados. No entanto a designação sistemas embebidos é a que gera mais consenso sendo a adoptada neste documento. Generalizando, sistema embebido é todo o sistema com processador, que é encapsulado e dedicado a um dispositivo ou sistema específico. Distingue-se dos computadores genéricos, por estes serem projectados para realizar tarefas específicas e predefinidas, através do processamento automático de informação. Assim, construindo sistemas específicos para a aplicação, reduz-se custos e tempos de projecto. Actualmente no nosso dia-a-dia, interagimos sem nos apercebermos com diversos sistemas embebidos, por exemplo, em máquinas de café, máquinas de lavar roupa, televisores e outros electrodomésticos, automóveis, máquinas multibanco, etc. Estes são todos sistemas com processamento de informação e logo são sistemas embebidos visto que não podemos alterar o seu funcionamento e/ou firmware.

CAPITULO 2


Sistemas mais complexos, como smartfones, PDA’s e tablets, são também considerados sistemas embebidos apesar de serem mais flexíveis ao nível do software. No entanto as suas características de hardware, coloca-os nas categorias de sistemas embebidos. Normalmente neste tipo de sistemas não permitem que o utilizador final possa alterar o firmware do mesmo. A única flexibilidade permitida é, no caso de um upgrade de novas versões de firmware disponibilizadas pelos fabricantes, que também disponibilizam as ferramentas necessárias para o respectivo upgrade. Para que um sistema embebido consiga executar as suas tarefas específicas são necessários os seguintes elementos:

• Hardware: Dispositivos electrónicos, desde circuitos integrados a componentes passivos, que disponibilizam a capacidade de processamento, de memória, de interface com o utilizador e a interacção com o mundo exterior, quer seja por accionamentos de dispositivos electromecânicos, quer por interfaces com o utilizador. Pode também ser distinguido por ser a parte de elementos tangíveis ou físicos e não algoritmos, instruções ou outros elementos abstractos;

• Firmware: Programas e estrutura de dados que permitem a execução da tarefa para o qual o sistema foi construído. Em sistemas embebidos, o termo mais correcto é firmware em vez de software, visto que nestes sistemas o firmware é desenvolvido para aceder directamente ao hardware.

As propriedades mais importantes de um sistema embebido são:

• Função específica: Os sistemas embebidos normalmente são projectados para executar uma tarefa específica e pré-definida de uma aplicação ou sistema;

• Funcionamento contínuo: Normalmente estes sistemas funcionam continuamente, podendo estar vários meses ou mesmo anos em funcionamento;

• Interacção permanente: Estes sistemas têm de constantemente interagir com o ambiente exterior quer seja por actuadores ou sensores, ou ambos ao mesmo tempo;

• Sistemas confiáveis: Muitas vezes estes sistemas realizam operações críticas, onde falhas podem ser catastróficas e por isso devem ser extremamente confiáveis. Um sistema diz-se confiável quando é estável, tem a capacidade de recuperar de falhas de forma autónoma, alta disponibilidade e baixo tempo de resposta a interagir com o meio exterior, para além de ter altos níveis de segurança, quer para o meio ambiente controlado pelo mesmo, quer por manter a confidencialidade dos dados do sistema;

• Outros requisitos: Num sistema embebido é exigido para além do seu correcto funcionamento, que um conjunto de métricas seja cumprido. Ao desenvolvimento de sistemas embebidos está associado um conjunto de requisitos não funcionais que incluem, entre outros, a fiabilidade, o desempenho e outros aspectos físicos, como o tamanho, o peso, o consumo de energia, etc. (Fernandes, J., 2000).

ESTADO DA ARTE

12

2.2.1 Desenvolvimento de um sistema embebido

Existem diversos métodos para o desenvolvimento de um sistema embebido, dependendo da complexidade e exigências do projecto. No entanto as etapas essenciais são as seguintes:

• Levantamento de requisitos: O levantamento de requisitos deve ser feito de forma exaustiva, de modo que sejam considerados todos os pontos. Os requisitos levantados durante a execução do projecto podem levar a alterações profundas do projecto, podendo ter custos elevados de implementação. Deste levantamento de requisitos deve resultar uma descrição clara e especifica do que pretendemos implementar;

• Pesquisa de mercado: A pesquisa de mercado é uma das etapas que se deve efectuar antes de se elaborar um projecto deste tipo. Soluções com ampla aceitação são normalmente mais acessíveis de implementar.

• Especificação: Na especificação descreve-se como o sistema se deve comportar e como ele é construído;

• Arquitectura: Na especificação da arquitectura detalha-se os constituintes do equipamento. Nesta fase começam a ser definidos os componentes essenciais do projecto e os módulos de software;

• Módulos: Nesta etapa são desenvolvidos os módulos do projecto, que podem ser módulos de hardware ou software. Os trabalhos são específicos a uma determinada parte integrante do projecto, podendo estes ser mesmo executados por equipas ou pessoas diferentes;

• Integração: Esta etapa é a mais complexa de todas e surge numa fase final em que é feita a integração de todos os componentes do projecto e é onde são encontrados os defeitos e problemas, que podem ser resultantes de erros em qualquer das etapas anteriores. A detecção de erros deve ser conseguida sempre que possível, efectuando o debug módulo a módulo de forma isolada, para facilitar o processo. De igual forma, deve-se também especificar logo no início do projecto, quais serão os meios e ferramentas que serão utilizadas nesta fase, para fazer um verificação e debug de funcionamento do equipamento (Fernandes, J., 2000).

Durante todas as etapas devem ser considerados ainda os seguintes requisitos não funcionais:

• Custo de produção: O menor possível, sem comprometer os requisitos e especificações do projecto. Estes custos como veremos na análise de custos no final deste documento, dependem em muito dos custos de produção que são fortemente influenciados pelo número de produtos produzidos;

• Desempenho: Deveremos prever um desempenho que permita não só implementar os requisitos do projecto, bem como deixar alguma margem para futuras necessidades ou mesmo necessidades que surjam durante o decorrer do projecto;

• Consumo de energia: Implementar meios que permitam desligar periféricos ou diminuir a velocidade de processamento dos mesmos e reduzir assim os consumos de energia;

• Interface com o utilizador: O interface com o utilizador deve ser sempre intuitivo, claro, simples e funcional. Na grande maioria dos sistemas embebidos não existe uma interface gráfica com o utilizador, no entanto deverá sempre existir algum mecanismo de indicação do estado funcional do mesmo.

CAPITULO 2


2.3 Soluções GNU/Linux

Actualmente soluções baseadas no kernel Linux e nas aplicações GNU, normalmente designadas por soluções GNU/Linux, podem ser encontradas em inúmeras aplicações, desde navegadores de GPS, smartphones, equipamentos de rede, equipamentos de televisão digital, tablets, etc. Como é uma solução de software livre, oferece algumas vantagens comparado com sistemas proprietários. A questão é se uma solução sobre a licença de software livre é relevante para a automação industrial. A resposta é claramente que sim. Actualmente existem muitos controladores para automação industrial ou outros sistemas embebidos que usam GNU/Linux para fornecer serviços. GNU/Linux oferece uma solução personalizável, confiável e eficiente.

2.3.1 Vantagens e desvantagens das soluções baseadas em GNU/Linux

As principais vantagens do uso de soluções baseadas em GNU/Linux são:

• Software livre: Uma das grandes vantagens é a colaboração da comunidade GNU/Linux, que disponibiliza muita informação, sendo esta uma característica principal natural das soluções de software livre. A utilização de software livre é por sua natureza gratuita e este pode ser adaptado livremente pelo utilizador final para as suas necessidades específicas. Além disso pode-se tirar partido de qualquer solução que já tenha sido criada na comunidade para a aplicação a desenvolver;

• Segurança: Sistemas operativos como o Windows apresentam constantemente ameaças de segurança de aplicações de software maliciosas (do inglês, Malware), destinado a infiltrar-se num sistema de computador alheio de forma ilícita, com o intuito de causar algum dano ou roubo de informações. Para se manter em segurança relativamente às novas vulnerabilidades encontradas, os utilizadores devem manter os seus sistemas frequentemente com os últimos pacotes de aplicações de software de actualização da Microsoft. O kernel Linux é muito mais seguro e enfrenta um menor número de ameaças. Com o Linux os projectistas podem poupar a energia de se preocupar com os tempos de serviço em baixo e vulnerabilidades de segurança;

• Estabilidade e Confiança: Soluções baseadas no kernel Linux oferecem excepcional estabilidade e segurança. É possível actualizar partes do sistema Linux sem reiniciar o sistema completo. Todos os serviços executados no Linux são independentes. Se um serviço pára, ele não danifica os outros serviços. Com o Linux, o sistema inteiro tem maior produtividade e maior tempo operacional (do Inglês, Uptime);

• Custo: Ao nível dos custos a vantagem do Linux vai para além dos custos de aquisição do sistema operativo e de licenças de utilização. O aumento da estabilidade e segurança reduz os custos de manutenção dos sistemas. Além disso existe uma densa comunidade na Internet, de entusiastas e apaixonados do Linux, que disponibilizam recursos muito ricos.

2.3.2 GNU/Linux em sistemas embebidos

O kernel Linux e as aplicações GNU, como são disponibilizadas sobre licença de software livre, permitem aos projectistas de sistemas embebidos a flexibilidade para reduzir o sistema operativo para se adaptar à sua plataforma alvo, ou adaptá-lo para melhor cumprir os requisitos específicos da sua

ESTADO DA ARTE

14

aplicação. Estas características tornam a solução GNU/Linux uma boa solução para sistemas embebidos, tendo se estabelecido como uma alternativa, sendo nos dias de hoje, dominante em projectos de sistemas embebidos. Os resultados das últimas pesquisas do portal Linuxdevices (LinuxDevices (2007), que são apresentadas na Figura 3, mostram que o uso de soluções GNU/Linux ainda está em ascensão. Esta pesquisa diz que actualmente mais de 45 em cada 100 projectos das empresas participantes na pesquisa têm usado soluções GNU/Linux em projectos integrados e/ou produto. Concluí-se ainda, que ao contrário do GNU/Linux as outras soluções tradicionais para sistemas embebidos têm perdido valor no mercado (LinuxDevices, 2007).

Figura 3 – Tendência do uso de sistemas operativos em sistemas embebidos.

2.4 Sistemas operativos de tempo-real (RTOS)

Neste subcapítulo, serão apresentados soluções para sistemas operativos de tempo-real, designados por RTOS (do Inglês, Real Time Operating System), que proporcionem uma infra-estrutura confiável para construir sistemas embebidos. Um sistema de tempo-real, pode-se caracterizar de forma sucinta como um sistema capaz de processar dados, e gerar uma resposta antes de um tempo máximo predefinido para cada situação. Aplicações como pilotagem automática de veículos motorizados, controle de tráfego aéreo ou ferroviário, controladores de robótica, receptores de televisão digital, sistemas de navegação e controladores de máquinas industriais, tal como a maioria dos sistemas de controlo e aquisição de dados enquadram-se na categoria de sistemas com necessidades de processamento em tempo-real. Por vezes, o termo tempo-real é confundido com um sistema que é simplesmente rápido, o que está errado. Nos sistemas de tempo-real o importante é a previsibilidade do sistema e não a sua velocidade de processamento. Em engenharia e computação, o sentido de tempo-real é usado de uma forma mais específica, significando o grau de determinismo de um sistema. Dessa forma, a execução de algumas tarefas pode ser lenta, mas deve ocorrer num intervalo de tempo predeterminado, sendo que o não

CAPITULO 2


cumprimento desse tempo muitas vezes está relacionado com incidentes fatais para os sistemas e até mesmo para a vida humana. Os sistemas operativos convencionais, como o Windows ou mesmo as soluções GNU/Linux na sua forma original, foram desenvolvidos em contraposição a este tipo de determinismo, sendo projectados para terem o menor tempo de resposta possível ao utilizador, favorecendo a interactividade com o utilizador, não o controlo de um sistema de forma determinística. Os sistemas de tempo-real podem ser classificados a partir do modo de execução das suas tarefas em:

• Sistemas Operativos de Tempo-real não críticos: quando a consequência de uma falha devida ao não cumprimento de um tempo de execução de uma tarefa (Deadline) é da mesma ordem de grandeza que os benefícios do sistema em operação normal (ex. sistema de comutação telefónico);

• Sistemas Operativos de Tempo-real críticos: quando as consequências de pelo menos uma falha no cumprimento de um tempo de execução de uma tarefa (Deadline) excedam em muito os benefícios normais do sistema (ex. sistema de controle de aviões).

2.4.1 Sistemas operativos de tempo-real baseados em Linux

Devido à crescente utilização de soluções GNU/Linux em sistemas embebidos, vários projectos têm sido lançados com o objectivo de adaptar o kernel Linux de modo a torná-lo um sistema operativo com características de tempo-real. Estas adaptações são essencialmente alterações no código fonte do kernel Linux, na forma de pacotes de software de modificação (do Inglês, Patch). Dentro dos vários projectos livres ou proprietários os mais reconhecidos actualmente são o RTLinux, o RTAI, o QNX e o Xenomai. Este último é um projecto derivado do Fusion, que foi uma transição do RTAI para o Xenomai. Estes pacotes de software são extensões ao kernel Linux, que oferecem suporte a tarefas com restrições temporais críticas e que alcançam latências da ordem dos microsegundos. O RTLinux foi o pioneiro neste tipo de abordagem no entanto tem perdido visibilidade para os outros dois pacotes de software, o Xenomai e o RTAI. Enquanto estes se mantêm como software livre o RTLinux apresenta-se actualmente com duas versões, uma com licença GPL e outra proprietária, o que sugere que a versão GPL perca qualidade e recursos, ficando desactualizada em relação à versão comercial. A empresa que suporta as duas versões, a RTLabs, tem interesse na comercialização da versão proprietária. Uma desvantagem do RTLinux é o excesso de modificações no kernel Linux para incluir funcionalidades de tempo-real, o que se torna uma grande dificuldade para acompanhar as evoluções do kernel Linux. Neste ponto o RTAI e o Xenomai utilizam uma abordagem diferente, utilizando o mesmo pacote de software desenvolvido pelo projecto ADEOS, mantido por Philippe Gerum, o mesmo autor do projecto Xenomai. Este pacote de software é genérico e fornece um maior controlo sobre as funções do kernel Linux, como interrupções e gestão de memória. O microkernel ADEOS disponibiliza uma interface de programação de aplicações (do Ingles, Application Programming

Interface (API)) sobre a qual pode ser implementado um ou mais kernel de tempo-real sob a forma de

ESTADO DA ARTE

16

diferentes domínios. Desta forma, tanto o RTAI como o Xenomai criaram um domínio diferente sobre o kernel fornecido por ADEOS (Figura 4).

Figura 4 - Arquitectura de tempo-real implementada pelo projecto ADEOS.

A ideia é que estes dois sistemas executem lado a lado (na mesma máquina), utilizando um microkernel, que gere as interrupções geradas pelo hardware. Este microkernel que é fornecido por um patch separado é o ADEOS (do Inglês, Adaptative Domain Environment for Operating Systems), o qual funciona com o conceito de domínios, que são as entidades que coexistem na máquina. Cada domínio comunica com o ADEOS mas não tem o conhecimento dos outros. Com o ADEOS o kernel do sistema operativo de propósito geral (Linux) passa a ter prioridades mais baixas, comparado com as tarefas geridas pelo sistema operativo de tempo-real. Assim, as interrupções são tratadas primeiro no sistema operativo de tempo-real e, caso não sejam destinadas a este, passam ao sistema operativo de propósito geral. Uma alternativa a este método é retirar todo o não-determinismo temporal existente no kernel Linux e procurar diminuir as latências quando possível, sendo esta tarefa muito complexa e requerendo um elevado conhecimento do kernel Linux.

2.5 Norma IEEE 1588

Na automação industrial, os vários equipamentos de um sistema distribuído estão normalmente fisicamente afastados uns dos outros, logo torna-se necessário a existência de um relógio local em cada equipamento. No entanto, não é suficiente pois existe a necessidade de sincronismo entre os diversos relógios, para termos um sistema com coerência temporal. Para solucionar este problema, diversos protocolos têm sido apresentados por fabricantes de hardware e software. A Norma IEEE1588-2002 (Standard for a Precision Clock Synchronization Protocol for Networked

Measurement and Control Systems), descreve o Precision Time Protocol (PTP). Esta norma descreve uma solução completa para fazer a sincronização de tempo muito preciso, numa rede distribuída. O protocolo foi originalmente desenvolvido pela empresa Agilent Technologies, no final dos anos 90, para instrumentação distribuída e para o controlo de processos. A técnica é baseada na obra de John

Eidson, que, como presidente do comité de normalização, é o grande responsável pela aprovação da norma em Novembro de 2002. Posteriormente, em 2004, o protocolo PTP é também adoptado como um standard IEC e foi publicado com a designação IEC61588 e em 2008, surge a versão 2 que resultou na publicação da norma IEEE 1588-2008 (NIST, 2010).

CAPITULO 2


Este protocolo permite sincronismo de relógios de equipamentos distribuídos, numa rede (normalmente Ethernet), utilizando um mecanismo de troca de pacotes compatíveis com a mesma rede. Este protocolo permite uma precisão de menos de um microsegundo, sem exigir grandes capacidades quer da estrutura da rede, quer dos equipamentos distribuídos pela mesma rede. Estas são as principais vantagens relativamente a outros protocolos desenvolvidos para o mesmo efeito (IXXAT, 2011).

2.6 Barramentos industriais

Entre as diversas topologias para interconexão de dispositivos de automação, a mais utilizada é a topologia de barramento. As principais vantagens são:

• Flexibilidade: Torna-se possível em qualquer altura adicionar ou remover dispositivos da rede;

• Distâncias: Permite atingir distâncias maiores que as conexões tradicionais;

• Economia: Redução de custo de implementação dos cabos;

• Simplicidade: Instalação simples da rede e possibilidade de interligação de equipamentos de diferentes fabricantes (Brudna, C, 2000).

O equipamento desenvolvido neste projecto, foi especificado com o barramento CAN e RS485. Ambos são formados por um par de fios entrelaçados, cada um coberto com um isolante. Os dois fios são entrelaçados para garantir que estão igualmente expostos aos mesmos sinais de interferência do ambiente externo. O Sinal é transmitido neste barramento de forma diferencial, ou seja, a diferença de tensão entre os dois terminais do barramento é que transporta a informação. Assim, temos uma grande imunidade EMI (Interferência Electromagnética) devido ao modo diferencial da comunicação (RIBEIRO, M, 1999). Em comunicações de dados digitais, o paradigma é completamente diferente da comunicação analógica. Em comunicações digitais exige-se usar a capacidade de transmitir vários dados simultaneamente (bidireccional), um único meio físico (fio trançado, cabo coaxial, cabo de fibra óptica) e de modo partilhado por todas as fontes de informação. Em vez de sinal, em comunicações digitais, fala-se em protocolo. Protocolo é um conjunto de regras semânticas e sintácticas que determina o comportamento dos instrumentos funcionais da rede, para se poder ter uma comunicação entre eles.

2.6.1 Barramento CAN

Ao contrário da comunicação ponto a ponto, normalmente utilizada pelos outros barramentos, o barramento CAN possui a característica de transmitir para vários elementos ao mesmo tempo (broadcast), o que pode ser convenientemente explorado em sistemas de automação industrial. Além disso, a atribuição de prioridade nas mensagens e recuperação de falhas utilizadas no barramento CAN oferece propriedades de tempo-real. O barramento CAN, que foi desenvolvido pela BOSCH na década de 1980 e tornou-se numa norma internacional (ISO 11898) em 1994, foi especialmente desenvolvido

ESTADO DA ARTE

18

para a rápida troca de dados entre controladores electrónicos em veículos motorizados, e actualmente tem vindo a ser utilizado em automação industrial (Brudna, C., 2000). O protocolo CAN é um protocolo de comunicação série que descreve os serviços da camada 2 do modelo OSI (do Inglês, Open Systems Interconnection), ou seja, na camada “ligação de dados”. Nesta camada, são definidos os diferentes tipos de datagramas (Frames), a forma de detecção de erros, validação e arbitragem de mensagens. Os dados numa rede CAN são transmitidos através de uma mensagem de dados (do Inglês, Frame). Este tipo de mensagem é composta principalmente por um campo identificador de 11 bits (Arbitration field), e um campo de dados (Data Field), que pode conter até 8 bytes de dados (Figura 5).

Figura 5 - Mensagem CAN.

Além da mensagem de dados, existe também a mensagem remota (RTR frame). Este tipo de mensagem não possui campo de dados, apenas o identificador, funcionando como uma requisição para que outro dispositivo da rede transmitir a mensagem de dados desejada. Numa rede CAN, qualquer elemento da rede pode tentar transmitir uma mensagem para a rede num determinado instante. Caso dois elementos tentem aceder à rede ao mesmo tempo, conseguirá transmitir aquele que enviar a mensagem mais prioritária. A prioridade da mensagem é definida pelo identificador da mensagem CAN, quanto menor o valor deste identificador, maior a prioridade da mensagem. O datagrama com o identificador 0 (zero) corresponde ao datagrama mais prioritário. A especificação do protocolo CAN define diversos mecanismos para controlo de erros, o que o torna numa rede muito confiável e com um índice muito baixo de erros de transmissão que não são detectados. Cada dispositivo da rede deve ser capaz de identificar a ocorrência destes erros, e informar os demais elementos que um erro foi detectado. Um dispositivo da rede CAN possui contadores internos que são incrementados cada vez que um erro de transmissão ou recepção é detectado, e decrementado quando um datagrama é enviado ou recebido com sucesso. Somente a definição de como detectar erros, criar e transmitir uma mensagem não são suficientes para definir um significado para os dados que são enviados via rede. É necessário que haja uma especificação que indique como o identificador e os dados devem ser agrupados e como as informações devem ser trocadas. Desta forma os elementos da rede podem interpretar correctamente os dados que são transmitidos. Neste sentido, as especificações como o DeviceNet, CANopen, J1939, entre outros, definem justamente como trocar dados entre os equipamentos e como cada dispositivo deve interpretar estes dados. Porém, estes protocolos não podem operar em conjunto na mesma rede.

2.6.2 Norma RS485

A norma RS-485 (Recommended Standard) é um standard para comunicação diferencial para comunicações digitais. Esta norma foi especificada em 1983 pela EIA (Electronic Industries Alliance) e tem tido grande aceitação, sendo implementado em todo o tipo de sistemas industriais e de consumo. A norma RS485 é uma norma que apenas especifica as características eléctricas do barramento, do emissor, do receptor e os modos de operação da rede, para que se possa realizar uma comunicação

CAPITULO 2


multiponto equilibrada. Não existe especificação nem recomendação ao nível do protocolo nesta norma. Assim, várias opções de protocolos de software estão disponíveis. Os protocolos mais conhecidos que usam o meio físico segunda a norma RS485, são o Modbus e o Profibus. As suas grandes vantagens como a velocidade que pode ir até aos 10Mbps, uma distância de comunicação até 1000 metros e sua imunidade ao ruído, fazem deste um meio de comunicação robusto e que, juntamente com a sua simplicidade, fazem com que norma RS-485 seja amplamente utilizada em projectos electrónicos de comunicação. A norma RS-485 indica que cada um dos nós conecta-se à linha de transmissão formando uma cadeia conhecida como topologia barramento (Bus). Pelas suas características físicas, este tipo de topologias é a mais simples que se pode implementar. Em contraste com os baixos requerimentos em hardware, o desenvolvimento do software implica o desenvolvimento de procedimentos de detecção de colisões e regras de arbitragem. A interface com a topologia do tipo barramento, pode ser desenhada para uma comunicação simultânea em ambos os sentidos (full-duplex) ou num sentido de cada vez (half-duplex).

2.6.3 Barramento USB

Definindo de forma bastante simplificada, USB é um protocolo de comunicação que suporta transferência de dados entre computadores e periféricos. A tecnologia USB (do Inglês, Universal Serial Bus), é uma tecnologia que tornou mais simples, fácil e rápida a conexão de diversos tipos de aparelhos (câmaras digitais, discos rígidos externos, pendrives, ratos e teclados, leitores de MP3, impressoras, scanners, leitor de cartões, etc) a um computador ou dispositivo electrónico, evitando assim a utilização de um tipo específico de conector para cada dispositivo (Alecrim, E., 2011). Esse protocolo é desenvolvido por grandes líderes industriais com o intuito de torná-lo uma norma definitiva para comunicação de periféricos. O barramento USB pode ser utilizado para fornecer energia eléctrica a determinados dispositivos. Para que isso seja possível, os cabos USB contam com quatro fios internos: VBus (VCC), D+, D- e GND. O primeiro e o quarto são os responsáveis pela alimentação eléctrica. O segundo e o terceiro são utilizados na transmissão de dados. Para esta norma existem os quatro tipos de conectores, tal como podemos verificar na Figura 6 (Alecrim, E., 2011).

Figura 6 - Tipos de conectores USB (Alecrim, E., 2011).

O conector do tipo USB A é o mais utilizado na maioria dos computadores e dispositivos de armazenamento de dados. O tipo USB B para dispositivos de maior porte e normalmente com alimentação externa, como impressoras. O tipo mini-USB e micro-USB em dispositivos de menor porte, como leitores de MP3 e telemóveis. O protocolo USB é um barramento mestre/escravo onde o mestre é o USB Host e o escravo o USB Device. O mestre da rede toma conhecimento da inserção e do

ESTADO DA ARTE

20

desligamento dos dispositivos, inicia o processo de enumeração e comanda todas as transacções subsequentes no barramento. É da sua responsabilidade também colectar os estados e as estatísticas de cada periférico.

2.7 Conclusões

Após esta pesquisa do estado da arte relativa às tecnologias abordadas neste projecto a primeira conclusão que se obtém é que a arquitectura ARM e os sistemas operativos de tempo-real são tecnologias afirmativas na implementação de um sistema embebido para automação industrial. A prova disso é a quantidade de fabricantes de processadores com uma das variantes da arquitectura ARM e o exponencial crescimento dos sistemas operativos com características de tempo-real. Os sistemas RTOS garantem uma quantidade de requisitos essenciais a uma aplicação de automação industrial. No entanto em automação industrial existem vários sistemas interligados, o que torna necessário um sincronismo temporal entre os diversos elementos. A norma IEEE1588 garante este sincronismo sem recursos elevados. As soluções baseadas no kernel Linux e nas aplicações GNU aparecem nesta realidade como uma confiável solução tanto para os RTOS, como para a arquitectura ARM.

CAPITULO 3


3 DESENVOLVIMENTO DA PLATAFORMA DE HARDWARE

Este capítulo apresenta todas as fases do projecto de hardware e também as características técnicas do equipamento desenvolvido. São definidos e apresentados os principais periféricos, os barramentos, as interconexões, etc. Por se tratar de um projecto de desenvolvimento de hardware, vários conceitos de electrónica, de software de desenho de circuitos impressos e de projecto e produção de placas de circuito impresso são apresentados. Este capítulo está organizado da seguinte forma:

• Subcapítulo 3.1: Algumas considerações sobre o desenho de circuitos impressos;

• Subcapítulo 3.2: Consideração sobre software de desenho de hardware (EDA);

• Subcapítulo 3.3: Levantamento de requisitos;

• Subcapítulo 3.4: Pesquisa de mercado;

• Subcapítulo 3.5: Especificações do projecto;

• Subcapítulo 3.6: Arquitectura do projecto;

• Subcapítulo 3.7: Desenvolvimento do módulo “MAIN BOARD”;

• Subcapítulo 3.8: Desenvolvimento do módulo “CPU BOARD”;

• Subcapítulo 3.9: Produção das placas de circuito impresso;

• Subcapítulo 3.10: Especificações técnicas do equipamento;

• Subcapítulo 3.11: Configurações do equipamento;

• Subcapítulo 3.12: Aspecto final do equipamento desenvolvido.

• Subcapítulo 3.12: Conclusões

3.1 Desenho de circuitos impressos

Este subcapítulo aborda os aspectos relacionados com o desenvolvimento do hardware propriamente dito. O projecto dos circuitos electrónicos, os requisitos dos sistemas, os fenómenos eléctricos associados aos circuitos electrónicos, o ruído, as capacidades parasitas e outras questões associadas aos circuitos são considerados. Em desenho e projecto de hardware, é sempre possível e até mesmo comum, independentemente do grau de experiência do projectista, a ocorrência de um mau funcionamento do circuito, embora este possa aparentemente apresentar um projecto de circuito “perfeito”. Muitas vezes, o responsável por ocorrências deste tipo é o ruído de interferência por acoplamento electromagnético ou por descargas electrostáticas.

3.1.1 Interferências electromagnéticas

Em primeiro lugar, existem dois tipos de ruídos presentes em qualquer circuito electrónico, os que são gerados internamente pelo próprio funcionamento do equipamento e os causados por elementos externos e que interferem no circuito alvo. Assim, as fontes de ruído podem ser:

DESENVOLVIMENTO DA PLATAFORMA DE HARDWARE

22

• Ruídos internos: Os ruídos gerados pelo próprio equipamento ocorrem em geral devido a fontes de alimentação comutadas inadequadas ou mal projectadas, condensadores de desacoplamento insuficientes, capacidades parasitas entre pistas paralelas, comutações em altas frequências, para além do ruído aleatório denominado de ruído térmico, gerado pelos componentes passivos;

• Ruídos externos: Os ruídos gerados externamente ocorrem normalmente devido a elementos próximos do equipamento como accionamentos mecânicos, comutação de relês, transmissores de rádio frequência, indutâncias parasitas nos fios de alimentação, descargas eléctricas e interferências causadas pelo funcionamento de motores.

Os efeitos provocados por exemplo por indução magnética e capacidades parasitas, são tanto mais prejudiciais ao bom funcionamento do equipamento quanto maior for o percurso que os sinais que o geram percorrem na placa. Por isso, uma estratégia aconselhável no desenho de circuitos impressos é a disposição de planos de massa onde for possível. Estes planos, que são o caminho de retorno preferenciais para a maioria dos sinais no circuito, diminuem as correntes de malha (do Inglês, loop

currents) no circuito e consequentemente o ruído que estas correntes geram. Nas linhas de alimentação, dado que não é possível minimizar o comprimento destas linhas, e uma vez que têm que chegar a todos os circuitos integrados do circuito electrónico para alimentar cada um deles, sugere-se que seja colocado um condensador de desacoplamento o mais próximo possível dos pinos de alimentação. Estes condensadores, além de garantir um caminho para a massa de baixa impedância para o ruído, ainda ajudam a disponibilizar as correntes necessárias nas mudanças de estado lógico dos mesmos. Outra prática sugerida é a utilização sempre que possível de reguladores na própria placa que permitem assim um melhor isolamento dos circuitos internos de ruídos das fontes externas.

3.1.2 Descargas electrostáticas

Um indivíduo pode facilmente ter um potencial electrostático de até centenas de volts, no seu corpo, com uma baixa capacidade de geração de corrente. Porém, pode causar danos irreversíveis aos circuitos integrados e outros componentes electrónicos, especialmente os baseados em tecnologia CMOS. Uma solução possível para este problema, é a colocação de um circuito seguidor de tensão (do Inglês, buffer), que isola os circuitos críticos. Um circuito seguidor de tensão é um amplificador de ganho unitário usado para isolar e interligar um estágio de alta impedância de saída a uma carga de baixa impedância de entrada. Além da maior resistência do seguidor de tensão às descargas electrostáticas, mesmo que uma linha deste se danifique, serve de “fusível” que protege os pinos de circuitos críticos, como memórias ou processadores, e a sua substituição será mais simples e económica. Devido ao nível de integração, consequência da reduzida dimensão da placa, esta técnica não foi largamente usada. No entanto, fica aqui a nota sobre esta boa prática.

3.1.3 Desenho de placas de circuito impresso

Em circuitos integrados, especialmente os que funcionam em altas frequências, neste projecto, o microcontrolador e as memórias SDRAM, há efeitos que precisam ser considerados. As linhas que ligam o circuito têm de ser entendidas como linhas de transmissão sujeitas à necessidade de adaptação

CAPITULO 3


de impedâncias e à ocorrência de reflexões e outros efeitos prejudiciais. É necessário especial cuidado no desenho destas linhas. Por este motivo, apesar de existirem no mercado diversos aplicações de software para desenho automático de linhas de circuitos impressos (auto-routing), capaz de diminuir drasticamente o tempo de desenho de uma placa, muitos projectistas de hardware aconselham que, pelo menos para aquelas ligações consideradas mais críticas, seja feito manualmente, com o objectivo de garantir um melhor desempenho e menos interferência. As principais considerações a ter são:

• Linhas de maior frequência e sinais de relógio: O comprimento destas linhas deve ser o mais curto possível e um plano de massa deve envolver as mesmas;

• Outras linhas: Evitar sempre curvas de 90º em todas as ligações. Curvas acentuadas fazem com que os sinais verifiquem um aumento de resistência devido ao estreitamento provocado pela curva e uma variação de impedância que resulta em reflexões do sinal.

3.1.4 Debug de hardware

Um assunto muito interessante no desenvolvimento de sistemas embebidos é a capacidade de identificação de problemas e detecção do funcionamento inapropriado dos circuitos electrónicos. Diferente do desenvolvimento de software para o qual existem ferramentas especializadas de debug que permitem execução passo a passo, monitorização de variáveis e registos, problemas relacionados ao funcionamento do hardware, apresentam em geral múltiplas possibilidades de causas e poucas ferramentas sistemáticas de identificação. A técnica para debug de hardware consiste em validar circuito a circuito de forma independente e não cair no erro de testar todo o equipamento ao mesmo tempo. Assim, no projecto de um primeiro protótipo, deve-se deixar a possibilidade de separar fisicamente circuitos críticos, colocando resistências de valor zero, que serão soldadas à medida que se vai validando os circuitos, ou mesmo fusíveis ou jumpers em série entre os circuitos. Esta técnica foi usada neste projecto sempre que possível.

3.2 Software de desenho de hardware (EDA)

As aplicações de software de desenho de hardware, designados por EDA (do Inglês, Electronic Design Automation) têm sido uma forte contribuição para o desenvolvimento de sistemas embebidos. São essencialmente um conjunto de ferramentas focadas no projecto, concepção, simulação e produção de equipamentos electrónicos, abrangendo desde o projecto de circuitos impressos até ao desenho e análise de circuitos integrados. Actualmente, as ferramentas mais avançadas permitem uma integração 3D dos componentes, permitindo uma validação física da geometria, bem como a validação das fixações, das caixas, etc. Anteriormente a estas ferramentas de software, os circuitos impressos eram desenhados manualmente ou em ferramentas de desenho assistido por computador CAD (do Inglês, Computer-Aided Design) genéricas. Nos anos 70 começaram a surgir as primeiras ferramentas de EDA resultantes de trabalhos académicos e nos anos 80 surgiram as primeiras ferramentas comerciais.


24

3.2.1 Software “ Altium Designer”

Altium Limited é uma empresa de software Australiana que desenvolve software profissional para o desenho de equipamentos electrónicos desde 1985. Até 2001 a empresa designava-se Protel, nome que também era atribuído ao seu software até então. A partir de 2001, o seu software de EDA passou a designar-se Altium Designer (Figura 7). Este fornece ao projectista de equipamentos electrónicos todos os recursos avançados necessários para atender os requisitos de desenho de circuitos electrónicos complexos. As principais características são:

• Esquemático intuitivo: Folhas múltiplas e esquemas hierárquicos permitem uma estruturação de projectos de forma intuitiva e lógica;

• Simulação: Modo de simulação de esquemas, incluindo simulação de circuitos analógicos, circuitos lógicos e mesmo microprocessadores;

• PLD e FPGA: Projecto, desenho e simulação de dispositivos lógicos programáveis, as PLD (do Inglês, Programmable Logic Devices) e de circuitos integrados que normalmente se designam como hardware programável, as FPGA (do Inglês, Field-Programmable Gate Array);

• Desenho de linhas automático: Desenho automático das linhas de placas de circuito impresso (do Inglês, auto-routing), tendo em conta as especificações do esquemático e as regras definidas para a placa electrónica;

• Analise e verificação: Incorpora um conjunto de funcionalidades que, quando devidamente configuradas e parametrizadas, permitem analisar e verificar os projectos, quer ao nível do esquemático e placa de circuito impresso, quer como à correspondência entre os dois;

• Integridade de sinais: Simulação de integridade de sinais, segundo regras definidas pelo utilizador, como por exemplo, comprimento de linhas, distância entre linhas, tamanho dos furos de ligação entre camadas (vias), etc;

• Gestão documental: Gestão integrada de documentos relativos ao desenvolvimento, simulação e produção;

• Ficheiros de produção: Gera todo o tipo de ficheiros para produção, quer para fabrico de circuitos impressos (gerber files), máquinas de colocação automática de componentes (pick-and-place files), ponto de teste (test-point files) e ficheiros de furação (nc-drill files);

• Trabalho em equipa: Permite vários utilizadores trabalharem no mesmo projecto ao mesmo tempo, essencial para projectos de grande dimensão;

• Integração mecânica: Integração e validação mecânica, importando e exportando ficheiros no formato nativo 3D (step files);

• Ligação a revendedores: Permite ligar os vários componentes das bibliotecas internas a sites de revenda, como a Farnell Components, S.L. e a Digi-Key Corporation, para que as listas de material, BOM (do Inglês, Bill-Of-Materials) apresentem valores aproximados de custos de material.

CAPITULO 3


Figura 7 - Ambiente integrado do software Altium Designer.

O fabricante fornece uma excelente documentação gratuita, incluindo manuais e vídeos, na sua página oficial da Internet, mais especificamente na seguinte hiperligação:

• http://www.altium.com/training/

O Altium Designer também é disponibilizado de forma gratuita, no formato de trial de 30 dias, disponível na seguinte hiperligação:

• http://www.altium.com/evaluate/en/self-evaluate.cfm#trial

3.2.2 Software “ Altium Designer Viewer”

A aplicação de visualização aumenta a capacidade de intercâmbio de dados, mesmo para quem não tiver o software Altium Designer. Este software fornece uma rápida, fácil e segura exploração de projectos e documentos que foram criados usando o Altium Designer, no modo só de leitura. Os utilizadores podem visualizar, imprimir e interrogar todos os aspectos de um projecto. Este software não só melhora a colaboração dentro de uma organização, mas também entre as equipas de desenho e os colaboradores externos, melhorando consideravelmente o fluxo de trabalho e produtividade do projecto. Esta aplicação gratuita pode ser instalada em qualquer computador e encontra-se disponível na página da empresa na seguinte hiperligação:

• http://www.altium.com/community/downloads/viewer-edition.cfm

3.3 Levantamento de requisitos

Os requisitos do equipamento desenvolvido neste projecto foram identificados após várias pesquisas e estudos. As principais conclusões desta etapa foram compiladas em três relatórios de progresso do projecto, elaborados no decorrer do mesmo e apresentadas neste subcapítulo.


26

Os requisitos ao nível do processamento foram especificados como sendo os necessários para executar o kernel Linux, algumas aplicações GNU e ainda os necessários para implementar uma arquitectura de tempo-real. Ao nível de memória considerou-se que o equipamento deveria ter no mínimo 32MB de memória RAM disponível para o processador. O software do sistema e o sistema operativo pretendia-se que fossem guardados numa memória estática, tecnologia FLASH, integrada no equipamento e/ou numa memória externa USB ou cartão de memória. Ao nível de comunicação com o ambiente externo, foi especificado que estivessem disponíveis algumas entradas e saídas digitais, um barramento de comunicação de campo, CAN e/ou RS485 e um protocolo de comunicações para redes industriais Ethernet, com a norma IEEE1588. Estas portas para o exterior serão em parte decididas tendo em conta a escolha da caixa e a forma mecânica da mesma. A caixa para o equipamento foi especificada para ter encaixe num suporte em calha DIN NS35, o standard da indústria da automação, e ter a possibilidade de criar um barramento, em que fosse possível interligar outros módulos. Assim, pretende-se criar um equipamento modular, com possibilidade de acrescentar módulos, igualmente em calha DIN, e “pendurados” no barramento de campo escolhido. Na instalação pretende-se algo como o esquema da Figura 8.

Figura 8 – Esquema de uma plataforma modular em calha DIN.

No entanto, este projecto centra-se no desenvolvimento do equipamento mestre (master) da plataforma e na definição e implementação do barramento. Assim, esta plataforma seria semelhante em termos de implementação física a um autómato industrial genérico. Ao nível dos requisitos não funcionais, especificou-se que o custo de produção devia ser o mais baixo possível, o consumo de energia também o mais baixo possível e o interface com o utilizador seria por meio de alguns LEDs, para indicar o estado de funcionamento do equipamento e alguns botões de pressão. Por fim, o equipamento desenvolvido neste projecto foi especificado como sendo uma solução para automação industrial e também como uma plataforma de desenvolvimento nas áreas de estudo que cobrem este projecto.

CAPITULO 3


3.4 Pesquisa de mercado

Uma das primeiras tarefas quando se pretende desenvolver um equipamento ou um

produto novo é a pesquisa da oferta do mercado. Deve-se sempre verificar o que se encontra

disponível, quais as tendências de mercado na área em questão e custos de aquisição de

tecnologia. Assim, foram feitas várias pesquisas de módulos para integração, que satisfaziam

os requisitos mínimos do projecto e também placas de desenvolvimento que permitissem

adquirir conhecimentos nas áreas abordadas. Serão apresentadas quatro soluções para

integração e quatro soluções para placas de desenvolvimento. Esta pesquisa mostra a

diversidade de fabricantes que implementam a arquitectura ARM nos seus microcontroladores.

Em oito amostras de produtos seleccionados existem cinco fabricantes diferentes, a Samsung,

a ATMEL, a NXP, a Cirrus Logic e por último a Texas Instruments, o que mais uma vez

demonstra a versatilidade de se usar a arquitectura ARM.

3.4.1 Soluções para integração

A primeira solução é um dos módulos de integração da família de produtos FriendlyARM. Estes produtos são desenvolvidos por uma empresa Alemã, a Pengutronix e.K. e uma empresa Americana, a Dajac Inc (Tabela 2).

Característica Descrição Imagem Referência Micro2440

Figura 9 - Módulo de integração "Micro2440".

Fabricante FriendlyARM

Url http://www.friendlyarm.net

Fornecedor http://www.watterott.com

MCU S3C2440A da Samsung

Núcleo ARM ARM920T

Frequência de relógio máxima

533 MHz

RAM 64 MB SDRAM, 32 bit 100 MHz Bus

Flash 64 MB NAND Flash e 2 MB NOR Flash com BIOS

Dimensões 63 mm x 52 mm

Custo unitário 35,70€

Tabela 2 - Características do módulo para integração "Micro2440 (FriendlyARM, 2011a)".


28

A segunda solução é o módulo de integração desenvolvido pela empresa Italiana ACME SYSTEMS srl. Este fornecedor apenas tem esta solução, com um conjunto de acessórios (Tabela 3).

Característica Descrição Imagem Referência Netus G20

Figura 10 - Módulo de integração "Netus G20".

Fabricante Acme Systems

Url http://www.acmesystems.it

Fornecedor http://eshop.acmesystems.it/?id=FOXG20

MCU AT91SAM9G20 da ATMEL

Núcleo ARM ARM926EJ-S


400 MHz

RAM 64MB de SDRAM

Flash 8MB (16GB microSD com possibilidade de boot)

Dimensões 40mm x 40mm

Custo unitário 69.00€

Tabela 3 - Características do módulo para integração " Netus G20 (AcmeSystems, 2011)".

A empresa da Bulgara OLIMEX Ltd, disponibiliza um conjunto diverso de módulos e plataformas de desenvolvimento na arquitectura ARM. O módulo seguinte é umas das soluções deste fabricante (Tabela 4).

Característica Descrição Imagem Referência LPC-H3131

Figura 11 - Módulo de integração " LPC-H3131".

Fabricante OLIMEX

Url http://www.olimex.com

Fornecedor http://www.olimex.com/dev/index.html

MCU LPC3131 da NXP



180 MHz

RAM SDRAM 32MBytes

Flash 512MBytes



Tabela 4 - Características do módulo para integração "LPC-H3131 (OLIMEX, 2011a)".

CAPITULO 3


A quarta solução é um dos módulos de integração da empresa Chinesa Embest Info&Tech Co. Esta empresa apresenta um vasta gama de produtos, desde módulos de integração, placas de desenvolvimento, programadores e debuggers, ferramentas de software, etc (Tabela 5).

Característica Descrição Imagem Referência LPCEB2000-B

Figura 12 - Módulo de integração "LPCEB2000-B".

Fabricante Embest Info&Tech Co

Url http://www.embedinfo.com/en/index-en.html

Fornecedor http://www.embedinfo.com/english/Product/lpc2000b.asp

MCU LPC2000 da NXP

Núcleo ARM ARM7TDMI-S


60 MHz

RAM 512K x 16 Bit SRAM

Flash 1M x 16 Bit Flash



Tabela 5 - Características do módulo para integração "LPCEB2000-B (Embest Info, 2011a)".

As quatro soluções de módulos para integração são muito semelhantes ao nível de desenho mecânico, apresentando uma forma rectangular e bastante compacta. No entanto, ao nível de interligação eléctrica, enquanto três utilizam ligação por barras de pinos normais, o módulo "Netus G20" utiliza uma ficha específica muito utilizada em módulos deste tipo, no entanto muito dispendiosa. Os módulos "Netus G20", "Micro2440" e "LPC-H3131" têm a vantagem de os seus fabricantes disponibilizarem para venda na sua loja online no site oficial da Internet, um conjunto de acessórios como placas de desenvolvimento para estes módulos, fontes de alimentação, caixas para os módulos, entre outros. O fabricante do módulo "Micro2440" disponibiliza ainda outros acessórios para as placas de desenvolvimento, como por exemplo câmaras de vídeo, ecrã gráfico (TouchScreen), conversores de sinais de vídeo VGA, etc. Este fornecedor, FriendlyARM, apresenta uma interessante linha de módulos e placas de desenvolvimento, não só para ARM9 como também ARM11 e ARM CORTEX-A8. O módulo LPCEB2000-B foi seleccionado nesta pesquisa por ser uma solução ARM7 e por ter um microcontrolador da NXP, diferenciando-se dos outros três e apresentando recursos de processamento e memória abaixo dos outros. Assim, para aplicações com menos exigências este módulo pode ser uma boa solução. No entanto, o seu fabricante, a Embest Info&Tech, tal como a FriendlyARM, disponibilizam um enorme conjunto de soluções, desde ARM7, ARM9, ARM11 e CORTEX A8 e ainda um conjunto extenso de acessórios para os seus produtos.


30

3.4.2 Placas de desenvolvimento

A primeira placa de desenvolvimento seleccionada é da OLIMEX Ltd, e foi seleccionada por apresentar uma arquitectura muito semelhante à deste projecto (Tabela 6).

Característica Descrição Imagem Referência 909-CS-E9302

Figura 13 - Placa de desenvolvimento "909-CS-E9302".

Fabricante OLIMEX

Url http://www.olimex.com/

Fornecedor http://www.olimex.com/

MCU EP9302 da Cirrus Logic

Núcleo ARM ARM920T


200 MHz

RAM SDRAM 32MB, 133 MHz Bus

Flash 16MB


Tabela 6 - Características da placa de desenvolvimento "909-CS-E9302 (OLIMEX,

2011b)".

A segunda placa de desenvolvimento é uma das boas soluções da FriendlyARM. Devido às características deste projecto não foi seleccionada uma solução com display, no entanto esta placa tem interface para display e saída VGA (Tabela 7).

Característica Descrição Imagem Referência Mini2440

Figura 14 - Placa de desenvolvimento " Mini2440".

Fabricante FriendlyARM

Url http://www.friendlyarm.net

Fornecedor http://www.watterott.com

MCU S3C2440A da Samsung

Núcleo ARM ARM920T


533 MHz

RAM 64 MB SDRAM, 32 bit 100 MHz Bus

Flash 256 MB NAND Flash e 2 MB NOR Flash com BIOS

Custo unitário 86,96€

Tabela 7 - Características da placa de desenvolvimento "Micro2440 (FriendlyARM,

2011b)".

CAPITULO 3


A terceira solução é da Embest Info&Tech Co, e foi seleccionada por ter um microcontrolador da mesma família que o deste projecto, a AT91SAM da ATMEL (Tabela 8).

Característica Descrição Imagem Referência EB-SAM9G45

Figura 15 - Placa de desenvolvimento " EB-SAM9G45".

Fabricante Embest Info&Tech Co

Url http://www.embedinfo.com/en/index-en.html

Fornecedor http://www.embedinfo.com/en/list.asp?id=99

MCU AT91SAM9G45 da ATMEL



400 MHz

RAM 64MB DDR2 SDRAM

Flash 256MB NandFlash, 2MB NorFlash, 4MB DataFlash

Custo unitário 255€

Tabela 8 - Características da placa de desenvolvimento "EB-SAM9G45 (Embest Info,

2011a)".

A quarta placa de desenvolvimento, é da empresa americana Texas Instruments, e permite desenvolver competências num microcontrolador baseado em arquitectura ARM, bem como no driver Ethernet com a norma IEEE1588, ambos da Texas Instruments (Tabela 9).

Característica Descrição Imagem Referência EK_LM3S8962

Figura 16 - Placa de desenvolvimento "EK_LM3S8962".

Fabricante Texas Instruments

Url http://www.ti.com/tool/ek-lm3s8962

Fornecedor http://www.aliexpress.com/fm-store/206148/210950214-433319774/TI-ARM-Cortex-M3-LM3S8962-Development-Board-Network.html

MCU LM3S8962

Núcleo ARM Contex M3


50 MHz

RAM 256-KB

Flash 256-KB

Custo unitário 55€

Tabela 9 - Características da placa de desenvolvimento "EK_LM3S8962 (TI, 2011)".


32

As placas de desenvolvimento "909-CS-E9302", "Mini2440" e "EB-SAM9G45" apresentam microcontroladores baseados na arquitectura ARM9, diferenciando-se a velocidade de processamento e as unidades de memória instaladas. Estas três placas de desenvolvimento são fornecidas com documentação (esquemáticos, manual de utilização, exemplos de aplicação para os periféricos) e imagens do kernel Linux já compiladas com os drivers para a respectiva arquitectura de hardware. O fornecedor FriendlyARM, disponibiliza também para as suas placas de desenvolvimento e módulos de integração, imagens compiladas de WindowsCE e de distribuições baseadas no kernel Linux com interface gráfico como o Android e Qtopia. Este fornecedor sediado na Alemanha e EUA, tem visto os seus produtos ter uma grande aceitação pelo mercado, pela sua qualidade e diversidade, elevada qualidade e quantidade de documentação e ainda pelos preços reduzidos.

Por fim, a placa de desenvolvimento da Texas Instruments, com a referência "EK_LM3S8962", foi selecciona por ser a única placa de desenvolvimento com arquitectura ARM e com hardware que possibilita a implementação da norma IEEE1588, disponível no mercado, à data da elaboração deste documento. Esta placa têm o microcontrolador Stellaris LM3S8962 ARM CORTEX M3, igualmente da Texas Instruments, que tem integrado o driver físico para a rede Ethernet e o driver físico CAN. Não sendo necessários os circuitos integrados de driver para o meio físico, este microcontrolador é uma boa solução para sistemas periféricos, que necessitem de característica de tempo-real, mas que não necessitem de um sistema operativo nativo. Ainda assim é disponibilizado pelo fabricante uma versão compatível para a placa do pequeno sistema operativo de tempo-real FreeRTOS. O FreeRTOS é um kernel de tempo-real ou escalonador de tempo-real. Com o FreeRTOS aplicações baseadas na arquitectura ARM ou noutra, podem ser construídas para satisfazer exigências de tempo-real e para que as aplicações possam a ser organizadas como um conjunto de linhas de execução, designadas por tarefas, executadas de forma independente. O kernel decide qual tarefa deve ser executada, examinando a prioridade atribuída à mesma (Barry, R., 2010). No entanto, as suas funcionalidades de alto nível e os drivers disponíveis são ainda limitados, apesar deste RTOS poder ser executado num grande número de arquitecturas diferentes, sendo portanto uma hipótese a considerar para pequenos sistemas.

CAPITULO 3


3.5 Especificação

Após um levantamento dos requisitos do sistema e de uma pesquisa do mercado, o equipamento desenvolvido neste projecto seguiu as especificações, apresentadas na Tabela 10.

Característica Especificação CPU Processador de 32 bits

Arquitectura do CPU Arquitectura ARM, velocidade de processamento de pelo menos 200 MIPS

Comunicações Industriais

RS485, CAN, USB Host ,USB Device e Ethernet (IEEE1588)

Memória dinâmica RAM no mínimo 32MB PC100

Memória estática FLASH, no mínimo 64MB

Programação e debug RS232 e USB

Alimentação 24VDC

Entradas digitais Mínimo 4

Saídas digitais Mínimo 4

Entradas analógicas Mínimo 2

Caixa Suporte para calha DIN NS35 e interligação para um barramento entre módulos

Tabela 10 - Tabela de especificações do equipamento.

3.6 Arquitectura

Esta secção descreve a arquitectura que foi implementada, detalhando a escolha dos componentes e módulos principais. Pretendendo-se desenvolver um equipamento que será uma solução para automação industrial, mas também um equipamento que pode ser utilizado para desenvolvimento de competências nas áreas de estudo deste projecto, optando por dividir o equipamento em duas placas electrónicas. Uma placa com a fonte de alimentação, circuitos de driver para as comunicações de campo (RS485 e CAN), entradas e saídas digitais, entradas analógicas e cartão de memória, denominada por "MAIN BOARD". A outra placa contendo todo o processamento, memórias, comunicações Ethernet e USB e que se denominou como "CPU BOARD". Ambas as placas contêm LEDs e botões de uso genérico e a placa "MAIN BOARD" contêm ainda LEDs indicadores do estado da alimentação. A interligação entre as duas placas é efectuada com fichas de pinos genéricas. A Figura 17 mostra um diagrama do equipamento, conforme descrito nos parágrafos anteriores.


34

Figura 17 - Diagrama do equipamento.

A escolha dos componentes foi ponderada, segundo os requisitos apresentados anteriormente e nos seguintes pontos, que se incorporam nos requisitos não funcionais:

• Preço dos componentes: Pretende-se desenvolver um produto acessível, logo a escolha dos componentes deve sempre considerar o preço dos mesmos;

• Disponibilidade: Nesta fase era importante escolher componentes acessíveis pelos distribuidores de electrónica online, para evitar tempos de entrega elevados;

• Facilidade de montagem: Optou-se sempre por componentes que sejam possíveis de soldar com equipamentos manuais, facilitando e reduzindo os custos na montagem de protótipos.

3.6.1 Processamento

Qualquer dispositivo electrónico inteligente, desde um relógio de pulso até um computador, precisa de um “cérebro electrónico” que faça o processamento das informações e execute os programas do utilizador. Esse “cérebro” é o processador (GEEK, 2011). Ao nível do processamento, a arquitectura ARM foi a única imposição à partida para este projecto, devida ao inúmero conjunto de vantagens desta tecnologia, que foram apresentadas anteriormente neste documento. No entanto, a tarefa mais difícil seria escolher a versão do núcleo ARM, a família e por fim o fabricante. Sendo o principal objectivo deste projecto desenvolver uma plataforma de hardware com capacidade para executar o kernel Linux, a existência de uma unidade de gestão de memória (MMU) foi uma outra exigência. Assim, e também considerando uma das características dos sistemas embebidos, que é a utilização do mínimo de recursos, a opção pela arquitectura ARMv5, apresentou o melhor compromisso entre as exigências do projecto. Após um longo trabalho de pesquisa, a opção foi para um microcontrolador do fabricante ATMEL, da família de microcontroladores AT91SAM, modelo AT91SAM9XE512. Este microcontrolador integra um núcleo ARM da família ARM9XE, versão da arquitectura é ARMv5TEJ e o núcleo é um ARM926EJ-S (Figura 18).

CAPITULO 3


Figura 18 – Módulos do microcontrolador SAM9XE da ATMEL.

A AT91SAM é uma família de microcontroladores do fabricante ATMEL, baseados na arquitectura ARM. Alguns são direccionados como processadores para aplicações, com barramento de memória externa usado para acesso à memória RAM (SDRAM ou DDR2) e FLASH, e um grande conjunto de periféricos integrados. Quando segmentados como microcontroladores incluem memórias integrada FLASH e SRAM, juntamente com uma série de periféricos, comunicações normalizadas e interfaces de rede. Isso os qualifica como sistemas num circuito electrónico (do Inglês, System On a Chip). Esta designação atribui-se a um circuito integrado que integra todos os componentes de um computador ou outro sistema electrónico num único circuito integrado. A família AT91SAM é constituída por microcontroladores baseados em ARM7, ARM9, ARM11 e ainda algumas versões em Cortex-M3, como podemos verificar na Figura 19.

Figura 19 - Família AT91SAM da ATMEL (Embest Info, 2011c).


36

Todos os microcontroladores da família AT91SAM, integram a possibilidade de programar toda a memória FLASH interna e/ou externa e os bits de configuração sem hardware adicional, via comunicação USB ou porta série. O software necessário pode ser utilizado em ambiente Linux ou Windows e encontra-se disponível de forma gratuita na página da Internet da ATMEL. A AT91SAM9260, foi a primeira gama de microcontrolador do mercado, baseado na arquitectura ARM9, que partilha o mesmo modelo de programação que microcontroladores baseados na arquitectura ARM7, permitindo uma migração directa entre vários microcontroladores do fabricante ATMEL, com diferentes núcleos ARM. A família AT91SAM9260 também suporta determinismo, operações de tempo-real, oferece funções de supervisão e suporte da comunidade AT91SAM para sistemas operativos de tempo-real em Linux embebido e Windows embebido. Em 2007 a ATMEL introduziu os primeiros microcontroladores baseados no AT91SAM9260, chamado SAM9XE, com até 512KB de FLASH integrada (MSC, 2011). A AT91SAM9XE é a primeira família de microcontroladores baseados no ARM9 com memória FLASH integrada. Todos os microcontroladores da família são compatíveis ao nível dos pinos (pin-compatible), e são quase 100% compatíveis com os microcontroladores AT91SAM9260 sem memória FLASH integrada e com o AT91SAM9G20 que é uma versão que pode funcionar até 400MHz. A memória FLASH integrada pode, no máximo, ter uma capacidade de até 512KB (Figura 20).

Figura 20 – Gama de microcontroladores da série SAM9260/9XE da ATMEL (MSC, 2011).

Os microcontroladores AT91SAM9XE128/256/528 são baseados no núcleo ARM926EJ-S, com 16KB de instruções e 8 KB de memória de cache. Este funciona a 200MIPS com 180 MHz de frequência de relógio. Possuí até 32KB de SRAM e 32KB de ROM com acesso num único ciclo na velocidade máxima do processador ou barramento, juntamente com uma interface de barramento externo com controladores para SDRAM e memórias estáticas incluindo NAND FLASH e COMPACT FLASH. O expansivo conjunto de periféricos inclui múltiplas interfaces de rede e conectividade integradas como o USB Host Full Speed e USB Device Full Speed, 10/100 Base T Ethernet MAC, Interface para sensor de imagem, interface para cartão de memória (compatível com SDCard/SDIO e MultiMediaCard), controlador série síncrono (SSC), quatro USARTs, dois interfaces de periféricos série (SPI), uma porta USART para debug, dois interfaces I2C (TWI), quatro canais ADC de 10 bits, entre outros (Figura 21).

CAPITULO 3


Figura 21 - Diagrama de blocos da série AT91SAM9XE (MSC-GE, 2011).

3.6.2 Memórias

Em consequência dos requisitos do projecto este equipamento será equipado com memória volátil e não volátil, para guardar diferentes tipos de dados. As memórias voláteis perdem os dados quando não têm alimentação e serão usadas pelo processador. As memórias não voláteis são memórias que guardam os dados mesmo quando falha a alimentação. Estas memórias servirão para guardar o próprio sistema operativo, as aplicações e ainda outros dados do equipamento. Ao nível de memórias voláteis foram seleccionadas as memórias da tecnologia SDR SDRAM. As memórias SDR SDRAM vieram para substituir as memórias EDO que não eram sincronizadas e tinham que esperar um tempo fixo, para entregar o dado pedido pelo processador. As memórias SDR SDRAM (do Inglês, Single Data Rate Sincronous Dynamic Random Access Memory), por sua vez, são capazes de trabalhar sincronizadas com os ciclos do processador, sem tempos de espera. Isso significa que a temporização das memórias SDR SDRAM é sempre de uma leitura por ciclo, conseguindo assim enviar 1 dado por pulso de sinal de relógio, tornando as SDR SDRAM mais rápidas que as EDO. Ao nível de velocidade máxima de funcionamento, existem 3 tipos de SDR SDRAM:

• PC66: Funcionam na frequência máxima de 66MHz;

• PC100: Funcionam na frequência máxima de 100MHz;

• PC133: Funcionam na frequência máxima de 133MHz.

A memória SDR SDRAM trouxe ainda outra novidade, em vez de um grande banco de dados unificado, estas dividem-se em 2, 4 ou 8 bancos de memória. Utilizada no Pentium I, II e III e no antigo Athlon, surgiu a necessidade de uma substituta, pela dificuldade de atingir velocidades maiores, tendo sido criada a memória DDR SDRAM (do Inglês, Double-Data-Rate Synchronous Dynamic

Random Access Memory), que consegue enviar 2 dados por pulso de relógio, duplicando assim o


38

desempenho em relação a técnica tradicional de transferência de dados quando operando à mesma frequência de relógio. A memória SDR SDRAM seleccionada é a referência da MT48LC16M16A2P-75:D do fabricante MICRON, e apresenta as seguintes características:

• Capacidade de 32MB por unidade;

• Compatível com PC100 e PC133;

• Configuração de 4 bancos de memória (4Mb x 16);

• Tempo de acesso inferior a 6 ns;

• Caixa de 54 pinos, formato TSOP (do Inglês, Thin small-outline package), que permite que seja soldado com equipamentos manuais.

Ao nível das memórias não voláteis foram seleccionadas as memórias da tecnologia NAND FLASH. Existem dois tipos de memórias FLASH, a NAND e a NOR. A memória FLASH NOR (Not OR) permite aceder aos dados da memória de maneira aleatória, mas com baixa velocidade enquanto a memória FLASH NAND (Not AND) trabalha em alta velocidade, faz acesso sequencial às células de memória e trata-as como conjuntos, isto é, em blocos de células, em vez de aceder de maneira individual. A memória FLASH NAND oferece um tempo de acesso rápido, embora não tão rápido como a memória volátil SDRAM. As maiores vantagens desse tipo de memória é a ocupação mínima de espaço, baixo consumo de energia, alta resistência, durabilidade e segurança, contando com recursos como ECC (do Inglês, Error Correcting Code), que permite detectar erros na transmissão de dados. A tecnologia faz uso de semicondutores, sendo assim, não tem peças móveis, evitando problemas de causa mecânica, como acontece nos tradicionais discos rígidos. O circuito integrado de memória NAND FLASH seleccionado é a referência HY27UF082G2B-TPCB do fabricante HYNIX SEMICONDUCTOR, e apresenta as seguintes características:

• Capacidade de 256 MB por unidade;

• Compatível com barramento de 8 e 16 bits;

• Configuração de 64 paginas x 2048 blocos;

• Tempo de acesso inferior a 20 ns;

• Caixa de 48 pinos, formato TSOP (do Inglês, Thin small-outline package), que permite que seja soldado com equipamentos manuais.

3.6.3 IEEE1588

Um driver para a camada física Ethernet, normalmente denominado por PHYTER (PHYTER-Physical

Layer), com a norma IEEE1588 é muito difícil de encontrar no mercado comercial. Assim, sem muitas opções, foi escolhido a referência DP83640TVV/NOPB do fabricante National Semiconductor, que é o único referido no site especializado na matéria, o NIST (NIST, 2010). O circuito integrado DP83640 oferece um alto nível de sincronização de relógio de precisão, para conectividade de tempo-real em redes industriais, baseado na norma IEEE1588. Este é determinístico, baixa latência e permite que seja utilizado juntamente com um microcontrolador genérico. A funcionalidade integrada IEEE1588, permite um flexível e exacto sincronismo temporal. As suas características principais são:

CAPITULO 3


• Suporta IEEE1588 versão 1 e versão 2;

• Comunicação MII ou RMMI;

• Envio de pacotes com uma marcação temporal (do Inglês, time stamp) para sincronização de relógios;

• Geração integrada de um relógio IEEE1588;

• Sincronização com microprocessador via pinos genéricos I/O;

• Funciona com o meio físico dois pares de fio de cobre e meio físico fibra;

• Funções avançadas de monitorização e diagnóstico da rede;

• LEDs programáveis para o estado da ligação (modo de funcionamento, detecção de colisões e actividade da rede);

• Caixa de 48 pinos, formato LQFP (do Inglês, Low-profile Quad Flat Package), que permite que seja soldado com equipamentos manuais.

A Figura 22 apresenta o diagrama funcional do driver. Neste projecto apenas o meio físico fibra óptica não foi implementado, sendo implementadas todas as outras funcionalidades.

Figura 22 - Diagrama do driver físico para Ethernet DP83640.

3.6.4 Caixa

A caixa escolhida para o equipamento, foi o modelo ME22,5 BUS5, do fabricante PHOENIX

CONTACT. Esta caixa assenta em todas as especificações pretendidas, o que à partida não seria uma exigência fácil, devido especialmente à questão do barramento. Assim, satisfazendo as nossas necessidades, esta caixa tem uma conexão lateral para um barramento com 5 ou 10 ligações, suporte para calha DIN NS35 e várias opções para a tampa frontal. Para o barramento foi seleccionada a opção de 5 ligações e para a tampa frontal foi escolhida a opção de dois andares de ligadores de parafuso, como podemos observar na Figura 23.


40

Figura 23 - Caixa seleccionada para o equipamento.

A existência de vários tipos de tampas frontais e várias larguras e alturas de caixas, compatíveis ao nível de suporte e barramento, é uma mais-valia para esta escolha, especialmente pretendendo que este seja um equipamento modular.

3.7 Desenvolvimento do módulo “MAIN BOARD”

Este módulo é constituído pela fonte de alimentação, driver para as comunicações de campo (RS485 e CAN), circuito das entradas e saídas digitais, circuito das entradas analógicas e circuito do cartão de memória. As ligações ao barramento, à ficha de alimentação e aos terminais da caixa são também efectuadas nesta placa electrónica. Contém ainda dois LEDs e dois botões de uso genérico e dois LEDs indicadores do estado da alimentação.

3.7.1 Fonte de alimentação

Este equipamento pode ser alimentado através de um conector do tipo Jack com um transformador genérico externo ou pelas ligações externas de parafusos da caixa. Ao nível de protecções relativamente à alimentação, o equipamento está protegido contra inversão de polaridade, com um díodo schottky (CR2), uma protecção contra picos de tensão, com um díodo TVS (D2) e uma protecção contra curto circuitos ou excesso de consumo de energia, com o polyswitch (F1). Os condensadores na entrada dos circuitos de alimentação (C8 e C3) servem para atenuar flutuações provenientes da tensão de entrada. O circuito com estas protecções pode ser visualizado na Figura 24.

CAPITULO 3


Figura 24 - Entrada de alimentação e protecções.

A fonte de alimentação foi implementada com três diferentes topologias de circuitos de conversão de níveis de tensão eléctrica, de corrente contínua para corrente contínua (DC/DC). Estes circuitos geram na sua saída um sinal de amplitude diferente da amplitude do sinal de entrada, podendo esse valor ser fixo ou regulável. As três topologias de regulação são as seguintes:

• Fonte comutada (do Inglês, switched-mode);

• Regulador linear (do Inglês, linear low-dropout);

• Bomba de carga (do Inglês, charge pump).

O circuito representado na Figura 25 é um circuito do tipo fonte comutada sendo utilizado para converter a tensão de alimentação externa do equipamento em 5 VDC. Este tipo de circuito integra um circuito que comuta a corrente de saída, ligando e desligando a mesma corrente, em alta frequência, de forma a gerar uma tensão de saída regulada e estabilizada. Este tipo de topologia é a mais eficiente, mas também mais complexa e mais dispendiosa relativamente aos outros dois tipos de circuitos, e as trocas de correntes tendem a produzir interferências electromagnéticas. No entanto, este tipo de circuitos tem uma elevada eficiência, tipicamente entre 80 a 95%. O circuito integrado seleccionado para este circuito é a referência MAX16977 do fabricante MAXIM, sendo um circuito conversor de tensão do tipo fonte comutada redutor (do Inglês, switch mode step-down), capaz de fornecer até 2 A. A frequência de comutação pode ser configurada entre 1MHz e 2.2MHz, por uma resistência externa (R10) e pode ser sincronizada com uma fonte externa de relógio. A saída pode ser ajustável entre 1 VDC e 10 VDC, ou uma tensão fixa de 5 VDC, como é o caso desta implementação. A nível de protecções este circuito integrado está protegido internamente contra sobrecargas de tensão e corrente eléctrica e desliga-se de forma automática quando a sua temperatura interna da junção exceder o seu limiar de funcionamento, recuperando o seu estado igualmente de forma automática. Como este circuito é um dos que pode ser desligado pelo microprocessador, é importante o seu baixo consumo

em modo de stand-by, que é cerca de 30µA. Para obter o esquema do circuito representando na Figura 25, foi seguida a nota de aplicação do fabricante.


42

Figura 25 - Circuito da fonte comutada, saída 5 Volts.

O circuito da Figura 26 é um circuito do tipo regulador linear de baixa queda de tensão e é utilizado para gerar a tensão de 3.3 VDC para a maioria dos circuitos integrados da placa, a partir dos 5 VDC do circuito anterior. Este tipo de circuitos é simples de implementar e tem poucos componentes externos ao regulador. Resumidamente, funciona com o princípio de um divisor de tensão para fornecer a tensão de saída. Um circuito de comparação ajusta o valor da tensão de saída, conforme uma tensão de referência que pode ser fixa ou ajustável, interna ou externa ao regulador. Este tipo de circuitos tem a desvantagem de só permitir descer a amplitude do sinal, e de ser ineficiente visto que a descida da amplitude do sinal é provocada pela queda de tensão no divisor resistivo, logo sendo dissipada em forma de calor.

Figura 26 - Circuito do regulador linear, saída de 3.3Volts.

O circuito da Figura 27, também é um regulador linear e será usado para gerar a tensão de alimentação do módulo de backup do microcontrolador, quando este entra em modo de baixo consumo a tensão de saída deste circuito é de 1.8 VDC, que é a tensão de alimentação do núcleo do microcontrolador. À entrada do regulador existem dois díodos que interligam duas fontes independentes, os 3.3VDC do circuito de alimentação da Figura 26 e uma pequena bateria de lithium CR1225. O objectivo da bateria é garantir que o processador não seja desligado na ausência de alimentação externa. Assim, ele poderá funcionar no modo de baixo consumo, alimentado pela bateria, garantindo o funcionamento do RTC (do Inglês, real-time clock) para que o sistema mantenha a hora actualizada e continue a executar as tarefas críticas sem interrupções.

CAPITULO 3


Figura 27 - Circuito do regulador linear, saída 1.8V e circuito da bateria de reserva (Backup).

Um regulador de tensão do tipo bomba de carga (do Inglês, charge pump), também designado por conversor DC-DC sem bobine (do Inglês, inductor-less DC-DC converter) ou circuito de comutação de carga de condensadores (do Inglês, switched-capacitor circuit) é outra topologia de reguladores que pode ser utilizada para conversão de tensão eléctrica. A tensão de saída deste circuito é de 1.8 VDC, que é a tensão de alimentação do núcleo do microcontrolador (Figura 28). Este tipo de circuitos usa condensadores como elementos de armazenamento de energia, para gerar uma fonte de energia com maior ou menor amplitude de sinal de entrada, tendo uma elevada eficiência, tipicamente entre 90 a 95%. São circuitos simples e com poucos componentes externos. Tal como os circuitos regulares lineares, estes necessitam de poucos componentes externos ao regulador. No entanto, estes circuitos necessitam de condensadores de armazenamento de carga (fly capacitor), neste circuito C5 e C6.

Figura 28 - Circuito do regulador bomba de carga, saída 1.8Volts.

O circuito da Figura 29, permite desligar os diversos circuitos de alimentação, quando o microcontrolador entrar em modo de poupança de energia (sleep), ou quando os circuitos periféricos pendurados nos respectivos circuitos não forem necessários.


44

Figura 29 - Circuito de controlo dos módulos de alimentação.

O circuito da Figura 29 está desenhado de forma que possa ser utilizado com o mesmo sinal de comando do microcontrolador (SHDN_P), para desligar os circuitos com lógica positiva (SHDN_5V) ou negativa (SHDN_0V), para habilitar ou desabilitar os mesmos. O jumper J2, força a habilitação de todos os circuitos de alimentação.

3.7.2 Barramento

Este equipamento está preparado para disponibilizar no barramento um dos dois protocolos de comunicação de campo mais utilizados em automação, o RS485 e o CAN. A selecção é efectuada com os jumpers J4 e J6. O jumper J5 permite colocar uma resistência de terminação no barramento, de 120 Ohms. Colocou-se também disponível no barramento a tensão de alimentação externa do equipamento e uma tensão de 5 VDC, que poderão ser utilizadas por outros equipamentos “pendurados” no barramento (Figura 30 e Figura 31).

Figura 30 - Circuito do barramento.

Figura 31 - Circuito para selecção do protocolo do

barramento.

Um transdutor (do Inglês, transceiver) é um circuito integrado que controla a recepção e a transmissão de um protocolo. Ele está ligado directamente ao microcontrolador e é responsável pela geração dos sinais que serão transmitidos pelo meio específico. O circuito integrado com a referencia ADM3490ARZ do fabricante ANALOG DEVICES é o transdutor seleccionado para o canal físico diferencial RS485. Foi seleccionado entre dezenas de circuitos semelhantes, devido à exigência de este funcionar a 3.3 VDC. Esta exigência deve-se à vantagem de assim não serem necessários circuitos de

CAPITULO 3


conversão de níveis de tensão entre os pinos I/O do microcontrolador e o driver, visto que assim ambos funcionarão a 3.3 VDC (Figura 32).

Figura 32 - Circuito da comunicação RS485.

Tal como para o transdutor da norma RS485, o único requisito na selecção do transdutor para a norma RS232 é a tensão de alimentação de 3.3 VDC. Assim, foi seleccionado o circuito integrado com referência ILC3232CVZ do fabricante INTERSIL. Os jumpers J1 e J3 permitem seleccionar se o canal 0 da USART do microcontrolador é utilizado para comunicação RS232 ou RS485. Esta porta RS232 e outra que é uma porta específica de debug do microcontrolador, ficam disponíveis numa ficha de pinos dentro do equipamento. Este circuito está representado na Figura 33 e a informação relativa aos pinos da ficha na Tabela 11.

Figura 33 - Circuito da comunicação RS232.

Numero Descrição 1 +3.3VDC 2 Debug TXD 3 Debug RXD 4 RXD 5 TXD 6 GND

Tabela 11 - Configuração da porta série de debug RS232 e RS232.

O protocolo de campo CAN, foi implementado com o controlador independente (stand-alone) CAN (Controller Area Network) com a referência MCP2515 do fabricante MICROCHIP. Este controlador comunica com o microcontrolador via uma ligação série SPI e ainda um pino de interrupção externa

do microcontrolador. Através dessa interface pode-se fazer a comunicação entre o


46

microcontrolador e o controlador com taxas de dados que podem alcançar 5 Mbps. Este pino de

interrupção será utilizado pelo controlador para avisar o microcontrolador que tem dados novos para ele. Para o meio físico foi seleccionado o transdutor com referência 65HVD232 do fabricante Texas

Instruments, que simplesmente converte o sinal TTL vindo do controlador para uma sinalização

diferencial, e vice-versa, de modo que o barramento se torna bastante imune aos ruídos normalmente presentes em ambientes industriais, ou seja, menos susceptível a interferências. Ambos os componentes foram escolhidos mais uma vez pela característica da tensão de alimentação de 3.3 VDC, para assim não ser necessário conversão de níveis de tensão (Figura 34).

Figura 34 - Circuito da comunicação CAN.

3.7.3 Entradas e saídas digitais com isolamento óptico

Num equipamento com processamento, as entradas e saídas (E/S), normalmente designadas por módulos I/O (do Inglês, Input / Output), constituem o elo físico entre o processamento e o meio externo que vai ser controlado. Os circuitos de I/O são normalmente constituídos por duas partes distintas, a parte de potência e a parte de lógica. Estes dois circuitos são normalmente acoplados por um circuito que isola electricamente a saída da entrada, ou vice-versa. Este isolamento eléctrico é muito importante em ambiente com muito ruído como na automação industrial. A parte de potência de um circuito I/O converte o sinal de entrada para um nível lógico que pode ser usado pelo controlador (RIBEIRO, M, 1999). Este equipamento foi implementado com seis entradas digitais e seis saídas digitais, todas com acoplamento óptico, conforme representado na Figura 35 e na Figura 36 respectivamente.

CAPITULO 3


Figura 35 - Circuito das entradas digitais com isolamento óptico.

Figura 36 - Circuito das saídas digitais com isolamento óptico.

3.7.4 Cartão de memória

Um conector para um cartão de memória genérico, SD CARD (Secure Digital Card), foi incorporado para guardar dados de forma não volátil, ou seja, manter os dados mesmo quando faltar a energia. Este cartão de memória pode servir para guardar dados do utilizador, de ocorrências, fazer registos de operações e também guardar o próprio sistema operativo, visto que é possível fazer o arranque do sistema (boot) através dele. Quando o cartão de memória for colocado no conector, o pino “SW3” e a respectiva linha “CD”, que significa detecção de cartão (do Inglês, card detect) é colocada a GND, por meio de um mecanismo mecânico, o que informa o microcontrolador deste acontecimento. O pino do microcontrolador que


48

liga a linha “CD”, é um pino de interrupção externa, para que esta funcionalidade seja implementada sem utilizar muitos recursos de processamento (Figura 37).

Figura 37 - Circuito do cartão de memória.

3.7.5 Aspecto final da “MAIN BOARD”

O posicionamento dos componentes no projecto do circuito impresso é extremamente importante e crítico, tal como foi referido anteriormente neste documento. Neste caso, o posicionamento dos componentes foi fortemente influenciado pelo desenho mecânico da caixa e para que este módulo encaixasse no outro módulo de hardware (módulo "CPU BOARD"). A grande dificuldade neste encaixe deveu-se à altura dos componentes, nomeadamente os condensadores electrolíticos, a bateria, circuitos reguladores lineares e a ficha (jack) de alimentação, que tiveram de ser posicionados em concordância com o outro módulo. Numa etapa final, os dois módulos foram desenvolvidos simultaneamente de forma a corrigir essas intersecções de componentes. Esta etapa foi facilitada devido às funcionalidades de integração 3D do Altium Designer (Figura 38).

Figura 38 - Aspecto Final da "MAIN BOARD".

CAPITULO 3


3.8 Desenvolvimento do módulo “CPU BOARD”

Este módulo é constituído pelo processador, circuitos de clock, memórias voláteis e não voláteis, ligação física para a comunicação Ethernet e USB. Como ferramenta de debug e programação foi implementada uma ligação JTAG. Ao nível de interface com o utilizador possui dois LEDs e dois botões de uso genérico.

3.8.1 Microcontrolador AT91SAM9XE512

Todos os circuitos associados ao microprocessador foram projectados e implementados segundo as notas de aplicação fornecidas pelo fabricante. Os documentos consultados relativamente a este microcontrolador foram a folha de dados do microcontrolador (ATMEL, 2010a), uma nota de aplicação (ATMEL, 2009) e ainda um guia de utilização de uma placa de desenvolvimento (ATMEL, 2008). Todos estes documentos são fornecidos pelo fabricante ATMEL, na seguinte hiperligação:

• http://www.atmel.com/dyn/products/product_card.asp?part_id=4263 Um dos pontos mais críticos no projecto de circuitos electrónicos com microprocessadores é o projecto das linhas de alimentação. Além das preocupações ao nível de um correcto desenho mecânico das linhas e planos, os níveis de tensão mínimos e máximo devem ser respeitados rigorosamente, para não danificar os circuitos. Assim, os pinos de alimentação para os circuitos digitais são os seguintes:

• VDDCORE: Alimentação do núcleo do microcontrolador, incluindo o processador, as memórias internas e os módulos dos periféricos. Faixa de tensão entre 1.65 VDC e 1.95 VDC, com 1.8 VDC de tensão nominal;

• VDDIOM : Alimentação das linhas de I/O do barramento externo. Faixa de tensão entre 1.65 VDC e 1.95 VDC, com 1.8V de tensão nominal ou faixa de tensão entre 3.0 VDC e 3.6 VDC, com 3.3 VDC de tensão nominal. Neste projecto optou-se pela segunda faixa de tensões, com uma tensão nominal de 3.3 VDC para as linhas do barramento I/O. A tensão nominal aplicada a este pino tem que ser a mesma dos circuitos “pendurados” no barramento externo, neste caso, memórias NAND FLASH e SDR SDRAM;

• VDDIOP0: Alimentação das linhas I/O dos periféricos e os módulos USB. Faixa de tensão entre 3.0 VDC e 3.6 VDC, com 3.3 VDC de tensão nominal;

• VDDIOP1: Alimentação das linhas de I/O dos periféricos que envolvem o sensor de imagem. Faixa de tensão entre 3.0 VDC e 3.6 VDC, com 3.3 VDC de tensão nominal;

• GND: Os pinos de GND são comuns aos circuitos digitais que são alimentados por VDDCORE, VDDIOM, VDDIOP0 e VDDIOP1.

Para os circuitos analógicos os pinos de alimentação são os seguintes:

• VDDBU: Alimentação do oscilador de baixa frequência e uma parte do microcontrolador. Faixa de tensão entre 1.65 VDC e 1.95 VDC, com 1.8 VDC de tensão nominal;

• VDDPLL: Alimentação das células PLL e o circuito oscilador principal. Faixa de tensão entre 1.65 VDC e 1.95 VDC, com 1.8 VDC de tensão nominal;


50

• VDDANA: Alimentação do conversor analógico - digital. Faixa de tensão entre 3.0 VDC e 3.6 VDC, com 3.3 VDC de tensão nominal;

• ADCREF: Tensão de referência do módulo analógico que deve estar entre VDDANA e GNDA;

• GNDA: Os circuitos analógicos têm pinos separados de GND. Estando disponíveis para VDDBU, VDDPLL e VDDANA, respectivamente GNDBU, GNDPLL e GNDANA.

Os circuitos analógicos requerem um cuidado especial, ao nível do projecto e desenho do circuito. Não existindo no equipamento fontes isoladas de alimentação, o cuidado ainda deve ser maior, pois o ruído e outras interferências presentes nos circuitos digitais irão reflectir-se nos circuitos analógicos. Para reduzir esses efeitos colocou-se um plano AGND, em toda a área envolvente aos circuitos analógicos, quer do microcontrolador, quer externos ao microcontrolador. Este plano AGND é então ligado ao plano GND dos circuitos digitais através de uma resistência de 0 ohm (R40 da Figura 39), criando assim um ponto único de ligação entre os dois planos, o mais próximo possível do ponto de alimentação externa. Para evitar que picos de corrente danifiquem o microcontrolador, o sinal de alimentação do módulo analógico do microcontrolador (VDDANA) e da tensão de referência do mesmo módulo (ADCREF), passa por uma bobine (L1), como podemos ver na Figura 39.

Figura 39 - Circuito de alimentação do módulo conversor analógico – digital.

Diversas arquitecturas modernas de microcontroladores utilizam fontes de sinal de clock diferentes, ajustadas dinamicamente durante a execução, com o objectivo de possibilitar a gestão do consumo de energia. Assim, estes microcontroladores podem aumentar ou diminuir a velocidade de processamento, aumentando e diminuído o consumo de energia, conforme as necessidades da própria aplicação. O circuito de relógio deste microcontrolador é realizado por dois circuitos PLL (do Inglês, Phase-

Locked Loop), um oscilador principal, um oscilador RC e um oscilador de baixa frequência. Ao nível do oscilador principal, este microcontrolador suporta um cristal externo entre 3 e 20 MHz. Para cristais com frequências inferiores a 8 MHz é necessário colocar uma resistência de 1KOhm em série com o pino 180 (XOUT). Um cristal de Quartzo de 18.432 MHz foi ligado ao pino 150 (XOUT) e ao pino 149 (XIN). A opção de 18.432 MHz deve-se ao facto de ser o mais versátil nas opções de arranque do microcontrolador (Figura 40).

CAPITULO 3


Figura 40 - Circuito do oscilador principal.

Ao nível do oscilador secundário, representado na Figura 41, foi colocado um cristal de Quartzo de 32.768 KHz, ligado ao pino 45 (XOUT32) e ao pino 46 (XIN32). Este cristal proporciona o sinal de clock para o relógio de tempo-real interno do microprocessador, o RTC (do Inglês, Real-Time Clock).

Figura 41 - Circuito do oscilador secundário.

A Figura 42 apresenta o circuito de selecção do circuito oscilador de baixa frequência, ou seja, o oscilador secundário. O pino 41 (OSCSEL) deve ser ligado a VDDBU para seleccionar o cristal externo de 32.786 KHz ou ligado a GND para seleccionar o circuito oscilador RC interno do microcontrolador. Esta selecção é efectuada soldando apenas uma das resistências R54 ou R29, conforme pretendamos o oscilador interno ou externo.

Figura 42 - Circuito para selecção do oscilador.

Um circuito PLL permite regular a frequência e a fase de um sinal, relativamente a um sinal de referência. Neste caso a PLL é utilizada como multiplicador da frequência do oscilador principal, para atingir um sinal de relógio interno maior que o fornecido pelo cristal. O módulo da PLL interna do microcontrolador, requer uma ligação a um filtro externo de segunda ordem através do pino PLLRCA. O módulo do microcontrolador PLLB é inicializado para gerar um sinal de relógio de 48 MHz necessário para o circuito do USB Device Full Speed. Um registo localizado no controlador de gestão de energia (do Inglês, Power Management Controller (PMC)) determina a frequência do oscilador principal e o correcto factor de multiplicação/divisão para o módulo PLL.


52

Figura 43 - Circuito do filtro PLL.

Segundo recomendado pelas notas de aplicação da ATMEL, os componentes R45, C37 e C35 (Figura 43) deverão estar o mais perto possível dos pinos do microcontrolador, para obter melhores resultados no filtro. Os valores dos componentes foram obtidos com o software da ATMEL, ATMEL_PLL_Filter_CALCULATOR_AT91_CAP_2v91 (ATMEL, 2010b). Um outro ponto importante, quando se implementa circuitos com microcontroladores ou outros circuitos integrados com processamento, é a gestão do reinício dos mesmos, tendo em conta os níveis de tensão da fonte de alimentação. Quando esse valor estiver abaixo dos mínimos recomendados pelo fabricante, deverá um circuito auxiliar desactivar e posteriormente reinicializar os circuitos quando esse voltar a níveis aceitáveis. Se isso não acontecer os dispositivos podem ter comportamentos indesejados e aleatórios. Como solução para este problema, a família de circuitos integrados TPS3808xxx, disponibiliza microcontroladores de supervisão e monitorização de tensões de alimentação entre os 0.4V e 5.0V, colocando a saída RESET a nível lógico baixo quando a tensão que monitoriza desce a abaixo de um determinado valor de tensão ou quando o pino MR é colocado manualmente a nível lógico baixo. A saída mantém-se no nível lógico baixo por um tempo configurável, até que o nível de tensão volte ao valor normal ou que o pino manual de reset deixe de estar no nível lógico baixo. Neste projecto, para monitorizar a tensão de alimentação do microcontrolador e gerir o reinício do mesmo, foi usado o modelo de monitorização de 3.3 VDC, o TPS3808G33 da Texas Instruments. Adicionalmente foi colocado um jumper (J1), para efectuar o

reinicio manual do microcontrolador. O tempo de manutenção em reinicialização ( )(stD ) é dado pela

equação (1), devendo sempre o valor do condensador de ajuste ( )(CT nF ) ser maior que 100pF (TI,

2008).

(1) ,2008) (TI175)](105.0)([)(C 3T ××−= − sstnF D

Da equação (1), temos: )(105.0175

)(C)( 3T s

nFstD

−×−=

então com nFnF 100)(CT = obtém-se

)(57.0)(105.0175

100)( 3 ssstD =×−= −

A Figura 44 mostra o esquema eléctrico do circuito de gestão de reinício do microcontrolador, com os valores dos componentes e esquema segundo o documento técnico fornecido pelo fabricante (TI, 2008).

CAPITULO 3


Figura 44 - Circuito de reinício do microcontrolador.

Em sistemas embebidos a gestão do consumo de energia é uma das principais características e exigências. Para isso, neste projecto foram implementadas as funcionalidades do microcontrolador que permitem desligar/ligar os periféricos e módulos. Quando o microcontrolador entrar em modo de poupança de energia (do Inglês, sleep mode), coloca o pino 49 (SHDN) a nível lógico baixo, desligando assim partes da fonte de alimentação e respectivos circuitos associados. O circuito da Figura 45 representa o sinal de comando do microcontrolador e o circuito da Figura 29 faz o interface entre o sinal do microcontrolador e os respectivos circuitos de alimentação. O jumper J8 (Figura 46), quando activo, força o microcontrolador a entrar no modo de funcionamento normal.

Figura 45 - Circuito de encerramento.

Figura 46 - Circuito de inicialização.

A interface JTAG criada em 1985, pelo grupo de trabalho JTAG (do Inglês, Joint Test Acess Group), pretendia implementar um standard para teste de circuitos integrados e placas de circuito impresso. As últimas versões das suas propostas foram aprovadas pelo IEEE, dando origem à norma IEEE1149 (IEEE Standard Test Acess Port and Boundary Scan Arquitecture). Este standard foi criado para efectuar testes a funcionalidades de componentes, interconexão de componentes e interacção de componentes em produtos completos. O núcleo ARM define uma interface JTAG para programação e debug dos programas. Além disso, existe também uma máquina de estados que implementa uma forma de debug sobre a interface JTAG. O método de debug permite definições de pausas em determinado ponto do funcionamento do programa (do Inglês, breackpoints), ou pausas quando o valor de uma


54

determinada expressão muda (do Inglês, watchpoints) e mudanças de estado definidas pelo utilizador no processo de debug do programa ou software de máquina (Rath, D., 2005). O esquema da ligação JTAG está representado na Figura 47 e a informação dos pinos da respectiva ficha de interface na Tabela 12.

Figura 47 - Circuito JTAG.

Nº Descrição Nº Descrição 1 +3.3VDC 2 +3.3VDC

3 NTRST (do Inglês, Test Reset Sinal). Permite efectuar um reset ao controlador JTAG.

4 GND

5 TDI (do Inglês, Test Data In). Entrada de dados série do controlador JTAG.

6 GND

7 TMS (do Inglês, Test Mode Select). Este pino selecciona o próximo estado na máquina de estados TAP (do Inglês, Test Acess Port).

8 GND

9 TCK (do Inglês, Test Clock). É o sinal de clock que permite o deslocamento de dados de entrada, nos pinos TMS e TDI. É um sinal de clock accionado no flanco ascendente positivo com os sinais TMS e TCK que definem o estado interno do dispositivo.

10 GND

11 RTCK (do Inglês, Returned Test Clock). Sinal de sincronização que o controlador JTAG usa para saber se este está preparado para receber / transmitir.

12 GND

13 TDO (do Inglês, Test Data Out). Este pino é a saída de dados série do controlador JTAG. Os dados são deslocados para fora do dispositivo no flanco descendente do sinal de clock TCK.

14 GND

15 NRST (do Inglês, Microcontroller Reset Activ Low). Este pino permite reiniciar o microcontrolador.

16 GND

17 NOT CONECT. 18 GND

19 NOT CONECT. 20 GND

Tabela 12 - Ligações do conector JTAG (Rath, D., 2005).

CAPITULO 3


Em ambientes de muito ruído e interferências electromagnéticas o pino 43 do microcontrolador (JTAGSEL) é recomendado estar ligado a GND ou adicionar uma resistência ligada a GND (pull-down) de 1KOhm. Para habilitar o funcionamento da interface JTAG, o mesmo pino deve ser ligado a VDDBU, o que acontece por defeito na placa projectada. O microcontrolador AT91SAM9XE128/256/512 disponibiliza um pino denominado ERASE, que permite reinicializar a memória interna FLASH e os bits de configuração genéricos (GPNVM), guardados em memória não volátil. O pino 40 (ERASE) deve ser mantido a VDDIO, no caso, 3.3 VDC, para apagar os bits GPNVM e todo o conteúdo da memória FLASH interna. Os bits GPNVM são:

• O bit de segurança (Security Bit) que controla o acesso à memoria interna FLASH via interface externo JTAG;

• Os bits que habilitam o módulo interno de reinicio quando a alimentação desce abaixo do nível de funcionamento do microcontrolador (Brownout);

• Os bits que permitem configurar a sequência de arranque (boot) do sistema. Em ambientes de muito ruído e interferências electromagnéticas o pino 40 (ERASE) é recomendado estar sempre ligado a GND. Estas opções foram implementadas com o jumper J4 (Figura 48).

Figura 48 - Circuito para apagar a memória FLASH.

Para finalizar este tópico, refira-se ainda que as linhas dos barramentos paralelos PA0 à PA31 e PB0 à PB31 e PC0 à PC3 podem fornecer uma determinada corrente, sendo que uma sobrecarga nestas linhas pode danificar definitivamente o microcontrolador. Segundo o manual do microcontrolador, cada uma destas linhas de entrada/saída genéricas, pode fornecer permanentemente até 16 mA, e um total de 350 mA em todas as linhas. Estes valores devem ser cumpridos para não danificar o microcontrolador.

3.8.2 Sensor de temperatura

Um circuito de medição de temperatura foi incorporado com a funcionalidade de proteger os circuitos electrónicos contra sobreaquecimento. Assim, o microcontrolador monitoriza a temperatura interna do equipamento, e deverá desligar os circuitos externos, via circuito da fonte de alimentação, e que desliga os módulos da placa (Figura 29), entrando em modo de baixa velocidade (sleep), a partir de um determinado valor de temperatura.


56

O MCP9701xx é um sensor de temperatura linear do fabricante MICROCHIP que fornece uma saída analógica em tensão correspondente ao valor de temperatura envolvente. Foi seleccionado por ser de baixo custo e baixo consumo. Permite uma resolução de 4º Celcius na gama de 0°C a +70°C, o que é mais que suficiente para a aplicação em causa. A conversão de tensão para temperatura será efectuada pelo conversor analógico digital do microcontrolador, segundo a relação característica de 19.5 mV/°C, fornecida na folha de dados do componente. O circuito electrónico é muito simples, como se pode verificar na Figura 49.

Figura 49 - Circuito do sensor de temperatura.

3.8.3 Memórias

A referência SDR SDRAM escolhida é a MT48LC16M16A2P-75:D do fabricante MICRON, com a configuração 4 MB de dados x 16 bits de endereços x 4 bancos de memória e uma velocidade máxima

de operação de 133 MHz, fornecendo 133 milhões de leituras (teóricas) por segundo (PC133). Neste

projecto foi implementado um acesso de 32 bits, usando duas memórias de 16 bits em paralelo (Figura 50). Este tipo de memórias forma uma espécie de matriz, organizadas num esquema de linhas e colunas. O cruzamento de uma coluna com uma linha forma o que conhecemos como endereço de memória. A referência escolhida para a memória NAND FLASH é a HY27UF082G2B-TPCB da HYNIX

SEMICONDUCTOR, com uma configuração 256M bits x 8, acedível por um barramento de dados de 8 bits (Figura 51).

CAPITULO 3


Figura 50 - Circuito da memória SDR SDRAM.

Figura 51 - Circuito da memória NAND FLASH.


58

3.8.4 Ethernet segundo a norma IEEE1588

Aquando da escolha dos componentes principais, no ponto anterior, foram apresentados os motivos da escolha do circuito integrado responsável pela comunicação Ethernet. Para a sua implementação foi consultada a folha de dados do circuito integrado (NS, 2010), uma nota de aplicação do mesmo (NS, 2008a) e ainda o esquema de uma placa de desenvolvimento (NS, 2008b). Ambos os documentos são fornecidos pelo fabricante do controlador, a National Semiconductor , na seguinte hiperligação:

• http://www.national.com/pf/DP/DP83640.html#Overview Seguindo os documentos referidos anteriormente, o esquema implementado é o representado na Figura 52. Os pontos mais críticos neste circuito e que foram desenhados de forma mais criteriosa, segundo as recomendações apresentadas na Secção 3.1 deste documento, são as ligações entre a ficha RJ45 e o driver, que têm de ser linhas paralelas e com o mesmo comprimento para cada canal, a alimentação da parte analógica do driver e as linhas de alta velocidade entre o microcontrolador e o driver.

Figura 52 - Circuito da Ethernet segundo a norma IEEE1588.

Como forma de debug do estado da rede Ethernet, e tal como acontece em qualquer dispositivo com Ethernet, foi implementado uma interface com o utilizador com dois LEDs indicando o estado e actividade da rede (Tabela 13).

CAPITULO 3


LED Indicação

Verde Este LED esta ligado quando a ligação apresenta um bom funcionamento

Amarelo Actividade na recepção ou transmissão de dados via Ethernet

Tabela 13 - LEDs indicadores do estado da comunicação Ethernet.

3.8.5 USB Host e USB Device

Este equipamento foi implementado com uma porta USB Host e uma porta USB device, ambas na versão USB 2.0 Full Speed, com uma capacidade de transferências de dados de até 12M bit/s. O circuito do USB Host é apresentado na Figura 53. Uma resistência de terminação série (R60 e R61) foi colocada nas linhas diferenciais da comunicação USB Host, segundo recomendação do fabricante (REXT).

Figura 53 - Circuito do USB Host.

O circuito do USB Device é apresentado na Figura 54. Uma resistência de terminação série (R34 e R36) é colocado nas linhas diferenciais da comunicação USB, tal como no circuito anterior, por recomendação do fabricante do microcontrolador. Os periféricos que usam alta velocidade (do Inglês, Full-Speed) devem ter uma resistência na ligação D+, e os de baixa velocidade (1,5 MB) devem ter uma resistência no D-. O mestre da rede usa a diferença de voltagem causada pela inclusão destas resistência no barramento para saber que um novo dispositivo foi acoplado e qual a sua velocidade. Neste caso, a resistência (R68) está na linha D+, indicando que este é um dispositivo de alta velocidade. A linha USBCNX é utilizada para monitorizar a linha de alimentação do barramento USB e para detectar a presença de um USB Host, na rede. Assim, é possível desligar o módulo do periférico USB Device interno do microcontrolador, bem como o respectivo driver físico na ausência de comunicação USB, poupando energia.


60

Figura 54 - Circuito do USB Device.

3.8.6 Aspecto final da “CPU BOARD”

O posicionamento dos componentes no projecto dos circuitos impressos é extremamente importante e crítico. Neste caso, o posicionamento dos componentes foi fortemente influenciado pelo desenho da caixa e pela tentativa de reduzir ao máximo o comprimento das linhas do barramento de dados e endereços das memórias e das comunicações Ethernet e USB. Na imagem do lado direito (Figura 55) podemos ver os condensadores de acoplamento, espalhados pela placa. O sensor de temperatura está no centro da placa, junto ao microcontrolador.

Figura 55 - Aspecto Final da "CPU BOARD".

3.9 Produção das placas de circuito impresso

As características técnicas das placas de circuito impresso são apresentadas na Tabela 14 no caso da placa “MAIN BOARD” e na Tabela 16 para a placa “CPU BOARD”. Estes dados são necessários para o fabrico das placas de circuito impresso e devem ser enviados ao fornecedor, juntamente com os ficheiros gerber e excellon/ncdrill. O formato de impressão gerber é usado pela indústria de circuitos impressos para descrever imagens de uma placa de circuito impresso, em cada uma das suas camadas, desde camadas de cobre à camada de marcação de componentes. Existem dois formatos distintos, o gerber: RS-274X (formato gerber estendido) e o obsoleto RS-274-D (formato gerber standard). Concretamente, a especificação referida

CAPITULO 3


como gerber que é necessária para a maioria dos fornecedores para produção de circuitos impressos é a RS-274X. São necessários ficheiros gerber-274X para cada camada de produção. Estas camadas estão descritas na Tabela 15 e na Tabela 17. Os ficheiros excellon ou ncdrill são formatos apropriados para máquinas de controlo numérico (CNC). De forma semelhante ao gerber, o formato ncdrill deriva do standard EIA-RS274-C, e é composto por conjunto de instruções 2D conhecidas como instruções CNC, também chamadas “G-code”. De uma forma simples estes ficheiros são compostos por listagens das posições dos furos agrupados por ferramenta. De forma a tornar o formato completo e independente, o cabeçalho do ficheiro passou a ter presente “G-codes” que definem as ferramentas usadas. O software que foi utilizado para este projecto, o Altium Design, tal como a grande maioria do software especializado para desenho de circuitos impressos, permite a criação destes ficheiros.

Parâmetro Descrição Nome do PCB ARM9MAIN_v1.0

Número de camadas: 2

Dimensão do PCB X (mm) 98.6

Dimensão do PCB Y (mm) 80

Tipo de material FR4 (standard)

Espessura do PCB (mm) 1.55 (standard)

Largura mínima das pistas de cobre (mm) 0.3

Largura mínima de isolamento entre pistas (mm) 0.152

Diâmetro mínimo dos furos (mm) 0.6

Diâmetro máximo dos furos (mm) 3

Número de furos 202

Cor da máscara de solda na camada superior (top) Verde (standard)

Cor da máscara de solda na camada inferior (bottom) Verde (standard)

Cor da marcação dos componentes na camada superior (top)

Branco (standard)

Cor da marcação dos componentes na camada inferior (bottom)

Branco (standard)

Acabamento lead free (standard)

Tabela 14 - Características técnicas da placa de circuito impresso “MAIN BOARD”.

Camada Nome do ficheiro Camada superior (Top Layer) ARM9MAIN_v1.0.GTL

Marcação dos componentes na camada superior (Top

Overlay) ARM9MAIN_v1.0.GTO

Máscara de solda superior (Top Solder Mask) ARM9MAIN_v1.0.GTS

Camada superior inferior (Bottom Layer) ARM9MAIN_v1.0.GBL

Marcação dos componentes na camada inferior (Bottom Overlay)

ARM9MAIN_v1.0.GBO

Máscara de solda inferior (Bottom Solder Mask) ARM9MAIN_v1.0.GBS

Limite exterior da placa (Keep Out) ARM9MAIN_v1.0.GM2

Tabela 15 - Lista das camadas da placa de circuito impresso "MAIN BOARD".


62

Parâmetro Descrição Nome do PCB ARM9CPU_v1.0

Número de camadas: 4

Dimensão do PCB X (mm) 98.6

Dimensão do PCB Y (mm) 80

Tipo de material FR4 (standard)

Espessura do PCB 1.55 (standard)

Largura mínima das pistas de cobre 0.1524mm

Largura mínima de isolamento entre pistas 0.1524mm

Diâmetro mínimo dos furos 0.381mm

Diâmetro máximo dos furos 3.2512mm

Número de furos 500

Cor da máscara de solda na camada superior (top) Verde (standard)

Cor da máscara de solda na camada inferior (bottom) Verde (standard)

Cor da marcação dos componentes na camada superior (top)

Branco (standard)

Cor da marcação dos componentes na camada inferior (bottom)

Branco (standard)

Acabamento lead free (standard)

Tabela 16 - Características técnicas da placa de circuito impresso “CPU BOARD”.

Camada Nome do ficheiro Camada superior (Top Layer) ARM9CPU_v1.0.GTL

Marcação dos componentes na camada superior (Top

Overlay) ARM9CPU_v1.0.GTO

Máscara de solda superior (Top Solder Mask) ARM9CPU_v1.0.GTS

Camada superior inferior (Bottom Layer) ARM9CPU_v1.0.G1

Marcação dos componentes na camada inferior (Bottom Overlay)

ARM9CPU_v1.0.G2

Máscara de solda inferior (Bottom Solder Mask) ARM9CPU_v1.0.GBL

Limite exterior da placa (Keep Out) ARM9CPU_v1.0.GBO

Camada superior (Top Layer) ARM9CPU_v1.0.GBS

Keep Out ARM9CPU_v1.0.GM2

Tabela 17 - Lista das camadas da placa de circuito impresso "CPU BOARD".

CAPITULO 3


3.10 Especificações técnicas do equipamento

As especificações técnicas do equipamento são as apresentadas na Tabela 18.

Processamento Microcontrolador ATMEL AT91SAM9XE512,

ARM926EJ-S Core

Velocidade de processamento 200 MIPS a 180 MHz

JTAG 1

RTC Com bateria de backup

Memória Fast SRAM (microcontrolador) 32KB

ROM (microcontrolador) 32KB

FLASH (microcontrolador) 512KB

FLASH 256MB

SDRAM 64MB

Cartão memória SDCard ou MMC

Comunicação ETHERNET 10/100 Mbps, IEEE1588, conector RJ45

CAN 1 Canal (barramento)

UART 1 RS232 (DEBUG COM PORT) 1 RS232 (COM PORT0) 1 RS485 (COM PORT1)

USB 1 USB host USB2.0 1 USB device USB2.0

SPI 1 Canal (pinos genéricos)

Debug JTAG Conector de 20 pinos (ARM JTAG)

RS232 Conector de 6 pinos genérico (ATMEL DEBUG COM PORT)

LEDs/ Botões 4

Outras Sensor de temperatura 1 (± 2 ° C de 0 ° C a +70 ° C)

Entradas e saídas digitais 6/6

Entradas Analógicas 2 com resolução de 10 bits (ficha de pinos genéricos)

LEDs e botões de uso genérico 4/4

Temperatura de funcionamento 0 ° C a +70 ° C

Tensão de alimentação 10 a 30Vdc

PCB MAIN 2 Camadas (98.6 mm x 80 mm)

CPU 4 Camadas (98.6 mm x 80 mm)

Caixa Dimensões externas (altura x comprimento x espessura)

114.5 mm x 89 mm x 22.5 mm

Tabela 18 - Especificações técnicas do equipamento.


64

3.11 Configurações do equipamento

As Tabelas 19 e 20 apresentam as configurações do equipamento que podem ser efectuadas via jumpers, na placa “MAIN BOARD” e “CPU BOARD” respectivamente.

Número Descrição J1 e J3 Seleccionar RS232 ou RS485 na COM0

1-2 RS485 2-3 RS232

J2 Força o funcionamento dos circuitos de alimentação. Para usar a função de encerramento por software: J2 deve estar aberto 3 VDC backup bateria deve estar colocada

J4 e J6 Seleccionar o protocolo do barramento 1-2 CAN 2-3 RS485 (Juntamente com esta configuração, colocar o J1 e J3 na posição 1-2)

J5 Activar a resistência de terminação de linha (120 ohm)

J7 Força o funcionamento do regulador de 5 VDC

Tabela 19 - Configuração dos Jumpers placa “MAIN BOARD”.

Número Descrição J1 Reset manual do microcontrolador

J2 Apagar os dados da memória FLASH 1-2 Para apagar os bits de uso genérico (PGNVMx), todo o conteúdo da memória FLASH e os bits de segurança (SECURITY). 2-3 Operação normal

J3 Força o micro a sair do modo de poupança de energia

J4 Activar a memória NAND FLASH

J5 Protecção contra escrita na NAND FLASH

Tabela 20 - ConFiguração dos Jumpers da placa “CPU BOARD”.

CAPITULO 3


3.12 Aspecto final do produto

O aspecto final do produto sem a respectiva caixa é apresentado na Figura 56. O software de desenho utilizado neste projecto, o Altium Design permite fazer uma modelação completa em três dimensões (3D), e criar vistas como a representada na Figura.

Figura 56 - Aspecto final do produto sem caixa.

3.13 Conclusões

Neste Capítulo ilustraram-se os passos necessários ao desenvolvimento de hardware

especializado, desde a escolha de componentes, elaboração e cuidados com o desenho e

construção de circuitos impressos, e finalmente a respectiva produção.

CAPITULO 4


4 DESENVOLVIMENTO DA PLATAFORMA DE SOFTWARE

Este capítulo inicia com uma breve descrição sobre virtualização, contextualizando a funcionalidade de algumas das ferramentas que são utilizadas no desenvolvimento da plataforma de software deste projecto. Apresenta também as diversas etapas, ferramentas e requisitos necessários para desenvolver uma plataforma de software baseado no kernel Linux, nas aplicações GNU e em diversos pacotes de software disponibilizados por diversos projectos. A par do desenvolvimento da plataforma de software para o equipamento projectado, será abordado o processo de emulação de hardware. Assim, este capítulo está organizado da seguinte forma:

• Subcapítulo 4.1: Conceitos sobre virtualização;

• Subcapítulo 4.1: Configuração do ambiente de trabalho;

• Subcapítulo 4.2: Soluções baseadas em Linux4SAM;

• Subcapítulo 4.3: Desenvolvimento de sistemas GNU/Linux para ARM;

• Subcapítulo 4.4: Carregar o sistema na plataforma desenvolvida;

• Subcapítulo 4.5: Emulação de hardware com QEMU;

4.1 Conceitos de Virtualização

A virtualização permite que "dentro" de um sistema operativo, ao qual se dá o nome de anfitrião (do Inglês, host), se instale outro sistema operativo, ao qual se dá o nome de convidado (do Inglês, guest). Por meio da virtualização é possível executar, por exemplo, o GNU/Linux sobre a plataforma Windows, ou vice-versa. Em virtualização, o sistema operativo anfitrião é o hypervisor. Os sistemas operativos convidados residem no hypervisor ou no sistema operativo anfitrião. Em alguns casos, o sistema operativo convidado tem como alvo a mesma arquitectura que o hardware do hypervisor, mas noutros casos pode ser uma arquitectura diferente. No desenvolvimento deste projecto são usadas as duas possibilidades (Figura 57).

Figura 57 - Estrutura básica de virtualização de plataforma

DESENVOLVIMENTO DA PLATAFORMA DE SOFTWARE

68

A virtualização é possível de obter de diversas formas, mas os seguintes três métodos são os mais frequentes:

• Virtualização nativa ou integral: Nesta implementação o hypervisor implementa os elementos básicos de isolamento, separando o hardware dos sistemas operativos convidados. Este método é utilizado pelo software VMware ESX Server e VirtualBox;

• Paravirtualização: Neste método, o programa de controlo implementa uma interface de programação da aplicação (API) do hypervisor que é utilizada pelo sistema operativo convidado. A paravirtualização é utilizada pelo Xen e pelo Kernel-based Virtual Machine (KVM) do Linux;

• Emulação: Este método virtualiza a plataforma convidada simulando o ambiente de hardware completo. Exemplos de virtualização através deste método incluem o QEMU e o Bochs.

4.2 Configuração do ambiente de trabalho

Como seria de esperar o processo de desenvolvimento de software será efectuado em ambiente GNU/Linux. No entanto, por questões de comodidade será usada a técnica de virtualização nativa do ambiente GNU/Linux. No ambiente GNU/Linux virtualizado é utilizado o emulador de hardware QEMU, para verificar o processo de desenvolvimento de software para a arquitectura ARM. O esquema do ambiente de trabalho é o representado na Figura 58.

Figura 58 - Esquema do ambiente de trabalho

4.2.1 Virtual Box: Virtualização Nativa

Primeiro, é necessário escolher o software de virtualização nativa ou integral, onde se irá virtualizar o ambiente GNU/Linux para a arquitectura x86.

CAPITULO 4


Hoje existem três aplicações de software conhecidas com esta funcionalidade e gratuitas: VMWare, QEMU, e VirtualBox. O VMWare possui duas versões livres, uma chamada de player e a outra chamada de server, tendo uma velocidade de execução inferior às versões profissionais. Já o QEMU funciona completamente através de linhas de comando, embora seja prevista uma versão gráfica para Windows, esta ainda em fase de desenvolvimento. Além desse aspecto este software não possui opções básicas como as outras máquinas virtuais possuem, nomeadamente colocar em pausa a máquina virtual. No entanto, este software diferencia-se dos outros por ter a possibilidade de emular hardware, e será utilizado para fazer emulação de hardware, permitindo assim simular o equipamento desenvolvido neste projecto. Concluindo, ao nível da virtualização nativa ou integral, resta então a opção gratuita da Oracle, o VirtualBox. O VirtualBox é um software gratuito, tornou-se software livre em Janeiro de 2007 e possui versões para praticamente todos os sistemas operativos. Antes de tudo, acede-se ao site do VirtualBox, navega-se até a secção de downloads e obtém-se o binário para Windows, disponível na seguinte hiperligação:

• https://www.virtualbox.org/wiki/Downloads Após descarregar o ficheiro de instalação, inicia-se o processo de instalação, muito facilitado, pois bastam os passos apresentados. Com o VirtualBox instalado correctamente, descarrega-se a distribuição GNU/Linux para a arquitectura do computador local. Neste projecto foi utilizada a distribuição GNU/Linux Debian para a arquitectura x86.

4.2.2 QEMU: Emulador de hardware

O desenvolvimento de software baseado em Linux para sistemas embebidos é tradicionalmente realizado directamente no hardware, onde o kernel Linux e o sistema de arquivos são instalados. Uma abordagem complementar é usar um emulador de processador, a fim de iniciar o processo de desenvolvimento e testar as aplicações sem o hardware subjacente. O software de emulação QEMU é um software livre que permite emular algumas plataformas de hardware. Além de emular um processador, este também permite a emulação de todos os subsistemas necessários, como hardware de rede, de vídeo, de som, periféricos, etc. Ainda permite a emulação de conceitos avançados, como sistemas de multiprocessamento simétrico (até 255 CPUs) e outras arquitecturas de processador, como ARM, MIPS, PowerPC, entre outros. A versão utilizada nesta implementação é a “QEMU PC emulater version 0.12.0”, disponível para download no site da Internet oficial do seu criador, na seguinte hiperligação:

• http://fabrice.bellard.free.fr/qemu/qemu-0.12.0.tar.gz Em ambiente GNU/Linux, os passos para instalar esta ferramenta, via código fonte, são os seguintes:

$tar zxvf qemu-0.12.0.tar.gz $cd qemu-0.12.0 $./configure $make


70

$make install Este processo cria não apenas uma imagem QEMU executável para a arquitectura local, mas também um conjunto de imagens para outras arquitecturas, incluindo a arquitectura ARM usada neste projecto, bem como outras como MIPS, PowerPC, 68K e SPARC. Com estes executáveis, é possível inicializar um kernel Linux que foi construído para uma arquitectura de destino diferente da arquitectura local. Se o sistema operativo anfitrião e convidado estão compilados para a mesma arquitectura de processador, é possível acelerar a execução de modo a obter-se um desempenho nativo utilizando para isso o acelerador de QEMU, designado por KQEMU. O KQEMU é um driver (módulo do kernel Linux) que permite que código de modo de utilizador e código de kernel seja executado directamente na CPU anfitriã. O processo para construir este acelerador é semelhante ao do QEMU.

4.3 Soluções baseadas em Linux4SAM

O portal AT91SAM (http://www.at91.com) é fundamentalmente orientado para a comunidade de clientes, parceiros, utilizadores e fãs da tecnologia ATMEL. Funciona basicamente como um portal de novidades e como fórum web sobre os microcontroladores da ATMEL baseados na arquitectura ARM. Neste portal são ainda apresentados todas as placas de desenvolvimento disponíveis no mercado com microcontroladores AT91, projectos de outras empresas parceiras da ATMEL e ainda novidades sobre acções de formação, seminários, palestras, ou outros assuntos relativos a formação na área. Um ponto interessantíssimo neste portal é a existência de três sites distintos, dentro do portal, relativos a implementação de arquitecturas baseadas em AT91SAM com três sistemas operativos distintos. Os portais e os referidos sistemas operativos estão disponíveis nas seguintes hiperligações:

• Linux: Disponível em: http://www.at91.com/linux4sam;

• Windows: Disponível em: http://www.at91.com/windows4sam;

• Android: Disponível em: http://www.at91.com/android4sam. O portal Linux4SAM, disponível em http://www.at91.com/linux4sam.com, é o principal ponto de partida para quem se inicializa na implementação do kernel Linux e nas soluções GNU em produtos AT91SAM. O objectivo é centralizar informações sobre o kernel Linux e projectos de código aberto em microcontroladores da ATMEL, baseados na arquitectura ARM. O portal Linux4SAM disponibiliza pacotes completos com os ficheiros prontos a serem carregados, para experimentar e testar soluções GNU/Linux nas suas placas de desenvolvimento. O equipamento desenvolvido neste projecto tem poucas semelhanças relativamente às placas de desenvolvimento do mesmo microcontrolador apresentados neste portal, quer ao nível de periféricos externos ao microcontrolador, quer à disposição dos componentes, fontes de alimentação, etc. No entanto, a aplicação de demonstração fornecida pelo portal pode ser experimentada no equipamento e serem testados os componentes essenciais, como microcontrolador, memória FLASH interna e externa, memória SDRAM, porta série, e comunicações USB e Ethernet. Essa versão de demonstração e toda a documentação relativa está disponível na seguinte hiperligação:

• http://www.at91.com/linux4sam/bin/view/Linux4SAM/GettingStarted#Demo9xe

CAPITULO 4


4.4 Desenvolvimento GNU/Linux para ARM

Esta etapa descreve o processo de criação de uma pequena distribuição GNU/Linux, personalizada para o hardware desenhado nesse projecto e para um ambiente de hardware emulado (QEMU), ambos com arquitectura ARM, utilizando o Buildroot.

4.4.1 Toolchain

Ao contrário dos computadores pessoais, os sistemas embebidos não são habitualmente, programados na plataforma onde a aplicação a desenvolver será executada. De modo a efectuar a compilação de um programa tendo como destino uma outra arquitectura computacional, são necessários toolchains especiais com um compilador cruzado ( do Inglês, Cross-compiler) específico para essa mesma arquitectura. O termo Cross-compiler representa um compilador capaz de gerar um código executável para uma plataforma diferente daquela em qual o compilador é executado. Traduzindo literalmente, toolchain é uma “corrente de ferramentas”. Na prática, é um conjunto de ferramentas de compilação. Existem basicamente dois tipos de toolchain: Native toolchain e Cross-compiler toolchain. O conceito é simples e pode ser visualizado na Figura 59.

Figura 59 - Compilação cruzada para ARM (Free Electrons, 2010).

Portanto, usa-se uma native toolchain quando se pretende compilar uma aplicação para a mesma arquitectura da máquina de desenvolvimento. Na prática, esta aplicação será executada na sua máquina de desenvolvimento (x86 no nosso exemplo). Já um cross-compiling toolchain vai gerar um binário para uma arquitectura diferente da sua máquina de desenvolvimento. No exemplo acima, tal como neste projecto, a máquina de desenvolvimento é x86 e a arquitectura alvo é ARM. Em sistema embebidos normalmente não é possível colocar toda a toolchain dentro do próprio sistema embebido por questões de memória e recursos disponíveis, logo a opção de cross-compiling toolchain é frequentemente utilizada.


72

As componentes de uma toolchain para desenvolvimento em Linux são as seguintes (Free Electrons, 2010):

• Compilador GCC: O compilador GNU C, compatível também com outras linguagens como C++ e Java, é capaz de gerar código para diversas arquitecturas incluindo ARM, AVR, Blackfin, MIPS, PowerPC e x86;

• Binutils: Um conjunto de ferramentas para manipular binários para arquitecturas específicas.

Por exemplo, possui o “as” para ler um código fonte assembly e gerar um arquivo objecto e o “ ld” para fazer o link de um ou mais arquivos objecto num executável;

• Biblioteca C padrão: A principal função da biblioteca C padrão é fazer a interface com o

kernel através de chamadas do sistema (do Inglês, System Calls). Quando esta biblioteca é compilada, a toolchain irá fazer o link do código da biblioteca com o código da aplicação (estaticamente ou dinamicamente). Por este motivo, a toolchain contém a biblioteca C padrão compilada para a sua arquitectura alvo. No Linux, existem diversas implementações de biblioteca C, as mais conhecidas são a glibc (padrão em sistemas desktop) e a uClibc (padrão em Linux embebido). Apesar de apresentarem a mesma interface (API) com as aplicações, a uClibc é optimizada para gerar um código menor e a glibc é optimizada para ter melhor performance;

• Kernel Headers: Uma toolchain inclui, compilada, a biblioteca C padrão do sistema. Isto significa que quando a toolchain é criada, ela compila a biblioteca e transforma-a num arquivo objecto (*.so ou *.a) para poder ser usada (“linkada”) pelas aplicações. Mas para compilar a biblioteca C padrão existe uma dependência adicional, os headers do kernel. A biblioteca C padrão interage com o kernel através de chamadas de sistema. Para a biblioteca C saber quais são as chamadas de sistema disponíveis consulta os headers do kernel. A definição das chamadas de sistema para uma arquitectura ARM encontra-se dentro do código fonte do kernel, em “arch/arm/include/asm/unistd.h”;

• GDB: O GDB é o debugger padrão em sistemas Linux e como também depende das bibliotecas do sistema, também faz parte da toolchain. Mas como não é necessário para compilar as aplicações, é apenas um elemento opcional.

Na prática, uma toolchain nativa é composta pelas ferramentas de compilação que usamos na máquina de desenvolvimento, como o gcc, as, ld, strip e gdb. Já um cross-compiling tool-chain acrescenta normalmente um prefixo ao nome destas ferramentas para indicar a arquitectura e outras informações adicionais. Por exemplo, o compilador gcc de uma toolchain para sistemas Linux de arquitectura ARM pode chamar-se “arm-linux-gcc”.

4.4.2 BuildRoot

Uma possível solução para a compilação de um kernel Linux embebido para uma determinada arquitectura (por exemplo, x86, Power PC, ARM, MIPS) é representada pelo projecto BuildRoot. Este projecto fornece um conjunto de Makefiles e patches permitindo também gerar facilmente uma compilação cruzada (toolchain) e o sistema de arquivos necessários para o sistema de destino Linux. Assim, pode-se afirmar que o Buildroot permite gerar uma distribuição Linux embebida do zero em relativamente pouco tempo.

CAPITULO 4


A primeira etapa será descarregar e descompactar a última versão estável do Buildroot. Na consola faz-se:

$wget http://buildroot.uclibc.org/downloads/buildroot-2011.11.tar.gz $tar zxvf buildroot-2011.11.tar.gz $cd /buildroot-2011.11

De seguida, executa-se o menu de configuração. O BuildRoot tem uma interface de configuração similar à interface de configuração do kernel do Linux. Existem diversas opções relativamente ao tipo de interface, e relativamente ao presente projecto será sempre usado o menu de configuração com ambiente gráfico, executando:

$make xconfig Se tudo correr bem, uma janela aparecerá onde se irá configurar todas as ferramentas necessárias para a compilação cruzada de x86 para ARM. Neste ambiente gráfico (Figura 60) é configurada a localização e versões dos diversos pacotes de software, a localização dos patches a utilizar, entre outros parâmetros descritos em seguida. Do lado esquerdo da janela, existem as diversas categorias a configurar para que o Buildroot gere correctamente a imagem do kernel Linux e o sistema de ficheiros para a plataforma pretendida. As categorias são as seguintes:

• Target Architecture: Selecção da arquitectura de destino;

• Target Architecture Variant: Selecção do modelo específico do núcleo do processador;

• Target ABI: Selecção do tipo de barramento externo;

• Build options: Parâmetros relativos ao processamento e download de pacotes de software necessários à compilação. Normalmente não necessita ser alterado;

• Toolchain: O menu toolchain permite especificar as opções para a compilação cruzada (toolchain). Neste menu seleccionamos as versões das diversas ferramentas de compilação, como as Linux Headers, o uClibc, o Binutils, o GCC, etc;

• System configuration: Este menu permite configurar vários parâmetros relativos ao sistema alvo, como o nome e o banner que será apresentado no arranque do sistema;

• Package Selection for the target: A selecção de pacotes permite especificar vários pacotes necessários no sistema a ser gerado. Normalmente, pelo menos o pacote Busybox deve ser seleccionado para ter um conjunto mínimo de comandos Linux;

• Filesystem images: As opções de sistema de arquivos alvo permitem seleccionar o tipo de sistema de arquivos para o destino, juntamente com outras opções;

• Bootloaders: Selecção dos diversos sistemas de bootloader disponíveis com o Buildroot;

• Kernel: O menu kernel permite especificar a versão do kernel Linux e o nome e directório do patch a ser aplicado, se necessário. Pode-se também fornecer o site do patch de onde o arquivo pode ser descarregado. Note-se que as opções do menu Kernel Header Toolchain devem conter a mesma versão do kernel Linux que o previsto neste menu.


74

Figura 60 - Menu de configuração do Buildroot.

Para compilar basta executar o comando "make". O Buildroot irá efectuar o download e compilar todos os pacotes necessários para gerar as ferramentas para compilação cruzada (toolchain), depois compilar o kernel e gerar o sistema de ficheiros (rootfs). Assim na linha de comandos executa-se:

$make

Este processo é demorado, devido ao tempo de descarregar e compilar os códigos fonte dos diversos constituintes da toolchain. Na consola são apresentados todos os resultados deste processo. Na seguinte lista pode-se verificar os passos desse processo, impressos na consola, pelas diversas ferramentas usadas na compilação e configuração.

>> host-gmp 5.0.2 Extracting >> host-gmp 5.0.2 Patching package//gmp >> host-gmp 5.0.2 Updating config.sub and config.guess >> host-gmp 5.0.2 Patching libtool >> host-gmp 5.0.2 Configuring >> host-gmp 5.0.2 Building >> host-gmp 5.0.2 Installing to host directory >> host-mpfr 3.0.1 Extracting >> host-mpfr 3.0.1 Patching package//mpfr >> host-mpfr 3.0.1 Updating config.sub and config.guess >> host-mpfr 3.0.1 Patching libtool >> host-mpfr 3.0.1 Configuring >> host-mpfr 3.0.1 Building >> host-mpfr 3.0.1 Installing to host directory >> host-binutils 2.21.1 Extracting

CAPITULO 4


>> host-binutils 2.21.1 Patching package//binutils >> host-binutils 2.21.1 Updating config.sub and config.guess >> host-binutils 2.21.1 Patching libtool >> host-binutils 2.21.1 Configuring >> host-binutils 2.21.1 Building >> host-gmp 5.0.2 Building >> host-gmp 5.0.2 Installing to host directory >> host-mpfr 3.0.1 Extracting >> host-mpfr 3.0.1 Patching package//mpfr >> host-mpfr 3.0.1 Building >> host-mpfr 3.0.1 Installing to host directory >> host-binutils 2.21.1 Extracting >> host-binutils 2.21.1 Patching package//binutils >> host-binutils 2.21.1 Building >> host-binutils 2.21.1 Installing to host directory >> busybox 1.19.3 Extracting >> busybox 1.19.3 Patching package//busybox >> busybox 1.19.3 Configuring >> busybox 1.19.3 Building >> busybox 1.19.3 Installing to target >> xenomai 2.6.0 Extracting >> xenomai 2.6.0 Patching package//xenomai >> xenomai 2.6.0 Updating config.sub and config.guess >> xenomai 2.6.0 Patching libtool >> xenomai 2.6.0 Configuring >> xenomai 2.6.0 Building >> xenomai 2.6.0 Installing to staging directory >> xenomai 2.6.0 Installing to target >> at91bootstrap 1.16 Extracting >> at91bootstrap 1.16 Patching boot//at91bootstrap >> at91bootstrap 1.16 Configuring >> at91bootstrap 1.16 Building >> at91bootstrap 1.16 Installing to images directory >> uboot 2010.06 Extracting >> uboot 2010.06 Patching boot//uboot >> uboot 2010.06 Configuring >> uboot 2010.06 Building >> uboot 2010.06 Installing to target >> uboot 2010.06 Installing to images directory >> linux 2.6.38.8 Download additional patches >> linux 2.6.38.8 Extracting >> linux 2.6.38.8 Patching /package/linux >> host-module-init-tools 3.12 Extracting >> host-module-init-tools 3.12 Patching package//module-init-tools >> host-module-init-tools 3.12 Updating config.sub and config.guess >> host-module-init-tools 3.12 Patching libtool >> host-automake 1.11.1 Extracting >> host-automake 1.11.1 Patching package//automake >> host-automake 1.11.1 Updating config.sub and config.guess >> host-automake 1.11.1 Patching libtool >> host-autoconf 2.65 Extracting >> host-autoconf 2.65 Patching package//autoconf >> host-autoconf 2.65 Updating config.sub and config.guess


76

>> host-autoconf 2.65 Patching libtool >> host-m4 1.4.15 Extracting >> host-m4 1.4.15 Patching package//m4 >> host-m4 1.4.15 Updating config.sub and config.guess >> host-m4 1.4.15 Patching libtool >> host-m4 1.4.15 Configuring >> host-m4 1.4.15 Building >> host-m4 1.4.15 Installing to host directory >> host-libtool 2.2.10 Patching package//libtool >> host-libtool 2.2.10 Updating config.sub and config.guess >> host-libtool 2.2.10 Building >> host-libtool 2.2.10 Installing to host directory >> host-autoconf 2.65 Configuring >> host-autoconf 2.65 Building >> host-autoconf 2.65 Installing to host directory >> host-automake 1.11.1 Configuring >> host-automake 1.11.1 Building >> host-automake 1.11.1 Installing to host directory >> host-module-init-tools 3.12 Autoreconfiguring >> host-module-init-tools 3.12 Configuring >> host-module-init-tools 3.12 Building >> host-module-init-tools 3.12 Installing to host directory >> host-uboot-tools 2011.03 Extracting >> host-uboot-tools 2011.03 Patching package//uboot-tools >> host-uboot-tools 2011.03 Configuring >> host-uboot-tools 2011.03 Building >> host-uboot-tools 2011.03 Installing to host directory >> linux 2.6.38.8 Configuring >> linux 2.6.38.8 Building >> linux 2.6.38.8 Installing to target >> linux 2.6.38.8 Installing to images directory >> host-fakeroot 1.9.5 Extracting >> host-fakeroot 1.9.5 Patching package//fakeroot >> host-fakeroot 1.9.5 Updating config.sub and config.guess >> host-fakeroot 1.9.5 Patching libtool >> host-fakeroot 1.9.5 Configuring >> host-fakeroot 1.9.5 Building >> host-fakeroot 1.9.5 Installing to host directory >> host-makedevs undefined Extracting >> host-makedevs undefined Patching package//makedevs >> host-makedevs undefined Configuring >> host-makedevs undefined Building >> host-makedevs undefined Installing to host directory >> Generating root filesystem image rootfs.tar

Toda a compilação é feita dentro do directório "output", e os seguintes directórios são criados dentro desse directório:

• build: onde o kernel e os pacotes do sistema de ficheiros (rootfs) são compilados;

• host: ferramentas para compilação cruzada dos pacotes;

• images: imagens geradas do kernel e do sistema de ficheiros (rootfs);

CAPITULO 4


• staging: ferramentas para compilação cruzada (toolchain) geradas;

• stamps: directório de controlo do buildroot;

• target: estrutura de directórios e arquivos do sistema de ficheiros (rootfs) final;

• toolchain: onde as ferramentas para compilação cruzada (toolchain) foram compiladas. Neste projecto criam-se dois sistemas distintos. Um para a plataforma de hardware desenvolvida neste projecto e outra para a placa versatilepb para emulação com o emulador de hardware QEMU. Esta placa é uma placa de desenvolvimento da própria ARM, Lda. e pode ser consultada na seguinte hiperligação:

• http://www.arm.com/products/tools/development-boards/versatile/index.php Por fim, ainda para verificação do correcto funcionamento da toolchain gerada pelo buildroot faz-se uma compilação cruzada, de x86 para ARM, e testa-se a sua execução.

4.4.3 RTOS para a plataforma desenvolvida

Este sistema é criado para o equipamento desenvolvido neste projecto, o que implica que se tem que aplicar algumas “alterações”, na forma de patches, ao kernel Linux. Assim, essas alterações são efectuadas aplicando os seguintes patches:

• microkernel ADEOS: pacote de software ADEOS para criar o microkernel de tempo-real, disponível em: http://download.gna.org/adeos/patches/v2.6/arm/ adeos-ipipe-2.6.38.8-arm-1.18-03.patch;

• Xenomai: Este pacote de software são extensões ao kernel Linux que oferecem suporte a tarefas com restrições temporais críticas, disponível em http://download.gna.org/xenomai/stable/.

• AT91 linux 2.6: Este patch criado para a família de microcontroladores ARM da ATMEL, altera os ficheiros do kernel onde estão as configurações e drivers relativos aos processadores e placas de desenvolvimento ATMEL. A versão a utilizar será a criada para o kernel versão 2.6.38, disponível em: http://maxim.org.za/at91_26.htm.l;

Deve-se sempre verificar a compatibilidade dos diversos pacotes de software. Nesta implementação foi utilizado o kernel Linux 2.6.38.8, o Xenomai 2.6.0 e o Adeos 1.18-03. Assim, as configurações no buildroot seriam as seguintes:

• Target Architecture: arm;

• Target Architecture Variant: arm926t;

• Target ABI: EABI;

• Toolchain: Toolchain: buildroot toolchain; kernel headers: 2.6.38.38

uClibs: 0.9.32.x binutos: 2.21.1


78

gcc: 4.3.x target optimizations: -ipipe

• System configuration: hostname: ARM9BOARD banner: Sistema embebido de tempo real baseado em Linux - ADRIANO

CAMPOS - MACSE - ISEC2011.

• Package Selection for the target: busybox: 1.19.x

Real-Time: Xenomai User-space: 2.6.0 Xenomai ARM CPU Type: Atmel AT91SAM926X

Networking applications: ntp: sntp (simple network time protocol) ntp: ntpd (time synchronization daemon)

• Filesystem images: jffs2 root filesystem: Flash type: NAND FLASH with 2kB page and 128 kb

erase size

• Bootloaders: u-boot version: 2010.06

u-boot binary format: u-boot.bin

• Kernel: kernel version: same as toolchain kernel headers configuration file path: at91sam9260ek;

kernel binary image: uImage; custom kernel patches: http://maxim.org.za/AT91RM9200/2.6/2.6.33-

at91.patch.gz linux kernel extensions: ADEOS/XENOMAI real-time patch: adeos-ipipe-

2.6.38.8-arm-1.18-03.patch

4.4.4 Sistema operativo para a Plataforma versatilepb

Esta versão é criada para se emular no software de emulação de arquitecturas de hardware, o QEMU. Nesta versão não é possível fazer as alterações para tempo-real, porque a máquina ARM que é emulada, a versatilepb, não é suportada pelo projecto ADEOS/Xenomai. Esta emulação será demonstrada na Secção 4.6.2 deste relatório. As configurações foram carregadas com o ficheiro "qemu_arm_versatile_defconfig", disponibilizado na directoria "/buildroot/configs" e que faz a seguinte configuração:

• Target Architecture: arm;

• Target Architecture Variant: arm926t;

• Target ABI: EABI;

• Toolchain: Toolchain: buildroot toolchain; kernel headers: 3.1.4 uClibs: 0.9.32.x binutos: 2.21.1

CAPITULO 4


gcc: 4.3.x target optimizations: -ipipe

• System configuration: hostname: ARM9BOARD_QEMU

banner: Sistema embebido de tempo real baseado em Linux - ADRIANO CAMPOS - MACSE - ISEC2011.

• Package Selection for the target: busybox : 1.19.x

• Filesystem images: cpio the root filesystem: compression method gzip

• Kernel: kernel version: same as toolchain kernel headers. configuration file path: buildroot/board/qemu/arm-versatile/linux-3.1.config.

kernel binary format: zImage;

4.4.5 Compilação cruzada de um programa

Neste ponto é criado um pequeno programa em linguagem C e faz-se uma compilação cruzada para ARM. Para compilar usa-se a toolchain criada pelo buildroot, na Secção 4.4.2. O programa escrito em linguagem C será o seguinte:

#include<stdio.h> int main() printf("GNU/LINUX\n\n"); printf("Mestrado em Automação e Comunicações em Sistemas de Energia\n\n"); printf("Adriano José Ribeiro Campos\n\n"); return 0;

Depois de gravar este ficheiro como "x86toARM.c" usa-se o compilador arm-linux-gcc, para ARM, gerado pelo buildroot, para criar uma aplicação que será posteriormente testada no QEMU. Então a compilação é realizada, dentro da pasta "buildroot/output/host/usr/" executando na consola:

# ./bin/arm-linux-gcc x86toARM.c Se se experimentar executar a aplicação no ambiente x86, verifica-se que o sistema não a consegue executar o programa.

# ./a.out bash: ./a.out: impossível executar o arquivo binário

Então o que terá que se fazer é colocar o executável gerado na compilação “a.out” na

directoria do buildroot que contém o sistema de ficheiros do sistema da plataforma alvo e


80

voltar a executar o comando "make", para criar novamente o sistema de ficheiros da

plataforma alvo, como o executável dentro da directoria "/root".

# cp a.out ../../target/root/

Na Secção 4.6.3 será demonstrado a execução deste programa.

4.5 Carga do sistema na plataforma desenvolvida

Esta secção demonstra os passos necessários para configurar e carregar o software na plataforma de hardware, ambos desenvolvidos neste projecto e documentados neste relatório. São apresentadas duas soluções, uma baseada numa ferramenta da ATMEL, o SAM-BA e outra solução baseada numa solução genérica de inicialização e carregamento do sistema, típica em sistemas embebidos, o Das U-Boot. Soluções padronizadas e abertas como o TFTP e o Das U-Boot, devem sempre ser consideradas em primeiro lugar, porque estas soluções permitem migrar facilmente para produtos de outros fabricantes. Em sistemas embebidos, sempre que se inicia o desenvolvimento de um firmware para uma nova plataforma de hardware, deve-se entender o processo de arranque do sistema.

4.5.1 Sequência de arranque do sistema

Várias componentes de software estão envolvidas para iniciar o kernel Linux em produtos com microcontroladores da família SAM9. A sequência de arranque da família de microcontroladores AT91SAM é executada nas seguintes etapas (Figura 61):

• Bootloader de 1º nível: O processador após ser alimentado ou ser reiniciado, executa o código de inicialização presente na ROM. O código de inicialização da ROM inicia a CPU e o controlador de memória, executando apenas a inicialização mínima dos dispositivos integrados (on-chip), como a consola da porta série para fornecer mensagens de diagnóstico do arranque. A CPU após arrancar, verifica se uma aplicação de configuração do hardware válida está presente nos dispositivos de memória FLASH (nesta ordem, SD CARD e FLASH

NAND) com possibilidade de arranque. Se encontrar uma destas interfaces disponíveis, carrega os primeiros 4KB para a SRAM e executa. Se não encontrar nenhuma aplicação válida nos dispositivos de memória FLASH, passa a execução para um código de arranque chamado SAM-BA. Este é um software de recuperação, que pode ser usado para se comunicar com um computador via USB para escrever na memória FLASH. O uso do SAM-BA é uma estratégia interessante, quando não existe uma memória FLASH NOR com um bootloader para gravar o Das U-Boot na memória NAND FLASH. Pode-se então usar o SAM-BA para gravar o Das U-Boot na memória NAND FLASH, e a partir daí usar o Das U-Boot para gravar o kernel e o sistema de ficheiros. Portanto, se se apagar “acidentalmente” o bootloader (1º ou 2ª nível)da NAND FLASH, vai ser necessário o SAM-BA, para recuperá-lo. Os 4KB de código que o código ROM carregou para a SRAM no arranque é AT91BootStrap, um bootloader da ATMEL;

CAPITULO 4


• Bootloader de 2º nível (AT91Bootstrap): É um bootloader da ATMEL, responsável pela configuração do hardware. Este configura a memória SDRAM, inicializa os circuitos de clock e outros registos associados ao CPU e carrega um bootloader de 3º nível, que no nosso caso é o Das U-Boot. Carrega a binário da aplicação Das U-Boot da NAND FLASH para a SDRAM, e inicia o bootloader Das U-Boot. A partir daí, o processo é o mesmo de qualquer sistema com Linux embebido, sendo o Das U-Boot o responsável por carregar o kernel Linux para a memória e executá-lo;

• Bootloader de 3º nível (Das U-Boot): Aplicação genérica de arranque de sistemas embebidos, o Das U-Boot; É o bootloader encarregue de carregar o binário do kernel do sistema operativo da NAND FLASH, de uma interface Ethernet, de uma ligação USB, ou outro dispositivo e iniciar o sistema. O funcionamento desta aplicação será demonstrado na Secção 4.5.2 deste documento;

• kernel Linux: Arranque do kernel do sistema operativo. Depois de carregado na memória, o kernel do Linux, normalmente compactado, é descompactado antes de iniciar a sua execução. Logo em seguida, é exibida uma série de mensagens, no ecrã ou consola, enviadas pelo kernel, durante a detecção e configuração do hardware existente no computador. O kernel configura a memória cache, inicializa cada um dos dispositivos de hardware através da função "init" em cada driver, monta a raiz do sistema de arquivos e executa o processo "init", que é o processo "pai" de todos os processos no modo de utilizador. Todos os outros processos são denominados como sendo filhos deste e são monitorizados pelo "init". Este é o único processo que não pode ser abortado pelo sistema;

• Sistema de ficheiros (Root Filesystem): Inicialização das aplicações que serão executados no equipamento, usando os serviços do sistema operativo. Aquando da execução do primeiro programa ("init" ) que faz com que a compartilhada biblioteca em tempo de execução (do Inglês, runtime library) seja carregada. Num sistema Linux típico, o processo "init" é o primeiro programa executado pelo kernel na sua inicialização. Este lê o arquivo "/etc/inittab" para executar o script de controlo adequado, executado a partir de "/etc/rc.d", que executa os scripts de início para inicializar os serviços de rede e outros serviços do sistema. Os scripts de inicialização do Linux estão localizados na pasta “/etc/rc.d” (ou /etc em outras distribuições como a Debian).


82

Figura 61 - Sequência de arranque da família AT91SAM9XXX.

4.5.2 Bootloader Universal Das U-Boot

O Das U-Boot, ou simplesmente U-Boot, é uma solução genérica de inicialização e carregamento do sistema, típica em sistemas embebidos O fabricante do microcontrolador usado neste projecto, a ATMEL, disponibiliza uma ferramenta, o SAM-BA, que permite carregar todo o sistema na placa. Assim. como o Das U-Boot não tem suporte à interface SD/MMC, uma forma de carregar o kernel e o sistema de ficheiros (rootfs) é via interface Ethernet. Para isso, deve-se usar o protocolo TFTP para transferir os arquivos para o Das U-Boot para que este as grave na memória NAND FLASH. Após configurar o serviço TFTP, copia-se as imagens do kernel (uImage) e do sistema de ficheiros (rootfs.jffs2) para o directório do TFTP, liga-se e coloca-se o equipamento em rede com o computador de desenvolvimento e acedendo ao menu do Das U-Boot, está-se preparado para a transferir os arquivos. Assim, em primeiro lugar, configura-se os endereços MAC e IP da rede:

# setenv ethaddr 3e:36:65:ba:6f:be #setenv ipaddr 192.168.0.100 # setenv serverip 192.168.0.1 # saveenv

Para verificar a ligação, usa-se o comando ping:

# ping 192.168.0.1

CAPITULO 4


Para gravar a imagem do kernel Linux:

# tftp 0x72200000 uImage # nand erase 0x00200000 0x00200000 # nand write.e 0x72200000 0x00200000 0x00200000

Para gravar o sistema de ficheiros (rootfs):

# tftp 0x72200000 rootfs.jffs2 # nand erase 0x00400000 0x03C00000 # nand write.jffs2 0x72200000 0x00400000 0x180000

Por último, configurar o Das U-Boot para iniciar o Linux pela memória NAND FLASH:

#setenvbootargs'mem=64Mconsole=ttyS0,115200mtdparts=atmel_nand:4M(bootstrap/uboot/kernel)ro,60M(rootfs),-(data) root=/dev/mtdblock1 rw rootfstype=jffs2' # setenv bootcmd 'nand read.e 0x72200000 0x00200000 0x1ad8f0; bootm 0x72200000' # saveenv

4.5.3 Ferramenta SAM-BA da ATMEL

O fabricante ATMEL disponibiliza a ferramenta SAM-BA, que além de poder ser usada como ferramenta para recuperar o bootloader de 2º nível da NAND FLASH, pode também ser usada para gravar o kernel e o sistema de ficheiros (rootfs) na memória NAND FLASH ou no cartão SD. Este tópico descreve como carregar o Das U-Boot na memória de arranque (boot) com o software SAM-BA, sendo o processo semelhante para o kernel ou o sistema de ficheiros O software SAM-BA é um assistente de arranque, que permite facilmente programar os microcontroladores da família AT91SAM usando uma interface gráfica ou por linha de comandos. Para isso deve-se seguir os seguintes passos (ATMEL, 2010c):

• Ligar o interface USB Device do equipamento ao computador;

• Verificar que o controlador pode executar o bootROM monitor SAM-BA-boot;

• Apagar o conteúdo da FLASH interna, colocando o jumper J2 na posição 1-2;

• Ligar a alimentação à placa;

• Verificar se a conexão USB é estabelecida (a mensagem “ATMEL Board Teste AT91xxxxx” aparece na área de notificação da barra de tarefas);

• Colocar o jumper J2, na posição 2-3, para arrancar em modo de operação normal;

• Iniciar a aplicação SAM-BA GUI (figura 62);


84

Figura 62 - Software SAM-BA (ATMEL, 2010c).

• Seleccionar o hardware, escolher a ligação e seleccionar “Connect”;

• Na janela principal da aplicação SAM-BA (Figura 63);

• Optar pela memória apropriada (DATA FLASH, NAND FLASH, SDRAM, SRAM, etc.) na interface gráfica (indicação 1 na Figura 63);

• Inicializar a memória escolhendo no menu o script e pressionando em “execute” (indicação 2 na Figura 63);

• Seleccionar o ficheiro binário “u-boot.bin” e pressionar “open” (indicação 3 na Figura 63);

• Introduzir o correcto endereço da memória na caixa de texto “Address” (indicação 4 na Figura 63);

• Fechar o SAM-BA e remover o cabo USB (indicação 5 na Figura 63).

Figura 63 - Janela Principal do software SAM-BA (ATMEL, 2010c).

CAPITULO 4


4.6 Emulação de hardware com QEMU

Este secção sobre emulação de hardware com QEMU é baseada no artigo publicado no site IBM

DeveloperWorks (Jones M.,2007). Este artigo explora o QEMU e a sua arquitectura e exemplifica como emular um sistema operativo em arquitectura x86 e ARM.

4.6.1 Emular arquitectura x86

Após a instalação deve-se verificar o sucesso da mesma, bem como quais as plataformas disponíveis para emulação com arquitectura x86. Assim, caso a instalação tenha sido bem sucedida, pode ser visualizada a lista de plataformas suportadas, executando na consola:

$qemu -M ? Supported machines are: pc Standard PC (alias of pc-0.12) pc-0.12 Standard PC (default) pc-0.11 Standard PC, qemu 0.11 pc-0.10 Standard PC, qemu 0.10 isapc ISA-only PC

Emular uma outra máquina requer inicialmente as mesmas etapas que quando se instala e configura um computador novo. Assim, a primeira etapa é instalar o seu sistema operativo. O “computador novo” vai então precisar de local para instalar o sistema operativo, portanto é necessário criar o seu disco rígido. O QEMU disponibiliza um comando especial para criar um disco rígido chamado qemu-img. Este executável pode criar imagens com vários formatos, mas o melhor para o QEMU é o formato qcow (qemu copy-on-write). Para criar uma imagem, ou seja, um falso disco rígido onde o sistema operativo será instalado deve-se digitar o seguinte comando:

$qemu-img create –f qcow nome_do_disco.img 128M Onde: qcow é o formato do disco. nome_do_disco.img é o nome da imagem. 128M significa que o disco terá 128MB de espaço disponível.

Agora que o disco rígido foi criado, instala-se o sistema operativo nele. Para verificação do funcionamento do QEMU, inicialmente experimenta-se uma distribuição do GNU/Linux pequena chamada de cfLinux. Esta distribuição destina-se a sistemas embebidos, e encontra-se disponível para download no site oficial do projecto cfLinux, na seguinte hiperligação:

• ftp://ftp.cflinux.fu/pub/cflinux/iso/cflinux-1.0.iso Uma imagem ISO é um formato de CD-ROM, segundo o sistema de arquivos da norma internacional ISO9660. Agora existe um disco emulado (nome_do_disco.img) e um CD-ROM (cflinux-1.0.iso) a


86

partir do qual se pode instalar o sistema operativo. A instalação do sistema operativo com o QEMU faz-se seguindo os seguintes passos:

$qemu –hda disk.img –cdrom cflinux-1.0.iso –boot d Onde: -hda: especifica que é uma imagem de disco rígido. -boot d: especifica que o arranque do sistema (boot) é efectuado a partir do CD-ROM.

Após este passo, seguem-se as instruções de instalação, até que seja solicitado que se reinicie o computador, no caso, a máquina virtual. Após a instalação sempre para utilizar o “novo computador”, deve-se executar:

#qemu –hda nome_do_disco.img Como se pode verificar é um processo simples. O processo seria exactamente o mesmo se se pretendesse instalar e efectuar boot a qualquer outro sistema operativo ou arquitectura de hardware.

4.6.2 Emular arquitectura ARM

Igualmente para ARM, é apresentada a lista de plataformas suportadas, ao executar na consola:

$qemu-system-arm -M ? Supported machines are: syborg Syborg (Symbian Virtual Platform) musicpal Marvell 88w8618 / MusicPal (ARM926EJ-S) mainstone Mainstone II (PXA27x) n800 Nokia N800 tablet aka. RX-34 (OMAP2420) n810 Nokia N810 tablet aka. RX-44 (OMAP2420) cheetah Palm Tungsten|E aka. Cheetah PDA (OMAP310) sx1 Siemens SX1 (OMAP310) V2 sx1-v1 Siemens SX1 (OMAP310) V1 tosa Tosa PDA (PXA255) akita Akita PDA (PXA270) spitz Spitz PDA (PXA270) borzoi Borzoi PDA (PXA270) terrier Terrier PDA (PXA270) connex Gumstix Connex (PXA255) verdex Gumstix Verdex (PXA270) lm3s811evb Stellaris LM3S811EVB lm3s6965evb Stellaris LM3S6965EVB realview-eb ARM RealView Emulation Baseboard (ARM926EJ-S) realview-eb-mpcore ARM RealView Emulation Baseboard (ARM11MPCore) realview-pb-a8 ARM RealView Platform Baseboard for Cortex-A8 realview-pbx-a9 ARM RealView Platform Baseboard Explore for Cortex-A9 versatilepb ARM Versatile/PB (ARM926EJ-S) versatileab ARM Versatile/AB (ARM926EJ-S) integratorcp ARM Integrator/CP (ARM926EJ-S) (default)

CAPITULO 4


Na página oficial do projecto QEMU estão disponíveis para download, imagens prontas a usar para testar as diversas plataformas suportadas pelo QEMU. Neste caso descarrega-se e descompacta-se a demonstração para ARM, com os seguintes comandos:

$wget http://wiki.qemu.org/download/arm-test-X.Y.tar.gz $tar -xvf arm-test-X.Y.tar.gz $cd arm-test $ls arm_root.img README zImage.integrator

Com o último comando de listagem de ficheiros, verifica-se o conteúdo do pacote de software descarregado. Vai-se então utilizar o QEMU para emular a imagem do kernel “zImage.integrator” compilada para a plataforma integrator que é a versão predefinida do QEMU para ARM (Secção 6.4) e o sistema de ficheiros “arm_root.img”. A opção "-initrd" especifica uma imagem do sistema de ficheiros para carregar como um disco de RAM inicial. Durante a inicialização o kernel irá montar este disco RAM como sistema de arquivos raiz e procurar um executável “init” para iniciar o sistema. No caso deste projecto o executável “init” é fornecido pelo Busybox. Assim, na consola deve ser executado o seguinte comando:

$qemu-system-arm -kernel zImage.integrator -initrd arm_root.img ou para emulação em linha de comandos :

$qemu-system-arm -kernel zImage.integrator -initrd arm_root.img -nographic Se for usada a opção com ambiente gráfico, o sistema emulado deverá aparecer tal como a imagem do ecrã, apresentada na Figura 64.


88

Figura 64 -QEMU com ambiente gráfico

Para emular o sistema GNU/Linux criado com o Buildroot para a plataforma ARM versatilepb, executa-se o QEMU, com os parâmetros relativos ao tipo de plataforma, ao kernel e ao sistema de ficheiros:

#qemu-system-arm -M versatilepb -kernel output/images/zImage -initrd output/images/rootfs.cpio.gz -nographic Uncompressing Linux... done, booting the kernel.

Após o QEMU descompactar o Linux e arrancar o sistema está disponível uma consola de comandos, onde se faz inicialmente o login. No seguinte excerto copiado da consola, pode-se verificar alguns dos comandos típicos do Linux. O comando "uname -a" dá a informação sobre a versão do kernel Linux, a data e hora do sistema e a referência do núcleo do processador. O comando "cat /proc/cpuinfo" dá toda a informação relativa ao processador e ao hardware, como se pode verificar nas linhas seguintes.

Sistema embebido de tempo real baseado em Linux - ADRIANO CAMPOS - MACSE - ISEC2011 ARM9BOARD_QEMU login: root # ls / bin etc init linuxrc opt root sys usr dev home lib mnt proc sbin tmp var # uname -a Linux ADRIANO 2.6.38.8 #1 Mon Nov 28 12:45:39 WET 2011 armv5tejl GNU/Linux

CAPITULO 4


# cat /proc/cpuinfo Processor : ARM926EJ-S rev 5 (v5l) BogoMIPS : 328.49 Features : swp half thumb fastmult vfp edsp java CPU implementer : 0x41 CPU architecture: 5TEJ CPU variant : 0x0 CPU part : 0x926 CPU revision : 5 Hardware : ARM-Versatile PB Revision : 0000 Serial : 0000000000000000

4.6.3 Testar uma aplicação ARM.

Este ponto demonstra a execução do programa criado com compilação cruzada na Secção 4.4.5. O ficheiro binário “a.out” que encontra-se na pasta “/root” do sistema de ficheiros criado, foi colocado para verificar o funcionamento da toolchain gerada pelo buildroot. Assim executando na consola o QEMU:

#qemu-system-arm -M versatilepb -kernel output/images/zImage -initrd output/images/rootfs.cpio.gz –nographic

Uncompressing Linux... done, booting the kernel. Sistema embebido de tempo real baseado em Linux - ADRIANO CAMPOS - MACSE - ISEC2011 ARM9BOARD_QEMU login: root # # ls /root/ a.out # ./a.out GNU/LINUX

Mestrado em Automação e Comunicações em Sistemas de Energia Adriano José Ribeiro Campos #

Assim verifica-se o funcionamento da toolchain gerada pelo buildroot.

4.7 Conclusões

Este capítulo, essencialmente prático, descreve detalhadamente todos os passos necessários para desenvolver uma plataforma de software baseada em soluções GNU/Linux, com características de tempo-real, para sistemas embebidos. Sempre que possível foi utilizada a técnica de emulação de hardware para verificar e visualizar alguns dos passos deste processo, nomeadamente a criação da imagem do kernel Linux para ARM, a criação do sistema de ficheiros e a verificação da toolchain. O processo de arranque do sistema, carga do sistema na placa, e outras configurações relativas ao hardware desenvolvido neste projecto, foram igualmente abordadas com detalhe.

CAPITULO 5


5 CONCLUSÕES

O contributo principal deste trabalho de projecto consiste na apresentação de uma metodologia para projecto e implementação de um sistema embebido de tempo-real baseado em Linux. O projecto aborda todas as etapas necessárias para a implementação de um sistema embebido, desde a pesquisa e especificação até a validação e simulação, passando pelo projecto dos circuitos electrónicos, desenho de hardware e desenvolvimento de software. As conclusões deste trabalho de projecto são apresentadas neste capítulo, são constituídas pelas conclusões relativas a cada um dos módulos de software e hardware que integram o projecto, um conjunto de conclusões finais e ainda uma secção sobre trabalhos futuros. Estão assim organizadas nos seguintes subcapítulos:

• Subcapítulo 5.1: Conclusões relativas ao desenvolvimento de hardware;

• Subcapítulo 5.2: Conclusões relativas ao desenvolvimento de software;

• Subcapítulo 5.3: Conclusões finais do projecto;

• Subcapítulo 5.4: Trabalhos futuros;

5.1 Desenvolvimento de hardware

O desenvolvimento de hardware é por si só uma tarefa exigente e minuciosa e requer um elevado nível de conhecimentos da área da electrónica, especialmente sobre os circuitos electrónicos associados ao microcontrolador, memórias e comunicações industriais. O desenvolvimento deste hardware requer um elevado grau de experiência neste tipo de projectos, devido à elevada frequência de funcionamento quando comparada com projectos comuns desenvolvidos anteriormente com microcontroladores de 8 bits. Interferências electromagnéticas, descargas electrostáticas, efeitos parasitas e outras fontes de interferências externas e/ou internas foram sempre consideradas no projecto do hardware. Igualmente, no desenho dos esquemas eléctricos, foram sempre consultadas e analisadas as notas de aplicação dos fabricantes dos respectivos componentes. No entanto, um circuito aparentemente bem projectado pode apresentar problemas de funcionamento quando ensaiado. Por essa razão os projectos de hardware são por vezes tarefas ingratas para além de envolverem muito trabalho. No entanto, muito gratificantes quando terminadas com sucesso. O projecto de hardware é no entanto facilitado e com um resultado final mais fiável quando é realizado com software avançado, especifico para o desenho e verificação de circuitos electrónicos. O software utilizado neste projecto, o Altium Design, mostrou-se uma excelente ferramenta e é em parte responsável pelo bom resultado obtido. Tendo em conta as especificações e dimensões das placas de circuito impresso, resultantes do formato da caixa escolhida, a possibilidade de desenho em 3D permitiu validar o projecto em termos mecânicos, verificar os footprints dos componentes electrónicos mais complexos e ainda verificar que as duas placas que constituem o equipamento encaixam uma na outra sem sobreposição. Refira-se que sem esta funcionalidade, teria que ser efectuada uma verificação manual, o que normalmente implicaria várias interacções até afinar o desenho, aumentando os custos e tempos de desenvolvimento.

CONCLUSÕES

92

O Altium Design tem ainda a vantagem de estar também disponível numa versão trial e outra em modo de só leitura, ambas gratuitas. A versão só de leitura proporciona uma facilidade de interacção entre os engenheiros de projecto e o pessoal externo ao desenvolvimento. Assim conclui-se que o software Altium Design é uma ferramenta consistente para projectos avançados de sistemas embebidos. Existem no mercado outras aplicações de software para esta função, de utilização gratuita, no entanto, ficam muito aquém deste ao nível do projecto mecânico e da interacção 3D, sendo também normalmente limitados ao nível do número de componentes e camadas da placa de circuito impresso. Ao nível da arquitectura escolhida, a arquitectura ARM, apenas podem ser apontadas vantagens. Estas vantagens reflectem-se na sua elevada aplicação em diversas áreas de produtos que utilizam sistemas embebidos e não só. Sendo suportada por diversas plataformas de hardware e sistemas operativos genéricos, permite um menor tempo de desenvolvimento de aplicações e uma maior facilidade de aquisição de ferramentas de desenvolvimento e de documentação. Mesmo existindo no mercado empresas especializadas em ferramentas e aplicações proprietárias para ARM, as soluções gratuitas também apresentam elevada qualidade e permitem implementar projectos confiáveis, seguros e especialmente competitivos para aplicações em sistemas industriais. Entre os diversos fabricantes que implementam a arquitectura ARM, conclui-se que a opção pelo fabricante ATMEL foi uma boa aposta. Os motivos prendem-se pelo suporte, nomeadamente, a documentação e notas de aplicação de boa qualidade, que ajudam e aceleram o desenvolvimento de um sistema embebido. Os circuitos associados ao microcontrolador e às memórias são baseados na placa de desenvolvimento da ATMEL para o microcontrolador escolhido, o que permite elevar o grau de confiança no projecto final, para além de facilitar a adaptação dos exemplos de software fornecidos pelo fabricante, diminuindo o tempo de desenvolvimento. Este projecto foi desenvolvido até à etapa de preparação da produção do protótipo. Todos os ficheiros e dados necessários para a produção dos circuitos impressos, instalação dos componentes e listas de material foram produzidos e verificados. É de esperar que sejam necessários alguns ajustes na fase de colocação em funcionamento. No entanto, para minimizar esses ajustes, todos os aspectos a considerar foram tratados no projecto muito detalhado do hardware, inclusive com um modelo 3D utilizando dimensões reais dos componentes, assim como numa simulação exaustiva do firmware, utilizando um emulador da arquitectura.

5.1.1 Análise de custos do desenvolvimento do hardware

Os custos de implementação do equipamento são baseados em orçamentos obtidos nos sites da Internet do respectivo fornecedor. Para os circuitos impressos foi seleccionado um dos mais conhecidos fornecedores europeus, a Eurocircuits. Este fornecedor, com sede na Bélgica, tem a sua produção na Alemanha e na Hungria. Para a montagem dos componentes foi seleccionado o fornecedor Chinês, a Onestopassembly. Ambos têm a possibilidade de orçamentação online, nas respectivas hiperligações:

• http://be.eurocircuits.com/Basic/ecbasket/order.aspx?lang=en

• http://www.onestopassembly.com/how-to-quote.html

CAPITULO 5


Assim, a Tabela 21 apresenta os custos de implementação para 1 unidade, que seria um protótipo, e 100 unidades que seria uma produção em massa.

Descrição Preço x1 Preço x100

Placa de circuito impresso “MAIN BOARD” 91.25 5,09

Componentes da placa “MAIN BOARD” 41,88 26,52

Assemblagem dos componentes “MAIN BOARD” 677,73 53,93

Placa de circuito impresso “CPU BOARD” 169,73 7,73

Componentes da placa “CPU BOARD” 95,23 62,64

Assemblagem dos componentes “CPU BOARD” 746,67 67,9

Base da caixa 21,25 12,75

Topo da caixa 17,83 10,7

TOTAL 1.770,32 € 247,26 €

Tabela 21 - Custos de produção do equipamento para 1 unidade e 100 unidades.

Estes preços, especialmente os relativos à montagem, são apenas indicativos e uma consulta personalizada pode reduzir os custos. No entanto, podemos retirar conclusões destes valores. A primeira conclusão é que os custos de produção de um protótipo são sempre elevados comparados com preços de produção em série. Esta discrepância deve-se essencialmente aos custos que os fornecedores têm para configurar as máquinas de produção e configurar a linha de produção para o respectivo trabalho. Outra conclusão é que os custos da montagem, mesmo para a produção em série, têm um peso elevado no custo final do produto, podendo mesmo ultrapassar o custo dos componentes. No entanto, o valor unitário de cada produto, quando produzido em lotes de 100 unidades, é bastante competitivo comparando com soluções comerciais de automação industrial com as mesmas especificações.

5.2 Desenvolvimento de firmware

Após se ter atingido com êxito, com muita dedicação e trabalho, os objectivos propostos para este projecto, conclui-se que este trabalho proporcionou um contacto muito interessante e de muita aprendizagem sobre o funcionamento de sistemas operativos genéricos e de tempo-real, protocolos de comunicação em ambiente industrial, estrutura e funcionamento do kernel Linux, funcionamento e método de trabalho das comunidades Open Source, etc. O trabalho desenvolvido permite afirmar com muitas certeza que o kernel Linux e as aplicações GNU são uma solução viável, segura e confiável, para a implementação de sistemas embebidos, mesmo quando são exigidos requisitos de tempo-real. A aplicação Buildroot, também disponibilizada por licença GNU, mostrou-se uma solução intuitiva e funcional para a construção de um sistema completo. Estas soluções, por serem totalmente abertas, permitem que sejam facilmente configuráveis e personalizáveis. Sendo gratuitas permitem construir produtos com um elevado potencial competitivo. A experiência obtida neste projecto permite afirmar que, a dificuldade de desenvolvimento de aplicações baseadas em soluções GNU/Linux, consiste na descentralização da informação. Esta

CONCLUSÕES

94

dificuldade é típica quando se trabalha com aplicações e ferramentas baseadas em software livre. Mesmo com elevada disponibilidade dos responsáveis da manutenção deste tipo de projectos, por vezes torna-se complexo ultrapassar certos problemas. Os problemas consistem na grande maioria das vezes na incompatibilidade de versões, entre compiladores, debuggers, patches, ferramentas de desenvolvimento, etc. Mesmo não tendo sido construído fisicamente o hardware, os diversos constituintes de software foram cuidadosamente analisados e simulados com elevado pormenor e realismo num emulador de hardware, nomeadamente a aplicação do projecto QEMU, prevendo-se poucos problemas para a implementação e debug da versão base. Aliás, a emulação de hardware é uma técnica cada vez mais utilizada, com o intuito de simplificar o desenvolvimento de sistemas embebidos. Com este trabalho passou-se a compreender melhor as potencialidades do kernel Linux, em que o facto de ser razoavelmente pequeno e totalmente personalizável, permite-nos colocar um sistema operativo genérico numa aplicação com recursos limitados, seleccionando apenas as componentes e as aplicações necessárias. Com um sistema operativo genérico a construção de aplicações é facilitada e permite a portabilidade das mesmas.

5.1 Conclusões gerais

Tendo sido projectado, elaborado e verificado todo o material necessário para a construção do protótipo, incluindo a modelização 3D do hardware, e tendo sido simulado detalhadamente todo o software num emulador de hardware da arquitectura alvo, pode-se afirmar que os objectivos do projecto foram alcançados com sucesso. Ao longo deste trabalho foi dada preferência às tecnologias estudadas e aplicadas no Mestrado em Automação e Comunicações em Sistemas de Energia, tendo sido o conhecimento adquirido fundamental para o sucesso atingido. Com o desenvolvimento deste projecto, complementaram-se os conhecimentos adquiridos no mestrado, especialmente nas áreas da automação industrial, sistemas embebidos, kernel Linux, controlo industrial, sistemas operativos de tempo-real, projecto de hardware e software, etc. Em síntese, os conceitos estudados e implementados neste projecto que podem trazer mais-valias para aplicações em sistemas industriais são:

• Arquitectura ARM, com evolução contínua e com bom suporte, quer de documentação, quer de ferramentas de desenvolvimento;

• Projecto de software baseado totalmente em software gratuito, permite reduzir custos de desenvolvimento;

• Diversos drivers para periféricos e protocolos de comunicação disponibilizados pela solução GNU/Linux;

• Sistema operativo de tempo-real, baseado em soluções GNU/Linux;

• Protocolo para automação industrial utilizando Ethernet segundo a norma IEEE1588;

CAPITULO 5


• Diversos protocolos para automação industrial (CAN, RS232, RS485, USB e Ethernet);

• Estrutura modular do equipamento, permitindo efectuar um barramento entre diversos módulos, construindo assim uma estrutura expansível.

A versatilidade do sistema desenvolvido neste projecto oferece elevada aplicabilidade em diferentes áreas de produção ou sectores económicos, podendo constituir a base para um módulo para aplicações industriais produzido em larga escala. Apresenta características que permitem criar uma solução competitiva, robusta e personalizável, requisitos essenciais para os sistemas industriais. Finalmente, ao nível do desenvolvimento pessoal, foi extremamente gratificante projectar e implementar com sucesso todos os componentes deste sistema. Considera-se que este trabalho representa uma mais-valia muito importante para projectos futuros de software e/ou hardware em que o autor possa vir a estar envolvido a nível profissional ou académico.

5.2 Trabalho futuro

Nesta secção, pretende-se fazer o levantamento de algumas questões que foram deixadas em aberto ou que surgiram durante o desenvolvimento e que merecem um tratamento futuro, de modo a melhorar o projecto e a alargar o âmbito da sua aplicação. Algumas destas ideias podem parecer um pouco fora do âmbito da automação industrial, no entanto, permitiriam adquirir conhecimentos adicionais sobre tecnologias muito abrangentes. Os possíveis trabalhos futuros que foram identificados pelo autor e orientadores são os seguintes:

• Acrescentar ao hardware uma FPGA, permitindo criar uma plataforma de hardware configurável;

• Implementar uma comunicação Wireless;

• Verificar as características especiais do microcontrolador, nomeadamente, processamento de código Java e módulo DSP;

• Verificar as potencialidades do interface para sensor de imagem do microcontrolador, disponibilizado no hardware em fichas de pinos genéricos. O sensor de imagem deverá funcionar segundo a norma ITU-R BT. 601/656;

• Implementar uma interface gráfica genérica, por exemplo VGA. Por fim, espera-se que o trabalho apresentado neste projecto, e as novas ideias para trabalho futuro, contribuam para incentivar novos projectos e desenvolvimentos na área dos sistemas embebidos de tempo-real, quer no estabelecimento de ensino onde surgiu este projecto, quer noutras instituições e empresas. Este trabalho representa também uma promoção dos produtos tecnológicos de desenvolvimento nacional, que possam implementar soluções competitivas, contribuindo para um melhor desempenho do sistema produtivo nacional. .

REFERÊNCIAS BIBLIOGRAFICAS


REFERÊNCIAS BIBLIOGRÁFICAS

AcmeSystems (2011) http://www.acmesystems.it/?id=NETUSG20 Netus G20 micro module consultado em 10 de Março de 2011 ARM (2011a). http://www.arm.com/products/processors/ ARM - The Architecture For The Digital World - Processors (página Internet oficial), consultado em 03 de Agosto de 2011 ARM (2011b). http://www.arm.com/products/processors/ ARM - The Architecture For The Digital World - Company Profile (página Internet oficial) consultado em 18 de Setembro de 2011 Alecrim, E. (2011) Tecnologia USB (Universal Serial Bus) http://www.infowester.com/usb.php

InfoWester 2011 consultado em 2 de Setembro de 2011 ATMEL (2008) http://www.atmel.org/dyn/resources/prod_documents/doc6311.pdf AT91SAM9XE-EK Evaluation Board User Guide ATMEL (2009) http://www.atmel.com/dyn/resources/prod_documents/doc6420.pdf AT91SAM9XE Microcontroller Series Schematic Check List ATMEL (2010a) http://atmel.com/dyn/resources/prod_documents/doc6254.pdf AT91 ARM Thumb Microcontrollers AT91SAM9XE128/256/512 ATMEL(2010b)http://www.atmel.com/dyn/products/tools_card.asp?tool_id=17236&category_id=163&family_id=605&subfamily_id=1964 Atmel PLL LFT Filter Calculator ATMEL (2010c) http://www.at91.com/linux4sam/bin/view/Linux4SAM/U-Boot Load u-boot on AT91 boards Barry, R. (2010) USING THE FREERTOS REAL TIME KERNEL A practical Guide LPC17XX Edition, 2010 Real Time Engineers Ltd Brudna, C. (2000) Desenvolvimento de Sistemas de Automação Industrial Baseados em Objectos Distribuídos em Barramento CAN Tese de Mestrado, Departamento de Engenharia Eléctrica, Porto Alegre, Brasil. Embest Info (2011a) http://www.embedinfo.com/english/product/lpc2000b.asp LPCEB2000-B Processor Board consultado em 20 de Março de 2011 Embest Info (2011b) http://www.embedinfo.com/en/list.asp?id=99 ATMEL SAM9G45 ARM9 Board(LCD Optional purchase) consultado em 20 de Março de 2011


98

Embest Info (2011c) http://www.embedinfo.com/en/list.asp?id=72 ATMEL SAM9G45 ARM9 Board consultado em 20 de Março de 2011 Fernandes, J. (2000) MIDAS: Metodologia Orientada ao Objecto para Desenvolvimento de Sistemas Embebidos Tese de Doutoramento, Escola de Engenharia da Universidade do Minho, Braga, Portugal. FriendlyARM (2011a) http://www.friendlyarm.net/products/micro2440 Micro2440 | S3C2440 ARM9 Stamp Module consultado em 5 de Março de 2011 FriendlyARM (2011b) http://www.friendlyarm.net/products/ Mini2440 | S3C2440 ARM9 Board consultado em 6 de Março de 2011 Free Electrons (2010) http://free-electrons.com/doc/toolchains.pdf Embedded Linux system development Crosscompiling toolchains, consultado em 20 de Outubro de 2011. Harper, A et al (2011) Gray Hat Hacking 3rd ed. - THe ethical hacker's Handbook. McGraw Hill Osborne Media; 3 edition English ISBN: 978-0-07-174255-9 IXXAT (2011) http://www.ixxat.com/introduction_ieee_1588_en.html IEEE 1588 PTP Introduction Jones, M (2007) Emulação do Sistema com o QEMU http://www.ibm.com/developerworks/br/library/l-qemu/ IBM DeveloperWorks, consultado em 5 de Outubro de 2011. MSC (2011)] http://www.msc.de/en/news/pressroom/newsletter/atmel/nl/2724-www.html MSC Vertriebs GmbH consultado em 12 de Agosto de 2011 MSC-GE (2011)] http://www.msc-ge.com/en/produkte/elekom/mc/atmel/3526-www/1619-www/4660-www/1824-www.html?locale=en MSC Vertriebs GmbH consultado em 18 de Outubro de 2011 NIST (2010) http://www.nist.gov/el/isd/ieee/intro1588.cfm IEEE 1588TM Standard for A Precision Clock Synchronization Protocol for Networked Measurement and Control Systems NS (2008) http://www.national.com/an/AN/AN-1469.pdf PHYTER® Design & Layout Guide NS (2010) http://www.national.com/ds/DP/DP83640.pdf DP83640 Precision PHYTER - IEEE® 1588 Precision Time Protocol Transceiver LinuxDevices (2007) http://www.linuxfordevices.com/c/a/Linux-For-Devices-Articles/ Snapshot of the embedded Linux market -- April, 2007, consultado em 11 de Julho de 2011.



OLIMEX (2011a) http://www.olimex.com/dev/lpc-h3131.html LPC-H3131 LOW COST COMPACT LPC3131 HIGH SPEED USB HEADER DEVELOPMENT PROTOTYPE BOARD consultado em 19 de Março de 2011 OLIMEX (2011b) http://www.olimex.com/dev/cs-e930x.html CS-E9302 DEVELOPMENT BOARD FOR EP9301/EP9302 ARM920T MICROCONTROLLER WITH USB, RS232, ETHERNET AND COMPACT FLASH CONNECTOR consultado em 20 de Março de 2011 Rath, D. (2005) Open On-Chip Debugger – Design and Implementation of an On-Chip Debug Solution for Embedded Target Systems based on the ARM7 and ARM9 Family Diploma Thesis, University of Applied Sciences Augsburg Department of Computer Science. RIBEIRO, M (1999) Automação Industrial, Tec Treinamento e Consultodoria Ltda, 4ºEdição, Salvador, Outono 1999. GEEK (2011) http://www.geek.com.br/posts/11036-entenda-os-processadores-arm Entenda os processadores ARM TECHSPOT (2011) http://www.techspot.com/news/44757-isuppli-arm-to-power-a-quarter-of-new-

notebooks-by-2015.html TechSpot | PC Technology News and Analysis, consultado em 12 de Setembro de 2011 TI (2008) http://www.ti.com/lit/ds/symlink/tps3808-ep.pdf Datasheet TPS3808-EP LOW QUIESCENT CURRENT, PROGRAMMABLE DELAY SUPERVISORY CIRCUIT TI (2011) http://www.ti.com/tool/ekt-lm3s8962 EKT-LM3S8962 Ethernet+CAN Evaluation Kits with Code Red Technologies Tool consultado em 30 de Março de 2011 WIKIPEDIA (2011). http://en.wikipedia.org/wiki/BBC_Micro. Wikipedia, the free encyclopedia.

Scordino, C. (2011) http://retis.sssup.it/~scordino/code/rs485.html Linux RS485 support

ANEXOS


ANEXOS

Anexo 1. Esquema eléctrico "MAIN BOARD"

ANEXOS

102

ANEXOS


ANEXOS

104

ANEXOS


ANEXOS

106

ANEXOS


ANEXOS

108

Anexo 2. Marcação dos componentes da placa "MAIN BOARD"

ANEXOS


Anexo 3. Camada Top e Bottom da placa “MAIN BOARD”

ANEXOS

110

Anexo 4. Lista detalhada de material da placa “MAIN BOARD”

Designator Comment Footprint QT REF PRICEx1 PRICEx100 TOTALx1 TOTALx100

B1 CR 2032 3V CR2032

SMD 1 FARNELL:1216354 1,17 1,04 1,17 1,04 C1, C14,

C19, C28, C30, C31, C34, C35, C37, C38, C40, C42,

C48 100nF 0805 X7R CC2012-

0805 13 FARNELL:1759143 0,011 0,011 0,143 0,143 C2, C17,

C21, C23, C24, C25 10UF 16V CAP-4-5.4 6 FARNELL:9696920 0,136 0,098 0,816 0,588

C3 220UF 35V CAP-8.3-8.3 1 MOUSER:647-

UCD1V221MNL1GS 0,289 0,289 0,289 0,289 C4, C7,

C9, C13, C15, C18, C22, C36, C39, C41, C43, C45,

C47 10uF 0805 Y5R 10V CC2012-

0805 13 FARNELL:1833812 0,119 0,06 1,547 0,78 C5, C6,

C11, C26, C44, C46 1uF 0805 Y5V

CC2012-0805 6 FARNELL:1611943 0,027 0,027 0,162 0,162

C8 330UF 35V CAP-10.3-

10.3 1 MOUSER:647-

UCD1V331MNL1GS 0,289 0,289 0,289 0,289

C10 10nF 0805 X7R CC2012-

0805 1 FARNELL:1759246 0,011 0,011 0,011 0,011

C12, C27 12pF 0805 NP0 CC2012-

0805 2 FARNELL:1828810RL 0,033 0,017 0,066 0,034

C16, C20 220UF 16V CAP-6.6-6.6 2 MOUSER:140-

VE221M1CTR0607 0,165 0,113 0,33 0,226

C29 2.2nF 0805 X7R CC2012-

0805 1 FARNELL:1520269 0,026 0,026 0,026 0,026

C32, C33 15pF 0805 NP0 CC2012-

0805 2 FARNELL:1650868 0,03 0,024 0,06 0,048

CR1 LTST-C170GKT LEDX4 1 FARNELL:1519467 0,60 0,42 0,6 0,42

CR2 SCHOTTKY, 1.5A,

60V DO-214 1 FARNELL:1463213 0,187 0,092 0,187 0,092

CR3 BZG05C3V3TR3 DO-214 1 FARNELL:9397965 0,48 0,30 0,48 0,3

CR4 BZD27C5V1P DO-214 1 FARNELL:1703019 0,193 0,145 0,193 0,145

CR5 STPS340U SMB 1 FARNELL:9803548 0,58 0,39 0,58 0,39

D1 BAT54C SOT-23 1 FARNELL:1621834 0,094 0,068 0,094 0,068

D2 TVS, UNI, 24V, 600W DO-214 1 FARNELL:1859880 0,22 0,186 0,22 0,186

DL1 Led SMD 1206 1206 1 FARNELL:1226417 0,089 0,063 0,089 0,063

ANEXOS



F1 POLYSWITCH, SMD

1.25A SMD125 1 FARNELL:609067 0,131 0,131 0,131 0,131

J1, J6 HDR1X3 HDR1X3 2 FARNELL:1925527 0,26 0,181 0,52 0,362

J2, J5, J7 HDR1X2 HDR1X2 3 FARNELL:1022247 0,147 0,095 0,441 0,285

J3, J4 HDR1X3 HDR1X3 2 FARNELL:1925527 0,26 0,181 0,52 0,362

K1 CARD, SD, W/O

COVER SM2.5-4H9 1 FARNELL:9186140 1,52 1,29 1,52 1,29

K2 JACK SOCKET, DC Power Entry 1 FARNELL:1608726 1,40 1,40 1,4 1,4

L1 10uH 805 1 FARNELL:1463501 0,14 0,101 0,14 0,101

L2 2.2UH 4A IND2424 1 FARNELL:1782805 0,28 0,31 0,28 0,31 P1, P2, P3, P4, P5, P6, P7, P11 1 ROW, 6WAY HDR1X6 8 FARNELL:1593462 0,58 0,23 4,64 1,84 P8, P9,

P10 1 ROW, 4WAY HDR1X4 3 FARNELL:1593460 0,38 0,152 1,14 0,456

Q1 SI1563DH-T1-E3 SOT-363 1 FARNELL:1470095 0,41 0,31 0,41 0,31 R1, R16,

R19, R20, R21, R22,

R36 2k2 CR2012-

0805 7 FARNELL:1577341 0,064 0,02 0,448 0,14 R2, R3,

R17, R18, R23, R25, R27, R29, R40, R41 165R

CR2012-0805 10 FARNELL:1400299RL 0,052 0,052 0,52 0,52

R4, R5, R6, R7, R8, R9,

R12, R15, R26, R28, R30, R31, R32, R34,

R37 100K CR2012-

0805 15 FARNELL:1653286 0,023 0,02 0,345 0,3

R10 12K CR2012-

0805 1 FARNELL:1400350RL 0,056 0,053 0,056 0,053

R11 0R CR2012-

0805 1 FARNELL:1469846 0,02 0,02 0,02 0,02 R13, R33, R35, R38 10K

CR2012-0805 4 FARNELL:1653284 0,023 0,02 0,092 0,08

R14 20K CR2012-

0805 1 FARNELL:1653297 0,104 0,081 0,104 0,081

R24 470R CR2012-

0805 1 FARNELL:1653307 0,104 0,081 0,104 0,081

R39 120R CR2012-

0805 1 FARNELL:1652914 0,094 0,037 0,094 0,037 SW1, SW2 7MM, 100G MCDTS6 2 FARNELL:9471723 0,20 0,072 0,4 0,144

U1, U2, U3, U4, U5, U6, U7, U8,

U9, U10, U11, U12 TCMT1103 SOP4 12 FARNELL:1328388 0,39 0,26 4,68 3,12

ANEXOS

112

U13 MCP2515-I/SO SO-G18/E7.7 1

MOUSER:579-MCP2515-I/SO

FARNELL:1292239 1,49 1,26 1,49 1,26

U14 TPS60502DGS MSOP-

UN10_N 1

MOUSER:595-TPS60502DGS

FARNELL:1461012 1,98 1,32 1,98 1,32

U15 TPS73018DBVT SOT-23-OT5_M 1 FARNELL:1135390 0,32 0,28 0,32 0,28

U16 MCP1827T-3302E/ET DDPAK-

ET5_L 1 FARNELL:1852006 1,76 1,06 1,76 1,06

U17 MAX16977RAUE/V+ TSSOP16_M 1 MOUSER:700-

MAX16977RAUE/V+ 4,53 3,20 4,53 3,2

U18 SN65HVD232D SO-G8/D5.1 1 FARNELL:1103107 3,27 1,78 3,27 1,78

U19 ADM3490ARZ SOIC8 1 FARNELL:1274165 2,58 1,32 2,58 1,32

U20 ICL3232CVZ TSSOP16 1 FARNELL:1561966 1,53 0,44 1,53 0,44

Y1 ABLS-20.000MHZ OSC 1 MOUSER:815-ABLS-

20-B2 0,29 0,255 0,29 0,255

TOTAL: 41,88 € 26,52 €

x1 x100

ANEXOS


Anexo 5. Esquema eléctrico da placa "CPU BOARD"

ANEXOS

114

ANEXOS


ANEXOS

116

ANEXOS


ANEXOS

118

ANEXOS


Anexo 6. Marcação dos componentes da placa "CPU BOARD"

ANEXOS

120

Anexo 7. Camada Top e Bottom da placa “MAIN BOARD”

ANEXOS


Anexo 8. Camada interna 1 e 2 da placa “MAIN BOARD”

ANEXOS

122

Anexo 9. Lista detalhada de material da placa “CPU BOARD”

Designator Comment Footprint QT REF PRICEx1 PRICEx100 TOTALx1 TOTALx100 C1, C3, C5, C6,

C13, C15, C18, C24, C27, C28, C31, C33, C34, C35, C38, C39, C41, C43, C45, C46, C47, C48, C49, C50, C51, C52, C53, C54, C55, C58, C59, C60, C61, C62, C63, C64, C65, C66, C67, C68, C69, C70, C71, C72, C73, C74, C78, C79, C80, C81, C82, C84, C87, C88, C90, C91 100nF 0805 X7R CC2012-0805 56 FARNELL:1759143 0,011 0,011 0,616 0,616

C2, C4, C44 1nF 0805 X7R CC2012-0805 3 FARNELL:1520296 0,022 0,022 0,066 0,066

C7, C9, C11, C14, C16, C20, C23, C25 10UF 16V CAP-4-5.4 8 FARNELL:9696920 0,136 0,098 1,088 0,784 C8, C12,

C85 33pF 0805 NP0 CC2012-0805 3 FARNELL:1362559 0,032 0,03 0,096 0,09 C10, C29, C30, C36, C40, C56, C57, C75,

C89 10uF/ 10V 1206+ 9 FARNELL:1457413 0,185 0,144 1,665 1,296

C17, C19 10pF 0805 NP0 CC2012-0805 2 FARNELL:1650856 0,031 0,025 0,062 0,05

C21, C22 47pF 0805 NP0 CC2012-0805 2 FARNELL:1362560 0,032 0,03 0,064 0,06

C26 1500pF 1k5V X7R 1206 1 FARNELL:1702136 0,23 0,183 0,23 0,183

C32 10uF 0805 Y5R 10V CC2012-0805 1 FARNELL:1833812 0,119 0,06 0,119 0,06

C37 2.2nF 0805 NP0 CC2012-0805 1 FARNELL:1520269 0,026 0,026 0,026 0,026

C42 10nF 0805 X7R CC2012-0805 1 FARNELL:1759246 0,011 0,011 0,011 0,011

C76, C77, C83, C86 15pF 0805 NP0 CC2012-0805 4 FARNELL:1650868 0,03 0,024 0,12 0,096

D1 SCHOTTKY 20V 1A SOD323F 1 FARNELL:1757764 0,097 0,064 0,097 0,064



F3, F5, F7 PTC 0.5A 0805 3 FARNELL:1861197RL 0,31 0,24 0,93 0,72

F4, F6 PTC 0.2A 0805 2 FARNELL:1861195 0,21 0,157 0,42 0,314 J1, J3, J4,

J5 HDR1X2 HDR1X2 4 FARNELL:1022247 0,147 0,095 0,588 0,38

J2 HDR1X3 HDR1X3 1 FARNELL:1022249 0,20 0,125 0,2 0,125

ANEXOS


K1 J0011D21BNL J0011D21BNL 1 MOUSER: 673-J0011D21BNL 4,79 3,52 4,79 3,52

K2 USB, TYPE A USB2.5-2H4B 1 FARNELL:1696534 0,80 0,31 0,8 0,31

K3 USB, TYPE B 1-1470156 1 FARNELL:1308876 0,59 0,42 0,59 0,42

K4 HDR2X10 HDR2X10 1 FARNELL:3418510 0,51 0,37 0,51 0,37

L1 10UH, 120MA, 10% 805 1 FARNELL:1463501 0,14 0,101 0,14 0,101 P1, P2, P3, P4,

P5, P6, P7 1 ROW, 6WAY HDR1X6 7 FARNELL:1248144 0,40 0,37 2,8 2,59

P8, P9, P10 1 ROW, 4WAY HDR1X4 3 FARNELL:11248142 0,19 0,174 0,57 0,522

R1, R7, R8, R11 165R 1/8W 1% CR2012-0805 4 0,052 0,052 0,208 0,208

R2, R3, R4, R5 49.9R 1/8W 5% CR2012-0805 4

FARNELL: 1612051RL 0,022 0,022 0,088 0,088

R6, R12, R19, R20, R24, R29, R33, R36, R37, R41, R42, R43, R44, R45, R46, R47, R52, R53, R54, R56, R59, R67, R70, R74, R75, R77 0R 1/8W 1% CR2012-0805 26 FARNELL:1469846 0,02 0,02 0,52 0,52

R9 2k2 1/10W 0.5% CR2012-0805 1 FARNELL:1577341 0,064 0,02 0,064 0,02 R10, R14, R18, R21, R26, R49, R50, R51, R55, R58 100K 1/10W 0.5% CR2012-0805 10 FARNELL:1653286 0,023 0,02 0,23 0,2

R13 4k87 1/8W 5% CR2012-0805 1 FARNELL:1575866 0,35 0,02 0,35 0,02 R15, R17,

R32 10K 1/10W 0.5% CR2012-0805 3 FARNELL:1653284 0,023 0,02 0,069 0,06

R16, R73 1k5 1/8W 1% CR2012-0805 2 FARNELL:1653006 0,094 0,037 0,188 0,074 R22, R23, R25, R27, R28, R31, R34, R35, R60, R61,

R63 ARRAY, 0804, 47R 0804 11 FARNELL:1770148 0,014 0,011 0,154 0,121

R30, R48, R57, R68 1K 1/10W 1% CR2012-0805 4 FARNELL:1500663 0,018 0,019 0,072 0,076

R38, R39, R64, R65 39R 1/8W 1% CR2012-0805 4 FARNELL:1400008 0,058 0,052 0,232 0,208

R40 22K 1/8W 5% CR2012-0805 1 FARNELL:1652960 0,094 0,037 0,094 0,037 R62, R66,

R76 15K 1/8W 1% CR2012-0805 3 FARNELL:1652920 0,094 0,037 0,282 0,111 R69, R71,

R72 470k 1/4W 1% CR2012-0805 3 FARNELL:1400121 0,026 0,026 0,078 0,078 SW1, SW2 7MM, 100G MCDTS6 2 FARNELL:9471723 0,20 0,072 0,4 0,144

U1 DP83640TVV VBH48A_M 1 DIGI-KEY:

DP83640TVV-ND 12,45 9,21 12,45 9,21

U2, U3 TPS3808G33DBVR SO-G6/E5 2 FARNELL:1703467 2,17 0,98 4,34 1,96

U4 AT91SAM9XE128-

QU 208PQFP 1 MOUSER: 556-

A91SAM9XE128-QU 16,38 9,33 16,38 9,33

U5, U6 MT48LC16M16A2P TSOP2-54 2 FARNELL:1216280 16,61 10,90 33,22 21,8

ANEXOS

124

U7 HY27UF082G2B TSOP48 1 FARNELL:1712425 7,35 4,42 7,35 4,42

U8 MCP9701AT-E/TT SOT-23 1 FARNELL:1834865 0,33 0,19 0,33 0,19

Y1 25M, 18PF CL HC49 1 FARNELL:1611791 0,37 0,23 0,37 0,23

Y2 ABLS-18.432MHZ HC49 1 FARNELL:1611789 0,46 0,30 0,46 0,3

Y3 32.768 KHz 12.5PF CM2000S 1 MOUSER:695-

CM200C-327KF-U 0,52 0,33 0,52 0,33

TOTAL: 95,23 € 62,64 €

x1 x100

Projecto e Construção de um Sistema Embebido de Tempo-Real ...

Documents

Transcript of Projecto e Construção de um Sistema Embebido de Tempo-Real ...