implementação de um sistema de arquivos para uma plataforma de

139
Implementação de um sistema de arquivos para uma plataforma de computação reconfigurável Adriano Kaminski Sanches

Upload: leque

Post on 07-Jan-2017

215 views

Category:

Documents


1 download

TRANSCRIPT

Page 1: Implementação de um sistema de arquivos para uma plataforma de

Implementação de um sistema dearquivos para uma plataforma de

computação reconfigurável

Adriano Kaminski Sanches

Page 2: Implementação de um sistema de arquivos para uma plataforma de
Page 3: Implementação de um sistema de arquivos para uma plataforma de

SERVIÇO DE PÓS-GRADUAÇÃO DO ICMC-USP

Data de Depósito: 09/08/2006

Assinatura :

Implementação de um sistema dearquivos para uma plataforma de

computação reconfigurável

Adriano Kaminski Sanches

Orientação:

Prof. Dr. Eduardo Marques

Dissertação apresentada ao Instituto de Ciências Mate-máticas e de Computação, como parte dos requisitospara a obtenção do título de Mestre em Ciências deComputação e Matemática Computacional.

ICMC - USP, São CarlosAgosto de 2006

Page 4: Implementação de um sistema de arquivos para uma plataforma de
Page 5: Implementação de um sistema de arquivos para uma plataforma de

Agradecimentos

Agradeço aos meus pais que sem medir esforços sempre estiveram determinados naminha educação. Apoio esse incondicional que me deu a possibilidade de me dedicar deforma integral e com total tranqüilidade aos estudos.

Agradeçoo à minha irmã Daniele pelo carinho e ao meu irmão Marcelo pelo apoio ededicação por estar sempre ao meu lado durante a realização do trabalho.

Agradeço em especial ao Professor Eduardo pela confiança depositada em mim, pelacompreensão nos momentos de desânimo e pelo grande lado humano, fazendo-me resgatarvalores que realmente fazem a diferença.

Agradeço aos colegas de turma que estiveram presentes nos momentos alegres e tristes,compartilhando experiências e emoções, fazendo com que este ambiente se tornasse maisfraterno e humano.

Agradeço também ao amigo Rodrigo pelo companheirismo nos momentos difíceis.

Agradeço aos funcionários do ICMC por estarem sempre a disposição em ajudar.

Agradeço ao Neimar Duarte da PI Componentes por ter cedido um cartão de memóriaessencial para a realização do trabalho.

Agradeço a Capes pelo apoio financeiro.

Por último e mais importante agradeço a Deus pelo dom da vida e por fazer com queo meu caminho fosse trilhado junto a pessoas tão especiais.

Page 6: Implementação de um sistema de arquivos para uma plataforma de

iv

Page 7: Implementação de um sistema de arquivos para uma plataforma de

Resumo

Em um sistema computacional, os dados são armazenados na unidade de armaze-namento, segundo alguma lógica, em estruturas denominadas arquivos. O Sistema deArquivos é o responsável por estruturar, identificar, acessar, proteger e gerenciar essesarquivos, além de agir como um elo de ligação entre o usuário e o dispositivo, tradu-zindo comandos de alta abstração (oriundos do usuário) em comandos de baixo nível,compreensível a unidade de armazenamento.

O presente trabalho visa a implementação de um sistema de arquivos para aplicaçãoem dispositivos móveis baseado em computação reconfigurável. Tal sistema servirá desuporte para as aplicações que necessitem armazenar e/ou restaurar grande volume dedados, como a aquisição de imagens digitalizadas de câmeras CMOS. Este sistema tambémserá utilizado como uma ferramenta inicial para o desenvolvimento de um módulo dearmazenamento em uma placa baseada em computação reconfigurável a ser utilizadapara fins didáticos. O sistema de arquivos implementado foi a FAT16 e o dispositivode armazenamento de massa utilizado foram os cartões de memória SD-Secure Digital eMMC-MultiMediaCard.

v

Page 8: Implementação de um sistema de arquivos para uma plataforma de
Page 9: Implementação de um sistema de arquivos para uma plataforma de

Abstract

In computational systems, usually the data are stored in storage units, accordingto some logic, in structures called files. The File System is responsible for structure,identification, access, protection and management of the files. It also acts as a connectorlink between the user and the device, translating high level commands (derived for theuser) into commands of low level, understandable for the storage unit.

The present work aims to implement a File System for application in mobile devicesbased on reconfigurable computation. Such system will act as a support for the applica-tions that need to store and/or to restore large volume of data, such as the acquisition ofdigital images from CMOS cameras. This system will also be used as an initial tool forthe development of a storage module of a board, based on reconfigurable computation, tobe used for didactic purposes. The implemented File System is based on FAT16 and thestorage device used was the memory cards SD (Secure Digital) and MMC (MultiMedia-Card).

vii

Page 10: Implementação de um sistema de arquivos para uma plataforma de
Page 11: Implementação de um sistema de arquivos para uma plataforma de

Sumário

Resumo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . v

Resumo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . vi

Lista de Figuras . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xv

Lista de Tabelas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xix

1 Introdução 1

1.1 Motivação . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2

1.2 Objetivos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3

1.3 Organização do Trabalho . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5

2 Dispositivos de Armazenamento 7

2.1 Introdução . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8

2.1.1 Memória Hierárquica . . . . . . . . . . . . . . . . . . . . . . . . . . 9

2.2 Fitas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12

2.3 Discos Rígidos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17

2.4 Discos Flexíveis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21

2.5 Mídias Ópticas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22

2.6 Memórias de Estado Sólido . . . . . . . . . . . . . . . . . . . . . . . . . . . 25

2.6.1 USB Flash Drive . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27

2.6.2 Memory Stick . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28

ix

Page 12: Implementação de um sistema de arquivos para uma plataforma de

x SUMÁRIO

2.6.3 xD–Picture Card . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29

2.6.4 Compact Flash . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30

2.7 Dispositivos de Armazenamento Utilizados Neste Projeto . . . . . . . . . . 31

2.7.1 SD Card . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31

2.7.1.1 Interface do Cartão SD . . . . . . . . . . . . . . . . . . . . 34

2.7.1.2 Escrita e Leitura no Cartão SD . . . . . . . . . . . . . . . 35

2.7.2 MMC - MultiMedia Card . . . . . . . . . . . . . . . . . . . . . . . 37

2.7.2.1 Interface do cartão MMC . . . . . . . . . . . . . . . . . . 39

2.8 Considerações Finais . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40

3 Sistema de Arquivos 41

3.1 Introdução . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42

3.2 Arquivos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43

3.2.1 Identificação . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43

3.2.2 Estrutura . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44

3.2.3 Atributos de Arquivos . . . . . . . . . . . . . . . . . . . . . . . . . 45

3.2.4 Tipos de Arquivos . . . . . . . . . . . . . . . . . . . . . . . . . . . 46

3.3 Diretórios . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47

3.3.1 Diretórios com Um Nível . . . . . . . . . . . . . . . . . . . . . . . . 48

3.3.2 Diretórios com Dois Níveis . . . . . . . . . . . . . . . . . . . . . . . 48

3.3.3 Diretórios Hierárquicos . . . . . . . . . . . . . . . . . . . . . . . . . 49

3.4 Operações . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51

3.5 Implementação do Sistema de Arquivos . . . . . . . . . . . . . . . . . . . . 52

3.5.1 Alocação Contínua . . . . . . . . . . . . . . . . . . . . . . . . . . . 53

3.5.2 Alocação com Lista Encadeada . . . . . . . . . . . . . . . . . . . . 54

3.5.3 Alocação com Lista Encadeada Usando Índice . . . . . . . . . . . . 55

Page 13: Implementação de um sistema de arquivos para uma plataforma de

SUMÁRIO xi

3.5.4 Nós-Índice . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 56

3.6 Sistema de Arquivos FAT . . . . . . . . . . . . . . . . . . . . . . . . . . . 57

3.6.1 Especificação da FAT16 . . . . . . . . . . . . . . . . . . . . . . . . 59

3.6.1.1 Setor de Boot Secundário . . . . . . . . . . . . . . . . . . 60

3.6.1.2 Tabela de Alocação de Arquivos . . . . . . . . . . . . . . . 61

3.6.1.3 Diretório Raiz . . . . . . . . . . . . . . . . . . . . . . . . . 63

3.6.1.4 Área de Dados . . . . . . . . . . . . . . . . . . . . . . . . 64

3.7 Considerações Finais . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 64

4 Plataforma de Desenvolvimento 65

4.1 Introdução . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 65

4.1.1 Modelos de desenvolvimento . . . . . . . . . . . . . . . . . . . . . . 66

4.2 Processador Nios II . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 68

4.2.1 Nios II/f . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 69

4.2.2 Nios II/e . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 70

4.2.2.1 Nios II/s . . . . . . . . . . . . . . . . . . . . . . . . . . 71

4.2.3 Comparação entre as Versões . . . . . . . . . . . . . . . . . . . . . 71

4.2.4 Famílias de FPGAs . . . . . . . . . . . . . . . . . . . . . . . . . . . . 73

4.2.4.1 Cyclone . . . . . . . . . . . . . . . . . . . . . . . . . . . . 73

4.2.4.2 Cyclone II . . . . . . . . . . . . . . . . . . . . . . . . . . 73

4.2.4.3 Stratix . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 74

4.2.4.4 Stratix GX . . . . . . . . . . . . . . . . . . . . . . . . . . 74

4.2.4.5 Stratix II . . . . . . . . . . . . . . . . . . . . . . . . . . . 74

4.2.5 Benefícios . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 75

4.2.5.1 Extensa Biblioteca de Componentes . . . . . . . . . . . . 75

4.2.5.2 Desempenho do Sistema . . . . . . . . . . . . . . . . . . . 76

Page 14: Implementação de um sistema de arquivos para uma plataforma de

xii SUMÁRIO

4.2.5.3 Redução de Custos . . . . . . . . . . . . . . . . . . . . . . 77

4.3 Ferramentas Utilizadas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 77

4.3.1 Kit de Desenvolvimento . . . . . . . . . . . . . . . . . . . . . . . . 78

4.3.2 Ferramenta de Desenvolvimento de Software . . . . . . . . . . . . . 80

4.3.3 Ferramenta de Desenvolvimento de Hardware . . . . . . . . . . . . 82

4.3.4 Ambiente de Testes e Validação Reais do Sistema de Arquivos FAT16

Desenvolvido . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 84

4.3.4.1 Sensor de Imagem . . . . . . . . . . . . . . . . . . . . . . 84

4.3.4.2 Necessidade de Armazenar as Imagens . . . . . . . . . . . 86

4.4 Considerações Finais . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 87

5 Implementação e Resultados 89

5.1 Introdução . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 89

5.2 Dispositivos de Armazenamento Utilizados . . . . . . . . . . . . . . . . . . 91

5.3 Elaboração da Interface de Conexão Física . . . . . . . . . . . . . . . . . . 93

5.3.1 Teste e Validação dos Conectores . . . . . . . . . . . . . . . . . . . 95

5.4 Camada de Abstração de Hardware . . . . . . . . . . . . . . . . . . . . . . 95

5.4.1 Ligar_Cartao . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 96

5.4.2 Ler_Setor . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 96

5.4.3 Escrever_Setor . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 96

5.4.4 Teste e Validação da Camada de Abstração de Hardware . . . . . . 97

5.5 Biblioteca FAT . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 98

5.5.1 inicializar . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 98

5.5.2 Abrir_Arquivo_Escrita . . . . . . . . . . . . . . . . . . . . . . . . 98

5.5.3 Escrever_Arquivo . . . . . . . . . . . . . . . . . . . . . . . . . . . . 99

5.5.4 Abrir_Arquivo_Leitura . . . . . . . . . . . . . . . . . . . . . . . . 99

Page 15: Implementação de um sistema de arquivos para uma plataforma de

SUMÁRIO xiii

5.5.5 Ler_Arquivo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 99

5.5.6 Fechar_Arquivo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 100

5.5.7 Teste e Validação do Sistema de Arquivos Proposto . . . . . . . . . 100

5.6 Gerador de arquivo gráfico de Mapa de Bits BMP . . . . . . . . . . . . . . 102

5.6.1 Teste e Validação do Gerador de Arquivos . . . . . . . . . . . . . . 103

5.6.2 Sistema Desenvolvido . . . . . . . . . . . . . . . . . . . . . . . . . . 105

5.7 Considerações Finais . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 106

6 Conclusões 107

6.1 Trabalhos Futuros . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 109

Referências Bibliográficas 111

Page 16: Implementação de um sistema de arquivos para uma plataforma de
Page 17: Implementação de um sistema de arquivos para uma plataforma de

Lista de Figuras

1.1 Plataforma de Desenvolvimento . . . . . . . . . . . . . . . . . . . . . . . . 4

2.1 Níveis de Hierarquia de Memória (Hennessy e Patterson, 2003) . . . . . . . 9

2.2 Tear de Jacquard . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12

2.3 Cartão Perfurado e sua Respectiva Unidade de Leitura . . . . . . . . . . . 13

2.4 Fitas de papel utilizadas como dispositivo de armazenamento . . . . . . . . 14

2.5 Fita Magnética . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15

2.6 Fita DAT de 4 GigaBytes de Capacidade . . . . . . . . . . . . . . . . . . . 15

2.7 StorageTek Streamline SL8500–T1000 . . . . . . . . . . . . . . . . . . . . . 16

2.8 Disco Rígido IBM 350 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18

2.9 Disco rígido MK4001MTD comparado a uma moeda . . . . . . . . . . . . . 19

2.10 Cabeça de leitura/gravação de um disco rígido . . . . . . . . . . . . . . . . 19

2.11 Paralelismo em um Disco Rígido com 4 (quatro) cabeças de leitura/gravação 20

2.12 Discos Flexíveis de 8, 5 1/4 e 3 1/2 polegadas . . . . . . . . . . . . . . . . 22

2.13 Disposição da trilha em forma de espiral na superfície do disco optico (Ta-

nenbaum, 1999) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24

2.14 Dispositivo de memória USB Flash Drive . . . . . . . . . . . . . . . . . . . 27

2.15 Três diferentes tamanhos disponíveis de Memory Stick: Pro, Pro Duo e Micro 29

2.16 Dispositivo de Memória xD–Picture Card . . . . . . . . . . . . . . . . . . . 30

xv

Page 18: Implementação de um sistema de arquivos para uma plataforma de

xvi LISTA DE FIGURAS

2.17 Compact Flash I de 2 GigaBytes de capacidade . . . . . . . . . . . . . . . 30

2.18 Cartão SD da Sandisk com 512 MegaBytes de capacidade . . . . . . . . . . 32

2.19 Cartão miniSD e seu adaptador para o padrão SD . . . . . . . . . . . . . . 32

2.20 Dispositivo MicroSD (TransFlash) . . . . . . . . . . . . . . . . . . . . . . . 33

2.21 Descrição dos Pinos do Cartão SD . . . . . . . . . . . . . . . . . . . . . . . 35

2.22 Operação de Leitura (Múltiplos) Blocos . . . . . . . . . . . . . . . . . . . . 36

2.23 Operação de Escrita (Múltiplos) Blocos . . . . . . . . . . . . . . . . . . . . 37

2.24 Diferença de pinagem entre os cartões MMC e MMCpluls (vista superior) . 38

2.25 Os três modelos disponíveis de cartão MMC: MMC PLUS, MMC mobile e

MMC micro . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38

3.1 Três tipos de estruturas de arquivos . . . . . . . . . . . . . . . . . . . . . . 45

3.2 Sistema de diretório de nível único . . . . . . . . . . . . . . . . . . . . . . 48

3.3 Sistema de diretório de dois níveis . . . . . . . . . . . . . . . . . . . . . . . 49

3.4 Sistema de diretório hierárquico . . . . . . . . . . . . . . . . . . . . . . . . 50

3.5 Técnica de Alocação Contínua . . . . . . . . . . . . . . . . . . . . . . . . . 53

3.6 Técnica de Alocação com Lista Encadeada . . . . . . . . . . . . . . . . . . 54

3.7 Técnica de Alocação com Lista Encadeada Usando Índice . . . . . . . . . . 55

3.8 Técnica de Alocação com Nós-Índice . . . . . . . . . . . . . . . . . . . . . 56

3.9 Representação lógica de uma unidade de armazenamento particionada . . . 60

4.1 Diagrama esquemático dos blocos internos da FPGA . . . . . . . . . . . . 67

4.2 Processador Nios II em diagrama de blocos . . . . . . . . . . . . . . . . . 70

4.3 Comparação entre as versões do processador Nios II com o Nios . . . . . 72

4.4 Componentes e eletrônicos do ambiente de desenvolvimento . . . . . . . . . 79

4.5 Diagrama de Blocos do Kit de Desenvolvimento . . . . . . . . . . . . . . . 79

4.6 Ambiente de Trabalho do Nios II IDE . . . . . . . . . . . . . . . . . . . . 81

Page 19: Implementação de um sistema de arquivos para uma plataforma de

LISTA DE FIGURAS xvii

4.7 Interface SPOC Builder . . . . . . . . . . . . . . . . . . . . . . . . . . . . 83

4.8 Sistema Multi-Câmera embarcado na base do robô Pioneer 3DX . . . . . . 85

4.9 Câmera CMOS (modelo C3188A - 1/3") . . . . . . . . . . . . . . . . . . . 86

5.1 Divisão do Sistema em Camadas . . . . . . . . . . . . . . . . . . . . . . . . 90

5.2 Cartão TransFlash da Sandisk de 64 Megabytes de capacidade com seu

adaptador para interface SD . . . . . . . . . . . . . . . . . . . . . . . . . . 91

5.3 Cartão SD da Sandisk de 1 Gigabytes de capacidade . . . . . . . . . . . . 92

5.4 Cartão MMC da LG de 256 MegaBytes de capacidade . . . . . . . . . . . . 92

5.5 Adaptador USB–SD/MMC . . . . . . . . . . . . . . . . . . . . . . . . . . . 92

5.6 Diagrama de Conexão do cartão SD/MMC com um barramento SPI . . . . 94

5.7 Cabo Confeccionado Acoplado a Placa de Desenvolvimento . . . . . . . . . 94

5.8 Imagens geradas na plataforma de desenvolvimento e visualizadas em um

computador . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 105

Page 20: Implementação de um sistema de arquivos para uma plataforma de
Page 21: Implementação de um sistema de arquivos para uma plataforma de

Lista de Tabelas

2.1 Definição dos Pinos do Cartão MMC no modo SPI (7 Pinos) . . . . . . . . 39

2.2 Definição dos Pinos do Cartão MMC no modo MMC(13 Pinos) . . . . . . . 40

3.1 Extensões típicas de arquivos. . . . . . . . . . . . . . . . . . . . . . . . . . 44

3.2 Campos do Setor de Boot . . . . . . . . . . . . . . . . . . . . . . . . . . . 61

3.3 Descrição dos Índices da Tabela de Alocação . . . . . . . . . . . . . . . . . 62

3.4 Entrada de Diretório do Sistema FAT16 . . . . . . . . . . . . . . . . . . . 63

3.5 Atributos do Arquivo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 63

4.1 Resumo das principais características das versões do Nios II . . . . . . . . 72

5.1 Cartões utilizados no desenvolvimento do projeto . . . . . . . . . . . . . . 91

xix

Page 22: Implementação de um sistema de arquivos para uma plataforma de
Page 23: Implementação de um sistema de arquivos para uma plataforma de

Capítulo

1

Introdução

Desde os primórdios, a humanidade tem o sonho de desenvolver máquinas que tomem

decisões pelo ser humano nas mais diversas áreas de atuação, seja para a realização de

simples tarefas domésticas quanto para a solução de problemas complexos. Uma das

propostas para atingir esse objetivo foi a concepção de robôs.

Robôs são dispositivos físicos dotados de sensores e atuadores, que executam uma

determinada tarefa pré-programada. As primeiras tentativas de desenvolvimento desses

dispositivos resultaram em robôs pouco inteligentes, com aplicações bem limitadas. Com

o passar do tempo, esforços foram empregados no desenvolvimento de robôs fixos, de

característica estática para serem aplicados basicamente em linhas de produção industrial.

Em uma fase mais recente, com os avanços alcançados na capacidade de processamento

1

Page 24: Implementação de um sistema de arquivos para uma plataforma de

2 CAPÍTULO 1. INTRODUÇÃO

dos dispositivos eletrônicos, pesquisadores estão concentrando esforços na pesquisa de

robôs móveis, que são inseridos em um ambiente dinâmico, com características autônomas,

dotados de “inteligência”, aumentando significativamente as perspectivas de utilidade para

os mesmos.

Uma alternativa para a integração dos circuitos lógicos pertencentes a um robô, bem

como da maioria dos sistemas eletrônicos, é a utilização de ASICs1, os quais possibilitam o

desenvolvimento de sistemas altamente eficientes, porém, a um custo elevado, sendo a sua

utilização indicada para dispositivos produzidos em larga escala (Gonçalves, 2002). Outra

possibilidade é utilizar processadores de uso genérico, que podem facilmente ser adaptados

a qualquer aplicação, porém, nem sempre atendem às necessidade de processamento, sendo

indicado para sistemas de baixa complexidade.

Visando o contorno dessas limitações, foram desenvolvidos dispositivos de lógica re-

configurável, também conhecidos como FPGAs2, que agilizam as etapas de prototipação

e implementação de sistemas digitais específicos, com capacidade de processamento supe-

rior aos processadores de uso genérico e a um custo inferior ao desenvolvimento baseado

em ASICs. Tais dispositivos reconfiguráveis possibilitam também a alteração do sistema

digital desenvolvido, mesmo após o término do projeto ou até mesmo em momento de

execução (Oldfield e Dorf, 1995; de O. S. Aragão e Marques, 1997).

1.1 Motivação

É no contexto da computação reconfigurável que é concebido o projeto ARMOSH

(Aprendizado de Robôs Móveis via Software e Hardware) (Romero, 2000), o qual tem

por objetivo a construção de robôs inteligentes móveis sob uma lógica reconfigurável,

inseridos em um ambiente dinâmico. Na Figura 1.1 são ilustrados os módulos, bem como1Application Specific Integrated Circuit2Field Programmable Gate Arrays

Page 25: Implementação de um sistema de arquivos para uma plataforma de

1.2. OBJETIVOS 3

a integração deles, do robô móvel reconfigurável proposto pelo projeto ARMOSH.

Para o robô desenvolver suas atividades de exploração de forma eficiente, ele será

dotado de diversos sensores e atuadores, dentre os quais, um sistema de mapeamento e

localização baseado em multi-câmeras digitais (Bonato, 2005b).

Essas câmeras, assim como os demais sensores disponíveis no sistema irão produzir

uma grande quantidade de dados que deverão ser armazenados em um dispositivo de

armazenamento de massa (conforme destacado na Figura 1.1) para posterior processa-

mento. Atualmente, existem várias alternativas de dispositivos de armazenamento de

massa. Porém, devido a restrições intrínsecas aos sistemas móveis, como a necessidade de

módulos com baixo consumo de energia e robustos a choques, a alternativa mais indicada

é a memória de estado sólido, que satisfaz essas restrições.

Uma vez definida a unidade de armazenamento a ser utilizada, faz-se necessária a im-

plementação de um sistema que organize os dados adquiridos de forma lógica em unidades

denominadas arquivos. Esse sistema, denominado de sistemas de arquivos, é responsável

por estruturar, identificar, acessar, proteger e gerenciar esses arquivos (Tanenbaum, 2001),

além de agir como um elo de ligação entre o usuário e o dispositivo, traduzindo comandos

de alta abstração (oriundos do usuário) em comandos de baixo nível, compreensível à

unidade de armazenamento.

1.2 Objetivos

A implementação de um Sistema de Arquivos para aplicação em dispositivos móveis

baseado em computação reconfigurável é o tema de investigação do presente trabalho. Esse

sistema servirá de suporte para as aplicações que necessitem armazenar e/ou restaurar

grandes volumes de dados, como, por exemplo, o sistema de mapeamento utilizado pelo

robô, o qual, irá manipular um grande número de imagens oriundas do sistema multi-

Page 26: Implementação de um sistema de arquivos para uma plataforma de

4 CAPÍTULO 1. INTRODUÇÃO

Figura 1.1: Plataforma de Desenvolvimento

Page 27: Implementação de um sistema de arquivos para uma plataforma de

1.3. ORGANIZAÇÃO DO TRABALHO 5

câmeras. Serão 4 câmeras fornecendo dados a 60 frames por segundo com resolução de

320 x 240 pontos por frame.

Uma outra aplicação para o sistema de arquivos resultante deste trabalho será o de-

senvolvimento de um módulo de armazenamento de uma placa proprietária baseada em

computação reconfigurável da PI Componentes3, a qual será utilizada para fins didáticos.

O sistema de arquivos implementado foi o FAT16 4 e os dispositivos de armazenamento

de massa utilizados foram os cartões de memória SD5 e MMC6.

1.3 Organização do Trabalho

Este plano de pesquisa está dividido em 6 (seis) capítulos, sendo esta Introdução o

primeiro deles. Os demais capítulos estão organizados da seguinte forma:

• no Capítulo 2 são ilustradas as características dos principais dispositivos de armaze-

namento de massa disponíveis, detalhando os dispositivos utilizados neste trabalho;

• no Capítulo 3 é apresentada uma visão geral sobre Sistemas de Arquivos, bem como

o detalhamento do sistema implementado;

• no Capítulo 4 são discutidos os aspectos principais da Computação Reconfigurável,

assim como a plataforma de desenvolvimento utilizado neste trabalho;

• no Capítulo 5 é apresentado o sistema de arquivos implementado; e

• no Capítulo 6 são apresentadas as conclusões obtidas, bem como algumas sugestões

de trabalhos futuros.

3http://www.picomponentes.com.br4File Allocation Table5Secure Digital6MultiMediaCard

Page 28: Implementação de um sistema de arquivos para uma plataforma de
Page 29: Implementação de um sistema de arquivos para uma plataforma de

Capítulo

2

Dispositivos de Armazenamento

Os Dispositivos de Armazenamento são utilizados na tarefa de armazenar dados e

aplicativos para posterior recuperação e manipulação.

Atualmente, existem várias alternativas de dispositivos com diferentes capacidade de

armazenamento, tempo de acesso, mobilidade e consumo de energia específicos para cada

necessidade.

Neste capítulo são ilustradas as características dos principais Dispositivos de Armaze-

namento, enfatizando o dispositivo utilizado neste trabalho.

7

Page 30: Implementação de um sistema de arquivos para uma plataforma de

8 CAPÍTULO 2. DISPOSITIVOS DE ARMAZENAMENTO

2.1 Introdução

Os dispositivos de armazenamento nos sistemas computacionais, similares à memória

no sistema biológico, são responsáveis por proverem mecanismos de gravação de informa-

ção em um banco, bem como posterior acesso ao mesmo para restaurar e/ou atualizar

essa informação. Tratando-se de um sistema computacional, existe uma grande variedade

de meios para disponibilizar esses mecanismos.

Em um sistema hipoteticamente perfeito, é natural verificar que a melhor abordagem

seria implementar um sistema de memória constituído apenas de memórias de alta velo-

cidade, que operem na velocidade do processador, disponíveis em grandes quantidades.

Entretanto, o desempenho dos processadores evoluem em um ritmo maior que as memó-

rias (Hennessy e Patterson, 2003), e um esquema assim disposto não é possível porque

quanto maior o desempenho, maior será o custo por unidade de dado e menor será a

capacidade de armazenamento (Stallings, 2002). Tal fato acarreta em um impasse entre

privilegiar o desempenho a um maior custo por bit e menor capacidade de armazena-

mento, ou aumentar a capacidade de armazenamento diminuindo o desempenho e o custo

por bit.

A solução adotada para esse dilema foi implementar um esquema de hierarquia de me-

mória. Esse esquema constitui-se em disponibilizar vários níveis de memória, distribuídos

de forma hierárquica, sendo cada nível classificado quanto à sua localização no sistema.

Quanto mais próximo a memória estiver do processador, mais rápida será, menor capa-

cidade terá e o custo por bit armazenado aumentará. Por outro lado, quanto mais longe

fisicamente estiver do processador, a memória será mais lenta, terá maior capacidade e

um menor custo por bit armazenado.

Page 31: Implementação de um sistema de arquivos para uma plataforma de

2.1. INTRODUÇÃO 9

2.1.1 Memória Hierárquica

Essa organização da memória do sistema é eficaz devido ao princípio de localidade de

referências apresentado por Stallings (2002) Apud Denning (1968). Este princípio afirma

que quando uma rotina típica é executada, as instruções e os dados por ela referenciados

tendem a agruparem-se na memória. Esse fato ocorre com as instruções porque geralmente

as rotinas têm laços e sub-rotinas que são acessadas com frequência, sendo que suas

instruções são referenciadas diversas vezes no decorrer da execução da rotina. Quanto

aos dados, é comum as rotinas utilizarem suas variáveis diversas vezes no decorrer de sua

execução, tendo seus dados freqüentemente referenciados pelo processador.

Assim, um sistema de memória hierárquico é organizado em vários níveis, adicionando

desempenho a um custo relativamente baixo. No topo desta hierarquia encontram-se as

memórias mais rápidas e que são mais freqüentemente requisitadas. Por outro lado, na

base dessa estrutura encontram-se os dispositivos de armazenamento externo, que são

mais lentos, porém, sendo requisitados em uma menor frequência. A Figura 2.1 ilustra

um exemplo típico desse sistema de memória, que é utilizado nos sistemas computacionais

atuais.

Figura 2.1: Níveis de Hierarquia de Memória (Hennessy e Patterson, 2003)

À esquerda da Figura 2.1 encontram-se os registradores internos ao processador. Os

registradores são a memória com maior desempenho do sistema de memória, operando

na velocidade do processador, porém, com uma baixa capacidade de armazenamento.

Page 32: Implementação de um sistema de arquivos para uma plataforma de

10 CAPÍTULO 2. DISPOSITIVOS DE ARMAZENAMENTO

À direita dos registradores tem-se a memória cache, uma memória de alta velocidade

e capacidade maior que os registradores, sendo atualmente implementadas fisicamente

dentro do processador. A memória principal encontra-se à direita da memória cache,

tendo uma capacidade bem maior que esta. Esses três primeiros níveis de um sistema

de memória hierárquico é denominado de memória interna. Devido à sua natureza física,

essas memórias são voláteis, ou seja, não tem a capacidade de manter os dados na falta de

energia, sempre estando sem conteúdo válido quando o sistema é ligado, até que alguma

operação de escrita seja realizada (Stallings, 2002).

À direita da Figura 2.1 encontram-se os dispositivos de entrada/saída1. Esses disposi-

tivos são classificados como memória externa, tendo a característica de manter seus dados

mesmo após o sistema ser desligado, ou seja, são não-voláteis. A memória externa é mais

lenta e com uma capacidade superior quando comparados à memória principal.

Segundo Hennessy e Patterson (2003), a cada nível que se desce na hierarquia da

memória, dos registradores até os dispositivos de entrada/saída a velocidade da memória

diminui por um fator de 10, indo de picosegundos a milesegundos, e a capacidade aumenta

por um fator de 1000, indo de bytes até terabytes.

Outra forma de classificar a memória é quanto ao método de acesso. Segundo essa

análise, Stallings (2002) destaca 4 grupos, ilustrados a seguir:

• Acesso seqüencial: nesse método de acesso os dados são agrupados na memória

seqüencialmente em unidades denominadas registros, que podem ser de tamanho

variado. No início de cada registro é armazenado um cabeçalho contendo um mar-

cador de início de registro e informações de endereçamento. Na operação de leitura

a um determinado registro, o mecanismo de leitura/escrita é posicionado sobre o

primeiro registro, e a partir de então é percorrido registro a registro seqüencial-

mente até encontrar o registro procurado ou, até chegar ao final da lista. Por essa1Input/Output

Page 33: Implementação de um sistema de arquivos para uma plataforma de

2.2. FITAS 11

característica, o tempo de acesso aos registros varia muito, dependendo do número

de registros intermediários existentes entre o primeiro registro do dispositivo até o

registro a ser localizado.

• Acesso Direto: diferente do acesso seqüencial, nesse método de acesso os registros

são organizados em blocos de tamanho único. Assim, cada bloco tem uma locali-

zação única e, conhecendo a geometria do dispositivo, ou seja, como os blocos são

dispostos fisicamente pela superfície do dispositivo, torna-se direta a localização de

um determinado bloco, convertendo seu endereço lógico em uma posição determi-

nada. Para acessar um bloco, o mecanismo de leitura/escrita é movimentado de sua

posição atual até uma vizinhança próxima, e a partir deste ponto é realizada uma

busca seqüencial até atingir o bloco procurado. Neste método o tempo de acesso é

variável, dependendo da distância percorrida pelo mecanismo de leitura/escrita.

• Acesso Aleatório: esse método de acesso diferencia-se do acesso seqüencial e

direto pois cada unidade mínima endereçavel está conectada a um mescanismo de

endereçamento próprio. Em uma operação de leitura/escrita, a localização e o acesso

a memória é direto, independete do último acesso realizado no dispositivo, tendo

um tempo de acesso constante.

• Associativo: esse método de acesso é um caso particular de acesso aleatório,

diferenciando-se por fazer uma busca por conteúdo ou parte do conteúdo e não por

endereço. Este método de acesso é utilizado por aplicações especiais que necessitem

detectar se um determinado conteúdo está presente atualmente na memória. Como

no acesso aleatório, o tempo de busca é constante, pois o conteúdo é endereçado e

acessado diretamente.

Uma vez ilustrados os métodos de classificação de memória, as próximas seções irão

detalhar alguns Dispositivos de Armazenamento propriamente ditos.

Page 34: Implementação de um sistema de arquivos para uma plataforma de

12 CAPÍTULO 2. DISPOSITIVOS DE ARMAZENAMENTO

2.2 Fitas

Fitas são utilizadas como dispositivo de armazenamento anteriormente à invenção dos

computadores eletrônicos. Já em 1725, o francês Basile Bouchon desenvolveu a primeira

máquina que utilizava cartão perfurado para reproduzir padrões de tecido no seu tear. Em

1801, o também francês Joseph Marie Jacquard aperfeiçoou esse invento criando o tear

de Jacquard. Esse tear, que é ilustrado na Figura 2.2 em exposição no Museu da Ciência

e Indústria de Manchester, Inglaterra (Museu, 2006), popularizou-se entre os tecelões

da época sendo que, em 1812, existiam aproximadamente 11.000 teares desse tipo em

operação na França.

Figura 2.2: Tear de Jacquard

O inglês Charles Babbage, inspirando-se no tear de Jacquard, especificou a máquina

analítica em 1837, sendo considerado o ponto de partida para os computadores eletrôni-

cos atuais. E ainda no século XIX, em 1889, o americano Herman Hollerith patenteou

um dispositivo capaz de ler grande quantidade de informação, armazenada em forma de

cartões perfurados, chamados de cartões de Hollerith, para serem utilizados em aplica-

Page 35: Implementação de um sistema de arquivos para uma plataforma de

2.2. FITAS 13

ções de estatística. O primeiro uso em larga escala deu-se em 1890 no censo americano,

automatizando o processo que até então era manual e consumia somas elevadas de tempo

e trabalho. Com este invento Hollerith fundou a Tabulating Machine Company, que em

1911 juntou-se com mais 2 empresas para formar a mundialmente conhecida IBM2 (IBM,

2006b).

Na primeira metade do século XX, no início da era do processamento de dados, o

meio de armazenamento mais utilizado era o cartão perfurado. Esse cartão, patenteado

por Hollerith, constituia-se de uma folha de papel geralmente com 80 colunas e 12 linhas

cada, armazenando um caractere por coluna. A informação é representada com a presença

ou ausência de perfurações em coordenadas pré-definidas, e sua leitura, nos primeiros

dispositivos fabricados, ocorria por sensores elétricos, sendo posteriormente implementado

dispositivos ópticos para detectar as coordenadas furadas no cartão. Na Figura 2.3 são

ilustrados um cartão perfurado e sua respectiva unidade de leitura.

Figura 2.3: Cartão Perfurado e sua Respectiva Unidade de Leitura

No auge do desenvolvimento dos cartões perfurados, uma unidade de leitura de cartões

conseguia ler 100 cartões de 80 caracteres por minuto resultando em uma taxa de leitura

de 133 caracteres por segundo.

Outro meio de armazenar informações eram as fitas de papel, as quais eram enroladas

2International Business Machine

Page 36: Implementação de um sistema de arquivos para uma plataforma de

14 CAPÍTULO 2. DISPOSITIVOS DE ARMAZENAMENTO

em uma bobina, e conseqüentemente, por serem maiores que um cartão, armazenavam

mais dados. Na Figura 2.8 são ilustrados dois rolos de fita de papel: em (a) é ilustrada

uma fita utilizada em um antigo computador UNIVAC e em (b) uma fita da empresa

HP3 (HP, 2006) contendo o compilador da linguagem ALGOL.

(a) (b)

Figura 2.4: Fitas de papel utilizadas como dispositivo de armazenamento

Em primeiro de maio de 1952 a IBM revolucionou o mercado de dispositivos de armaze-

manento apresentando a fita magnética, que inicialmente foi desenvolvida para armazenar

música. O primeiro protótipo de uma unidade de leitura de fita magnética é ilustrada na

Figura 2.5. A primeira unidade comercialmente disponível pela IBM tinha a capacidade

de ler 7500 caracteres por segundo, ou seja, 56 vezes mais rápido quando comparado a

fita de papel, sendo que a fita magnética ocupava um espaço bem menor.

A fita magnética é constituída por uma fita plástica de meia polegada de largura co-

berta com óxido magnético, sendo o dispositivo de menor custo e menor velocidade (Stal-

lings, 2002). No processo de leitura/gravação a fita é rebobinada do lado esquerdo para o

direito passando pela cabeça de leitura/gravação em velocidade constante, onde acontece

a operação (Flynn e McHoes, 1985). Os dados são armazenados na fita em unidades

denomidas registros, sendo que os registros podem ter tamanho variado, definido pelo

usuário, existindo um marcador de intervalo entre os registros para facilitar a busca de3Hewlett-Packard

Page 37: Implementação de um sistema de arquivos para uma plataforma de

2.2. FITAS 15

Figura 2.5: Fita Magnética

um registro específico (Flynn e McHoes, 2002)

As primeiras fitas continham 7 trilhas paralelas, armazenando 7 bits por quadro, sendo

6 utilizadas para inserir um dígito decimal codificado em binário e uma trilha para in-

serir o bit de paridade, sendo obsoleto a décadas (Monteiro, 2002). Atualmente as fitas

magnéticas tem 18 ou 36 trilhas, com densidade de até 6250 bytes por polegada, tendo

uma velocidade de transporte de 200 polegadas por segundo (Flynn e McHoes, 2002) e

são conhecidas como fitas DAT 4. A Figura 2.6 ilustra uma fita DAT da marca Sony com

4 GigaBytes de capacidade.

Figura 2.6: Fita DAT de 4 GigaBytes de Capacidade

4Digital Audio Tape

Page 38: Implementação de um sistema de arquivos para uma plataforma de

16 CAPÍTULO 2. DISPOSITIVOS DE ARMAZENAMENTO

Com o desenvolvimento de novas tecnologias de armazenamento de massa mais ágeis, o

uso de sistemas de fita restringiu-se a grandes corporações que manipulam grande quanti-

dade de dados. Os sistemas atuais de grande capacidade são implementados em bibliotecas

automáticas de fitas. Esses dispositivos armazenam em suas bibliotecas várias fitas, sendo

que um robô autônomo é encarregado de carregar a fita até a unidade de leitura/gravação

e posteriormente armazená-la novamente na biblioteca, podendo acessar terabytes em

poucos segundos sem a intervenção humana (Stallings, 2002).

Na Figura 2.7 é ilustrada a biblioteca automática de fitas StorageTek Streamline

SL8500–T1000 da SUN5 (SUN, 2006). Esse dispositivo é um dos mais modernos existen-

tes atualmente, podendo conectar-se à outras bibliotecas. Em sua configuração máxima,

com 32 bibliotecas interconectadas, esse sistema contém 2048 unidades de leitura/escrita,

cada uma operando a 120 megabytes por segundo, podendo armazenar até 300.000 fitas

de 500 gigabytes cada, totalizando 150 perabytes de dados (Sun, 2006).

Figura 2.7: StorageTek Streamline SL8500–T1000

5Sun Microsystems

Page 39: Implementação de um sistema de arquivos para uma plataforma de

2.3. DISCOS RÍGIDOS 17

2.3 Discos Rígidos

Assim como as fitas magnéticas, o disco rígido, também conhecido por HD6, é um dis-

positivo que armazena dados não-voláteis em uma superfície magnetizável, diferenciando-

se das fitas por utilizar um prato magnético em forma de disco e por ser um dispositivo

de acesso direto.

O primeiro disco rígido existente foi fabricado pela IBM em 1956. Chamava-se IBM 350

e era constituído de 50 pratos de superfície dupla e 24 polegadas cada, tendo a capacidade

de armazenar 5 megabytes, o que representava um grande avanço para a época. Cada uma

das 100 superfícies formada por seus 50 pratos eram acessadas por apenas um mecanismo

de leitura/gravação, também conhecida como cabeça de leitura/gravação, resultando em

um tempo lento de acesso médio a uma determinada informação armazenada em um prato

comparado com os sistemas atuais. Na Figura 2.8 (a) é ilustrado esse dispositivo que

media 60x68x29 polegadas. Já na Figura 2.8 (b), é apresentado o IBM 350 internamente,

detalhando o braço da cabeça de leitura/gravação acessando um prato do dispositivo.

Essa unidade de armazenamento, que é a base para os discos rígidos atuais, vendeu mais

de 1000 unidades até o ano de 1961, quando sua produção foi extinta (IBM, 2006a).

Os discos rígidos acompanharam a evolução da microeletrônica reduzindo o tamanho

e aumentando a capacidade e o desempenho. Quanto ao tamanho, os discos diminuíram

de 24 polegadas do IBM 350 para 0,85 polegadas, como o MK4001MTD (Toshiba, 2006a)

da Toshiba (Toshiba, 2006b), o qual é ilustrado na Figura 2.9 comparado a uma moeda.

A capacidade de armazenamento aumentou mais de 100.000 vezes, existindo dispo-

sitivos com capacidade superiores a 500 gibabytes, como por exemplo, o Barracuda ES

ST3750640NS de 3,5 polegadas da Seagate7 (Seagate, 2006), que consegue armazenar 750

6Hard Disk7http://www.seagate.com

Page 40: Implementação de um sistema de arquivos para uma plataforma de

18 CAPÍTULO 2. DISPOSITIVOS DE ARMAZENAMENTO

(a) (b)

Figura 2.8: Disco Rígido IBM 350

gigabytes de dados. Embora evoluções significativas ainda estão por vir na densidade das

superfícies dos discos, um fator limitante de difícil superação está presente nas partes mó-

veis do dispositivo, na velocidade de rotação do disco e na movimentação do mecanismo

de posicionamento das cabeças de leitura/gravação.

Guardadas as diferenças geométricas, o funcionamento do disco rígido é similar ao

funcionamento da fita magnética. O prato é constituído geralmente de alumínio ou vidro,

sendo coberto por uma fina camada magnética. No processo de gravação, a cabeça de

leitura posiciona-se próximo da superfície do prato, e produz um campo magnético. Caso

o campo magnético seja positivo, o pólo negativo da superfície próxima à cabeça irá

ficar alinhada. Caso contrário, o pólo positivo da superfície ficará alinhado com o campo

magnético negativo da cabeça, valendo-se da lei que os opostos se atraem (Resnick et al.,

2003).

No processo de leitura, a operação ocorre de forma inversa. A cabeça de leitura,

que também é constituída de material eletromagnético, polariza-se inversamente ao valor

gerado pelo campo magnético previamente gravado na superfície do disco. A operação de

Page 41: Implementação de um sistema de arquivos para uma plataforma de

2.3. DISCOS RÍGIDOS 19

Figura 2.9: Disco rígido MK4001MTD comparado a uma moeda

leitura ou escrita é realizada várias vezes por segundo conforme a superfície do disco vai

passando pela cabeça de leitura/gravação. A Figura 2.10 ilustra, no detalhe, uma cabeça

de leitura/gravação espelhada na própria superfície do disco.

Figura 2.10: Cabeça de leitura/gravação de um disco rígido

Cada prato de um disco rígido é dividido em trilhas concêntricas, sendo cada trilha

dividida em setores, geralmente de 512 bytes cada. Os primeiros discos rígidos mantinham

Page 42: Implementação de um sistema de arquivos para uma plataforma de

20 CAPÍTULO 2. DISPOSITIVOS DE ARMAZENAMENTO

o mesmo número de setores para cada trilha, ocasionando perda de capacidade de arma-

zenamento, pois setores de trilhas mais externas ocupavam maior área do disco quando

comparados a setores de trilhas mais internas. Nos discos atuais, trilhas próximas são

agrupadas em zonas, quanto maior o raio, maior o número de setores dentro da trilha,

otimizando o aproveitamento de sua superfície.

Um mecanismo utilizado para multiplicar a taxa de transferência foi a implementação

do conceito de cilindro. Para cada superfície dos discos presentes no dispositivo é dispo-

nibilizada uma cabeça de leitura/gravação, sendo que todas as cabeças estão fisicamente

ligadas ao mesmo mecanismo de movimentação. Assim, quando uma cabeça é movimen-

tada para uma determina trilha de sua superfícies, todas as demais cabeças estarão sobre

a mesma trilha de suas respectivas superfícies. Então, o processo de leitura ou escrita é

efetuado em paralelo por todas as cabeças do sistema, sendo o conjunto de cada trilha

de cada superfície acessada concomitantemente é denominado de cilindro. A Figura 2.11

ilustra um esquema de 4 (quatro) pratos com 2 (duas) superfícies cada montadas, sobre o

mesmo eixo e suas respectivas cabeças de leitura/gravação ligadas a um único mecanismo

de movimento (Monteiro, 2002).

Figura 2.11: Paralelismo em um Disco Rígido com 4 (quatro) cabeças de leitura/gravação

Os discos rígidos popularizaram-se maciçamente sendo o mais importante meio de

Page 43: Implementação de um sistema de arquivos para uma plataforma de

2.4. DISCOS FLEXÍVEIS 21

armazenamento externo para computadores, tornando-se padrão nos sistemas computa-

cionais atuais (Stallings, 2002).

2.4 Discos Flexíveis

O disco flexível, também conhecido como FD8 ou disquete, foi desenvolvido para prover

uma unidade de armazenamento mais barata que os dispositivos existentes na época. Seu

funcionamento interno assemelha-se ao disco rígido, diferenciando-se deste na capacidade

de armazenamento, velocidade de acesso e taxa de transferência. Outra característica

peculiar ao disquete é que o disco na qual as informações são gravadas não está fisicamente

preso à unidade de leitura/gravação, possibilitando que um disquete seja acessado por

diversos mecanismos de leitura/gravação. De forma análoga, um único mecanismo de

leitura/gravação poderá ler diversos disquetes.

O primeiro disco flexível, com 8 polegadas de tamanho de disco, foi desenvolvido

na década de 60, com capacidade de armazenar apenas 80 kilobytes e sendo apenas de

leitura. Com o desenvolvimento da tecnologia, os disquetes foram evoluindo, aumentando

a capacidade e diminuindo o tamanho. A evolução posterior ao disco de 8 polegadas

foi o disco de 5 1/4 polegadas, primeiramente disponível com uma superfície de leitura,

chamado de face simples, evoluindo para a face dupla chegando à capacidade de 1.2

megabytes. Com o lançamento da linha PS/2 da IBM, foi desenvolvido mais um sistema

de disco flexível com capacidade para 1.44 megabytes, deferenciando-se fisicamente dos

demais por ter um disco de 3 1/2 polegadas e por proteger o disquete com um invólucro

mais rígido (Monteiro, 2002). A Figura 2.12 ilustra 3 disquetes, de 8, 5 1/4 e 3 1/2

polegadas, possibilitando uma comparação de tamanho entre eles.

Devido à sua facilidade de transferência de dados entre diversos sistemas e sua capa-

8floppy-disk

Page 44: Implementação de um sistema de arquivos para uma plataforma de

22 CAPÍTULO 2. DISPOSITIVOS DE ARMAZENAMENTO

Figura 2.12: Discos Flexíveis de 8, 5 1/4 e 3 1/2 polegadas

cidade de armazenamento satisfatória para a época, os disquetes tiveram rápida popula-

rização, tornando-se dispositivos padrão nos sitemas computacionais nas décadas de 80 e

90.

Atualmente, com o aumento da densidade dos dados e o desenvolvimento de novas

tecnologias de armazenamento com maior capacidade, como os discos ópticos e as memó-

rias de estado sólido, e até mesmo a internet, os disquetes estão caindo em desuso, não

sendo mais encontrados em diversos computadores portáteis e até sendo oferecido como

opcional em alguns computadores pessoais.

2.5 Mídias Ópticas

A mídia óptica surgiu em 1983 com o disco compacto, também conhecido por CD9,

sendo originalmente desenvolvida para armazenar audio digital. Esta nova tecnologia

popularizou-se, sendo o padrão mais utilizado para o armazenamento de músicas, des-

bancando seu concorrente, o disco de vinil, que tinha menor capacidade, durabilidade e

qualidade sonora (Stallings, 2002).

Dois anos após seu lançamento, o CD foi aprimorado, tornando-se mais resistente e

portando mecanismos de correção de erros para detectar e restaurar dados que pudessem

estar corrompidos. Este aprimoramente foi então utilizado para armazenar qualquer tipo

9Compact Disc

Page 45: Implementação de um sistema de arquivos para uma plataforma de

2.5. MÍDIAS ÓPTICAS 23

de dado digitalizado, sendo denominado CD–ROM10. A partir de então, as mídias ópticas

foram sendo utilizadas como meio de armazenamento externo, armazenando uma grande

quantidade de informação, sendo popularmente disponibilizada em duas versões, uma de

650 megabytes de capacidade e outra de 700 megabytes.

O CD é constituído geralmente de um disco de 12 centímetros contendo uma resina do

tipo policarbonato revestido com uma superfície com alto índice de reflexão, normalmente

o alumínio. A gravação é realizada por um laser infravermelho de alta intensidade com

tamanho de onda de 780 nm, que entrando em contato com a superfície do CD cria depres-

sões ou áreas planas. Na operação de leitura, um laser de baixa intensidade é direcionado

na superfície do disco, sendo refletido em um sensor de luminosidade. Quando o laser

está percorrendo um plano, a luz é refletida com mais intensidade quando comparado a

depressão. Então, o fotossensor consegue detectar qual dos dois possíveis estados está

gravado na superfície, convertendo-o em um sinal digital. Conforme o motor da unidade

de leitura/gravação rotaciona o disco, a operação de leitura ou escrita ocorre várias vezes

por segundo (Stallings, 2002).

Diferente dos discos rígidos e dos discos flexíveis, a informação não é gravada em trilhas

concêntricas, e sim, em uma única trilha em espiral. A Figura 2.13 ilustra a disposição

da trilha na superfície do disco. Para efeito de curiosidade, caso essa trilha fosse posta

em uma linha reta, mediria 5,27 quilômetros. Para aproveitar ao máximo a capacidade

de armazenamento, o disco é rotacionado em uma velocidade linear constante, ou seja,

quando a unidade de leitura está em uma área mais externa da superfície, a velocidade

de rotação angular é inferior quando comparado a uma área mais interna da superfície do

disco.

Devido à sua composição, o CD era limitado a uma única operação de escrita em

sua superfície. Este problema foi superado com o desenvolvimento do CD regravável,

10Compact Disc Read Only Memory

Page 46: Implementação de um sistema de arquivos para uma plataforma de

24 CAPÍTULO 2. DISPOSITIVOS DE ARMAZENAMENTO

Figura 2.13: Disposição da trilha em forma de espiral na superfície do disco optico (Ta-nenbaum, 1999)

denominado CD–RW11. O diferencial do CD–RW em relação aos anteriores está na super-

fície do disco, que é constituído de um material que, quando estimulado pelo laser, tem

a capacidade de mudar seu índice de reflexão (para uma configuração de baixa ou alta

reflexão) várias vezes, tornando-se uma boa opção para quem necessita armazenar dados

temporariamente, bastando antes de cada regravação, apagar o conteúdo atual do disco.

Com a crescente evolução da sensibilidade dos dispositivos ópticos foi desenvolvido

o DVD12. Como o CD foi o substituto do disco de vinil para o áudio, o DVD também

foi o substituto para as fitas de vídeo VHS analógicas para o vídeo, obtendo grande

popularização. O DVD diferencia-se do CD pela capacidade de armazenamento, a qual é

de 4,7 gigabytes para as superfícies de uma camada e de 8,5 gigabytes para as superfícies

de duas camadas, apresentando-se em versões gravável e regravável. A operação de leitura

e escrita é similar ao do CD diferenciando-se pelo tipo de laser utilizado, que é um laser

vermelho, com comprimento de onda menor, medindo 650 nm, aumentando a densidade

de gravação.

11Compact Disc Rewritable12Digital Video Disc, ou, mais recentemente Digital Versatile Disc

Page 47: Implementação de um sistema de arquivos para uma plataforma de

2.6. MEMÓRIAS DE ESTADO SÓLIDO 25

Atualmente, as mídias ópticas estão passando por mais uma evolução com a utilização

do laser azul, com comprimento de onda de 405 nm. Em contraste com os desenvol-

vimentos anteriores, não há um consenso entre o mercado para uma solução universal,

existindo duas vertentes explorando essa nova tecnologia. Assim, como no início dos anos

80 houve uma batalha entre o Betamax da Sony (Sony, 2006c) e o VHS da JVC (JVC,

2006) na disputa pelo mercado de fita de vídeo analógico, hoje estamos diante de um ce-

nário parecido no mercado de discos ópticos de altíssima capacidade (Wells, 2005). De um

lado está um consórcio de várias empresas encabeçada pela Toshiba no desenvolvimento

do HD DVD, um disco com 15 gigabytes de capacidade por superfície tendo seu preço

como principal atrativo para os consumidores (Newmérique, 2006). Do outro lado está

um consórcio encabeçado pela Sony (Sony, 2006c) no desenvolvimento do Blue Ray, um

disco com capacidade de armazenar 25 gigabytes de dados por superfície (Sony, 2006a).

2.6 Memórias de Estado Sólido

As memórias de estado sólido são dispositivos que não contêm partes móveis, constitu-

indo-se apenas de semicondutores. Essas memórias podem ser tanto voláteis ou não-

voláteis. Como por exemplo, as voláteis são as memórias de acesso randômico dinâmica

e as memórias de acesso randômico estáticas também conhecidas, respectivamente, por

DRAM e SRAM. Por outro lado, as não-voláteis são as memórias com a capacidade de

manter seu conteúdo mesmo quando o sistema não se encontra ligado (Laplante, 1997).

Atualmente, o principal exemplo de memória de estado sólido não-volátil disponível no

mercado é a memória Flash 13, a qual é geralmente comercializada em dois modelos

distintos, as memórias NOR e as memórias NAND (Ungerer, 2002). O primeiro desses

modelos tem capacidade de acessar diretamente cada palavra da memória para leitura,13EEPROM= Electrically Erasable Programmable Read Only Memory (Memória apenas de leitura

apagável e programável eletricamente)

Page 48: Implementação de um sistema de arquivos para uma plataforma de

26 CAPÍTULO 2. DISPOSITIVOS DE ARMAZENAMENTO

pois ele é dotado de sofisticados controladores que conseguem endereçar individualmente

cada célula. Por essa característica, as memórias NOR são indicadas para dispositivos que

necessitem executar rapidamente pequenas rotinas diretamente sobre a própria memória

que os armazenam, como por exemplo, códigos básicos de inicialização do sistema. Devido

a complexidade do controlador de endereçamento, que acaba consumindo uma grande área

na pastilha da memória, a capacidade de armazenamento desta tecnologia é limitada.

O segundo modelo de memória Flash, as memórias NAND, é indicado para armazena-

mento de grandes quantidades de dados, como as câmeras digitais e os tocadores de música

digital, que armazenam dados sequenciais. A principal diferença das memórias NAND

para as memórias NOR está no acesso aos dados, que é realizado em blocos geralmente

de 512 bytes, utilizando um controlador de endereçamento mais simples, resultando em

um maior aproveitamento da área do chip para a armazenamento de dados (Inc., 2005).

A operação de escrita nas memórias Flash é, obrigatoriamente, realizada em blocos.

Embora as memórias NOR consigam endereçar para leitura cada palavra da memória

em alta velocidade, a operação de escrita é realizada em blocos, sendo uma operação

relativamente lenta. Por outro lado, a operação de escrita nas memória NAND podem

ser realizadas em blocos do mesmo tamanho quando comparados a operação de leitura,

operando na mesma velocidade (Hennessy e Patterson, 2003).

Por sua natureza física sem partes móveis, essas memórias apresentam diversas van-

tagens sobre as memórias que contém algum dispositivo mecânico, sendo mais robusta a

choques, tendo tempo de acesso constante, maior durabilidade, menor consumo de energia,

operando sem poluição sonora. Por outro lado, embora vários avanços estejam sendo con-

quistados, encontrando-as cada vez mais baratas e com maior capacidade. Atualmente,

as memórias Flash estão mais caras e com menor densidade quando comparados a outros

meios de armazenamento externos tradicionais.

Com os avanços alcançados na indústria de memórias de estado sólido, as memórias

Page 49: Implementação de um sistema de arquivos para uma plataforma de

2.6. MEMÓRIAS DE ESTADO SÓLIDO 27

Figura 2.14: Dispositivo de memória USB Flash Drive

Flash estão cada vez mais presentes nos equipamentos eletrônicos, sendo utilizadas para

os mais diversos fins, como celulares, câmeras fotográficas, tocadores de música e vídeo,

computadores de mão, impressoras, etc. Recentemente a Samsung (Samsung, 2006) lan-

çou o primeiro computador portátil baseado em discos de estado sólido (Williams, 2006;

Datalight, 2005a), utilizando memórias Flash do tipo NAND com capacidade para 32

gibabytes, apostando nas vantagens dessa tecnologia em contraste aos modelos baseados

em discos rígidos (Datalight, 2005b).

Existem várias alternativas de dispositivos de armazenamento baseados em memórias

de estado sólido disponíveis no mercado. Nas próximas seções são ilustradas as principais

alternativas, enfatizando a utilizada neste trabalho.

2.6.1 USB Flash Drive

O USB Flash Drive, também conhecido como pendrive, é um dispositivo de memória

Flash externa integrado a uma interface USB 14 (USB, 2006). O desenvolvimento desse

dispositivo foi motivado pela grande disseminação de portas de comunicação USB nos

computadores pessoais, transformando-se em um disco removível extremamente portátil,

podendo ser inserido em qualquer sistema que apresente uma interface USB disponível.

Atualmente, o USB Flash Drive é o dispositivo de memória de estado sólido de maior

capacidade. A empresa Kanguru Solutions (Kanguru, 2006b) lançou em meados de 2006

o Kanguru Flash Drive Max 64GB atingindo impressionantes 64 gigabytes de armazena-

mento em apenas 18 gramas de peso, custando U$ 2.799,95 no mercado americano (Kan-

14Universal Serial Bus

Page 50: Implementação de um sistema de arquivos para uma plataforma de

28 CAPÍTULO 2. DISPOSITIVOS DE ARMAZENAMENTO

guru, 2006a). Este dispositivo é ilustrado na Figura 2.14.

A velocidade na transferência dos dados depende do modelo de cada fabricante, po-

dendo chegar a 24 megabytes por segundo na operação de leitura e a 14 megabytes por

segundo na operação de escrita em modelos de alto desempenho, como o DataTraveler

Elite (Kingston, 2006) da Kingston Technology Company. Outra característica importante

associada a esses discos removíveis é a possibilidade de serem encapsulados com outros

dispositivos, como tocadores de áudio e vídeo digital, e até mesmo rádio FM, aumentando

sua funcionalidade.

2.6.2 Memory Stick

A linha de cartão de memória Memory Stick (Sony, 2006b) foi desenvolvida pela

Sony (Sony, 2006c) para ser utilizada como padrão de memória removível em seus pro-

dutos, sendo apresentado ao público em 1998 (Sony, 1998). Atualmente, além da Sony,

também a Sony Ericson (SonyEricson, 2006) utiliza este cartão como unidade de armaze-

namento, tendo a sua produção licenciada para a SanDisk (Sandisk, 2006) e Lexar (Lexar,

2006).

Esses cartões são apresentados em 5 (cinco) modelos e 3 (três) diferentes tamanhos,

especificados a seguir:

1. Standard Memory Stick e Memory Stick Pro: 50.0mm X 21.5mm X 2.8mm;

2. Memory Stick Duo e o Memory Stick Pro Duo: 31.0mm X 20.0mm X 1.6mm e

3. Memory Stick Micro: 15.0mm X 12.5mm X 1.2 mm.

Com o uso de um adaptador próprio, os dois modelos menores mantém as caracte-

rísticas físicas do Standard Memory Stick, podendo ser utilizado em qualquer dispositivo

que tenha essa interface. Na Figura 2.15 são ilustrados os 3 (três) diferentes tamanhos

disponíveis.

Page 51: Implementação de um sistema de arquivos para uma plataforma de

2.6. MEMÓRIAS DE ESTADO SÓLIDO 29

Figura 2.15: Três diferentes tamanhos disponíveis de Memory Stick: Pro, Pro Duo eMicro

Atualmente, a capacidade máxima de armazenamento é de 8 gigabytes, e a velocidade

máxima de transferência é de 20 megabytes por segundo na operação de leitura e de 10

megabytes por segundo para a operação de escrita.

2.6.3 xD–Picture Card

O cartão de memória xD–Picture 15 é o único cartão desenvolvido, exclusivamente,

para ser utilizado em câmeras fotográficas digitais (xD Picture, 2006). Esse cartão foi

lançado em 2002 pelas empresas Fuji Photo Film (FujiFilm, 2006) e Olympus (Olympus,

2006), sendo utilizado apenas em seus produtos e manufaturados pelas empresas Toshiba

Corporation (Toshiba, 2006b), Samsung Electronics (Samsung, 2006), Kodak (Kodak,

2006), SanDisk (Sandisk, 2006) e Lexar (Lexar, 2006).

Esse cartão é apresentado em um único tamanho de 20 mm x 25 mm x 1,78 mm, como

ilustrado na Figura 2.16. Suas velocidades máximas de leitura e escrita são, respectiva-

mente, 15 megabytes por segundo e 9 megabytes por segundo.

Uma desvantagem dessa tecnologia em contraste com seus concorrentes está na capa-

15Extreme Digital

Page 52: Implementação de um sistema de arquivos para uma plataforma de

30 CAPÍTULO 2. DISPOSITIVOS DE ARMAZENAMENTO

Figura 2.16: Dispositivo de Memória xD–Picture Card

Figura 2.17: Compact Flash I de 2 GigaBytes de capacidade

cidade de armazenamento, sendo atualmente de apenas 1 gigabyte. Outra desvantagem

está relacionada à falta de portabilidade do cartão em outros dispositivos, não dando

alternativas de utilização ao usuário, obrigando-o a utilizá-lo apenas nas câmeras digitais.

2.6.4 Compact Flash

O cartão de memória Compact Flash foi especificado e produzido pela SanDisk (San-

disk, 2006) em 1994, sendo a mais velha memória flash removível dentre os modelos dispo-

níveis atualmente. Em 1996 foi criada uma associação responsável pelo desenvolvimento

do cartão, chamada CFA - Compact Flash Association (Compact, 2006).

Desde o seu lançamento, esta memória flash mantém suas características físicas, sendo

disponibilizadas em dois tamanhos, o modelo Compact Flash I medindo 43 mm x 36 mm

x 3,3 mm e o modelo Compact Flash II medindo 43 mm x 36 mm x 5 mm. Na Figura 2.17,

é ilustrado um cartão SanDisk Extreme III CompactFlash com capacidade de 2 gigabytes.

Embora o modelo Compact Flash II seja assim denominado, geralmente não é baseado

em memória flash, e sim em disco rígido. Porém, compartilhando o mesmo protocolo de

Page 53: Implementação de um sistema de arquivos para uma plataforma de

2.7. DISPOSITIVOS DE ARMAZENAMENTO UTILIZADOS NESTE PROJETO 31

comunicação que o seu modelo mais fino baseado em memória flash, o Compact Flash I.

Devido ao seu grande tamanho, o maior entre as atuais memórias flash removíveis,

está é a memória que tem maior potencial de crescimento de capacidade. Entretanto, é

a que tem menor aceitação entre os dispositivos ultra compactos, como computadores de

mão e telefones celulares.

O cartão de memória Compact Flash é o que tem melhor desempenho entre seus concor-

rentes, podendo chegar a 40 MegaBytes por segundo tanto na operação de leitura quanto

na operação de escrita na linha SanDisk Extreme IV CompactFlash, com capacidade de

até 8 GigaBytes.

2.7 Dispositivos de Armazenamento Utilizados Neste Projeto

Existem ainda dois padrões bastante utilizados como cartão de memória, o cartão SD

e o cartão MMC que por ser motivo deste trabalho serão descritos em detalhes na próxima

seção.

2.7.1 SD Card

O cartão SD16 foi apresentado em 1999 pelas empresas Panasonic (Panasonic, 2006),

Sandisk (Sandisk, 2006) e Toshiba (Toshiba, 2006b) medindo 24 mm x 32 mm x 2.1 mm,

sendo posteriormente criada no ano de 2000 uma associação para cuidar das questões de

padrão e licenciamento, denominada SDA17 (Secure, 2006), sendo disponibilizado neste

mesmo ano para comercialização. Na Figura 2.18 é ilustrado um cartão de memória SD

da Sandisk com 512 megabytes de capacidade.

Em 2003, a SDA lançou um novo modelo de cartão baseado no cartão SD denominado

16Secure Digital17Secure Digital Card Association

Page 54: Implementação de um sistema de arquivos para uma plataforma de

32 CAPÍTULO 2. DISPOSITIVOS DE ARMAZENAMENTO

Figura 2.18: Cartão SD da Sandisk com 512 MegaBytes de capacidade

miniSD, diferenciando-se do cartão SD apenas pelo menor tamanho, medindo 20 mm x

21.5 mm x 1.4 mm, mantendo as mesmas características internas de funcionamento. Essa

nova interface pode ser acoplada a um adaptador, possibilitando a inserção do cartão em

um conector padrão SD. Na Figura 2.19 é ilustrado um cartão miniSD e o seu adaptador.

Figura 2.19: Cartão miniSD e seu adaptador para o padrão SD

Um ano após o lançamento do miniSD, a SanDisk fez o lançamento da menor me-

mória removível do mundo, denominada TransFlash (Sandisk, 2004). Essa memória teve

seu nome alterado em 2005 pela SDA, passando a chamar-se MicroSD. Com dimensões

reduzidas (Figura 2.20 (a)), aproximando-se às de uma unha humana, como pode ser visto

na Figura 2.20 (b), o MicroSD foi desenvolvido para ser utilizado em dispositivos ultra

compactos, como aparelhos celulares, com capacidade de armazenar programas aplicati-

vos para câmeras digitais, MP3 players, jogos e e acesso a internet. Esse cartão também

Page 55: Implementação de um sistema de arquivos para uma plataforma de

2.7. DISPOSITIVOS DE ARMAZENAMENTO UTILIZADOS NESTE PROJETO 33

dispõe de um adaptador para ser compatível com conectores do tipo SD. O sistema im-

plementado foi validado em um cartão SD tamanho padrão e em um cartão MicroSD.

(a) (b)

Figura 2.20: Dispositivo MicroSD (TransFlash)

Os cartões SD estão tendo uma grande aceitação nos dispositivos eletrônicos, sendo

encontrados em uma grande gama de produtos, como aparelhos de som, tocadores de

DVD e impressoras, principalmente por serem menores que os cartões Compact Flash, e

com menor restrição de licença que os cartões Memory Stick e o xD–Picture.

Atualmente, os cartões SD de maior capacidade conseguem armazenar 4 gigabytes,

chegando a velocidade máxima de 22,5 megabytes por segundo para leitura e escrita nos

modelos de alto desempenho.

As principais características do cartão SD são:

• alvo para aplicação tanto móveis como estacionárias;

• suporte PnP18;

• tensão de inicialização de 2,0 a 3,6 Volts;

• tensão de operação de 3,1 a 3,5 Volts;

• suporte para cartão apenas leitura e leitura/escrita;18Plug and Play

Page 56: Implementação de um sistema de arquivos para uma plataforma de

34 CAPÍTULO 2. DISPOSITIVOS DE ARMAZENAMENTO

• clock variável de 0 a 50 MhZ; e

• remoção do dispositivo durante uma operação de leitura não acarretando em dano

ao conteúdo da memória.

Após uma apresentação sucinta do cartão SD, na próxima seção será vista com maiores

detalhes como se dá a interface entre o cartão e o sistema que o utiliza.

2.7.1.1 Interface do Cartão SD

A interface do cartão com um sistema pode ser realizada em dois modos de operação.

O primeiro é o modo SD, que tem como principal característica a utilização de um barra-

mento de dados de 4 vias, transmitindo 4 bits por sinal de clock. Este modo de operação

utiliza um protocolo de comunicação proprietário da SDA não podendo ser utilizado sem

o pagamento de uma licença.

O segundo modo de operação é baseado na interface SPI 19, que é uma interface serial

para a troca de dados entre dispositivos. Essa interface tem a capacidade de transmitir

apenas 1 bit por sinal de clock e trata-se de um padrão aberto, podendo ser desenvolvido

sem a necessidade de pagamento de licença. Por questão de custo, a interface utilizada

neste trabalho é a interface SPI.

A interface do dispositivo com o sistema ocorre através de 9 (nove) pinos. Na Fi-

gura 2.21 é ilustrada o layout dos pinos do cartão SD bem como a descrição funcional de

cada pino.

O cartão é alimentado pelo pino 4 (Vdd), tendo 2 pinos de aterramento (3 e 6). Todo

o sincronismo da operação é realizado pelo pino 5 (CLOCK) que é fornecido pelo host.

Os comandos são enviados pelo host através do pino 2 (DataIn), assim como os dados,

19Serial Peripheral Interface

Page 57: Implementação de um sistema de arquivos para uma plataforma de

2.7. DISPOSITIVOS DE ARMAZENAMENTO UTILIZADOS NESTE PROJETO 35

Pino Nome Descrição1 CS Seleção de chip2 DataIn Host para cartão, comandos e dados3 Vss1 Terra4 Vdd Fonte de alimentação5 CLOCK Relógio6 Vss2 Terra7 DataOut Cartão para host, dados e estado8 – não utilizado no protocolo SPI9 – não utilizado no protocolo SPI

Figura 2.21: Descrição dos Pinos do Cartão SD

em uma operação de escrita no cartão. O estado do dispositivo é enviado pelo pino 7

(DataOut), junto com os dados, em uma operação de leitura no cartão.

Na próxima seção serão detalhados os procedimentos de escrita e leitura no cartão SD.

2.7.1.2 Escrita e Leitura no Cartão SD

As operações sobre o cartão SD são simples e totalmente compatíveis com os 3 modelos

de cartão existentes. O host envia o comando a ser executado serialmente pelo pino DataIn

e recebe a resposta do cartão pelo pino DataOut. Se a ação associada ao comando envolver

a transferência de algum bloco de dados, o mesmo é enviado pelo pino DataOut, sendo que,

após o envio de cada bloco pode ser transmitido um bloco de conferência para detectar

se houve alguma falha no envio. A técnica utilizada para gerar o bloco de conferência é o

CRC20, que consiste em, através de uma função que tem como variável o bloco transferido,

gerar uma sequência de bits. Quando o host está de posse do bloco de dados e do bloco de

conferência, ele executa uma função similar à do cartão sobre o bloco de dados, e compara

os bits gerados por ele com os enviados pelo cartão. Caso ocorra alguma divergência entre

os dois é porque houve uma falha no envio. No caso de falha o host poderá fazer uma

requisição de reenvio do bloco inconsistente ao cartão, obtendo um bloco sem falhas. Toda

20(Cyclic Redundancy Check)

Page 58: Implementação de um sistema de arquivos para uma plataforma de

36 CAPÍTULO 2. DISPOSITIVOS DE ARMAZENAMENTO

operação de escrita no cartão é seguida por uma operação de leitura, para confirmar que

os dados foram escritos corretamente. Caso haja um bit defeituoso, este bit é trocado por

um bit sobressalente. Na ocorrência de mais de uma falha, o setor inteiro é susbstituído

por um setor reservado. Esta operação é completamente transparente para o host e não

altera a capacidade do cartão.

Uma característica importante a ser destacada é que as operações de leitura/escrita

podem ser realizadas através de transferências simples de blocos ou de transferências múl-

tiplas de dados. Se a operação envolver transferência múltipla de blocos o host precisará

enviar apenas um comando e os blocos são disponibilizados um após o outro serialmente,

até que o host envie um comando de parada no envio, aumentando sensivelmente a velo-

cidade da transferência.

Na Figura 2.22 é demonstrada uma operação de leitura realizada no dispositivo. No

início, o host envia para o cartão um comando de leitura de bloco, e logo após o cartão

envia uma resposta ao host aceitando o comando. Com a resposta enviada, o cartão

começa a enviar o bloco seguido do CRC. Se o comando envolver transferência simples de

dado a operação se encerra. Caso contrário, o cartão continua enviando os blocos até o

envio pelo host de um comando requisitando a parada do envio. A operação é encerrada

com o envio da resposta do cartão para o host.

Figura 2.22: Operação de Leitura (Múltiplos) Blocos

Page 59: Implementação de um sistema de arquivos para uma plataforma de

2.7. DISPOSITIVOS DE ARMAZENAMENTO UTILIZADOS NESTE PROJETO 37

A operação de escrita comporta-se de forma similar a de leitura, como demonstrado

na Figura 2.23. A diferença na escrita consiste na realização adicional da conferência de

consistência no bloco, após o envio do mesmo pelo host para o cartão com os bits do

CRC, para detectar se houve falha no envio. Caso não haja falha no envio o cartão irá

programar o bloco recebido na memória. Esse processo demora um tempo deixando o

cartão indisponível. Nessa fase o cartão envia um sinal de ocupado no barramento de

dados, informando quando a programação estiver concluída, estando apto para executar

novas operações.

Figura 2.23: Operação de Escrita (Múltiplos) Blocos

2.7.2 MMC - MultiMedia Card

O cartão MMC foi desenvolvido pela Siemens (Siemens, 2006) e pela Sandisk (Sandisk,

2006) em 1997, com o tamanho de 24mm x 32 mm x 1.4 mm, sendo desenvolvido para

concorrer com o cartão Compact Flash que tinha dimensões superiores. Atualmente,

existe uma associação que controla o desenvolvimento do cartão, chamada MultiMedia

Card Association(MMCA) (MultimediaCard, 2006).

Em 2004 a MMCA apresentou um novo modelo de cartão com dimensões de 18 mm x

24 mm x 1.4 mm chamado Reduced-Size MultiMediaCard(RS-MMC), lançando em seguida

um modelo ainda menor com 14 x 12 x 1.1 mm chamado MMCmicro.

Page 60: Implementação de um sistema de arquivos para uma plataforma de

38 CAPÍTULO 2. DISPOSITIVOS DE ARMAZENAMENTO

Figura 2.24: Diferença de pinagem entre os cartões MMC e MMCpluls (vista superior)

Figura 2.25: Os três modelos disponíveis de cartão MMC: MMC PLUS, MMC mobile eMMC micro

Recentemente, após a publicação da versão 4.1 da especificação do cartão MMC (MMCA,

2005) em 2005, os cartões MMC e RS-MMC foram substituídos, entrando no seu lugar

os cartões MMCplus e MMCmobile, respectivamente, mantendo-se a mesma dimensão de

seus antecessores, mas, alterando a sua pinagem e com novos recursos. A Figura 2.24

ilustra as diferenças de pinos entre os cartões MMC e MMCplus, alterando de 7 para 13

pinos, e a Figura 2.25 demonstra os 3 modelos de cartões disponíveis.

Após a criação do cartão SD, o cartão MMC vem perdendo espaço no mercado, pois

tem menor capacidade e desempenho, chegando a 2 GigaBytes de capacidade e 11 Me-

gaBytes por segundo na operação de leitura e 7 MegaBytes por segundo na operação de

escrita. Entretanto, com a publicação da versão 4.1 da especificação do cartão MMC, a

MMCA aumentou significativamente a possibilidade de capacidade e desempenho, prome-

tendo aumentar a rivalidade entre os dois padrões que compartilham o mesmo conector.

Page 61: Implementação de um sistema de arquivos para uma plataforma de

2.8. CONSIDERAÇÕES FINAIS 39

A seguir será descrita a interface do cartão MMC.

2.7.2.1 Interface do cartão MMC

Existem duas configurações de pinos possíveis, como foi ilustrado na Figura 2.24. A

anterior, a especificação 4.1 de 7 pinos e a da versão 4.1 de 13 pinos. A versão mais antiga,

a utilizada neste trabalho, tem dois modos de operação, o modo MMC e o modo SPI.

Para manter a compatibilidade com a implementação do protocolo de comunicação SPI

do cartão SD, foi implementado o modo SPI neste trabalho, que opera de forma similar

ao cartão SD no modo SPI, já descrito na Seção 2.7.1.2, tendo seus pinos descritos na

Tabela 2.1.

Pino Nome Descrição1 CS Seleção de Chip2 DataIn Host para Cartão Comandos e Dados3 Vss1 Terra4 Vdd Fonte de alimentação5 CLOCK Relógio6 Vss2 Terra7 DataOut Cartão para Host Dados e Estado

Tabela 2.1: Definição dos Pinos do Cartão MMC no modo SPI (7 Pinos)

A versão mais recente da especificação do cartão MMC, que não foi utilizada neste

trabalho, diferencia-se da antiga por dispor de uma segunda fileira de pinos como foi

ilustrado na Figura 2.24. Com esta nova configuração, a transferência de dados pode

ser realizada 8 vezes mais rápida quando comparada a versão anterior, pois contém um

barramento de 8 vias, transferindo 1 byte a cada ciclo de clock, como pode ser visto na

Tabela 2.2.

A operação de leitura e de escrita no cartão MMC utilizado neste projeto no modo SPI

é similar a operação de leitura e de escrita do cartão SD utilizando o mesmo protocolo.

Page 62: Implementação de um sistema de arquivos para uma plataforma de

40 CAPÍTULO 2. DISPOSITIVOS DE ARMAZENAMENTO

Pino Nome Descrição1 DADO[3] bit 3 do barramento de dado2 CMD Comando / Resposta3 Vss1 Terra4 Vdd Fonte de alimentação5 CLOCK Relógio6 Vss2 Terra7 Data[0] bit 0 do barramento de dado8 Data[1] bit 1 do barramento de dado9 Data[2] bit 2 do barramento de dado10 Data[4] bit 4 do barramento de dado11 Data[5] bit 5 do barramento de dado12 Data[6] bit 6 do barramento de dado13 Data[7] bit 7 do barramento de dado

Tabela 2.2: Definição dos Pinos do Cartão MMC no modo MMC(13 Pinos)

2.8 Considerações Finais

Os dispositivos de armazenamento apresentados neste capítulo são utilizados para

armazenar grandes volumes de dados em um sistema computacional. Tais dispositivos,

com as constantes evoluções tecnológicas, vêm aumentando rapidamente sua capacidade

de armazenamento e diminuindo o tempo de acesso ao dado armazenado.

Várias são as alternativas de dispositivos de armazenamento, cada qual com caracte-

rísticas específicas. O presente trabalho, que tem um de seus focos voltado para a área de

sistemas móveis, deve privilegiar os dispositivos de armazenamento com baixo consumo

de energia e robustos a choques. Por atender a esses quesitos, as memórias de estado

sólido SD e MMC, descritas neste capítulo, foram as escolhidas.

Page 63: Implementação de um sistema de arquivos para uma plataforma de

Capítulo

3

Sistema de Arquivos

Os sistemas computacionais atuais são geralmente constituídos de diversos módulos,

como por exemplo, os dispositivos de armazenamento de massa. Esses dispositivos são

capazes de armazenar grandes quantidades de dados, as quais devem ser estruturadas de

forma a possibilitar posterior recuperação e manipulação das mesmas. O gerencimento

desses dispositivos, bem como o provimento de uma interface computacional mais amigável

para o desenvolvimento de aplicações que os utilizem é a razão da existência do Sistema

de Arquivos.

Neste capítulo é apresentada uma visão geral de Sistema de Arquivos, bem como o

sistema de arquivos implementado.

41

Page 64: Implementação de um sistema de arquivos para uma plataforma de

42 CAPÍTULO 3. SISTEMA DE ARQUIVOS

3.1 Introdução

Todas as aplicações executadas em um sistema computacional necessitam manipular

dados. Um processo em execução pode facilmente consumir um dado por ele produzido,

bem como, consumir dados de outros processos em execução através de mecanismos de

troca de mensagem. Porém, em determinadas situações, um processo necessita de dados

produzidos por processos que não se encontram mais ativos, dados estes que dependendo

da particularidade deverão ser mantidos no sistema por tempo indeterminado. Outro

problema consiste no fato de que o dado, gerado por uma determinada aplicação, po-

derá ser necessário para outro processo que venha a ser executado, devendo o sistema

disponibilizar mecanismos para o efetivo compartilhamento desses dados entre diversas

aplicações.

Para solucionar esses problemas o dado é armazenado em algum dispositivo de arma-

zenamento não volátil, em unidades denominadas arquivos (Seção 3.2), as quais poderão

ser posteriormente recuperadas e manipuladas pelos processos. A responsabilidade pela

criação, remoção e modificação dos arquivos, bem como pelo controle de acesso a eles, é

atribuída ao Sistema de Arquivos. Para atender, as suas responsabilidades o Sistema de

Arquivos precisa basicamente executar quatro tarefas, descritas a seguir:

1. Manter um registro de onde cada arquivo está armazenado;

2. Adotar um critério que determine onde e como os arquivos devem ser armazenados,

de forma que o espaço disponível para armazenagem seja eficientemente aproveitado

e os arquivos facilmente acessados;

3. Alocar cada arquivo ao usuário que obteve permissão para acessá-lo e registrar cada

acesso; e

Page 65: Implementação de um sistema de arquivos para uma plataforma de

3.2. ARQUIVOS 43

4. Desalocar o arquivo assim que ele estiver pronto para voltar para o dispositivo de

armazenamento e comunicar sua disponibilidade a outros usuários que porventura

estejam esperando por ele.

Para um melhor entendimento destas tarefas, nas próximas seções o conceito de ar-

quivos é mostrado em detalhes.

3.2 Arquivos

Um arquivo é uma coleção de informações relacionadas, e pode representar tanto um

programa como um dado informativo. De forma geral um arquivo é simplesmente uma

seqüência de bits cujo significado é definido por quem o criou. A criação de um arquivo

deve levar em consideração alguns aspectos importantes, tais como a sua identificação, a

sua estrutura, os seus atributos e o seu tipo. Esses aspectos são detalhados a seguir.

3.2.1 Identificação

Cada Sistema de Arquivos tem sua própria regra para nomear seus arquivos, e todos os

sistemas atuais permitem uma identificaçã de pelo menos 8 caracteres. Alguns Sistemas

de Arquivos fazem distinção entre caracteres maiúsculos (caixa alta) e minúsculos (caixa

baixa), como por exemplo, os Sistemas de Arquivos baseados em UNIX1. Por outro lado,

existem outros Sistemas de Arquivos que não fazem essa distinção, como por exemplo, os

Sistemas de Arquivos baseados em Windows2.

1UNIX é um Sistema Operacional portável, multitarefa e multiusuário originalmente criado por umgrupo de programadores da AT&T e dos Bell Labs, que incluem Ken Thompson, Dennis Ritchie e DouglasMcIlroy. Atualmente, existem várias versões de sistemas baseados no UNIX, podendo destacar: SunOS,Solaris, IRIX, AIX, HP-UX, OSF, SCO, NeXTSTEP e Linux.

2Sistema Operacional dominante do mercado, desenvolvido pela Microsoft baseado em janelas, sendoo sucessor do MS–DOS (Sistema Operacional de Disco).

Page 66: Implementação de um sistema de arquivos para uma plataforma de

44 CAPÍTULO 3. SISTEMA DE ARQUIVOS

É comum nos Sistemas de Arquivos existentes o acréscimo de uma extensão, separada

por um ponto, à sua identificação. Essa extensão representa uma característica associada

à funcionalidade do arquivo, facilitando a recuperação do tipo de informação contida no

mesmo. Na Tabela 3.1 são mostradas algumas extensões com o seu respectivo significado.

Extensão Significado.bak Arquivo de backup.c Código fonte da linguagem C.gif Arquivo de imagem no formato GIF.hlp Arquivo de ajuda.html Arquivo de hipertexto.jpg Arquivo de imagem no formato JPEG.mp3 Arquivo de música no formato MPEG layer 3.mpg Arquivo de vídeo

.o Arquivo objeto.pdf Arquivo no formato PDF(Portable Document Format).ps Arquivo no formato PS(Post Script).tex Arquivo de entrada para o programa TEX.txt Arquivo de texto.zip Arquivo compactado.exe Arquivo executável

Tabela 3.1: Extensões típicas de arquivos.

3.2.2 Estrutura

Cada arquivo, necessariamente, é estruturado de alguma forma no dispositivo de ar-

mazenamento. As formas mais comuns utilizadas nesta estruturação são as seqüências

de bytes, as seqüências de registros e a estruturação em árvore, conforme ilustrado na

Figura 3.1.

As seqüências de bytes (Figura 3.1 (a)) deixam a cargo do processo criador do arquivo

implementar a estrutura do mesmo, ausentando o Sistema de Arquivos dessa responsabi-

lidade. Tal característica dá uma grande flexibilidade ao projetista da aplicação.

Page 67: Implementação de um sistema de arquivos para uma plataforma de

3.2. ARQUIVOS 45

Figura 3.1: Três tipos de estruturas de arquivos

Na segunda forma, chamada de seqüências de registros (Figura 3.1 (b)),o Sistema de

Arquivos é o responsável pelas operações de escrita/leitura, sendo que cada operação é

realizada sobre um registro inteiro, e não apenas bytes, como na forma anterior.

Já a estruturação em árvore (Figura 3.1 (b)) consiste em estruturar o arquivo em

árvores de registros, sendo que cada registro conterá um campo com uma chave específica.

Os registros são dispostos nesta árvore seguindo a ordenação das chaves, permitindo

uma rápida busca para uma chave em particular. Este tipo de estrutura é utilizado

intensamente em computadores de grande porte dedicados ao processamento de grande

volume de dados.

3.2.3 Atributos de Arquivos

Uma vez criado o arquivo e identificado, é comum atribuir ao mesmo algumas infor-

mações úteis ao seu respeito, as quais são chamadas atributos. Cada Sistema de Arquivos

implementa seus próprios atributos, sendo alguns deles comuns à maioria dos Sistemas de

Page 68: Implementação de um sistema de arquivos para uma plataforma de

46 CAPÍTULO 3. SISTEMA DE ARQUIVOS

Arquivos existentes.

Como exemplos de atributos de arquivos pode-se citar:

• hora de criação;

• hora de modificação;

• hora do último acesso;

• sinalização de arquivo de sistema; e

• sinalização de arquivo oculto.

Os Sistemas de Arquivos que implementam mecanismos de proteção podem ter, por

exemplo, os seguintes atributos:

• proprietário;

• criador;

• senha de acesso;

• grupo de usuários com acesso;

• sinalização de arquivo oculto; e

• permissões (leitura, escrita e execução).

3.2.4 Tipos de Arquivos

Cabe ao Sistema de Arquivos definir os tipos de arquivos existentes no sistema. Os

tipos de arquivos mais comuns são:

Page 69: Implementação de um sistema de arquivos para uma plataforma de

3.3. DIRETÓRIOS 47

Regulares: São os arquivos que os usuários estão acostumados a manipular, criados

por processos e que contém alguma informação que está armazenada em algum

meio. Esses arquivos podem ser binários ou arquivos ASCII. Os arquivos ASCII

contém apenas caracteres que possam ser impressos, já os binários podem conter

qualquer tipo de caracter. Os arquivos binários ainda podem dividir-se em arquivos

executáveis e arquivos não executáveis.

Especiais de caracteres: São arquivos especiais que modelam dispositivos seriais (o

mouse e o teclado, por exemplo) do sistema. Uma vez modelados, qualquer ope-

ração de leitura/escrita em um dispositivo será facilmente executada por meio da

leitura/escrita do arquivo que o modela.

Especiais de bloco: São arquivos especiais similares aos de caracteres, com a diferença

de modelarem dispositivos de bloco (as unidades de disco, por exemplo) do sistema.

Diretórios: São arquivos que não estão associados diretamente a um conjunto de dados,

como os arquivos regulares, mas sim a um agrupamento de arquivos que possam

ter algum vínculo entre si. Os diretórios serão detalhados com maior precisão na

próxima seção.

3.3 Diretórios

Os diretórios, também conhecidos como pastas, são um tipo especial de arquivos que

não estão associados diretamente a um conjunto de dados, mas sim a um agrupamento

de arquivos que possam ter algum vínculo entre si. Fazendo uma analogia ao mundo

real, seria como um armário, com várias portas e gavetas (diretórios), cada uma contendo

um tipo específico de objeto (arquivos), separando-os por grupo de interesse, provendo

Page 70: Implementação de um sistema de arquivos para uma plataforma de

48 CAPÍTULO 3. SISTEMA DE ARQUIVOS

assim uma melhor organização ao sistema. As próximas seções visam o detalhamento das

principais formas utilizadas na implementação de diretórios.

3.3.1 Diretórios com Um Nível

Essa é a forma mais simples utilizada na implementação de diretórios. Ela consiste

na criação de apenas um diretório, chamado de diretório raiz, no qual todos os arquivos

estão dispostos, e não possibilita a criação de novos diretórios. Esse tipo de estrutura

foi utilizada nos primeiros Sistemas de Arquivos, assim implementados para garantir a

simplicidade, a qual era desejável dado o baixo poder computacional existente na época.

Essa simplicidade na implementação resulta em um alto grau de performance nas opera-

ções realizadas nos arquivos, sendo ainda utilizada em sistemas embarcados específicos.

Na Figura 3.2 é ilustrado um diretório com um nível.

Figura 3.2: Sistema de diretório de nível único

O principal problema associado a essa organização surgiu com o advento de sistemas

com múltiplos usuários. Os usuários não se sentiam confortáveis em compartilhar o mesmo

diretório de trabalho com os outros usuários. Para superar essa limitação foi desenvolvido

o sistema de diretório com dois níveis, o qual será abordado na próxima seção.

3.3.2 Diretórios com Dois Níveis

A implementação de diretórios em dois níveis, como já citado, surgiu para prevenir

conflitos entre os diversos usuários que compartilhavam o mesmo diretório para armazenar

Page 71: Implementação de um sistema de arquivos para uma plataforma de

3.3. DIRETÓRIOS 49

seus dados. Dessa forma, tornou-se possível criar diretórios dentro do diretório raíz,

possibilitando a cada usuário ter seu próprio diretório para armazenar seus arquivos.

Essa forma de implementação é ilustrada na Figura 3.3, na qual pode-se notar a

existência de diretórios de usuários.

Figura 3.3: Sistema de diretório de dois níveis

Uma característica de segurança importante incorporada em sistemas com múltiplos

usuários implementando diretórios de dois níveis foi o desenvolvimento de mecanismos de

proteção baseados em autenticação. Com esse mecanismo, cada usuário deve se autenticar,

utilizando um nome de usuário e uma senha, ao iniciar o sistema, para acessar apenas

arquivos que seja o proprietário, ou, arquivos que o real proprietário permita que outros

usuários acessem-o, como o diretório de programas aplicativos da Figura 3.3, que poderia

ser compartilhado entre todos usuários, por conter arquivos de interesse comum.

3.3.3 Diretórios Hierárquicos

Os crescentes avanços nos dispositivos dos sistemas computacionais, tanto em desem-

penho como em capacidade de armazenamento, ocasionou um aumento considerável da

complexidade e utilidade dos aplicativos, que cresciam em tamanho e números de arqui-

vos. Assim, os usuários não estavam satisfeitos em ter apenas dois níveis de diretório para

armazenar seus dados e aplicativos.

Page 72: Implementação de um sistema de arquivos para uma plataforma de

50 CAPÍTULO 3. SISTEMA DE ARQUIVOS

Para satisfazer essa necessidade foi implementado o conceito de diretórios hierárquicos,

o qual possibilita a criação de diretórios em cadeia. Dessa forma, o usuário pode criar

novos diretórios dentro do seu diretório, e assim sucessivamente, de acordo com a sua

necessidade. A Figura 3.4 ilustra um exemplo dessa implementação.

Figura 3.4: Sistema de diretório hierárquico

Pela flexibilidade que esse tipo de estrutura fornece ao usuário para organizar seus

arquivos dentro do Sistema de Arquivos, os diretórios hierárquicos são implementados em

todos sistemas operacionais atuais.

Uma vez detalhado o conceito de arquivo, e a sua organização, a próxima seção visa

detalhar as operações comumente realizadas sobre os arquivos.

Page 73: Implementação de um sistema de arquivos para uma plataforma de

3.4. OPERAÇÕES 51

3.4 Operações

Dado que o objetivo fundamental dos Sistemas de Arquivos é o armazenamento de

informações para posterior recuperação e manipulação, faz-se necessário o provimento,

ao usuário, de um conjunto de operações que possam ser realizadas sobre os arquivos. A

seguir serão ilustradas as principais operações sobre arquivos existentes nos Sistemas de

Arquivos atuais. Vale lembrar que tal conjunto de operações não é único para todos os

Sistemas de Arquivos, podendo ocorrer diferenças de funcionalidade e de repertório entre

eles Tanenbaum (2001).

As principais operações sobre arquivos regulares são:

• CREATE: Cria um arquivo vazio, configurando seus atributos iniciais.

• DELETE: Remove um arquivo do sistema.

• OPEN: Abre um arquivo anteriormente criado. Esta abertura pode ser realizada

para leitura e/ou escrita.

• CLOSE: Fecha um arquivo previamente criado.

• READ: Executa a leitura de um arquivo previamente aberto.

• WRITE: Executa a escrita em um arquivo previamente aberto.

• APPEND: Executa a escrita no final de um arquivo previamente aberto.

• SEEK: Posiciona o ponteiro de leitura em uma dada posição.

• GET ATTRIBUTES: Obtêm os atributos de um arquivo.

• SET ATTRIBUTES: Configura os atributos de um arquivo.

Page 74: Implementação de um sistema de arquivos para uma plataforma de

52 CAPÍTULO 3. SISTEMA DE ARQUIVOS

• RENAME: Renomeia um arquivo previamente criado.

Similares às operações sobre arquivos, as principais operações sobre diretórios são:

• CREATEDIR: Cria um diretório vazio.

• DELETEDIR: Remove um diretório. Em muitas implementações é necessário que

o diretório a ser removido esteja vazio para que a operação seja realizada.

• OPENDIR: Abre um diretório para posterior visualização dos arquivos nele con-

tidos.

• CLOSEDIR: Fecha um diretório previamente aberto.

• READDIR: Lê o conteúdo de um diretório previamente aberto.

• RENAMEDIR: Renomeia um diretório previamente criado.

Após a análise das características inerentes aos arquivos, bem como das operações

sobre eles realizadas, torna-se interessante a análise da implementação propriamente dita

do Sistema de Arquivos. Tal análise dar-se-á na próxima seção.

3.5 Implementação do Sistema de Arquivos

Um dos aspectos mais importantes a ser considerado na implementação do Sistema

de Arquivos é a forma como os arquivos serão armazenados no dispositivo de armazena-

mento. Esse armazenamento pode se dar por diversas formas, sendo que a maioria delas

se assemelham por associarem blocos de disco a arquivos. Nas próximas seções, serãos

ilustradas as principais formas de armazenamento de arquivos.

Page 75: Implementação de um sistema de arquivos para uma plataforma de

3.5. IMPLEMENTAÇÃO DO SISTEMA DE ARQUIVOS 53

3.5.1 Alocação Contínua

Esta é a forma mais simples de alocação de arquivos. Cada arquivo é identificado como

se fosse um único bloco, do tamanho do arquivo. Os dados são inseridos nesse bloco de

forma seqüencial. Com isso a entrada do arquivo precisa apenas guardar o endereço inicial

e o tamanho do arquivo. A Figura 3.5 ilustra esta técnica para 5 arquivos de tamanhos

distintos.

Figura 3.5: Técnica de Alocação Contínua

Este método apresenta o melhor desempenho entre os outros métodos por possibilitar

a leitura de todo o arquivo em uma única operação. As desvantagens principais desse

método são: 1) a necessidade de se conhecer, antes da criação do arquivo, o tamanho do

mesmo (o que, geralmente, não é possível), para alocacação de espaço no disco, 2) o fato

da remoção de arquivos acarretar em um sério problema de fragmentação do disco.

Page 76: Implementação de um sistema de arquivos para uma plataforma de

54 CAPÍTULO 3. SISTEMA DE ARQUIVOS

3.5.2 Alocação com Lista Encadeada

Este método foi criado para possibilitar o aumento ou redução do tamanho de um ar-

quivo após a sua criação. Neste caso, o disco é dividido em blocos de tamanho igual, sendo

que a entrada do arquivo precisa guardar o endereço do primeiro bloco onde o arquivo

está inserido. A primeira palavra de cada bloco indica o endereço do bloco subseqüente

onde as informações estão armazenadas no arquivo, como ilustrado na Figura 3.6.

Figura 3.6: Técnica de Alocação com Lista Encadeada

Desta forma qualquer bloco do disco pode ser utilizado, sem ocorrência de fragmenta-

ção externa. Este método tem duas desvantagens. A primeira é que o acesso randômico é

lento, pois para acessar um bloco é necessário carregar, individualmente, todos os blocos

antecessores a ele. Outra desvantagem é que a informação contida no bloco não é uma

Page 77: Implementação de um sistema de arquivos para uma plataforma de

3.5. IMPLEMENTAÇÃO DO SISTEMA DE ARQUIVOS 55

potência de dois, porque a primeira palavra do bloco é utilizada como um ponteiro para

o próximo bloco.

3.5.3 Alocação com Lista Encadeada Usando Índice

Este é um método parecido com o anterior, eliminando as desvantagens da lista encade-

ada. Ele consiste em criar um índice (tabela) para guardar todos os blocos do disco. Cada

arquivo armazena apenas o primeiro bloco por ele utilizado. Desta forma, o Sistema de

Arquivos carrega essa tabela na memória com apenas um acesso a disco, podendo chegar

ao endereço de qualquer bloco de um arquivo apenas percorrendo essa tabela, facilitando

o acesso randômico. Outra vantagem é que o bloco pode ser utilizado, totalmente, para

armazenar informações. A Figura 3.7 ilustra um exemplo com lista encadeada usando

índice com dois arquivos, onde o primeiro arquivo, "‘robo.txt"’, é constituído pelos blocos

1, 3 e 6, e o segundo arquivo, "‘sdcard.jpg"’, é constituído pelos blocos 5, 0, 4, 8 e 7. Nesta

mesma figura, é observada a existência de 3 blocos livres para esse sistema hipotético.

Figura 3.7: Técnica de Alocação com Lista Encadeada Usando Índice

Page 78: Implementação de um sistema de arquivos para uma plataforma de

56 CAPÍTULO 3. SISTEMA DE ARQUIVOS

O sistema de arquivos FAT16, implementado neste trabalho, basea-se neste método

de alocação.

3.5.4 Nós-Índice

Neste método é associado a cada arquivo um nó-i (nó índice) que lista os atributos e

endereços em disco dos blocos do arquivo. Se o arquivo for pequeno, todos os endereços

dos blocos do arquivo estarão disponíveis no próprio nó-i. Se não couber todos os blocos

do arquivo em uma entrada do nó-i, o mesmo poderá apontar para outro nó que contém

mais endereços de blocos, e assim sucessivamente, até que todo o arquivo seja mapeado,

conforme ilustrado na Figura 3.8.

Figura 3.8: Técnica de Alocação com Nós-Índice

Page 79: Implementação de um sistema de arquivos para uma plataforma de

3.6. SISTEMA DE ARQUIVOS FAT 57

3.6 Sistema de Arquivos FAT

O sistema de arquivos FAT3 (Tabela de Alocação de Arquivos) foi criado em 1977 por

Bill Gates e Marc McDonald, sendo o sistema de arquivos suportado pela Microsoft Mi-

crosoft (2006) MS-DOS4 (Sistema Operacional de Disco). Esse sistema foi, inicialmente,

desenvolvido para ser um simples sistema de arquivos de discos flexíveis que, na época,

tinham capacidade inferior a 500 kilobytes (Microsoft, 2000).

Essa versão inicial de desenvolvimento, denominada FAT12, tinha este nome devido

ao tamanho de cada entrada na tabela de alocação, medida em número de bits. Devido ao

tamanho de cada entrada, 12 bits, esse sistema tinha a capacidade de endereçar apenas 212

(4096) entradas em sua tabela de alocação, sendo cada uma delas associada a no máximo

16 setores consecutivos no disco. O conjunto de setores consecutivos associado a cada

entrada da tabela de alocação é denominado cluster. Como geralmente o tamanho de

um setor é de 512 bytes, cada cluster poderia representar no máximo 8 kilobytes, e como

o sistema FAT12 pode endereçar até 4096 clusters, o tamanho máximo do disco estava

limitado a 32 megabytes, o que era suficiente para os sistemas da época que utilizavam o

MS-DOS. Atualmente, devido a suas limitações, o sistema FAT12 encontra-se obsoleto,

não sendo mais utilizado.

Com os avanços na capacidade de armazenamento, fez-se necessário o desenvolvimento

de um sistema de arquivos que superasse a limitação dos 32 megabytes da FAT12. Essa

solução veio com o desenvolvimento do sistema FAT16, que mantinha as mesmas caracte-

rísticas do sistema FAT12, diferenciando-se deste por reservar 16 bits para cada entrada

da tabela de alocação, com a capacidade de endereçar 216 (65536) clusters. A capacidade

de cada cluster na FAT16 também foi alterada, agora podendo associar até 64 setores, ou

3File Allocation Table4Disk Operating System

Page 80: Implementação de um sistema de arquivos para uma plataforma de

58 CAPÍTULO 3. SISTEMA DE ARQUIVOS

seja, considerando um setor de 512 bytes, essa capacidade seria de 32 kilobytes. Assim,

a FAT16 aumentou consideravelmente a capacidade máxima de endereçamento, quando

comparada à FAT12, podendo endereçar 2 (dois) gigabytes. Esse sistema de arquivos

ainda é muito utilizado em dispositivos com capacidade de até 2 gigabytes, como por

exemplo, a maioria das memórias de estado sólido utilizadas em cartões de memória de

máquinas fotográficas digitais.

Com o lançamento do sistema operacional Windows 95, realizou-se uma pequena al-

teração na identificação dos arquivos no sistema de arquivos FAT16. Esse novo sistema,

denominado VFAT5 tinha a capacidade de nomear os arquivos com até 255 caracteres em

contraste com os 8 caracteres dos sistemas anteriores.

Em uma versão mais recente, com os crescentes avanços nos dispositivos de massa,

necessitou-se desenvolver um sistema de arquivos para unidades superiores a 2 gigabytes.

Para tal propósito, foi criada uma nova versão de FAT, denominada FAT32. Embora este

sistema esteja associado ao número 32, atualmente usa-se apenas 28 bits para representar

cada entrada na tabela de alocação de arquivos. Diferente dos sistemas anteriores, esse

sistema não consegue endereçar 228 clusters por ser definido que o número máximo de

setores que uma unidade pode ter é representado por um número de 32 bits, o que limita

o sistema de arquivos FAT32 a 2 terabytes de capacidade máxima (Tanenbaum, 2001).

A Microsoft, detentora dos direitos autorais do sistema de arquivos FAT, em dezembro

de 2003 lançou a versão 2.1 da especificação do seu sistema de arquivos (Microsoft, 2000).

A diferença dessa especificação para as anteriores não estava relacionada a aspectos técni-

cos, e sim, aos termos de utilização, exigindo, tanto dos produtores de memória de estado

sólido removível quanto aos produtores de bens de consumo que utilizem o sistema de

arquivos FAT em seus dispositivos a pagarem uma taxa de 25 centavos de dólares ameri-

canos por unidade fabricada, ou 250 mil dólares americanos para uma produção ilimitada.

5Virtual FAT

Page 81: Implementação de um sistema de arquivos para uma plataforma de

3.6. SISTEMA DE ARQUIVOS FAT 59

Uma vez que o trabalho proposto nesta dissertação até a presente data restringiu-se ao

ambiente acadêmico, não tendo aplicação comercial, ele não é afetado por essa licença,

não sendo necessário o pagamento de royalties.

Na próxima seção serão abordados os aspectos técnicos relacionados a implementação

da FAT16, sistema de arquivos utilizado neste presente trabalho, seguindo a especificação

apresentada em (Microsoft, 2000).

3.6.1 Especificação da FAT16

As unidades de armazenamento de massa, após passarem por um processo de forma-

tação, têem um padrão entre si. Caso a unidade esteja particionada, ou seja, dividida em

vários volumes lógicos, a unidade seguirá um padrão, como ilustrado na Figura 3.9. Como

pode ser observado, o primeiro setor desta unidade é constituído do MBR6 (Setor de Boot

Primário), o qual é responsável por armazenar o primeiro código de carga disponível na

unidade, bem como informações de endereçamento das demais partições.

Após o bloco MBR, segue-se a área reservada para cada partição, tendo cada sistema

de arquivos uma forma lógica diferente de organizar os dados neste espaço. Como pode

ser observado, uma partição FAT16 é dividida em 4 regiões, sendo o primeiro setor da

partição constituído por uma área reservada chamada setor de boot, seguindo-se pela

região da FAT, ou seja, a tabela de alocação de arquivos, que por motivo de segurança,

geralmente tem seu conteúdo duplicado para possibilitar a restauração da tabela de uma

segunda cópia, caso a primeira venha a estar corrompida. A FAT é seguida pela região

reservada para o diretório raíz, a qual contém as informações dos arquivos e diretórios

armazenados nele. Logo em seguida, é localizada a região dos dados dos arquivos e sub-

diretórios, onde finalmente encontra-se o conteúdo dos arquivos.

Nas próximas seções serão detalhadas as 4 regiões encontradas em uma partição6Master Boot Record

Page 82: Implementação de um sistema de arquivos para uma plataforma de

60 CAPÍTULO 3. SISTEMA DE ARQUIVOS

Figura 3.9: Representação lógica de uma unidade de armazenamento particionada

FAT16.

3.6.1.1 Setor de Boot Secundário

O setor de boot é a estrutura de dados mais importante do sistema de arquivos, e é

localizado no primeiro setor de cada partição, ou no setor zero do dispositivo de arma-

zenamento caso este não esteja particionado. Do ponto de vista do sistema de arquivos

esse setor é muito importante, encontrando-se nele as informações básicas do dispositivo,

como o tamanho do setor, quantidade de cilindros e superfícies e o nome da partição. Na

Tabela 3.2 são apresentadas as informações contidas neste setor.

Page 83: Implementação de um sistema de arquivos para uma plataforma de

3.6. SISTEMA DE ARQUIVOS FAT 61

Nome Deslocamento Tamanho do Descriçãodo byte campo (bytes)

jmpBoot 0 3 Instrução de desvio para código de bootOEMName 3 8 Nome e versão OEM(Original Equipment Manufacturer)ButsPerSec 11 2 Bytes por setorSecPerClus 13 1 Setores por clusterRsvdSecCnt 14 2 Setores reservadosNumFATs 16 1 Números de tabelas FAT

RootEntCnt 17 2 Número de entradas no diretório raízTotSec16 19 2 Número de setores no volume (16 bits)Media 21 1 Byte de descrição da mídiaFATz16 22 2 Setores por tabela de alocação de arquivos

SecPerTrk 24 2 Número de setores por trilhaNumHeads 26 2 Número de cabeçasHiddSec 28 4 Número de setores ocultosTotSec32 32 4 Número de setores no volume (acima de 16 bits)DrvNum 36 1 Número da unidade físicaReserved1 37 1 ReservadoBootSig 38 1 Registro de assinatura de inicialização estendidaVolID 39 4 Número de série do volumeVolLab 43 11 Rótulo do volume

FilSysType 54 8 Sequência de caracteres

Tabela 3.2: Campos do Setor de Boot

3.6.1.2 Tabela de Alocação de Arquivos

A tabela de alocação de arquivos encontra-se após o setor de boot da partição. A área

de dados de um dispositivo de armazenamneto de massa no sistema de arquivos FAT16

é dividida em clusters (agrupamento de setores consecutivos). A partir do setor de boot,

é possível identificar o número de setores dos clusters. A tabela de alocação de arquivos

(FAT) do sistema FAT16, como anteriormente comentado na Seção 3.5.3, utiliza a técnica

de alocação com lista encadeada usando índice. Portando, cada índice encontrado na

tabela de alocação corresponde diretamente a um clustes localizado na área de dados.

Os dois primeiros campos da FAT são sempre reservados, sendo que os demais des-

crevem a utilização de seus agrupamentos correspondentes e são interpretados conforme

descrito na Tabela 3.3

Page 84: Implementação de um sistema de arquivos para uma plataforma de

62 CAPÍTULO 3. SISTEMA DE ARQUIVOS

Valor Descrição0000 cluster não utilizado, disponível

0xFFF0-0xFFF6 clusters reservados0xFFF7 cluster com defeito

0xFFF8-0xFFFF último cluster utilizado pelo arquivooutro valor próximo cluster utilizado pelo arquivo

Tabela 3.3: Descrição dos Índices da Tabela de Alocação

No diretório raíz, cada entrada de arquivo contém o número do primeiro cluster atri-

buído a ele na área de dados, que representa a sua entrada na FAT. A partir do conteúdo

desse índice na FAT é possível identificar os demais clusters pertencentes ao arquivo, re-

petindo o processo até encontrar uma entrada na FAT com o valor de final de arquivo

(0xFFF8 a 0xFFFF).

Geralmente, os sistemas de arquivos FAT16 tem mais de uma cópia da FAT em cada

partição, para garantir a integridade das informações. As alterações ocorrem simultanea-

mente em todas as cópias das FATs. Na ocorrência de algum erro em alguma das cópias,

o sistema poderá restaurar-se a partir de outra FAT não corrompida.

A seguinte rotina é necessária para calcular os clusters de um arquivo qualquer.

1. Utilize a entrada do diretório para encontrar o agrupamento inicial do arquivo a ser

examinado;

2. Multiplique o número do agrupamento por 27;

3. Utilize o produto como deslocamento na tabela de alocação de arquivos e guarde o

seu conteúdo;

4. Se o resultado for um valor final de arquivo, o mesmo não tem mais nenhum cluster

na partição. Caso contrário, o resultado é o número do próximo cluster.

7O passo 2 é necessário devido cada índice ocupar 16 bits, ou seja, 2 bytes

Page 85: Implementação de um sistema de arquivos para uma plataforma de

3.6. SISTEMA DE ARQUIVOS FAT 63

3.6.1.3 Diretório Raiz

O diretório raíz é localizado logo após os setores ocupados pela FAT. Cada arquivo ou

diretório presente no diretório raíz dessa partição possui uma entrada de 32 bytes contendo

o nome do arquivo, a extensão, a data de quando foi criado ou quando foi feita a última

modificação, o tamanho em bytes e o número do cluster onde o arquivo começa.

Na Tabela 3.4 é descrita a estrutura da entrada do diretório raíz para um sistema de

arquivos FAT16.

Deslocamento Tamanho em bytes Descrição0 8 Nome do Arquivo8 3 Extensão11 1 Atributos12 9 Reservado22 2 Horário de criação ou da última atualização24 2 Data de criação ou última atualização26 2 Cluster inicial28 4 Tamanho do arquivo em bytes

Tabela 3.4: Entrada de Diretório do Sistema FAT16

Na Tabela 3.5 são demonstrados os atributos existentes para os arquivos.

Deslocamento Atributo0 Apenas leitura1 Arquivo oculto2 Arquivo de sistema3 Identificação de volume4 Arquivo do tipo diretório5 Arquivo regular6 não utilizado7 não utilizado

Tabela 3.5: Atributos do Arquivo

Page 86: Implementação de um sistema de arquivos para uma plataforma de

64 CAPÍTULO 3. SISTEMA DE ARQUIVOS

3.6.1.4 Área de Dados

A área de dados é o último bloco da partição, localizando-se logo após as entradas

do diretório raíz. É nesta área que se localizam os clusters, representando o conteúdo de

cada arquivo.

3.7 Considerações Finais

Em um sistema computacional os dados são armazenados em forma de arquivos, fi-

cando sob responsabilidade do Sistema de Arquivos determinar como eles serão gravados

e posteriormente recuperados no dispositivo de armazenamento.

Neste capítulo foram ilustradas as principais características de um arquivo, bem como

as operações realizadas sobre eles. Foram ilustradas também algumas técnicas utilizadas

pelo Sistema de Arquivos na tarefa de armazenamento propriamente dita.

O Sistema de Arquivos FAT16 foi abordado com maiores detalhes por ter sido o

escolhido na execução deste trabalho.

Page 87: Implementação de um sistema de arquivos para uma plataforma de

Capítulo

4

Plataforma de Desenvolvimento

Neste capítulo será apresentada a plataforma utilizada no desenvolvimento deste tra-

balho. Inicialmente, é introduzido o conceito de computação reconfigurável, no qual se

enquadra este desenvolvimento, seguido dos aspectos básicos do processador Nios II da

empresa Altera. São apresentadas também as ferramentas de hardware e software utili-

zadas no desenvolvimento do sistema proposto.

4.1 Introdução

Os dispositivos eletrônicos estão cada vez mais presentes no cotidiano do ser humano,

aplicados para os mais variados fins. O desenvolvimento desses dispositivos pode seguir

65

Page 88: Implementação de um sistema de arquivos para uma plataforma de

66 CAPÍTULO 4. PLATAFORMA DE DESENVOLVIMENTO

3 (três) modelos distintos, a utilização da tecnologia ASIC1, o uso de processadores de

propósito geral e o desenvolvimento baseado em computação reconfigurável. Tais modelos

são descritos sucintamente na próxima seção.

4.1.1 Modelos de desenvolvimento

O modelo baseado em ASIC é indicado para aplicações estáticas com grande volume

de fabricação, permitindo o alcance de um bom desempenho na execução de suas tare-

fas devido ao seu desenvolvimento ser focado na resolução específica de um problema.

Contudo, com a mudança do ambiente, em alguns casos, faz-se necessária a mudança de

implementação desses circuitos, visando melhor execução de suas tarefas. Tal mudança

de implementação é impossível no modelo baseado em ASIC, sendo necessária então a fa-

bricação de um novo dispositivo com a implementação dos requisitos adicionais, onerando

o processo e tornando-o mais demorado.

Em contraste à idéia de implementação de tarefas diretamente em hardware, a tecno-

logia de processadores de propósito geral apresenta-se muito mais flexível e customizável.

Seu funcionamento baseia-se na busca, decodificação e execução de instruções, implicando

em um alto grau de generalização. Entretanto, essa característica torna o processo de exe-

cução de tarefas mais lento.

Com o intuito de trazer uma maior flexibilidade em relação à implementação de ta-

refas diretamente em hardware, e um melhor desempenho relacionado ao processador de

propósito geral, a computação reconfigurável, representada pela tecnologia denominada

FPGA2, apresenta-se como solução a esse problema.

As FPGAs consistem em um arranjo de elementos lógicos configuráveis contidos em um

único chip. Cada um desses elementos, chamados de blocos lógicos, contêm capacidade

1Application Specific Integrated Circuit2Field Programmable Gate Arrays

Page 89: Implementação de um sistema de arquivos para uma plataforma de

4.1. INTRODUÇÃO 67

computacional para implementar funções lógicas e/ou realizar roteamento, permitindo a

comunicação entre células. A comunicação entre os blocos é realizada por meio dos recur-

sos de interconexão. Desse modo, circuitos customizados podem ser mapeados na FPGA

computando-se as funções lógicas nos blocos lógicos e usando os recursos de interconexão

para agregar os blocos, formando o circuito necessário. A borda externa do arranjo con-

siste em blocos especiais capazes de realizar operações de entrada e saída. A Figura 4.1

ilustra um diagrama esquemático dos blocos internos da FPGA.

Figura 4.1: Diagrama esquemático dos blocos internos da FPGA

Page 90: Implementação de um sistema de arquivos para uma plataforma de

68 CAPÍTULO 4. PLATAFORMA DE DESENVOLVIMENTO

As FPGAs foram desenvolvidas tendo-se em mente que o uso futuro dos dispositivos

lógicos programáveis, chamados SoPC3, consistem em sistemas que integram toda a fun-

cionalidade necessária (processadores, periféricos, memória, entre outras coisas) em um

único chip (Bonato et al., 2004a,b). Para atingir esse objetivo, os dispositivos desenvolvi-

dos possuem grande capacidade e diversidade de elementos lógicos internos. Além disso,

conseguem acessar dispositivos externos com alta velocidade.

Um exemplo de processador implementado em uma plataforma de computação recon-

figurável é o Nios II (Altera, 2006b,c) da empresa Altera (Altera, 2006a). Este proces-

sador, que é utilizado na execução do Sistema de Arquivos implementado nesse trabalho

é descrito na próxima seção.

4.2 Processador Nios II

O processador Nios II faz parte da segunda geração de processadores lançados pela

empresa Altera. Tal processador tem melhor desempenho a um menor custo quando

comparado aos processadores da primeira geração, e é um dos processadores reconfigurá-

veis4 mais populares. Com esse processador pode-se atingir desempenho superior a 200

DMips5 (Saraty e Lima, 2002). Outra característica importante observada é a existência

de um grande número de IP Cores6 que podem ser integrados aos projetos desenvolvidos,

possibilitando atingir rapidamente as reais necessidade do usuário.

O supra-citado processador é distribuído em três versões, as quais se diferenciam pela

quantidade de elementos lógicos e pelo desempenho de cada unidade. As três versões

3System-on-a-Programable-Chip4Processadores reconfiguráveis são aqueles implementados em FPGA, com extrema flexibilidade de

customização para as aplicações do usuário.5Dhrystone Millions of Instruction per Second6Um núcleo de propriedade intelectual-(intellectual property core-IP Core) é um bloco da lógica ou

de dados que representa uma funcionalidade que pode ser utilizada no desenvolvimento de dispositivosaplicados em FPGAs ou ASICs.

Page 91: Implementação de um sistema de arquivos para uma plataforma de

4.2. PROCESSADOR NIOS II 69

compartilham o mesmo repertório de instruções e são totalmente compatíveis, ou seja,

o mesmo código binário pode ser executado em qualquer versão, sem necessidade de

adaptações ou recompilações.

Algumas das características compartilhadas pelas três versões são:

• arquitetura RISC (conjunto reduzido de instruções);

• conjunto de instruções de 32 bits;

• dado de 32 bits;

• 32 registradores de propósito geral;

• espaço de endereçamento de 2 gigabytes, e

• até 256 instruções customizáveis.

Cada versão do processador Nios II é constituída de um núcleo, um conjunto de

periféricos on-chip, memória on-chip e interface para a memória off-chip, todas imple-

mentadas em um único chip de FPGA. Na Figura 4.2 é ilustrado um diagrama de blocos

do processador.

As próximas seções são dedicadas ao detalhamento de cada versão do processador Nios

II disponível no mercado, culminando em um estudo comparativo entre elas.

4.2.1 Nios II/f

O Nios II/f (rápido7) foi desenvolvido para usuários com necessidade de alto desem-

penho de execução. O custo da adoção dessa versão é o número de elementos lógicos

utilizados em sua concepção, que é aproximadamente 35% maior que a versão padrão8.

As principais características desse processador são:7Fast8Standard

Page 92: Implementação de um sistema de arquivos para uma plataforma de

70 CAPÍTULO 4. PLATAFORMA DE DESENVOLVIMENTO

Figura 4.2: Processador Nios II em diagrama de blocos

• cache de dados e instruções configuráveis;

• pipeline de 6 estágios, e

• previsão dinâmica de desvios.

Devido à sua característica de alto desempenho, o processador Nios II/f foi o adotado

para o desenvolvimento deste trabalho.

4.2.2 Nios II/e

O Nios II/e (econômico9) foi desenvolvido visando o menor tamanho possível, ocu-

pando o mínimo de recursos da FPGA, mas mantendo a compatibilidade com as outras

versões quanto ao seu repertório de instruções.

Esse processador deve ser utilizado em projetos que não demandam um alto desem-

penho, economizando recursos. O número de elementos lógicos utilizados na concepção9Economy

Page 93: Implementação de um sistema de arquivos para uma plataforma de

4.2. PROCESSADOR NIOS II 71

desse processador é aproximadamente a metade da versão padrão (Nios II/s).

O custo da adoção dessa versão é o baixo desempenho, necessitando de aproxima-

damente 6 ciclos de relógio na média para executar uma instrução, demonstrando um

desempenho bem inferior às demais versões.

4.2.2.1 Nios II/s

O Nios II/s (padrão10) foi desenvolvido para ser um processador pequeno com um

alto desempenho. Essa versão tem um desempenho aproximadamente 400% maior que o

Nios II/e e ocupa aproximadamente 25% menos lógica que o Nios II/f, caracterizando-se

como uma versão intermediária.

As principais características do Nios II/s são:

• cache de instruções configuráveis;

• pipeline de 5 estágios, e

• previsão estática de desvios.

4.2.3 Comparação entre as Versões

Cada uma das 3 (três) versões disponíveis do processador apresenta particularidades,

as quais são demonstradas na Tabela 4.1.

Na Figura 4.3 é feita uma comparação entre as 3 (três) versões do processador Nios II

com o seu antecessor, o Nios. Essa comparação é realizada em termos de elementos lógicos

consumidos e desempenho alcançado. Na Figura 4.3 podem ser notadas as vantagens

de cada versão do processador Nios II. Em comparação com a primeira geração do

processador Nios, a versão econômica da segunda geração tem a vantagem de ocupar

10standard

Page 94: Implementação de um sistema de arquivos para uma plataforma de

72 CAPÍTULO 4. PLATAFORMA DE DESENVOLVIMENTO

Características Distribuição do ProcessadorNios II/e Nios II/s Nios II/f

Desempenho DMips/MHz 0,16 0,75 1,17DMips Máximo 28 120 200

Frequência Máxima 150 MHz 135 MHz 135 MHzTamanho aproximado 600 1.300 1.800Estágios de pipeline – 5 6Espaço de endereçamento externo 2 gigabytes 2 gigabytes 2 gigabytes

Instrução Cache – 512 bytes/64 kilobytes 512 bytes/64 kilobytesPrevisão de desvio – Estática Dinâmica

Dados Cache – – 512 bytes/64 kilobytesULA Multiplicador – 3 ciclos 1 ciclo

Divisão – – OpcionalDeslocamento 1 ciclo/bit 3 ciclos 1 ciclo

Suporte a instruções customizadas 256 256 256

Tabela 4.1: Resumo das principais características das versões do Nios II

50% menos elementos lógicos, já a versão rápida do Nios II tem um desempenho 4

(quatro) vezes superior que a versão rápida do Nios. Por fim, a segunda versão padrão

tem um desempenho 2 vezes superior à primeira, ocupando 10% menos elementos lógicos

que a versão econômica do Nios, demonstrando todo o potencial evolutivo adicionado à

segunda geração de processadores reconfiguráveis da empresa Altera.

Figura 4.3: Comparação entre as versões do processador Nios II com o Nios

Page 95: Implementação de um sistema de arquivos para uma plataforma de

4.2. PROCESSADOR NIOS II 73

Após a apresentação das versões do processador Nios II, na próxima seção são apre-

sentadas as famílias de FPGAs da empresa Altera que servem de suporte a tais processa-

dores, ou seja, FPGAs nas quais os processadores são implementados.

4.2.4 Famílias de FPGAs

A empresa Altera provê uma vasta família de FPGAs que dão suporte ao processador

Nios II. Essas famílias vão desde FPGAs mais simples, utilizadas em projetos pequenos,

que não necessitam de alto desempenho, até dispositivos altamente densos, a serem uti-

lizados em projetos complexos. Tais famílias são apresentadas com maiores detalhes nas

próximas seções.

4.2.4.1 Cyclone

A família Cyclone dá suporte ao processador Nios II com o menor custo por FPGA,

sendo utilizada principalmente por aplicações que demandam um baixo orçamento.

Com até 20.060 elementos lógicos e 288 kilobits de memória RAM, a família Cyclone

é uma alternativa para aplicações ASICs de densidade moderada, sendo uma solução

reconfigurável com custo similar às soluções tradidicionais.

Desde seu lançamento já foram vendidas milhões de unidades, sendo utilizadas no

mundo inteiro nas mais diversas áreas de atuação.

4.2.4.2 Cyclone II

Com até 68.416 elementos lógicos e 1.1 megabits de memória embutida,a família Cy-

clone II é a alternativa mais barata na análise custo/benefício.

Como a família Cyclone, a família Cyclone II foi densenvolvida para atender aplica-

ções de baixo custo. Por ter alta densidade, esta FPGA pode suportar sistemas digitais

complexos em uma única pastilha, diminuindo o custo de produção, o que a torna uma

Page 96: Implementação de um sistema de arquivos para uma plataforma de

74 CAPÍTULO 4. PLATAFORMA DE DESENVOLVIMENTO

alternativa atrativa a projetos complexos desenvolvidos em ASICs que não necessitem alto

desempenho.

4.2.4.3 Stratix

Desenvolvida para aplicações complexas de alto desempenho, a família de FPGAs Stratix

contém até 79.040 elementos lógicos e 7 megabits de memória embutida.

Essa família de FPGAs é dotada de até 22 bolocos de processamento digital de sinais e

alta capacidade de desempenho em portas de entrada/saída, sendo indicada para sistemas

que demandem alta largura de banda.

O presente trabalho irá utilzar kits de desenvolvimento que são compostos por FPGAs

da família Stratix.

4.2.4.4 Stratix GX

Essa é uma família especial de FPGAs derivada da família Stratix, desenvolvida es-

pecialmente para aplicações que necessitem de uma alta velocidade na transferência de

dados.

A família Stratix GX é dotada de até 20 canais de transceptores independentes capazes

de receber e enviar informações simultaneamente, com uma frequência de operação por

canal de até 3,125 Gbps.

4.2.4.5 Stratix II

Essa família tem o maior desempenho e maior densidade de totas as famílias de FPGAs

da Altera, sendo até 50% mais rápida, disponibilizando mais que o dobro de capacidade

lógica da primeira geração de FPGAs Stratix.

Essa família pode ter até 180.000 elementos lógicos e 9 megabits de memória RAM,

Page 97: Implementação de um sistema de arquivos para uma plataforma de

4.2. PROCESSADOR NIOS II 75

podendo ser utilizada por aplicações de altissimas complexidade e demanda de desempe-

nho.

Uma vez apresentado o conceito de computação reconfigurável, bem como os proces-

sadores reconfiguráveis e as FPGAs que os suportam, a próxima seção visa ilustrar os

benefícios alcançados com o uso desses processadores.

4.2.5 Benefícios

Uma das decisões mais importantes de um desenvolvedor de sistemas embutidos é a

escolha do processador que melhor se adapta às necessidades da aplicação. Mesmo com a

existência de centenas de alternativas de processadores, muitas vezes é impossível achar

um que atenda perfeitamente às exigências do projeto, forçando o desenvolvedor a adotar

um processador mais caro, com recursos sem utilidade ou escolher um processador que

não representa uma escolha ideal.

Com a utilização de um processador reconfigurável, a criação do sistema torna-se

uma tarefa fácil, sendo encapsulado em um chip programável, diminuindo o custo, facili-

tando novas modificações, aumentando o desempenho, obtendo um sistema que se adequa

perfeitamente às necessidades do projeto. Os principais benefícios dos processadores re-

configuráveis são descritos nas próximas seções.

4.2.5.1 Extensa Biblioteca de Componentes

Os processadores reconfiguráveis facilitam a adição de novos componentes, integrando-

os ao processador. A empresa Altera, por exemplo, disponibiliza mais de 60 componentes,

entre eles, interfaces de memória e entrada/saída, interface para placa de rede Ethernet,

periféricos como portas paralelas e seriais e co-processadores matemáticos, para serem

integrados ao processador. Tal característica aumenta bastante a gama de componentes

que podem ser utilizadas pelo projetista, o qual poderá adicionar ao processador apenas

Page 98: Implementação de um sistema de arquivos para uma plataforma de

76 CAPÍTULO 4. PLATAFORMA DE DESENVOLVIMENTO

os componentes necessários, obtendo um sistema que melhor atenda às necessidades do

projeto.

4.2.5.2 Desempenho do Sistema

A escolha do processador a ser utilizado em uma aplicação embutida está diretamente

associada ao desempenho do sistema. Algumas características inerentes aos processadores

reconfiguráveis, e que possibilitam o aumento do desempenho do sistema, são:

• Sistema multi-processado: o desenvolvedor do sistema pode optar por adicio-

nar vários processadores ao projeto, combinando-os de acordo com sua preferência,

aumentando sensivelmente o desempenho do sistema.

• Instruções customizadas: alguns processadores reconfiguráveis possibilitam ao

usuário criar um repertório de até 256 instruções personalizadas para suas neces-

sidades específicas. Este processo é viabilizado através da concepção de instruções

customizadas, que podem ser utilizadas através de simples chamadas de procedi-

mento. Como exemplo de incremento de desempenho, o cálculo de CRC de um

buffer de 64 kilobytes opera 27 vezes mais rápido com uma instrução customizada

do que quando processada pelo próprio processador.

• Acelerador de hardware: o acelerador de hardware pode ser utilzado em ope-

rações sobre grandes blocos de dados, funcionando como um co-processador cus-

tomizado. Utilizando o exemplo do cálculo de CRC de um buffer de 64 kilobytes,

utilizando o acelerador de hardware, a operação é executada 530 vezes mais rápido

quando comparada com a execução no próprio processador, comprovando ser um

recurso que pode aumentar drasticamente o desempenho do sistema.

Page 99: Implementação de um sistema de arquivos para uma plataforma de

4.3. FERRAMENTAS UTILIZADAS 77

4.2.5.3 Redução de Custos

Um fator importante a ser analisado no desenvolvimento de um sistema embutido é o

preço final do produto.

A utilização de processadores reconfiguráveis são uma alternativa interessante por

reduzirem o custo do sistema obtendo alto desempenho.

O custo do sistema diminui principalmente devido ao alto nível de integração que

pode ser obtido, possibilitando o encapsulamento em uma única pastilha de um sistema

complexo, constituindo de vários processadores, memória, periféricos e interfaces de en-

trada/saída, reduzindo drasticamente o custo de construção da placa do sistema, sua

complexidade e a potência consumida.

Outro diferencial importante dos processadores reconfiguráveis com relação ao custo

é o alto tempo de vida útil do produto, devido a possibilidade de atualização real do

hardware do sistema após a entrega ao cliente, não sendo necessária a aquisição de novos

componentes físicos, apenas necessitando a reprogramação da lógica da FPGA.

Uma vez determinados o processador e a família de FPGAs a ser utilizada neste trabalho,

na próxima seção serão ilustradas as demais ferramentas utilizadas no desenvolvimento

do mesmo.

4.3 Ferramentas Utilizadas

Nesta seção é apresentado o kit de desenvolvimento no qual será carregado o pro-

cessador customizado em conjunto com o sistema de arquivos para validação final do

projeto. Em seguida são ilustradas a ferramenta de auxílio à concepção do software do

sistema, a ferramenta de auxílio ao desenvolvimento do hardware do sistema, bem como

as ferramentas utilizadas no ambiente de teste proposto para este projeto.

Page 100: Implementação de um sistema de arquivos para uma plataforma de

78 CAPÍTULO 4. PLATAFORMA DE DESENVOLVIMENTO

4.3.1 Kit de Desenvolvimento

Foi utilizado o kit de desenvolvimento Nios II da empresa Altera, Edição Stratix,

o qual foi adquirido e encontra-se no Laboratório de Computação Reconfigurável (LCR,

2006) do Institudo de Ciências Matemáticas e Computação (ICMC, 2006) da Universidade

de São Paulo (USP, 2006). Ele possui as seguintes caracteristicas:

• 1 dispositivo StratixTM EP1S10F780C6 com 10570 elementos lógicos e 920 kilobits

de memória on-chip;

• 8 megabytes de memória flash;

• 1 megabyte de RAM estática;

• 16 megabytes de SDRAM;

• 2 portas serias RS-232 DB9;

• 4 botões de pressão conectados aos pinos de entrada/saída da Stratix ;

• 8 diodos emissores de luz11 conectados aos pinos de entrada/saída da Stratix ;

• 2 displays de 7 segmentos;

• 1 oscilador de 50 MHz;

• lógica a bordo para configuração do dispositivo Stratix da memória flash;

• interface Ethernet 10/100 Mbps MAC/PHY LAN91C111 com conector RJ-45, e

• conectores JTAC para dispositivos Altera via cabos de download.

Nas Figuras 4.4 e 4.5 são ilustrados o kit de desenvolvimento Nios II Edição Stratix

e o seu diagrama de blocos, respectivamente.11LEDs

Page 101: Implementação de um sistema de arquivos para uma plataforma de

4.3. FERRAMENTAS UTILIZADAS 79

Figura 4.4: Componentes e eletrônicos do ambiente de desenvolvimento

Figura 4.5: Diagrama de Blocos do Kit de Desenvolvimento

Page 102: Implementação de um sistema de arquivos para uma plataforma de

80 CAPÍTULO 4. PLATAFORMA DE DESENVOLVIMENTO

4.3.2 Ferramenta de Desenvolvimento de Software

A tarefa de desenvolver software (neste caso, um sistema operacional) para o proces-

sador Nios II será realizada pelo programa Nios II IDE, no qual é possível editar,

compilar e depurar os programas desenvolvidos.

O Nios II IDE é executado sobre a plataforma Eclipse12, que é uma plataforma

para construção de ambientes de desenvolvimento integrados que podem ser utili-

zados para criar as mais diversas aplicações, como websites, programas embedded

Java, programas C++ e Enterprise JavaBeans.

A plataforma Eclipse é construída sobre um mecanismo que integra e executa vários

módulos chamados plug-ins. Esses plug-ins são desenvolvidos separadamente por um

provedor de ferramentas, sendo adicionado ao programa Eclipse em um diretório

específico. Sempre que o ambiente Eclipse é executado é apresentado ao usuário um

ambiente compostos de todos os plug-ins avaliados no diretório específico, integrados

em uma única ferramenta

Para evitar ambigüidades, a plataforma Eclipse com o plug-in disponibilzado pela

Altera para o desenvolvimento do software do processador Nios II será chamado

de Nios II IDE.

A seguir são demonstradas algumas interfaces do Nios II IDE que representam as

principais funcionalidades do ambiente de desenvolvimento.

Na Figura 4.6 é apresentado o ambiente de desenvolvimento com um projeto imple-

mentado em linguagem C carregado sob a perspectiva de desenvolvimento C/C++.

Nessa interface são mostradas algumas informações sobre o conteúdo do projeto

aberto.12http://www.eclipse.org

Page 103: Implementação de um sistema de arquivos para uma plataforma de

4.3. FERRAMENTAS UTILIZADAS 81

Figura 4.6: Ambiente de Trabalho do Nios II IDE

Page 104: Implementação de um sistema de arquivos para uma plataforma de

82 CAPÍTULO 4. PLATAFORMA DE DESENVOLVIMENTO

Através de um único ambiente, o usuário desenvolve todas as etapas do projeto do

software. O ambiente disponibiliza um editor de textos para a escrita e visualiza-

ção do código fonte, um compilador para gerar o código executável do projeto e

uma ferramenta para executar o código gerado, tanto direto no kit de desenvolvi-

mento como também em um simulador do repertório de instruções do processador.

Também é disponibilizado uma ferramenta completa de depuração do código desen-

volvido, que pode ser depurado em ambiente de simulação ou diretamente no kit de

desenvovimento.

Outra funcionalidade disponibilizada pelo ambiente é um ferramenta de programa-

ção da memória Flash contida no kit de desenvolvimento, possibilitando a gravação

do código desenvolvido em memória não volátil.

4.3.3 Ferramenta de Desenvolvimento de Hardware

A tarefa de desenvolver sistemas complexos pelos métodos tradicionais torna-se

uma tarefa lenta e custosa. Por outro lado, o mercado atual exige novos produtos a

preços cada vez mais baixos. Tentando atender a esses dois objetivos conflitantes,

a empresa Altera desenvolveu a ferramenta SPOC Builder, integrada a ferramenta

Quartus II, utilizada no presente projeto.

A Ferramenta SPOC Builder proporciona o rápido desenvolvimento de sistemas com-

plexos, customizados para a necessidade do usuário, sendo uma poderosa plataforma

para a geração de sistemas de forma automática a partir de nível de blocos ou com-

ponentes.

Em conjunto com a ferramenta são disponibilzados mais de 60 componentes que

podem ser facilmente integrados ao projeto, como por exemplo, o processador re-

configurável Nios II, interfaces para o uso de dispositivos off-chip, interfaces e

Page 105: Implementação de um sistema de arquivos para uma plataforma de

4.3. FERRAMENTAS UTILIZADAS 83

memória, módulos de comunicação e periféricos. Além de componentes fornecidos,

o usuário pode obter componentes de outros fabricantes, ou construir seus próprios

componentes, integrando-os à ferramenta facilmente.

Na Figura 4.7 é ilustrada a interface da ferramenta. À esquerda da figura encontram-

se os componentes prontos para serem inseridos no sistema, e à direita encontram-se

os componentes existentes no sistema desenvolvido.

Figura 4.7: Interface SPOC Builder

Page 106: Implementação de um sistema de arquivos para uma plataforma de

84 CAPÍTULO 4. PLATAFORMA DE DESENVOLVIMENTO

4.3.4 Ambiente de Testes e Validação Reais do Sistema de Arquivos FAT16

Desenvolvido

Futuramente, o atual projeto será testado em uma plataforma robótica, servindo

como suporte à obtenção de imagens oriundas de câmeras digitais. O robô a ser

utilizado nos experimentos é o modelo Pioneer 3DX desenvolvido e fornecido pela

empresa ActivMedia Robotics (ActivMedia Robotics, 2006). Nesse robô é embarcado

o kit de desenvolvimento Nios com 4 câmeras CMOS, conforme pode ser visto na

figura 4.8. Esse sistema multi-câmeras é um projeto de doutoramento em desenvol-

vimento no Laboratório de Computação Reconfigurável (LCR, 2006) do Institudo de

Ciências Matemáticas e Computação (ICMC, 2006) da Universidade de São Paulo

(USP, 2006) apresentado em (Bonato, 2005a).

4.3.4.1 Sensor de Imagem

A câmera para a aquisição das imagens é composta pelo sensor de imagem ov7620

de tecnologia CMOS, vista na figura 4.9. A câmera pode fornecer imagens coloridas

com resolução de 320x240 pixels a 30 frames/segundo ou em tons de cinza com

resolução de 640x480 pixels a 60 frames/segundo. A definição do tipo de imagem e

diversos outros parâmetros são configurados através de uma interface I2C presente

na câmera. Essa câmera também possui uma lente com 6mm de comprimento focal

e 1,6mm de abertura , proporcionando abertura focal de 43 graus na horizontal e

33 graus na vertical.

Page 107: Implementação de um sistema de arquivos para uma plataforma de

4.3. FERRAMENTAS UTILIZADAS 85

Visão

Dianteira

Visão

Traseira

Visão

Lado Esquerdo

Visão

Lado Direito

Figura 4.8: Sistema Multi-Câmera embarcado na base do robô Pioneer 3DX

Page 108: Implementação de um sistema de arquivos para uma plataforma de

86 CAPÍTULO 4. PLATAFORMA DE DESENVOLVIMENTO

Figura 4.9: Câmera CMOS (modelo C3188A - 1/3")

4.3.4.2 Necessidade de Armazenar as Imagens

As câmeras acopladas ao ambiente de desenvolvimento captam imagens na resolu-

ção 320 x 240 pontos a 60 frames por segundo com 8 bits de resolução por ponto.

Estas imagens, após captadas, passam por um processo de análise. Esta análise

consiste em verificar o conteúdo da seqüência dos últimos frames adquiridos pelo

robô. Para tanto, faz-se necessário a disponibilização de um dispositivo de armaze-

namento. Uma vez que as imagens são captadas em alta freqüência, este dispositivo

deve ser de alta capacidade, recurso este indisponível no kit de desenvolvimento.

Assim, o atual trabalho tem por objetivo prover uma ferramenta de suporte a essa

limitação de espaço de armazenamento. Cada frame armazenado ocupa 76800 (320

x 240) bytes, permitindo que o cartão de maior capacidade utilizado nesse projeto

(de 1 Gigabyte) armazene acima de 10000 frames, equivalente a 40 segundos de

operação do sistema composto por 4 câmeras que adquire 60 frames por segundo

cada, quantidade suficiente para a análise.

Page 109: Implementação de um sistema de arquivos para uma plataforma de

4.4. CONSIDERAÇÕES FINAIS 87

4.4 Considerações Finais

Neste capítulo foi apresentada a plataforma de desenvolvimento utilizada na imple-

mentação do presente projeto. O processador Nios II e família de FPGAs Stratix

foram ilustradas com maiores detalhes por terem sido escolhidos para o desenvol-

vimento. Também foram apresentados as ferramentas para desenvolvimento de

software e de software e de hardware, bem como o ambiente de testes proposto,

envolvendo uma plataforma robótica em desenvolvimento no LCR.

Page 110: Implementação de um sistema de arquivos para uma plataforma de
Page 111: Implementação de um sistema de arquivos para uma plataforma de

Capítulo

5

Implementação e Resultados

Neste capítulo são descritas as principais etapas de implementação deste trabalho,

bem como os resultados obtidos, os quais são validados por meio dos experimentos

realizados.

5.1 Introdução

Como mencionado, os dispositivos de armazenamento de massa são de grande im-

portância nos equipamentos eletrônicos, principalmente nos dias atuais, uma vez

que esses equipamentos são dotados de diversos recursos, como sistemas de áudio e

vídeo, demandando espaços de armazenamento cada vez maiores.

89

Page 112: Implementação de um sistema de arquivos para uma plataforma de

90 CAPÍTULO 5. IMPLEMENTAÇÃO E RESULTADOS

Figura 5.1: Divisão do Sistema em Camadas

A implementação de um Sistema de Arquivos para um sistema computacional do-

tado de um dispositivo de armazenamento está dividida em 2 fases: o conhecimento

do funcionamento interno do dispositivo de armazenamento, para realizar as opera-

ções de leitura e escrita em baixo nível, e o conhecimento do sistema de arquivos a

ser implementado, para organizar de forma lógica os dados armazenados, facilitando

assim a recuperação dos mesmos, mantendo a compatibilidade com outros sistemas

que dão suporte ao mesmo Sistema de Arquivos.

Neste trabalho, a implementação foi dividida em camadas, de acordo com o ilus-

trado na Figura 5.1. As camadas mais inferiores, mais próximas do dispositivo

de armazenamento, dão suporte às camadas superiores, sendo necessariamente im-

plementadas primeiro. Assim, a complexidade do problema também foi dividida

em partes menores, podendo estabelecer parâmetros bem definidos da evolução da

implementação.

Neste capítulo são demonstrados em detalhes os cartões utilizados no desenvolvi-

mento do trabalho, bem como a interface de conexão física entre esses cartões e

a FPGA. Em seguida é ilustrada a camada de abstração de hardware, que traduz

comandos de alta abstração de escrita/leitura oriundas da biblioteca FAT para o

Page 113: Implementação de um sistema de arquivos para uma plataforma de

5.2. DISPOSITIVOS DE ARMAZENAMENTO UTILIZADOS 91

dispositivo de armazenamento. São demonstrados também os principais recursos

da biblioteca FAT implementada, e o gerador de arquivo gráfico de mapa de bits

BMP, o qual, em uma fase posterior, será utilizado para armazenar no dispositivo

de armazenamento as figuras adquiridas das câmeras CMOS a serem integradas a

esse sistema.

5.2 Dispositivos de Armazenamento Utilizados

No desenvolvimento deste trabalho foram utilizados 3 cartões distintos, os quais são

descritos na Tabela 5.2:

Interface Modelo Fabricante CapacidadeSD – Secure Digital TransFlash SanDisk 64 MegaBytesSD – Secure Digital Padrão SanDisk 1 GigaBytes

MMC – MultiMediaCard Padrão LG 256 MegaBytes

Tabela 5.1: Cartões utilizados no desenvolvimento do projeto

Nas Figuras 5.2, 5.3 e 5.4 são ilustrados os cartões utilizados.

(a) frente (b) trás

Figura 5.2: Cartão TransFlash da Sandisk de 64 Megabytes de capacidade com seu adap-tador para interface SD

Para validar os experimentos é necessário montar o Sistema de Arquivos imple-

mentado em outro sistema computacional, para verificar realmente como os dados

Page 114: Implementação de um sistema de arquivos para uma plataforma de

92 CAPÍTULO 5. IMPLEMENTAÇÃO E RESULTADOS

(a) frente (b) trás

Figura 5.3: Cartão SD da Sandisk de 1 Gigabytes de capacidade

(a) frente (b) trás

Figura 5.4: Cartão MMC da LG de 256 MegaBytes de capacidade

foram escritos. Para isso, foi utilizado um adaptador USB–SD/MMC, ilustrado na

Figura 5.5, que pode ser inserido em qualquer computador com uma porta USB dis-

ponível, permitindo uma comparação entre o conteúdo esperado dos arquivos com

o seu valor real.

A seguir será ilustrada a interface de conexão entre os cartões e a FPGA.

Figura 5.5: Adaptador USB–SD/MMC

Page 115: Implementação de um sistema de arquivos para uma plataforma de

5.3. ELABORAÇÃO DA INTERFACE DE CONEXÃO FÍSICA 93

5.3 Elaboração da Interface de Conexão Física

Como descrito no Capítulo 2, neste projeto foi utilizado o protocolo de comunicação

SPI para estabelecer uma comunicação entre o cartão e a FPGA. O protocolo SPI é

constituído de 4 pinos: CS 1(Seleção de Pastilha), Clock, MISO 2(Saída do Escravo

e Entrada do Mestre) e MOSI 3(Saída do Mestre e Entrada no Escravo).

Portanto, a primeira etapa no desenvolvimento deste trabalho foi a implementação

de uma interface SPI na FPGA. Essa interface é constituída de 3 portas de saída,

CS, Clock e MOSI e uma porta de entrada, MISO, sendo totalmente controladas por

software pelo processador Nios II, que é o mestre da comunicação. Para cada uma

dessas portas foi associado um pino externo a FPGA para ser acoplado ao conector

do cartão.

Após a implementação da interface SPI, foi necessário confeccionar a interface física

entre o conector do cartão e os pinos de entrada/saída da FPGA. Um problema

relacionado a essa fase foi a aquisição do conector, que não foi encontrado no co-

mércio local, necessitando importá-lo por uma grande empresa de eletrônica, que

não o mantinha em estoque, retardando as fases de implementação. De posse do

conector, a interface física foi confeccionada, e o diagrama desta conexão é ilustrado

na Figura 5.6.

Além dos 4 sinais da interface SPI, os cartões SD/MMC possuem 3 pinos de ali-

mentação, 2 de terra e um de fase, totalizando 7 pinos na interface. Um dos cabos

confeccionados no decorrer do projeto é demonstrado acoplado a placa de desenvol-

vimento na Figura 5.7.

1Chip Select2Master In Slave Out3Master Out Slave In

Page 116: Implementação de um sistema de arquivos para uma plataforma de

94 CAPÍTULO 5. IMPLEMENTAÇÃO E RESULTADOS

Figura 5.6: Diagrama de Conexão do cartão SD/MMC com um barramento SPI

Figura 5.7: Cabo Confeccionado Acoplado a Placa de Desenvolvimento

Page 117: Implementação de um sistema de arquivos para uma plataforma de

5.4. CAMADA DE ABSTRAÇÃO DE HARDWARE 95

5.3.1 Teste e Validação dos Conectores

Após a verificação das conexões o conector foi inserido nos pinos de entrada e saída

reservados na plataforma de desenvolvimento. Primeiramente, foi conferido através

de um multímetro os pinos de alimentação do cartão, constatando que o pino 4 do

conector estava ligado em 3,3 Volts e os pinos 3 e 6 do conector estavam ligados ao

terra. Após examinar os pinos de alimentação, foi concebida uma rotina para gerar

sinais nos pinos de saída (MOSI, Clock e CS) e uma rotina para ler o conteúdo do

pino de entrada (MISO), o que foi satisfatoriamente examinado, validando a inter-

face física de conexão entre o cartão de memória e a plataforma de desenvolvimento.

A seguir, os aspectos relacionados a implementação das funções básicas de acesso

ao cartão são descritos.

5.4 Camada de Abstração de Hardware

Após a conclusão da interface de conexão foram implementadas as funções de acesso

ao cartão. Essas são as funções de mais baixo nível, comunicando-se diretamente

com o dispositivo de armazenamento de massa através do protocolo de comunicação

SPI.

O conjunto de funções disponíveis por essa camada de abstração pode ser utilizado

por qualquer sistema que necessite acessar o cartão, provendo rotinas de baixo nível.

Assim, o usuário desta camada não precisará conhecer como ocorre o funcionamento

interno do cartão, acessando-o de forma transparente através das rotinas disponíveis.

Esta camada tem uma limitação de desempenho por realizar todo o controle do

dispositivo via software, o que torna a comunicação lenta.

Page 118: Implementação de um sistema de arquivos para uma plataforma de

96 CAPÍTULO 5. IMPLEMENTAÇÃO E RESULTADOS

As 3 principais funções disponibilizadas por essa camada são detalhadas a seguir.

5.4.1 Ligar_Cartao

Esta função é responsável por gerar toda a sequência de inicialização do cartão

SD/MMC. Ela deve ser requisitada sempre que um novo cartão for inserido no

conector, ou, quando for executada uma operação de reset no cartão ou no sistema.

Não é passado parâmetro para essa função e ela retorna 0 (zero), caso o cartão seja

inicializado satisfatoriamente, ou, um número negativo na ocorrência de algum erro.

5.4.2 Ler_Setor

Com esta função é possível ler um setor do cartão com 512 bytes de tamanho. É

passado como parâmetro o número do setor a ser lido e uma variável indicando o

local onde o setor lido deve ser armazenado. Esta função retorna 0 (zero), caso a

leitura seja efetuada com sucesso e um número negativo na ocorrência de falha.

5.4.3 Escrever_Setor

Esta função é utilizada para escrever um setor de 512 bytes no cartão. Ela recebe

como parâmetro o número do setor a ser escrito e uma variável indicando o local

onde encontra-se o conteúdo a ser escrito no cartão. Na ocorrência de alguma falha

na operação é retornado um número negativo. Caso contrário, a função retorna 0

(zero).

Page 119: Implementação de um sistema de arquivos para uma plataforma de

5.5. BIBLIOTECA FAT 97

5.4.4 Teste e Validação da Camada de Abstração de Hardware

Para validar as operações implementadas na camada de hardware, primeiramente

foi desenvolvida uma rotina que inicializa o cartão com a função Ligar_Cartão e em

seguida escreve em um setor uma sequência de bytes previamente determinada com

a função Escrever_Setor. Após a operação de escrita ser finalizada, realizou-se uma

operação de leitura sobre o mesmo bloco com a função Ler_Setor, onde foi verificado

que o conteúdo lido é idêntico a sequência de bytes que foi escrita, validando as três

operações básicas desta camada.

Após a comprovação da eficiência da camada de hardware em operações de um setor,

foi implementada uma rotina para verificar a integridade de todos os setores de cada

um dos cartões utilizados. Esta rotina consiste em, a cada iteração, escrever um

valor em todos os byte de cada setor presente no cartão, seguido de uma operação

de leitura, para verificar que todos os setores foram preenchidos satisfatoriamente.

Os valores selecionados para preencher em cada iteração cada byte do cartão foram

consecutivamente, 0 4, 15 5, 240 6 e 255 7, obtendo sucesso em todas operações,

garantindo que cada bit do cartão pode ser preenchido com 0 ou 1 e posteriormente

ser restaurado.

A seguir são ilustradas as funções responsáveis por estruturar os dados no dispositivo

de armazenamento de forma lógica, possibilitanto sua fácil restauração.

400 (hexadecimal) / 00000000 (binário50F (hexadecimal) / 00001111 (binário)6F0 (hexadecimal) / 11110000 (binário)7FF (hexadecimal), 11111111 (binário)

Page 120: Implementação de um sistema de arquivos para uma plataforma de

98 CAPÍTULO 5. IMPLEMENTAÇÃO E RESULTADOS

5.5 Biblioteca FAT

Com as funções de baixo nível disponibilizadas pela camada de abstração de hard-

ware, o acesso ao dispositivo de armazenamento ocorre de forma transparente. As-

sim, a camada da biblioteca FAT não precisa preocupar-se com os aspectos de baixo

nível de acesso ao cartão, bastanto para isso acessá-lo através das funções dispo-

nibilizadas pela camada de abstração de hardware. A camada da biblioteca FAT

é responsável por prover rotinas básicas de manipulação de arquivos, sendo suas

principais funções descritas nas próximas seções.

5.5.1 inicializar

Esta função é responsável por detectar o Sistema de Arquivos utilizado no dispositivo

de armazenamento. Não são passados parâmetros para essa função, e ela retorna 0

(zero) caso o sistema FAT16 seja identificado e inicializado corretamente e retorna

um número negativo na ocorrência de falha.

5.5.2 Abrir_Arquivo_Escrita

Antes de escrever em um arquivo é necessário abri-lo para escrita, funcionalidade

esta oferecida pela função Abrir_Arquivo_Escrita. Esta função recebe como pa-

râmetro o nome do arquivo a ser aberto para leitura, e seu valor de retorno é um

número negativo caso ocorra um erro e, um valor positivo, que representa o índice

do arquivo na tabela de arquivos abertos, caso a operação ocorra com sucesso.

Page 121: Implementação de um sistema de arquivos para uma plataforma de

5.5. BIBLIOTECA FAT 99

5.5.3 Escrever_Arquivo

Quando um arquivo já se encontra aberto para escrita, é necessário utilizar a função

Escrever_Arquivo para modificar o seu conteúdo. São passados três parâmetros

para essa função: o índice do arquivo a ser escrito na tabela de arquivos abertos,

uma variável com o conteúdo a ser escrito e uma variável indicando o número de

bytes a ser escrito. Esta função retorna o número de bytes escritos, ou, um número

negativo na ocorrência de erro.

5.5.4 Abrir_Arquivo_Leitura

Antes de ler um arquivo é necessário abri-lo para leitura. Esta operação é realizada

pela função Abrir_Arquivo_Leitura. É passado como parâmetro o nome do arquivo

a ser aberto para leitura, e a função retorna o índice do arquivo na tabela de arquivos

abertos em caso de sucesso na operação e, um valor negativo caso ocorra um erro.

5.5.5 Ler_Arquivo

Esta função é responsável por ler um arquivo previamente aberto para leitura. São

passados três parâmetros para esta função, o índice do arquivo a ser lido na tabela

de arquivos abertos, uma variável onde os dados lidos serão armazenados e uma

variável indicando o número de bytes a ser lido do arquivo. É retornado um valor

negativo caso ocorra erro na operação, ou, o número de bytes lidos caso contrário.

Page 122: Implementação de um sistema de arquivos para uma plataforma de

100 CAPÍTULO 5. IMPLEMENTAÇÃO E RESULTADOS

5.5.6 Fechar_Arquivo

Após a utilização do arquivo e, não sendo o mesmo mais necessário à aplicação que

o abriu, é preciso fechá-lo para desalocar seu índice da tabela de arquivos abertos

e atualizar seus atributos. Esta função recebe como parâmetro o índice do arquivo

a ser fechado retornando 0 (zero), caso o arquivo seja fechado com sucesso. Caso

contrário é retornado um valor negativo.

5.5.7 Teste e Validação do Sistema de Arquivos Proposto

Nesta seção são ilustrados os métodos utilizados para assegurar que o trabalho foi

desenvolvido segundo a especificação padrão FAT16, sendo portável para qualquer

sistema que a possui. A validação do trabalho implementado constitui de duas

etapas, que validam os processos de leitura e escrita no cartão.

A primeira etapa da validação (escrita no cartão) consiste nos seguintes passos:

1. Inserir o cartão SD/MMC no conector da plataforma de desenvolvimento;

2. Ligar a plataforma de desenvolvimento;

3. Executar a função Ligar_Cartao;

4. Abrir um determinado arquivo para escrita com a função Abrir_Arquivo_Escrita;

5. Escrever neste arquivo um determinado conteúdo com a função Escrever_Arquivo;

6. Fechar o arquivo aberto para escrita com a função Fechar_Arquivo

7. Retirar o cartão SD/MMC do conector da plataforma de desenvolvimento;

8. Desligar o sistema;

9. Inserir o cartão SD/MMC no adaptador USB–SD/MMC;

Page 123: Implementação de um sistema de arquivos para uma plataforma de

5.5. BIBLIOTECA FAT 101

10. Conectar o adaptador USB–SD/MMC em um computador tipo PC dotado de

uma porta USB;

11. Identificar a presença do arquivo aberto no passo 4 no sistema de arquivos do

cartão;

12. Abrir o arquivo identificado com um computador tipo PC, e

13. Comparar o conteúdo lido pelo computador com o escrito no passo 5.

Para a validação da operação de escrita do sistema, o resultado da comparação

executada no passo 13 deve indicar que o conteúdo escrito pela plataforma de de-

senvolvimento seja idêntico ao conteúdo lido pelo computador através do adaptador

USB–SD/MMC, o que foi verificado nos experimentos.

Uma vez que a primeira etapa esteja cumprida, resta validar a segunda etapa (leitura

do cartão), cujos passos são descritos a seguir:

1. Inserir o cartão SD/MMC no adaptador USB–SD/MMC;

2. Conectar o adaptador USB–SD/MMC em um computador tipo PC dotado de

uma porta USB;

3. Gravar neste cartão um arquivo com um conteúdo pré-determinado;

4. Retirar o adaptador USB–SD/MMC da porta USB do computador;

5. Inserir o cartão SD/MMC no conector da plataforma de desenvolvimento;

6. Ligar a plataforma de desenvolvimento;

7. Executar a função Ligar_Cartao;

8. Abrir o arquivo previamente escrito no passo 3 para leitura com a função

Abrir_Arquivo_Leitura;

Page 124: Implementação de um sistema de arquivos para uma plataforma de

102 CAPÍTULO 5. IMPLEMENTAÇÃO E RESULTADOS

9. Ler o conteúdo armazenado neste arquivo com a função Ler_Arquivo disponi-

bilizando seu conteúdo na saída padrão do NIOS II IDE;

10. Comparar o conteúdo escrito pelo computador no passo 3 com o conteúdo lido

pela plataforma de desenvolvimento no passo 9;

11. Fechar o arquivo aberto para leitura com a função Fechar_Arquivo

12. Retirar o cartão SD/MMC do conector da plataforma de desenvolvimento, e

13. Desligar o sistema.

Para a validação da operação de leitura do sistema, o resultado da comparação

executada no passo 10 deve indicar que o conteúdo lido pela plataforma de desen-

volvimento seja idêntico ao conteúdo escrito pelo computador através do adaptador

USB–SD/MMC, o que foi verificado nos experimentos.

5.6 Gerador de arquivo gráfico de Mapa de Bits BMP

Com o sistema de arquivos validado, a última etapa a ser implementada consiste

no desenvolvimento de um aplicativo que utilize as funções disponibilizadas pela

biblioteca FAT para armazenar algum dado por ele produzido. Este aplicativo

encontra-se na camada mais superior, provendo para o usuário um comando de alta

abstração, que utiliza de forma transparente os comandos disponibilizados pelas

camadas inferiores.A aplicação escolhida foi um gerador de arquivo gráfico que será

posteriormente utilizado no ambiente final de teste, onde as imagens serão fornecidas

pelo robô através das 4 câmeras. O gerador de arquivos gráficos irá armazenar as

imagens seguindo a especificação dos arquivos BMP (BitMap).

Atualmente, devido ao sistema de multi-câmeras não estar ainda integrado ao dispo-

sitivo de armazenamento, o conteúdo das figuras a serem armazenadas são criadas

Page 125: Implementação de um sistema de arquivos para uma plataforma de

5.6. GERADOR DE ARQUIVO GRÁFICO DE MAPA DE BITS BMP 103

em momento de compilação. O usuário deste aplicativo deverá fornecer dois pa-

râmetros ao sistema: a) uma variável contendo o mapa de bits que representa os

pontos (pixels) da figura a ser armazenada, figura esta de tamanho pré-determinado,

uma imagem de 240 linhas com 320 pontos por linha sendo de 8 bits de cor em tons

de cinza por ponto (exatamente como será disponibilizada pelas câmeras CMOS do

sistema real futuramente utilizado); b) um nome para o arquivo onde a imagem será

armazenada. Esta função retorna um valor 0 (zero) caso o arquivo seja gravado com

sucesso, e um número negativo na ocorrência de algum erro.

5.6.1 Teste e Validação do Gerador de Arquivos

Para validar a implementação do programa aplicativo gerador de arquivo, primei-

ramente criou-se em momento de compilação uma variável contendo a imagem a

ser armazenada. Em seguida, com o cartão de memória inserido na plataforma de

desenvolvimento, a aplicação foi executada, indicando sucesso na operação.

Para garantir que a imagem gerada na plataforma de desenvolvimento foi realmente

armazenada seguindo a especificação do arquivo BMP, o cartão foi inserido no adap-

tador USB–SD/MMC e este adaptador foi conectado a um computador com uma

porta USB. Com o adaptador conectado, verificou-se a presença do arquivo no dispo-

sitivo, seguido pela sua abertura em um programa gráfico compatível com arquivos

BMP, conferindo o imagem visualizada no microcomputador com o conteúdo escrito

na plataforma de desenvolvimento.

O sistema foi testado para diversas imagens, sendo algumas ilustradas na Figura 5.8,

demonstrando que o conteúdo escrito pela plataforma de desenvolvimento foi idên-

tico ao conteúdo lido no computador.

Page 126: Implementação de um sistema de arquivos para uma plataforma de

104 CAPÍTULO 5. IMPLEMENTAÇÃO E RESULTADOS

(a) escrito (b) lido

(c) escrito (d) lido

(e) escrito (f) lido

Page 127: Implementação de um sistema de arquivos para uma plataforma de

5.6. GERADOR DE ARQUIVO GRÁFICO DE MAPA DE BITS BMP 105

(g) escrito (h) lido

(i) escrito (j) lido

Figura 5.8: Imagens geradas na plataforma de desenvolvimento e visualizadas em umcomputador

5.6.2 Sistema Desenvolvido

Como descrito no Capítulo 4, para o desenvolvimento deste projeto foram utilizadas

as ferramentas disponibilizadas pela empresa Altera. Os itens de hardware imple-

mentados foram desenvolvidos na ferramenta SOPC Builder integrado ao Quartus,

adicionando 3 portas de saída e 1 porta de entrada ao processador NIOS II/f. Os

itens de software implementados foram desenvolvidos na ferramente NIOS II IDE

codificados na linguagem ANSI 8 C, totalizando aproximadamente 2000 linhas de

8American National Standards Institute

Page 128: Implementação de um sistema de arquivos para uma plataforma de

106 CAPÍTULO 5. IMPLEMENTAÇÃO E RESULTADOS

código.

5.7 Considerações Finais

Neste Capítulo foram ilustradas as principais etapas envolvidas na implementação

deste trabalho bem como os resultados obtidos. Foram descritos a interface física de

conexão entre a plataforma de desenvolvimento e o cartão, a camada de abstração

de hardware, a biblioteca FAT e aplicativo desenvolvido capaz de gerar imagens

BMP, bem como os testes realizados para validar cada camada desenvolvida.

Page 129: Implementação de um sistema de arquivos para uma plataforma de

Capítulo

6

Conclusões

Este projeto teve como objetivo implementar um sistema de arquivos em um dispo-

sitivo de armazenamento de alta capacidade, baixo consumo, de pequenas dimensões

e resistente a choque para ser utilizado em um sistema embarcado. Foi implemen-

tado um Sistema de Arquivos padrão FAT16 da Microsoft Corporation. O protocolo

utilizado para a comunicação entre o dispositivo de armazenamento e o processador

Nios II foi o SPI 1, o que possibilitou o uso de dois tipos de cartões, o SD (Secure

Digital) e o MMC (MultiMediaCard).

O sistema implementado atendeu satisfatoriamente as necessidades de armazena-

mento em grande escala (grande capacidade) das imagens geradas pelas 4 câmeras

1Serial Peripheral Interface

107

Page 130: Implementação de um sistema de arquivos para uma plataforma de

108 CAPÍTULO 6. CONCLUSÕES

CMOS que serão conectadas ao robô PIONER 3DX do Laboratório de Computa-

ção Reconfigurável (LCR, 2006) do Institudo de Ciências Matemáticas e Compu-

tação (ICMC, 2006) da Universidade de São Paulo (USP, 2006). Com o maior

dispositivo implementado, de 1 Gigabyte, é possível armazenar acima de 10000 ima-

gens captadas pelo robô, equivalendo a um período superior a 40 segundos. Apesar

deste período ser pequeno (apenas 40 segundos), ele é suficiente para cumprir seu

objetivo que consiste na análise dessas imagens para a detecção de landmarks na-

turais, ou seja, pontos de referência presentes nessas imagens, que são tema de

doutoramento de Bonato (2005a).

Caso seja necessário analisar as imagens capturadas em modo off-line, ou seja, com

a plataforma de desenvolvimento desligada, o sistema implementado provê suporte a

essa necessidade. O dispositivo de armazenamento, pode facilmente ser transportado

para qualquer computador tipo PC com uma porta USB utilizando um adaptador

USB–SD/MMC. Assim, as imagens armazenadas no cartão de memória são portadas

para outro ambiente, diferente do ambiente que a gerou, mantendo a integridade do

seu conteúdo.

A tecnologia do dispositivo de armazenamento utilizada é considerada avançada,

sendo amplamente difundida no mercado de dispositivos de armazenamento móveis

e utilizada em diversos equipamentos eletrônicos tais como aparelhos de telefones

celulares, tocadores de som digital (MP3 players), tocadores de DVD, impressoras,

computadores de mão (Handheld, PDA 2) e câmeras fotográficas digitais.

As memórias de estado sólido, utilizadas neste projeto, encontram-se em plena evolu-

ção. A capacidade de armazenamento destes dispositivos vem aumentando de forma

a atender as crescentes necessidades inerentes a eletrônica. Os cartões SD/MMC

2Personal Digital Assistant – Assistente Pessoal Digital

Page 131: Implementação de um sistema de arquivos para uma plataforma de

6.1. TRABALHOS FUTUROS 109

estão nesta categoria com densidades cada vez maiores. Entretanto, os modelos

mais recentes mantêm a compatibilidade com o protocolo SPI, possibilitando a atu-

alização do dispositivo utilizado por outro mais evoluído de maior capacidade e

desempenho. Assim, as alterações no protocolo de comunicação e na implemen-

tação não são necessárias, garantindo uma grande escalabilidade ao sistema para

futuro uso em outros projetos baseados no processador NIOS II da Altera.

Os testes realizados comprovaram a eficácia do armazenamento de arquivos no dis-

positivo e também detectaram uma limitação na sua velocidade. Esta limitação é

conseqüência de dois motivos: a) da largura do barramento de dados que são en-

viados bit a bit, impedindo a transferência dos dados em paralelo; b) da função de

controle do cartão, que tem seus sinais de comunicação entre a FPGA e o cartão,

gerados via software e executado no processador NIOS II que opera na freqüência

de 50 Mhz.

6.1 Trabalhos Futuros

O desenvolvimento do projeto permite a expansão para uma gama de trabalhos

futuros, são eles:

– Adicionar velocidade no sistema, implementando o controle de acesso ao cartão

via hardware, através da implementação de um acesso direto a memória (DMA)

conectado ao processador NIOS II, possibilitando o aumento da velocidade de

escrita/leitura ao dispositivo de armazenamento;

– Estender o processo de leitura/escrita desenvolvido no cartão de memória

SD/MMC para as demais memórias de estado sólido existentes, como Me-

mory Stick, xD-Picture Card, Compact Flash e USB Flash Drive, garantindo

Page 132: Implementação de um sistema de arquivos para uma plataforma de

110 CAPÍTULO 6. CONCLUSÕES

uma cobertura das principais mídias removíveis atualmente existentes;

– Integrar o sistema de armazenamento FAT16 ao sistema de mapeamento e

localização simultâneos usando multi-câmeras, possibilitando a armazenagem

de imagens reais captadas pelas 4 câmeras CMOS do robô;

– Estender o programa aplicativo responsável pela geração de imagens BMP, im-

plementando o método de compactação, permitindo um melhor aproveitamento

da área disponível no cartão de memória; e

– Implementar mecanismos de tolerância a falha para a recuperação e detecção de

erros nas imagens armazenadas, adicionando maior confiabilidade ao sistema.

Page 133: Implementação de um sistema de arquivos para uma plataforma de

Referências Bibliográficas

ActivMedia Robotics Educational price list, 2006.

Disponível em http://www.activrobots.com/ (Acessado em 7/2006)

Altera Corporation home page. site: http://www.altera.com - visitado em

07/2006. 2006a.

Altera Nios ii processor reference handbook. site:

http://www.altera.com/literature/hb/nios2/n2cpunii5v1.pdf −

visitadoem07/2006. 2006b.

Altera Nios ii software developer’s handbook . site: Nios ii software developer’s handbook.

2006c.

Bonato, V. Um sistema de mapeamento e localização simultâneos usando multi-câmeras

para robôs móveis, qualificação de Doutorado, 2005a.

Bonato, V. Um sistma de mapeamento e localização simultâneos usando multi-câmeras

para robôs móveis. Tese de Doutoramento, ICMC - USP, São Carlos - SP, 2005b.

Bonato, V.; Sanches, A. K.; Fernandes, M.; Cardoso, J. M.; Simões, E. D. V.;

Marques, E. A real time gesture recognition system for mobile robots. International

Conference on Informatics in Control, Automation and Robotics (ICINCO-2004), p. 207—

214, 2004a.

111

Page 134: Implementação de um sistema de arquivos para uma plataforma de

112 REFERÊNCIAS BIBLIOGRÁFICAS

Bonato, V.; Wolf, D.; Sanches, A. K.; Simões, E. D. V.; Marques, E. Formas

de implementação de redes neurais baseada em computação reconfigurável. Brazilian

Symposium on Artificial Neural Networks (SBRB (ICINCO-2004), 2004b.

Compact Flash association home page. site: http://www.compactflash.org - visitado em

07/2006. 2006.

Datalight Incorporation, samsung electronics launches the

worlds first pcs with nand flash-based solid state disk. site:

http://www.samsung.com/presscenter/pressrelease/pressrelease.asp?seq=20060-

5230000257520 - visitado em 07/2006. 2005a.

Datalight Incorporation, the future of nand flash memory in the embedded market. site:

http://linuxdevices.com/articles/at6503806063.html - visitado em 07/2006. 2005b.

Denning, P. The working set model for program behavior. Communications of the

ACM, 1968.

Flynn, I. M.; McHoes, A. M. I/o design – data management in operating systems. 9

ed. Rochelle Park, NJ: Hayden Book Company, Inc., 1985.

Flynn, I. M.; McHoes, A. M. Introdução aos sistemas operacionais. 2 ed. São Paulo,

SP: Pioneira Thomson Learning, 2002.

FujiFilm Home page. site: http://www.fujifilm.com - visitado em 07/2006. 2006.

Gonçalves, R. A. Architect-r: Uma ferramenta para o desenvolvimento de robôs recon-

figuráveis. Dissertação de Mestrado, ICMC–USP, São Carlos, SP, 2002.

Hennessy, J. L.; Patterson, D. A. Computer architecture: A quantitativa approach.

3 ed. Morgan Kaufmann, 2003.

Page 135: Implementação de um sistema de arquivos para uma plataforma de

REFERÊNCIAS BIBLIOGRÁFICAS 113

HP Hewlett-packard. site: www.hp.com - visitado em 07/2006. 2006.

IBM Fifty years of storage innovation: Magnetic tape beyond. site:

http://www-03.ibm.com/ibm/history/exhibits/storage/storagef ifty.html −

visitadoem07/2006. 2006a.

IBM International business machine. site: www.ibm.com - visitado em 07/2006. 2006b.

ICMC Instituto de ciências matemáticas e de computação, 2006.

Disponível em http://www.icmc.usp.br/ (Acessado em 7/2006)

Inc., D. Nand vs. nor flash – tradeoffs and strategies. site:

http://www.linuxdevices.com/articles/at4422361427.html visitado em 07/2006. 2005.

JVC Site: http://www.jvc.com - visitado em 07/2006. 2006.

Kanguru Flash drive max 64gb. site: http://www.kanguru.com/flashdrive_max.html -

visitado em 07/2006. 2006a.

Kanguru Solutions. site: http://www.kanguru.org - visitado em 07/2006. 2006b.

Kingston Datatraveler elite and datatraveler elite privacy edition: Advanced security

and high performance white paper. 2006.

Kodak Home page. site: http://www.kodak.com - visitado em 07/2006. 2006.

Laplante, P. A. Real-time systems design and analysis: An engineer’s handbook. 2 ed.

Berkeley, CA, 1997.

LCR Laboratório de computação reconfigurável, 2006.

Disponível em http://www.icmc.usp.br/~lcr (Acessado em 7/2006)

Lexar Home page. site: http://www.lexar.com - visitado em 07/2006. 2006.

Page 136: Implementação de um sistema de arquivos para uma plataforma de

114 REFERÊNCIAS BIBLIOGRÁFICAS

Microsoft Fat: General overview of on-disk format. 2000.

Microsoft Home page. site: http://www.microsoft.com - visitado em 07/2006. 2006.

MMCA Multimediacard system specification version 4.1. MMCA Home Page, 2005.

Monteiro, M. A. Introdução à organização de computadores. 4 ed. LTC Editora,

2002.

MultimediaCard Association home page. site: http://www.mmca.com - visitado em

07/2006. 2006.

Museu da ciência e indústria de manchester, inglaterra, site: http://www.msim.org.uk -

visitado em 07/2006. 2006.

Newmérique, B. A. Hd dvd a technical introduction. DVD Forum, 2006.

de O. S. Aragão, A. C.; Marques, E. A tecnologia FPGA. Relatório Técnico 60,

ICMC–USP, São Carlos, SP, 1997.

Oldfield, J. V.; Dorf, R. C. Field–programmable gate arrays: Reconfigurable logic for

rapid prototyping and implementation of digital systems. New York, NY: John Wiley &

Sons, Inc., 1995.

Olympus Home page. site: http://www.olympus.com - visitado em 07/2006. 2006.

Panasonic Home page. site: http://www.panasonic.com - visitado em 07/2006. 2006.

xD Picture Card home page. site: http://www.xdpicture.com - visitado em 07/2006.

2006.

Resnick, R.; Halliday, D.; Walker, J. Fundamentos de física: Eletromagnetismo -

vol. 3. LTC, 2003.

Page 137: Implementação de um sistema de arquivos para uma plataforma de

REFERÊNCIAS BIBLIOGRÁFICAS 115

Romero, R. A. F. ARMOSH: Aprendizado em robôs móveis via software e hardware.

Relatório Técnico, ICMC–USP, São Carlos, SP, 2000.

Samsung 2006.

Disponível em http://www.samsung.com (Acessado em 7/2006)

Sandisk Sandisk introduces transflash - world’s smal-

lest removable flash storage module for mobile phones. site:

http://www.sandisk.com/oem/documentinfo.aspx?documentid=1493 - visitado em

07/2006. 2004.

Sandisk Home page. site: http://www.sandisk.com - visitado em 07/2006. 2006.

Saraty, A. N.; Lima, P. G. P. Análise de desempenho de cpu. Unama - Universidade

da Amazônia, Belém - Pará - Brasil, 2002.

Seagate Barracuda es: Highest-capacity drives for the enterprise, datasheet. 2006.

Secure Digital card association home page. site: http://www.sdcard.org - visitado em

07/2006. 2006.

Siemens Home page. site: http://www.siemens.com - visitado em 07/2006. 2006.

Sony Sony announces "memory stick"recordable ic memory card pro-

ducts: New format supports recording and playback of audio/video content

. site: http://www.sony.net/sonyinfo/news/pressarchive/199807/98 − 067 −

visitadoem07/2006. 1998.

Sony Blue ray disc association site: http://www.blueraydisc.com - visitado em 07/2006.

2006a.

Page 138: Implementação de um sistema de arquivos para uma plataforma de

116 REFERÊNCIAS BIBLIOGRÁFICAS

Sony Memory stick home page. site: http://www.memorystick.com - visitado em 07/2006.

2006b.

Sony Site: http://www.sony.com - visitado em 07/2006. 2006c.

SonyEricson Home page. site: http://www.sonyericson.com - visitado em 07/2006.

2006.

Stallings, W. Arquitetura e organização de computadores. 5 ed. São Paulo, SP:

Prentice–Hall, Inc., 2002.

Sun Data sheet: Storage streamline* sl8500. 2006.

SUN Microsystems. site: www.sun.com - visitado em 07/2006. 2006.

Tanenbaum, A. S. Structured computer organization. 4 ed. 1999.

Tanenbaum, A. S. Modern operating systems. 2 ed. Upper Saddle River, NJ: Prentice–

Hall, Inc., 2001.

Toshiba 0.85-inch hard disk drives. site: http://sdd.toshiba.com - visitado em 07/2006.

2006a.

Toshiba Corporation home page. site: http://www.toshiba.com - visitado em 07/2006.

2006b.

Ungerer, G. Using flash memory with uclinux. site:

http://linuxdevices.com/articles/at6850006074.html - visitado em 07/2006. 2002.

USB - universal serial bus association site: http://www.usb.org - visitado em 07/2006.

2006.

Page 139: Implementação de um sistema de arquivos para uma plataforma de

REFERÊNCIAS BIBLIOGRÁFICAS 117

USP Universidade de são paulo, 2006.

Disponível em http://www.usp.br/ (Acessado em 7/2006)

Wells, T. What next-gen dvd will survive the next three years? 2005.

Williams, M. Cebit: Samsung shows flash-disk-based laptop: Company continues to

develop more stable solid-state disks. IDG News Service, 2006.