UFSC – UNIVERSIDADE FEDERAL DE SANTA CATARINA

PREG – PRÓ-REITORIA DO ENSINO DE GRADUAÇÃO

CURSO DE CIÊNCIAS DA COMPUTAÇÃO

Trabalho de Conclusão de Curso

Odyr Apoena Bernanos de Zayas Sohn

Florianópolis – SC

2011

UNIVERSIDADE FEDERAL DE SANTA CATARINA

Desenvolvimento de aplicativo do driver sintonizador

com diversidade para Linux embarcado em Set Top

Box

Odyr Apoena Bernanos de Zayas Sohn

Florianópolis – SC

2011

2

UNIVERSIDADE FEDERAL DE SANTA CATARINA DEPARTAMENTO DE INFORMÁTICA E ESTATÍSTICA

CURSO DE CIÊNCIAS DA COMPUTAÇÃO

Desenvolvimento de aplicativo do driver sintonizador com

diversidade para Linux embarcado em Set Top Box

Odyr Apoena Bernanos de Zayas Sohn

Trabalho de conclusão de curso apresentado como parte dos requisitos para obtenção do grau de Bacharel em Ciências da Computação.

Carlos Aurélio Faria da Rocha, Dr.

Orientador

Florianópolis - SC 2011

v

Título: Desenvolvimento de aplicativo do driver sintonizador com diversidade

para Linux embarcado em Set Top Box

Aluno: Odyr Apoena Bernanos de Zayas Sohn

Banca Examinadora:

____________________________________

Prof. Carlos Aurélio Faria da Rocha, Dr. Orientador

____________________________________

Prof. Antônio Augusto Fröhlich, Dr.

____________________________________

Prof. Raimes Moraes, Ph.D.

vi

SUMÁRIO

Resumo .............................................................................................................. vii

Figuras .............................................................................................................. viii

Códigos .............................................................................................................. ix

Siglas ................................................................................................................... x

1 Introdução .................................................................................................. 1

2 Fundamentação Teórica ............................................................................ 6 2.1 Sistema Operacional Linux .......................................................................... 6 2.2 Drivers para Linux ........................................................................................ 9 2.3 Plataforma de Desenvolvimento da ST (STAPISDK) ................................. 10 2.4 Set Top Box ............................................................................................... 11 2.5 Sistema de Transmissão de TV-Digital ISDB-T ......................................... 13 2.6 Sintonizador de TV-Digital ......................................................................... 15 2.7 Protocolo de Comunicação I2C .................................................................. 19 2.8 Ferramentas Utilizadas .............................................................................. 21 2.8.1 Picocom ..................................................................................................... 21 2.8.2 U-Boot ........................................................................................................ 22 2.8.3 i2c-tools ..................................................................................................... 23

3 Desenvolvimento ..................................................................................... 24 3.1 Compilando as Imagens do STLinux e do U-Boot ..................................... 24 3.2 Embarcando o U-Boot ............................................................................... 26 3.3 Adaptação do Driver para o Sintonizador SIRDAI ..................................... 30 3.4 Criação do aplicativo sintonizador ............................................................. 35 3.5 Integração do Aplicativo Sintonizador com a STAPI .................................. 37

4 Conclusão ................................................................................................ 42

REFERÊNCIAS .................................................................................................. 44

ANEXOS ............................................................................................................. 45 ARTIGO.............................................................................................................61

vii

Resumo

A necessidade de uma melhor recepção do sinal digital motivou o

projeto SIRDAI-TVD a desenvolver um novo sintonizador com sistema de

recepção com diversidade. O sintonizador produzido foi instalado em um Set

Top Box de uso doméstico e facilmente encontrado no mercado. Este

trabalho apresenta procedimentos para embarcar um sistema operacional

Linux em um Set Top Box. Abordando desde a utilização de ferramentas para

diagnóstico do protocolo I2C e comunicação serial RS-232, assim como

procedimentos para compilar o U-Boot e o STLinux para a arquitetura Super-

H (SH4) do chip STi7109. A pesquisa também apresenta informações sobre o

sistema ISDB-T, objetivando a programação de funcionalidades relacionadas

a banda e frequência no rastreamento e sintonização de canais do SBTVD. O

estudo sugere diretrizes de como implementar, em linguagem C, um

aplicativo para o sintonizador com chip de diversidade de recepção. O

aplicativo terá a finalidade de sintonizar e rastrear canais do sistema

brasileiro de transmissão terrestre de TV-Digital no padrão ISDB-T executado

em um Set Top Box.

Palavras-chave: Sistemas Operacionais, Sistemas Embarcados, Linux, Set

Top Box, TV Digital, Transmissão Digital Terrestre, ISDB-T, STLinux, SH4,

Super-H.

viii

Figuras

FIGURA 1 - EXEMPLO DE CAMADAS DO KERNEL DO LINUX. .......................................... 8

FIGURA 2 - ORGANIZAÇÃO DE CAMADAS DA STAPISDK ........................................... 11

FIGURA 3 – EXEMPLO DE UM DIAGRAMA DE BLOCOS DE STB. .................................... 12

FIGURA 4 - STB PROVIEW XPS-1000 UTILIZADO NESTE TRABALHO. .......................... 12

FIGURA 5 – DIAGRAMA BÁSICO PARA TRANSMISSÃO DO SINAL ISDB-T. ...................... 13

FIGURA 8 - ATRASO DEVIDO O CAMINHO PERCORRIDO PELO FLUXO DE DADOS. ........... 18

FIGURA 9 - SINTONIZADOR SIRDAI COM DOIS SOCS DIBCOM DIB8096. ................. 19

FIGURA 10 - EXEMPLO DO BARRAMENTO I2C............................................................ 20

FIGURA 11 - DIAGRAMA DE SINAIS PROTOCOLO I2C.................................................. 20

FIGURA 13 - SISTEMA MESTRE/ESCRAVO DOS CHIPS COM DIVERSIDADE. .................... 34

FIGURA 14 - CAMADAS DO LINUX, APLICATIVO SINTONIZADOR, STAPP. ..................... 41

FIGURA 15 - SEGMENTAÇÃO DO CANAL EM FORMATO ISDB-T. .................................. 56

FIGURA 16 - EXEMPLO DE DIAGRAMA DE BLOCOS DE UM FONT-END RECEPTOR .......... 57

FIGURA 17 - EXEMPLO DE DIAGRAMA DE BLOCOS DE UM BACK-END RECEPTOR. ......... 57

FIGURA 18 - INDICAÇÃO DOS POLOS PARA O CONECTOR TTL NA PLACA DO STB. ........ 59

FIGURA 19 - VISÃO GERAL DO EQUIPAMENTO UTILIZADO.. ......................................... 59

FIGURA 20 - DETALHE DO SINTONIZADOR SIRDAI. ................................................... 60

FIGURA 21 - DETALHE DA CONEXÃO DO SINTONIZADOR SIRDAI ................................ 60

ix

Códigos

CÓDIGO 1 - UTILIZAÇÃO BÁSICA DO APLICATIVO PICOCOM. ................................................ 21

CÓDIGO 2 - CÓDIGO PARCIAL DE CONFIGURAÇÃO DA STAPISDK. ..................................... 25

CÓDIGO 3 - SEQUENCIA DE COMANDOS PARA COMPILAR O KERNEL DO STLINUX. ................ 26

CÓDIGO 4 - SEQUENCIA DE COMANDOS PARA COMPLIAR O U-BOOT PARA SH4. .................. 26

CÓDIGO 5 - TERMINAL 1, COM O CARREGAMENTO DO U-BOOT. .......................................... 28

CÓDIGO 6 - TERMINAL 2, COM A SAÍDA DA CONEXÃO SERIAL NO STB. ................................. 29

CÓDIGO 7 - PROCEDIMENTOS DE CONFIGURAÇÃO MANUAIS PARA O BOOT VIA NFS ............. 30

CÓDIGO 8 - UTILIZAÇÃO DO I2C-TOOLS, PARA RASTREAMENTO DE ENDEREÇOS. ................. 31

CÓDIGO 9 - PSEUDO-ALGORITMO PARA ESCRITA DOS ATRASOS NOS CHIPS. ........................ 33

CÓDIGO 10 - PSEUDO-ALGORITMO PARA IMPLEMENTAÇÃO DO SISTEMA MESTRE/ESCRAVO. . 35

CÓDIGO 11 - PSEUDO-ALGORITMO PARA IMPLEMENTAÇÃO DO APLICATIVO RASTREADOR. .... 36

CÓDIGO 12 - SEQUENCIA DE COMANDOS PARA COMPILAR E INSTALAR O STLINUX ............... 37

CÓDIGO 13 - PARTES MODIFICADAS DO ARQUIVO STAPISDK/STAPP/MAKEFILE ..................... 38

CÓDIGO 14 - SAÍDA DO APLICATIVO RASTREADOR DE CANAIS ISDB-T. ............................... 39

CÓDIGO 15 - EXEMPLO DE UTILIZAÇÃO DO PIPE COM FILE DESCRIPTOR NO LINUX. ............ 40

x

Siglas

ST STMicroeletronics

STAPI Interface de programação de aplicativos da ST

STAPISDK

STM

Kit de desenvolvimento de aplicativos da STAPI

STMicroeletronics

STB

SO

TVD

SIRDAI-TVD

IIC

Set Top Box

Sistema Operacional

Sistema de Televisão Digital

Sistema de Recepção com Diversidade e Antenas

Inteligentes para TV Digital

Protocolo de Comunicação Inter-Integrated Circuit

1

1 INTRODUÇÃO

A TV Digital é uma realidade no mundo inteiro, porém a maioria dos

países1 está em processo de transição tecnológica. É o caso do Brasil que

em 2007 instituiu o padrão ISDB-T2, sendo que São Paulo foi a primeira

cidade brasileira a disponibilizar o sinal de TVD. Atualmente, os olhares estão

voltados para 2016, data prevista para o switch-off do modelo analógico, ou

seja, plena ativação da transmissão digital.

Além de transmitir a programação tradicional das emissoras de TV, a TV

Digital possui características diferenciadas para os espectadores, não só na

qualidade de experiência audiovisual, mas também na acessibilidade e

possibilidade de interação. Com relação a interatividade, em Portugal, foram

realizadas experiências com interatividade no âmbito da TV a Cabo, relatadas

no livro de Nuno Bernardo, “O guia prático da produção de televisão

interactiva”. A definição de TV Digital Interativa, ou TVDI, de acordo com o

autor, é a seguinte:

“A Televisão Digital Interactiva (iTV – Interactive Television) permite que o telespectador possa interagir com uma aplicação que é entregue em complemento ao sinal de televisão, através de uma rede digital, que pode ser satélite digital, cabo digital ou digital terrestre. Esse é o resultado da união da televisão tradicional e o poder da Internet através da adição de elementos interactivos a programas de TV tradicionais.... A Interactividade varia de programa para programa, mas o telespectador poderá obter mais informações sobre o programa que está a visualizar, votar em

1 Há uma lista no Anexo A citando alguns países e seus respectivos prazos de

implantação da TV Digital. 2 Padrão de transmissão digital terrestre de serviços integrados.

2

sondagens, enviar mensagens para os apresentadores do programa ou colocar uma questão directamente ao entrevistado de um talk show”. (BERNARDO, 2002, p. 16)

Os aparelhos decodificadores destinados ao uso doméstico, utilizados

no âmbito da TV Digital, são os chamados Set Top Box, ou STB. Este pode

ser ligado à maioria dos televisores brasileiros. Predicados importantes, como

a interatividade, se tornam mais fáceis de desenvolver devido à flexibilidade

da utilização de sistemas operacionais embarcados nos Set Top Boxes. O

sistema operacional Linux desempenha um papel muito importante nesta

área de aplicação, sendo popularmente utilizado nestes dispositivos.

No final dos anos 90 alguns usuários de TV a cabo já estavam

utilizando Linux embarcado em sistemas de captura e decodificação de TVs a

cabo nos Estados Unidos da América. Inicialmente, estes aparelhos eram

utilizados para burlar os sistemas de bloqueio das companhias de TV a cabo

e disponibilizar o sinal para usuários que não pagavam pelo serviço. Isto

demonstra a flexibilidade da utilização do SO Linux, sendo que os

desenvolvedores contavam com um sistema conhecido, suportes e drivers

básicos, além da possibilidade de programarem em linguagens como C,

facilitando depuração e produção de software para o dispositivo embarcado.

Quando se trabalha com sistemas embarcados, são comuns os casos

em que o SO Linux não possua suporte a algum hardware específico. Este

pode ter sido fabricado exclusivamente para o sistema embarcado, logo,

surge a necessidade de desenvolver um driver para este hardware ou

dispositivo ligado ao sistema. Com um driver, é possível acessar e disparar

funcionalidades específicas daquele hardware de maneira homologada pelo

seu fabricante. Ocasionalmente, pode ocorrer a omissão, pelos fabricantes,

de especificações técnicas do dispositivo, dificultando muito o

desenvolvimento do driver que usufrua corretamente de suas

3

funcionalidades. Nestes casos, é preciso utilizar técnicas de engenharia

reversa para adquirir informações necessárias à criação do driver.

Os sistemas embarcados, Set Top Boxes, cuja principal funcionalidade

é receber o sinal da TV Digital, decodificar, descompactar este sinal

decodificado e mostrar a imagem ao expectador, não se limitam a apenas

estas funções básicas. Várias funcionalidades extras são desenvolvidas nos

sistemas operacionais Linux embarcados nos STBs. Um exemplo é a

gravação de programas da TV Digital, em horários pré-programados,

armazenando-os em dispositivos e mídias removíveis, como pendrives USB.

Outra aplicação é a interação com o usuário, como enquetes, por exemplo,

em que o expectador pode responder com o controle remoto do dispositivo e

suas respostas serem enviadas através de uma conexão do STB com a

internet.

Outra propriedade da TV Digital é em sua disponibilidade para

dispositivos móveis como celulares, por exemplo. Com a TV Digital é possível

transmitir dados codificados de maneira compatível com as características de

decodificação limitadas destes dispositivos, assim, necessitando de menor

poder embarcado para exibir o vídeo. Porém, nestes dispositivos móveis, um

grande problema é a recepção do sinal transmitido. Como se trata de

dispositivos que podem estar em movimento variável e em localidades com

baixa qualidade de sinal, é necessário que novas tecnologias na recepção do

sinal sejam desenvolvidas.

Com o objetivo de desenvolver uma nova tecnologia na recepção do

sinal de TV-Digital, o projeto SIRDAI-TVD foi criado a partir de um consórcio

entre INATEL, PUCRS, UNICAMP, UFSC, UFPR, Mackenzie e CTI. O

GPQCOM3, Grupo de Pesquisa em Comunicações do Departamento de

Engenharia Elétrica, representou a UFSC neste projeto, tendo como

3 GPQCOM - gpqcom.ufsc.br

4

colaboradores atuantes no projeto, Prof. Carlos Aurélio Rocha, Prof. Raimes

Moraes, Prof. Leonardo Resende e Me. Eng. Eletr. Gustavo Corrêa Lima. Um

dos objetivos deste projeto foi um sistema de arranjo de antenas inteligentes

com suporte a diversidade de sinal. O sistema demandou o desenvolvimento

de um novo sintonizador com componentes ainda pouco vinculados no

mercado. Este protótipo desenvolvido utiliza chips DiB8096, da fabricante

DIBCOM, para efetuar a recepção e demodulação do sinal de TV Digital.

Como se tratava de um novo dispositivo ligado ao Set Top Box, não havia

suporte de drivers para este sintonizador no Linux embarcado, isto geraria a

necessidade do desenvolvimento de um novo driver. No entanto, foi

disponibilizado pelo fabricante do chip, um driver de referência utilizado como

base e adaptado para as funcionalidades requeridas neste novo sintonizador

de TV Digital do projeto SIRDAI-TVD.

O STB de desenvolvimento utilizava uma plataforma da

STMicroeletronics, com o processador STi7109 de arquitetura SuperH (SH4).

Desta maneira foi possível embarcar o sistema operacional STLinux, mantido

pela própria ST. Para a inserção do driver resultante na interface de

aplicações do Set Top Box, foi utilizada a plataforma de desenvolvimento da

ST para o STLinux, a STAPISDK, a qual dispôs de ferramentas que

facilitaram o desenvolvimento deste trabalho.

O sintonizador produzido pelo projeto SIRDAI-TVD utiliza o sistema de

transmissão em vias terrestres. Vias terrestres são aquelas transmitidas por

ondas de radiofrequência, em que os sinais digitais são transmitidos no ar e

necessitam de antenas e receptores apropriados para a sua recepção. Uma

das características deste sistema de transmissão é o custo econômico mais

baixo de implantação, sendo que não é preciso pagar pela transmissão, como

nos casos com transmissões via satélite, e também os custos de

infraestrutura são menores que os de transmissões via cabo, por exemplo.

Desta maneira basta que às emissoras de televisão transmitam e os

consumidores recebam com um aparelho decodificador de TV-Digital, pelo ar,

5

sem a necessidade de cabeamento específico, ou aluguel de satélites. No

Brasil as transmissões terrestres de TV-Digital utilizam o padrão ISDB-T, que

trabalha na faixa VHF e UHF, sendo que cada canal tem uma banda de

6MHz [6] . Apesar de especificada a banda VHF, ainda é utilizada apenas a

UHF para transmissões da TV-Digital.

Será apresentado um estudo sobre algumas ferramentas que auxiliam no

desenvolvimento no sistema embarcado utilizado. Também algumas

diretrizes para o desenvolvimento de um aplicativo que utiliza o driver de um

sintonizador para rastrear canais da TV-Digital do sistema de transmissão

ISDB-T.

6

2 FUNDAMENTAÇÃO TEÓRICA

2.1 SISTEMA OPERACIONAL LINUX

De acordo com Tanenbaum [1], um sistema computacional moderno é

composto por um ou mais processadores, memória principal, dispositivos de

armazenamento permanente (discos rígidos), dispositivos periféricos

(impressoras, scanners, etc.), teclado, monitor, interfaces de rede e outros

dispositivos de entrada e saída. É um sistema complexo, o que torna

extremamente difícil o desenvolvimento de programas capazes de controlar

todos estes componentes corretamente. Por esta razão, os computadores

fazem uso de um software especial denominado sistema operacional, cujas

funções principais concentram-se em gerenciar os diferentes componentes

de dispositivo e fornecer aos programas do usuário uma interface para

interação com este dispositivo de forma padronizada e mais simples.

O gerenciamento do acesso aos periféricos é uma das tarefas mais

importantes de um sistema operacional embarcado. Há diferentes formas de

um sistema operacional gerenciar esta comunicação, porém a forma mais

comum, utilizada pela grande maioria dos sistemas operacionais, é a criação

de camadas específicas para as interações que ocorrem entre programas de

usuários, na camada do usuário, e o dispositivo do computador, na camada

do kernel. Neste caso, sempre que um programa necessita algum tipo de

operação de entrada e saída, não a solicita diretamente ao dispositivo, mas

sim ao sistema operacional. Com este controle é possível uma maior

estabilidade do sistema operacional, bloqueando programas que não tem

permissão de utilizar ou interagir diretamente com o dispositivo e também

mantendo uma camada de abstração que possibilita maior conforto na

programação dos aplicativos do usuário.

7

O finlandês Linus Torvalds, cientista da computação que idealizou e

criou o sistema operacional Linux, não imaginava o grande impacto que sua

iniciativa teria. Não somente quanto à modernização dos sistemas

operacionais, mas como na modelagem de uma nova cultura de fabricação e

disponibilização de produtos da computação. Ao lançar sua ideia para o

mundo, Linus Torvalds demonstra sua “ingenuidade” quanto a abrangência e

o impacto de seu projeto, algo que se pode ver em sua citação durante uma

lista de discussão por e-mail:

“I'm doing a (free) operating system (just a hobby, won't be big and professional like gnu) for 386(486) AT clones.” (Torvalds, Linus (1991-08-25). Post to comp.os.minix newsgroup)4

Linus Torvalds se baseou no sistema operacional Minix de Andrew S.

Tanenbaum (TANENBAUM, Andrew S., 2008, p23) para desenvolver o Linux.

Na época, o Minix era utilizado apenas como uma ferramenta de ensino em

ambientes acadêmicos. Este sistema não era adequado para uso em outros

ambientes. Atualmente em sua 3ª versão, o Minix ambiciona ser um sistema

operacional para aplicações reais com foco em sistemas de recursos

limitados, como, por exemplo, os sistemas embarcados.

Apesar de possuir concepções herdadas do Minix e Unix, os códigos

contidos no Linux foram totalmente reescritos. O Linux evoluiu muito

rapidamente desde sua concepção inicial e seu desenvolvimento ramificou-se

na tentativa de solucionar as mais diversas necessidades de sistemas

computacionais. Suas vertentes mais popularmente conhecidas são quanto

ao seu uso como um sistema operacional para usuários comuns - aqueles

que não sabem programar ou diagnosticar um sistema operacional[1]. Devido

a suas características para licenciamento de modificação de código e

4

http://groups.google.com/groups?hl=en&selm=1991Aug25.205708.9541%40klaava.

Helsinki.FI

8

distribuição gratuita, o Linux se tornou uma ferramenta muito importante nas

vertentes de aplicações de sistemas operacionais em sistemas embarcados.

As tarefas mais importantes do sistema operacional são administradas

por um conjunto de códigos que formam o núcleo deste sistema. O núcleo do

SO Linux é chamado de kernel e possui a responsabilidade de gerenciar

recursos de E/S5, memória e processamento para os aplicativos do sistema

operacional. Na figura abaixo, observa-se as diferentes atribuições do Kernel.

Figura 1 - Exemplo de camadas do Kernel do Linux.

Para a utilização do Linux em uma plataforma embarcada, devemos

adequá-lo às condições desta. Características como a arquitetura do

processador e dispositivos anexos a plataforma são cruciais. Através de

ferramentas de cross-compiling, é possível desenvolver, compilar e testar

programas destinados a uma arquitetura de destino diferente da arquitetura

de origem. Como exemplo genérico, esta técnica possibilita compilar um

5 Entrada e Saída

9

kernel Linux para processadores PowerPC, a partir de um ambiente de

desenvolvimento executado em um processador x86.

O STLinux6 é um sistema operacional Linux com componentes e

ferramentas específicas para plataformas da STM. O STB escolhido para

desenvolvimento possui o chipset STi7109, logo, o STLinux e suas

ferramentas facilitarão o desenvolvimento deste trabalho. Baseado no mesmo

kernel que pode ser encontrado no website kernel.org, o STLinux é otimizado

para rodar em plataformas e placas da STM de arquitetura Super H 4 (SH4),

além de prover total compatibilidade com drivers da STAPI, interface que

disponibiliza recursos avançados para hardwares e aplicações das placas da

STM.

2.2 DRIVERS PARA LINUX

Segundo Rubini [2], um driver é escrito para interagir de forma

planejada na camada do sistema operacional destinada a ele. No âmbito de

um sistema operacional Linux, na camada de usuário, o driver desempenha a

função de intermediar o acesso dos programas, aos dispositivos controlados

na camada do kernel. Utilizando-se de protocolos de comunicação

específicos do sistema ao qual o driver está acessando e também todas as

características de escrita e leitura de registradores para o controle deste

dispositivo. Estas informações são muitas vezes fornecidas pelo fabricante do

dispositivo. Desta forma, o programa na camada de usuário acessa apenas

funções que procuram abstrair procedimentos padronizados, intrínsecos às

características do dispositivo, promovendo estabilidade, segurança e

confiabilidade para o sistema, limitando o usuário a controlar o dispositivo da

forma arquitetada e validada pelo desenvolvedor do driver ou fabricante do

dispositivo.

6 Para baixar uma cópia do STLinux acesse ftp://ftp.stlinux.com/pub/stlinux/

10

Em um sistema embarcado, devem-se levar em consideração as

características específicas deste sistema. Na adaptação do driver para o

dispositivo sintonizador do projeto SIRDAI-TVD, o sistema operacional

utilizado foi o STLinux, o qual oferece várias ferramentas importantes para

esta implementação. Também foi utilizada a STAPI, que promove um acesso

otimizado aos hardwares presentes no STB.

2.3 PLATAFORMA DE DESENVOLVIMENTO DA ST (STAPISDK)

A plataforma de desenvolvimento de software da STMicroeletronics, a

STAPISDK, possui ferramentas para a geração de sistemas operacionais

embarcados em placas da ST, além disso promove uma abstração da

camada do sistema operacional de desenvolvimento, sendo que pode ser

utilizada para desenvolvimento em ambientes Linux, OS21 e Windows.

O STB utilizado no projeto SIRDAI-TVD possuía placa da STM com o

chipset STi7109, versão 29bits. Para que aplicações que utilizam o kit de

desenvolvimento de software da ST pudessem usufruir do aplicativo para o

driver sintonizador, foi necessário inclui-lo na camada de aplicação STAPP,

de forma a tornar as funcionalidades do dispositivo sintonizador do projeto

SIRDAI-TVD disponível para aplicativos nesta camada. A seguir tem-se a

organização das camadas da STAPI.

11

Figura 2 - Organização de camadas da STAPISDK

A camada da STAPI possui drivers específicos para as placas da STM,

como a placa do STB utilizado. Ela é instalada através de módulos no

STLinux, em tempo de execução. O pacote de módulos é chamado Multicom

e é compilado no mesmo momento em que a STAPISDK é compilada, mas

deve ser carregado através de um script gerado especificamente para aquela

compilação e após o boot normal do kernel.

2.4 SET TOP BOX

O Set Top Box, ou STB, é uma plataforma embarcada destinada

principalmente a recepção, transformação e disponibilização de sinal de TV-

Digital em conteúdo multimídia. Considere a figura abaixo como um diagrama

de componentes básicos de um STB.

12

Figura 3 – Exemplo de um diagrama de blocos de STB.

No projeto SIRDAI-TVD, o aparelho STB escolhido foi do fabricante

Proview, devido a suas especificações técnicas e compatibilidade com a

plataforma da ST para desenvolvimento. O STB utilizado pode ser visualizado

na figura abaixo.

Figura 4 - STB Proview XPS-1000 utilizado neste trabalho. À direita, tem-se a placa retirada da caixa do STB.

13

2.5 SISTEMA DE TRANSMISSÃO DE TV-DIGITAL ISDB-T

A sigla ISDB-T significa Terrestrial Integrated Services Digital

Broadcasting. É um sistema japonês, criado pela ARIB, Association of Radio

Industries and Businesses. Foi o sistema selecionado[6] como base para a

implantação nacional da transmissão de TV Digital. A característica principal

deste sistema é especificar a transmissão de vídeo, áudio e dados, de forma

independente ou em qualquer combinação destes. O receptor recebe um

sinal de radiofrequência e disponibiliza os dados para o decodificador. O

diagrama de blocos da figura seguinte representa as funcionalidades básicas

do sistema para sua transmissão e recepção.

Figura 5 – Diagrama básico para transmissão do sinal ISDB-T (as linhas pontilhadas representam fluxo de controle, enquanto que as contínuas, fluxo de sinal).

O ISDB-T suporta até cerca de 19Mbit/s e vários feixes de dados em

paralelo[5], traduzidos em transmissões diferentes de áudio, vídeo e dados.

Estes feixes de dados são conhecidos como Transport Stream, ou

abreviadamente TS. As camadas de áudio e vídeo são codificadas e então

multiplexadas. Opcionalmente pode ser multiplexada em conjunto com uma

14

camada adicional de dados. Este TS resultante é então re-multiplexado com

demais TSs, em um bloco multiplexador de TSs, formando um feixe único de

dados contendo todos os demais. Este feixe único de dados resultante passa

por uma modulação e amplificação, para só então ser transmitido.

Embora interessantes, detalhes sobre a codificação e modulação de

um canal dentro do sistema ISDB-T não serão necessários para a

compreensão deste trabalho. Será utilizada apenas a frequência do canal

para que o sintonizador receba o sinal transmitido de forma adequada e

assim disponibilize o TS ao sistema embarcado do Set Top Box.

Para a transmissão digital foi reservada a faixa de 470 MHz a 806

MHz, com exceção da faixa de 608 MHz a 614 MHz, canal 37. Esta

transmissão ocorre dentro da faixa compreendida por UHF, Ultra-High

Frequency, pode-se traduzir em canais de 14 a 69, com exceção do canal 37.

Por uma questão organizacional, apenas depois de terminado o processo de

implantação da transmissão digital e encerramento das transmissões

analógicas é que a banda VHF, Very High Frequency, será utilizada também

para transmissões digitais.

Cada canal UHF dispõe de 6 MHz de banda, esta banda deve conter

14 segmentos, sendo que destes, apenas uma largura aproximada de 5,572

MHz, contendo 13 segmentos, são utilizáveis para a transmissão de dados. A

distribuição destes segmentos pode ser analisada de forma mais detalhada

na figura do Anexo D.

A transmissão no canal deve respeitar os limites de espaçamento e a

largura de banda utilizável normatizada pela ABNT NBR15601:2007, estes

limites podem ser vistos na figura abaixo.

15

É possível verificar que há uma distância de 5/14 MHz para o início da

banda utilizável e que o primeiro segmento está no centro da banda utilizável

do canal. Logo, para sintonizar o receptor no segmento contendo o início do

TS, é preciso sintonizar na frequência resultante do centro da banda utilizável

contando com o deslocamento inicial da banda. Isto é equivalente tomar a

frequência base do canal e somar 3,142857 MHz. Por exemplo, a frequência

de sintonização do canal 40, cujo 626 MHz é sua frequência base, resultaria

em 629,142857 MHz.

2.6 SINTONIZADOR DE TV-DIGITAL

Um sintonizador de TV Digital pode ser separado em duas partes, são

elas o front-end e o back-end. De acordo com C. LI (2009) o front-end é o

bloco do conjunto do sintonizador receptor que opera na gama da

radiofrequência, chamados de blocos RF7, sendo o demodulador o

7 RF – Radiofrequência, faixa correspondente a frequência das ondas de rádio

Figura 6 - Limites de utilização da banda disponível normatizada pela ABNT 15601:2007.

16

delimitador entre front-end e back-end. Já o back-end, ainda no caso do

receptor, opera após a demodulação na gama de frequências intermediárias8.

Abaixo pode-se visualizar o protótipo do sintonizador SIRDAI utilizado.

No sintonizador transmissor a saída do front-end é modulada e

passada aos blocos RF, que neste caso são chamados de back-end. Nota-se

que é o inverso do receptor.

Detalhando o bloco front-end dos receptores, Bowick (2007) diz que

um front-end RF9 inclui filtros RF, amplificadores de baixo ruído10 e mixers

necessários para processar sinais modulados recebidos pela antena. Ele é o

responsável pela seleção do canal, banda do canal e por todos os

procedimentos de limpeza de sinal necessários para uma boa qualidade de

recepção. Pode-se verificar na figura seguinte, um diagrama de blocos

genérico para um sintonizador receptor de sinal TVD.

O sintonizador com diversidade possui um bloco adicional, aqui

chamado de “Combinador de Diversidade”. Este bloco combina os sinais de

saída do bloco de equalização (EQ) e os sinais de outro demodulador. O

sistema de diversidade do sintonizador SIRDAI trabalha em um sistema de

mestre e escravos. No demodulador escravo o sinal de saída é o de seu

bloco combinador de diversidade. Portanto, ao tomar um caminho exclusivo e

8 Frequências intermediárias, também chamadas de low digital data rate

9 – Radiofrequência, faixa correspondente a ondas de rádio

10 LNA - low-noise amplifiers

Figura 7 - Diagrama de blocos genérico de um sintonizador.

Front-End Sinal RF Back-End TS

17

não passando pelos demais blocos do demodulador, este sinal passa por um

barramento de diversidade para o demodulador seguinte da cadeia de chips.

O sintonizador mestre recebe a saída do bloco combinador de diversidade do

demodulador anterior na cadeia, combina com seu sinal e entrega a saída

para os blocos sequentes, que liberam o TS MPEG no canal se saída do

SIRDAI.

Figura 6 - Back-end receptor com diversidade, adicionado um bloco Combinador de Diversidade.

Na figura acima, tem-se o Back-End receptor com diversidade. Pode-

se verificar que o Combinador de Diversidade possui duas entradas e saídas

de sinal. Os blocos subsequentes, em vermelho, serão inabilitados nos chips

em que a saída Div OUT está ligada, denominados chips escravos. No chip

Saída do

Front-End

Conversor

A/D

Interpolação e Filtragem

FFT EQ

Combinador de Diversidade

Desentrelaçador Correção de

Erros MPEG TS

Div OUT

Div IN

18

mestre, último chip da cadeia de diversidade, estes blocos serão ativados e a

saída Div OUT, desativada. Quando o sinal é captado pelo primeiro chip da

cadeia ele sofre um atraso adicional em relação ao sinal do chip seguinte.

Este atraso é decorrente da passagem pelo bloco Combinador de

Diversidade.

Figura 8 - Atraso devido o caminho percorrido pelo fluxo de dados.

O atraso é compensado no bloco combinador de diversidade do chip

seguinte na cadeia de diversidade. O bloco armazena fluxo de dados, em

modo FIFO11, pelo tempo necessário até que o atraso em relação ao primeiro

chip da cadeia seja alcançado, assim fica certificado que os dados de

recepção serão compatíveis com os dados de entrada do primeiro chip na

cadeia de diversidade. A informação sobre este atraso foi disponibilizada pelo

fabricante do chip para que ocorra a configuração apropriada dos chips em

modo de diversidade.

11

FIFO – First In First Out – modo em que o primeiro dado a chegar será o primeiro a

sair da fila.

Sinal RF da Antena

atraso

Sinal de saída do bloco Combinador de Diversidade

19

Figura 9 - Sintonizador SIRDAI com dois SoCs12

DIBCOM DIB8096.

Na figura acima, pode-se visualizar o protótipo do sintonizador

resultante do projeto SIRDAI-TVD. Possuindo dois chips DIBCOM DIB8096,

suporta diversidade de recepção com duas entradas de antenas, conectadas

através dos conectores F coaxiais localizados na margem esquerda da

imagem.

2.7 PROTOCOLO DE COMUNICAÇÃO I2C

Grande parte dos sistemas operacionais Linux possuem suporte ao

protocolo I2C e o STLinux está incluso neste grupo. Isto facilitou, em termos

de depuração de problemas, a adaptação do driver de referência para o

sintonizador SIRDAI, uma vez que o controle dos chips no sintonizador é

realizado através deste barramento de comunicação no STB. Este protocolo

foi inicialmente concebido pela empresa Philips para a comunicação entre

componentes em televisores.

12

SoC – System on a Chip

20

Figura 10 - Exemplo do barramento I2C, onde o dispositivo em azul se

tornou mestre e os em verde em escravos.

O Inter-Integrated Circuit (I2C), pode ser encontrado nos mais diversos

dispositivos. É um barramento que permite a comunicação serial entre

circuitos integrados em um sistema embarcado. A simplicidade do protocolo e

seus requisitos de hardware, permitem que ele seja implementado tanto em

hardware quanto em software utilizando poucos recursos.

Figura 11 - Diagrama de sinais protocolo I2C.

O barramento I2C requer duas conexões, uma para o sinal de clock

(SCL) e a outra para o sinal de dados (SDA). Todos os dispositivos, os quais

devem se comunicar, deverão conectar-se no mesmo barramento I2C. Desta

forma, qualquer dispositivo pode receber ou enviar informações para

qualquer outro ligado ao barramento I2C do sistema embarcado. O dispositivo

que inicia a comunicação se torna mestre, sendo que os outros dispositivos

Mestre

Barramento I2C

Escravo

Escravo Escravo

21

se tornam escravos. Através de um sistema de endereçamento o dispositivo

mestre se comunica com o dispositivo escravo que responde àquele

endereço.

2.8 FERRAMENTAS UTILIZADAS

2.8.1 PICOCOM

É uma ferramenta para linux muito utilizada como terminal de

comunicação serial. Funciona através de emulação de terminais que

interpretam sinais básicos como CR e LF. A saída de terminal abaixo mostra

uma simples conexão serial utilizando o picocom.

Código 1 - Utilização básica do aplicativo Picocom.

# picocom -b 115200 /dev/ttyS0 picocom v1.4 port is : /dev/ttyS0 flowcontrol : none baudrate is : 115200 parity is : none databits are : 8 escape is : C-a noinit is : no noreset is : no nolock is : no send_cmd is : ascii_xfr -s -v -l10 receive_cmd is : rz -vv Terminal ready

22

2.8.2 U-BOOT

Este utilitário gerencia de maneira mais simplificada as funcionalidades

para o carregamento de um sistema operacional. O procedimento de pre-

inicialização do sistema operacional é conhecido como boot loading, sendo

que o U-Boot13 é um aplicativo boot-loader. O U-Boot é utilizado

principalmente para dispositivos embarcados, pois suporta várias arquiteturas

de processadores como MIPS, ARM, Nios14, MicroBlaze15, entre outros. A

arquitetura SH416 é utilizada pelo chip STi7109 do Set Top Box de

desenvolvimento e é também uma das arquiteturas a qual o U-Boot oferece

suporte.

O U-Boot possui uma grande flexibilidade no carregamento de diversos

tipos de sistemas, pode-se carregar sistemas via interface de rede, cartões

de memória, dispositivos de armazenamento diversos17 e vários sistemas de

arquivos.

Dentre suas principais características, destacam-se:

Protocolos de carregamento via rede: TFTP, BOOTP, DHCP, NFS;

Suporte de carregamento via Serial: s-record, binary (via Kermit);

Modelos de memória Flash suportados: CFI NOR-Flash, NAND-Flash;

Utilitários de memória embutidos: copy, dump. crc, check, mtest;

Compatível com dispositivos de armazenamento: IDE, SATA, USB;

Tipos de sistemas de arquivos: raw block, ext2, fat, reiserfs;

Suporte a linha de comando busybox, com várias funcionalidades extras.

13

http://sourceforge.net/projects/u-boot 14

Nios é um soft-processor da Altera 15

MicroBlaze é um soft-processor da Xilinx 16

SH4 - Versão 4 da arquitetura SuperH 17

Pendrives USB, discos removíveis

23

Logo, por sua flexibilidade e suporte a arquitetura SH4, o U-Boot foi

escolhido para carregar o STLinux no equipamento de desenvolvimento.

Visando agilidade nos processos de desenvolvimento, teste e depuração, foi

utilizada a opção de carregamento da imagem de kernel através do protocolo

de sistema de arquivos em rede, o NFS18. Este protocolo permite que o

sistema de arquivos seja armazenado na estação de desenvolvimento e

remotamente acessado como pasta raiz do sistema embarcado. Ao compilar

o STLinux e os fontes utilizados no projeto, foi possível acessa-los

diretamente no dispositivo embarcado, sem a necessidade de procedimentos

intermediários, como por exemplo, copiar os arquivos para um dispositivo de

armazenamento externo e preparar o dispositivo para se tornar pronto para o

boot.

2.8.3 I2C-TOOLS

O i2c-tools é um conjunto de ferramentas para depuração e controle de

dispositivos que se comunicam através do protocolo I2C. Já que a

comunicação com o chip do sintonizador SIRDAI utiliza o protocolo I2C, estas

ferramentas serviram para obter informações como o endereço do chip e se a

comunicação estava ocorrendo corretamente.

18

NFS - Network File System

24

3 DESENVOLVIMENTO

O driver foi implementado na camada de aplicação da STAPISDK, o

código objetivou controlar o dispositivo utilizando o protocolo de comunicação

de entrada e saída serial Inter-Integrated Circuit (I2C) na arquitetura de

instrução SH4 do processador STi7109 da plataforma utilizada para testes no

STB da fabricante Proview. Desta forma foi possível ler e escrever nos

registradores específicos do chip DIB8096 controlando o que era necessário

para a sintonização de um canal de forma a aplicar a captura deste sinal com

diversidade de recepção, o que era o objetivo específico do projeto SIRDAI-

TVD. Este driver na camada de usuário do STLinux deveria ser portado para

a camada específica para aplicações de STBs, reprodutores de DVDs, entre

outros aparelhos que utilizam a STAPI como kit de desenvolvimento de

software para suas plataformas.

3.1 COMPILANDO AS IMAGENS DO STLINUX E DO U-BOOT

Quanto se está trabalhando com a STAPISDK, todas as configurações,

tanto das variáveis para configuração do kernel do STLinux quanto para

variáveis para a compilação da STAPI, estão no arquivo

/opt/STM/stapisdk/bin/setenv.sh. Para configurar o kernel STLinux deve-se

procurar a cláusula que define as variáveis de compilação no arquivo citado

anteriormente, no caso do STB utilizado neste trabalho, o modelo de sua

placa era MB442 (COCOREF_GOLD_7109_LINUX).

25

Código 2 - Código parcial de configuração da STAPISDK, arquivo setenv.sh. Para maiores detalhes, verificar Anexo F.

É interessante ressaltar a variável $LINUX_PARAMETERS, que

representa os parâmetros de inicialização do kernel STLinux em seu

carregamento no STB. O endereço do cross-compiler SH4 é adicionado à

variável $PATH para que a STAPI e demais programas sejam compilados na

arquitetura da plataforma do STB.

Para carregar as configurações e variáveis de ambiente, execute os

procedimentos abaixo, podendo então compilar o kernel e a stapi após o

procedimento.

## STB7109 - COCOREF_GOLD/LINUX - Hardware configuration ## if [ "$1" = "COCOREF_GOLD_7109_LINUX" ] ; then echo COCOREF_GOLD_7109_LINUX Configuration selected ! (quebra de continuação) export PATH=/opt/STM/STLinux-$LINUX_VERSION/devkit/sh4/bin:$PATH export MANPATH=/opt/STM/STLinux-$LINUX_VERSION/host/man:$MANPATH export KDIR=/opt/STM/STLinux-$LINUX_VERSION/devkit/sources/kernel/linux-

sh4 export KTARGET=/opt/STM/STLinux-$LINUX_VERSION/devkit/sh4/target/root export LINUX_TARGETIP=192.168.0.10 export LINUX_SERVERIP=192.168.0.9 export LINUX_GWIP=192.168.0.1 export LINUX_NETMASK=255.255.255.0 export LINUX_NAME=stapisdk export LINUX_AUTOCONF=off export LINUX_SERVERDIR=/opt/STM/STLinux-

$LINUX_VERSION/devkit/sh4/target export LINUX_KERNEL=$KDIR/vmlinux export LINUX_PARAMETERS="console=ttyAS1,115200 \ root=/dev/nfs rw mtdparts=physmap-flash:256k,3072k,- \ nwhwconf=device:eth0,hwaddr:00:22:C2:00:78:15 \

nfsroot=$LINUX_SERVERIP:$LINUX_SERVERDIR,rsize=4096,wsize=8192,tcp \

ip=$LINUX_TARGETIP::$LINUX_GWIP:$LINUX_NETMASK:$LINUX_NAME:eth0:$LINUX_AUTOCONF \

mem=128m \ stmmaceth=phyaddr:5 \ coprocessor_mem=4m@0x10000000, 4m@0x10400000 \ bigphysarea=2500" fi

26

Código 3 - Sequencia de comandos para compilar o kernel do STLinux.

Para compilar o U-Boot para a arquitetura SH4 deve ser utilizado o

procedimento abaixo. A placa utilizada no STB é a MB442, a qual deve ser

citada na configuração do compilador.

Código 4 - Sequencia de comandos para compliar o U-Boot para arquitetura SH4.

Desta forma obtêm-se as imagens necessárias para carregar o sistema

operacional embarcado no Set Top Box.

3.2 EMBARCANDO O U-BOOT

Para instalar o U-Boot, o STB precisa ser conectado através da

interface JTAG a um sistema host. Para isto foi necessário um dispositivo

especial19, fabricado pela própria ST. É necessário também, realizar uma

ligação serial RS-23220 entre a estação de desenvolvimento e o STB. A porta

serial da estação é do padrão RS-232-C, o qual prevê níveis de tensão entre 19

ST MicroConnect 20

Protocolo de comunicação serial

$ cd /opt/STM/STLinux-2.3/devkit/sources/u-boot/u-boot-sh4-1.3.1_stm23_0042/ $ make distclean $ make mb442_config $ make

$ cd /opt/STM/stapisdk/stapp $ source ../bin/setenv.sh COCOREF_GOLD_7109_LINUX $ make purge_kernel $ make kernel

27

+- 3V e +- 15V. Já o STB possui interface RS-232 em nível TTL21, que utiliza

tensões de 0V e +5V, logo, foi necessário um conversor de TTL para RS-232-

C. Utilizando o chip MAX232 o Me. Eng. Comp. Pedro Giassi Jr. ajudou no

projeto, produzindo o conversor necessário para a comunicação. Fotos e

indicações das conexões estão disponíveis no Anexo H. As principais

ligações entre os dispositivos envolvidos nesta operação podem ser vistas na

figura abaixo.

Utilizando a ferramenta picocom inicia-se a conexão serial, com isso, a

saída deste terminal mostrará o resultado das operações realizadas no STB.

Em outro terminal, com a ferramenta sh4-linux-gdb, carrega-se o U-Boot para

o STB. O procedimento realizado para o carregamento do U-Boot no STB

pode ser verificado nas saídas de terminais abaixo.

21

TTL – Transistor-Transistor Logic

SET-TOP-BOX

ISDB-T MAX232

Figura 12 - Conexões entre os dispositivos no ambiente de desenvolvimento.

Antenas

HDMI

TTL

RS232

RJ45 x-over

28

Código 5 - Terminal 1, com o carregamento do U-Boot através da conexão com o ST MicroConnect.

$ sh4-linux-gdb (gdb) sh4tp 192.168.0.10:mb442:st40,silent=1 The target is assumed to be little endian The target architecture is assumed to be sh4 0xa0000000 in ?? () (gdb) load /opt/STM/STLinux-2.3/devkit/sh4/target/boot/u-boot-

1.3.1_stm23_0042-mb442/u-boot Loading section .text, size 0x1f6b0 lma 0x93f00000 Loading section .rodata, size 0x834 lma 0x93f1f6b0 Loading section .rodata.str1.4, size 0x7ddc lma 0x93f1fee4 Loading section .data, size 0xcf0 lma 0x93f27cc0 Loading section .u_boot_cmd, size 0x570 lma 0x93f289b0 Start address 0x93f00000, load size 167712 (gdb) continue Continuing.

29

Código 6 - Terminal 2, com a saída da conexão serial no STB durante o carregamento do U-Boot.

Será necessário acesso à interface de rede, uma vez que será utilizado

boot de kernel com sistema raiz de arquivos NFS. Para isso, no terminal

ligado à porta serial, ajusta-se o U-Boot com as configurações de rede locais.

Logo após pode-se salvar as configurações na memória e reiniciar o STB.

$ picocom -b 115200 /dev/ttyS0 picocom v1.4 port is : /dev/ttyS0 flowcontrol : none baudrate is : 115200 parity is : none databits are : 8 escape is : C-a noinit is : no noreset is : no nolock is : no send_cmd is : ascii_xfr -s -v -l10 receive_cmd is : rz -vv Terminal ready Board: STb7100-Reference (MB442) [29-bit mode] U-Boot 1.3.1 (Sep 30 2009 - 17:05:30) - stm23_0042 DRAM: 128 MiB NOR: 32 MiB *** Warning - bad CRC, using default environment In: serial Out: serial Err: serial MB442>

30

Código 7 - Procedimentos de configuração manuais para o boot via NFS no U-Boot

Ao reiniciar o STB, ele irá procurar pela imagem de kernel de acordo

com a configuração22 prévia, no servidor NFS localizado em 192.168.0.9, na

pasta /opt/STM/STLinux-2.3/devkit/sh4/target.

No Anexo B, pode-se ver a saída do terminal conectado na porta serial

com o carregamento normal o STLinux embarcado no STB.

3.3 ADAPTAÇÃO DO DRIVER PARA O SINTONIZADOR SIRDAI

O fabricante do chip utilizado no sintonizador SIRDAI forneceu uma

API de driver referencial, em linguagem C, a qual possuía códigos

compatíveis com vários modelos de chips front-ends, inclusive o DiB809623.

Foram necessárias adaptações no código do driver para que funcionalidades

22

Como configurado no arquivo /opt/STM/stapisdk/bin/setenv.sh (Capítulo 3.1) 23

Chip da DIBCOM utilizado no sintonizador SIRDAI

MB442> setenv serverip 192.168.0.9 MB442> setenv netmask 255.255.255.0 MB442> setenv gatewayip 192.168.0.1 MB442> setenv ipaddr 192.168.0.10 MB442> setenv bootcmd nfs 0xa0040000 192.168.0.9:/opt/STM/STLinux-2.3/devkit/sh4/target \; bootm MB442> setenv bootargs console=ttyAS1,115200 root=/dev/nfs

nfsroot=192.168.0.9: /opt/STM/STLinux-2.3/devkit/sh4/target rw ip=192.168.0.10 MB442> saveenv Saving Environment to Flash... Unprotecting Flash.... done Un-Protected 1 sectors Erasing Flash...... done Erased 1 sectors Writing to Flash....... done Protecting Flash... done Protected 1 sectors MB442>

31

requeridas pelo sistema de recepção com diversidade fossem habilitadas e

ocorressem dentro das especificações do fabricante.

A comunicação com os demoduladores é realizada através do

protocolo i2c. Para obter a informação sobre endereço I2C do chip front-end,

foi utilizado o programa i2cdetect, com ele foi possível rastrear e listar os

dispositivos presentes no barramento I2C. Para se ter certeza de que o

endereço é do dispositivo devem ser utilizadas as ferramentas i2cdump e

i2cget, as quais realizam leituras de registradores, assim comparando com a

documentação do chip buscado. Pode-se verificar na tela seguinte a

utilização o i2cdetect a partir do STLinux embarcado no STB.

Código 8 - Utilização do i2c-tools, para rastreamento de endereços.

No caso do sintonizador SIRDAI, há um controlador I2C para

comunicação interna entre os componentes do sintonizador. Este controlador

disponibiliza o acesso externo através de roteamento do sub-endereço,

extraindo este sub-endereço diretamente dos dados enviados. Por isso, é

possível comunicar-se com os demoduladores no sintonizador.

O sistema de recepção com diversidade trabalha com um chip para

cada entrada de sinal de radiofrequência, vindo da antena. Um arranjo de até

root@LDDE_LINUX:~# i2cdetect 0 WARNING! This program can confuse your I2C bus, cause data loss and worse! I will probe file /dev/i2c-0. I will probe address range 0x03-0x77. 0 1 2 3 4 5 6 7 8 9 a b c d e f

00: -- -- -- -- -- -- -- -- -- -- -- -- --

10: -- -- -- -- -- -- -- 17 -- -- -- -- -- -- -- --

20: -- -- 22 -- -- -- -- -- -- -- -- -- -- -- -- --

30: -- -- -- -- -- -- -- -- -- -- -- -- -- -- 3e --

40: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --

50: -- -- -- -- -- -- -- -- -- -- -- -- 5c -- -- --

60: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --

70: -- -- -- -- -- -- -- --

32

quatro antenas independentes pode ser conectado a estes chips, de forma a

melhorar a recepção deste sinal. É necessário que um dos chips se torne

mestre, enquanto que os outros trabalhem em modo escravo para ocorrer a

diversidade. Como há um atraso intrínseco ao caminho realizado pelo fluxo

de dados através dos blocos nos chips, é necessário especificar este atraso

corretamente na implementação do código para que o driver possa configurar

os registradores dos chips e compensar este atraso.

No driver de referência, um objeto é instanciado para cada chip. A

definição deste objeto contém todas as informações inerentes ao chip. Um

array contendo estes objetos é então utilizado no código para leitura dos

atributos inerentes aos chips. Destes objetos, a informação mais importante

para este trabalho é o atributo relativo ao atraso24 que cada chip deverá

utilizar para combinar os dados da diversidade. Um algoritmo genérico para

este procedimento seria o seguinte:

24

Para mais informações obre este atraso verificar capítulo “Sintonizador de TV-

Digital”.

33

Código 9 - Pseudo-algoritmo para escrita dos atrasos nos chips sintonizadores.

No exemplo acima, temos 4 chips, cada um com seu sub-endereço I2C

e seus atrasos definidos. Os atrasos utilizados neste pseudo-algoritmo são

apenas ilustrativos. Esta informação depende de cada chip, logo, deverá ser

fornecida pelo fabricante do chip sintonizador com diversidade utilizado. A

função i2c_escreva_word_reg escreve uma palavra de 16bits em um

registrador de um componente interno do sintonizador, usando um endereço

base no barramento I2C base, no caso definido com o endereço 0x22 no

cabeçalho do código. O algoritmo mostrado registra os valores dos atrasos

em cada chip demodulador.

/// cabeçalho #define ENDEREÇO_BASE_SIRDAI_I2C 0x22 #define ENDEREÇO_REGITRADOR_ATRASO 56 struct chip { uint8_t subendereco_i2c; uint16_t atraso_diversidade; } /// código struct chip dib8096[4] = { { 0x90, 30 }, //chip mestre { 0x92, 20 }, //chip escravo { 0x94, 10 }, //chip escravo { 0x96, 0 }, //chip escravo (1

o da cadeia de recepção)

} for (int i = 0; i < sizeof(dib8096); i++){ i2c_escreva_word_reg(dib8096[i], ENDEREÇO_REGITRADOR_ATRASO,

dib8096[i].atraso_diversidade) } int i2c_escreva_word_reg(struct chip [ ], uint8_t reg, uint16_t dados) { uint32_t msg; msg = (chip.subendereco_i2c << 24) + (reg << 16) + dados; i2c_escreva (ENDEREÇO_BASE_SIRDAI_I2C, msg ); }

34

Figura 13 - Sistema mestre/escravo dos chips com diversidade.

A imagem acima representa o caminho do sinal, através dos chips

sintonizadores, quando implementada a diversidade de recepção. As

entradas e saídas em vermelho estão desligadas, já as entradas e saídas em

verde, ligadas. Cada chip sintonizador está acoplado a uma antena de onde

recebe sinal RF25. Os tons em gradiente representam sinal melhorado e

também o aumento do atraso referente a passagem pelo bloco Combinador

de Diversidade em cada chip. O tom mais claro está com menor atraso que o

tom mais escuro. Este sistema ilustra o pseudo-algoritmo demonstrado no

Código 10.

25

RF – Radiofrequência, faixa correspondente a frequência das ondas de rádio

Sintonizador

Escravo 2

Div OUT

Div IN

T

S

O

U

T

Sintonizador

Escravo 1

Div OUT

Div IN

T

S

O

U

T

MPEG TS Sintonizador

Master

Div OUT

Div IN

T

S

O

U

T

Sintonizador

Escravo 0

Div IN

T

S

O

U

T Div OUT

RF

RF

RF

RF

35

Código 10 - Pseudo-algoritmo para implementação do sistema mestre/escravo nos chips da cadeia de diversidade.

O pseudo-algoritmo acima, habilita a diversidade nos chips

configurando as saídas e entradas dos demoduladores para que se respeite a

hierarquia da cadeia de diversidade ilustrada na Figura 13.

3.4 CRIAÇÃO DO APLICATIVO SINTONIZADOR

Utilizando funções disponibilizadas pela API do driver de referência,

adicionalmente com as adaptações no driver vistas no capítulo anterior, foi

int count = sizeof(dib8096); uint16_t reg_div_e = 78; // endereco_registrador_entrada_diversidade uint16_t reg_div_s = 79; // endereco_registrador_saida_diversidade for (i = 0; i < count; i++) { if (i == count-1) { // Sintonizador Escravo 0 // configura a entrada de diversidade como desligada i2c_escreva_word_reg(dib8096[i], reg_div_e, 0); // configura a saida de diversidade como ligada i2c_escreva_word_reg(dib8096[i], reg_div_s, 1); } else { // demais Sintonizadores Escravos // configura a entrada de diversidade como ligada i2c_escreva_word_reg(dib8096[i], reg_div_e, 1); // configura a saida de diversidade como ligada i2c_escreva_word_reg(dib8096[i], reg_div_s, 1); } if (i == 0) { // Sintonizador mestre, apenas saida de TS ligada i2c_escreva_word_reg(dib8096[i], reg_div_s, 0); } }

36

possível criar um aplicativo para rastrear os canais TVD disponíveis26 e

sintonizar em um canal específico para o recebimento do TS.

Código 11 - Pseudo-algoritmo para implementação do aplicativo rastreador de canais ISDB-T.

O algoritmo para rastreamento de canais produzido é baseado nas

normas oficiais do sistema de transmissão terrestre de TV Digital, adotado

pelo Brasil em 2007 (ABNT NBR 15601:2007). Com isso pode-se visualizar

na fração de código seguinte, todas as características intrínsecas às normas

brasileiras.

26

Com qualidade de sinal suficiente para sintonizar e receber o TS.

int bandwidth_kHz = 6000; // Largura da banda disponivel para o canal int RF_kHz = 177143; // Frequencia direta do primeiro canal VHF int RF_limite_VHF_kHz = 213143; // Frequencia do ultimo canal VHF int RF_limite_UHF_kHz = 803143; // Frequencia do ultimo canal UHF int salto_VHF_UHF_kHz = 260000; // Salto de 260MHz entre limites VHF e // UHF de transmissão // Canal 37 é reservado, quando chegar no 36 pula para o 38 int RF_canal_36 = 605143; while (RF_kHz <= RF_limite_UHF_KHz){ // Sintoniza todos os chips com diversidade sintoniza_div(dib8096, RF_kHz); // Verifica se o chip mestre encontrou um canal if(dib8096[0].status == STATUS_LOCKED){ // Adiciona a frequencia do canal no array de canais

encontrados canais[j] = RF_kHz; // Reinicia as configuracoes dos chips reiniciar(dib8096);

j++; } // Se atingiu o limite VHF, salta para UHF if (RF_kHz == RF_limite_VHF_kHz){ // Salto de 260MHz entre limites VHF e UHF de transmissão RF_kHz += salto_kHz } else if (RF_kHz == RF_36) { RF_kHz += 2 * bandwidth_kHz; // Salta o canal 37 (reservado) } else { // Soma a banda de canal, para testar o próximo canal RF_kHz += bandwidth_kHz; } }

37

3.5 INTEGRAÇÃO DO APLICATIVO SINTONIZADOR COM A STAPI

Dois aplicativos foram produzidos, o tuner_tune e o tuner_scan, um

para realizar a sintonização em um canal, e o outro para rastrear canais

disponíveis. Os canais encontrados pelo tuner_scan serão impressos na

saída de terminal do STLinux.

Foi necessário o uso de ferramentas cross-compiling para compilar o

código direcionado ao STB (SH4). Estas ferramentas ficam localizadas no

diretório /opt/STM/STLinux-2.3/devkit/sh4/bin, porém sua utilização direta foi

desnecessária neste trabalho, uma vez que a STAPISDK automatiza todo o

procedimento utilizando makefiles. Na seguinte saída de terminal, podemos

ver como é executado o procedimento de compilação da STAPI.

Código 12 - Sequencia de comandos para compilar e instalar o STLinux e a STAPI no diretório raiz NFS para boot no STB

O driver foi inserido no makefile da STAPI de forma a ser compilado e

copiado para o sistema de arquivos do STLinux em conjunto com a

compilação normal da STAPI. Para isto foi adicionada uma variável de

$ cd /opt/STM/stapisdk/stapp $ source ../bin/setenv.sh COCOREF_GOLD_7109_LINUX $ make purge_all $ make all $ make install

38

ambiente no arquivo setenv.sh chamada $SIRDAI. Esta variável é testada

dentro do makefile, caso ela exista o driver será compilado e instalado no

sistema embarcado. A seguir, podem-se ver trechos do

stapisdk/stapp/makefile:

Código 13 - Partes modificadas do arquivo stapisdk/stapp/makefile

Agora, quando a plataforma STAPI for compilada e instalada, estarão

disponíveis também no STB os aplicativos tuner_scan e tuner_tune. Abaixo

tem-se uma amostra da execução do aplicativo tuner_scan rodando no

STLinux embarcado no STB:

… … ifeq "$(SIRDAI)" "1" @$(ECHO) Building SIRDAI DRIVER... -@$(MAKE) all -C sirdai/main/ endif … … … ifeq "$(SIRDAI)" "1" install : install_make_dirs install_stapi install_stgfb install_sirdai else install : install_make_dirs install_stapi install_stgfb endif ... ... install_sirdai: -@$(CP) sirdai/main/tuner_tune $(KTARGET)/ -@$(CP) sirdai/main/tuner_scan $(KTARGET)/

39

Código 14 - Saída do aplicativo rastreador de canais ISDB-T.

Para que fosse possível a integração com a STAPI, nesta etapa foi

implementada uma comunicação inter-processo utilizando o método de

acesso de arquivo na linguagem C. Este método abre um terminal Linux e

acessa diretamente seu file descriptor, permitindo que se execute um

comando no SO Linux e obtenha a sua saída de terminal padrão. Logo, como

o aplicativo tuner_scan imprime os canais na saída padrão, é possível obtê-

los com o método pipe dentro da STAPI.

STMicroelectronics Base Distribution version 2.3 LDDE_LINUX login: root Linux LDDE_LINUX 2.6.23.17_stm23_0116-COCOREF_GOLD_7109-STSDK #4

PREEMPT Wed Sep 30 15:00:07 BRT 2009 sh4 unknown unknown GNU/Linux Welcome to STMicroelectronics Base Distribution. Last login: Sat Jan 1 00:00:35 +0000 2000 on console. No mail. root@LDDE_LINUX:~# tuner_scan 521143 586143 root@LDDE_LINUX:~#

40

Código 15 - Exemplo de utilização do PIPE com File Descriptor no Linux, em linguagem C.

Para teste da aplicação, foi utilizado o TestTool, programa de

depuração da STAPISDK. No código-fonte deste programa, foi criado um

comando que executava um rotina utilizando o método de pipe e file

descriptor para acessar os aplicativos tuner_tune e tuner_scan. Desta forma,

as saídas dos aplicativos eram tratadas dentro do programa TestTool,

disponibilizando informações destes aplicativos ao ambiente da camada

STAPP.

#include <stdio.h> … FILE *fp; char buffer[7]; fp = popen("./tuner_scan", "r"); while ( fgets( buffer, sizeof(buffer), fp)) { …. TUNER_Canais [n_canal] = atoi (buffer); …. } pclose(fp);

41

Figura 14 - Camadas do Linux, aplicativo sintonizador, STAPP e comunicação entre processos e hardware no ambiente de desenvolvimento.

Nesta figura, é possível verificarmos a hierarquia das camadas

abordadas na integração do aplicativo com a STAPP e as setas mostram os

módulos de Kernel utilizados para acesso ao hardware. A imagem também

ilustra o barramento I2C interno ao Sintonizador SIRDAI, o qual é acessado

através do controlador I2C servindo como ponte para o barramento do Set

Top Box, assim disponibilizando o controle dos chips ao Kernel do STLinux.

(Linux PIPE)

Hardware (Set Top Box)

STDEBUG

STLinux (Kernel)

STAPI

Driver SIRDAI

STAPP

Aplicativo do

Sintonizador

Barramento I2C

Sintonizador SIRDAI

I2C

module

Multicom

modules

Barramento I2C interno

Controlador

I2C

Chip 0 Chip 1 Chip 2

42

4 CONCLUSÃO

O sistema operacional Linux se mostra cada vez mais versátil, sendo

utilizado nas mais diversas áreas e aplicações. Os device drivers

desempenham um papel essencial, possibilitando a intercomunicação de

componentes de hardware com aplicações de vital importância para qualquer

sistema operacional.

Foi possível observar que as ferramentas utilizadas para portar e

embarcar o Linux em outras arquiteturas estão cada vez mais amigáveis,

expandindo os horizontes deste sistema operacional às mais diversas

aplicações em dispositivos dedicados.

Neste trabalho, foram abordados alguns procedimentos para a

aplicação de um SO Linux em um Set Top Box da TV Digital. Abrangendo

algumas etapas de instalação do STLinux no STB, com chipset de arquitetura

SH4, foi possível adquirir conhecimentos importantes sobre ferramentas e

procedimentos aplicáveis ao embarcar os mais diversos sistemas

operacionais Linux.

As pesquisas nas áreas de sistemas embarcados, sistemas de

transmissão de TV Digital e sistemas operacionais estão em constante

evolução. Novos conjuntos de ferramentas, bibliotecas e APIs emergem da

comunidade científica simplificando os procedimentos para análise,

depuração e desenvolvimento de sistemas embarcados, dos simples aos

mais complexos.

Convém dizer que o sintonizador produzido pelo projeto SIRDAI-TVD é

muito importante na evolução dos sistemas de recepção de TV Digital. Ele

43

motivou a realização deste trabalho e proporcionou aprendizados de muito

valor. As pesquisas realizadas, como sobre a implantação da TV Digital no

brasil e normas de transmissão deste sistema para criar o aplicativo de

rastreamento de canais, formaram uma base de conhecimentos que

continuarão sendo aprofundados no futuro.

44

REFERÊNCIAS

[1] TANENBAUM, Andrew S. : Modern operating systems. Upper Saddle River: 3ª edição, Prentice Hall do Brasil, 2008. [2] RUBINI, Alessandro; CORBET, Jonathan: Linux device drivers. 2nd ed., Beijing: O'Reilly, 2001. [3] MITCHELL, M.: Advanced Linux Programming. New Riders Publishing, 2001. [4] BOVETI, D.; CESATI, M.: Understanding the Linux Kernel, 3rd ed.: O´reilly, 2005. [5] Bowick, C.: RF circuit design. Newnes. 2007. [6] ABNT NBR 15601:2007 – Televisão Digital Terrestre – Sistema de Transmissão. 2007. [7] Nakahara, J.: ISDB-T for Sound Broadcasting. Terrestrial Digital Radio in Japan. ABU Seminar 2003. Disponível em www.rthk.org.hk/about/digitalbroadcasting/DSBS/ABU_AIR_2003/ses2.pdf

[8] TANENBAUM, ANDREW S.: Organização Estruturada de Computadores, Addison-Wesley Professional, 5nd edition, 2006. [9] GNU Make Manual Home Page, http://www.gnu.org/software/make/manual/make.html#Overview [10] Eric S. Raymond.: The Art of UNIX Programming. Addison Wesley, 2005.

45

ANEXOS

46

ANEXO A. Tabela dos países em processo de implementação da TVD

47

48

ANEXO B. Saída da porta serial do STB com o carregamento normal do STLinux embarcado.

picocom -b 115200 /dev/ttyUSB0 picocom v1.4 port is : /dev/ttyUSB0 flowcontrol : none baudrate is : 115200 parity is : none databits are : 8 escape is : C-a noinit is : no noreset is : no nolock is : no send_cmd is : ascii_xfr -s -v -l10 receive_cmd is : rz -vv Terminal ready Board: STb7100-Reference (MB442) [29-bit mode] U-Boot 1.3.1 (Sep 30 2009 - 17:05:30) - stm23_0042 DRAM: 128 MiB NOR: 32 MiB *** Warning - bad CRC, using default environment In: serial Out: serial Err: serial Hit any key to stop autoboot: 0 ## Booting image at a0040000 ... Image Name: Linux 2.6 Image Type: SuperH Linux Kernel Image (gzip compressed) Data Size: 2578493 Bytes = 2.5 MiB Load Address: 84601000 Entry Point: 84602000 Verifying Checksum ... OK Uncompressing Kernel Image ... OK Starting kernel console=ttyAS1,115200 root=/dev/nfs rw mtdparts=physmap-

flash:256k,3072k,- mem=36m stmmaceth=phyaddr:5 nwhwconf=device:eth0,hwaddr:00:22:C2:00:78:15 nfsroot=192.168.0.9:/opt/STM/STLinux-2.3/devkit/sh4/target,nfsvers=2,rsize=4096,wsize=8192,tcp ip=192.168.0.10::192.168.0.1:255.255.255.0:LDDE_LINUX::off bigphysarea=2500 - 0x00000000 - 0 ...

Linux version 2.6.23.17_stm23_0116-COCOREF_GOLD_7109-STSDK

(root@localhost.localdomain) (gcc version 4.2.4 (snapshot) (STMicroelectronics/Linux Base 4.2.4-42)) #4 PREEMPT Wed Sep 30 15:00:07 BRT 2009

Booting machvec: STb7100 Reference board Node 0: start_pfn = 0x4600, low = 0x6a00 Zone PFN ranges: Normal 17920 -> 27136 Movable zone start PFN for each node early_node_map[1] active PFN ranges

49

0: 17920 -> 27136 STMicroelectronics STb7100 Reference board initialisation STx7109 version 3.x Chip version 3.2 Built 1 zonelists in Zone order. Total pages: 9144 Kernel command line: console=ttyAS1,115200 root=/dev/nfs rw mtdparts=physmap-

flash:256k,3072k,- mem=36m stmmaceth=phyaddr:5 nwhwconf=device:eth0,hwaddr:00:22:C2:00:78:15 nfsroot=192.168.0.9:/opt/STM/STLinux-2.3/devkit/sh4/target,nfsvers=2,rsize=4096,wsize=8192,tcp ip=192.168.0.10::192.168.0.1:255.255.255.0:LDDE_LINUX::off bigphysarea=2500

BPA2 (bigphysarea) @ 0x04b09000 size 0x009c3fff PID hash table entries: 256 (order: 8, 1024 bytes) Using tmu for system timer Using 16.594 MHz high precision timer. Console: colour dummy device 80x25 console [ttyAS1] enabled Dentry cache hash table entries: 8192 (order: 3, 32768 bytes) Inode-cache hash table entries: 4096 (order: 2, 16384 bytes) Memory: 21636k/36864k available (3669k kernel code, 834k data, 132k init) PVR=04061100 CVR=30480000 PRR=00009300 I-cache : n_ways=2 n_sets=256 way_incr=8192 I-cache : entry_mask=0x00001fe0 alias_mask=0x00001000 n_aliases=2 D-cache : n_ways=2 n_sets=512 way_incr=16384 D-cache : entry_mask=0x00003fe0 alias_mask=0x00003000 n_aliases=4 Mount-cache hash table entries: 512 CPU: STb7109 NET: Registered protocol family 16 Generic PHY: Registered new driver SCSI subsystem initialized usbcore: registered new interface driver usbfs usbcore: registered new interface driver hub usbcore: registered new device driver usb Time: SuperH clocksource has been installed. NET: Registered protocol family 2 IP route cache hash table entries: 1024 (order: 0, 4096 bytes) TCP established hash table entries: 2048 (order: 2, 16384 bytes) TCP bind hash table entries: 2048 (order: 1, 8192 bytes) TCP: Hash tables configured (established 2048 bind 2048) TCP reno registered JFFS2 version 2.2. (NAND) © 2001-2006 Red Hat, Inc. JFS: nTxBlock = 169, nTxLock = 1353 io scheduler noop registered io scheduler anticipatory registered (default) io scheduler deadline registered io scheduler cfq registered STMicroelectronics ASC driver initialized stasc.0: ttyAS0 at MMIO 0x18032000 (irq = 121) is a stasc stasc.1: ttyAS1 at MMIO 0x18033000 (irq = 120) is a stasc RAMDISK driver initialized: 16 RAM disks of 4096K size 1024 blocksize STMMAC driver: platform registration... <6>done! MAC 10/100 no valid MAC address; please, set using ifconfig or nwhwconfig! STMMAC MII Bus: probed STe100p: Registered new driver STe101p: Registered new driver pegasus: v0.6.14 (2006/09/27), Pegasus/Pegasus II USB Ethernet driver usbcore: registered new interface driver pegasus usbcore: registered new interface driver asix

50

usbcore: registered new interface driver cdc_ether usbcore: registered new interface driver net1080 usbcore: registered new interface driver zaurus rt73: init usbcore: registered new interface driver rt73 usbcore: registered new interface driver zd1201 usbcore: registered new interface driver usb8xxx nwhw_config: (eth0) setting mac address: 00:22:C2:00:78:15 scsi0 : sata_stm ata1: SATA max UDMA/133 cmd 0xb9209000 ctl 0xb9209820 bmdma 0x00000000

irq 170 ata1: SATA link down (SStatus 0 SControl 300) physmap platform flash device: 02000000 at 00000000 physmap-flash: Found 1 x16 devices at 0x0 in 16-bit bank Intel/Sharp Extended Query Table at 0x010A Intel/Sharp Extended Query Table at 0x010A Intel/Sharp Extended Query Table at 0x010A Intel/Sharp Extended Query Table at 0x010A Intel/Sharp Extended Query Table at 0x010A Intel/Sharp Extended Query Table at 0x010A Using buffer write method Extended Query version 1.3 Feature/Command Support: 03E6 - Chip Erase: unsupported - Suspend Erase: supported - Suspend Program: supported - Legacy Lock/Unlock: unsupported - Queued Erase: unsupported - Instant block lock: supported - Protection Bits: supported - Page-mode read: supported - Synchronous read: supported - Simultaneous operations: supported - Extended Flash Array: unsupported Supported functions after Suspend: 01 - Program after Erase Suspend: supported Block Status Register Mask: 0001 - Lock Bit Active: yes - Lock-Down Bit Active: no - EFA Lock Bit: no - EFA Lock-Down Bit: no Vcc Logic Supply Optimum Program/Erase Voltage: 1.8 V Vpp Programming Supply Optimum Program/Erase Voltage: 9.0 V cfi_cmdset_0001: Erase suspend on write enabled 3 cmdlinepart partitions found on MTD device physmap-flash Creating 3 MTD partitions on "physmap-flash": 0x00000000-0x00040000 : "Partition_000" 0x00040000-0x00340000 : "Partition_001" 0x00340000-0x02000000 : "Partition_002" stm-ehci stm-ehci.0: STM EHCI Host Controller stm-ehci stm-ehci.0: new USB bus registered, assigned bus number 1 stm-ehci stm-ehci.0: irq 169, io mem 0x191ffe00 stm-ehci stm-ehci.0: USB 0.0 started, EHCI 1.00, driver 10 Dec 2004 usb usb1: configuration #1 chosen from 1 choice hub 1-0:1.0: USB hub found hub 1-0:1.0: 1 port detected stm-ohci stm-ohci.0: STM OHCI Host Controller stm-ohci stm-ohci.0: new USB bus registered, assigned bus number 2 stm-ohci stm-ohci.0: irq 168, io mem 0x191ffc00 usb usb2: configuration #1 chosen from 1 choice

51

hub 2-0:1.0: USB hub found hub 2-0:1.0: 1 port detected Initializing USB Mass Storage driver... usb 1-1: new high speed USB device using stm-ehci and address 2 usb 1-1: configuration #1 chosen from 1 choice scsi1 : SCSI emulation for USB Mass Storage devices usbcore: registered new interface driver usb-storage USB Mass Storage support registered. mice: PS/2 mouse device common for all mice i2c /dev entries driver usbcore: registered new interface driver usbhid drivers/hid/usbhid/hid-core.c: v2.6:USB HID core driver STMicroelectronics - Coprocessors st231 Init st-coprocessor-0: No RAM reserved st231.0 Coprocessor ------------------------------------------- not configured! --------------------------------------------------------------- st-coprocessor-1: No RAM reserved st231.1 Coprocessor ------------------------------------------- not configured! --------------------------------------------------------------- stm_rng hardware driver 1.0 configured TCP cubic registered NET: Registered protocol family 1 NET: Registered protocol family 17 ieee80211: 802.11 data/management/control stack, git-1.1.13 ieee80211: Copyright (C) 2004-2005 Intel Corporation <jketreno@linux.intel.com> stmmac_timer: TMU2 Timer ON (freq 256Hz) IP-Config: Complete: device=eth0, addr=192.168.0.10, mask=255.255.255.0, gw=192.168.0.1, host=LDDE_LINUX, domain=, nis-domain=(none), bootserver=255.255.255.255, rootserver=192.168.0.9, rootpath= Looking up port of RPC 100003/2 on 192.168.0.9 PHY: 0:05 - Link is Up - 100/Full scsi 1:0:0:0: Direct-Access Audio Player PQ: 0 ANSI: 0 CCS sd 1:0:0:0: [sda] 4083712 512-byte hardware sectors (2091 MB) sd 1:0:0:0: [sda] Write Protect is off sd 1:0:0:0: [sda] Assuming drive cache: write through sd 1:0:0:0: [sda] 4083712 512-byte hardware sectors (2091 MB) sd 1:0:0:0: [sda] Write Protect is off sd 1:0:0:0: [sda] Assuming drive cache: write through sda: sda1 sd 1:0:0:0: [sda] Attached SCSI removable disk Looking up port of RPC 100005/1 on 192.168.0.9 VFS: Mounted root (nfs filesystem). Freeing unused kernel memory: 132k freed INIT: version 2.86 booting Fast Starting Kernel event manager... Activating swap. Checking all file systems... fsck 1.39 (29-May-2006) Mounting local filesystems... Cleaning /tmp /var/run /var/lock. Setting up networking...done. Hostname: LDDE_LINUX. Setting up IP spoofing protection: rp_filter. Disable TCP/IP Explicit Congestion Notification: done. Configuring network interfaces: done. Starting portmap daemon: portmap.

52

Fast Replaying boot udev events... STMicroelectronics Base Distribution version 2.3 LDDE_LINUX login: root Linux LDDE_LINUX 2.6.23.17_stm23_0116-COCOREF_GOLD_7109-STSDK #4

PREEMPT Wed Sep 30 15:00:07 BRT 2009 sh4 unknown unknown GNU/Linux Welcome to STMicroelectronics Base Distribution. Last login: Sat Jan 1 00:00:35 +0000 2000 on console. No mail. root@LDDE_LINUX:~#

53

ANEXO C. Tabela de Canais UHF e suas respectivas frequências de sintonização. (ABNT)

Canal Freqüência inicial (MHz)

Freqüência final (MHz)

Freqüência de Sintonização (MHz)

14 470 476 473 + 1/7 MHz

15 476 482 479 + 1/7 MHz

16 482 488 485 + 1/7 MHz

17 488 494 491 + 1/7 MHz

18 494 500 497 + 1/7 MHz

19 500 506 503 + 1/7 MHz

20 506 512 509 + 1/7 MHz

21 512 518 515 + 1/7 MHz

22 518 524 521 + 1/7 MHz

23 524 530 527 + 1/7 MHz

24 530 536 533 + 1/7 MHz

25 536 542 539 + 1/7 MHz

26 542 548 545 + 1/7 MHz

27 548 554 551 + 1/7 MHz

28 554 560 557 + 1/7 MHz

29 560 566 563 + 1/7 MHz

30 566 572 569 + 1/7 MHz

31 572 578 575 + 1/7 MHz

32 578 584 581 + 1/7 MHz

33 584 590 587 + 1/7 MHz

34 590 596 593 + 1/7 MHz

35 596 602 599 + 1/7 MHz

54

36 602 608 605 + 1/7 MHz

37 RESERVADO - Não utilizado para televisão

38 614 620 617 + 1/7 MHz

39 620 626 623 + 1/7 MHz

40 626 632 629 + 1/7 MHz

41 632 638 635 + 1/7 MHz

42 638 644 641 + 1/7 MHz

43 644 650 647 + 1/7 MHz

44 650 656 653 + 1/7 MHz

45 656 662 659 + 1/7 MHz

46 662 668 665 + 1/7 MHz

47 668 674 671 + 1/7 MHz

48 674 680 677 + 1/7 MHz

49 680 686 683 + 1/7 MHz

50 686 692 689 + 1/7 MHz

51 692 698 695 + 1/7 MHz

52 698 704 701 + 1/7 MHz

53 704 710 707 + 1/7 MHz

54 710 716 713 + 1/7 MHz

55 716 722 719 + 1/7 MHz

56 722 728 725 + 1/7 MHz

57 728 734 731 + 1/7 MHz

58 734 740 737 + 1/7 MHz

59 740 746 743 + 1/7 MHz

60 746 752 749 + 1/7 MHz

61 752 758 755 + 1/7 MHz

55

62 758 764 761 + 1/7 MHz

63 764 770 767 + 1/7 MHz

64 770 776 773 + 1/7 MHz

65 776 782 779 + 1/7 MHz

66 782 788 785 + 1/7 MHz

67 788 794 791 + 1/7 MHz

68 794 800 797 + 1/7 MHz

69 800 806 803 + 1/7 MHz

56

ANEXO D. ISDB-T Segmentação dos canais

Figura 15 - Segmentação do canal em formato ISDB-T.

57

ANEXO E. Diagramas de blocos demoduladores

Figura 16 - Exemplo de diagrama de blocos de um Font-End receptor

Figura 17 - Exemplo de diagrama de blocos de um Back-End receptor.

Antena Entrada de

Sinal RF

Tratamento de RF

Saída para demodulador

Saída do front-end

Conversor

A/D

Interpolação e Filtragem

FFT EQ Desentrelaçador

Correção de Erros

MPEG-TS

58

ANEXO F. Código parcial específico da placa ST do STB no arquivo de configurações da STAPISDK (setenv.sh)

########################################################### ## STB7109 - COCOREF_GOLD/LINUX - Hardware configuration ## ########################################################### if [ "$1" = "COCOREF_GOLD_7109_LINUX" ] ; then echo COCOREF_GOLD_7109_LINUX Configuration selected ! export STB7109ROOT=$STSDKROOT/apilib export DVD_MAKE=$STB7109ROOT/make export DVD_ROOT=$STB7109ROOT/src export DVD_EXPORTS=$STB7109ROOT/lib export DVD_INCLUDE=$STB7109ROOT/include export DVD_CONFIG=$STB7109ROOT/config export DVD_TRANSPORT=stpti4 export DVD_PLATFORM=cocoref_gold export DVD_BACKEND=7109 export DVD_FRONTEND_TUNER=FE_DIB8096T #FE_DNIS22CX241A export DVD_SERVICE=DVB export DVD_DISPLAY_SD=D_NTSC export DVD_DISPLAY_HD=D_1080I60HZ export HEAP_WITH_STSDK=0 export RUN_FROM_FLASH=1 export TARGET=192.168.0.3 export ARCHITECTURE=ST40 export DVD_OS=LINUX export LINUX_VERSION=2.3 export LINUX_UNIFIED_STAPI=1 export RPC_SOURCE=/opt/STM/MULTICOM/R3.2.2p2 export PATH=/opt/STM/STLinux-$LINUX_VERSION/devkit/sh4/bin:$PATH export MANPATH=/opt/STM/STLinux-$LINUX_VERSION/host/man:$MANPATH export KDIR=/opt/STM/STLinux-$LINUX_VERSION/devkit/sources/kernel/linux-

sh4 export KTARGET=/opt/STM/STLinux-$LINUX_VERSION/devkit/sh4/target/root export LINUX_TARGETIP=192.168.0.10 export LINUX_SERVERIP=192.168.0.9 export LINUX_GWIP=192.168.0.1 export LINUX_NETMASK=255.255.255.0 export LINUX_NAME=stapisdk export LINUX_AUTOCONF=off export LINUX_SERVERDIR=/opt/STM/STLinux-

$LINUX_VERSION/devkit/sh4/target export LINUX_KERNEL=$KDIR/vmlinux export LINUX_PARAMETERS="console=ttyAS1,115200 \ root=/dev/nfs rw mtdparts=physmap-flash:256k,3072k,- \ nwhwconf=device:eth0,hwaddr:00:22:C2:00:78:15 \

nfsroot=$LINUX_SERVERIP:$LINUX_SERVERDIR,rsize=4096,wsize=8192,tcp \ ip=$LINUX_TARGETIP::$LINUX_GWIP:$LINUX_NETMASK:$LINUX_NAME:eth0:$LINUX_AUTOCONF \ mem=128m \

stmmaceth=phyaddr:5 \ coprocessor_mem=4m@0x10000000, 4m@0x10400000 \ bigphysarea=2500" fi

59

ANEXO G. Fotos das conexões com a placa do STB, sintonizador SIRDAI e o desktop de desenvolvimento.

Figura 18 - Indicação dos polos para o conector TTL na placa do STB.

Figura 19 - Visão geral do equipamento utilizado. À esquerda, o sintonizador SIRDAI conectado na placa do STB.

60

Figura 20 - Detalhe do sintonizador SIRDAI. Pode-se reparar os dois chips DIBCOM DIB8096, promovendo a diversidade de recepção para duas antenas. Os conectores F acoplados no sintonizador.

Figura 21 - Detalhe da conexão do sintonizador SIRDAI com a placa do STB. É importante notar que foi utilizada a mesma interface de pinos do sintonizador original do STB. Este sintonizador original foi dessoldado.

61

ARTIGO

Aplicativo para Sintonizador Utilizando Diversidade de

Recepção de Sinal

Odyr Apoena Bernanos de Zayas Sohn

Departamento de Informática e Estatística – Universidade Federal de Santa Catarina

Florianópolis – Santa Catarina - Brasil

odyrsohn@inf.ufsc.br

Abstract. This meta-paper shows how we can enable the diversity chain on

tuners that have the diversity in signal reception, this way you can take

advantages of this technology and have a better signal reception.

Resumo. Este trabalho apresenta um estudo para implementação e

habilitação da cadeia de diversidade em sintonizadores com diversidade de

recepção, demonstrando como utilizar este recurso presente em alguns

receptores de alta tecnologia disponibilizados pela indústria de

telecomunicações.

1. 1. INTRODUÇÃO Este artigo apresenta como implementar, em linguagem C, um aplicativo para um

sintonizador com chip de diversidade de recepção de sinal de TV-Digital. A pesquisa

também apresenta informações sobre o sistema ISDB-T, objetivando a programação

de funcionalidades relacionadas ao espectro de freqüências do sistema para o

rastreamento e sintonização de canais do SBTVD. O aplicativo terá a finalidade de

sintonizar e rastrear canais do sistema brasileiro de transmissão terrestre de TV-

Digital no padrão ISDB-T executado em um Set Top Box.

2. 3. SET TOP BOX Os Set Top Boxes (STBs) são sistemas embarcados cuja principal funcionalidade é

receber o sinal da TV Digital, decodificá-lo, descompactá-lo e mostrar a imagem ao

expectador. Porém, estes dispositivos não se limitam a apenas estas funções básicas.

Sistemas operacionais são embarcados nos STBs para que tenhamos uma maior

flexibilidade e para que várias funcionalidades extras possam ser desenvolvidas para o

sistema. Um exemplo de funcionalidade extra, seria a gravação de programas da TV

Digital em horários pré-programados, armazenando-os em dispositivos e mídias

removíveis, como pendrives USB.

62

Figura 22 – Exemplo de um diagrama de blocos de STB.

Outra aplicação é a interação com o usuário, como enquetes, por exemplo, em que o

expectador pode responder com o controle remoto do dispositivo e suas respostas

serem enviadas através de uma conexão do STB com a internet.

3. 2. SISTEMA DE TRANSMISSÃO DE TV-DIGITAL (ISDB-T) A sigla ISDB-T significa Terrestrial Integrated Services Digital Broadcasting. É um

sistema japonês, criado pela ARIB, Association of Radio Industries and Businesses.

Foi o sistema selecionado como base para a implantação nacional da transmissão de

TV Digital. A característica principal deste sistema é especificar a transmissão de

vídeo, áudio e dados, de forma independente ou em qualquer combinação destes. O

receptor recebe um sinal de radiofrequência e disponibiliza os dados para o

decodificador. O diagrama de blocos da figura seguinte representa as funcionalidades

básicas do sistema para sua transmissão e recepção.

63

Figura 23 – Diagrama básico para transmissão do sinal ISDB-T (as linhas pontilhadas representam fluxo de controle, enquanto que as contínuas, fluxo de sinal).

Para a transmissão digital foi reservada a faixa de 470 MHz a 806 MHz, com exceção

da faixa de 608 MHz a 614 MHz, canal 37. Esta transmissão ocorre dentro da faixa

compreendida por UHF, Ultra-High Frequency, pode-se traduzir em canais de 14 a

69, com exceção do canal 37. Por uma questão organizacional, apenas depois de

terminado o processo de implantação da transmissão digital e encerramento das

transmissões analógicas é que a banda VHF, Very High Frequency, será utilizada

também para transmissões digitais.

Cada canal UHF dispõe de 6 MHz de banda, esta banda deve conter 14 segmentos,

sendo que destes, apenas uma largura aproximada de 5,572 MHz, contendo 13

segmentos, são utilizáveis para a transmissão de dados.

64

A figura acima demonstra os limites de espaçamento e a largura de banda utilizável

normatizada pela ABNT NBR15601:2007. Tais limites deverão ser respeitados por

qualquer transmissora de sinal.

4.1 4. SINTONIZADOR DE TV-DIGITAL COM DIVERSIDADE DE RECEPÇÃO

Um sintonizador de TV Digital pode ser separado em duas partes, são elas o front-end

e o back-end. De acordo com C. LI (2009) o front-end é o bloco do conjunto do

sintonizador receptor que opera na gama da radiofrequência, chamados de blocos RF,

sendo o demodulador o delimitador entre front-end e back-end. Já o back-end, ainda

no caso do receptor, opera após a demodulação na gama de frequências

intermediárias.

4. Na figura acima, temos um diagrama genérico de um sintonizador para TV-Digital.

Na figura 5 tem-se o Back-End receptor com diversidade. Pode-se verificar que o

Combinador de Diversidade possui duas entradas e saídas de sinal. Os blocos

subsequentes, em vermelho, serão inabilitados nos chips em que a saída Div OUT está

ligada, denominados chips escravos. No chip mestre, último chip da cadeia de

diversidade, estes blocos serão ativados e a saída Div OUT, desativada. Quando o

sinal é captado pelo primeiro chip da cadeia ele sofre um atraso adicional em relação

Figura 25 - Diagrama de blocos genérico de um sintonizador.

Front-End Sinal RF Back-End TS

Figura 24 - Limites de utilização da banda disponível normatizada pela ABNT 15601:2007.

65

ao sinal do chip seguinte. Este atraso é decorrente da passagem pelo bloco

Combinador de Diversidade.

Figura 26 - Back-end receptor com diversidade, adicionado um bloco Combinador de Diversidade.

Desta forma, para implementar um algoritmo rastreador e sintonizador, devemos

utilizar as informações de recepção do modelo de transmissão adotado no Brasil e do

hardware sintonizador demonstrado de maneira genérica. Este chip com diversidade

de recepção trabalha em conjunto com outros chips formando a cadeia de diversidade.

Como podemos verificar no diagrama abaixo.

Saída do

Front-End

Conversor

A/D

Interpolação e Filtragem

FFT EQ

Combinador de Diversidade

Desentrelaçador Correção de

Erros

Div OUT

MPEG TS

Div IN

66

Figura 27 - Sistema mestre/escravo dos chips com diversidade.

5. APLICATIVO SINTONIZADOR Daremos uma abordagem genérica de como este algoritmo deverá ser implementado,

respeitando os limites e padrões do sistema ISDB-T de transmissão de TV-Digital no

Brasil. Utilizando os drivers do próprio fabricante podemos estruturar o código desta

maneira.

Sintonizador

Escravo 2

Div OUT

Div IN

T

S

O

U

T

Sintonizador

Escravo 1

Div OUT

Div IN

T

S

O

U

T

MPEG TS Sintonizador

Master

Div OUT

Div IN

T

S

O

U

T

Sintonizador

Escravo 0

Div IN

T

S

O

U

T Div OUT

RF

RF

RF

RF

67

Figura 7 - Pseudo-algoritmo para escrita dos atrasos nos chips sintonizadores.

O pseudo-código acima demonstra como devem ser relacionados os atrasos que cada

chip deverá implementar no armazenamento do sinal de entrada para que o chip

anterior entregue o sinal em tempo sincronizado. O pseudo-código abaixo demonstra

como pode ser implementada a cadeia de diversidade.

/// cabeçalho #define ENDEREÇO_BASE_SIRDAI_I2C 0x22 #define ENDEREÇO_REGITRADOR_ATRASO 56 struct chip { uint8_t subendereco_i2c; uint16_t atraso_diversidade; } /// código struct chip dib8096[4] = { { 0x90, 30 }, //chip mestre { 0x92, 20 }, //chip escravo { 0x94, 10 }, //chip escravo { 0x96, 0 }, //chip escravo (1

o da cadeia de recepção)

} for (int i = 0; i < sizeof(dib8096); i++){ i2c_escreva_word_reg(dib8096[i], ENDEREÇO_REGITRADOR_ATRASO,

dib8096[i].atraso_diversidade) } int i2c_escreva_word_reg(struct chip [ ], uint8_t reg, uint16_t dados) { uint32_t msg; msg = (chip.subendereco_i2c << 24) + (reg << 16) + dados; i2c_escreva (ENDEREÇO_BASE_SIRDAI_I2C, msg ); }

68

Figura 8 - Pseudo-algoritmo para implementação do sistema mestre/escravo nos chips da cadeia de diversidade.

O algoritmo para rastreamento de canais produzido é baseado nas normas oficiais do

sistema de transmissão terrestre de TV Digital, adotado pelo Brasil em 2007 (ABNT

NBR 15601:2007). Com isso pode-se visualizar na fração de código seguinte, todas as

características intrínsecas às normas brasileiras.

6. CONCLUSÃO Implementar um algoritmo de sintonização e rastreamento para a TV-Digital com

dispositivos de sintonização que utilizam diversidade de recepção para melhorar o

sinal. Demonstrado de forma genérica em pseudo-algoritmo similar a linguagem de

programação C. Assim pode-se fazer uso de tecnologias avançadas em recepção de

sinal de TV-Digital.

int count = sizeof(dib8096); uint16_t reg_div_e = 78; // endereco_registrador_entrada_diversidade uint16_t reg_div_s = 79; // endereco_registrador_saida_diversidade for (i = 0; i < count; i++) { if (i == count-1) { // Sintonizador Escravo 0 // configura a entrada de diversidade como desligada i2c_escreva_word_reg(dib8096[i], reg_div_e, 0); // configura a saida de diversidade como ligada i2c_escreva_word_reg(dib8096[i], reg_div_s, 1); } else { // demais Sintonizadores Escravos // configura a entrada de diversidade como ligada i2c_escreva_word_reg(dib8096[i], reg_div_e, 1); // configura a saida de diversidade como ligada i2c_escreva_word_reg(dib8096[i], reg_div_s, 1); } if (i == 0) { // Sintonizador mestre, apenas saida de TS ligada i2c_escreva_word_reg(dib8096[i], reg_div_s, 0); } }

69

7. REFERÊNCIAS

Bowick, C.: RF circuit design. Newnes. 2007.

ABNT NBR 15601:2007 – Televisão Digital Terrestre – Sistema de Transmissão.

2007.

Nakahara, J.: ISDB-T for Sound Broadcasting. Terrestrial Digital Radio in

Japan. ABU Seminar 2003. Disponível em

www.rthk.org.hk/about/digitalbroadcasting/DSBS/ABU_AIR_2003/ses2.pdf

TANENBAUM, ANDREW S.: Organização Estruturada de Computadores,

Addison-Wesley Professional, 5nd edition, 2006.

Eric S. Raymond.: The Art of UNIX Programming. Addison Wesley, 2005