sistema de apoio ao preenchimento de dados em …laplima/ensino/tcc/concluidos/2010/recfala.pdf ·...

Pontifícia Universidade Católica do Paraná

GIORDANO BRUNO ZELENSKI

HENRIQUE LUIZ RIBEIRO

SISTEMA DE APOIO AO PREENCHIMENTO

DE DADOS EM PRONTUÁRIO ELETRÔNICO

DO PACIENTE,

A PARTIR DE RECONHECIMENTO DE FALA

GRADUAÇÃO EM

ENGENHARIA DE COMPUTAÇÃO

PUCPR

CURITIBA

2010

GIORDANO BRUNO ZELENSKI

HENRIQUE LUIZ RIBEIRO

SISTEMA DE APOIO AO PREENCHIMENTO

DE DADOS EM PRONTUÁRIO ELETRÔNICO

DO PACIENTE,

A PARTIR DE RECONHECIMENTO DE FALA

Relatório Final apresentado ao Programa

de Aprendizagem de PROJETO FINAL I I

do Curso de Graduação em Engenhar ia

de Computação da Pont i f íc ia

Universidade Catól ica do Paraná como

requisi to parcial do 2º bimestre para

obtenção do tí tulo de Engenhei ro de

Computação.

__________________________________

Or ientador: Prof .ª Cláudia M. C. M. Barra

CURITIBA

2010

Resumo

Este trabalho tem por finalidade apresentar uma alternativa para auxiliar o

preenchimento do prontuário eletrônico do paciente (PEP), elaborado em língua

portuguesa. Trata-se do desenvolvimento de um hardware gravador de áudio

comandado por voz, que possibilitará ao profissional de saúde armazenar dados e

descrições referentes ao atendimento do paciente em uma memória USB flash

drive (pen drive), enquanto está com as mãos ocupadas.

Palavras-chave: Reconhecimento de fala, Reconhecimento de fala embarcado,

Prontuário Eletrônico do Paciente, áudio digital.

Abstract

This paper aims to present an alternative to help fill the electronic patient

record (EPR) in Portuguese. Will develop a hardware audio recording voice-

activated, allowing the healthcare professional recording data and descriptions

relating to the patient in a USB flash drive (pen drive), while his hands full. Using the

software IBM Via Voice, audio recordings will be converted into text.

Keywords: Speech Recognition, Speech Recognition Embedded, Electronic Patient

Record.

Sistema de Apoio ao Preenchimento do PEP a partir de Reconhecimento de Fala Versão: <1.0>

Projeto físico revisado Data: <25/11/2010>

@PUC-PR,2010 Pág. 1 de 48

Sumário Sumário ................................................................................................................................................. 1

Introdução ............................................................................................................................................ 3

Visão Geral do Projeto .......................................................................................................................... 4

Justificativa para Escolha dos Componentes ........................................................................................ 5

Testes realizados para identificação dos critérios de seleção dos componentes de hardware. ....... 5

Testes com BLUETOOTH ............................................................................................................... 5

Testes de Quantização e Freqüência de Amostragem .................................................................. 7

Especificação do Projeto ..................................................................................................................... 10

Diagrama Geral de Blocos ............................................................................................................... 12

Nome do Hardware: Paracelso ....................................................................................................... 13

Módulo Reconhecimento de Fala Embarcado ................................................................................ 14

Módulo Interface USB Flash Drive .................................................................................................. 17

VDIP1 .......................................................................................................................................... 20

TTL-232RG ................................................................................................................................... 21

Módulo Conversor A/D ................................................................................................................... 24

Microcontrolador PIC 16F877 ......................................................................................................... 25

Firmware ..................................................................................................................................... 28

Software de Reconhecimento de Fala para validação .................................................................... 29

Procedimentos de Teste e Validação do Projeto ................................................................................ 32

Roteiro da apresentação Final - Testes em Caixa Preta .................................................................. 32

Gravador de Áudio ...................................................................................................................... 32

Qualidade do áudio ..................................................................................................................... 32

Testes em Caixa Branca .................................................................................................................. 32

Reconhecimento de Fala Embarcado .......................................................................................... 32

Interface USB Flash Drive ............................................................................................................ 33

Comunicação entre PIC e Interface USB Flash Drive ................................................................... 33

Conversor A/D 8-bit .................................................................................................................... 33

Microcontrolador ........................................................................................................................ 33

Protótipo - Plano de Testes e Resultados ........................................................................................... 34

Módulo de Reconhecimento de Fala Embarcado ........................................................................... 34

Teste Funcional 1 ........................................................................................................................ 34

Módulo VDIP ................................................................................................................................... 35




Teste Funcional 1 ........................................................................................................................ 35

Módulo Conversor A/D ................................................................................................................... 36

Teste Funcional 1 ........................................................................................................................ 36

Considerações Finais ........................................................................................................................... 38

Referências ......................................................................................................................................... 39

Anexos ................................................................................................................................................ 40

Anexo 1 – Esquemático A/D Teste .................................................................................................. 40

Anexo 2 – Esquemático HM2007 Teste .......................................................................................... 41

Anexo 3 – Lista de Comandos do VDIP ............................................................................................ 42

Anexo 4 – Cabeçalho WAV .............................................................................................................. 46

Anexo 5 – Esquemático Geral ......................................................................................................... 47




Introdução

Prontuários eletrônicos de pacientes, além de serem essenciais no atendimento,

tem a função de agilizar o serviço de saúde. Em contrapartida, preencher

formulários manualmente ocupa espaço e demanda tempo, contradizendo seu

requisito principal, praticidade. Existem situações nas quais o profissional não tem

como registrar dados e/ou eventos devido as mãos estarem ocupadas no momento

em que os dados estão sendo gerados, uma alternativa seria decorar o que precisa

ser armazenado até o tempo de fazê-lo. Não apenas profissionais de saúde

enfrentam esta dificuldade, entretanto, este projeto demonstra uma alternativa para

solucionar este dilema: um hardware gravador digital de voz comandado por fala

que, desta forma, pode ser acionado e desacionado por um locutor qualquer. A ídeia

principal é que, uma vez que tenhamos áudio digital que possa ser reproduzido e

interpretável, qualquer software de reconhecimento de fala poderia gerar texto a

partir dele (o que exige um requisito mínimo de qualidade de áudio, porém, realizar

a tradução para texto está fora do escopo deste projeto), caminhando em rumo à

facilitar tarefas como o preenchimento de um prontuário.

O projeto é composto por um conjunto de módulos que operando em

conjunto, irão fornecer a ferramenta necessária para solucionar, de maneira

alternativa, um problema aparentemente trivial: O profissional de saúde, enquanto

precisa registrar dados a respeito de seu paciente, quase sempre está com ambas

as mãos ocupadas. No entanto, desenvolver um método para facilitar este processo

envolve, inclusive, conhecer o ambiente hospitalar, que por sua vez, possui muitas

influências eletromagnéticas, as quais podem interferir em tecnologias de

comunicação sem fio.

Este projeto de final de curso propõe uma solução alternativa para o

problema descrito acima. Parte deste documento será feito do detalhamento do

projeto apresentando uma visão geral e diagrama geral de blocos, seguido pela

especificação de cada bloco/módulo. Ao final estão todos os procedimentos de teste

e validação seguidos pelas conclusões e, por fim, os anexos.




Visão Geral do Projeto O funcionamento geral do projeto pode ser interpretado pela figura 1 abaixo.

Porta USB

COMPUTADOR

PENDRIVE

Porta USB

GRAVADOR DE ÁUDIO

RECONHECIMENTO

DE FALA

EMBARCADO

MICROFONE

VOZ

PROFISSIONAL DE

SAÚDE

Áudio a ser

armazenado +

Comandos

ÁUDIO INTELIGÍVEL

Figura 1. Esquema Geral do Projeto.

Entradas:

Áudio (voz a ser gravada + comandos “gravar” e “interromper”) vinda

de microfone.

Saída

Áudio digital codificado em formato Microsoft WAV, armazenado em

pendrive através de uma porta USB.

O Gravador de áudio é uma aplicação do hardware que será desenvolvido de

acordo com a especificação presente neste documento. Sua função será gerar um

arquivo WAV, (cabeçalho: Anexo 4) que possa ser posteriormente reproduzido de

forma inteligível.

Como o intuito futuro (além do presente escopo) para agilizar o

preenchimento do prontuário eletrônico é extrair informações do áudio digital

gravado e armazená-las em bases de dados hospitalares, os requisitos mínimos de




qualidade foram selecionados a partir de um software de Reconhecimento de Fala

(IBM ViaVoice v9.0) no computador, que produz texto a partir de fala. Tendo-se em

mãos um texto bem próximo do que foi pronunciado durante a gravação, este pode

fornecer matéria-prima para processos de armazenamento de dados. Sendo assim,

um dos requisitos deste projeto é que o áudio gravado possua qualidade suficiente

para que a posterior conversão para texto não seja muito prejudicada.

Justificativa para Escolha dos Componentes Esta seção especifica o hardware que foi desenvolvido, bem como as

justificativas para as escolhas dos componentes que foram utilizados.

Primeiramente estão descritos os procedimentos que identificam os requisitos e

limitações desta parte do projeto.

Testes realizados para identificação dos critérios de seleção doscomponentes

de hardware.

Foi realizada uma sequência de testes que acabaram por demonstrar a

inviabilidade do uso do microfone sem fio devido à baixa qualidade de áudio, o que

demonstrou a necessidade de desenvolvimento de um hardware embarcado para a

realizar a gravação do áudio. Após esta constatação, outros testes foram

executados, buscando identificar os requisitos mínimos de qualidade do arquivo de

áudio a ser armazenado para que, quando o mesmo for reproduzido para o

Software de Reconhecimento de Fala, possa ser traduzido em texto de maneira

satisfatória. Os resultados obtidos são informações importantes, pois definem um

limite mínimo de desempenho para o hardware a ser desenvolvido. O detalhamento

destes testes está descrito abaixo.

Em primeira instância, por ser aparentemente trivial, a tecnologia Bluetooth

para transmissão de áudio sem fio foi utilizada.

Testes com BLUETOOTH

Bluetooth (BT) é uma especificação para comunicação sem fio que utiliza

ondas de rádio na freqüência de 2,4 GHz. Em termos de transmissão de áudio, o BT

utiliza o seu CODEC padrão SBC (Subband Codec), para transformar o som




natural/analógico em informação digital. O BT é altamente suscetível a ruído,o que

causa perda de pacotes de dados. Para aplicações em tempo real, o seu uso é

limitado a situações em que essas perdas não causam grandes impactos, o que não

é o caso do reconhecimento de fala.

O teste foi realizado utilizando um headset BT (slave) e um adaptador BT

USB (master). A comunicação entre estes era controlada por um aplicativo chamado

BlueSoleil da IVT Corporation, a fim de traduzir a fala para texto, conforme mostra

a figura 2.

Adaptador

Po

rta

US

B

COMPUTADOR

BlueSoleil

SOFTWARE DE

RECONHECIMENTO

DE FALA

ÁUDIO

TXT

Figura 2. Teste realizado com headset Bluetooth.

Os dados vindos através do BT chegaram aos “ouvidos” do IBM2V. No

entanto, os testes apresentaram alta quantidade de erros, bem como alto grau dos

mesmos. E isso, a pequenas distâncias. Portanto, não optamos por investir em

adaptadores ou headsets de classe superior, a fim de validar os testes.

Tratando-se de reconhecimento de fala, pequenas perdas de pacotes de

áudio representam grandes alterações no processo de identificação, pois a tentativa

de reconstrução da parte do sinal que foi perdido apresenta truncamento, e o

mesmo modifica o sinal, impossibilitando o IBM2V de obter êxito na comparação

com um sinal conhecido.




Foi constatada, então, a impossibilidade da tecnologia atual, de baixo custo,

de realizar transmissão sem fio de áudio, relativamente sem perdas e em tempo

real. O que culminou na retirada deste último requisito do escopo do projeto. Apesar

de que modelos sofisticados de microfones Bluetooth que, aparentemente,

apresentam certa resistência a ruído não foram testados, devido preços inviáveis.

Como a transmissão sem fio não foi satisfatória e o uso de cabos é inviável

no ambiente cirúrgico restou somente a possibilidade de gravar o áudio necessário

para posteriormente ser reproduzido ao software de reconhecimento de fala.

A fim de definir a qualidade de áudio necessária e então verificar viabilidade

de desenvolver um sistema embarcado que resolva o problema das mãos

ocupadas, foi iniciada outra série de testes.

Testes de Quantização e Freqüência de Amostragem

Gravar o áudio a uma taxa de amostragem inferior a utilizada pelo software

de Reconhecimento de Fala certamente diminuiria a taxa de acertos do mesmo. Por

outro lado, utilizar uma freqüência maior que a amostrada seria desnecessário.

Sendo assim, devem-se tomar cuidados com relação à taxa de amostragem

utilizada pelo IBM2V quando reconhece a fala, bem como a resolução das amostras

coletadas, para gravar um áudio compatível. Porém estas informações não foram

encontradas na documentação do Software.

Devido ao fato de que o IBM2V suporta vocabulários adicionais e trabalha

com treinamento incremental,o mesmo deveria manter, de alguma forma, arquivos

correspondentes à coleta dessas palavras que não constam no seu dicionário

interno padrão. Em uma das pastas temporárias deste software,foram encontrados

arquivos no formato wave (*.WAV) relacionados à estas atividades.

Através da função de visualização de propriedades de arquivos, fornecida

pelo Windows XP, foi possívelencontrar os parâmetros de quantização e

amostragem de um dos arquivos gerados pelo IBM2V. Como identificado na figura

3, podemos reconhecer, superficialmente, o CODEC (Audio format) utilizado no

arquivo, bem com deduzir os métodos utilizados na captura do áudio para

reconhecimento de fala.




Figura 3. Quantização, Amostragem e CODEC de um arquivo do IBM2V.

As informações encontradas não podem ser vistas como especificações

técnicas, são apenas deduções que servem de ponto de partida para o teste abaixo.

Testes com freqüências de amostragem diferentes

Para realizar esta bateria de teste, primeiramente, definimos o procedimento:

Através de um cabo auxiliar, no qual as duas pontas possuem

conectores P2, compatíveis com as entradas line-in e microfone, e

saída line-out, de uma placa de som on-board comum, conectamos

diretamente o line-out no line-in(figura 4), ou seja, o som reproduzido

pelo player de áudio foi diretamente submetido ao reconhecimento do

IBM2V.




Figura4.Conexão line-in/line-out.

Uma vez que o procedimento anterior foi realizado, foi utilizando um gravador

de áudio de código-aberto para gravar várias vezes um comando conhecido pelo

IBM2V, com diferentes parâmetros de gravação.

O CODEC utilizado para todos os testes foi o PCM (Pulse Code Modulation),

por ser sem compactação e perdas. Além disso, é um CODEC de simples

implementação em hardware, tornando possível a criação de um gravador de áudio,

cujos arquivos são compatíveis com o IBM2V.

Ao reproduzir o produto das gravações-teste para o IBM2V, os resultados

obtidos foram:

Amostragem 8 kHz 11,025 kHz 22,05 kHz 44,1 kHz 22,05 kHz

Quantização 16-bit 16-bit 16-bit 16-bit 8-bit

Resultado Não reconheceu Reconheceu

Tabela 1. Resultados para testes de freqüência e quantização.

Nota: Os testes com quantização inferior a 8-bit não foram realizados devido

a limitações do CODEC do gravador. O tamanho dos quadros deve ser no mínimo 1

byte.



@PUC-PR,2010 Pág. 10 de 48

Como o teste em 22,05 kHz e 8-bit (176 kbps) obteve êxito e é o mais

econômico em recursos de hardware, tal critério foi adotado para o desenvolvimento

do hardware gravador de áudio, que possibilitará ao sistema realizar a atividade de

reconhecimento de fala sem que esta seja em tempo real, ou seja, a partir das

gravações.

Especificação do Projeto

Principais características

Acionado e desacionado por comandos de voz;

Comandos de voz são programáveis, ou seja, não existe um critério fixo para

a escolha dos comandos de acionamento ou desacionamento;

Simula independência de locutor. Os comandos de voz podem ser

programados até 10 vezes repetidas, podendo ser cada um de um locutor

diferente. Comandos de acionamento devem ser treinados em posições de

memória que são números pares, ao contrário dos comandos de

desacionamento.

Grava até 4GB (mais de 5 horas contínuas) em um único arquivo;

Consumo durante gravação: 100mA (170mA de pico incial);

Interface USB, após o término da gravação, o áudio gravado em uma

unidade USB flash drive pode ser transferido e reproduzido no computador;

Arquivos em formato WAV em 8 bits * 22050 Hz ;

Cria e nomeia os arquivos automaticamente de FILEA até FILEZ (A a Z);

Utiliza uma bateria de 3V auxiliar para conservar os últimos comandos

treinados;

Alimentação: bateria 9V;

O arquivo gerado pode ser processado por software de reconhecimento de

fala;

Projetado para gravar voz descritiva (próximo ao microfone).

Trata-se de um gravador de áudio que é acionado e interrompido a partir de

comandos de voz. Para tal, é utilizado o CI HM2007 que é capaz de reconhecer

palavras previamente cadastradas. A fim de evitar que o usuário pronuncie um



@PUC-PR,2010 Pág. 11 de 48

comando acidentalmente, o mesmo deve ser pronunciado duas vezes seguidas

para que possa ser executado.

As amostragens das gravações são feitas através do conversor

analógico/digital (A/D) presente no CI ADC0820 e então armazenadas em uma

unidade USB Flash Drive, cuja interface é fornecida pelo módulo VDIP1.

As amostras são ser coletadas a uma taxa de 22,05 kHz. Tal freqüência

atende ao Critério de Nyquist (equação 1) para sinais de voz, que geralmente não

ultrapassam 4 kHz e, corresponde à taxa de amostragem utilizada pelo IBM Via

Voice, garantindo assim,que o áudio gravado, quando reproduzido para o mesmo,

seja compatível, para que a fala seja reconhecida com quantidade mínima possível

de erros.

Equação (1)

Para que isso seja possível, o microcontrolador PIC16F877A realiza a coleta

de dados vindos do conversor A/D com a freqüência determinada, envia a amostra

coletada para o módulo USB (grava a amostra). Este mesmo CI é responsável por

manter a estrutura de software que responde aos comandos de voz.

O hardware deve ser estruturado de acordo com o Diagrama Geral de Blocos

(DGB)ilustrado na figura 4.



@PUC-PR,2010 Pág. 12 de 48

Diagrama Geral de Blocos

DTBUS3[0..7]

Módulo Reconhecimento de

Fala Embarcado

(CI HM2007)

8K x 8 SRAM

Palavras Conhecidas

(CI 6264)

DT

BU

S1

[0..

7]

AD

BU

S[0

..1

2]

Latch Octal

(CI 74HC573)DTBUS2[0..7]

Microcontrolador PIC

(CI PIC16F877)

Módulo Conversor A/D

8-bit

(CI ADC0820)

Sinal de Voz

READ

RB0/INT

Módulo de

Interface USB Flash Drive

(VDIP1)

Latch Enable

SR

BU

S[0

..3

]

USBBUS[0..3]

Microfone

Porta USB

Sinal de Voz

RD – Pin 7__

Chip Select

Figura 4. Diagrama Geral de Blocos do Paracelso.

Os barramentos do DGB são especificados de acordo com a tabela 2.

Barramento Descrição

ADBUS[0..12] Barramento de Endereços. Endereçamento na memória de 8K

x 8 bits.

DTBUS1[0..7] Barramento de Dados 1. Bits de dados correspondentes ao

código de saída do HM2007.

DTBUS2[0..7] Barramento de Dados 2. Bits de dados correspondentes à

saída do Latch Octal. São os mesmos dados do DTBUS1.

DTBUS3[0..7] Barramento de Dados 3. Bits de dados correspondentes à

conversão analógico/digital 8-bit do Sinal de Voz.

SRBUS[0..3] Barramento Serial. É utilizado para controle e transporte de

dados seriais para interface USB Flash Drive.

USBBUS[0..3] Barramento USB. É utilizado para controle e transporte de

dados entre a interface USB e o Flash Drive.

Tabela 2. Descrição dos barramentos do Paracelso.



@PUC-PR,2010 Pág. 13 de 48

Nome do Hardware: Paracelso

Paracelso é o nome do hardware gravador. Uma breve descrição sobre quem

foi este homem está escrita abaixo.

Foi médico revolucionário de sua época. Viveu entre os séculos XIV e XV.

Morreu aos 48 anos de idade, conforme previu antes de escrever detalhadamente

seu testamento e as instruções exatas para o seu funeral. Criou a quimioterapia e a

base do que veio a ser futuramente chamada de homeopatia. Visto por muitos,

como médico mago, foi homem apaixonado pelos estudos da medicina e escreveu

diversas obras. Rebelou-se à sociedade médica, acreditando que o conhecimento

possui cinco naturezas: a Doutrina Secreta, também conhecida como Hermetismo; o

misticismo; o conhecimento científico; a alquimia (medicina); e a Ars Magna, ou Arte

Maior, a unificação dos anteriores. Tratou enfermidades de todos os tipos, em

grande parte do mundo, inclusive do filho do Grande Khan, na Tartária.

Quando se bacharelou em medicina, se auto entitulou Paracelso, que

significa acima de Celso, (Aulus Cornelius Celsus), médico romano do século I.

Afirmou que a medicina é dupla: clínica e cirúrgica. “Toda afecção que vai do

centro até à periferia deve ser considerada como física (clínica), e toda aquela que

ao contrário, ganha o centro partindo da periferia será tributária da cirurgia” (A

CHAVE DA ALQUIMIA, 1973, p. 33).

Na igreja de Santo Estevão, um epitáfio encontra-se ainda marcado numa

placa de mármore, em elogio ao homem que foi: “Aqui jaz Felipe Teofrasto de

Hohenheim. Famoso doutor em medicina, que curou toda a espécie de feridas, a

lepra, a gota, a hidropisia e outras enfermidade do corpo com ciência maravilhosa.

Morreu em 24 de setembro no ano da graça de 1541” (A CHAVE DA ALQUIMIA,

1973, p. 15).

O nome dado a este hardware é, com certeza, em reconhecimento a esta

importante e singular personalidade que foi Paracelso, principalmente para a

medicina.



@PUC-PR,2010 Pág. 14 de 48

Módulo Reconhecimento de Fala Embarcado

O Circuito Integrado HM2007 reconhece comandos de voz fornecidos ao

Paracelso. Estes são palavras previamente cadastradas na memória (6264)

utilizada pelo CI. Sua pinagem está descrita na figura 5.

Figura 5. Pinagem (48-pin PDIP) do HM2007.

Como requisito básico, o HM2007 exige que, para cadastros de até 20

palavras, as mesmas tenham duração de no máximo 1,92 segundos. No caso de

desejar-se cadastrar mais que 20 (até 40), cada palavra não deve exceder o tempo

de 0,96 segundos.

Neste projeto, dois comandos serão armazenados e independerão de locutor.

São eles:

Gravar – Se pronunciado duas vezes inicia a rotina de gravação do

Paracelso. Habilita o conversor A/D, a fim de coletar amostras a uma



@PUC-PR,2010 Pág. 15 de 48

taxa de 22 kHz. Porém, continua suscetível à possível interrupção, que

é gerada caso o locutor pronuncie duas vezes o comando Pausar;

Pausar – Se pronunciado duas vezes pára a rotina de gravação do

Paracelso. Desabilita o conversor A/D, mas continua esperando novos

comandos de voz. Neste caso, a única seqüência de comandos

possível seria pronunciar duas vezes o comandoGravar.

A independência de locutor pode ser simulada se, na fase de configuração,

diferentes vozes treinarem a mesma palavra. O Paracelso utilizará dez pronuncias

para cada, totalizando vinte palavras.

Para compreender melhor as seqüências de comandos que o Paracelso deve

aceitar, o diagrama de transição de estados (DTE) presente na figura 6 ilustra os

possíveis casos.

Gravando

Parado em

Alerta

Recebe Comando Pausar

Recebe Comando Gravar

Recebe Comando

Gravar

Desilgado

Parado

Inicia o sistema

Fim da Espera

Gravando em

Alerta

Fim da Espera

Recebe Comando

Pausar

Figura 6. DTE do Paracelso



@PUC-PR,2010 Pág. 16 de 48

Para cadastrar as palavras/comandos na memória do gravador, durante a

fase de implementação, foi necessária a interface do HM2007 com um teclado

matricial para executar sua configuração, pois, através deste são realizadas as

funções CLR (clear) e TRN (train), conforme ilustra a figura 7.

Figura 7. Interface de configuração do HM2007.

O barramento KBBUS[0..2][0..3], é conectado diretamente ao HM2007 nos

pinos específicos para este tipo de teclado. Os três primeiros bits ([0..2]) devem ser

conectados aos pinos S1, S2 e S3. Os quatro próximos bits correspondem aos

pinos K1, K2, K3 e K4.

O processo de treinamento/cadastro de palavras nas respectivas posições da

memória e deve ser feito da seguinte maneira:

Digitar no teclado numérico um número entre 1 e 20, que corresponde

a posição da memória;

Teclar TRN;

Falar a palavra (menos que 1,96 segundos) ao microfone.

A tabela 3 abaixo descreve o comportamento do HM2007 quando submetido

à possíveis seqüências exemplo de comandos.



@PUC-PR,2010 Pág. 17 de 48

Passos Seqüências de Ações

1 Teclar 01 Teclar 09601 Teclar 02 Teclar 3202 Teclar 99

2 Teclar TRN Teclar TRN Teclar CLR Teclar CLR Teclar CLR

3 Falar Palavra Falar Palavra - - -

Resultado Armazena palavra na posição 01.

Armazena palavra na posição 01.

Apaga a palavra

treinada na posição 02.

Apaga a palavra

treinada na posição 02.

Apaga toda a memória.

Tabela 3. Possíveis resultados para configuração do HM2007.

O Teste das palavras treinadas é feito simplesmente pronunciando-se a

palavra desejada, sem pressionar nenhuma tecla. O código da palavra identificada

será transmitido para o barramento DTBUS1[0..7] e ficará gravado no Latch Octal.

Sendo assim, o teclado matricial só é necessário na etapa de configuração.

O HM2007 pode ainda gerar três códigos de erro, sendo eles:

01010101 (BCD 55): Palavra muito longa;

01100110 (BCD 66): Palavra muito curta;

01110111 (BCD 77): Palavra não cadastrada.

Nota: O HM2007 é incapaz de reconhecer palavras pronunciadas em

ambientes com muito ruído. No entanto, microfones com tecnologias para

eliminação de ruídos podem ser utilizados, melhorando assim, o desempenho de

um sistema que utiliza o HM2007.

Utilizando este recurso, o usuário não precisa apertar botões no gravador

para executar a função desejada. Desta forma, o profissional de saúde poderá

registrar dados enquanto utiliza as mãos para outras funções.

MóduloInterface USB Flash Drive

O Circuito Integrado Vinculum VNC1L é responsável pela interface entre o

microcontrolador e a unidade USB Flash Drive. O VNC1L possui os seguintes

recursos principais para o projeto [REF002]:

Protocolo USB inteiramente tratado no chip.

Duas portas host USB 2.0 independentes.



@PUC-PR,2010 Pág. 18 de 48

Firmware atualizável via UART ou USB.

Configuração operacional gratuita através de escolha de firmware disponível.

Firmware, quando integrado, permite leitura de e escrita para dispositivos

USB Flash em formato FAT.

Programável via interface UART.

Alimentação de +3.3v com entradas seguras de 5v.

Operação de baixo consumo (25mA operacional, 2mA em standby)

A pinagem do chip está descrita na figura 8.

Figura 8. Pinagem do VNC1L.

O microcontroladorcomunica-se com o chip através de um barramento serial

UART (SRBUS[0..3]).



@PUC-PR,2010 Pág. 19 de 48

O VNC1L é fabricado pela FTDI (Future Technology Devices International

Ltd) e é comercializado sem nenhum firmware pré-programado. No site do

fabricante é possível encontrar diferentes versões de firmwares para

download[REF01].São elas:

VDAP (disk and peripherals) - Configura uma porta USB para Flash

Diske outra para dispositivos genéricos. Interfaces de comando em

UART, FIFO ou SPI.

VDIF (disk and FTDI Interface) - Configura uma porta USB para Flash

Disk e outra para dispositivos genéricos. Interfaces de comando em

UART, FIFO, SPI ou USB.

VMSC(music player) – Configura uma porta USB para Flash Diske

permite interface com chips decodificadores de MP3. Interfaces de

comando em UART, FIFO ou SPI.

VDPS (disk, PC monitor and slave port) - Configura uma porta USB

para Flash Disk e outra para dispositivos genéricos, podendo ser

conectada a um computador. Interfaces de comando em UART, FIFO

ou SPI.

VCDC (communication class device) - Configura uma conexão

automática com dispositivos USB de classe de comunicação.

Interfaces de comando em UART.

VDFC (disk and file copier) – Configura duas portas USB para Flash

Disk. Interfaces de comando em UART, FIFO ou SPI.

Além das opções de firmware disponibilizadas, o fabricante também fornece

um datasheet[REF03] para o desenvolvimento de firmwares personalizados, o que

não será aplicado neste projeto.

Como requisito básico, o gravador precisa armazenar dados na unidade USB

Flash. A versão do firmware, mais simples que atende completamente este requisito

é a VDAP, portanto, esta é utilizada.

A gravação do firmware no VNC1L é realizada através da interface serial

UART ligada nos pinos TXD, RXD, RTS# E CTS# (SRBUS[0..3]) e exige que os

pinos #PROG e #RESET estejam em nível lógico baixo.



@PUC-PR,2010 Pág. 20 de 48

O CI FT232R, do mesmo fabricante, possibilita esta interface criando uma

porta serial virtual no computador (VCOM) de um lado através de uma porta USB e

uma interface serial TTL do outro, wire-ended. Através do software VPROG,

também disponibilizado no site, o arquivo (*.ROM) correspondente ao firmware

desejado pode ser instalado no VNC1L. A interface entre o FT232R e o VNC1L é

feita conforme a figura 9 abaixo.

Figura 9. Conexão VNC1L com interface para VCOM.

Para facilitar esta comunicação, a empresa oferece dois módulos pré-

fabricados. São eles:

VDIP1

Este módulo implementa todo o circuito necessário para o funcionamento do

VNC1L, que nele está integrado, bem como uma porta USB e configuração DIP 24-

pin adaptada. O VDIP1 está apresentado na figura 10.



@PUC-PR,2010 Pág. 21 de 48

Figura 10. Módulo VDIP1.

TTL-232RG

Este é um cabo e implementa todo o circuito necessário para o

funcionamento do CI FT232R, que nele está integrado e conectado a uma porta

USB, fornecendo assim, a interface necessária para comunicação com o

computador. Do outro lado do cabo, está o barramento serial TTL em aberto para

conexão com os pinos do módulo VDIP1, ou seja, trata-se de um conversor

genérico USB para TTL serial UART, responsável pela gravação do firmware no

VDIP1. Este módulo está apresentado na figura 11 abaixo.

Figura 11. Módulo TTL-232RG.



@PUC-PR,2010 Pág. 22 de 48

Os módulos TTL-232RG são fornecidos em uma gama de diferentes

configurações. São elas:

TTL-232RG-VSW3V3-WE: Cabo com um lado USB e outro aberto

(wire-ended) para conexões UART de nível lógico +3.3V e

fornecimento de saída com relação de potência +3.3V / 50mA.

TTL-232RG-VREG3V3-WE: Cabo com um lado USB e outro aberto



TTL-232RG-VREG1V8-WE: Cabo com um lado USB e outro aberto



TTL-232RG-VSW5V-WE: Cabo com um lado USB e outro aberto



TTL-232RG-VIP-WE: Cabo com um lado USB e outro aberto (wire-

ended) para conexões UART de nível lógico configurável pelo usuário.

O módulo que melhor atende aos requisitos do projeto é o TTL-232RG-

VSW5V-WE, pois sua relação de potência na saída é a mínima oferecida, porém

suficiente para que o VNC1L reconheça os níveis seriais de tensão. De maneira

geral, durante a fase de configuração, ou seja, instalação do firmware, as conexões

serão feitas conforme mostra a figura 12.



@PUC-PR,2010 Pág. 23 de 48

VPROGV

C

O

MUSB Port

TT

L-2

32

RG

VCC

TXD

RXD

CTS#

RTS#

COMPUTADOR

Figura 12. Virtual COMPort para configuração via VPROG.

Com o firmware VDAP programado, a interface com o USB Flash Drive

estará apta para comunicação com o microcontrolador, através de seqüências de

controle e dados, conforme especificações presentes na referência [REF01] e no

anexo 2. O pino RX do cabo (amarelo), pode ser usado para “assistir” transmissão

serial no Hyperterminal, basta conectá-lo a qualquer TX ativo de outro elemento que

esteja transmitindo de forma serial com o mesmo baud-rate. Esta técnica foi usada

durante o processo de testes para verificar sincronismo, comandos/estímulos e

respostas aos estímulos do PIC16F com o VDIP1 em ambos os sentidos da

comunicação.

A pinagem do barramento serial do VDIP está descrita na tabela 4 abaixo.



@PUC-PR,2010 Pág. 24 de 48

Tabela 4. Barramento serial presente no VDIP.

Os pinos 6, 8, 9, 10 correspondem ao barramento SRBUS[0..3], os demais

não são utilizados.


Este será responsável pela amostragem e quantização do sinal de voz

enquanto o processo de gravação estiver sendo executado. Caso contrário, será

desativado para economia de energia, uma vez que o tempo de funcionamento

contínuo do sistema é umaquestão crítica.

CI’s codificadores de áudio, geralmente, implementam funcionalidades além

das necessárias para o funcionamento do gravador presente no contexto deste

projeto. Entre elas, podemos citar o decodificador embutido (CODEC). Por esta

razão o áudio será amostrado apenas com um conversor A/D.

O ADC0820é um circuito integrado CMOS, que utiliza a técnica de conversão

A/D half-flash, permitindo manipulação da freqüência de amostragem pelo

microcontrolador.Foi escolhido por possuir recursos que possibilitam os requisitos

de gravação. São eles:

Resolução 8-bit.

Tempo de conversão 1.5µs.



@PUC-PR,2010 Pág. 25 de 48

Baixo consumo de energia – 75 mW no máximo, o que significa uma

corrente de 15 mA, quando alimentado com 5V.

Função track-and-hold embutida.

Não necessita de clock externo.

Encapsulamento DIP 20-pin.

Este circuito possui, na entrada do sinal, faixa de operação de 0 a 5V se o

mesmo for alimentado com 5V e, portanto, tensão de referência em 5V.

A fim de não amostrar ruído sonoro de altas frequências, faz-se necessária a

utilização de um filtro passa-baixas passivo antecedente a entrada do CAD. Como a

voz humana não ultrapassa 4kHz, estão sendo usados (anexo 5) um resistor de 6k8

e um capacitor de 5,6nF que determinam um frequencia de corte de 4179Hz de

acordo com a equação

.

A leitura dos dados quantizados de saída (amostras) será realizada, bem

como o tratamento adequado, pelo microcontrolador responsável.

Microcontrolador PIC 16F877

Fabricado pela Microchip e, com um clock de 20 MHz (máximo suportado),

executa um ciclo de instrução a cada 200ns. Possui capacidade de interrupção por

timer, pino externo, entre outras 12 opções [REF07]. Este microcontrolador será

responsável pela interligação dos módulos citados acima, deverá coletar amostras

vindas do módulo Conversor A/D e encaminhá-las para dentro de um pendrive

conectado ao módulo VDIP assim como interpretar os comandos identificados pelo

CI HM2007.

Como as especificações mínimas para o gravador são uma taxa de

amostragem de 22,05 kHz e uma resolução de 8-bit, totalizando 176kbps, o ciclo

completo de captura e gravação deve ocorrer no período máximo de 45,35µs

(equações 2 e 3). Tempo suficiente para executar até 167 instruções de 271ns

(aproximadamente, para XTAL de 14,7456 MHz) cada, o que permite o

processamento paralelo de outras informações entre os ciclos de amostragem.



@PUC-PR,2010 Pág. 26 de 48

Equação (2)

Equação (3)

Para coletar dados vindos do conversor A/D no tempo necessário, o módulo

TIMER2, interno ao circuito, será usado para gerar interrupções de hardware no

período da freqüência de 22,05 kHz.

O TIMER2 possui os seguintes recursos:

Contador 8-bit – TMR2.

Registrador 8-bit – PR2.

Divisor de freqüência de entrada – prescaler.

Divisor de freqüência na saída – postscaler.

O diagrama de blocos do TIMER2 está ilustrado na figura 13.

Figura 13. Diagrama de Blocos do TIMER2. [REF07].

A contagem é iniciada em zero, e é incrementada a cada pulso da freqüência

já dividida. Quando o TMR2 se iguala ao valor presente no PR2, o contador é

reiniciado e pode gerar uma interrupção no PIC, se o bit de controle para tal,

TMR2IF, no registrador PIR1, estiver ativado.



@PUC-PR,2010 Pág. 27 de 48

A cada interrupção gerada pelo TIMER2, uma amostra será coletada do

conversor A/D, possibilitando que a amostragem seja efetuada na freqüência

desejada.

Cada amostra coletada é trasmitida para o VDIP através da USART do PIC

para ser armazenada no pen-drive, em blocos de 128KB. O código para o

microcontrolador está em anexo.

As taxas de transmissão serial (baud-rate) utilizadas serão inicialmente

9600Bd (default do VDIP) e então ajustada para 921600 (máxima), pois com este

valor de XTAL oscilador de 14,7456 MHz conseguimos um erro 0% entre o valor do

baud-rate real e desejado, sendo que o bit BRGH (informa ao PIC se estamos

utilizando altas velocidades ou baixas) está sempre em nível lógico alto (=1),

conforme tabela 5 abaixo.

Comunicação Assíncrona Baud Rate - PIC16F877

Fclock= 1,47E+07 Hz valor do XTAL: 14,7456 MHz

BRGH=0 BRGH=1 TIMER 2

BaudRate SPBRG Baud Rate Real

Erro (%) SPBRG

Baud Rate Real

Erro (%) Entrada do clock:

110 255 900 718,2 255 3600 3172,7 clk/4 = 3,69E+06

300 255 900 200,0 255 3600 1100,0 1200 191 1200 0,0 255 3600 200,0 Valor de PR2:

2400 95 2400 0,0 255 3600 50,0 167

4800 47 4800 0,0 191 4800 0,0

9600 23 9600 0,0 95 9600 0,0 Frequêcia resultante

19200 11 19200 0,0 47 19200 0,0 de interrupção:

38400 5 38400 0,0 23 38400 0,0 22074,25

57600 3 57600 0,0 15 57600 0,0 115200 1 115200 0,0 7 115200 0,0

230400 0 230400 0,0 3 230400 0,0

460800 0 230400 50,0 1 460800 0,0 921600 0 230400 75,0 0 921600 0,0 Tabela 5. Taxas/erros de BaudRate

Os métodos de gravação utilizam os códigos de comunicação presentes no

anexo 3.



@PUC-PR,2010 Pág. 28 de 48

Firmware

O firmware desse microcontrolador é programado em linguagem C, no

ambiente MPLAB, utilizando a ferramenta SourceBoost C. Sua rotina principal é

controlada, através dos comandos gerados pelo HM2007, para decidirquando

realizar amostragem contínua da voz, armazenando-a, conforme mostra a figura 14.

Rotina Principal

Início

A/D

Habilitado?

Desabilitar A/D

Habilitar A/D

S

S

N

N

Leitura 2

Leitura 1

Rotina Principal

Coletar 1 byte

do A/D

Armazenar byte

no USB Flash

Drive

Aguardar o tempo

para próxima

amostra

Figura 14. PIC – Rotina Principal.

O reconhecimento dos códigos de comando de voz gerados pelo Módulo de

Reconhecimento de Fala Embarcado é feito por duas sub-rotinas que estão

identificadas nos diagrama como “Leitura 1 e 2”. Os funcionamentos destas sub-

rotinas estão ilustrados na figura 15.



@PUC-PR,2010 Pág. 29 de 48

Sub-Rotinas

Recebeu

Comando

Gravar?

Ler Palavra

Recebeu

Comando

Gravar?

tempo < 5s

S

S

N

S

N

N

Leitura 1

Sub-rotina de Leitura 1

Ler Palavra

Recebeu

Comando

Pausar?

Ler Palavra

Recebeu

Comando

Pausar?

tempo < 5s

S

S

N

S

N

N

Leitura 2

Sub-rotina de Leitura 2

Ler Palavra

Figura 15. Sub-rotinas de Leitura.

Software de Reconhecimento de Fala para validação

Este software será futuramente utilizado para validação da qualidade do

áudio final. Sua função é receber como entrada o arquivo de áudio armazenado na

unidade USB Flash Drivee convertê-lo para texto.

É uma ferramenta pronta chamada de “ViaVoice Pro USB edition Release 9”

que foi desenvolvido pela International Business Machines Corporation (IBM) no ano

de 2001. Conforme o estado da arte levantado sobre ferramentas deste tipo, o IBM

ViaVoice é o mais eficaz para uso com a Língua Portuguesa Brasileira.



@PUC-PR,2010 Pág. 30 de 48

Possui os seguintes recursos:

Funciona sobre plataforma Windows.

Faz treinamento incremental – conforme o usuário realiza mais etapas

do treinamento, o reconhecimento aumenta sua precisão.

Busca automáticamente palavras não reconhecidas, bem como a

adição das mesmas no vocabulário do usuário.

Os processos de instalação e treinamento podem ser executados de forma

intuitiva através de wizards.No segundo caso, o usuário deve ler um texto para o

ViaVoice, quando estiver na tela “Criando Meu Padrão Pessoal de Voz”, ilustrada na

figura x.

Figura 20. ViaVoice – Inicio do treinamento.

Quando o treinamento estiver concluído, a seguinte mensagem aparecerá na

tela (figura x):



@PUC-PR,2010 Pág. 31 de 48

Figura 21. ViaVoice – Fim do treinamento.

O usuário deve, então, clicar no botão “Analisar” para efetivar esta etapa.

Caso queira, poder continuar realizando o treinamento incremental, clicando no

botão “Continuar Leitura”.

O ViaVoice quando instalado e pronto para usar, ficará localizado como uma

barra fixa, na parte superior da tela, conforme a figura 22.

Figura 22. ViaVoice – Barra.

Os itens da barra representam: 1. Menu. 2. Estado do microfone (ativado,

desativado ou interrompido). 3. Nível de áudio. 4. Interface de feedback. 5. Ajuda. 6.

Usuário ativo.

Neste estágio, o ViaVoice já está pronto para ser utilizado.



@PUC-PR,2010 Pág. 32 de 48

Procedimentos de Teste e Validação do Projeto

Para validar o sistema serão realizados testes de dois tipos:

Testes em Caixa Preta – Procedimentos deste tipo são do ponto de

vista do usuário, onde apenas as entradas e saídas são analisadas. O

processo é transparente.

Testes em Caixa Branca – Procedimentos deste tipo são do ponto de

vista do sistema, que é analisado por dentro, buscando validar o

funcionamento de cada módulo.

Roteiro da apresentação Final - Testes em Caixa Preta

Estes testes serão feitos durante a apresentação da implementação final.

Gravador de Áudio

I. Pronunciar um comando de voz e verificar se o comportamento foi alterado

corretamente, isto é, quando for pronunciado 2 vezes um dos comandos

“gravar” ou “interromper”, o sistema deverá mudar-se para o estado

correspondente.

II. Ditar um texto e verificar se após o fechamento do arquivo existem dados

gravados no pendrive.

Qualidade do áudio

III. Se os testes acima se confirmarem, então serão realizados os seguintes:

IV. Reproduzir o arquivo gerado pelo gravador de áudio e verificar sua

inteligibilidade.

V. Se a inteligibilidade for confirmada podemos ainda executar o áudio para o

software de reconhecimento de fala apresentado na seção acima. Caso a

transcrição seja satisfatória estaremos um passo mais perto de eliminar e

automatizar o problema das mãos ocupadas

Testes em Caixa Branca

Estes testes não serão executados na implementação final, são apenas para

verificar a integridade dos módulos caso resolvamos dar continuidade ao trabalho:

Reconhecimento de Fala Embarcado

O teste será realizado da seguinte forma:

Passo 1. Cadastrar uma palavra.



@PUC-PR,2010 Pág. 33 de 48

Passo 2. Verificar o barramento de dados utilizando a rotina do

microcontrolador quando a palavra cadastrada é pronunciada, comparando o código binário recebido com o esperado.

Passo 3. Cadastrar a mesma palavra com mais quatro diferentes locutores e executar o passo 2 quando a mesma é pronunciada por um sexto locutor.

Interface USB Flash Drive

Com o auxílio do cabo utilizado na etapa de gravação do

firmware será testada a interface de gravação de informações em um

pendrive. Após isso, os dados gravados serão verificados em um

computador.

Comunicação entre PIC e Interface USB Flash Drive

O microcontrolador PIC irá gravar uma seqüência de bytes

conhecida em um pendrive. Esses dados serão verificados a fim de

identificar erros de sincronismo da serial UART.

Conversor A/D 8-bit

Os valores gerados pelo conversor A/D serão verificados afim

de identificar se o ganho do amplificador está aceitável, ou seja, se o

sinal não está muito atenuado ou saturado.

Microcontrolador

A fim de verificar a taxa de amostragem utilizada pelo TIMER2,

um teste será feito ativando-se um bit de uma das portas de saída para

cada coleta realizada. A variação deste bit será medida em um

osciloscópio. A freqüência do bit deve ser a mesma da amostragem

desejada.



@PUC-PR,2010 Pág. 34 de 48

Protótipo - Plano de Testes e Resultados Para realizar a montagem de um protótipo com módulos separados para teste, estão

descritos abaixo os procedimentos.

Módulo de Reconhecimento de Fala Embarcado

Teste Funcional 1

Equipamentos para montagem

Proto-board.

Microfone.

Teclado matricial numérico (membrana).

Entradas

Áudio do microfone;

Dados do teclado.

Saídas

Barramento com 8 LEDs indicadores.

Descrição do Procedimento Passo-a-passo

I. Montar o circuito seguindo o esquema elétrico especificadono Anexo 2;

II. Enquanto o módulo executa sua rotina principal, um endereço de memória inferior a 20

deve ser selecionado a partir do teclado matricial;

III. O LED indicador verde irá apagar;

IV. Apertar o botão # (TRAIN) no teclado matricial para cadastrar uma palavra na posição de

memória selecionada;

V. O LED indicador verde irá acender novamente;

VI. Falar uma palavra no microfone, com duração inferior a 1,92 segundos;

VII. O LED indicador verde irá piscar uma vez;

VIII. O módulo irá retornar para sua rotina principal de reconhecimento de fala;

IX. Neste momento, o barramento de saída deve estar exibindo números binários referentes às

mensagens de erro (55, 66 ou 77, em decimais);

X. Falar no microfone, entre outras, a palavra cadastrada.

Saídas Esperadas

Se uma palavra cadastrada for falada ao microfone, o módulo deve exibir no barramento de

saída o endereço de memória onde ela foi armazenada/treinada.

Se uma palavra não cadastrada, muito curta ou muito longa for falada ao microfone, o

módulo deve exibir no barramento de saída um dos códigos de erro.

Resultado Obtido



@PUC-PR,2010 Pág. 35 de 48

O teste foi realizado no dia 15/08/2010. Os resultados obtidos foram muito semelhantes às

saídas esperadas, porém, percebemos algumas confusões na detecção de palavras

armazenadas com sílabas tônicas e dicções parecidas.

Conclusões

Devido aos resultados obtidos, a fim de evitar confusões e aumentar a precisão do módulo,

decidimos que a palavra de atenção não será mais utilizada. Ao invés disso, iremos

armazenar todo o banco de memória com apenas duas palavras, as quais, para serem

reconhecidas como comandos, deverão ser pronunciadas duas vezes consecutivas.

As novas palavras escolhidas para os comandos “gravar” e “pausar” ainda estão em

discussão, mas devem ser escolhidas com diferentes tonificações e dicções. A princípio estão

em uso “gravuri” e “senfala”, que significam gravar e inativo respectivamente em esperanto.

Módulo VDIP

Teste Funcional 1


Proto-board;

Cabo TTL-232R-5V;

Computador com Hyperterminal e porta USB.

Entradas

Comandos do Hyperterminal do Windows.

Saídas

Alterações no pendrive.


I. Montar o circuito seguindo o esquema elétrico ilustrado pela figura 12;

II. Conectar o cabo TTL-232-5V ao módulo VDIP conforme as especificações de conexão;

III. Conectar a outra ponta do cabo na USB do computador;

IV. O computador não reconhecerá o dispositivo;

V. Instalar o firmware VDAP a partir do computador conforme instruções fornecidas neste

documento;

VI. Depois de instalado o firmware VDAP fornecido pela FTDI, o computador irá reconhecer o

dispositivo como uma porta serial virtual (VCOM);

VII. Abrir conexão do hyperterminal com o VDIP utilizando baudrate padrão, 9600 bps;

VIII. Conectar um pendrive FAT32 no módulo VDIP;

IX. O módulo irá piscar em sinal de reconhecimento ao pendrive conectado e o hyperterminal

exibirá uma mensagem confirmando a conexão;

X. Enviar comandos da lista de comandos presente do Anexo 3.



@PUC-PR,2010 Pág. 36 de 48

Saídas Esperadas

Alterações no pendrive coerentes aos comandos transmitidos pelo hyperterminal do

Windows.

Resultado Obtido

O teste foi realizado no dia 06/08/2010. Os resultados obtidos são satisfatórios. O módulo

funciona conforme o que se esperava a partir da leitura dos datasheets relacionados ao

mesmo.

Conclusões

A criação e manipulação de arquivos são realizadas de modo transparente ao

microcontrolador, fazendo do VDIP uma solução para o armazenamento de arquivos em

sistemas FAT.

O módulo está pronto para interligação com o microcontrolador.


Teste Funcional 1


Proto-board.

Entradas

Áudio do microfone.

Saídas

Barramento com 8 LEDs.


I. Montar o circuito seguindo o esquema elétrico especificado no Anexo 1;

II. Após montado o circuito conforme o esquema elétrico, conectar o osciloscópio à entrada do

ADC0820;

III. Falar ao microfone e observar a saída.

Saídas Esperadas

Espera-se que o conversor A/D consiga fazer amostragem em período inferior ao da

freqüência de 22,1 kHz.

Os LEDs do barramento de saída devem piscar na freqüência selecionada pelo oscilador

conectado ao pino controlador da leitura (/RD – READ – pino 8).

Os LEDs do barramento de saída devem acender de maneira a ilustrar a linearidade entre a

amplitude do sinal de entrada e a escala binária de 8 bits do barramento de saída.

Resultado Obtido



@PUC-PR,2010 Pág. 37 de 48

O teste foi realizado no dia 23/07/2010. Os resultados obtidos são satisfatórios. Este módulo

está pronto para interligação com o microcontrolador.

Conclusões

O circuito integrado ADC0820 foi é uma boa escolha para quem precisa de velocidade. Suas conversões através da técnica half-flashsão realmente rápidas e possuem pouco erro.



@PUC-PR,2010 Pág. 38 de 48

Considerações Finais Esta alternativa de solução demonstra-se viável. Após a validação, seu potencial

poderá ser reconhecido como um facilitador para o preenchimento do prontuário

eletrônico, sem que o profissional de saúde precise utilizar as mãos. Além disso, a

utilidade desse gravador vai muito além da área médica, podendo ser utilizado em

quaisquer situações em que a questão das “mãos ocupadas” seja um problema.

Conforme o projeto ia sendo desenvolvido, muitas dúvidas e preocupações

foram resolvidas. Percebeu-se também que a exaustiva pesquisa e estudo de

documentações técnicas realizados no início do projeto foram muito importantes

para evitar surpresas desagradáveis ao longo do desenvolvimento.

A aquisição de componentes exigiu muita pesquisa e demandou muito mais

tempo do que o esperado, o que atrasou o início do desenvolvimento do protótipo.

Até mesmo o conversor A/D (ADC0820) precisou ser encomendado de outro

estado. Somente o microcontrolador (16F877A) e o latch octal (74573) puderam ser

adquiridos pessoalmente.

O módulo USB VDIP1, que utiliza o CI VNC1L, demonstrou algumas limitações

como a demora para abrir e fechar arquivos no pendrive, o que tornou as respostas

do gravador um pouco lentas. Além disso, o modulo demonstrou limitações para

gravar caracteres depois de um comando de seek, Impossibilitando a atualização do

cabeçalho do arquivo WAV com valores apropriados.



@PUC-PR,2010 Pág. 39 de 48

Referências

[REF01] FTDI. Vinculum Firmware:User Manual. Version 2.05: Issue Date: 2008-08-04. Disponível em: <http://www.vinculum.com/documents/fwspecs/UM_VinculumFirmware_V205.pdf>. Acesso em: 18 de junho de 2010.

[REF02] FTDI. Vinculum VNC1L Embedded USB Host Controller: IC Datasheet. Version 2.01. Disponível em: <http://www.vinculum.com/documents/datasheets/DS_VNC1L.pdf>. Acesso em: 18 de junho de 2010.

[REF03] FTDI. Vinculum Firmware Tools User Manual. Version: 1.0: Issue Date: 2007-10-30. Disponível em: <http://www.vinculum.com/documents/manuals/Vinculum%20Firmware%20Tools%20User%20Manual%20V1.0%20Rev%203.pdf>.Acesso em 18 de junho de 2010.

[REF04] FTDI. VDIP1 :Vinculum VNC1L Module Datasheet . Version 1.01: Issue Date: 2010-05-31. Disponível em: <http://www.vinculum.com/documents/datasheets/DS_VDIP1.pdf>. Acesso em: 19 de junho de 2010.

[REF05] HMC. HM2007: Speech Recognition Datasheet. Disponível em: <http://www.datasheetcatalog.org/datasheets/2300/499674_DS.pdf>. Acesso em: 16 de junho de 2010.

[REF06] FTDI. TTL-232RG: TTL to USB Serial Converter Generic Cables Datasheet. Version 1.1: Issue Date: 2009-04-02. Disponível em: <http://www.ftdichip.com/Documents/DataSheets/Modules/DS_TTL-232RG_CABLES.pdf>.Acesso em: 20 de junho de 2010.

[REF07] MICROCHIP TECHNOLOGY INC. PIC16F87X: Data Sheet. 2001.Disponível em:<http://ww1.microchip.com/downloads/en/devicedoc/30292c.pdf>. Acesso em 15 de junho de 2010.

[REF08] HYUNDAI SEMICONDUCTOR. HY6264: Datasheet. Disponível em: <http://www.datasheetcatalog.org/datasheet/hynix/HY6264-85.pdf>. Acesso em: 16 de junho de 2010.

[REF09] NATIONAL SEMICONDUCTOR. ADC0820: Datasheet. Disponível em:<http://web.mit.edu/6.115/www/datasheets/ADC0820.pdf>. Acesso em: 17 de junho de 2010.

[REF10] ViaVoice para Windows, Pro USB Edition: Manual do Usuário – Release 9. 1ª edição. Agosto de 2001. Fornecido juntamente com o software.

[REF11] PARACELSO. A CHAVE DA ALQUIMIA. São Paulo: Três, 1973. 416 p.

[REF12]Play a .wav file.Disponível em: <http://java.itags.org/java-newer/75286/>. Acesso em: 23 de maio de 2010.



@PUC-PR,2010 Pág. 40 de 48

Anexos

Anexo 1 – Esquemático A/D Teste



@PUC-PR,2010 Pág. 41 de 48

Anexo 2 – Esquemático HM2007 Teste



@PUC-PR,2010 Pág. 42 de 48

Anexo 3 – Lista de Comandos do VDIP Conjunto de comandos estendidos (mensagem retornada)

Conjunto de comandos curtos (mensagem retornada)

D:\><cr> ><cr>

Em hexadecimal (3E 0D). Disco presente ? Conjunto de comandos

estendidos (mensagem retornada)


SIM D:\><cr> ><cr> Em hexadecimal (3E 0D).

NÃO No Disk<cr> ND<cr> Em hexadecimal (4E 44 0D).

Evento ocorrido Conjunto de comandos estendidos (mensagem retornada)


Um dispositivo USB escravo foi inserido na porta 2

Device Detected P2<cr> DD2<cr>

Em hexa. (44 44 32 0D).

Um dispositivo USB escravo foi removido na porta 2

Device Removed P2<cr> DR2<cr> Em hexa. (44 52 32 0D).

Conjunto de comandos estendidos

Conjunto de comandos curtos (em hexadecimal)

Descrição

SCS<cr> 10 0D Troca para o conjunto de comandos curtos.

ECS<cr> 11 0D Troca para o conjunto de comandos estendidos.

IPA<cr> 90 0D Configura o monitor de comandos para trabalhar com valores em ASCII.

IPH<cr> 91 0D Configura o monitor de comandos para trabalhar com valores binários (Hexadecimal).

SBDdivisor<cr> 1420divisor 0D Troca a taxa de baud rate do monitor de comandos.

FWV<cr> 13 0D Exibe a versão do firmware VNC1L.

E<cr> 45 0D Ecoa o caracter 'E' para efeito de sincronismo. Ou seja, retorna E<cr>.

e <cr> 65 0D Ecoa o caracter 'e' para efeito de

sincronismo. Ou seja, retorna e<cr>. Conjunto de comandos estendidos

Conjunto de comandos curtos (em hexadecimal)

Descrição

DIR<cr> 01 0D Mostra os nomes dos arquivos no diretório (pasta) atual.

DIRNome_arq<cr> 0120Nome_arq 0D Mostra o tamanho do arquivo especificado em Nome_arq em 4 bytes.

CDNome_pasta<cr> 0220Nome_pasta 0D Muda o diretório (pasta) atual.

CD..<cr> 02 20 2E 2E 0D Retorna um nível acima do diretório (pasta)



@PUC-PR,2010 Pág. 43 de 48

atual. RDNome_arq<cr> 0420Nome_arq 0D Lê todo o conteúdo de

um arquivo. DLDNome_pasta<cr> 0520Nome_pasta0D Apaga um diretório

(pasta). MKDNome_pasta<cr> 0620Nome_pasta 0D Cria um diretório

(pasta). MKDNome_pasta DataHora <cr> 0620Nome_pastaDataHor

a 0D Cria um diretório (pasta) e especifica a data e a hora da criação.

DLFNome_arq<cr> 0720Nome_arq 0D Apaga um arquivo. WRFTama_Dword<cr>Dados 08 20Tama_Dword 0D

Dados Escreve uma quantidade de bytes especificado no 1º parâmetro Tama_Dword (4 bytes), no arquivo atualmente aberto pelo comando OPW. Os dados a serem gravados são colocados no 2º parâmetro Dados.

OPWNome_arq<cr> 0920Nome_arq 0D Abre um arquivo para escrita.

OPWNome_arq DataHora<cr> 0920Nome_arq20 DataHora 0D

Abre um arquivo para escrita e, especifica a data e a hora da gravação.

CLFNome_arq<cr> 0A20Nome_arq 0D Fecha o arquivo atualmente aberto.

RDFTama_Dword <cr> 0B 20Tama_Dword 0D Lê um número de bytes especificado no 1º parâmetro Tama_Dword (4 bytes) do arquivo atualmente aberto.

RENAtual_arq Novo_arq<cr> 0C20Atual_arq20 Novo_arq 0D

Nomeia um arquivo. O 1º parâmetro é o nome atual que se deseja mudar. O 2º parâmetro é o novo nome do arquivo.

OPRNome_arq<cr> 0E20Nome_arq 0D Abre um arquivo para leitura.

OPRNome_arq Data<cr> 0E20Nome_arq20 Data 0D Abra um arquivo para leitura, especificando uma data de acesso do arquivo.

SEKOffset_Dword<cr> 28 20Offset_Dword 0D Move o ponteiro de arquivo à posição especificada no parâmetro Offset_Dword (4 bytes).

FS<cr> 12 0D Retorna o espaço livre disponível em discos menor ou igual a 4GB (em 4 bytes).

FSE<cr> 93 0D Retorna o espaço livre disponível em quaisquer



@PUC-PR,2010 Pág. 44 de 48

discos (em 6 bytes). Este comando lê discos grandes (até centenas de TERA Bytes).

IDD<cr> 0F 0D Exibe informação sobre o disco se for menor que 4GB.

IDDE<cr> 94 0D Exibe informação sobre quaisquer tamanhos de discos.

DSN<cr> 2D 0D Exibe o número serial do disco.

DVL<cr> 2E 0D Exibe o nome do disco. DIRT Nome_arq <cr> 2F20Nome_arq 0D Exibe informações

sobre o arquivo especificado, como: data e hora de criação, modificação e acesso.

Conjunto de comandos estendidos (mensagem retornada)


Descrição

Bad Command<cr> BC<cr>

Em hexadecimal: (42 43 0D) Comando não reconhecido.

Command Failed<cr> CF<cr>

Em hexadecimal: (43 46 0D) Nome de arquivo ou diretório não encontrado.

Disk Full<cr> DF<cr>

Em hexadecimal: (44 46 0D) Não há espaço no disco.

Invalid<cr> FI<cr>

Em hexadecimal: (46 49 0D)

Tentou-se abrir um diretório para leitura ou escrita. Tentou-se mudar o diretório atualmente selecionado para um arquivo.

Read Only<cr> RO<cr> Em hexadecimal: (52 4F 0D)

Tentou-se "escrever" num arquivo com atributo "somente leitura".

File Open<cr> FO<cr> Em hexadecimal: (46 4F 0D)

Um arquivo está atualmente aberto para escrita e deve ser fechado antes que esse



@PUC-PR,2010 Pág. 45 de 48

comando possa ser executado.

Dir Not Empty<cr> NE<cr>

Em hexadecimal: (4E 45 0D) Tentou-se apagar um diretório que não está vazio.

No Upgrade<cr> NU<cr> Em hexadecimal: (4B 55 0D)

Arquivo para atualizar o firmware não encontrado no disco.


Conjunto de comandos curtos

Descrição

FWUNome_arq.FTD<cr> 9520Nome_arq.FTD

0D Força a atualização do firmware no VNC1L a partir de um arquivo do tipo .FTD disponível no disco (Pen-drive). Não tentar com arquivos do tipo. ROM que são usados pelo programa VPROG e VPROG_COM.


Conjunto de comandos curtos

Descrição

SUD<cr> Em hexadecimal: (15 0D)

(Suspend disk) - Faz o pen-driver "dormir", mantendo-o em stand-by quando não estiver em uso, para economia de energia.

WKD <cr> Em hexadecimal: (16 0D)

(Wake disk) - "Acorda" o pen-drive, faz ele voltar ao modo on-line, ativo e pronto para uso.

Baud Rate 1º byte

2º Byte 3º Byte

300 0x10 0x27 0x00 600 0x88 0x13 0x00 1200 0xC4 0x09 0x00 2400 0xE2 0x04 0x00 4800 0x71 0x02 0x00 9600 0x38 0x41 0x00 19200 0x9C 0x80 0x00 38400 0x4E 0xC0 0x00 57600 0x34 0xC0 0x00

115200 0x1A 0x00 0x00

230400 0x0D 0x00 0x00

460800 0x06 0x40 0x00

921600 0x03 0x80 0x00

1000000 0x03 0x00 0x00

1500000 0x02 0x00 0x00

2000000 0x01 0x00 0x00

3000000 0x00 0x00 0x00



@PUC-PR,2010 Pág. 46 de 48

Anexo 4 – Cabeçalho WAV



@PUC-PR,2010 Pág. 47 de 48

Anexo 5 – Esquemático Geral



@PUC-PR,2010 Pág. 48 de 48

Anexo 6 – Placa de circuito impresso (bottom view)

Anexo 7 – Placa de circuito impresso (top view)