SISTEMA DE INTERPRETAÇÃO DE ARQUIVOS FAT32 E DECODIFICAÇÃO DE MPEG UTILIZANDO ARQUITETURA ARM CORTEX - M4

James dos Santos Fraga
SISTEMA DE INTERPRETAÇÃO DE ARQUIVOS FAT32 E DECODIFICAÇÃO DE
MPEG UTILIZANDO ARQUITETURA ARM CORTEX-M4
Porto Alegre
2017

Trabalho de Conclusão apresentado para
obtenção do título de Tecnólogo em
Sistemas Embarcados na Faculdade de
Tecnologia SENAI Porto Alegre do Curso
Superior de Tecnologia em Sistemas
Embarcados.
Orientador: Professor Me. Alexandre
Gaspary Haupt
Porto Alegre
2017

CIP – CATALOGAÇÃO NA PUBLICAÇÃO
FACULDADE DE TECNOLOGIA SENAI PORTO ALEGRE
Diretor: Márcio Rogério Basotti
Coordenador: Alexandre Gaspary Haupt
Bibliotecária: Gilmara Freitas Gomes Peres
FRAGA, James dos Santos
Sistema de Interpretação de Arquivos FAT32 e
Decodificação de MPEG Utilizando Arquitetura ARM
CORTEX-M4 / James dos Santos Fraga; orientação [por]
Alexandre Gaspary Haupt. Porto Alegre: Faculdade de
Tecnologia SENAI Porto Alegre, 2017.
89 f.: il.
1. Sistemas Embarcados. 2. Decodificação
3. MPEG. 4. Vídeos. 5. FAT32. I. Alexandre Haupt.
II. Título.

Trabalho de Conclusão apresentado para obtenção do título de Tecnólogo em
Sistemas Embarcados na Faculdade de Tecnologia SENAI Porto Alegre do Curso
Superior de Tecnologia em Sistemas Embarcados.
30/06/2017
______________________________________
Prof. Me. Alexandre Gaspary Haupt (orientador)
__________________________________
Prof. Me. Taciano Ares Rodolfo (avaliador)
________________________________________
Prof. Me. Alexandre Gaspary Haupt (coordenador)

À minha mãe, por sempre acreditar e investir em mim.
Aos meus amigos e colegas, pelo incentivo e pelo
apoio constante.

Agradecimentos
Agradeço primeiramente a Deus por ter me dado saúde е força para superar as
dificuldades.
Aos meus pais, Margarete e Oldemar, pelo amor, incentivo e apoio incondicional. Às
minhas irmãs, Alessandra e Elisandra, por todo amor e carinho. Ao meu padrasto,
José Aguinaldo, por estar sempre presente.
Aos meus colegas Andrieli e Deivid, pela experiência que passamos juntos em
estudos para as provas e a realização de trabalhos acadêmicos. Essa caminhada não
seria a mesma sem vocês.
Aos meus amigos, Amanda, Aryanne, Daiana, Julia, Liziane, Priscila e Sumaia por
todo apoio e cumplicidade.
Ao meu orientador Alexandre Gaspary Haupt, por ter me dado suporte no
desenvolvimento deste trabalho.
Meu agradecimento especial para os meus animais de estimação, Fila e Dobby, que
acompanharam grande parte da minha trajetória de vida.
A todos que direta ou indiretamente fizeram parte da minha formação, o meu muito
obrigado.

“Talvez não tenha conseguido fazer o melhor, mas
lutei para que o melhor fosse feito. Não sou o que
deveria ser, mas Graças a Deus, não sou o que era
antes”.
(Martin Luther King)

RESUMO
A popularização e o avanço da tecnologia de mídias digitais tornaram-se algo notável
nas últimas décadas. Esse grande avanço torna necessário o desenvolvimento de
técnicas de compressão/descompressão de vídeos mais eficientes. No entanto,
padrões de compressão/descompressão de vídeos MPEG e técnicas para
interpretação de sistemas de arquivo FAT32, são pouco difundidos. Além disso, são
escassas as tecnologias, acessíveis para reproduzir mídias através de dispositivo de
memória (pendrive). Este projeto visa desenvolver um protótipo de equipamento de
reprodução de vídeos de baixo custo para atender as demandas do mercado
brasileiro. Um dos objetivos deste trabalho, além de ser um dispositivo de baixo custo,
será analisar o desempenho da arquitetura ARM na decodificação de vídeos MPEG.
São objetivos específicos: interpretar um sistema de arquivos FAT32 na arquitetura
ARM Cortex-M4, desenvolver programa para decodificação de vídeos MPEG e testar
o sistema na reprodução de vídeos MPEG. Este trabalho utilizou a metodologia
experimental visando elaborar rotinas para a decodificação de vídeos MPEG em
linguagem C no software System Workbench for STM32. O sistema desenvolvido para
fazer a interpretação de arquivos FAT32 de um dispositivo de mídia (pendrive) teve
resultados satisfatórios. Ao inserir um pendrive com 10 arquivos, todos os arquivos
foram exibidos no display LCD. Os resultados de decodificação no projeto foram
satisfatórios e todos os objetivos foram atingidos. Através dos resultados obtidos, foi
atribuída uma nota de 83,3% para a decodificação de vídeos MPEG na resolução
QQVGA (160x120). Como melhoria futura deste projeto, pode-se desenvolver um
decodificador de áudio com o objetivo de reproduzir som dos vídeos MPEG.
Palavras-chave: Vídeos. MPEG. Decodificação. FAT32. ARM.

ABSTRACT
The popularization and advance of digital media technology became remarkable in
recent decades. This breakthrough makes it necessary to develop more efficient video
compression/decompression techniques. However, MPEG
compression/decompression standards and techniques for interpreting FAT32 file
systems are scarce. In addition, there are few technologies, accessible to play media
through a memory device (pendrive). This project aims to develop a prototype of a low
cost video playback equipment to meet the demands of the Brazilian market. One of
the objectives of this work, besides being a low cost device, will be to analyze the ARM
architecture performance in decoding MPEG videos. Specific objectives are to interpret
a FAT32 file system in ARM Cortex-M4 architecture, develop a program for decoding
MPEG videos and test the system for MPEG video playback. This work uses the
experimental methodology to elaborate routines for the decoding of MPEG videos in C
language in the System Workbench for STM32 software. The system developed to
interpret FAT32 files from a media device (pendrive) had satisfactory results. When
inserting a pendrive with 10 files, all the files were displayed in LCD display. The
decoding results in the project were satisfactory and all objectives were achieved.
Through the results obtained, a score of 83.3% was attributed to the decoding of MPEG
videos in the QQVGA resolution (160x120). As a future improvement of this project,
an audio decoder can be developed to reproduce sound from MPEG videos.
Keywords: Videos. MPEG. Decoding. FAT32. ARM.

LISTA DE FIGURAS
Figura 1 – Diagrama de blocos........................................................................................... 16
Figura 2 – Uma hierarquia de tarefas de processamento de imagens. ....................... 17
Figura 3 – Representação de uma imagem digital bidimensional. ............................... 19
Figura 4 – Composição de uma imagem digital RGB..................................................... 20
Figura 5 – Exemplo da binarização de uma imagem...................................................... 21
Figura 6 – Exemplo de um ruído do tipo sal-e-pimenta.................................................. 22
Figura 7 – Exemplo de aplicação do filtro da mediana................................................... 22
Figura 8 – Clareamento de imagem. ................................................................................. 23
Figura 9 – Várias camadas de um sistema composto pelo módulo FatFs.................. 25
Figura 10 – Constituição do macrobloco MPEG.............................................................. 26
Figura 11 – Estrutura da camada de vídeo MPEG.......................................................... 27
Figura 12 – Traduzindo códigos......................................................................................... 28
Figura 13 – Linguagem C e suas derivações................................................................... 29
Figura 14 – Tela de inicialização da IDE........................................................................... 30
Figura 15 – IDE após a criação de um projeto com o código main.c aberto. ............. 30
Figura 16 – Placa STM32F429i Discovery na embalagem plástica............................. 31
Figura 17 – Lado superior da placa STM32F429i Discovery. ....................................... 32
Figura 18 – Lado inferior da placa STM32F429i Discovery........................................... 33
Figura 19 – Pinos do microcontrolador. ............................................................................ 35
Figura 20 – Diagrama de blocos do padrão CMSIS. ...................................................... 36
Figura 21 – Comparação da velocidade das versões de USB...................................... 37
Figura 22 – Tipos de conectores USB............................................................................... 38
Figura 23 – Função de inicialização do display LCD...................................................... 39
Figura 24 – Representação de 16 bits para RGB 565.................................................... 40
Figura 25 – Função de conversão para RGB 565........................................................... 40
Figura 26 – Exemplo de uma janela retangular............................................................... 42
Figura 27 – Etapas do desenvolvimento do projeto........................................................ 43
Figura 28 – Pendrive utilizado no projeto. ........................................................................ 45
Figura 29 – Cabo adaptador USB-OTG............................................................................ 45
Figura 30 – Pendrive conectado no kit de desenvolvimento. ........................................ 46
Figura 31 – Tela inicial do STM32CubeMX...................................................................... 47
Figura 32 – Projeto criado no STM32CubeMX. ............................................................... 48

Figura 33 – Configuração de clock pelo software STM32CubeMX.............................. 48
Figura 34 – Tela de configuração de periféricos e middlewares. ................................. 49
Figura 35 – Projeto gerado pelo STM32CubeMX. .......................................................... 50
Figura 36 – Projeto no System Workbench for STM32. ................................................. 51
Figura 37 – Compilação do Projeto. .................................................................................. 51
Figura 38 – Gravação de firmware no kit de desenvolvimento. .................................... 52
Figura 39 – Diagrama de blocos de hardware................................................................. 53
Figura 40 – Esquemático do conector mini USB............................................................. 54
Figura 41 – Esquemático da fonte de alimentação......................................................... 54
Figura 42 – Esquemático do microcontrolador de gravação. ........................................ 55
Figura 43 – Esquemático da alimentação do microcontrolador. ................................... 56
Figura 44 – Esquemático dos pinos do microcontrolador. ............................................. 56
Figura 45 – Esquemático das barras de pinos do kit de desenvolvimento. ................ 57
Figura 46 – Esquemático do display LCD......................................................................... 58
Figura 47 – Esquemático do driver de touchscreen........................................................ 58
Figura 48 – Esquemático da comunicação USB. ............................................................ 59
Figura 49 – Diagrama de blocos do desenvolvimento de firmware.............................. 60
Figura 50 – Diagrama de arquivos da biblioteca CMSIS. .............................................. 61
Figura 51 – Chamada das funções de inicialização........................................................ 62
Figura 52 – Diagrama em blocos da biblioteca USB Host............................................. 63
Figura 53 – Estrutura de arquivos da biblioteca USB..................................................... 64
Figura 54 – Máquina de estados da biblioteca USB Host.............................................. 65
Figura 55 – Diagrama de blocos do módulo MSC........................................................... 67
Figura 56 – Função para imprimir uma imagem no display LCD.................................. 70
Figura 57 – Teste da função de imprimir imagem no display........................................ 71
Figura 58 – Tela inicial do sistema de decodificação MPEG. ....................................... 71
Figura 59 – Arquitetura do middleware FatFs.................................................................. 72
Figura 60 – Implementação da função FATFS_LinkDriver............................................ 73
Figura 61 – Implementação da função FATFS_UnLinkDriver....................................... 73
Figura 62 – Exemplo de acesso a um arquivo do pendrive........................................... 74
Figura 63 – Função para mostrar os arquivos do pendrive no display. ....................... 75
Figura 64 – Arquivos de um pendrive exibidos no display............................................. 76
Figura 65 – Estruturas das imagens.................................................................................. 78
Figura 66 – Função para decodificar o vídeo MPEG...................................................... 78

Figura 67 – Função para encontrar arquivos MPEG no pendrive. ............................... 79
Figura 68 – Vídeo decodificado no display LCD.............................................................. 80
Figura 69 – Telas desenvolvidas para o projeto.............................................................. 81
Figura 70 – Vídeo sendo reproduzido no display LCD................................................... 82
Figura 71 – Análise da resolução do vídeo com o tempo. ............................................. 83
Figura 72 – Análise do desempenho na decodificação.................................................. 83

LISTA DE TABELAS
Tabela 1 – Relação do Cluster com o armazenamento. ................................................ 24
Tabela 2 – Funções do módulo FatFs............................................................................... 25
Tabela 3 – Códigos de início de vídeos MPEG. .............................................................. 27
Tabela 4 – Modos de operação do registrador GPIOx_MODER.................................. 33
Tabela 5 – Velocidades disponíveis para o registrador GPIOx_OSPEEDR............... 34
Tabela 6 – Modos de PullUp disponíveis para o registrador GPIOx_PUPDR............ 34
Tabela 7 – Registradores do display LCD........................................................................ 41
Tabela 8 – Arquivos da biblioteca CMSIS. ....................................................................... 61
Tabela 9 – Principais funções da biblioteca CMSIS. ...................................................... 62
Tabela 10 – Arquivos do USB Host Core. ........................................................................ 64
Tabela 11 – Descrição da máquina de estados USB Host............................................ 66
Tabela 12 – Arquivos da biblioteca MSC.......................................................................... 67
Tabela 13 – Funções para inicializar um sistema de arquivos na biblioteca MSC. ... 68
Tabela 14 – Funções de baixo nível do driver ILI9341................................................... 69
Tabela 15 – Principais funções utilizadas do driver ILI9341.......................................... 69
Tabela 16 – Funções da biblioteca MPEG. ...................................................................... 77

LISTA DE SIGLAS
ANSI – American National Standarts Institute
ARM – Advanced RISC Machine
BSP – Board Support Package
CMOS – Complementary Metal Oxide Semiconductor
CMSIS – Cortex Microcontroller Software Interface Standard
CPU – Central Processing Unit
DSP – Digital Signal Processor
FAT32 – Tabela de Alocação de Arquivos
HD – Disco Rígido
HDTV – High Definition TV
HVGA – Half-size VGA
VGA – Video Graphics Array
IDE – Ambiente de Desenvolvimento Integrado
I2C – Inter-Integrated Circuit
ISO – International Standard Organization
JPEG – Joint Photographic Expert Group
kB – Quilobyte
LED – Light Emitting Diode
MPEG – Grupo de Especialistas em Imagens com Movimento
MSC – Mass Storage Class
PDI – Processamento Digital de Imagens
PLL – Phase Locked Loop
QVGA – Quarter Video Graphics Array
QQVGA – Quarter - QVGA
RGB – Red, Green, Blue
RTOS – Sistema Operacional de Tempo Real
SPI – Serial Peripheral Interface
TCC – Trabalho de Conclusão de Curso
TFT – Thin Film Transistor
USB – Universal Serial Bus
VCR – Vídeo Cassete Record

SUMÁRIO
1 INTRODUÇÃO ................................................................................................................... 15
2 REFERENCIAL TEÓRICO............................................................................................... 17
2.1 Processamento de imagens ......................................................................................... 17
2.1.1 Fundamentos da imagem digital .............................................................................. 18
2.1.2 Binarização de uma imagem..................................................................................... 20
2.1.3 Filtragem de uma imagem......................................................................................... 21
2.2 Sistemas de arquivos FAT e decodificação MPEG.................................................. 23
2.2.1 FAT32 ........................................................................................................................... 24
2.2.2 Padrão MPEG.............................................................................................................. 26
2.3 Linguagens de programação........................................................................................ 28
2.3.1 Linguagem C................................................................................................................ 28
2.3.2 Ferramentas de desenvolvimento ............................................................................ 29
2.4 Plataforma de desenvolvimento ARM......................................................................... 31
2.4.1 Placa de desenvolvimento STM32F429i Discovery.............................................. 31
2.4.2 Microcontrolador ARM Cortex-M4............................................................................ 33
2.4.3 CMSIS........................................................................................................................... 35
2.4.4 USB ............................................................................................................................... 37
2.4.5 Display LCD ................................................................................................................. 38
3 PROCEDIMENTO METODOLÓGICO ........................................................................... 43
3.1 Especificações do sistema............................................................................................ 43
3.2 Ferramentas utilizadas .................................................................................................. 44
3.2.1 Pendrive........................................................................................................................ 44
3.2.2 Cabo adaptador USB-OTG ....................................................................................... 45
3.2.3 STM32CubeMX ........................................................................................................... 46
3.2.4 System Workbench for STM32 ................................................................................. 50
3.3 Descrição de hardware.................................................................................................. 53
3.3.1 Gravador ST-Link........................................................................................................ 53
3.3.2 Microcontrolador STM32F429ZIT6 .......................................................................... 55
3.3.3 QVGA TFT LCD .......................................................................................................... 57
3.3.4 Comunicação USB...................................................................................................... 59
3.4 Descrição do firmware ................................................................................................... 60
3.4.1 Bibliotecas.................................................................................................................... 60

3.4.2 Driver USB Host .......................................................................................................... 63
3.4.3 Driver ILI9341 .............................................................................................................. 68
3.4.4 Sistema de arquivos FatFs........................................................................................ 72
3.4.5 Decodificação MPEG ................................................................................................. 76
4 APLICAÇÃO E RESULTADOS ....................................................................................... 81
5 COMENTÁRIOS FINAIS .................................................................................................. 85
REFERÊNCIAS ..................................................................................................................... 87

15
1 INTRODUÇÃO
A popularização e o avanço da tecnologia de mídias digitais tornaram-se algo
notável nas últimas décadas. À medida que a tecnologia evolui, torna-se necessário o
desenvolvimento de técnicas de compressão/descompressão de vídeos mais
eficientes. Nesta perspectiva surge a necessidade de estudar o padrão de
compressão/descompressão de vídeos MPEG em conjunto com a interpretação de
um sistema de arquivos FAT32, a fim de reproduzir mídias através de dispositivo de
memória (pendrive).
Este projeto visa a desenvolver um protótipo de equipamento de reprodução
de vídeos de baixo custo para atender as demandas do mercado brasileiro. Um dos
objetivos deste trabalho, além de ser um dispositivo de baixo custo, será analisar o
desempenho da arquitetura ARM na decodificação de vídeos MPEG. O projeto irá
explorar o padrão de compressão de vídeos MPEG, o gerenciamento e interpretação
de um sistema de arquivos FAT32 e a arquitetura ARM Cortex-M4.
Este projeto tem como objetivo geral desenvolver o protótipo de um sistema
de interpretação de arquivos utilizando o sistema de arquivos FAT32 e decodificar
vídeos MPEG utilizando a arquitetura ARM Cortex-M4. O protótipo do projeto terá um
display TFT de 2.4'', com uma resolução de 240x320 pixels, para mostrar o vídeo
decodificado. Este trabalho de conclusão de curso tem os seguintes objetivos
específicos:
 estudar o sistema de arquivos FAT32;
 analisar o padrão MPEG para decodificação de vídeos;
 adquirir um KIT de desenvolvimento com a arquitetura ARM Cortex-M4;
 desenvolver o software embarcado de interpretação de sistema de
arquivos FAT32;
 realizar leitura de arquivos de um pendrive por meio do software de
interpretação de sistema de arquivos;
 desenvolver funções no software para mostrar os arquivos do pendrive no
display LCD;
 decodificar os vídeos MPEG;
 mostrar os vídeos decodificados no Display LCD; e
 analisar os resultados e o desempenho do sistema.

16
Inicialmente será desenvolvido um software embarcado utilizando a
arquitetura ARM Cortex-M4 com o intuito de analisar o desempenho do
microcontrolador na interpretação de sistema de arquivos e execução de algoritmos
de decodificação de vídeos.
O software embarcado desenvolvido para o sistema de interpretação de
arquivos FAT32 e decodificação de vídeos MPEG será dividido em nove passos. Na
Figura 1, pode-se observar o diagrama de blocos do sistema embarcado.
Figura 1 – Diagrama de blocos.
Fonte: Autor, 2016.
Este trabalho foi estruturado e organizado em 6 capítulos. O primeiro capítulo
deste trabalho fala sobre a introdução, tema, objetivos geral e específicos, justificativa
e estrutura do trabalho. O segundo capítulo apresenta os conceitos fundamentais para
entendimento do trabalho, como as características de hardware e linguagens de
programação utilizadas.
O terceiro capítulo apresenta a metodologia do trabalho e os métodos que
foram utilizados para o mesmo ser desenvolvido. O quarto capítulo, por sua vez,
desenvolve uma análise dos resultados alcançados com os objetivos específicos
deste trabalho. O quinto capítulo apresenta as conclusões, limitações e sugestões
para projetos futuros. Por fim, o sexto e último capítulo apresenta todas as referências
bibliográficas que foram utilizadas para desenvolver este trabalho.

17
2 REFERENCIAL TEÓRICO
Este capítulo apresenta os conceitos fundamentais para o entendimento e
desenvolvimento do projeto.
2.1 Processamento de imagens
O processamento digital de imagens trata-se de um conjunto de técnicas e
operações matemáticas utilizadas para corrigir ou realçar detalhes de uma imagem
como, por exemplo, remover ruídos ou suavizar uma parte da imagem. Segundo
Gonzalez e Woods (2010, p.18), “o campo de processamento digital de imagens se
refere ao processamento de imagens digitais por um computador digital”.
O PDI não é uma tarefa simples, na realidade ele abrange um conjunto de
tarefas interconectadas, conforme ilustra a Figura 2.
Figura 2 – Uma hierarquia de tarefas de processamento de imagens.
Fonte: QUEIROZ; GOMES, 2017.

18
Todo o processo de PID se inicia com a captura de uma imagem realizada
através do processo de aquisição. Após a imagem ser digitalizada, ela precisará estar
de forma apropriada para todo o tratamento computacional. Uma imagem é
considerada apropriada quando ela for representada por duas ou mais dimensões. O
primeiro passo efetivo de processamento é comumente conhecido como pré-
processamento, o qual envolve passos como a filtragem de ruídos introduzidos pelos
sensores e a correção de distorções geométricas causadas pelo sensor (QUEIROZ;
GOMES, 2017).
2.1.1 Fundamentos da imagem digital
A imagem digital é caracterizada pela representação de duas ou mais
dimensões de uma imagem utilizando dígitos binários (0 e 1). De acordo com Solomon
e Toby (2013, p.1), “Uma imagem digital pode ser considerada como uma
representação discreta de dados que processam informação espacial e de intensidade
(cor) ”.
Uma imagem monocromática pode ser caracterizada como uma função
bidimensional, 𝑓( 𝑥, 𝑦), onde x e y representam os valores das coordenadas espaciais
e a amplitude de f representa a intensidade do nível de cinza da imagem nestas
coordenadas. Quando as coordenadas e os valores de intensidade são quantidades
finitas e discretas, chamamos de imagem digital (GONZALEZ; WOODS, 2010).
Observe que uma imagem digital é composta de um número finito de
elementos, cada um com localização e valor específicos. Esses elementos
são chamados de elementos pictóricos, elementos de imagem, pels e pixels.
Pixel é o termo mais utilizado para representar os elementos de uma imagem
digital (GONZALEZ; WOODS, 2010, p.18).
Na Figura 3, pode-se observar a notação matricial usual para a localização de
um pixel no conjunto de pixels de uma imagem digital. O índice m (linha) representa o
valor da posição da linha na qual está o pixel enquanto o índice n (coluna) representa
o valor da posição da coluna (QUEIROZ; GOMES, 2017).

19
Figura 3 – Representação de uma imagem digital bidimensional.
Fonte: QUEIROZ, GOMES, 2017.
Um pixel pode ser visto, em uma imagem digital colorida RGB, como um vetor
no qual os componentes representam um valor de azul, verde e vermelho. A imagem
colorida pode ser caracterizada como a união de três imagens monocromáticas
(QUEIROZ; GOMES, 2017).
A equação (1) representa uma imagem colorida RGB. O valor das amplitudes
fVERMELHO , f 𝑉𝐸𝑅𝐷𝐸 𝑒 f 𝐴𝑍𝑈𝐿 irão representar os níveis de intensidade de cada cor no ponto
de coordenada (x, y).
f(x,y) = fVERMELHO (x,y) + f 𝑉𝐸𝑅𝐷𝐸 (x,y) + fAZUL(x,y) (1)
Na Figura 4, são representados os planos bidimensionais de uma imagem
digital de três planos (RGB). Segundo Queiroz e Gomes (2017), “os mesmos conceitos
formulados para uma imagem monocromática aplicam-se a cada plano de uma
imagem colorida”.

20
Figura 4 – Composição de uma imagem digital RGB.
Fonte: WIKIWAND, 2017.
2.1.2 Binarização de uma imagem
A binarização é uma técnica de processamentos de imagens utilizada apenas
em imagens grayscale (tons de cinza). O objetivo desta técnica é transformar uma
imagem cinza em uma imagem nova preto e branco. Para utilizar esta técnica, será
necessário definir um limiar de binarização. Este limiar que irá controlar quais valores
de cinza serão convertidos para preto (0) e quais serão convertidos branco (255)
(HAUPT; DACHI; PIOVEZAN, 2013).
A equação (2) mostra o processo de binarização a partir de um limiar.
𝑔( 𝑥, 𝑦) = {
0, 𝑥 ≤ 𝑙𝑖𝑚𝑖𝑎𝑟
255, 𝑥 > 𝑙𝑖𝑚𝑖𝑎𝑟
(2)
Desta forma, pode-se entender que os valores dos pixels menores que o limiar
serão convertidos para preto e os valores maiores serão convertidos para branco.
Segundo Haupt, Dachi e Piovezan (2013, p.21), “o valor de limiar pode realçar ou
reduzir detalhes importantes em uma imagem. Este valor pode ser definido
empiricamente, ou através de algumas técnicas para estimar o valor ideal”.
Na Figura 5, pode-se observar um exemplo de binarização. No item a está a
imagem original. O item b representa a imagem binarizada com um limiar de 80. O
item c representa a imagem binarizada com limiar de 10. O item d representa a
imagem binarizada com o limiar de 30 (HAUPT; DACHI; PIOVEZAN, 2013).

21
Figura 5 – Exemplo da binarização de uma imagem.
Fonte: HAUPT, DACHI e PIOVEZAN, 2013.
2.1.3 Filtragem de uma imagem
O grande avanço da tecnologia nos dias atuais tornou possível melhorar a
qualidade de imagens através de técnicas de filtragem de imagens. O objetivo das
técnicas de filtragem é facilitar o processamento da imagem, a deixando mais
realística. Segundo Haupt, Dachi e Piovezan (2013, p.23), “os principais problemas
de degradação de imagens são os ruídos provocados por equipamentos, os borrões
que surgem quando um objeto está em movimento, perda de foco e até excesso ou
falta de iluminação”.
Os ruídos são pixels corrompidos que são causados por erro na transmissão
de dados. Eles têm o seu valor alterado para valores muito baixo ou muito alto,
causando assim uma grande diferença entre os pixels na sua volta. Os ruídos que
apresentam pontos pretos e brancos sobre a imagem são chamados de ruído sal-e-
pimenta (salt-and-pepper) (HAUPT; DACHI; PIOVEZAN, 2013).
Na Figura 6, pode-se observar uma imagem com pixels corrompidos
representando um ruído do tipo sal-e-pimenta.

22
Figura 6 – Exemplo de um ruído do tipo sal-e-pimenta.
As imagens digitais que possuírem ruído do tipo sal-e-pimenta podem ser
filtradas através do filtro da mediana. O filtro da mediana é uma das melhores técnicas
para remover ruídos do tipo sal-e-pimenta, este filtro identifica e elimina todos os pixels
corrompidos com valor preto (zero) ou branco (255) (HAUPT; DACHI; PIOVEZAN,
2013).
Na filtragem da mediana os valores dos pixels de vizinhança 8 são
considerados e organizados em forma de vetor. [101, 100, 102, 100, 0, 101,
99, 100, 99]. Logo após é organizado o vetor em ordem crescente. [0, 99, 99,
100, 100, 100, 101, 101, 102]. O valor dessa filtragem é o número central
localizado na quinta coluna, cujo valor é 100. Portanto o pixel com ruído será
substituído pelo pixel de valor mediano (HAUPT; DACHI; PIOVEZAN, 2013,
p.25.).
Na Figura 7, observa-se o exemplo de uma imagem ruidosa onde se aplica o
filtro da mediana.
Figura 7 – Exemplo de aplicação do filtro da mediana.

23
No PDI, deve-se levar em consideração que o objeto de interesse não fique
degradado, dificultando a extração de informações da imagem. Conforme Haupt,
Dachi e Piovezan (2013, p.24), “a iluminação é um dos fatores que mais prejudicam
uma imagem”.
Quando a imagem digital estiver bem escura, pode-se aumentar o valor de
cada pixel e assim, gerar uma imagem mais clara. Entretanto, se for necessário
escurecer a imagem, deve-se fazer o processo inverso. Ao invés de aumentar o valor
de cada pixel, diminui-se esse valor para escurecer (HAUPT; DACHI; PIOVEZAN,
2013).
A Figura 8 ilustra o clareamento de uma imagem. Na esquerda está a imagem
original e na direita está a imagem com clareamento.
Figura 8 – Clareamento de imagem.
Fonte: HAUPT; DACHI; PIOVEZAN, 2013.
2.2 Sistemas de arquivos FAT e decodificação MPEG
O FAT é um sistema de arquivos que organiza e gerencia os dados de cada
arquivo em dispositivos de memória como pendrive, HD e outras mídias. Ao passar
dos anos, o FAT foi se aperfeiçoando e ganhando sucessores como FAT12, FAT16 e
FAT32. O FAT12 não foi usado por muito tempo e o FAT16 foi padrão dos sistemas
operacionais da Microsoft por vários anos (POZZEBOM, 2017).
O MPEG foi formado no final dos anos 80 com o objetivo de criar padrões de
codificação e decodificação de áudio e vídeo (ALENCAR apud ARABURA, 2012).

24
2.2.1 FAT32
O FAT32 foi lançado no Windows 95 com o objetivo de remover as limitações
existentes no sistema de arquivos FAT16. As principais características que se
destacam neste sistema de arquivos é a possibilidade de criar várias partições de até
2TB (tera-bytes) e a diminuição do desperdício de memória em disco (TORRES,
2017).
Este desperdício de memória em disco, também conhecido como slack space,
são regiões de memória marcadas como utilizadas, porém fisicamente estão vazias.
Conforme Torres (2017, p. 1), “Isso ocorre porque o sistema FAT armazena arquivos
em unidades chamadas Clusters. Caso o arquivo não tenha um tamanho múltiplo do
cluster utilizado, o arquivo irá ocupar mais espaço do que o necessário. ”
Por exemplo, se o disco rígido estiver utilizando clusters de 32 KB, um arquivo
de 100 KB obrigatoriamente ocupará 128 KB (4 clusters de 32 KB), pois não
é possível alocar "metades" de cluster, somente o cluster inteiro. Nesse nosso
exemplo, 28 KB seriam desperdiçados (TORRES, 2017, p. 1).
O tamanho do cluster utilizado pela unidade lógica será decidido na hora da
formatação do dispositivo no sistema de arquivos. Na Tabela 1, pode-se observar uma
relação do tamanho do cluster e a capacidade de armazenamento (TORRES, 2017).
Tabela 1 – Relação do Cluster com o armazenamento.
Tamanho Do Cluster Capacidade Máxima de Armazenamento
512 bytes 512 bytes
4 kB 8 GB
8 kB 16 GB
16 kB 32 GB
32 kB 2 TB
Fonte: TORRES, 2017.
O módulo FatFs é um sistema de arquivos FATbastante utilizado em sistemas
embarcados com baixo processamento. Segundo Rodrigues (2012, p.27), “Este
módulo está totalmente escrito em linguagem C e apresenta uma estrutura
completamente separada da camada de software que faz a gestão do dispositivo de
memória”.

25
Como pode ser visto na Figura 9, este módulo é independente da arquitetura
de hardware utilizada, ele pode ser facilmente adaptado para vários tipos de
microcontroladores, como por exemplo: 8051, PIC, AVR, ARM (RODRIGUES, 2012).
Figura 9 – Várias camadas de um sistema composto pelo módulo FatFs.
Fonte: RODRIGUES, 2012, p.27.
O módulo FatFs fornece várias funções de controle de arquivos para serem
utilizadas na aplicação. A Tabela 2 mostra algumas dessas funções.
Tabela 2 – Funções do módulo FatFs
Função Descrição
f_open Abre ou cria um arquivo.
f_close Fecha um arquivo aberto.
f_read Lê dados de um arquivo.
f_write Escreve dados em um arquivo.
f_gets Lê uma string de um arquivo.
f_putc Escreve um caracter em um arquivo.
f_puts Escreve uma string em um arquivo.
f_printf Escreve uma string formatada em um arquivo.
f_size Retorna o tamanho de um arquivo.
f_stat
Verifica a existência de um arquivo ou um
subdiretório.
f_unlink Remove um arquivo ou um subdiretório.
f_rename Renomeia ou move um arquivo/subdiretório.
f_mkdir Cria um subdiretório.
f_mount
Registra/Apaga o espaço de um dispositivo de
mídia.
f_getlabel Retorna o nome do dispositivo de mídia.
f_setlabel Renomeia o dispositivo de mídia.
Fonte: Autor, 2017.

26
2.2.2 Padrão MPEG
O primeiro padrão MPEG-1 foi criado em 1991. Ele foi desenvolvido com o
objetivo de armazenar sinais digitais de áudio e vídeo colorido com qualidade VCR e
ser transmitido a uma velocidade de 1,5Mbps (LEGALL apud MARGI; BRESSAN;
RUGGIERO, 2004).
O padrão MPEG é dividido em três camadas. A primeira camada é a camada
de sistema que especifica como os sinais de áudio e vídeo são associados e
sincronizados. A segunda camada é chamada de camada de vídeo, é nela que estão
armazenados os sinais de vídeos. A terceira camada é chamada de camada de áudio,
ela que armazena os sinais de áudio (MARGI; BRESSAN; RUGGIERO, 2004).
No MPEG-1, a imagem é dividia em blocos de 16x16 amostras para
luminância e blocos de 8x8 amostras para cada sinal de crominância. Um macrobloco
é caracterizado por ser composto de um bloco de luminância (4 x (8 x 8) amostras) e
dois blocos de crominância (1x (8 x 8) + 1x (8 x 8) amostras), conforme observa-se na
Figura 10 (MARGI; BRESSAN; RUGGIERO, 2004).
Figura 10 – Constituição do macrobloco MPEG
Fonte: MARGI; BRESSAN; RUGGIERO, 2004.
A camada de vídeo MPEG é separada em seis subcamadas: Camada de
Sequência de Vídeo, Camada de Grupo de Imagens (GOP), Camada de Imagem,
Camada de slice, Camada de Macroblocos e Camada de Blocos. Na Figura 11, pode-
se observar todas as divisões da camada de vídeo MPEG (MARGI; BRESSAN;
RUGGIERO, 2004).

27
Figura 11 – Estrutura da camada de vídeo MPEG
As subcamadas da camada de vídeo são identificadas pelo cabeçalho, cujos
valores são observados na Tabela 3 (MICHEL apud MARGI; BRESSAN; RUGGIERO,
2004).
Tabela 3 – Códigos de início de vídeos MPEG.
Nome do Código de Início Valor em Hexadecimal
extension_start_code 000001B5
group_start_code 000001B8
picture_start_code 00000100
Reservado 000001B0
Reservado 000001B1
Reservado 000001B6
sequence_end_code 000001B7
sequence_error_code 000001B4
sequence_header_code 000001B3
slice_start_code 1 00000101
... ...
slice_start_code 175 000001AF
user_data_start_code 000001B2

28
2.3 Linguagens de programação
Uma linguagem de programação pode ser definida como um método
padronizado utilizado para expressar instruções de um programa a um computador
programável. Ela segue um conjunto de regras que dizem respeito à forma de escrita
e ao conteúdo (GOTARDO, 2015).
Segundo Gotardo (2015, p.17), “ao usarmos uma linguagem de programação
você cria o chamado “Código Fonte”. Um código fonte é um conjunto de palavras
escritas de acordo com as regras sintáticas e semânticas de uma linguagem”.
Compiladores são programas que “traduzem” o código fonte em “códigos
alvos” que são executáveis em um computador. Na Figura 12, pode-se observar um
programa elaborado em linguagem C pode ser traduzido em uma linguagem
compreensível pelo computador (GOTARDO, 2015).
Figura 12 – Traduzindo códigos.
Fonte: GOTARDO, 2015.
2.3.1 Linguagem C
A linguagem C surgiu em 1972 nos laboratórios AT&T Bell. Logo depois, foi
lançado o livro The C Programming Language que serviu como um tutorial para
programação em linguagem C. Em 1989 a linguagem foi padronizada pela ANSI
(PINHEIRO, 2016).
De acordo com Pinheiro (2016, p.22), “a linguagem C é uma das mais bem-
sucedidas linguagens de alto nível já criadas e é considerada uma das linguagens de
programação mais utilizadas de todos os tempos”. O autor afirma que uma linguagem
de alto nível é aquela que está relativamente próxima da linguagem humana, diferente
do código binário de máquina.

29
Esta linguagem de programação influenciou muitas outras linguagens
desenvolvidas posteriormente, como C++, Java, C# e PHP. Na Figura 13, pode-se
observar uma breve história de evolução da linguagem C e sua influência em outras
linguagens de programação (BACKES apud PINHEIRO, 2016).
Figura 13 – Linguagem C e suas derivações.
Fonte: BACKES apud PINHEIRO, 2016.
2.3.2 Ferramentas de desenvolvimento
As ferramentas de desenvolvimentos têm como objetivo facilitar o
desenvolvimento do código fonte e a organizar o projeto a ser desenvolvido. Um
exemplo de ferramenta de desenvolvimento é o Eclipse.
O Eclipse é uma comunidade de código aberto que os projetos são
concentrados em uma plataforma de desenvolvimento aperta composta de
ferramentas, estruturas, implementação e gerenciamento de software. Na Figura 14,
pode-se observar o Eclipse sendo aberto pela primeira vez, o usuário se depara com
uma página de boas-vindas dentro do ambiente de trabalho (ANISZCZYK;
GALLARDO, 2012).
O System Workbench, também chamado de SW4STM32, é uma IDE de
desenvolvimento gratuita compatível com Linux e Windows, totalmente baseada em
Eclipse com suporte a todos os microcontroladores STM32. Esse ambiente de
desenvolvimento recebe suporte oficial da STMicro, possui suporte a várias

30
ferramentas de geração de código automático e uma série de facilidades no
desenvolvimento de projetos (CURVELLO, 2015a).
Na Figura 14, pode-se observar a tela de inicialização desta IDE. Essa tela é
exibida toda vez que o programa for iniciado.
Figura 14 – Tela de inicialização da IDE.
Fonte: CURVELLO, 2015a.
Ao criar um novo projeto no ambiente de desenvolvimento System
Workbench, será criada uma estrutura-base do projeto, como pode ser visto na Figura
15. O programa irá criar arquivos padrões, como é o caso do main.c, localizado no
diretório src da raiz do projeto. Os demais diretórios correspondem a bibliotecas e
drivers de suporte (CURVELLO, 2015a).
Figura 15 – IDE após a criação de um projeto com o código main.c aberto.
Fonte: CURVELLO, 2015a.

31
2.4 Plataforma de desenvolvimento ARM
Uma plataforma de desenvolvimento é uma placa eletrônica desenvolvida
com vários periféricos com o objetivo de facilitar o desenvolvimento de um projeto.
A plataforma de desenvolvimento escolhida para este projeto possui um
microcontrolador ARM Cortex-M4 e ela será utilizada junto com um cabo USB-OTG e
um dispositivo de mídia (pendrive). A plataforma escolhida possui um display TFT de
2.4'', com uma resolução de 240x320 pixels.
2.4.1 Placa de desenvolvimento STM32F429i Discovery
O kit de desenvolvimento STM32F429i Discovery é bem completo, ele possui
vários recursos para testar todas as funcionalidades do microcontrolador
STM32F429ZI. O mesmo está disponível a venda no site da STMicroelectronics por
um preço de US$ 25,00 e o kit vem com uma embalagem plástica, contendo proteção
para o display LCD TFT além de folheto explicativo com detalhes do microcontrolador
(CURVELLO, 2015b).
Na Figura 16, pode-se observar o kit de desenvolvimento na embalagem.
Figura 16 – Placa STM32F429i Discovery na embalagem plástica.
Fonte: Autor, 2017.
O processador deste kit de desenvolvimento é bem poderoso, ele pode operar
à uma frequência de até 180MHz além de outros recursos a mais. Possui um gravador

32
ST-LINK/V2, com seleção de modo, permitindo gravar e depurar programas no
microcontrolador ou simplesmente executar a aplicação (CURVELLO, 2015b).
A alimentação da placa de desenvolvimento é feita através do barramento
USB ou por alimentação externa com fontes de 3V e 5V. O kit possui um display LCD
2.4’’ QVGA TFT com touchscreen resistivo, uma memória SDRAM de 64Mbits e um
giroscópio digital de 3 eixos (CURVELLO, 2015b).
Nesta plataforma de desenvolvimento, existem seis LEDS para indicação de
comunicação USB, USB OTG e para aplicação de usuário. Pode-se contar também
com um pushbutton de reset e um pushbutton para aplicação de usuário (CURVELLO,
2015b).
A parte superior da placa STM32F429i Discovery se caracteriza pela
localização do display LCD TFT de 2.4’’, o bloco de gravação e os botões azul e preto,
este para reset e aquele para uso do usuário. Na Figura 17, pode-se observar o lado
superior da placa, na parte esquerda está localizado o bloco de gravação ST-LINK
junto com um conector mini-USB para gravação e alimentação do kit de
desenvolvimento.
Figura 17 – Lado superior da placa STM32F429i Discovery.
Fonte: Autor, 2017.
A parte inferior da placa de desenvolvimento STM32F429i Discovery se
caracteriza pela presença do microcontrolador STM32F429ZIT6 no centro da placa e
a memória SRAM de 64Mbits localizada do lado direito da placa. Na Figura 18, nota-
se a grande quantidade de pinos disponíveis para interagir com o microcontrolador.
Nesta mesma imagem observa-se também o conector USB OTG padrão micro-AB no
lado direito da placa.

33
Figura 18 – Lado inferior da placa STM32F429i Discovery.
Fonte: Autor, 2017.
2.4.2 Microcontrolador ARM Cortex-M4
O microcontrolador utilizado no kit de desenvolvimento é o STM32F429ZIT6,
possui um núcleo de processamento Cortex-M4 da empresa ARM. Este
microcontrolador é um processador de sinais digitais embarcados de alta
performance, operando a uma frequência de 180MHz, com 2MB de memória Flash,
256kb de RAM, 32 bit e ponto flutuante. O encapsulamento do microcontrolador
utilizado neste kit é o LQFP144 (FACCIN, 2016).
Os processadores STM32-F429i possuem 8 portas GPIO de 16 bits,
designadas pelas letras A, B, C, D, E, F, G e H. Estas portas são controladas pelo
software através de registradores. Os registradores são iniciados pela nomenclatura
GPIOx_ onde substitui-se x pela letra que designa a porta (STEMMER, 2017).
O registrador GPIOx_MODER é responsável por registrar o modo de
operação do pino, ele possui dois bits para cada porta. A Tabela 4 ilustra os modos
de operações disponíveis para este registrador (STEMMER, 2017).
Tabela 4 – Modos de operação do registrador GPIOx_MODER.
Modo de operação Descrição
00 Modo de entrada (estado inicial no reset).
01 Porta digital de saída.
10 Função alternativa.
11 Entrada analógica.
Fonte: STEMMER, 2017.

34
O registrador GPIOx_OTYPER configura um tipo de saída para cada porta,
apenas os bits 0 a 15 são utilizados. Um bit valor 0 seleciona uma saída CMOS tipo
push-pull e o bit valor 1 seleciona dreno aberto. O registrador GPIOx_OSPEEDR
indica a velocidade de cada pino, este registrador possui dois bits para cada porta.
Nota-se que as velocidades mais altas possuem maior consumo de corrente. A Tabela
5 ilustra as velocidades disponíveis para cada pino (STEMMER, 2017).
Tabela 5 – Velocidades disponíveis para o registrador GPIOx_OSPEEDR.
00 Baixa velocidade (default).
01 Baixa velocidade.
10 Média velocidade.
11 Alta velocidade.
O registrador GPIOx_PUPDR indica o tipo de PullUp de cada pino. Este
registrador possui dois bits para cada porta. Na Tabela 6, pode-se observar os modos
de operações disponíveis para este registrador (STEMMER, 2017).
Tabela 6 – Modos de PullUp disponíveis para o registrador GPIOx_PUPDR.
00 Sem pull-up nem pull-down (estado inicial).
01 Pull-up.
10 Pull-down.
11 Reservado.
Os processadores STM32-F429i ainda possuem mais cinco
registradores para as portas GPIO. O GPIOx_IDR é um registrador utilizado para ler
os estados dos pinos de entrada, apenas os bits 0 a 15 são utilizados. O registrador
GPIOx_ODR é utilizado para escrever nos pinos de saída, são utilizados apenas os
bits de 0 a 15. O registrador GPIOx_BSRR utiliza os bits de 0 a 15 para ligar bits da
porta e os bits de 16 a 31 para desligar bits (STEMMER, 2017).
Os registradores GPIOx_AFRL e GPIOx_AFRH são dois registradores de 32
bits utilizados para selecionar funções alternativas dos pinos, usando 4 bits para cada

35
pino. Geralmente os pinos da família de processadores STM32-F429i podem ter até
16 funções (STEMMER, 2017).
Na Figura 19, pode-se observar a vasta quantidade de pinos do
microcontrolador escolhido para este projeto.
Figura 19 – Pinos do microcontrolador.
Fonte: FACCIN, 2016.
2.4.3 CMSIS
O Cortex Microcontroller Software Interface Standard é um padrão criado pela
ARM que define uma camada de abstração de acesso ao hardware para todos os
processadores da família Cortex-M (PRADO, 2012).
Na prática, o CMSIS é um conjunto de arquivos “.c” e “.h” que possibilitam a
criação de um BSP para os microcontroladores da linha ARM Cortex-M (PRADO,
2012). Segundo Prado (2012, p.1), “se você usar as funções definidas pelo padrão

36
CMSIS na sua aplicação, poderá migrar mais facilmente para outros chips da mesma
família”.
Ao utilizar o padrão CMSIS, a curva de aprendizado será menor, já que não
será necessário aprender como usar diferentes camadas de abstração e bibliotecas
fornecidas por fabricantes de chip, será necessário apenas aprender a interface
provida pelo padrão CMSIS (PRADO, 2012).
A Figura 20 ilustra o diagrama de blocos do padrão CMSIS. Neste diagrama
é possível observar que o padrão CMSIS é composto basicamente por quatro
componentes: CMSIS-DSP, CMSIS-RTOS, CMSIS-CORE e CMSIS-SVD.
Figura 20 – Diagrama de blocos do padrão CMSIS.
Fonte: PRADO, 2012.
O componente CMSIS-CORE é a interface principal com o core da CPU e com
os periféricos do CHIP. O CMSIS-DSP é a biblioteca com as funções principais de
ponto flutuante para a aplicação. Nos microcontroladores da linha M4, a
implementação é otimizada para usar o DSP do chip e a unidade de ponto flutuante,
caso seja um Cortex-M4F (PRADO, 2012).
Os outros componentes CMSIS-RTOS e CMSIS-SVD são, respectivamente,
a interface para o RTOS e o padrão de arquivos para descrever o sistema completo
(PRADO, 2012).

37
A camada de DST possui mais de 60 rotinas utilizadas para processamento
de sinal, incluindo operações em vetores, seno, cosseno, diversas funções de filtros,
operações de matrizes, etc. A camada de RTOS possui uma camada de abstração
para rotinas comuns em sistemas operacionais de tempo real, como o gerenciamento
de threads, semáforos e queues (PRADO, 2012).
2.4.4 USB
A tecnologia USB surgiu no ano de 1994 e desde então vem teve várias
versões. A primeira versão que se popularizou foi a USB 1.1 que é capaz de alcançar
taxas de transmissão de até 12Mb/s (megabits por segundo). Outra versão que
ganhou bastante destaque foi a USB 2.0 que consegue alcançar uma velocidade de
até 480 Mb/s (MARTINEZ, 2015).
Após o grande sucesso da tecnologia USB e com o avanço da tecnologia,
tornou-se necessário desenvolver outra versão do padrão USB, a versão 3.0. Essa
nova versão possui uma velocidade até 60 vezes mais rápida que a da geração
anterior, alcançando um limite de 4,8 Gb/s (MARTINEZ, 2015).
Na Figura 21, pode-se observar uma comparação da velocidade das versões
1.1, 2.0 e 3.0 do padrão de comunicação USB. Nesta imagem, nota-se a grande
diferença da versão 3.0 em relação a 2.0.
Figura 21 – Comparação da velocidade das versões de USB.
Fonte: Autor, 2017.

38
Quando dois dispositivos são conectados através de uma interface USB eles
assumem papeis distintos. Um deles será a unidade controladora, também chamada
como host, e outro será a unidade controlada, também conhecida como device. O
computador, por exemplo, possui várias portas USB do tipo host para conectar
acessórios do tipo device (câmera digital, mouse, pendrive, etc) (FACCIN, 2016).
Existem diversos tipos de conectores para a interface USB. Geralmente, as
interfaces do tipo host utilizam os conectores do tipo A. Na Figura 22, observar-se os
tipos de conectores da interface USB (FACCIN, 2016).
Figura 22 – Tipos de conectores USB.
Fonte: FACCIN, 2016.
2.4.5 Display LCD
O kit de desenvolvimento STM32F429i Discovery inclui um display de cristal
líquido do tipo TFT (Thin-Film Transistor) colorido de 2.4 polegadas com uma
resolução QVGA (320x240). Este display possui uma tela touch-screen e utiliza o
driver controlador ili9341.

39
A cor dos pixels deste display pode ser definida em formato RGB com 16 ou
18 bits. A comunicação com o microcontrolador pode ser feita através da comunicação
serial através do protocolo SPI ou pela comunicação paralela através de um
barramento de dados de 8, 16 ou 18 bits (STEMMER, 2017).
Na comunicação pelo protocolo SPI, o microcontrolador utiliza quatro sinais
de sincronismo: LCD_CS, LCD_SCK, LCD_DC e LCD_MOSI. A porta SPI envia de
forma serial síncrona um byte de cada vez, utilizando os sinais de clock e dados
LCD_SCK e LCD_MOSI. O dado de leitura MISO não é utilizado. O sinal LCD_CS
seleciona o LCD no barramento SPI ficando em nível baixo durante a transmissão de
um byte. O sinal LCD_DC indica se o byte transmitido é um comando (nível baixo) ou
um dado (nível alto) (STEMMER, 2017).
As configurações e definições das cores dos pixels é feita enviando comandos
para o display LCD. Cada comando é enviado com um byte de comando seguido de
um número variável de bytes de dados (STEMMER, 2017).
O display presente no kit de desenvolvimento STM32F429i Discovery precisa
de uma sequência de inicialização, feita através da função lcd_init. A Figura 23 mostra
a função de inicialização do display LCD. Nesta figura, observa-se que a função
configura as portas e a interface SPI para se comunicar com o display LCD
(STEMMER, 2017).
Figura 23 – Função de inicialização do display LCD.
Fonte: Autor, 2017.

40
Na configuração do display LCD, utiliza-se o formato de cor RGB 565 com
bytes trocados. Nesta configuração, a cor dos pixels é definida com 16 bits (5 bits para
vermelho, 6 bits para verde e 5 bits para azul). A ordem dos bytes na memória deste
display LCD é big-endian, enquanto o Cortex utiliza little-endian. Isso significa que
para obter a cor desejada, é necessário além de separar os bits, o número resultante
deve ter os bytes trocados. A Figura 24 representa os 16 bits para uma cor
(STEMMER, 2017).
Figura 24 – Representação de 16 bits para RGB 565.
Para utilizar o padrão RGB 565 deve-se utilizar uma função para mapear o
RGB de 24 bits para o formato de 16 bits com bytes trocados. A Figura 25 ilustra o
mapeamento de 24 bits para o padrão 565 (STEMMER, 2017).
Figura 25 – Função de conversão para RGB 565.
Fonte: Autor, 2017.
O display LCD possui uma série de comandos e registradores que podem ser
utilizados para configuração no desenvolvimento do sistema embarcado. A Tabela 7
mostra os registradores deste display com uma descrição de cada um.

41
Tabela 7 – Registradores do display LCD.
Código hexadecimal Descrição
0x01 Reinicialização por software.
0x04 Lê informação de identificação do display.
0x09 Lê o modo do display.
0x0A Lê o modo de alimentação do display.
0x0B Lê o registrador MADCTL do display.
0x0C Lê o formato de pixel do display.
0x0D Lê o formato de imagem do display.
0x0E Lê o modo de sinal do display.
0x0F Lê o resultado do autodiagnostico do display.
0x10 Entra em modo dormir.
0x11 Registrador do modo dormir.
0x12 Entra no modo parcial.
0x13 Entra no modo normal do display.
0x20 Desabilita inversão do display.
0x21 Habilita inversão do display
0x26 Registrador do gamma.
0x28 Comando para desligar o display.
0x28 Comando para ligar o display.
0x2A Registrador do endereço de coluna.
0x2B Registrador do endereço da página.
0x2C Registrador da GRAM.
0x2D Comando para habilitar a cor.
0x2E Comando para ler a memória.
0x30 Comando para ler área parcial.
0x33 Comando para definir rolagem vertical.
0x34 Habilita linha de efeito tremendo.
0x35 Desabilita linha de efeito tremendo.
0x36 Registrador de controle do acesso de memória.
0x37 Endereço inicial da rolagem vertical.
0x38 Desabilita modo ocioso.
0x39 Habilita modo ocioso.
0x3A Registrador do formato do pixel.
0x3C Comando para escrever na memória Continue.
0x3E Comando para ler a memória Continue.
Fonte: Autor, 2017.

42
Neste display, é possível definir a cor em uma janela retangular. Ele utiliza o
conceito de janela retangular de acesso para facilitar localização dos pixels para
definir as cores. Para isso é necessário utilizar os comandos 0x2A, 0x2B e 0x2C para
definir as coordenadas dos cantos da janela e definir a cor dos pixels (STEMMER,
2017).
O comando 0x2A define as colunas X1 e X2 da janela em quatro bytes, cada
um contendo dois bytes de endereço dos pixels. O comando 0x2B define as linhas Y1
e Y2 da janela em quatro bytes, cada um contendo dois bytes de endereço dos pixels.
O comando 0x2C por sua vez, define a cor dos pixels da área da janela. Para cada
pixel é enviado uma cor em 16 bits de dado seguindo o padrão RGB 565 (STEMMER,
2017).
A Figura 26 exemplifica o conceito de uma janela retangular criada no display
na cor amarelo.
Figura 26 – Exemplo de uma janela retangular.

43
3 PROCEDIMENTO METODOLÓGICO
Este trabalho utiliza como procedimento metodológico a pesquisa
experimental. O método experimental consiste em submeter os objetos de estudo à
influência de certas variáveis, em várias condições conhecidas e controladas pelo
investigador, com o objetivo de observar os resultados que a variável produz no objeto
(GIL, 2008).
Este capítulo contém as especificações, descrição do hardware, ferramentas
utilizadas para o desenvolvimento do projeto e as etapas do processo para o
desenvolvimento deste trabalho.
3.1 Especificações do sistema
Este projeto visa desenvolver um protótipo de um equipamento de reprodução
de vídeos MPEG com o objetivo de analisar o desempenho da arquitetura ARM na
decodificação dos mesmos. O projeto propõe como solução o uso de bibliotecas,
drivers e middlewares no kit de desenvolvimento STM32F429i Discovery.
A Figura 27 ilustra as etapas do desenvolvimento do projeto.
Figura 27 – Etapas do desenvolvimento do projeto.
Fonte: Autor, 2017.

44
O projeto é um sistema de reconhecimento de sistemas de arquivos FAT32
através de um pendrive e reconhecer os arquivos MPEG e mostrar os frames no
display LCD. Inicialmente foi feito um estudo analisando os sistemas de arquivos
FAT32 e o padrão de codificação MPEG.
Após os estudos dos padrões a serem utilizados, foi adquirido uma plataforma
de desenvolvimento. Esta plataforma é o Kit STM32F429i Discovery, ele possui os
itens necessários para solucionar o problema deste projeto.
O projeto possui uma porta USB para inserir um pendrive com um cabo
adaptador e um display TFT de 2.4'', com uma resolução de 240x320 pixels para
mostrar o vídeo decodificado. O sistema irá reconhecer os arquivos .mpeg dentro do
pendrive e irá decodificar os mesmos para serem reproduzidos no display.
3.2 Ferramentas utilizadas
Na implementação deste projeto foi necessário utilizar alguns recursos e
ferramentas de desenvolvimento. Entre as ferramentas utilizadas, destaca-se o uso
de um cabo adaptador USB-OTG e um pendrive contendo vídeos MPEG para serem
decodificados pelo sistema.
O System Workbench é um ambiente de desenvolvimento feito para auxiliar
na organização de projetos de software. O STM32CubeMX é uma ferramenta utilizada
para gerar códigos iniciais de um projeto, como por exemplo a inicialização do clock
do sistema e acionamento de pinos.
3.2.1 Pendrive
Um pendrive é um dispositivo de mídia removível utilizado para
armazenamento de dados. No desenvolvimento deste projeto, foi necessário utilizar
um pendrive para armazenar vídeos no formato .mpeg.
Os vídeos armazenados no pendrive foram utilizados para testar o
funcionamento do sistema embarcado desenvolvido. Na Figura 28, observa-se o
pendrive utilizado neste projeto.

45
Figura 28 – Pendrive utilizado no projeto.
Fonte: Autor, 2017.
3.2.2 Cabo adaptador USB-OTG
O cabo adaptador USB-OTG foi utilizado para realizar as conexões elétricas
entre suas pontas. Em um lado existe um conector micro USB macho e de outro lado
o conector USB tipo A fêmea.
Este cabo adaptador é bastante utilizado em smartphones para fazer conexão
com pendrive. Este adaptador pode ser facilmente encontrado em diversas lojas de
celulares. A Figura 29 ilustra o cabo adaptador USB-OTG.
Figura 29 – Cabo adaptador USB-OTG.
Fonte: Autor, 2017.
No desenvolvimento deste projeto, foi necessário utilizar este cabo adaptador
USB-OTG para fazer a ligação de um pendriveno kit de desenvolvimento STM32F429i

46
Discovery. Na Figura 30, nota-se o pendrive ligado no kit de desenvolvimento através
do cabo adaptador USB-OTG.
Figura 30 – Pendrive conectado no kit de desenvolvimento.
Fonte: Autor, 2017.
A comunicação do microcontrolador com o dispositivo de memória removível
será feita através do protocolo de comunicação USB. Deste modo, o microcontrolador
terá acesso aos arquivos de vídeos tornando possível a decodificação de MPEG neste
kit de desenvolvimento.
3.2.3 STM32CubeMX
Os microcontroladores da família STM32 possuem suporte no software da
STMicroelectronics chamado de STM32CubeMX. Este software serve para auxiliar no
desenvolvimento de projetos que utilizem os microcontroladores da família STM32.
Um dos objetivos principais de utilizar esta ferramenta é que a mesma facilita
a configuração de clock do microcontrolador, detecção de conflitos de pinos e geração
de arquivos iniciais do projeto. Esta ferramenta está disponível gratuitamente no site
da STMicroelectronics.
Após fazer a instalação da ferramenta na máquina utilizada para
desenvolvimento do projeto é necessário criar um novo projeto no software. A Figura
31 ilustra a tela inicial do STM32CubeMX.

47
Figura 31 – Tela inicial do STM32CubeMX.
Fonte: Autor, 2017.
Na tela inicial do programa, deve-se clicar em novo projeto e selecionar a
versão do microcontrolador ou do kit de desenvolvimento que será utilizado. Nota-se
que se for selecionado o kit de desenvolvimento o software já irá detectar todos os
pinos ocupados pelo display LCD e outros periféricos.
Após a criação do projeto no software STM32CubeMX, o sistema já irá
mostrar quais pinos estão ocupados e quais estão livres. Esta ferramenta da
STMicroelectronics também faz sugestão de middlewares que possam ser utilizados
neste projeto.
Na Figura 32, observa-se o projeto criado no software STM32CubeMX.
Observa-se também, nesta figura, que os pinos na cor verde estão disponíveis para
uso no kit de desenvolvimento STM32F429i Discovery.

48
Figura 32 – Projeto criado no STM32CubeMX.
Fonte: Autor, 2017.
Ao selecionar a aba “Clock Configuration”, o sistema ilustra em uma imagem
a configuração de clock do microcontrolador. Nesta aba, é possível configurar e ajustar
a velocidade do clock dos periféricos, PLL e outras configurações internas.
Na Figura 33, nota-se a configuração de clock do microcontrolador utilizado
neste projeto.
Figura 33 – Configuração de clock pelo software STM32CubeMX.
Fonte: Autor, 2017.

49
Ao selecionar a aba de “Configuration”, a ferramenta irá mostrar as
configurações dos periféricos e middlewares selecionados para o projeto. Nesta aba
será possível selecionar e configurar middlewares e periféricos do microcontrolador.
Neste projeto, foi utilizado os middlewares FatFs e USB_Host. O middleware
USB_Host possui todos os códigos padrão de comunicação USB e o FatFs possui os
arquivos para emular um sistema de arquivos pela comunicação desejada, neste caso
será a USB. Assim, será possível o microcontrolador reconhecer o sistema de
arquivos de um pendrive, por exemplo.
A Figura 34 ilustra a tela de configuração de periféricos e middlewares da
ferramenta STM32CubeMX.
Figura 34 – Tela de configuração de periféricos e middlewares.
Fonte: Autor, 2017.
Após fazer todas as configurações de clock, periféricos, pinos e middlewares
do projeto, esta ferramenta possui uma função de gerar códigos iniciais do projeto.
Para utilizar esta função, basta clicar no ícone do lado esquerdo do botão de salvar
ou apertar as teclas de atalho (Ctrl+Shift+G).
A ferramenta do STM32CubeMX gera os arquivos iniciais de desenvolvimento
do projeto no formato reconhecido pelo software System Workbench for STM32. Na

50
Figura 35, pode-se observar o projeto gerado pela ferramenta já aberto no software
System Workbench. Nesta figura nota-se também que os arquivos foram organizados
em pastas, facilitando a visualização e modificação dos mesmos.
Figura 35 – Projeto gerado pelo STM32CubeMX.
Fonte: Autor, 2017.
3.2.4 System Workbench for STM32
O software utilizado para o desenvolvimento de firmware deste projeto foi o
System Workbench for STM32 desenvolvido pela própria STMicroelectronics. Este
software serve como IDE para o desenvolvimento de projetos de software.
Esta ferramenta está disponível gratuitamente no site da STMicroelectronics
e possui suporte para diversos sistemas operacionais. O motivo da escolha desta
ferramenta para este projeto foi que o mesmo possui suporte com o kit de
desenvolvimento adquirido e não é necessário instalar nenhum outro programa.
O System Workbench for STM32 possui os drivers necessários para programar
o kit de desenvolvimento e criar novos projetos, entretanto, será utilizado o projeto
gerado pelo STM32CubeMX. A Figura 36 ilustra o projeto criado no STM32CubeMX
aberto na IDE de desenvolvimento de projetos.

51
Figura 36 – Projeto no System Workbench for STM32.
Fonte: Autor, 2017.
Após abrir o projeto no System Workbench for STM32, o mesmo deve ser
compilado. Para compilar o projeto clique na aba “Project” e em seguida “Build All”, ou
utilizar a tecla de atalho (Ctrl+B).
Inicialmente o projeto deverá ser compilado e não deve apresentar nenhum erro
de compilação. Na Figura 37, observa-se o resultado da compilação deste projeto
gerado pelo STM32CubeMX. Nesta figura é possível observar o tamanho do arquivo,
neste caso, 17952 bytes.
Figura 37 – Compilação do Projeto.
Fonte: Autor, 2017.
Esta ferramenta possui diversas funcionalidades. Destaca-se como
funcionalidade conseguir compilar o projeto e fazer a gravação do firmware no kit de
desenvolvimento utilizando o mesmo software. Uma maneira alternativa de gravar o

52
firmware no kit de desenvolvimento é utilizar a ferramenta STM32 ST-LINK Utility,
porém esta não será utilizada neste projeto.
Uma vez que o programa foi compilado com sucesso na IDE e for necessário
fazer a gravação do firmware gerado, basta clicar na aba “Run” e em seguida em
“Run”. O kit de desenvolvimento deve estar conectado no computador pela porta USB,
caso contrário mostrará que não foi possível se conectar com o dispositivo.
Esta ferramenta possui funcionalidades de depurar o código desenvolvido para
o kit de desenvolvimento. Deste modo, quando for gravado o código pelo ambiente de
desenvolvimento o sistema irá exibir opções de “Play”, “Stop” e “Next Step”.
A Figura 38 ilustra a gravação de firmware no kit de desenvolvimento. Nota-se
também nesta figura que o sistema está no modo de depuração e está informando em
qual linha está executando o código, neste caso ele está na linha 82 executando a
função HAL_Init.
Figura 38 – Gravação de firmware no kit de desenvolvimento.
Fonte: Autor, 2017.

53
3.3 Descrição de hardware
Este projeto é composto por hardware e firmware. No desenvolvimento de
hardware foi adquirido o kit de desenvolvimento STM32F429i Discovery desenvolvido
pela STMicroelectronics.
O hardware do kit de desenvolvimento STM32F429i Discovery é composto
por vários blocos. A Figura 39 ilustra um diagrama de blocos contendo os principais
itens de hardware.
Figura 39 – Diagrama de blocos de hardware.
Fonte: Autor, 2017.
3.3.1 Gravador ST-Link
O gravador disponível no kit de desenvolvimento STM32F429i Discovery é
uma ferramenta embarcada de programação e depuração. A grande vantagem deste

54
gravador presente no hardware do projeto é que não é necessário adquirir um
hardware de gravação de firmware.
No circuito do gravador ST-Link, é possível notar que o conector mini USB faz
a alimentação de todo o kit de desenvolvimento. A Figura 40 ilustra o esquemático do
conector mini USB. Nota-se que o pino de alimentação do conector é ligado no 5V.
Figura 40 – Esquemático do conector mini USB.
Fonte: STMICROELECTRONICS, 2016.
O circuito deste gravador também apresenta uma fonte de alimentação de 3V.
A Figura 41 ilustra o esquemático da fonte de alimentação de 3V. Observa-se que
este é um simples circuito de conversão de 5V para 3V, o mesmo foi desenvolvido
pela STMicroelectronics.
Figura 41 – Esquemático da fonte de alimentação.
O bloco de gravador ST-Link caracteriza-se pela presença de outro
microcontrolador. O STM32F103CBT6 é um microcontrolador utilizado para fazer as
funções de gravação, depuração e upload de programas em outros
microcontroladores. Este microcontrolador não pode ser programado pelo usuário. A
Figura 42 ilustra o esquemático do microcontrolador do gravador ST-Link.

55
Figura 42 – Esquemático do microcontrolador de gravação.
3.3.2 Microcontrolador STM32F429ZIT6
O microcontrolador presente utilizado neste projeto para fazer o sistema de
interpretação de arquivos FAT32 e decodificação MPEG é o STM32F429ZIT6. Este
microcontrolador possui 2 megabytes de memória flash e 256 kB em memória RAM.
No esquema eletrônico deste microcontrolador, deve-se alimentar todos os
pinos de alimentação com 3V. Na Figura 43, observa-se a ligação dos pinos de
alimentação deste microcontrolador e vários capacitores de desacoplamento,
inseridos por recomendação do fabricante.

56
Figura 43 – Esquemático da alimentação do microcontrolador.
Os outros pinos deste microcontrolador são os PORT que podem variar de A
até H. Esses pinos devem ser ligados conforme o interesse do projetista. Cada pino
possui mais de uma funcionalidade e isso deve ser levado em consideração. A Figura
44 ilustra o esquemático dos pinos do microcontrolador, nesta imagem observa-se a
vasta quantidade de pinos que este chip possui.
Figura 44 – Esquemático dos pinos do microcontrolador.
O esquema eletrônico do kit de desenvolvimento STM32F429i Discovery
possui dois conectores de barras de pinos para facilitar montagem de outros módulos
de hardware. Esses conectores possuem pinos de alimentação e dos PORT de A até
H.

57
A Figura 45 mostra o esquema eletrônico das barras de pino do kit de
desenvolvimento. Nota-se a presença dos pinos de alimentação que podem ser
utilizados para alimentar outros módulos de hardware.
Figura 45 – Esquemático das barras de pinos do kit de desenvolvimento.
3.3.3 QVGA TFT LCD
O esquema eletrônico do display LCD TFT QVGA baseia-se no circuito de
recomendação do fabricante. Este display permite vários tipos de comunicação de
dados: SPI, I2C, Serial e Paralelo. A configuração da comunicação é feita através dos
pinos IM0, IM1, IM2 e IM3. Neste projeto foi utilizada a configuração de SPI com 8 bits
de dados.
A Figura 46 ilustra o esquemático do display LCD TFT. Nesta figura nota-se a
configuração dos pinos IM0, IM1, IM2 e IM3. Os componentes que possuem a legenda
N/A significa que o mesmo não foi montado.

58
Figura 46 – Esquemático do display LCD.
Uma parte que merece destaque neste bloco é a parte do circuito do
touchscreen. Este display possui uma tela sensível ao toque e necessita de um circuito
para fazer a leitura das coordenadas do display.
A comunicação do chip de touchscreen com o microcontrolador é feita através
do protocolo de comunicação I2C. No hardware, trata-se de dois fios ligados do
microcontrolador até o chip de controle, um deles será o clock e o outro será os dados.
Na Figura 47, observa-se o esquema eletrônico do circuito de touchscreen.
Figura 47 – Esquemático do driver de touchscreen.

59
3.3.4 Comunicação USB
O microcontrolador STM32F429ZIT6 é utilizado para controlar uma
comunicação USB em alta velocidade no kit de desenvolvimento STM32F429i
Discovery. O conector micro-USB presente no kit de desenvolvimento pode se
conectar com outros elementos como host ou device.
O circuito eletrônico da comunicação USB possui dois LEDs dedicados neste
módulo. O LD5, na cor verde, indica quando o barramento VBUS está ativo. O LD6,
na cor vermelha, indica quando ocorreu sobrecarga de corrente em um dispositivo
conectado.
A Figura 48 ilustra o esquemático do bloco de comunicação USB. Neste
esquema eletrônico é possível notar os LEDs dedicados LD5 e LD6.
Figura 48 – Esquemático da comunicação USB.

60
3.4 Descrição do firmware
Este projeto é composto por hardware e firmware. No desenvolvimento de
firmware foi desenvolvido técnicas para realizar a leitura dos arquivos .mpeg
disponíveis no pendrive e mostrar os mesmos decodificados no display LCD.
O firmware desenvolvido para o kit de desenvolvimento STM32F429i
Discovery é composto por vários blocos. A Figura 49 ilustra um diagrama de blocos
contendo os principais blocos do desenvolvimento do firmware.
Figura 49 – Diagrama de blocos do desenvolvimento de firmware.
Fonte: Autor, 2017.
3.4.1 Bibliotecas
As bibliotecas são arquivos fontes prontos que possuem funções para serem
utilizadas em outros códigos. Inicialmente devem-se incluir todas as bibliotecas
necessárias para inicializar o microcontrolador.

61
O desenvolvimento de firmware deste projeto será feito em cima do projeto
criado pelo software STM32CubeMX. Neste projeto, já está incluso todas as
bibliotecas necessárias para o sistema se inicializar e rodar um programa simples de
“pisca-LED”.
Os processadores da família Cortex necessitam de um conjunto de biblioteca
padrão chamado de CMSIS. Para utilizar o padrão CMSI, são necessários apenas
quatro arquivos. A Figura 50 ilustra um diagrama de arquivos da biblioteca CMSIS.
Figura 50 – Diagrama de arquivos da biblioteca CMSIS.
Fonte: PRADO, 2012.
Neste projeto, o device utilizado será “stm32f4xx”. Deste modo, será
necessário utilizar os arquivos “startup_stm32f4xx.s”, “system_stm32f4xx.c”,
“stm32f4xx.h” e “system_stm32f4xx.h”. A Tabela 8 apresenta uma breve descrição
destes arquivos.
Tabela 8 – Arquivos da biblioteca CMSIS.
Arquivo Descrição
startup_stm32f4xx.s
Este é o arquivo e inicialização, ele inclui a
rotina de reset, configuração do stack pointer e a
tabela de vetores de interrupção.
system_stm32f4xx.c e
system_stm32f4xx.h
Esses são arquivos com rotinas genéricas de
configuração do sistema (inicialização, clock,
barramento, etc).
stm32f4xx.h
Este é o arquivo de cabeçalho com definições
de estruturas e constantes de acesso aos
registradores da CPU e dos periféricos do chip.
Fonte: PRADO, 2012.

62
Após incluir estes arquivos da biblioteca CMSIS no projeto, será possível
utilizar diversas funções na aplicação. Lembre-se que quando se cria um projeto pelo
STM32CubeMX, esses arquivos já são incluídos. Na Tabela 9 observam-se algumas
das principais funções disponibilizadas pela biblioteca CMSIS.
Tabela 9 – Principais funções da biblioteca CMSIS.
NVIC_EnableIRQ()
NVIC_DisableIRQ()
Habilita e desabilita as interrupções.
NVIC_SetPriority()
NVIC_GetPriority()
Configura as prioridades das interrupções.
NVIC_SystemReset() Reinicializa o sistema.
SystemCoreClockUpdate()
Atualiza a variável global SystemCoreClock, que
indica a velocidade atual do clock da CPU.
SysTick_Config() Configura o System Tick.
__enable_irq()
__disable_irq()
Habilita e desabilita todas as interrupções.
__get_CONTROL()
__set_CONTROL
__get_IPSR()
__get_APSR()
Acesso aos registradores da CPU.
Fonte: PRADO, 2012.
No desenvolvimento do firmware deste projeto, somente é necessário chamar
a função HAL_Init e em seguida SystemClock_Config. Essas funções fazem a
chamada das funções de baixo nível de hardware. A Figura 51 ilustra o início do
firmware deste projeto mostrando a chamada das funções de inicialização.
Figura 51 – Chamada das funções de inicialização.
Fonte: Autor, 2017.

63
3.4.2 Driver USB Host
A biblioteca de comunicação USB Host é disponibilizada pela própria
STMicroelectronics. Essa biblioteca utiliza arquivos de configuração separados do
core, deste modo, a configuração da biblioteca não altera o código da biblioteca.
A Figura 52 ilustra um diagrama de blocos da biblioteca USB Host. Nesta
figura, nota-se que a biblioteca USB Host é composta de duas partes: o USB class e
USB core.
Figura 52 – Diagrama em blocos da biblioteca USB Host.
Na prática, a biblioteca desenvolvida pela STMicroelectronics possui vários
arquivos fontes “.c” e “.h”. A Figura 53 mostra a estrutura de arquivos da biblioteca
USB Host já adaptada no projeto criado pelo STM32CubeMX.

64
Figura 53 – Estrutura de arquivos da biblioteca USB
Fonte: Autor, 2017.
A pasta Core possui toda a biblioteca de USB Host definida pela Universal
Serial Bus Specification, revisão 2.0. A pasta Class possui todos os arquivos relativos
à implementação da biblioteca class de acordo com a função desejada, neste caso
será de host.
A Tabela 10 apresenta os principais arquivos da biblioteca core do USB Host
e uma breve descrição do que contém em cada um deles.
Tabela 10 – Arquivos do USB Host Core.
Arquivos Descrição
usbh_core (.c, .h)
Estes arquivos contêm as funções de toda a
comunicação USB e a máquina de estados
principal.
usbh_ioreq (.c, .h)
Estes arquivos contém a geração das transações
USB.
usbh_conf.h
Este arquivo contém a configuração do número
de interface do dispositivo, o número de
configuração e o tamanho máximo de pacotes.

65
O funcionamento desta biblioteca de USB Host desenvolvida pela
STMicroelectronics se resume em uma máquina de estados. A Figura 54 descreve a
máquina de estados da biblioteca USB Host.
Figura 54 – Máquina de estados da biblioteca USB Host.
A máquina de estados da biblioteca USB Host possui nove estados. A Tabela
11 apresenta uma breve descrição de cada um destes estados.

66
Tabela 11 – Descrição da máquina de estados USB Host.
Estados Descrição
HOST_IDLE
Depois da inicialização da biblioteca USB Host, o
core estará neste estado. Neste estado o sistema
fica verificando se ocorreu alguma conexão de
dispositivos USB device. O sistema também
entra neste estado sempre que for detectado
algum evento de desconexão ou por erros.
HOST_ISSUE_CORE_RESET
O sistema entra neste estado quando o device é
conectado com o objetivo de reinicializar a
comunicação serial.
HOST_DEV_ATTACHED
O core entra nesse estado quando o dispositivo
estiver ligado. Assim que o mesmo for detectado,
a máquina de estados vai para o modo
HOST_ENUMERATION.
HOST_ENUMERATION
Neste estado, o core enumera o dispositivo USB.
No final deste estado, o dispositivo com a
configuração “zero” é selecionado.
HOST_USR_INPUT
Este é um estado intermediário que segue a
enumeração e aguarda o comando para
inicializar a operação USB Class.
HOST_CLASS_REQUEST
Iniciando neste estado, o driver Class assume
controle. No final o core move o estado para o
HOST_CLASS.
HOST_CLASS
Neste estado, a máquina de estados Class é
chamada para a operação desejada (sem
controle e com controle de operação).
HOST_CTRL_XFER
O sistema entrará neste estado sempre que for
necessário controle de transferência.
HOST_ERROR_STATE
O sistema entrará neste estado sempre que
acontecer algum erro desconhecido em alguma
das bibliotecas.
O processo da máquina de estados é implementado pela função
USBH_Process. Esta função deve ser chamada periodicamente no looping principal
do projeto. A inicialização da biblioteca USB é feita através da função USBH_init. Esta
função deve ser chamada durante a inicialização da aplicação, antes do looping
principal.

67
A STMicroelectronics disponibiliza junto com os drivers de USB algumas
bibliotecas extras. Nestas bibliotecas está a classe de armazenamento em massa.
Esta classe é importante neste projeto, ela irá trabalhar junto com o módulo FatFs.
A classe de armazenamento em massa se resume em quatro arquivos. A
Tabela 12 apresenta os arquivos da biblioteca MSC do USB Host e uma breve
descrição do que contém em cada um deles.
Tabela 12 – Arquivos da biblioteca MSC.
Arquivos Descrição
usbh_msc_core (.c, .h)
Arquivos com uma implementação de máquina
de estados MSC.
usbh_msc_bot (.c, .h)
Arquivos com implementação do protocolo Bulk-
Only Transport (BOT).
usbh_msc_scsi (.c, .h)
Arquivos com a implementação dos comandos
Small Computer System Interface (SCSI).
usbh_msc_fatfs (.c, .h)
Funções para interagir com um sistema de
arquivo, com operações de acesso de arquivo.
A configuração e otimização da biblioteca MSC se resume apensa nestes
quatro arquivos. Estes arquivos que interagem com o nível mais baixo da
comunicação USB. A Figura 55 ilustra um diagrama de blocos do módulo MSC.
Figura 55 – Diagrama de blocos do módulo MSC.

68
Uma vez que a biblioteca MSC possui o arquivo “usbh_msc_fatfs.c” ela
permite que o driver MSC se comunique com sistemas de arquivos, como é o caso de
um pendrive.
As bibliotecas de comunicação USB disponibilizadas pela STMicroelectronics
possuem um código aberto e suporte para o sistema de arquivos FatFs. A
comunicação da biblioteca USB com o módulo FatFs ocorre através das funções que
precisam ser implementadas. A Tabela 13 apresenta o nome dessas funções e uma
breve descrição do que precisa conter nelas.
Tabela 13 – Funções para inicializar um sistema de arquivos na biblioteca MSC.
disk_initialize Inicializa a unidade de disco.
disk_read Função para ler uma página.
disk_write Função para escrever uma página.
disk_status Função para testar se a unidade está pronta.
disk_ioctl Funcionalidade de controle de device-dependent.
A STMicroelectronics informa no manual que se for utilizado o sistema de
arquivos FatFs, o tamanho da página deve ser fixo em 512 bytes. O sistema não
suporta unidades de disco que possuírem uma memória flash com um tamanho de
página maior que esse.
3.4.3 Driver ILI9341
O display utilizado neste projeto utiliza o driver ILI9341. Este driver foi
desenvolvido pela ILI Technology Corp possuindo um manual de utilização com várias
recomendações de comandos para inicializar o display e fazer comunicação com o
mesmo.
O driver ILI9341 foi desenvolvido em linguagem C no software System
Workbench for STM32. A biblioteca desenvolvida se resume em dois arquivos
“ili9341.c” e “ili9341.h”.
O arquivo “ili9341.h” possui os protótipos de todas as funções do driver, as
definições de resolução, número de identificação do fabricante e todos os comandos
citados no referencial teórico do display LCD, no item 2.4.5. O arquivo “ili9341.c”

69
apresenta funções de baixo nível interagindo diretamente com o LCD. Essas funções
geralmente iniciam com a nomenclatura “LCD_IO” para diferenciar das outras. A
Tabela 14 apresenta as funções de baixo nível do driver ILI9341, essas funções são
responsáveis pela comunicação SPI do microcontrolador com o display LCD.
Tabela 14 – Funções de baixo nível do driver ILI9341.
LCD_IO_Init Inicializa a comunicação SPI.
LCD_IO_WriteData
Escreve 16 bits no barramento de comunicação
SPI.
LCD_IO_WriteReg
Escreve 8 bits no barramento de comunicação
SPI, comandos possuem apenas 8 bits.
LCD_IO_ReadData Lê até 32 bits de um endereço informado.
LCD_IO_Delay Função para gerar atrasos em milissegundos.
Fonte: Autor, 2017.
A biblioteca ILI9341 também é possui funções de alto nível para o display.
Essas funções utilizam os protótipos das funções de baixo nível que foram mostradas
na tabela acima. A Tabela 15 apresenta algumas das principais funções do driver
ILI9341.
Tabela 15 – Principais funções utilizadas do driver ILI9341.
ili9341_Init
Esta função inicializa a comunicação SPI,
chamando a função LCD_IO_Init. Em seguida ela
faz a sequência de comandos de inicialização,
recomendada pelo fabricante do display LCD.
ili9341_ReadID
Esta função retorna o número de identificação do
display LCD.
ili9341_WriteReg
Esta função é para escrita de um registrador,
basicamente ela chama a função
LCD_IO_WriteReg.
ili9341_WriteData
Esta função é para escrita de um dado,
LCD_IO_WriteData.
ili9341_ReadData
Esta função é para leitura de um dado,
LCD_IO_ReadData.
ili9341_DisplayOn
ili9341_DisplayOff
Esta função envia um comando para
ligar/desligar o display.

70
ili9341_GetLcdPixelWidth
ili9341_GetLcdPixelHeight
Esta função retorna a largura e altura do display.
ili9341_DrawPixel Esta função desenha um pixel na cor desejada.
ili9341_DrawChar Esta função escreve um caracter no display LCD.
Fonte: Autor, 2017.
A partir dessas funções básicas da biblioteca do driver LCD, podem-se
desenvolver outras. A Figura 56 ilustra o código da função utilizada para mostrar uma
imagem no display LCD. Lembre-se que essa função precisa ser chamada após a
inicialização do display, através da função ili9341_Init.
Figura 56 – Função para imprimir uma imagem no display LCD.
Fonte: Autor, 2017.
Nesta função, é enviado comandos para configurar uma janela retangular no
tamanho da imagem, conforme foi explicado no referencial teórico do display LCD
(item 2.4.5). Após configurar a janela retangular, é enviado um comando para enviar
os pixels e em seguida, o buffer da imagem é enviado. A Figura 57 ilustra o teste
dessa função imprimindo uma imagem no display LCD do kit de desenvolvido.

71
Figura 57 – Teste da função de imprimir imagem no display.
Fonte: Autor, 2017.
A partir da biblioteca ILI9341 que foi implementada neste projeto, foi
desenvolvido uma tela inicial para o sistema decodificador de vídeos MPEG. O
protótipo de tela inicial pode ser visto na Figura 58.
Figura 58 – Tela inicial do sistema de decodificação MPEG.
Fonte: Autor, 2017.

72
3.4.4 Sistema de arquivos FatFs
O FatFs é um sistema de arquivos genérico do tipo FAT desenvolvido para
pequenas aplicações de sistemas embarcados. Este módulo fornece diversas funções
para acessar e manipular sistemas de arquivos, como foi explicado no referencial
teórico (item 2.2.1).
O módulo FatFs é um middleware que está totalmente separado das funções
de baixo nível. Assim, ele funciona independente do hardware de sistema de arquivo
utilizado, como por exemplo: cartão de memória, memória flash, pendrive, etc. A
Figura 59 ilustra a arquitetura do middleware FatFs.
Figura 59 – Arquitetura do middleware FatFs.
Este módulo possui uma camada de interface, esta camada facilita em
adicionar ou remover dispositivos de mídia no módulo FatFs. Para ligar o módulo
FatFs em um dispositivo de baixo nível que possua um sistema de arquivos, pode-se
utilizar a função FATFS_LinkDriver. Para desligar o módulo de um dispositivo já
conectado, utilize a função FATFS_UnLinkDriver.
Este middleware também informa ao usuário quantos dispositivos estão
conectados no módulo FatFs. Para verificar a quantidade de dispositivos conectado,
utilize a função FATFS_GetAttachedDriversNbr.

73
A função FATFS_LinkDriver conecta um dispositivo compatível e incrementa
o número de dispositivos conectados. Essa função retorna “0” se foi possível conectar,
caso contrário retornará “1”. O módulo FatFs possui um limite máximo de 10 volumes
de disco conectados. A Figura 60 apresenta a implementação do da função
FATFS_LinkDriver, desenvolvida pela STMicroelectronics.
Figura 60 – Implementação da função FATFS_LinkDriver.
Fonte: Autor, 2017.
A função FATFS_UnLinkDriver desconecta um dispositivo e decrementa o
número de dispositivos conectados. Essa função retorna “0” se foi possível
desconectar, caso contrário retornará “1”. A Figura 61 apresenta a implementação do
da função FATFS_UnLinkDriver, desenvolvida pela STMicroelectronics.
Figura 61 – Implementação da função FATFS_UnLinkDriver.
Fonte: Autor, 2017.

74
Após ligar um dispositivo no módulo FatFs, será possível utilizar as funções
básicas de manipulação de arquivos. Neste projeto, o dispositivo utilizado é a
comunicação USB e assim, será utilizado os dispositivos de mídia removível
(pendrive).
Uma vez que o dispositivo USB estiver conectado no FatFs, deve-se montar
a unidade lógica com a função f_mount e acessar um arquivo com a função f_open.
Na Figura 62, observa-se o código fonte para acessar um arquivo no pendrive.
Figura 62 – Exemplo de acesso a um arquivo do pendrive.
Fonte: Autor, 2017.
O código apresentado nesta figura cria um arquivo “STM32.txt” e escreve a
seguinte frase: “text to write logical disk”. A partir deste código, podem-se desenvolver
diversas aplicações com sistemas de arquivos.
Um dos objetivos específicos deste trabalho é fazer a leitura de todos os
arquivos de um pendrive e mostrar os mesmos no display LCD. Para isso, foi
desenvolvida uma função chamada Decoder_DisplayAllFiles. Esta função conecta
com o sistema com o pendrive, verifica todos os arquivos que estão nele e exibe os
mesmos no display LCD. A Figura 63 mostra a função desenvolvida para mostrar os
arquivos do pendrive no display LCD.

75
Figura 63 – Função para mostrar os arquivos do pendrive no display.
Fonte: Autor, 2017.
Após desenvolver a função para mostrar todos os arquivos de um pendrive no
display LCD, foi realizado testes utilizando oito arquivos: “decodificador.pptx”,
“image02.bmp”, “image03.bmp”, “james fraga.docx”, “proposta tcc.pdf”, “stm32.txt”,
“teste.mpeg” e “vídeo.mpeg”. A Figura 64 apresenta os resultados deste teste,
exibindo os arquivos de um pendrive no display LCD.

76
Figura 64 – Arquivos de um pendrive exibidos no display.
Fonte: Autor, 2017.
No teste realizado, foi possível notar que todos os arquivos foram exibidos no
display, porem com nomes truncados. Isso deve ser alguma limitação da biblioteca
FatFs utilizada. Outra observação foi que para os formatos de arquivos, a biblioteca
permite apenas três caracteres. Desta forma, os formatos “.docx” e “.mpeg”
apareceram truncados.
3.4.5 Decodificação MPEG
A decodificação de vídeos é um dos objetivos específicos deste trabalho. Para
o desenvolvimento de firmware deste projeto, foi necessário utilizar uma biblioteca
MPEG.
Essa biblioteca foi desenvolvida por Greg Ward no Hospital e Instituto
Neurológico de Montreal para facilitar o desenvolvimento de um MPEG Player nas
estações de trabalho da Silicon Graphics. Depois disso, essa biblioteca foi utilizada
em inúmeras aplicações gráficas (THIEL, 1997).

77
Foi utilizada a versão 1.2 da biblioteca MPEG, será necessário incluir apenas
o arquivo de biblioteca estática. Para adicionar esta biblioteca no projeto, basta ir em
configurações do projeto e inserir o caminho do arquivo da biblioteca “libmpeg.a”.
Essa biblioteca MPEG possui quatro funções básicas para a decodificação de
um vídeo MPEG. A Tabela 16 apresenta as funções presentes na biblioteca MPEG e
uma descrição sobre os parâmetros que cada uma delas precisa.
Tabela 16 – Funções da biblioteca MPEG.
OpenMPEG
Essa função deve receber como parâmetro um
arquivo MPEG e um ponteiro de buffer para
salvar os frames. Essa função prepara uma
transmissão MPEG para ser decodificada. Ela
inicializa estruturas internas para decodificação,
criando mapas de cores. Depois de chamar essa
função, obtemos a largura, altura, densidade dos
pixels, tamanho e mapa de cores de cada frame.
SetMPEGOption
Essa função permite variar opções de
decodificação do MPEG. Deve-se inserir um
parâmetro de modo, que pode ser
MPEG_DITHER, MPEG_LUM_RANGE,
MPEG_CR_RANGE e MPEG_CB_RANGE. O
primeiro modo configura a matização da imagem
do vídeo e os outros configuram a iluminação e
cromaticidade.
GetMPEGFrame
Essa função precisa receber um parâmetro de
um ponteiro de um buffer para alocar a próximo
frame do vídeo. Ela irá retornar TRUE quando
existir próximo frame para ser decodificada e
FALSE quando for a último frame.
RewindMPEG
Essa função precisa receber dois parâmetros, o
arquivo MPEG e o ponteiro do buffer que estão
os frames. Essa função reajusta o ponteiro para
o início da linha de transmissão e reinicializa a
estrutura para ler o MPEG novamente.
Fonte: Autor, 2017.
A estrutura dos frames “ImageDesc” fornece todas as variáveis necessárias
para decodificar e mostrar um MPEG no display, ela possui variáveis de altura, largura,
densidade, tamanho do pixel, tamanho da imagem e uma outra estrutura de mapa de
cores. A estrutura de mapa de cores é chamada de ColormapEntry, ela possui uma
variável de 8 bits para cada uma das cores RGB. A Figura 65 ilustra as duas estruturas
utilizadas na biblioteca de decodificação.

78
Figura 65 – Estruturas das imagens.
Fonte: Autor, 2017.
Através das funções disponibilizadas por essa biblioteca, foi criada uma
função para decodificar os vídeos MPEG. A função desenvolvida recebe como
parâmetro o nome do arquivo MPEG e em seguida as funções da biblioteca MPEG
são utilizadas para abrir o arquivo MPEG e pegar todos os frames da imagem para
mostrar no display LCD. A Figura 66 ilustra a função desenvolvida para decodificar e
mostrar o vídeo MPEG no display LCD.
Figura 66 – Função para decodificar o vídeo MPEG.
Fonte: Autor, 2017.

79
A função DecoderMPEG_PlayVideo precisa receber como parâmetro o
ponteiro de um arquivo MPEG, para isso foi necessário desenvolver uma função para
encontrar os arquivos MPEG no pendrive. A função desenvolvida é bem parecida com
a função para mostrar todos os arquivos do pendrive no display, como foi mostrado
no item anterior.
No desenvolvimento desta função, foi necessário criar um filtro com as
extensões “mpe” ou “MPE” para os arquivos MPEG. O motivo deste filtro abreviado é
que a biblioteca FatFs trunca a extensão dos arquivos em apenas três caracteres. Na
Figura 67, observa-se a função desenvolvida para encontrar os arquivos MPEG em
um pendrive.
Figura 67 – Função para encontrar arquivos MPEG no pendrive.
Fonte: Autor, 2017.

80
Após desenvolver as funções para encontrar os arquivos MPEG e decodificar
o arquivo, foi utilizado um vídeo para testar o funcionamento das mesmas. O vídeo
utilizado faz a contagem de cinco segundos, bem conhecido na internet. A Figura 68
ilustra diversas imagens do display LCD, mostrando os frames decodificadosdo vídeo
utilizado.
Figura 68 – Vídeo decodificado no display LCD.
Fonte: Autor, 2017.

81
4 APLICAÇÃO E RESULTADOS
O objetivo geral deste trabalho foi desenvolver um protótipo de um sistema de
interpretação de arquivos FAT32 utilizando um pendrive e decodificar vídeos na
arquitetura ARM Cortex-M4. Para isso, foi necessário seguir um procedimento
metodológico visando atingir todos os objetivos específicos do projeto.
No desenvolvimento deste projeto, foram criadas duas telas iniciais. As telas
desenvolvidas possuem texto e valores que correspondem a nomes de arquivos. A
Figura 69 apresenta as duas telas iniciais desenvolvidas neste projeto.
Figura 69 – Telas desenvolvidas para o projeto.
Fonte: Autor, 2017.
A primeira tela desenvolvida mostra o nome do trabalho e mostra uma
mensagem de “Insira um disco na unidade”. Após conectar um pendrive no kit de
desenvolvimento, o sistema vai para a segunda tela desenvolvida, exibindo no display
LCD todos os arquivos que estão no pendrive.
Em seguida, o sistema realiza um filtro nos arquivos com extensão “.mpeg” e
inicia o processo de decodificação do mesmo, fazendo uma leitura do cabeçalho do
arquivo e decodificando os frames para enviar no display LCD. A Figura 70 ilustra os
frames do vídeo sendo exibidos no display, em sequência.

82
Figura 70 – Vídeo sendo reproduzido no display LCD.
Fonte: Autor, 2017.
Os vídeos reproduzidos no display LCD, com resolução de 320x240 pixels,
apresentaram muita lentidão. O vídeo utilizado como teste tem duração de 5 segundos
e levou 15 segundos de duração na reprodução no display LCD. Baseando-se nesses
dados, conclui-se que o sistema levou 200% a mais do tempo para reproduzir o vídeo
no sistema desenvolvido, comparando com o tempo que levaria sendo executado em
um computador com um processador Intel Core i5. A informação sobre a duração
também aparece nas propriedades do vídeo.
A fim de realizar um teste no desempenho da arquitetura ARM Cortex-M4, foi
desenvolvido um teste utilizando o mesmo vídeo com resoluções diferentes. Neste
teste, foram utilizados vídeos nas resoluções QQVGA (160x120), Game Boy Color
(160x144), Game Boy Advance (240x160), QVGA (320x240) e HVGA (480x360).
A Figura 71 ilustra um gráfico que compara diversas resoluções do vídeo com
o tempo de duração dos mesmos.

SISTEMA DE INTERPRETAÇÃO DE ARQUIVOS FAT32 E DECODIFICAÇÃO DE MPEG UTILIZANDO ARQUITETURA ARM CORTEX - M4

SISTEMA DE INTERPRETAÇÃO DE ARQUIVOS FAT32 E DECODIFICAÇÃO DE MPEG UTILIZANDO ARQUITETURA ARM CORTEX - M4

Recomendados

Recomendados

Mais conteúdo relacionado

Semelhante a SISTEMA DE INTERPRETAÇÃO DE ARQUIVOS FAT32 E DECODIFICAÇÃO DE MPEG UTILIZANDO ARQUITETURA ARM CORTEX - M4

Semelhante a SISTEMA DE INTERPRETAÇÃO DE ARQUIVOS FAT32 E DECODIFICAÇÃO DE MPEG UTILIZANDO ARQUITETURA ARM CORTEX - M4 (20)

Último

Último (7)

SISTEMA DE INTERPRETAÇÃO DE ARQUIVOS FAT32 E DECODIFICAÇÃO DE MPEG UTILIZANDO ARQUITETURA ARM CORTEX - M4