Maycon Rodrigo Moreira. Projeto de Interface de Telefonia Analógica USB para sistemas VoIP

Transcrição

1 Maycon Rodrigo Moreira Projeto de Interface de Telefonia Analógica USB para sistemas VoIP São José SC Fevereiro/2015

2 Maycon Rodrigo Moreira Projeto de Interface de Telefonia Analógica USB para sistemas VoIP Monografia apresentada à Coordenação do Curso Superior de Tecnologia em Sistemas de Telecomunicações do Instituto Federal de Santa Catarina para a obtenção do diploma de Tecnólogo em Sistemas de Telecomunicações. Orientador: Prof. Roberto de Matos, M. Eng. Co-orientador: Prof. Marcelo Maia Sobral, Dr. Eng. CURSO SUPERIOR DE TECNOLOGIA EM SISTEMAS DE TELECOMUNICAÇÕES INSTITUTO FEDERAL DE SANTA CATARINA São José SC Fevereiro/2015

3 Monografia sob o título Projeto de Interface de Telefonia Analógica USB para sistemas VOIP, defendida por Maycon Rodrigo Moreira e aprovada em 24 de fevereio de 2015, em São José, Santa Catarina, pela banca examinadora assim constituída: Prof. Roberto de Matos, M. Eng. Orientador Prof. Marcelo Maia Sobral, Dr. Coorientador Prof. Eraldo Silveira e Silva, Dr. IFSC Prof. Sandro Carlos Lima, M. Eng. IFSC

4 Olho por olho, e o mundo acabará cego. M. Gandhi

5 Agradecimentos Aquela que tornou tudo isso possível, agraceço imensamente à minha mãe. À toda minha família, que nunca deixou qualquer dificulade me abalar. Agradeço também à paciente e sempre presente minha namorada. Aos meus verdadeiros amigos, que impulsionaram essa tarefa da forma mais prazerosa possível, muito obrigado. Imposível esquecer meu professor e orientador, Roberto de Matos, que mostrou o caminho certo durante todo o trabalho, além da confiança depositada. Meus sinceros agradecimentos também ao meu professor Marcelo Maia Sobral, que me fez crer neste projeto. Agradeço a todas as outras pessoas que não foram citadas aqui. Muito obrigado a todos.

6 Resumo Atualmente, o uso da Internet para transmitir voz está consolidado, seja nas comunicações utilizando puramente voz sobre o protocolo da Internet (VoIP) ou mascarado por sistemas que fazem a conversão entre a telefonia analógica e VoIP. No segundo cenário, um dos grandes atores são os sistemas que fazem a integração dos sistemas analógicos com as centrais telefônicas IP. Esses sistemas podem ser equipamentos proprietários ou computadores, de capacidade computacional elevada, equipados de dispositivos com interfaces analógicas, os quais são interligados via os complexos barramentos internos. Tudo isso sugere que esses equipamentos fiquem dedicados à função de gateway de telefonia, atendendo de forma satisfatória empresas de todos os portes. Entretanto, para uso domiciliar e em pequenos escritórios o custo para instalação de tais equipamentos pode ser proibitivo, não permitindo que esse seguimento faça o uso dos diversos serviços implementados em software nas centrais telefônicas IP. Dessa forma, a implementação de dispositivos que disponibilizem interfaces analógicas via o barramento USB, torna possível a implementação de gateways telefônicos em sistemas compartilhados, como notebook pessoal, ou em sistemas de baixo poder computacional e custo reduzido, como por exemplo, a placa Raspberry Pi 1. A proposta deste trabalho é estudar os conceitos computacionais e de telefonia necessários para implementar um dispositivo com interface USB que permita a integração entre a rede comutada de telefonia brasileira e rede IP, de forma a permitir que mesmo sistemas simples, com uma porta USB disponível, sejam transformados em uma central telefônica IP de pequeno porte. 1 Raspberry Pi é um computador do tamanho de um cartão de crédito. Todo o hardware é integrado numa única placa com custo de US$35

7 Abstract Currently, the use of the Internet to transmit voice is consolidated, either in communications using purely voice over Internet protocol (VoIP) or masked by systems that make the conversion between analog and VoIP telephony. In the second scenario, the big actors are the systems that make the integration of analog systems to IP telephone exchanges. The systems may be proprietary equipment or computers, high computing power, equipped devices with analog interfaces, which are interconnected via the complex internal buses. All this suggests that these devices remain dedicated to the gateway function telephony, given satisfactorily companies of all sizes. However, for home use and small office the cost for installation of such equipment may be prohibitive, not allowing that follow make use of the various services implemented in software in the IP telephone exchanges. Thus, the implementation of devices that provide analog interfaces via a USB bus, makes possible the implementation of telephone gateways shared systems such as notebook personal, or low computational power and low cost systems, such as plate Raspberry Pi. The purpose of this study is to assess computing and telephony concepts necessary to implement a device with USB interface allowing integration between the switched network of brazilian and IP telephony network in order to allow both simple systems with an available USB port, be transformed into a small telephone exchange IP

8 Sumário Lista de Figuras Lista de Tabelas 1 Introdução p Objetivos p Organização do texto p Fundamentação teórica p Conceitos de telefonia p Sinalização acústica p Sinalização de discagem p Alimentação do circuito p Interfaces FXO e FXS p Digitalização da voz p Processo de amostragem p Processo de quantização p Processo de codificação p Rede de telefonia pública integrada à rede IP p Gateway p Asterisk p Digium Asterisk Hardware Device Interface - (DAHDI) p Subscriber Line Interface Circuit - (SLIC) p. 24

9 2.4.1 SLIC Microsemi p SLIC Silicon Labs p Interface Universal Serial Bus p Métodos de transferências p Método Isochronous p Conclusões p Estudo dos componentes e kits de desenvolvimento p Estrutura do SLIC si p SPI p PCM p Kits de desenvolvimento si p Estrutura p Software utilizados p Proslic Application Programming Interface - (API) p Estrutura do LPC p Cortex-M p Serial Peripheral Interface p Interface USB p Outros periféricos p Kit de desenvolvimento LPC p Estrutura p Biblioteca NXP p Projeto MBED p Discussão p Conclusão p. 63

10 4 Arquitetura e Projeto Lógico p Arquitetura dos Sistemas p Sistema Básico p Sistema de utilização de recursos externos p Sistema de utilização de compartilhamento de recursos p Projeto Lógico do Hardware p Elaboração do projeto lógico p Conclusão p Experimento p Experimentos Primeira Etapa - Placa Filha no Modo Hospedeiro p Experimento 1 - Utilização do software ProSLIC Voice GUI p Experimentos Segunda Etapa - Placa Filha Modo Standalone p Experimento 1 - Avaliação da interface USB p Experimento 2 - Avaliação da interface SPI p Experimento 3 - Avaliação do barramento PCM p Conclusão p Conclusões p Trabalhos Futuros p. 85 Referências Bibliográficas p. 86 Anexo A -- Representante da Microsemi p. 88

11 Lista de Figuras 2.1 Exemplo de utilização da interface FXO (3CX, 2014) p Exemplo de utilização da interface FXS (3CX, 2014) p Processo de digitalização da voz (PINHEIRO, 2005) p Interligação entre PSTN e telefonia VoIP (LAMARAO; ALVAO, 2005).... p Arquitetura Asterisk (CUNHA et al., 2012) p Família de SLICs Microsemi (MICROSEMI, 2015) p Família de SLICs Silicon Laboratories (Figura cedida por cortesia pela Silicon Labs p Arquitetura lógica da conexão USB (SASAKI; CAIXETA, 2006) p Diagrama de blocos do si32919 e interligação por método capacitivo com o CI si32919 (Figura cedida por cortesia pela Silicon Labs p Escrita no registrador com dado de 8 bits (Figura cedida por cortesia pela Silicon Labs p leitura no registrador com dado de 8 bits (Figura cedida por cortesia pela Silicon Labs p Escrita na RAM com dado de 16 bits (Figura cedida por cortesia pela Silicon Labs p Leitura na RAM com dado de 16 bits (Figura cedida por cortesia pela Silicon Labs p Exemplo dos sinais PCLK, FSYNC, DRXa e DTXa de um timeslot, utilizando o modo Short FSYNC (Figura cedida por cortesia pela Silicon Labs p. 37

12 3.7 Exemplo dos sinais PCLK, FSYNC, DRXa e DTXa de um timeslot, utilizando o modo Long FSYNC (Figura cedida por cortesia pela Silicon Labs p Kit de desenvolvimento da Silicon Laboratories VMB2 REV p Kit de desenvolvimento da Silicon Laboratories Si32179BFB11SL0EVB... p Software ProSLIC Voice GUI p Software Proslic api config tool p Arquitetura Proslic API (Figura cedida por cortesia pela Silicon Labs p Arquitetura Proslic API (Figura cedida por cortesia pela Silicon Labs p Estrutura básica da CMSIS (MIYADAIRA, 2012) p Diagrama de bloco do ARM Cortex-M3 (NXP, 2015a) p Mapa de memória do processador ARM Cortex-M3 (MIYADAIRA, 2012).. p Barramento SPI (MIYADAIRA, 2012) p Transferência de um dado de 8 bits (MIYADAIRA, 2012) p Barramento USB para o modo device (NXP, 2015b) p Kit de desenvolvimento MBED LPC-1768 (NXP, 2015a) p Ambiente MBED, tela principal p Ambiente de escolha da plataforma p Arquitetura sistema Básico p Arquitetura do sistema de utilização de recursos externos p Arquitetura sistema de utilização de compartilhamento de recursos p Diagrama do sistema proposto pelo projeto p Projeto lógico do dispositivo de telefonia p Configuração física do cenário para o experimento da placa filha no modo hospedeiro p Reprodução de um segundo de áudio enviado via USB p Sinais SCLK (canal 1) e SS (canal 2) p. 75

13 5.4 Escrita REG 14. Sinais SCLK (canal 1) e MOSI (canal 2) p Escrita REG 14. Sinais SCLK (canal 1) e MOSI (canal 2) ampliados p Escrita REG 14. Sinais SCLK (canal 1) e MISO (canal 2) p Leitura REG 3. Sinais SCLK (canal 1) e MOSI (canal 2) p Leitura REG 3. Sinais SCLK (canal 1) e MOSI (canal 2) ampliados p Leitura REG 3. Sinais SCLK (canal 1) e MISO(canal 2) p Leitura REG 3. Sinais SCLK (canal 1) e MISO (canal 2) ampliados p Configuração física do cenário para a avaliação do barramento PCM p Sinais PCLK (canal 1) e FSYNC (canal 2) p Sinais PCLK (canal 1) e FSYNC (canal 2), ampliados p Fluxograma de avaliação para o barramento PCM p Sinai PCLK (canal 1) e sinal FSYNC (canal 2) com 16KHz p. 82 A.1 Contato representante da Microsemi p. 89

14 Lista de Tabelas 2.1 Conjunto de frequências DTMF p Byte CONTROL (Tabela cedida por cortesia pela Silicon Labs p Registrador MSTRSTAT (Tabela cedida por cortesia pela Silicon Labs p. 36

15 14 1 Introdução Vários serviços hoje fazem uso da rede de computadores, tais como os de segurança eletrônica e controle de acesso. Com a telefonia não é diferente. Usar a internet para efetuar chamadas locais ou chamadas de longa distância é uma realidade. O que torna isso possível é o uso do VoIP. Esse acrônimo já é de uso cotidiano, assim como o termo telefonia IP. VoIP é o acrônimo em inglês para Voice Over Internet Protocol (voz sobre o protocolo internet), tecnologia que usa a rede mundial de computadores (comutação de pacotes) para transmitir voz. Essa tecnologia foi desenvolvida ao longo da década de 1990, nascendo de duas vertentes: a digitalização do tráfego entre as centrais telefônicas e para a comunicação de voz pela Internet, possibilitando custos menores em ligações de longa distância. Entretanto, a Rede Pública de Telefonia Comutada (PSTN, do inglês Public Switched Telephone Network) ainda tem um papel muito forte nas comunicações de voz. Dessa forma, é necessário o uso de equipamentos para integração entre os sistemas VoIP e a telefonia convencional (ARAÚJO; BRAGA, 2009). O responsável por essa integração é o gateway que executa a conversão de mídia em tempo real (sinal analógico para sinal digital) e a conversão de sinalização para as chamadas telefônicas que entram e saem da rede VoIP (LAMARAO; AL- VAO, 2005). Para tal integração os gateways devem prover interfaces padronizadas FXO (do inglês Foreign Exchange Office) e FXS (do inglês Foreign Exchange Station). FXS e FXO são interfaces utilizadas nos sistemas telefônios analógicos. Mais detalhadamente, a FXS é a interface que fornece os padrões elétricos e lógicos de uma linha telefônica, responsável por alimentar o circuito, verificar a ocupação do sistema, interpretar os dígitos providos pelo telefone e gerar corrente de toque para o sistema. Já a FXO é a interface que recebe a linha analógica. Essa interface é responsável por inserir uma carga (resistência elétrica) na via de transmissão (um par de fios), a fim de circular corrente no circuito e informar ao terminal remoto que foi solicitada a ocupação dele. A interface FXO também é responsável por interpretar a corrente de toque que o sistema remoto envia, com o objetivo de indicar que uma ligação está sendo solicitada.

16 1.1 Objetivos 15 Uma opção muito comum para a criação de gateways VoIP é o uso de software de código livre, como por exemplo, o Asterisk (CUNHA et al., 2012), que implementa os recursos encontrados em uma central telefônica convencional, utilizando a arquitetura de um computador pessoal (PC), sem a necessidade de grandes sistemas proprietários. Entretanto, para habilitar a funcionalidade de gateway é necessário o uso de placas providas com portas FXO e FXS, as quais normalmente utilizam os barramentos internos do PC por possuírem várias portas e ter seu foco no mercado corporativo. Essa mistura de software livre, uso da arquitetura estabelecida do PC e diminuição dos altos custos de telefonia fizeram o mercado corporativo impulsionar comercialmente a evolução da telefonia IP. Essa evolução tornou as centrais telefônicas em software com serviços modulares, escaláveis e altamente atrativos, inclusive para uso no seguimento residencial e de pequenos escritórios (SOHO, do inglês Small Office and Home office ). Entretanto o hardware ainda é muito focado para soluções corporativas, o que encarece e dificulta as soluções nesse seguimento de mercado. Dessa forma, um dispositivo que contenha interfaces FXS e FXO e integre a central telefônica/gateway implementada em software via USB, viabilizaria o uso de soluções VoIP nas residências e pequenos escritórios. Considerando complexo e extenso o estudo, projeto e implementação do hardware, firmware e drivers para uma interface de telefonia analógica USB, provida de uma FXO e uma FXS, decidiu-se limitar o trabalho sem fugir do contexto discutido. O trabalho atual almeja servir de base para guiar uma futura implementação completa e compreende o estudo e avaliação dos componentes comerciais e suas placas de desenvolvimento, uma proposta de projeto lógico de hardware e implementações de experimentos que validam o projeto proposto. 1.1 Objetivos O objetivo deste trabalho é o estudo dos componentes comerciais no intuito de projetar uma interface de telefonia USB com um par de portas analógicas, uma FXO e uma FXS, para integração futura com uma central telefônica/gateway VoIP implementada em software. Como objetivos específicos define-se: - Estudo e seleção de componentes comerciais para as interfaces analógicas; - Estudo e avaliação das placas de desenvolvimento; - Projeto lógico de hardware;

17 1.2 Organização do texto 16 - Implementação de blocos de firmware para validar o projeto lógico. 1.2 Organização do texto O texto está organizado da seguinte forma: no capítulo 2 é apresentada a fundamentação teórica do trabalho. Esse capítulo traz os conceitos necessários para o desenvolvimento de sistemas de telefonia analógica/digital. Em seguida, é feita uma abordagem sobre dispositivos comerciais que implementam interfaces FXS e FXO. O capítulo 3 abordará o estudo de dispositivos específicos, como o circuito integrado si32179 e o LPC-1768, como forma de avaliar se suas características atendem às necessidades de desenvolvimento de um dispositivo de telefonia. Ainda nesse capítulo, serão avaliadas as placas usadas nos testes e o desenvolvimento para o projeto. O capítulo 4 apresenta a descrição do projeto do sistema. Esse capítulo visa demonstrar a arquitetura geral do sistema, alguns cenários de uso e o projeto lógico do sistema proposto. No capítulo 5 serão descritos os experimentos feitos com os componentes para averiguar a possibilidade de sua utilização na proposta. Ao final do capítulo apresenta-se uma análise de viabilidade para utilização dos componentes para o sistema proposto. Por fim, no capítulo 6 são apresentadas as conclusões e possibilidades de trabalhos futuros.

18 17 2 Fundamentação teórica O escopo deste capítulo é a apresentação das técnicas utilizadas para a criação da interface de telefonia. Assim, passa-se a discorrer sobre os fundamentos teóricos necessários para alcançar os objetivos. 2.1 Conceitos de telefonia Para que um sistema opere conforme as necessidades dos usuários, é necessário que sejam estabelecidos padrões de comunicação, implementação e operação. No âmbito da telefonia brasileira, os padrões são definidos pela Agência Nacional de Telecomunicações (ANATEL). Para a operação básica do sistema telefônico, é tomado como exemplos a sinalização acústica, a sinalização de discagem e a alimentação do circuito Sinalização acústica A sinalização acústica adotada no Brasil é especificada pela prática Telebrás STP [Tel96a]. Em relação à sinalização acústica, valem as seguintes definições e características (JESZENSKY, 2004): Tom de discar (TD) é o sinal enviado ao terminal chamador após a ocupação do circuito de linha associado, para que seja iniciada a marcação dos algarismos do telefone do assinante chamado ou o acesso à programação de um serviço suplementar. A frequência utilizada deve ser de (425 ± 25) Hz. O regime de emissão do tom de discar deve ser contínuo. Tom de ocupado (TO) é o sinal enviado ao terminal chamador indicando que o terminal chamado está na condição de ocupado. O sinal deve ser enviado diretamente pelo circuito de linha do assinante. A frequência utilizada deve ser (425 ± 25) Hz. O TO deve ser um

19 2.1 Conceitos de telefonia 18 sinal com a seguinte cadência: período de tom de 250 ms ± 10%; período de silêncio de 250 ms ± 10 %. Corrente de toque (CT) é o sinal enviado ao aparelho telefônico do assinante chamado, indicando que há uma ligação dirigida a ele. A frequência utilizada é de (25 ± 2,5) Hz. A forma de onda desse sinal deve ser senoidal, tolerando-se uma distorção de até 15% para geradores dinâmicos e até 10% pra geradores estáticos, medida na saída do equipamento gerador de CT. A cadência da corrente de toque deve ser: período de toque de ms ± 10%; período de silêncio de ms ± 10%. A CT deve ser interrompida tão logo o assinante chamado atenda, de forma que ele não ouça através da cápsula receptora. Tolera-se um atraso máximo de 300 ms em relação ao instante de atendimento. A tensão do sinal, sem carga, em regime de emissão contínua, na saída do respectivo gerador, deve ser de (80 ± 10) Vrms, sobreposta a um potencial de (-48 ± 4) Vdc Sinalização de discagem Os sistemas públicos de telefonia fazem uso de um esquema de sinalização denominado dual tone multi frequency (DTMF). Esses sinais são utilizados para codificar os dígitos de discagem de um aparelho telefônico em sinais analógicos, de forma que possam ser transmitidos por meio de uma rede de telefonia até uma central, onde os sinais são decodificados e tratados. O sistema DTMF utiliza oito frequências diferentes, as quais são combinadas e transmitidas em pares, podendo assim representar dezesseis números, símbolos ou letras distintas. As frequências DTMF são mostradas na tabela 2.1. Tabela 2.1: Conjunto de frequências DTMF. Hz A B C 941 * 0 # D Alimentação do circuito O fornecimento de energia para o circuito telefônico é proveniente do sistema de comutação da operadora que fornece o link. O nível deve ser medido em regime de emissão contínua nos pontos indicados com tensão nominal de alimentação de -48 VCC, em quaisquer condições de tráfego a que se submeta a central (ANATEL, 1996).

20 2.1 Conceitos de telefonia Interfaces FXO e FXS Foreign Exchange Office (FXO) é uma interface que recebe sinalização da operadora (STFC) ou de uma central telefônica PABX. É o plugue do aparelho telefônico que deve ser conectado à interface Foreign Exchange Station (FXS) para funcionar. Portanto, todo telefone ou fax a possui. A interface FXS, tal como um plugue fêmea, é a que permite o acesso do telefone à rede da operadora de telefonia. As interfaces FXO e FXS são compostas por dois fios (o par telefônico ou par metálico ou, ainda, linha telefônica) e conectores, usualmente no padrão RJ- 11. Essa linha segue, através de um cabo telefônico ou outro tipo de meio de transmissão, até a central telefônica, responsável por enviar os tons (linha, ocupado etc.), energizar o aparelho telefônico, reconhecer os dígitos discados e enviar e receber a voz e demais sons compreendidos pelo espectro sonoro entre 300 Hz a Hz (CUNHA et al., 2012). FXO A interface FXO foi projetada para receber um ramal de um PABX externo. Opera como um aparelho telefônico analógico quando uma ligação chega a ele, oriunda da rede VoIP. É capaz de reagir a correntes de toque e reconhecer chamadas originadas do PABX (GALRÃO, 2007). A figura 2.1 ilustra um exemplo de utilização da porta FXO. Figura 2.1: Exemplo de utilização da interface FXO (3CX, 2014). FXS Já a interface FXS foi projetada para ser diretamente ligada a um aparelho telefônico analógico e, então, a qualquer posição de tronco analógico de um PABX. Opera como uma central telefônica, fornecendo alimentação, tons e reconhecendo discagens DTMF. Gera toque

21 2.2 Digitalização da voz 20 de campainha quando uma ligação vinda da rede chega a ele (GALRÃO, 2007). A figura 2.2 ilustra um exemplo de utilização da porta FXS. Figura 2.2: Exemplo de utilização da interface FXS (3CX, 2014). 2.2 Digitalização da voz A digitalização da voz foi projetada pelo Bell System na década de 50. O projeto original da digitalização da voz foi o empacotamento de dois ou mais canais de áudio para ser transmitido em um par de fios (PINHEIRO, 2005). O processo de digitalização da voz é ilustrado na figura 2.3. A conversão de voz analógica para sinal digital passa por três passos: Processo de amostragem; Processo de quantização; e Processo de codificação. Figura 2.3: Processo de digitalização da voz (PINHEIRO, 2005) Processo de amostragem A amostragem do sinal é feita por intervalos de tempos periódicos. Quanto maior a quantidade de amostras, mais fiel será a reprodução do sinal na decodificação. Por outro lado, a maior

22 2.3 Rede de telefonia pública integrada à rede IP 21 quantidade de amostras exigirá uma maior largura de banda para transmissão do sinal codificado. Para chegar a uma quantidade de amostras que não degradasse a qualidade da voz e nem usasse muita largura de banda, foi usado o Teorema de Nyquist. O referido teorema especifica que, para que um sinal arbitrário transmitido seja reconstruído pelo receptor, é necessário que a quantidade de amostras por segundo seja o dobro da maior frequência do sinal transmitido. Apesar de a voz humana ter o espectro de frequência de 20 Hz a 20 KHz, para uma boa reprodução em canais telefônicos foi admitida uma faixa de 300 a Hz. Arredondando para cima, a maior frequência do sinal de voz para canal telefônico então é de Hz. A saída da amostragem é um sinal modulado em amplitude de sinal Processo de quantização É a classificação das amplitudes das amostras em uma escala de valores para que eles sejam transmitidos. Há duas formas de fazer a quantização. A primeira é a forma linear, em que toda a escala tem valores e tamanhos iguais. A outra maneira é a forma logarítmica, em que a escala tem valores diferentes, comportando-se de forma semelhante ao ouvido humano Processo de codificação É a transformação dos valores decimais criados pela quantização em valores binários para serem transmitidos em um canal digital. 2.3 Rede de telefonia pública integrada à rede IP Apesar de a PSTN estabelecer chamadas de voz entre dois terminais de forma eficiente, há uma grande demanda por novas funcionalidades e de menor custo. Isso está levando inúmeras empresas a mudarem seus sistemas de telefonia tradicionais para uma tecnologia baseada em comutação de pacotes, o VoIP (CUNHA et al., 2012). Com a intervenção do VoIP é possível, em residências, escritórios ou pequenas empresas, fazer uso de novas facilidades. Pode-se imaginar equipamentos interagindo com atuais e estáticos PABXs disponibilizando serviços que estes não agregavam. Chamadas telefônicas de longa distância feitas a custo de chamadas locais, utilização remota (acesso à distância) das linhas telefônicas da PSTN e fácil implementação de correio de voz são exemplos dessa integração. Um equipamento crucial para que tal integração ocorra é o gateway. Este equipamento comumente utiliza o software livre Asterisk. Um exemplo de como a rede PSTN e a telefonia

23 2.3 Rede de telefonia pública integrada à rede IP 22 IP encontram-se atualmente pode ser visto na figura 2.4. Figura 2.4: Interligação entre PSTN e telefonia VoIP (LAMARAO; ALVAO, 2005) Gateway Gateway (GW) é a funcionalidade responsável pela interoperabilidade entre a rede VoIP e a rede de telefonia pública. Para que o gateway execute sua função, ele necessita de interfaces que tratem toda a sinalização da PSTN e também a digitalização da voz. Quando implementado em um Personal Computer (PC), geralmente são utilizadas interfaces FXO, FXS, E1 ou T1 em placas com interface Peripheral Component Interconnect (PCI) para integração com a rede de telefonia tradicional. O Asterisk é um software muito requisitado para implementar a função de gateway (CUNHA et al., 2012) Asterisk Asterisk é um software livre que disponibiliza o serviço de um PABX completo utilizando tecnologia VoIP. Inicialmente ele foi desenvolvido pela empresa Digium, mas atualmente é mantido por meio de contribuições de desenvolvedores e usuários espalhados pelo mundo. O Asterisk permite a utilização de todas as funções das centrais telefônicas convencionais, como

24 2.3 Rede de telefonia pública integrada à rede IP 23 unidades de resposta automática (URAs), correio de voz, conferência, distribuição automática de chamadas, entre outras. A arquitetura do Asterisk é apresentada na figura 2.5, que exemplifica algumas aplicações disponibilizadas ao usuário. Os canais consistem em módulos de interfaces de comunicação lógica (CUNHA et al., 2012). Figura 2.5: Arquitetura Asterisk (CUNHA et al., 2012) Digium Asterisk Hardware Device Interface - (DAHDI) O Asterisk Hardware Device Interface (DAHDI) é um driver utilizado para controlar, originalmente, as placas de interface da Digium (CUNHA et al., 2012). A conexão estabelecida por meio do DAHDI é denominada Span e utiliza o protocolo TDM over Ethernet) (TDMoE) para realizar transferência de dados (CUNHA et al., 2012). O DAHDI é tanto um pacote de módulos para o kernel (drivers) quanto um middleware que faz a comunicação do channel driver do Asterisk com os drivers das placas de hardware. Portanto, ao instalar o pacote DAHDI, são instalados todos os módulos das placas compatíveis com essa arquitetura e um processo (middleware) que faz a comunicação dos componentes. Resumindo, o DAHDI é responsável por toda a comunicação entre a aplicação (channel driver) e o hardware de telefonia (interface FXO e FXS).

25 2.4 Subscriber Line Interface Circuit - (SLIC) Subscriber Line Interface Circuit - (SLIC) Subscriber Line Interface Circuit (SLIC) é uma interface que fornece um circuito integrado especialista em tratar os sinais de telefonia. É uma denominação comercial e muito utilizado no projeto de sistema telefônicos. O circuito é responsável por fazer a conversão AD/DA seguindo padrões de codificação ITU. O SLIC possui integrado a ele um processador digital de sinais (DSP), que após converter o sinal analógico para digital, manipula e trata essas informações para serem disponibilizadas a um hardware externo. Esse processo permite que as amostras dos sinais sejam manipuladas para serem utilizadas em aplicações específicas. São funções básicas de um SLIC: Fazer a conversão analógica/digital da voz; Gerar corrente DC para o circuito (FXS); Gerar corrente de toque ring (FXS); Gerar tons de progressão de chamadas (FXS); Gerar impedância para sinalização de ocupação do circuito (FXO); Interpretar corrente de toque (FXO); e Gerar DTMF para sinalização do número de destino (FXO). No mercado podemos encontrar alguns fabricantes para esse tipo de dispositivo, com variadas funções e desempenhos, as quais devem ser observadas para cada tipo de aplicação. Dois fabricantes que se destacam nesse tipo de tecnologia, a Silicon Laboratories 1 e a Microsemi SLIC Microsemi O VE8911 é um SLIC altamente integrado e de baixo custo, com uma interface FXS e uma interface FXO. É uma solução otimizada para gateways VoIP residenciais, tais como modems DSL com interface de telefone, set-top boxes e adaptadores de terminal analógico. No lado digital, o chipset VE8911 fornece uma interface padrão MPI e uma interface PCM para um processador VoIP

26 2.4 Subscriber Line Interface Circuit - (SLIC) 25 O VE8911, juntamente com a VoicePath API-II (VP API-II), oferece aos desenvolvedores de softwares recursos de programação e controle do hardware. O código VP API-II-C é usado como abstração dos dispositivos para o aplicativo, proporcionando funções para controlar, supervisionar e testar um conjunto de linhas de assinantes. O bloco de funções do VE8911 pode ser vista na figura 2.6 Figura 2.6: Família de SLICs Microsemi (MICROSEMI, 2015) SLIC Silicon Labs A Silicon Laboratories possui a família de SLICs de baixo custo, denominada ProSLIC si3217x. Essa família oferece uma completa interface de telefonia analógica, ideal para empresas, escritórios e aplicações em centrais. A ProSLIC si3217x pode ser facilmente configurada com requisitos específicos de cada país, tais como impedância AC, frequência, cadência e de formato de onda do ring, usando um design de hardware único. Todos os parâmetros do SLIC são configuráveis usando registradores de configuração acessíveis por barramento serial digital. API Silicon Labs acelera e simplifica o desenvolvimento do software de controle com um conjunto de funções prontas e comuns a toda família ProSLIC. Alguns dispositivos da família podem suportar uma interface FXS e uma interface FXO integrada. O diagrama de blocos da família ProSLIC si3217x pode ser vista na figura 2.7.

27 2.5 Interface Universal Serial Bus 26 Figura 2.7: Família de SLICs Silicon Laboratories (Figura cedida por cortesia pela Silicon Labs Interface Universal Serial Bus O padrão Universal Serial Bus (USB) foi desenvolvido sob a óptica do conceito plug and play (expressão inglesa para ligue e divirta-se), que permite a conexão de periféricos sem a necessidade de desligar o computador. Além disso, a USB facilitou a implementação de novos dispositivos, minimizando o trabalho em relação ao suporte por parte dos sistemas operacionais (OLIVEIRA; ZANATTA; SANTOS, 2007). A primeira versão foi a 1.0, com velocidade de 1,5 Mbps (low-speed). Logo em seguida foi concebida a versão 1.1, com velocidade que varia de 1,5 Mbps a 12 Mbps. Essa versão é conhecida como full-speed. No final de 2000 foi lançada a versão 2.0 (high-speed), compatível com as versões anteriores, mas com alguns aperfeiçoamentos que vão desde a topologia à velocidade de tráfego de dados, chegando ao extremo de 480 Mbps, equivalente a cerca de 60 MBps (60 milhões de bytes por segundo) (OLIVEIRA; ZANATTA; SANTOS, 2007). Segundo a estrutura criada para o padrão USB, um dispositivo host consome ou cria dados para aplicações distintas (SASAKI; CAIXETA, 2006). Todos os dispositivos USB têm de ter o mesmo padrão para fazer a tradução dos dados consumidos. Como é possível uma grande variedade de aplicações, foi preciso ter uma estrutura lógica bem definida para os dados criados ou consumidos. Na figura 2.8, temos um exemplo da arquitetura lógica da conexão USB Métodos de transferências O padrão USB é um barramento compartilhado e que pode ser utilizado, simultaneamente, por vários dispositivos. O driver cliente comunica ao driver USB que deseja efetuar uma transferência do/para o seu dispositivo correspondente. Algumas dessas transferências consistem em

28 2.5 Interface Universal Serial Bus 27 Figura 2.8: Arquitetura lógica da conexão USB (SASAKI; CAIXETA, 2006).

29 2.5 Interface Universal Serial Bus 28 blocos maiores de dados, os quais precisam ser quebrados em várias transações. A transferência de dados é feita em intervalos regulares denominados frames. Um frame é composto de uma ou mais transações que devem ser executadas dentro de 1 ms (ZUQUIM, 2007). Abaixo, são mostrados os métodos de transferências. Control - Método de transferência utilizado pelo host para fazer requisições ao dispositivo. É nesse tipo de transferência que é feita a leitura dos descritores, por exemplo. Nele acontece também a verificação de erros. Transferências do tipo Isochronous e Interrupt têm uma maior prioridade em relação às outras quando distribuídas em um frame. Transferências do tipo Bulk só serão executadas quando houver disponibilidade de espaço dentro de um frame (ZUQUIM, 2007). Bulk - Esse método de transferência é utilizado para blocos maiores de dados, para o qual a taxa de transferência não é fator relevante. O que é importante nesse tipo de transferência é o grau de correção com o qual os dados chegarão ao destino, sendo indispensável a verificação de erros. Possui um payload de dados de 8, 16, 32 ou 64 bytes por frame. A largura de banda disponível para esse tipo de transferência varia de acordo com a disponibilidade. Um bom exemplo de um dispositivo que utiliza esse tipo de transferência são as impressoras (ZUQUIM, 2007). Interrupt - O objetivo desse método de transferência é verificar se algum dispositivo necessita transferir algum dado para o host. Esse processo ocorre de tempos em tempos e o intervalo é denominado Polling Interval. Dessa forma, o host sonda os devices e, caso seja necessário, a transferência é feita. Nesse método também é realizada a verificação de erros. Possui um payload de dados de 64 bytes/frame. Exemplo de dispositivos que utilizam este tipo de transferência são o teclado e o mouse (ZUQUIM, 2007). Isochronous - Taxa de transmissão de dados constante. O foco desse método de transferência é garantir a entrega dos dados dentro de um determinado tempo, sendo dispensável a verificação de erros. Não pode ocorrer distorção no envio dos dados e o sincronismo é o foco deste tipo de transferência. Portanto, só é suportada por dispositivos de alta velocidade (12 Mb/s). É unidirecional e possui um payload de dados de 1023 bytes/frame. Exemplos de dispositivos que utilizam esse tipo de transferência são microfones e demais dispositivos de som de uma maneira geral (ZUQUIM, 2007).

30 2.6 Conclusões Método Isochronous Para aplicações nas quais é necessário um fluxo constante de dados, seja vídeo ou áudio, é interessante que não haja retransmissão destes. Nas interfaces de hardware em que serão implementadas as portas FXO e FXS, o método de transferência utilizado é o Isochronous. Por se tratar de um método de transferência sem transações de pacotes de handshake, ele se torna o método mais apropriado para a troca de streaming de áudio, pois um dado atrasado é tão inútil quanto dado nenhum nesse tipo de aplicação, e para aplicações de streaming em tempo real, retransmissões não são aceitas. 2.6 Conclusões Neste capítulo foram explorados conceitos e fundamentos, que servem de base para avaliar os componentes e as tecnologias associadas ao desenvolvimento de um dispositivo de telefonia. Em particular, um estudo sobre os conceitos de telefonia, a fim de avaliar possíveis dispositivos especialistas nos padrões de telefonia utilizados no Brasil, de forma que esses atendam aos requisitos necessários. Após os estudos sobre os conceitos de telefonia, uma pesquisa de dispositivos comerciais se fez necessária. Tal pesquisa teve foco em duas grandes fabricantes de semicondutores nesse tipo dispositivo, a Silicon Laboratories e a Microsemi. Outro estudo, porém mais brando, foi sobre a forma com que a rede PSTN interage com a rede mundial de computadores. Esse estudo pode dar uma visão de como o dispositivo de telefonia poderia servir às aplicações do gateway de telefonia, que no futuro poderá ser utilizado em uma solução SOHO. Também foi abordado alguns conceitos sobre a interface USB e seus métodos de transferências. Sobre a interface USB, foi dado destaque ao método de transferências isochronous que, potencialmente, pode vir ser o método de transferência mais apropriado. No capítulo seguinte serão apresentados os estudos efetuados nos kits e softwares escolhidos, os quais serão utilizados para um futuro dispositivo de interface de telefonia.

31 30 3 Estudo dos componentes e kits de desenvolvimento O presente capítulo tem a finalidade de apresentar os estudos realizados nos componentes selecionados nesse trabalho para o projeto da interface de telefonia USB. Para um melhor entendimento, primeiro foi abordado o SLIC si32179 da Silicon Laboratories, que implementa as interfaces FXO e FXS, detalhando seu funcionamento e barramentos. Na sequência, o capítulo incluí detalhes sobre os kits de desenvolvimento VMB2 REV 2.0 e Si32179BFB11SL0EVB e, também, os softwares utilizados para explorar o seus funcionamentos. Essas ferramentas, formadas pelos kits e pacote de softwares, tem a finalidade de facilitar o estudo e desenvolvimento do SLIC si32179, tornando mais ágil o desenvolvimento de novos produtos. O capítulo aborda ainda o componente LPC-1768 da NXP, componente selecionado para fazer o controle do SLIC e a interface USB com o sistema principal. Além disso, os estudos efetuados no kit de desenvolvimento para o LPC-1768 é relatado. Por fim, há uma discussão sobre os estudos dos dispositivos, kits e softwares selecionados, para compreensão dos motivos que levaram a cada seleção. 3.1 Estrutura do SLIC si32179 O si32179 pertence a famíla si3217x de SLICs da fabricante Silicon Laboratories que implementam uma interface FXS completa. Essa família traz uma solução completa em acordo com as especificações ITU e European Telecommunications Standards Institute (ETSI). Algumas peças da família de produtos também implementam a tecnologia de isolamento capacitivo patenteado pela Silicon Laboratories para permitir a conexão perfeita com um circuito integrado do lado da linha (Si3291x) para formar uma interface FXO. O si32179 fornece uma banda de voz padrão de 200 Hz até 3.4 KHz no codec de áudio e, também, tem a opção de uma banda de voz entre 50 Hz até 7 KHz. Esses componentes atendem às necessidades de aplicações muito utilizadas nas telecomunicações,

32 3.1 Estrutura do SLIC si dentre elas: Ideal para aplicações de curto e médio de prazo, incluindo voz sobre IP (VoIP); Gateways a cabo: Endereço MAC do Adaptador do Terminal (EMTA); Gateways DSL integrated access devices (IAD); FTTH optical network terminals (ONT); Terminal de voz WiMax; Wireless Fixed Terminals (WFT); e Adaptador de terminal analógico (ATA). A figura 3.1 ilustra o diagrama de bloco dos circuitos si32179 e si Nessa, também pode ser vista a forma de interligação capacitiva usada pela Silicon Laboratories. Figura 3.1: Diagrama de blocos do si32919 e interligação por método capacitivo com o CI si32919 (Figura cedida por cortesia pela Silicon Labs Características do si32179 O sub-sistema FXS contém um processador DSP integrado que executa as seguintes funções para o canal FXS: Características de alimentação DC (DC Feed Characteristics) - circuitos de alimentação de linha interno do SLIC, fornecem características de alimentação DC completamente programáveis. Quando no estado ativo, o SLIC opera em uma das três regiões de operação de alimentação DC de linha: uma região de tensão constante, uma região de corrente constante, ou uma região de resistência. A região de tensão constante tem uma resistência baixa, tipicamente 160 Ω. A região de corrente constante aproxima resistência infinita;

33 3.1 Estrutura do SLIC si Estados de operação de avanço de linha (Linefeed Operating States) - a interface de alimentação de linha inclui oito diferentes estados de operação de registo programável; Monitoramento da tensão e corrente da linha (Line Voltage and Current Monitoring) - o SLIC monitora continuamente o TIP, RING, tensões de bateria e correntes através de um ADC no chip e armazena os valores resultantes em locais individuais na RAM; Monitoramento de energia e detecção de falhas de energia (Power Monitoring and Power Fault Detection) - função de monitoramento do Si32179 utilizada para proteger continuamente contra as condições em que há energia excessiva. Se o Si3217x detecta uma condição de falha ou sobre carga, o dispositivo automaticamente esse se volta para um estado aberto e gera uma interrupção, indicando um alarme; Desligamento de sobrecarga térmica (Thermal Overload Shutdown) - ao exceder atingir uma temperatura de junção, o dispositivo automaticamente é desativado. A temperatura de junção típica (TJmax) é de 145 graus celsius; Gerador de ring (Ringing Generation) - o si32179 provê um sinal de ring com formato de onda senoidal ou trapezoidal, com um deslocamento (offset) DC. A frequência, forma de onda e cadência são totalmente programáveis; Inversão de polaridade (Polarity Reversal) - o SLIC pode monitorar o comportamento da linha, caso haja alguma alteração da polaridade ele pode informar sobre o progresso da chamada; Gerador de tons (Tone Generators) - o Si32179 inclui dois geradores de som digitais que permitem uma grande variedade de frequência simples ou duplo tom e junto com combinações de amplitude; Detecção de DTMF (DTMF Detection) - no DTMF, dois tons gera um dígito DTMF. Um tom é escolhido a partir de quatro tons possíveis de uma linha, e um tom é escolhido a partir de outros quatro tons possíveis de uma coluna. A soma destes tons constitui um dos possíveis 16 dígitos DTMF; Controle DC-DC (DC-DC Controller) - o si3217x integra um controlador de DC-DC, que opera a partir de uma única entrada DC positiva. O controlador gerencia dinamicamente um circuito conversor DC-DC externo para gerar a tensão da bateria ideal para cada estado de funcionamento; e Largura de banda do áudio (Wideband Audio) - através de programação é possível fazer o si32179 operar em uma banda larga de áudio (50 Hz 7 khz) ou em uma bada

34 3.1 Estrutura do SLIC si estreita (200 Hz 3.4 khz). O SLIC ainda permite uma taxa de amostragem de 16 khz 16-bit para uma maior qualidade de áudio, mantendo a compatibilidade de áudio padrão de telefonia. As amostras de áudio são transmitidos e recebidos na interface PCM usando dois quadros consecutivos de 8 khz. Para programar todas as características (features), a Silicon Laboratories disponibiliza um software para testes do dispositivo e outro software para desenvolvimento das aplicações necessárias. Dessa forma, o desenvolvimento tem uma velocidade melhorada e com maior confiabilidade, já que podem ser feitos testes em todos os blocos lógicos e comparar com o desenvolvimento proprietário. Principais barramentos O SLIC si32179 possui uma interface PCM e uma interface SPI. A interface PCM implementa um barramento de áudio, que possibilita a transferência das amostras de áudio já codificadas entre o SLIC e o host. A interface de controle SPI (slave) permite a configuração do SLIC através de um dispositivo master. É por meio da interface SPI que o host inicializa e programa as funções do SLIC para que esse opere conforme desejado SPI O método SPI utilizado no SLIC si32179 é o método 3 (CPOL = 1 e CPHA = 1), por meio do qual o primeiro bit de dado (bit 7) é encaminhado para o barramento na primeira borda do sinal de clock e amostrado na borda de subida. Quando não há atividade no barramento, o Master coloca o sinal SCLK em nível lógico 1 (um). Para transmitir ou receber dados do SLIC, seja da random access memory (RAM) ou do registrador (REG), é preciso antes enviar uma palavra de controle (byte CONTROL). Sua função é descrita na tabela 3.1. O documento AN340.pdf, que está protegido sob NDA 1, traz todas as informações sobre os métodos de escrita e leitura do SLIC. Além da palavra de controle, é preciso indicar qual endereço, da RAM ou REG, será aferido. Para isso, logo após enviar a palavra de controle, 1 byte é enviado, informando qual o endereço da memória ou do registrador será escolhido. Assim, são disponibilizados 256 possíveis endereços para cada operação. Outro byte que se faz uso é o dado propriamente dito. No entanto, é possível enviar 1 ou 2 bytes e isso é feito enviando uma sequência de 2 bytes 1 NDA (Non-Disclosure Agreement) é um acordo de não divulgação

35 3.1 Estrutura do SLIC si Tabela 3.1: Byte CONTROL (Tabela cedida por cortesia pela Silicon Labs 7 BRDCST Este bit indica uma operação em broadcast, ou seja, transmissão ou recepção para todos os canais. 6 R/W Bit de leitura ou escrita: 0 = operação de escrita; 1 = operação de leitura. 5 REG/RAM Bit de Acesso à RAM/REG: 0 = acesso à RAM; 1 = acesso ao REG. 4:0 CID[4:0] Estes 5 bits indicam qual canal será acessado. após ter sido enviada a palavra de endereço. As figuras 3.2, 3.3, 3.4 e 3.5 mostram exemplos de operações utilizados pelo SLIC si32179: Figura 3.2: Escrita no registrador com dado de 8 bits (Figura cedida por cortesia pela Silicon Labs Figura 3.3: leitura no registrador com dado de 8 bits (Figura cedida por cortesia pela Silicon Labs Figura 3.4: Escrita na RAM com dado de 16 bits (Figura cedida por cortesia pela Silicon Labs

36 3.1 Estrutura do SLIC si Figura 3.5: Leitura na RAM com dado de 16 bits (Figura cedida por cortesia pela Silicon Labs PCM Pulse Code Modulation (PCM) é a técnica de modulação por código de pulso, por meio da qual os sinais analógicos são codificados em taxas de 64 Kbps (ARAÚJO; BRAGA, 2009). Comumente, para a transmissão dos códigos obtidos mediante essa técnica (pedaços da voz), é utilizada a técnica de transmissão (Time Division Multiplex) (TDM), que é a multiplexação dos dados em períodos de tempo, denominados timeslots. Essa técnica é largamente utilizada no sistema telefônico (ROSA; BONATELLI, 2008). Em todo sistema telefônico digital que faz uso do TDM é preciso inserir, pelo menos, duas fontes de sincronismo. Uma para ditar a taxa de transferência do sistema e outra para marcar o início de cada timeslot. A interface PCM utilizada no si32179 provê os padrões que os dispositivos de telefonia usam na indústria. Esses padrões são descritos no documento AN340.pdf. A documentação especifica como a transferência de dados é controladas, utilizando entradas dos sinais de sincronismo PCLK e FSYNC e os sinais de dados DRXa e DTXa. O SLIC si32179 pode assumir algumas variantes, tanto nas taxas de transferências quanto na forma de marcação de cada timeslot. Sinais PCLK e FSYNC O sinal PCLK é utilizado para especificar a taxa de transferência do barramento PCM. O SLIC si32179 pode operar com taxas a partir de 512 KHz, podendo ser incrementado em potências de 2 até o valor de MHz. Com essas especificações, a interface PCM pode assumir de 4 até 128 timeslots com 8 bits cada (Documentação cedida por cortesia pela Silicon Labs As definições para o sinal PCLK são configuradas por intermédio do registrador REG 11 (PCMODE), que define qual o modo PCM será utilizado, que são três:

37 3.1 Estrutura do SLIC si PCM utilizando a-law; PCM utilizando u-law; e PCM utilizando 16-bits linear. Os registradores REG 12 e REG 15 (PCMTXHI/PCMTXLO e PCMRXHI/PCMRXLO) são responsáveis por determinar, para a interface FXS, em que posição as amostras serão inseridas no quadro PCM. Para a interface FXO, é utilizado o registrador REG 33 para determinar qual modo PCM (idem ao FXS). E para determinar em que posição serão inseridas as amostras da interface FXO, são utilizados os registradores REG 34 e REG 37. O sinal FSYNC atua sincronizado com o sinal PCLK, marcando o início de cada quadro no barramento PCM. Caso o sinal PCLK seja estipulado em 512 KHz, o sinal FSYNC pode ser obtido por meio de 64 pulsos de PCLK. Como PCLK possui frequência de 512 KHz, seu período é de 1, us (1, microsegundos). Por sua vez, como o FSYNC possui frequência de 8 KHz, seu período é de 125 us (125 microsegundos). A quantidade de pulsos pode ser mediante a equação 3.1: numeropulsos = => 64pulsos (3.1) 1, Para a avaliação dos sinais PCLK e FSYNC, o REG 3 (MSTRSTAT) é responsável por indicar se os valores estão de acordo com a funcionalidade do SLIC. Segundo a documentação AN340.pdf, espera-se que contenha o valor 0x1F ( ), o que indica que os valores de PCLK e FSYNC gerados no barramento PCM estão corretos. Os bits do registrador estão disponíveis na tabela 3.2 e devem ser observados os valores de D4 até D0 (Documentação cedida por cortesia pela Silicon Labs Tabela 3.2: Registrador MSTRSTAT (Tabela cedida por cortesia pela Silicon Labs Bit D7 D6 D5 D4 D3 D2 D1 D0 Nome PLL FAULT FS FAULT PCLK FAULT SRAN CLR PLL LOCK FS DETECT FS VALID PCLK VALID Tipo Sticky1 Sticky1 Sticky1 R R R R R Sinais DRXa e DTXa A transferência das amostras de áudio são feitas pelos sinais DRXa e DTXa. Para receber uma amostra de áudio, é utilizado o sinal DRXa. Para se transmitir uma amostra de áudio, é uti-

38 3.1 Estrutura do SLIC si lizado o sinal DTXa. Esses dois sinais são compartilhados entre a interface FXS e FXO, sendo alocados em um determinado pulso no sinal PCLK, conforme configuração dos registradores REG 12 (PCMTXLO) e REG 13 (PCMTXHI) para a interface FXS e REG 34 e REG 37 para a interface FXO. As formas de onda dos sinais descritos podem ser observadas nas figuras 3.6 e 3.7. A figura 3.6 mostra o método com um pulso curto do sinal FSYNC e a figura mostra o método com um pulso longo do sinal FSYNC. Figura 3.6: Exemplo dos sinais PCLK, FSYNC, DRXa e DTXa de um timeslot, utilizando o modo Short FSYNC (Figura cedida por cortesia pela Silicon Labs Figura 3.7: Exemplo dos sinais PCLK, FSYNC, DRXa e DTXa de um timeslot, utilizando o modo Long FSYNC (Figura cedida por cortesia pela Silicon Labs

39 3.2 Kits de desenvolvimento si Kits de desenvolvimento si32179 Para iniciar o desenvolvimento do dispositivo si32179 e se inteirar das funções que ele implementa, a Silicon Laboratories fornece dois kits de desenvolvimento o VMB2 REV 2.0 e Si32179BFB11SL0EVB. Esses dois kits podem atuar de forma conjunta ou separada. O VMB2 REV 2.0 é uma placa mãe com conectores para o kit Si32179BFB11SL0EVB e uma interface USB, a qual permite a conexão a um computador e controle total do componente si32179 utilizando um software disponibilizado pela empresa. O kit VMB2 REV 2.0 ainda pode ser utilizado como uma simples fonte de energia para kit Si32179BFB11SL0EVB, isso permite que o controle do si32179 seja efetuado por um controlador externo ligado nas portas SPI e PCM do SLIC Estrutura Ambos os kits tem funções importantes para os testes, o desenvolvimento e diagnósticos do projeto. Entender como sua estrutura funciona, proporciona um melhor resultado na evolução final, além de acelerar o processo de desenvolvimento. Kit VMB2 REV 2.0 O kit VMB2 REV 2.0 é uma placa mãe que pode atuar em dois modos: Placa mãe - esse modo permite que um segundo kit seja integrado a ele. Assim é possível o acesso ao SLIC sem a necessidade de um hardware gernérico para efetuar o controle; e Fonte de energia - esse modo é uma alternativa para fornecer os níveis DC a um kit que será controlado por um hardware e software de terceiros. São partes integrantes do kit, como mostra a figura 3.8: Interface USB - essa interface implementa a comunicação entre a unidade de controle e o computador portador do software que faz seu gerenciamento; Conector DC - fornece os níveis DC para o kit hospedeiro no modo placa mãe e no modo fonte de energia; Conector SPI - permite a conexão física do barramento SPI para o kit hospedeiro no modo placa mãe;

40 3.2 Kits de desenvolvimento si Conector PCM - permite a conexão física do barramento PCM para o kit hospedeiro no modo placa mãe; Unidade de controle - responsável pela comunicação entre a interface USB e o computador portador do software que faz seu gerenciamento. Essa unidade faz uma interface entre o software de desenvolvimento e os barramentos do kit que é hospedado por ele no modo placa mãe; e Conector fonte - conexão de entrada de nível DC 12 V 2A, que gera os níveis de alimentação para o kit. Figura 3.8: Kit de desenvolvimento da Silicon Laboratories VMB2 REV 2.0. Kit Si32179BFB11SL0EVB O kit Si32179BFB11SL0EVB é responsável pela implementação do circuito de telefonia, é nele que está disponível o SLIC si32179 e o circuito integrado si Esse kit permite efetuar a conexão de um hardware externo e controlar o si32179 por um software proprietário, isso o torna o mais importante entre os kits. Ele dispõe de todas as conexões físicas para se ter acesso aos barramentos do si32179, o que também torna fácil a análise dos sinais individualmente. O kit Si32179BFB11SL0EVB pode atuar em dois modos: Modo hospedeiro - esse modo permite kit VMB2 REV 2.0 faça o controle de suas funções.

41 3.2 Kits de desenvolvimento si Modo Standalone - esse modo permite que o kit seja controlado por um hardware e um software de terceiros. São partes integrantes do kit, como mostra a figura 3.9: Conectores RJ-11 - fornece conexão física para a rede PSTN e terminal telefônico; Conector DC - recebe os níveis DC fornecidos pela placa mãe ou outra fonte quando controlado por um hardware externo; Conector SPI - fornece conexão física do barramento SPI para o kit quando no modo placa mãe e/ou quando controlado por um hardware externo; Conector PCM - fornece conexão física do barramento PCM para o kit quando no modo placa mãe e/ou quando controlado por um hardware externo; Si SLIC responsável pelas implementações de telefonia (interface FXS e interface FXO); Si circuito integrado auxiliar para a implementação da interface FXO; Pontas de prova - fornece conexões de fácil acesso a todos os sinais do barramento SPI, barramento PCM, níveis DC e conectores RJ-11. Figura 3.9: Kit de desenvolvimento da Silicon Laboratories Si32179BFB11SL0EVB Software utilizados Para auxiliar o desenvolvimento de sistemas que utilizam o si32179, a Silicon Laboratories fornece junto aos kits dois softwares: O ProSLIC Voice GUI e o Proslic api config tool.

42 3.2 Kits de desenvolvimento si Cada um deles possui funções específicas e são exclusivos para o sistema operacional Windows. Além desses dois softwares de aplicação, há também o software driver CP210x, que é responsável por fazer a comunicação do kit VMB2 REV 2.0 com computador, controlando a interface USB que acompanha o kit VMB2 REV 2.0. ProSLIC Voice GUI O software ProSLIC Voice GUI é parte integrante da plataforma de desenvolvimento da Silicon Laboratories, sua finalidade é controlar o kit VMB2 REV 2.0 através de uma porta serial emulada via USB. Com o software é possível ter acessos a todos os registradores e memórias RAM do si Tudo através de uma interface gráfica amigável, como pode ser observado na figura Figura 3.10: Software ProSLIC Voice GUI Um script (Si32179FB.txt) de inicialização correspondente ao SLIC utilizado é fornecido junto ao software, ele torna possível uma fácil inicialização com algumas configurações já definidas. Após a inicialização a partir do script, o sistema permite uma sequência de testes de todas as features do si Outra utilização do software é verificar se o kit está operando dentro das condições normais, além de efetuar testes mais específicos como: Checar circuito de ring; Gerar tons DTMF;

43 3.2 Kits de desenvolvimento si Identificar tons DTMF gerados a partir de um terminal; Medições de pulso; Geração de sinais Frequency-shift keying (FSK); Configuração do canal PCM; Alimentação DC; Efetuar diagnósticos do sistema; e Ferramentas para manipulação do áudio. A interface gráfica traz na primeira tela, de forma organizada, os mnemônicos de todos os registradores e memória RAM, cada qual, com os respectivos valores tornando fácil a compreensão, em tempo real, do que ocorre no si32179 para cada ação tomada. Proslic api config tool Para o desenvolvimento de um projeto ter uma velocidade maior, o Proslic api config tool pode atuar como acelerador. Ele permite, de forma organizada, configurar os valores iniciais dos registradores e memória RAM para aplicar ao SLIC. Todas as características do SLIC estão disponíveis em uma tela, como se fossem checklist, onde cada configuração é feita passo-a-passo, como pode ser observada na figura Após editar os valores de cada item para uma aplicação proprietária, o Proslic api config tool disponibiliza uma função capaz de gerar o código fonte para ser utilizado em um determinado projeto. Os códigos fontes gerados são na linguagem C e seguem a nomenclatura NomeSclic constants.c, NomeSclic constants.h, vdaa constants.c, vdaa constants.h. Para ter uma maior efecácia na utilização do Proslic api config tool, recomenda-se o estudo da Proslic Application Programming Interface (API), já que essa descreve como os blocos funcionais do si32179 devem ser construídos Proslic Application Programming Interface - (API) Assim como outros grandes fabricantes de semicondutores, a Silicon Laboratories fornece uma API de desenvolvimento para ser aplicada aos projetos de seus chips. A Proslic API é um conjunto de padrões estabelecidos pela Silicon Laboratories, que estrutura a utilização das características do si32179 para o desenvolvimento de um software que irá controlá-lo.

44 3.2 Kits de desenvolvimento si Figura 3.11: Software Proslic api config tool. A ideia da API definir uma camada de interface abstrata entre o código aplicativo do usuário e os drivers de dispositivo específico ProSLIC, proporcionando ao usuário acesso total aos recursos do dispositivo ProSLIC usando uma estrutura padrão. A figura 3.12 ilustra o modelo de arquitetura da Proslic API. Figura 3.12: Arquitetura Proslic API (Figura cedida por cortesia pela Silicon Labs O fluxo de controle da estrutura Proslic API pode ser observada na figura 3.13, que traz um exemplo da rotina de troca do estado do ring.

45 3.2 Kits de desenvolvimento si Figura 3.13: Arquitetura Proslic API (Figura cedida por cortesia pela Silicon Labs ProSLIC API - Software de configuração A API ProSLIC utiliza as suas próprias estruturas de dados para manter a ligação entre o hardware do sistema e os drivers de dispositivo ProSLIC. Três tipos de estrutura de dados deve ser criado e inicializado para fornecer os drivers ProSLIC com essa ligação hardware: Interface objeto de controle ProSLIC (controlinterfacetype): Fornece ponteiro void (vazio) para o controle do objeto; Fornece ponteiros de função aos recursos do sistema (reset, timers, SPI); e Uma instância por interface de controle (ou seja, por chip select). Interface objeto do dispositivo ProSLIC (proslicdevicetype): Fornece ponteiro controle para interface objeto do dispositivo ProSLIC; Itens de informações específicas do dispositivo ProSLIC (tipo, revisão); e Uma instância física por dispositivo. Interface objeto do canal ProSLIC (proslicchantype): Fornece ponteiro para a interface objeto do canal ProSLIC; Armazena opções de status do canal (enable, error, BOM options); e Uma instância por canal criado.

46 3.3 Estrutura do LPC ProSLIC - inicialização do dispositivo A ProSLIC API fornece chamadas de funções para realizar uma inicialização básica do dispositivo ProSLIC. O driver inicia o dispositivo ProSLIC, executa todas as calibrações obrigatórias, e implementa todas as personalizações feitas e os parâmetros gerais de configurações. ProSLIC - configuração do dispositivo O dispositivo ProSLIC pode ser configurado para atender os requisitos de concepção do utilizador após que sua inicialização se complete. A API ProSLIC fornece chamadas de função para carregar presets do usuário, que são gerados usando a ferramenta de configuração API ProSLIC. A API ProSLIC permite funções que podem ser chamadas a qualquer momento após a inicialização do dispositivo, dessa forma ela permite que, dinamicamente, o dispositivo possa atender as necessidades de aplicação. ProSLIC - controle do dispositivo Uma vasta biblioteca de funções de controle são definidos na API ProSLIC para simplificar o controle de aplicação do dispositivo ProSLIC conjunto de recursos ricos. Esta biblioteca permite ao usuário implementar funções de telefonia padrão com pouca sobrecarga do software pelo desenvolvedor. Além dessas especificações citadas, a Proslic API também descreve como o software Proslic api config tool pode ser melhor aproveitado 3.3 Estrutura do LPC-1768 O LPC-1768 é um microcontrolador de 32 bits fabricado pela NXP, baseado na tecnologia Reduced Instruction Set Computer (RISC), que surgiu com a união de forças da Acorn Cumputer Groupe, VLSI Technology Inc. e a Apple Computer onde deu origem a ARM Ltd. Dessa união criou-se a arquitetura Acorn RISC Machine, mais tarde batizada de Advanced RISC Machine (ARM-TM) (MIYADAIRA, 2012). A tecnologia ARM é utilizada em uma grande variedade de aplicações, como telefones celulares, roteadores, sistemas de trava para veículos,

47 3.3 Estrutura do LPC aparelhos MP3, câmeras, driver de HD, TV digital e vários outros equipamentos. Microcontroladores com tecnologia ARM, possuem um núcleo com processadores da família Cortex-A (A5, A7, A8, A9 e A15), que é a família aplicação, família Cortex-M (M0, M0+, M1, M3 e M4), que é a família microcontrolador, e a família Cortex-R (R4 e R5), que é a família tempo real (MIYADAIRA, 2012). O LPC-1768 é baseado nos processadores Cortex-M3 e as principais características desses processadores são: Endereçamento de memória fixo de 4 GB; Bit-banding; Arquitetura Load/Store (carga/armazenamento); Conjunto de instruções Thumb-TM2; Pipeline de três estágios e uma unidade de pré-busca (prefetch); Multiplicador de 32 bits x 32 bits; SysTick timer; Non-Maskable Interrupt (NMI); Nested Vectored Interrupt Controller (NVIC); Memory Protection Unit; e Modos de operação do processador. Thread mode ou Handler mode O LPC-1768 é constituído de uma CPU com frequência máxima de 100 MHz de operação. Ainda dispõe de uma memória flash com 512 KB e uma Static Random Access Memory (SRAM) de 64 KB. Ao todo são 70 pinos de entrada/saída para uso em aplicações gerais e interfaces de controle e transferência como Ethernet, USB, SPI, PWM, entre outras Cortex-M3 De maneira geral, ARM Cortex-M3 é um microprocessador de 32 bits, que oferece alto desempenho com um baixo consumo de energia. O ARM Cortex-M3 oferece muitos recursos, incluindo um conjunto de instruções Thumb-2, estado automático para salvar e restaurar interrupções, controlador de interrupção totalmente integrado com controlador de interrupção de wake-up, e vários barramentos centrais com acessos simultâneos.

48 3.3 Estrutura do LPC No ARM Cortex-M3 é empregada técnicas de canalização de modo que todas as partes dos sistemas de processamento e de memória pode operar continuamente. Normalmente, quando uma instrução está sendo executado, o seu sucessor está sendo decodificado, e uma terceira instrução está sendo obtido a partir da memória. Organização do núcleo Pensando em simplificar a portabilidade/reaproveitamento de código entre processadores da série Cortex-M, a empresa ARM Ltd. estabeleceu uma camada de software padronizada, denominada Cortex Microcontroller Software Interface Standard (CMSIS) visível na figura Figura 3.14: Estrutura básica da CMSIS (MIYADAIRA, 2012). A CMSIS pode ser dividida nas seguintes camadas: Camada de acesso aos periféricos do processador; Camada de acesso aos periféricos do microcontrolador; e Camada de acesso middleware. O núcleo do Cortex-M3 traz um barramento Multi-layer AHB Matrix e um Advanced Peripheral Bus. O AHB-Matrix constitui em um barramento de alto desempenho entre as memórias SRAM e FLASH e a CPU. Já o APB, faz o barramento dos periféricos com o AHB- Matrix e, apesar do APB ser um barramento de 32 bits, permite que alguns periféricos atuem com menos de 32 bits, dependendo da necessidade de cada periférico, por exemplo, o periférico DAC, que atua com 10 bits, os dois barramentos são ilustrados na figura 3.15.

49 3.3 Estrutura do LPC Figura 3.15: Diagrama de bloco do ARM Cortex-M3 (NXP, 2015a). Organização da memória Os processadores ARM Cortex-M3 possuem um espaço de endereçamento de memória fixo de 4 GB (MIYADAIRA, 2012), conforme ilustado na figura O mapeamento de memória está dividido em sete regiões, sendo: Código (Code): Região da memória onde o programa é normalmente armazenado, contém 512 MB; SRAM (SRAM): Região da memória onde os dados voláteis são armazenados. Está região suporta o bit-banding (técnica que permite ao processador acessar um bit diretamente), contém 512 MB; Periférico (Peripheral): Região da memória onde os registros dos periféricos do microcontrolador estão localizados. Esta região suporta o bit-banding, contém 512 MB; RAM externa (External RAM): Região da memória dedicada ao acesso da memória RAM externa, contém 1 GB; Dispositivo externo (External Device): Região da memória dedicada ao acesso de dispositivos externos, contém 1 GB; Barramento de periférico particular (PPB - Private Peripheral Bus): Região da memória que contempla o barramento PPB, contém 1 MB; e

50 3.3 Estrutura do LPC Figura 3.16: Mapa de memória do processador ARM Cortex-M3 (MIYADAIRA, 2012). Sistema (System): Região da memória específica para aplicações do fabricante, contém 511 MB. O LPC-1768 é capaz de manipular dados de 8 bits (byte), 16 bits (half-word) e 32 bits (word), já que tem uma visão da memória como um conjunto linear de bytes numerados de forma ascendente (MIYADAIRA, 2012). Conjunto de instruções A tecnologia Thumb-2 possui novas instruções de 32 bits e, ao mesmo tempo integra a antiga tecnologia Thumb. O uso dessa tecnologia torna desnecessário o uso do interworking, pois permite num só modo instruções de 16 bits e 32 bits, tornando possível gerar códigos sem alterar a performance (MIYADAIRA, 2012). O interworking é uma técnica que subdivide o código entre ARM e Thumb, para se obter uma alta densidade de código sem comprometer a performance. Por sua vez, Thumb é um subconjunto de instruções ARM de 32 bits comprimidas em 16 bits, e depois que essas instruções entram em execução são descomprimidas em instruções ARM.

51 3.3 Estrutura do LPC Serial Peripheral Interface O LPC-1768, traz uma interface Serial Peripheral Interface (SPI) nativa. Essa interface é massivamente utilizada nos estudos para o desenvolvimento do dispositivo de telefonia, por isso ela tem destaque dentre as outras. A SPI, interface desenvolvida pela Motorola, é um sistema serial síncrono que utiliza uma alta taxa de transferência e barramento full-duplex. Nessa interface, o barramento suporta um dispositivo Master ativo, que pode ser empregado por um microcontrolador ou um microprocessador. Além do Master, o barramento pode assumir vários Slaves, que são periféricos em geral. O barramento é composto por quatro linhas de comunicação (MIYADAIRA, 2012), sendo elas: SCLK: Slave - entrada de sinal de clock; Master - saída de sinal de clock; MOSI: Slave - entrada de dados; Master - saída de dados; MISO: Master - entrada de dados; Slave - saída de dados; SS: Slave - entrada de seleção do periférico; Master - saída de seleção de periférico. Figura 3.17: Barramento SPI (MIYADAIRA, 2012). Essa interface é amplamente utilizada em uma infinidade de periféricos, sendo aplicada em conversores A/D e D/A, memórias, expansores de pinos I/O, Real Time Clock s (RTC), gravadores e reprodutores de som, entre outros.

52 3.3 Estrutura do LPC Princípio de funcionamento Uma comunicação é estabelecida na interface SPI quando o dispositivo Master força o sinal de entrada SS de um determinado Slave para o nível lógico 0 (nível lógico baixo). Assim que o sinal SS de um Slave vai para nível lógico 0, os dados armazenados nos shift registers (registradores de deslocamento) são transferidos entre eles bit a bit a cada pulso de clock aplicado no sinal SCLK. A transmissão ocorre do bit MSB para o LSB. Assim que o último bit de dado é transferido, o dispositivo Master pode realizar uma nova transmissão. Caso não se queria transmitir mais dados, o Master deve forçar o pino SS para o nível lógico 1 (nível lógico alto) (MIYADAIRA, 2012). A figura 3.18 mostra um exemplo de como os registradores shift registers operam e como ocorre a transferência de dados. Tipos de conexões O barramento SPI suporta quatro tipos de conexões diferentes. Uma vez escolhido o método pelo Master, todos os outros dispositivos (Slaves), devem utilizar o mesmo método. Dois bits são responsáveis pela escolha do método: Clock Polarity (CPOL): define a configuração da polaridade; e Clock Phase (CPHA): define a configuração da fase Interface USB O controlador USB do LPC-1768 suporta uma interface 2.0 full-speed com os modos device, host e On-The-Go (OTG), com controlador DMA e PHY dedicado no chip para o device, host e as funções OTG. Esse controlador de dispositivo permite uma comunicação numa taxa de 12 Mbit/s de dados com um controlador USB host. O controlador consiste de uma interface de registro, um engine (motor) de interface serial, memória buffer de endpoint, e um controlador de DMA. O engine de interface serial decodifica o fluxo de dados USB e grava dados para o buffer de endpoint apropriado. O status de uma condição de transferência USB ou de erro concluída é indicado através dos registos de estado. Uma interrupção também é gerada caso seja habilitado. Assim que ativado, o controlador de DMA transfere dados entre o buffer de endpoint e SRAM.

53 3.3 Estrutura do LPC Figura 3.18: Transferência de um dado de 8 bits (MIYADAIRA, 2012).

54 3.3 Estrutura do LPC Features São características da interface USB do LPC-1768: Totalmente compatível com a especificação USB 2.0 full speed; Suporta 32 (16 lógicas) endpoints físicos com um 4 kb de buffer endpoint/ram; Suporta endpoints com os métodos Control, Bulk, Interrupt e Isochronous; Realização escalável de endpoints em tempo real; Seleção de tamanho máximo do pacote do endpoint (até especificação máxima USB) por software em tempo real; Suporta recursos SoftConnect e GoodLink; Enquanto USB está no modo de suspensão, permite entrar no modo baixo consumo e ser ativado sobre qualquer atividade na USB; Permite a comutação dinâmica entre o slave controlado pela CPU e os modos DMA; e permite a implementação debuffer duplo para endpoints bulk e isochronous. Sugestão de implementação para a interface USB A NXP sugere um circuito para aplicações onde será implementa uma interface USB device, conforme ilustrado na figura Esse barramento só se aplica nos casos onde o cabo do host (PC, por exemplo) fornece a energia para o circuito. Figura 3.19: Barramento USB para o modo device (NXP, 2015b).

55 3.3 Estrutura do LPC Outros periféricos Além dos periféricos destacados nas sessões e 3.3.3, o microcontrolador LPC-1768 dispõe de outras possíveis interfaces que poderiam ser aplicadas a esse projeto. Elas poderiam flexibilizar o desenvolvimento, tornando possível a utilização de outros dispositivos comerciais além do si32179 e, também, facilitar o desenvolvimento de alguns barramentos para esse projeto, como é o caso da interface Pulse Width Modulation (PWM). Alguns periféricos que podemos citar: Inter-Integrated Circuit (I2C); Pulse Width Modulation (PWM); e Ethernet. Inter-Integrated Circuit (I2C) O LCP-1768 possui 3 interfaces I2C. Essa é uma interface serial síncrona que suporta múltiplos master, desenvolvida pela Philips Semiconductors para simplificar a troca de informações entre circuitos integrados, já que possui em seu barramento, apenas duas linhas de comunicação, uma de dados bidirecional (SDA) e outra para o sinal de clock (SCL). Cada dispositivo é reconhecido por um endereço único e pode operar tanto como um dispositivo só de receptor (por exemplo, um controlador de LCD) ou um transmissor com a capacidade de receber e enviar as informações (como memória). Características da interface I2C do LPC-1768: Suporta taxas de até 1 Mbit/s no fast mode; Fácil configuração para o master mode, slave mode e/ou master mode/slave mode; Transferência bidirecional de dados entre master e slave; Barramento multi master (nenhum master central); Sincronização do clock serial permite que dispositivos com diferentes taxas de bits se comuniquem através do mesmo barramento de dados; Sincronização do clock serial pode ser usado como um mecanismo de handshake para suspender e retomar a transferência de dados; e O barramento I2C pode ser utilizada para fins de teste e de diagnóstico.

56 3.3 Estrutura do LPC Pulse Width Modulation (PWM) PWM é a técnica de modulação por largura de pulsos em que se aplica o controle de potência entregue em uma determinada carga. O princípio de seu funcionamento é chavear a tensão de alimentação entre dois estados, ligado e desligado, durante um período de tempo previamente configurado. O sinal PWM pode ser utilizado em uma infinidade de aplicações, como controle de luminosidade, controlar a temperatura de uma determinada resistência para se atingir o aquecimento desejado, geração de áudio e controlar a velocidade de motores. O microcontrolador LPC-1768, possui um módulo PWM, com sete registros de comparação, capaz de gerar até seis sinais PWM controlados por uma única borda ou três sinais controlados por duas bordas. Um exemplo de aplicação para esse projeto, é a implementação dos sinais para o barramento PCM que contempla o SLIC si32179 visto na sessão Ethernet O bloco Ethernet contém uma featured Ethernet completa de 10 Mbit/s ou 100 Mbit/s projetada para fornecer desempenho otimizado através do uso da aceleração de hardware DMA. As features incluem um conjunto generoso de registros de controle para operação half ou full duplex, controle de fluxo, quadros de controle, aceleração de hardware para transmissão de repetição, receber a filtragem de pacotes e wake-up sobre a atividade LAN (WoL). O bloco Ethernet e a CPU compartilham o ARM Cortex-M3 D-code e o barramento do sistema através da matriz multicamadas AHB, assim os dados Ethernet podem acessar vários blocos SRAM do chip, controle e informações de status. Características da interface Ethernet do LPC-1768: Suporte aos padrões Ethernet: Camada física com 10 Mbit/s ou 100 Mbit/s, incluindo 10 Base-T, 100 Base-TX, 100 Base-FX e 100 Base-T4; Completamente compatível com o padrão IEEE 802.3; Completamente compatível com controle de fluxo 802.3x full duplex; Transmissão e recepção flexível de opções de frame; e Suporte a frames para Virtual Local Area Network (VLAN).

57 3.4 Kit de desenvolvimento LPC Gerenciamento da memória: Buffers independentes de transmissão e recepção para compartilhar o mapeamento de memória SRAM; e Tráfego de memória otimizada por buffering and pre-fetching. Características reforçadas do Ethernet: Filtro recepção; Suporte a quadros multicast e broadcast para transmissão e recepção; Quadro com Frame Check Sequence (FCS) opcional com inserção automática de Cyclic Redundancy Check (CRC) para transmissão; Preenchimento automático de quadro de transmissão opcional; Modo de recepção promíscua; Colisão automática back-off e estrutura de retransmissão; e Inclui gerenciamento de energia por troca de clock; e O suporte ao WOL com o gerenciamento de energia permite que o sistema seja ativado remotamente: usando os filtros de recepção ou um filtro de detecção de magic frame. Com o uso de uma interface Ethernet, pode-se obter diagnósticos do LPC-1768 e do si32179 remotamente. Com o auxílio do protocolo Simple Network Management Protocol (SNMP), o sistema pode ser monitorado e até poder ter algumas configurações modificadas em tempo de execução. Isso possibilita a manutenção, gerenciamento e coletas de diagnósticos de forma mais simples e organizada de vários dispositivos simultaneamente. 3.4 Kit de desenvolvimento LPC-1768 A NXP junto com o um projeto denominado MBED fornecem kits de desenvolvimento com a arquitetura Cortex-M, com vários modelos de microcontroladores. Em particular, para esse projeto foi estudado o kit MBED LPC Esse kit é de fácil acesso, sem a necessidade de efetuar acordos de uso e restrições de documentação. Um dos pontos fortes para uso desse Kit é que existe vários exemplos de códigos disponibilizados em uma comunidade on-line mantida pelo projeto MBED.

58 3.4 Kit de desenvolvimento LPC Um recurso interessante do Kit é a possibilidade de utilizar sua interface de integração com o computador. Esse recurso permite a fácil gravação do firmware, sem a necessidade de nenhum gravador especial ou interface Joint Test Action Group (JTAG). Quando plugado em uma interface USB, esse torna uma unidade de disco removível como um pendrive. Basta então copiar o firmware gerado pela plataforma MBED (arquivo.bin) para a sua unidade de disco removível. Podemos visualizar o Kit na figura Figura 3.20: Kit de desenvolvimento MBED LPC-1768 (NXP, 2015a) Estrutura O objetivo nessa sessão é relatar algumas características do Kit de desenvolvimento. Quais os principais componentes, seu sistema de funcionamento, também é feito uma visão geral de quais sistemas fazem suporte para ele. Com isso, teremos ciência da melhor forma de utilizá-lo. Componentes O Kit MBED LPC-1768 está munido de um microcontrolador LPC-1768 ARM Cortex-M3, com uma série de periféricos e facilidades de desenvolvimento. Ele traz um conector USB tipo B fêmea e 40 pinos mapeados para variadas aplicações. Esses compatíveis com todos os códigos disponíveis na plataforma de desenvolvimento MBED, podendo migrar de um kit para outro com facilidade (inclusive para outro fabricante que não seja a NXP). Além dos 40 pinos o kit contempla 5 LEDs, um para indicar o funcionamento desse e outros quatro para uso de aplicações gerais.

59 3.4 Kit de desenvolvimento LPC Ele contém um controlador (mbed interface) responsável pelo gerenciamento do kit que faz a interface entre o microcontrolador LPC-1768 ARM Cortex-M3 e a interface USB. Esse controlador é responsável pelo gerenciamento da unidade de disco removível e também é responsável por aplicar o firmware para a memória flash do LCP Funcionamento Para que o firmware fique atuante no microcontrolador LPC-1768 ARM Cortex-M3 é preciso pressionar um botão do tipo push button disponível na parte superior e centralizada do kit. Após pressionar o botão, o microcontrolador responsável pelo gerenciamento do kit verifica o primeiro arquivo binário disponível (considera-se a ordem alfanumérica) na unidade removível e o envia para a memória flash do LPC Uma vez pressionado o botão, entrará em produção. Essa característica o torna muito atrativo, já que em pouco tempo podemos ter um firmware funcional, basta apenas pressionar um botão. Como a comunicação do kit é feita puramente sobre a interface USB com o sistema de desenvolvimento, sem a necessidade de uma interface especializada como uma interface JTAG, podemos fazer uso de variados sistemas operacionais. O desenvolvimento poder ser inicializado em qualquer plataforma Windows que dê suporte à interface USB, passar com plena compatibilidade por um sistema Mc-OS e, por fim, terminar o desenvolvimento em sistemas operacionais Linux. Ainda podemos facilmente utilizar Tablets que dêem suporte à uma interface USB host. O que permite o desenvolvimento até mesmo em uma praça no centro da cidade. Alimentação Apesar do kit dispor de entradas especificas de alimentação DC (GND e VIN), ele faz uso da alimentação disponível na própria interface USB. Assim o kit dispensa o uso de fontes específicas e externas Biblioteca NXP Para o desenvolvimento de aplicações utilizando o LPC-1768, a NXP disponibiliza uma biblioteca de desenvolvimento. Uma das características da biblioteca NXP é o uso de código aberto projetado para rodar em todos os microcontroladores USB LPC da NXP. Ela é oferecida gratuitamente a todos os clientes NXP. A biblioteca NXP dispõe das seguintes features: Controladores suportados:

60 3.4 Kit de desenvolvimento LPC Full speed, controlador no modo device (buffers dedicados); Full speed, controlador no modo device e no modo host (buffers compartilhados); e High speed, controlador no modo device e no modo host. Tipos de padrões de transferência: Control; Bulk; Interrupt; e Isochronous. Ferramentas suportadas: Keil uvision 4; e LPCXpresso 4. Placas suportadas LPCXpresso LPC11U14, LPC176x e placa base Rev B; Hitex LPC1850/4350 Evaluation Board (rev A4); NGX LPC4330-Xplorer; Element 14 LPC4350 Gaming Board; e Embedded Artists. Exemplos incluídos Dispositivos e hosts de áudio; Teclados; Dispositivos de armazenamento; Dispositivos de apontadores (mouse; Dispositivos VCOM; e A biblioteca não possui suporte a hub. ROM drivers HS: LPC1800, LPC4300; e FS: LPC11U00, LPC1300.

61 3.4 Kit de desenvolvimento LPC Para o desenvolvimento de um projeto usando a biblioteca NXP, é necessário ter um Ambiente de Desenvolvimento Integrado (IDE, do inglês Integrated Development Environmen) específica. O desenvolvimento fica restrito a um ambiente de trabalho com a necessidade de efetuar backups em vários locais (para garantir a integridade dos dados). Caso haja a necessidade de migrar de ambiente de trabalho é necessário que o projeto seja migrado de alguma forma, ou via armazenamento portátil ou por meio de downloads. Para a gravação do firmware na memória do microcontrolador há a necessidade de gravador especial ou interface Joint Test Action Group (JTAG). O qual faz a conexão para o acesso à memória flash do microcontrolador, e assim pôr o firmware em produção. Apesar de completa a biblioteca é complexa e densa. O uso da biblioteca requer um estudo aprofundado de baixo nível, o que torna o desenvolvimento demorado. O simples fato de precisar estudar como configurar as funções de cada pino, seja de entrada ou saída de uso geral ou de uma característica mais específica como uma interface SPI, torna o processo moroso Projeto MBED MBED é uma plataforma de desenvolvimento (FrameWork) em nuvem e foi iniciada por dois funcionários da ARM. A plataforma foi inspirada e desenvolvida para trabalhar com microcontroladores Advanced RISC Machine (ARM) de vários fabricantes como NXP, SMT, Nordic, entre outros 2. Sua interface oferece um excelente ambiente de trabalho, amigável e confiável, e oferece um editor de texto preparado para a linguagem C e C++, já com compilador, tudo isso on-line e sem custos. Para poder utilizar o FrameWork é preciso criar uma conta disponível em sua página 3. Todo o acesso aos serviços é oferecido gratuitamente, bastando fazer o ingresso em seu portal. A partir do ingresso, o usuário poderá escolher o kit de desenvolvimento e criar um projeto para iniciar a programar. Além do ambiente de trabalho, é oferecida e mantida uma comunidade com vários exemplos de aplicações para todos os kits disponíveis. A plataforma pode ser observada na figura 3.21, que traz a tela principal. Flexibilidade A plataforma, por ser apoiada em um sistema computacional em nuvem, proporciona uma poderosa flexibilidade. Qualquer sistema operacional que possua navegação na internet é um

62 3.4 Kit de desenvolvimento LPC Figura 3.21: Ambiente MBED, tela principal. potencial sistema para poder utilizar o MBED, sem a necessidade de instalação de pacotes extras. O usuário pode iniciar seu projeto em um sistema Linux e terminá-lo projeto em um sistema Windows, sem que precise instalar ou migrar qualquer código fonte. Também é possível migrar para um hardware diferente, caso o mercado ofereça um outro por um valor mais acessível. Para migrar de uma plataforma para outra, o FrameWork dispõe de acesso fácil à migração. A figura 3.22 ilustra como se pode alternar facilmente entre plataformas. Programação facilitada O projeto MBED provê classes em linguagem C++ que permitem criar objetos específicos para as variadas aplicações que os kits dispõe. Essas classes fazem uma abstração ao acesso de baixo nível. A implementação de uma interface SPI, por exemplo, pode ser feita totalmente em alto nível, ficando para as classes disponíveis no projeto MBED, a responsabilidade de fazer as configurações dos registradores competentes para cada aplicação. Não se preocupar com detalhes de baixo nível em um microcontrolador, pode acelerar o desenvolvimento de uma aplicação, já que o estudo de bibliotecas específicas são densas e, muitas vezes complexas, com poucos exemplos e suportes para o desenvolvedor.

63 3.4 Kit de desenvolvimento LPC Figura 3.22: Ambiente de escolha da plataforma. Confiabilidade Por se tratar de uma plataforma computacional em nuvem, não há a necessidade de salvar projetos em disco local. Todos os projetos ficam disponíveis em um ambiente virtual. Caso ocorra algum sinistro no ambiente de trabalho, todo o projeto pode ser rapidamente acessado em outra máquina de trabalho íntegra, sem que seja preciso instalar qualquer ferramenta de desenvolvimento ou backup Discussão Após os estudos dos componentes e das ferramentas de desenvolvimento, se fez necessário uma discussão sobre esses. SLIC Microsemi versus SLIC Silicon Laboratories Já no primeiro momento, tomou-se de partida os estudos da família de SLICS da Silicon Laboratories, especificamente o si Isso devido a uma pequena pesquisa de mercado. Em um primeiro contato via com um representante da Microsemi (ANEXO A) foi declarado que o SLIC VE8911 contemplado com a porta FXO tem problemas. O representante confirmou que houveram vários relatos de problemas em campo. Dessa forma, a decisão mais conservadora foi optar pelo si32179 da Silicon Laboratories.

64 3.5 Conclusão 63 Biblioteca NXP versus Projeto MBED Mesmo sendo uma biblioteca completa, a biblioteca NXP deixou de ser uma opção após o estudo do projeto MBED. Para se conseguir um resultado eficaz com a biblioteca NXP, seria necessário investir muitas horas de estudo em relação ao projeto MBED. O projeto MBED se mostrou uma opção simples e com todos os recursos necessários às implementações desse projeto. Além da vantagem de ser uma coletânea fácil e completa para a implementação do dispositivo de telefonia, o projeto MBED pode ser utilizado com kits que dispensam o uso de interfaces JTAG, o que torna mais prático o desenvolvimento. Além disso, a migração para um dispositivo suportado pelo MBED é muito simples, desde que o hardware suporte os requisitos da aplicação e aplicação utilize somente as abstrações providas pelo framework. Por exemplo, para migrar do LPC-1768 (Cortex-M3) para o LPC11U24 (Cortex-M0) é necessário poucos cliques no ambiente de desenvolvimento e a aplicação é compilada para o novo controlador. Como o LPC11U24 suporta USB Isochronous, um dos requisitos de hardware mais complexos, e SPI, ele se tornaria um forte candidato para ser o componente utilizado na produção, após uma fase de otimização do sistema, na procura por corte de custos. 3.5 Conclusão Nesse capítulo se efetuou um estudo específico sobre quais componentes e kits serão utilizados para contemplar uma futura interface de telefonia. O objetivo era conhecer o funcionamento e características sobre os dois principais componentes, que são o SLIC si32179 e o microcontrolador LPC1768. Além de conhecer os dispositivos, o capítulo tinha o escopo de avaliar o ambiente de desenvolvimento fornecido pela Silicon Laboratories, a fim de poder iniciar os estudos práticos com o SLIC. Também foi feita uma discussão sobre a possibilidade de se utilizar a biblioteca NXP ou o Projeto MBED. Através dessa discussão, pode-se perceber que o uso do Projeto MBED seria uma alternativa atrativa, devido sua característica de abstração de acesso aos recursos de baixo nível do microcontrolador. Com esses estudos, pode-se concluir o que é necessário para se pôr em prática a implementação dos blocos lógicos do firmware e a arquitetura do projeto lógico. Este vem na sequência, no próximo capítulo.

65 64 4 Arquitetura e Projeto Lógico Esse capítulo destina-se a demonstrar possíveis arquiteturas de sistemas que podem ser implementados com o dispositivo de telefonia, além do projeto lógico de hardware. 4.1 Arquitetura dos Sistemas O Projeto de Interface de Telefonia Analógica USB para sistemas VoIP foi pensado para atender pequenos sistemas de integração da rede de telefonia pública com a rede IP. Mesmo que seja um equipamento pequeno, o projeto pode atender e abranger variadas situações de uso, potencializando o uso de sistemas telefônicos analógicos e dando mais liberdade para novas aplicações Sistema Básico A arquitetura do Sistema Básico pode ser observado na figura 4.1. Nessa arquitetura é apresentada uma forma simplificada de uso, essa é a forma mais básica de aproveitamento do sistema. O aproveitamento dessa arquitetura é apenas por funções locais, como fazer uso do correio de voz da central telefônica IP, unidade de resposta audível (URA), agenda, gravação de ligações, tarifação, etc. Mesmo que sejam funções simples, temos nessa arquitetura uma potencial forma de utilização. Figura 4.1: Arquitetura sistema Básico.

66 4.1 Arquitetura dos Sistemas Sistema de utilização de recursos externos Uma outra arquitetura que pode ser observada é a Sistema de utilização de recursos externos, conforme pode ser vista na figura 4.2. Além de contemplar o mesmo propósito que a arquitetura Sistema Básico, é possível incrementar o uso do sistema. Todas as funções agora podem ser usufruídas externo ao ambiente local. Um usuário com acesso à internet, pode obter os recursos do seu sistema telefônico remotamente. Assim duas novas funções foram inseridas ao sistema: Função 1: - mesmo que fora de sua residência a linha telefônica está disponível para efetuar ou receber ligações, visto que a interface FXO integra a PSTN à rede IP. Função 2: - também é possível efetuar uma ligação para o terminal telefônico ligado à interface FXS, o que caracteriza uma ligação gratuita. O que, do ponto de vista econômico, torna o sistema muito atrativo com essas duas novas funções. Além de poder atender ligações destinadas à sua residência em qualquer local que haja acesso à internet. Figura 4.2: Arquitetura do sistema de utilização de recursos externos Sistema de utilização de compartilhamento de recursos A arquitetura Sistema de utilização de compartilhamento de recursos vem a ser o sistema mais completo, conforme ilustra a figura 4.3. Nesse tipo de sistema pode-se operar com todas as facilidades dos sistemas anteriores.

67 4.2 Projeto Lógico do Hardware 66 O que diferencia nessa arquitetura é o atributo de poder compartilhar recursos. Com uma integração entre várias centrais telefônicas IP utilizando a internet, os recursos do sistema telefônico podem ser compartilhados, um vez que as interfaces de telefonia nas extremidades dão subsídios ao acesso à PSTN. Para que o compartilhamento ocorra, é preciso que um agente faça o controle dos acessos e gerenciamento dos recursos. O atual trabalho permite que essa integração seja feita com maior facilidade, agilidade e com reduções de custos, pois o projeto é caracterizado pelo seu sistema simples, barato, no nível de usuário e de fácil instalação. Figura 4.3: Arquitetura sistema de utilização de compartilhamento de recursos. 4.2 Projeto Lógico do Hardware Nessa etapa foram definidos os componentes do sistema levando em consideração os requisitos da plataforma proposta. A parte circulada na figura 4.4 demonstra, de maneira simplificada, um diagrama do sistema proposta pelo projeto. O SLIC faz a interface com a PSTN e com o aparelho telefônico ao sistema. O microcontrolador controla a inicialização e configuração do SLIC, cria uma interface de controle (ex.: sinalização da interfaces) e uma interface de dados (voz digitalizada) via USB para inteiração com o driver. O driver, por sua vez, disponibiliza a interface para acesso e controle da central telefônica implementada em espaço de usuário. No caso do Asterisk, por exemplo, o módulo DAHDI controlaria o hardware via USB para integrar as portas analógicas com os serviços da central telefônica IP. A implementação do sistema completo é bastante complexo, envolvendo várias áreas do conhecimento, como por exemplo, projeto e implementação de hardware, firmware e driver. Além da modificação da aplicação que implementa a central telefônica IP. Dessa forma, esse trabalho se limitou em aprofundar o estudo do SLIC e de um microcontrolador capaz de executar as tarefas já comentadas.

68 4.3 Conclusão 67 Figura 4.4: Diagrama do sistema proposto pelo projeto Elaboração do projeto lógico Para uma visão mais abstrata do hardware (SLIC + Microcontrolador) foi gerado um diagrama de blocos, conforme visto na figura 4.5. A função do diagrama é ser utilizada como referência para saber quais são os componentes necessários para a implementação do circuito e, também, para a geração futura de um esquemático e layout para fabricação de uma placa de circuito impresso. O diagrama lógico também serviu de referência para orientar as ligações físicas entre as placas de desenvolvimento utilizadas durante os experimentos. Figura 4.5: Projeto lógico do dispositivo de telefonia. 4.3 Conclusão Com esse capítulo, pode-se ter uma visão geral de como o dispositivo serviria a possíveis cenários, sugerindo algumas soluções de uso em um sistema SOHO. Esses cenários ilustram

69 4.3 Conclusão 68 o problema proposto dando origem ao diagrama do sistema proposto pelo projeto, culminando em um projeto lógico do hardware. Esse, por sua vez, pode ser utilizado como referência para uma futura prototipagem de uma placa de circuito impresso, pelo qual se pode obter um produto comercial.

70 69 5 Experimento Este capítulo descreve quais os procedimentos efetuados para avaliar o hardware e o software proposto para o sistema de telefonia. O objetivo é verificar se o microcontrolador LPC e o SLIC si32179 atendem às necessidades de implementação para controle do dispositivo de telefonia. Na primeira etapa foram feitos testes com o kit VMB2 REV 2.0 no modo placa mãe, hospedando o kit Si32179BFB11SL0EVB (placa filha) e utilizando o software ProSLIC Voice GUI para controlar os kits. Os kits VMB2 REV 2.0 e Si32179BFB11SL0EVB e o software ProSLIC Voice GUI foram estudados na sessão 3.2. Esse primeiro passo submeteu o si32179 a testes de inicialização e testes funcionais, utilizando a ferramenta que o fabricante recomenda para início dos estudos. Com esse procedimento é possível avaliar se todos os componentes estão operando sem problemas, para então utilizar o hardware e firmware propostos para o sistema de telefonia. A segunda etapa dos experimentos foi utilizar o microcontrolador LCP-1768 Cortex-M3 e o firmware desenvolvido na plataforma MBED para controlar o si32179 que está disponível no kit Si32179BFB11SL0EVB. Nessa etapa o kit VMB2 REV 2.0 ficou como elemento passivo, ou seja, ele operou no modo fonte de energia. Com isso, todos os recursos do si32179 foram controlados diretamente pelo microcontrolador LCP-1768 Cortex-M3, dando acesso total para o firmware aos registradores e memória RAM do SLIC. O objetivo da segunda etapa era testar os blocos funcionais separadamente. Portanto, houve um experimento para avaliar a interface USB, um outro experimento para avaliar a interface SPI e, por último, um experimento para avaliar o barramento PCM.

71 5.1 Experimentos Primeira Etapa - Placa Filha no Modo Hospedeiro Experimentos Primeira Etapa - Placa Filha no Modo Hospedeiro Nessa primeira parte do experimento o intuito foi utilizar todas as ferramentas (kits e softwares) disponibilizadas pela Silicon Laboratories. Esse experimento é de muita importância para o desenvolvimento, pois avalia a integridade dos componentes e traz exemplos de como eles se comportam com uma solução de testes inteiramente do fabricante Experimento 1 - Utilização do software ProSLIC Voice GUI A figura 5.1 ilustra o cenário utilizado nesse teste. Essa facilita a compreensão sobre o experimento efetuado. Figura 5.1: Configuração física do cenário para o experimento da placa filha no modo hospedeiro. Objetivo do Experimento: O escopo desse experimento é verificar se a placa filha está operando dentro das condições normais, além de obter exemplos do funcionamento esperado do componente si Para efetuar os testes, foi utilizado o software ProSLIC Voice GUI.3.4.0, que a Silicon Laboratories fornece sob NDA. Procedimento: Em um ambiente Windows, foi instalado o software ProSLIC Voice GUI Ao conectar a interface USB do kit VMB2 REV 2.0, foi solicitado instalar o driver da unidade controladora, para que o software ProSLIC Voice GUI pudesse acessar as funcionalidades do kit. Após a instalação do driver os testes evoluíram da seguinte forma: Inicialização do si32179: O processo de inicialização do SLIC foi carregar um script

72 5.1 Experimentos Primeira Etapa - Placa Filha no Modo Hospedeiro 71 fornecido pela Silicon Laboratories. O script trata-se do arquivo Si32179FB.txt, o qual contém uma lista de valores pré-definidos pelo fabricante para aferir cada endereço de registrador e memória RAM responsáveis por inicializar o componente. Além dos valores a serem carregados, o script possui rotinas para que cada valor seja inserido nos tempos corretos. Após a carga desse arquivo pelo software ProSLIC Voice GUI.3.4.0, um upload é feito para o si A interface indica se esse procedimento foi efetuado com sucesso ou não. Com o script carregado, o kit possibilitou ao software efetuar o uso das funções do SLIC. Verificar valores dos endereços dos registradores e endereços da memória RAM: Com o sistema operando, foi utilizado a função Continous Read do ProSLIC Voice GUI Para utilizar essa função foi preciso pressionar o botão Read All, assim temos os valores de todos os registradores e endereços da memória RAM em tempo real. Testes de ocupação do circuito : O teste de ocupação do circuito foi efetuado com um terminal telefônico conectado ao RJ-11 (conector J1) correspondente a interface FXS. Retirando o terminal de seu repouso foi observado as alterações dos registradores: SPEEDUP (REG 33): - valor alterado de 10 para 0; LCRRTP (REG 34): - valor alterado de 0 para 2; BATSEL (REG 37): - valor alterado de 12 para 10; e PDN STAT (REG 99): - valor alterado de 5 para 4. Geração de ring: A ferramenta ProSLIC Tools do software ProSLIC Voice GUI tornou possível configurar as características do formato de onda do sinal de ring e as cadências utilizadas. Após a configuração foi utilizado a opção Linefeed Status, que dispõe de um botão para ativar o ring previamente configurado; Geração do tom (discagem, chamada): Na ferramenta ProSLIC Tools foi utilizado a opção Tone Generator. Essa opção possibilita a configuração de dois osciladores, nesses foi possível configurar as frequências, cadências desejadas e amplitude do sinal. Para o teste, foi configurado os valores: Oscilador 1 - amplitude -18 dbm, frequência 425 Hz, sinal presente 1 s e sinal ausente 4 s; e Oscilador 2 - amplitude -18 dbm, frequência 0 Hz, sinal presente 0 s e sinal ausente 0 s.

73 5.1 Experimentos Primeira Etapa - Placa Filha no Modo Hospedeiro 72 Esses valores simularam um tom de chamada no padrão brasileiro e, em seguida, foi efetuado um teste para simular o tom de discagem para o padrão brasileiro, para o qual foi utilizado os seguintes valores: Oscilador 1 - amplitude -18 dbm, frequência 425 Hz, sinal presente 1 s e sinal ausente 1 s; e Oscilador 2 - amplitude -18 dbm, frequência 0 Hz, sinal presente 0 s e sinal ausente 0 s. Com um terminal telefônico conectado ao RJ-11 (conector J1), foi possível ouvir todos os sinais, e com o auxílio de um osciloscópio foi aferido os valores nominais. Coleta do DTMF gerado por um terminal telefônico: Para esse teste também foi utilizado um terminal telefônico conectado ao RJ-11 (conector J1). Foram testados todos os valores DTMFs disponíveis no teclado desse terminal e verificado o comportamento do registrador TONDTMF (REG 60), os quais seguem: Tecla 1: - alterado de 0 para 31 - tecla em repouso, valor é alterado para 1; Tecla 2: - alterado de 1 para 32 - tecla em repouso, valor é alterado para 2; Tecla 3: - alterado de 2 para 33 - tecla em repouso, valor é alterado para 3; Tecla 4: - alterado de 3 para 34 - tecla em repouso, valor é alterado para 4; Tecla 5: - alterado de 4 para 35 - tecla em repouso, valor é alterado para 5; Tecla 6: - alterado de 5 para 36 - tecla em repouso, valor é alterado para 6; Tecla 7: - alterado de 6 para 37 - tecla em repouso, valor é alterado para 7; Tecla 8: - alterado de 7 para 38 - tecla em repouso, valor é alterado para 8; Tecla 9: - alterado de 8 para 39 - tecla em repouso, valor é alterado para 9; Tecla 0: - alterado de 9 para 3A - tecla em repouso, valor é alterado para A; Tecla *: - alterado de A para 3B - tecla em repouso, valor é alterado para B; e Tecla #: - alterado de B para 3C - tecla em repouso, valor é alterado para C. Durante todos os testes, foram coletados os principais sinais (PCLK FSYNC, RESET, SCLK, MOSI, MISO, SS e INT) do kit com o auxílio de um osciloscópio. O objetivo era comparar o formato de onda dos sinais originados pelo sistema de desenvolvimento da Silicon Laboratories, com os que o hardware e o firmware externo produziram.

74 5.2 Experimentos Segunda Etapa - Placa Filha Modo Standalone 73 Análise dos resultados: De acordo com a documentação fornecida pela Silicon Laboratories e com os padrões estabelecidos na telefonia brasileira, todos os resultados saíram como o esperado. Essa bateria de testes serviu para conhecer melhor as placas de desenvolvimento e componentes, além de validar se todos os elementos, que implementam o dispositivo de telefonia, estavam íntegros. Para efetuar o experimento e avaliar todos os resultados foi preciso o estudo sobre os kits de desenvolvimento e a documentação auxiliar para o uso do software ProSLIC Voice GUI Experimentos Segunda Etapa - Placa Filha Modo Standalone Esta sessão apresenta as avaliações de cada bloco funcional de interface, como por exemplo, interface USB, interface SPI e barramento PCM. O objetivo foi verificar o comportamento de cada um dos blocos utilizando os componentes e placas de desenvolvimento estudados. Nesta etapa a placa filha com o SLIC foi controlada pelo firmware desenvolvido na plataforma MBED Experimento 1 - Avaliação da interface USB Objetivo do Experimento: Para esse experimento foi reservada o objetivo de avaliar se a implementação da interface USB no modo Isochronous, desenvolvida pelo projeto MBED, foi bem sucedida e se atende os requisitos necessários. O desejado nesse experimento é conseguir transmitir amostras de áudio para um driver 1 de som no Windows e reproduzí-las com o auxílio do software livre Audacity 2. Procedimento: Para validar se o microcontrolador conseguiu implementar um USB device no modo Isochronous, foi criado um vetor de inteiros no firmware com amostras de 8 bits cada, o que equivale a um segundo de áudio. As amostras foram obtidas a partir do software matemático Matlab lendo um arquivo de áudio. Como essas amostras possuíam os valores em níveis não codificados, foi feita uma multiplicação de cada amostra pelo valor 127, criando, assim, valores de uma codificação PCM linear. Para a estrutura desse bloco lógico, não faz diferença se o dado é de um codec utilizando PCM linear ou PCM-A, pois o que se pretendia avaliar era possibilidade de se manipular e enviar cada amostra separada umas das outras, já que é dessa forma que o SLIC fornece as amostras de áudio. Mediante o método write((uint8 t *)buf), que está disponível na classe USBAudio fornecida

75 5.2 Experimentos Segunda Etapa - Placa Filha Modo Standalone 74 pela plataforma MBED, pode-se enviar, a partir do microcontrolador, amostras de áudio para o computador. Já com o método read((uint8 t *)buf) é possível receber amostras do computador para o microcontrolador, fazendo as duas vias de áudio (DRXa e DTXa) entre o SLIC e o computador. O driver utilizado para fazer os testes é disponibilizado pela MBED, e as amostras do áudio são visíveis na figura 5.2. Figura 5.2: Reprodução de um segundo de áudio enviado via USB. Análise dos resultados: Após coletar as amostras com o auxílio do Audacity, foi possível reproduzí-las e analisar se o áudio havia sido transferido corretamente. As amostras de áudio contidas no Audacity nos revelaram que a transferência ocorreu com sucesso. O que sugere ser viável o uso da classe USBAudio para a transferência no modo Isochronous Experimento 2 - Avaliação da interface SPI Objetivo do Experimento: Esse experimento tem o objetivo de avaliar a comunicação SPI entre o microcontrolador LPC-1768 e o SLIC si Com uma rotina de leitura e escrita inserido em determinado registrador um valor conhecido e depois efetuar leitura para ser comparado ao dado inicial. Procedimento: Utilizando a classe SPI do projeto MBED e da Proslic API, foi implementado um driver SPI no LPC-1768 compatível com a interface SPI do si A frequência utilizada no barramento foi de 186 KHz, o que nos dá uma taxa de transferência de 186 Kbps. Outras taxas também foram testadas como 512 KHz (512 Kbps) e 1 MHz (1 Mbps), obtendo-se o mesmo resultado. A figura 5.3 ilustra a captura dos sinais SCLK (canal 1) e SS (canal 2) com o auxílio do osciloscópio. No teste de escrita foi utilizado o endereço 14 do registrador com o dado 0x40 (decimal 64, binário ). A coleta do sinal MOSI é ilustrada na figura 5.4, onde os valores foram

76 5.2 Experimentos Segunda Etapa - Placa Filha Modo Standalone 75 Figura 5.3: Sinais SCLK (canal 1) e SS (canal 2). transferidos corretamente. Para a melhor visualização, foi feita uma ampliação do sinal MOSI na figura 5.5. Figura 5.4: Escrita REG 14. Sinais SCLK (canal 1) e MOSI (canal 2). Figura 5.5: Escrita REG 14. Sinais SCLK (canal 1) e MOSI (canal 2) ampliados. Para ajudar a entender a escrita no SLIC, foi realizado também a coleta do sinal MISO. Porém, como a operação é de escrita, o sinal MISO não tem nenhuma perturbação, ou seja, nenhuma alteração é percebida no byte de controle, no byte de endereço e no byte de dados, pois o SLIC recebeu no sinal MOSI uma operação de escrita. Isso é percebido na figura 5.6.

77 5.2 Experimentos Segunda Etapa - Placa Filha Modo Standalone 76 Figura 5.6: Escrita REG 14. Sinais SCLK (canal 1) e MISO (canal 2). Foi feito também um teste de leitura com o REG 3 (registrador responsável pela avaliação dos sinais PCLK e FSYNC, que são sinais do barramento PCM). Sendo esse um registrador somente de leitura. Foi obtida uma amostra do sinal MOSI, por meio do qual foi enviado o byte de leitura 0x60, seguido do byte de endereço 3. Como a operação é de leitura, o byte de dado não é relevante. A figura 5.7 mostra o sinal MOSI na operação de leitura e a figura 5.8 ilustra a ampliação do sinal para facilitar a avaliação. Figura 5.7: Leitura REG 3. Sinais SCLK (canal 1) e MOSI (canal 2). A operação de leitura é o único momento em que o sinal MISO é aferido e apenas o byte de dado é avaliado, tornando os outros dois bytes antecedentes do sinal MISO obsoletos. A figura 5.9 apresenta o sinal MISO coletado, pelo qual se constata o valor 0x1F (decimal 31, binário ). Uma ampliação do sinal também pode ser visualizada na figura Ainda foi realizada a leitura do registrador 14 e obteve-se o mesmo valor enviado na operação de escrita (valor 0x40), o que nos mostra que o barramento SPI está operando nas condições desejadas. Os testes foram feitos várias vezes, por longos períodos e sempre foram

78 5.2 Experimentos Segunda Etapa - Placa Filha Modo Standalone 77 Figura 5.8: Leitura REG 3. Sinais SCLK (canal 1) e MOSI (canal 2) ampliados. Figura 5.9: Leitura REG 3. Sinais SCLK (canal 1) e MISO(canal 2). Figura 5.10: Leitura REG 3. Sinais SCLK (canal 1) e MISO (canal 2) ampliados.

79 5.2 Experimentos Segunda Etapa - Placa Filha Modo Standalone 78 alcançados os mesmos resultados. Isso indica que a interface SPI implementada a partir da plataforma MBED é confiável para ser usada na interface com o SLIC. Análise dos resultados: As análises dos sinais feitas no procedimento foram comparadas com os dados coletados nesse experimento. Como a sessão é totalmente baseada na solução do fabricante (hardware e software) e os sinais comparados tiveram o mesmo formato, pode-se afirmar que o experimento obteve êxito. Como o que se esperava era ter uma comunicação segura e confiável entre os componentes envolvidos, os testes mostraram que a implementação do barramento SPI pode ser utilizada sem problemas. Depois de ter uma interface de comunicação confiável, foi possível extrair a coleta do REG 3 (MSTRSTAT) para dar subsídios aos testes seguintes Experimento 3 - Avaliação do barramento PCM O cenário para o experimento de avaliação do barramento PCM pode ser visualizado na figura Essa facilita a compreensão sobre o experimento efetuado. Objetivo do Experimento: O escopo desse experimento é verificar se os sinais PCLK e FSYNC gerados pelo LPC-1768 foram validados pelo SLIC si Como trata-se de sinais que estabelecem sincronismo para circuito, esses sinais são a todo tempo verificados si O diagnóstico desses sinais é disponibilizado pelo si32179 no REG 3 (MSTRSTAT), o significado de cada valor é obtido na documentação fornecida pela Silicon Laboratories (Documentação cedida por cortesia pela Silicon Labs O experimento foi dividido em dois estágios: Estágio 1: Valor de FSYNC nominal - sinal FSYNC com frequência de 8 KHz (64 períodos de PCLK); e Estágio 2: Valor de FSYNC arbitrário - sinal FSYNC com frequência de 16 KHz (32 períodos de PCLK) O que se espera na primeira parte é obter o valor do REG 3 com dados que indiquem o pleno funcionamento do barramento PCM. No entanto, para a segunda parte, o que se espera é obter valores que indiquem algum problema no barramento PCM, já que foi usado um valor fora dos padrões do dispositivo. Assim é possível confirmar se o barramento foi implementado corretamente. Procedimento Estágio 1: No barramento PCM foram avaliados os sinais PCLK e FSYNC

80 5.2 Experimentos Segunda Etapa - Placa Filha Modo Standalone 79 Figura 5.11: Configuração física do cenário para a avaliação do barramento PCM.

81 5.2 Experimentos Segunda Etapa - Placa Filha Modo Standalone 80 (figura 5.12). Para uma melhor visualização do sinal PCLK, a figura 5.13 traz uma ampliação deste. Esses sinais foram construídos a partir das ferramentas disponíveis no MBED. O sinal utilizado no PCLK foi de 512 KHz, resultando em 4 timeslots. O sinal FSYNC foi obtido por meio da fórmula 3.1, na qual cada 64 pulsos do sinal PCLK constituem um período do sinal FSYNC. Para um sinal com formato de onda de 8 KHz, com 50% de nível lógico alto e 50% de nível lógico baixo, é preciso dividir os 64 pulsos por 2, e isso nos dá 32 pulsos em nível lógico alto e 32 pulsos em nível lógico baixo. Foi utilizado um sinal de interrupção para contar 32 bordas de subida do sinal PCLK para manter o sinal FSYNC em nível lógico alto e 32 em nível lógico baixo. Como é possível contar cada nível de subida do sinal PCLK, também é possível saber o início e fim de cada timeslot para aferir os sinais DRXa e DTXa. Figura 5.12: Sinais PCLK (canal 1) e FSYNC (canal 2). Figura 5.13: Sinais PCLK (canal 1) e FSYNC (canal 2), ampliados. Em todos os testes foi avaliado o valor do registrador 3 (MSTRSTAT), que é responsável por nos informar o comportamento dos sinais PCLK e FSYNC. Enquanto se operou dentro