Curso USB Serial

ROGERCOM – Curso USB/Serial – www.rogercom.
com
ÍNDICE
Introdução ao USB (Universal Serial Bus) ............................................................................................. 1
Topologia USB (Tier star)....................................................................................................................... 7
Topologia física ...................................................................................................................................... 8
Hub ......................................................................................................................................................... 9
Portas Downstream e Upstream ............................................................................................................ 9
Tipos de produtos USB disponíveis no mercado ................................................................................... 9
Arquitetura típica de um sistema USB ................................................................................................... 9
Dispositivos com mini-hub incluso ....................................................................................................... 10
Controlador Host .................................................................................................................................. 11
UHCI..................................................................................................................................................... 12
OHCI..................................................................................................................................................... 12
EHCI ..................................................................................................................................................... 12
Visão geral do sistema USB................................................................................................................. 14
Tipos de conectores ............................................................................................................................. 15
Estrutura elétrica e sinais do cabo USB............................................................................................... 18
Corrente/tensão do BUS ...................................................................................................................... 18
Características do cabo USB ............................................................................................................... 19
Configuração de alta e baixa velocidades ........................................................................................... 20
Tipos de interfaces ............................................................................................................................... 21
Bus-powered ........................................................................................................................................ 24
Self-powered ........................................................................................................................................ 26
Protocolo .............................................................................................................................................. 28
Tipos de fluxo de dados ....................................................................................................................... 28
Control .................................................................................................................................................. 28
Interrupt Data........................................................................................................................................ 28
Isochronous .......................................................................................................................................... 29
Bulk Data .............................................................................................................................................. 29
Endpoints.............................................................................................................................................. 34
Pipes..................................................................................................................................................... 34
Stream .................................................................................................................................................. 35
Message ............................................................................................................................................... 36
Descritores ........................................................................................................................................... 36
Processo de enumeração .................................................................................................................... 43
Conhecendo o chipset FT232BM......................................................................................................... 45
Características...................................................................................................................................... 45
Pinagem ............................................................................................................................................... 47
Configuração ........................................................................................................................................ 48
Configuração da EEPROM 93C46 (56 ou 66) ..................................................................................... 48
Configurando uma interface Bus-powered........................................................................................... 50
Configurando uma interface Self-powered........................................................................................... 51
Configurando LEDs indicadores de comunicação (TX/RX) ................................................................. 54
Instalação e configuração de drivers relacionados aos chipsets FTDI................................................ 56
DLL ....................................................................................................................................................... 56
Porta Virtual COM (VCP) ..................................................................................................................... 65
Usando o aplicativo Mprog para gravar a EEPROM 93C46................................................................ 75
Programando a memória EEPROM 93C46 para personalizar o dispositivo ....................................... 82
Desinstalando os drivers D2XX e VCP ................................................................................................ 87
Introdução a Porta Serial...................................................................................................................... 91
Modos de transmissão serial................................................................................................................ 93
Simplex................................................................................................................................................. 94
Half-duplex ........................................................................................................................................... 94
Full-duplex ............................................................................................................................................ 94
DTE-DCE.............................................................................................................................................. 95
Tipos de transmissão ........................................................................................................................... 95
Síncrona ............................................................................................................................................... 95
Índice USB/Serial
ROGERCOM – Curso USB/Serial – www.rogercom.com
ÍNDICE
Assíncrona............................................................................................................................................ 96
Bit de paridade ..................................................................................................................................... 98
Interface RS232.................................................................................................................................... 99
Sinais elétricos ................................................................................................................................... 100
Conectores ......................................................................................................................................... 101
Controle de fluxo por software ........................................................................................................... 105
Controle de fluxo por hardware .......................................................................................................... 106
Cabo Null Modem............................................................................................................................... 107
Confecção de cabos para controle de Fluxo por Hardware............................................................... 108
Interligação LoopBack........................................................................................................................ 109
UART.................................................................................................................................................. 111
Registradores ..................................................................................................................................... 113
THR .................................................................................................................................................... 114
RDR.................................................................................................................................................... 114
DLH .................................................................................................................................................... 114
DLL ..................................................................................................................................................... 114
IER...................................................................................................................................................... 115
IIR ....................................................................................................................................................... 116
LCR .................................................................................................................................................... 116
MCR ................................................................................................................................................... 117
LSR..................................................................................................................................................... 118
MSR.................................................................................................................................................... 119
Funções da API do windows para acessar a Porta Serial ................................................................. 121
CreateFile()......................................................................................................................................... 122
GetCommState() ................................................................................................................................ 123
SetCommState()................................................................................................................................. 123
BuildCommDCB()............................................................................................................................... 125
GetCommTimeouts().......................................................................................................................... 126
SetCommTimeouts() .......................................................................................................................... 126
ReadFile()........................................................................................................................................... 127
WriteFile() ........................................................................................................................................... 128
CloseHandle()..................................................................................................................................... 129
EscapeCommFunction()..................................................................................................................... 130
SetCommBreak()................................................................................................................................ 130
ClearCommBreak() ............................................................................................................................ 130
TransmitCommChar()......................................................................................................................... 130
GetCommModemStatus() .................................................................................................................. 131
Interface para testar as linhas do Modem.......................................................................................... 133
Convertendo sinais padrão RS232 em TTL....................................................................................... 135
Interface foto-acoplada usando o CI 4N25 ........................................................................................ 135
Interface usando o driver MAX232..................................................................................................... 135
Trabalhando com o microcontrolador PIC 16F877 ............................................................................ 137
Pinagem do PIC 16F877 .................................................................................................................... 139
Funções: set_time0(),get_timer0(),set_tris_d(),setup_timer_0()........................................................ 140
Funções: enable_interrupts(),input(),output_bit(),output_high(),output_low() ................................... 140
Funções: delay_ms(), getc(),printf() ................................................................................................... 141
Diretivas: #int_rda,#include,#use delay,#fuses rs232........................................................................ 142
Tipos de osciladores: LP, XT, RC, HS ............................................................................................... 142
Tipos de fusíveis................................................................................................................................. 142
Definindo a direção dos pinos de I/O do PIC 16F877........................................................................ 143
Exemplos de circuitos e programação usando o PIC 16F877........................................................... 144
Circuito/programa pisca LED usando while()..................................................................................... 144
Circuito/programa pisca LED usando timer0() ................................................................................... 145
Circuito/programa lê botão (interuptor) .............................................................................................. 146
Índice USB/Serial
ROGERCOM – Curso USB/Serial – www.rogercom.com
ÍNDICE
Conectando o PIC 16F877 na Porta Serial RS232............................................................................ 148
Conectando o PIC 16F877 no Bus USB ............................................................................................ 149
Instalando o CCS C Compiler (Versão Trial Evaluation 30 dias)....................................................... 151
Configurando o MPLAB IDE para gravação do microcontrolador PIC16F877 .................................. 153
Escolhendo uma placa para gravar o microcontrolador PIC ............................................................. 162
Testando os circuitos da Aula 15 ....................................................................................................... 168
Projetos práticos................................................................................................................................. 169
Conversor USB<=>RS232 ................................................................................................................. 170
Conversor USB<=>RS485 ................................................................................................................. 171
Conversor USB/RS485<=>RS485/USB (numa distância de até 1.200m)......................................... 172
Comunicação USB<=>RS485 com o PIC16F877 a 256.000 bps ..................................................... 173
Interfaces Foto-acopladas.................................................................................................................. 176
Programação através das funções da dll FTD2XX.DLL .................................................................... 179
Trabalhando no modo Bit Bang para controle de 8 pinos (I/O paralela) ........................................... 190
Controle de Relês............................................................................................................................... 193
Sensor de temperatura....................................................................................................................... 201
Sensor de luminosidade..................................................................................................................... 205
Controle de Motor de Passo............................................................................................................... 208
Construindo um dirver Serial para controle de um display LCD via USB .......................................... 220
Controle de acesso sem fio através dos módulos RR3/RT4 da Telecontrolli.................................... 236
Informação: USB OTG (On The Go) .................................................................................................. 252
Informação: WUSB (USB Wireless) ................................................................................................... 252
Bibliografia.......................................................................................................................................... 253
Índice USB/Serial
ROGERCOM – Curso USB – www.rogercom.com
Bem vindo ao Curso USB - Universal Serial Bus
É com imensa alegria e satisfação que venho através deste curso, acrescentar a
todos um pouco da minha experiência com algumas pesquisas, testes e estudos
sobre o barramento USB. Espero que todos gostem e tirem o máximo proveito das
informações aqui contidas, para que possam aplicá-las nos seu novos projetos,
acrescentando uma tecnologia de ponta, mundialmente utilizada por diversos
fabricantes em milhares de dispositivos como: computadores, mouses, impressoras,
scanners, câmeras digitais, modems, celulares, relógios, aparelhos de som, placas
de interfaces, Finger Scanners, Players MP3, gravadores/leitores de CD-ROM/DVD,
memórias portáteis, entre outros. Parece até moda, mas na verdade, os produtos
com interfaces USB tornaram as vidas dos técnicos, usuários e consumidores de
eletrônicos muito mais fáceis. Onde antes, o usuário que deseja-se acrescentar por
exemplo, um scanner ao computador, era necessário abrir o gabinete, espetar uma
placa em um de seus slots, jampear, configurar endereços de DMA, IRQs, e no final
de tudo, ao rodar o software especifico, receber uma mensagem de erro do sistema
operacional, indicando conflitos entre dispositivos. Agora simplesmente "pluga-se" a
extremidade de um cabo USB, na traseira ou dianteira externa do gabinete, sem ser
preciso nenhum tipo de configuração. Pronto, o scanner está apto a trabalhar.
No sistema USB a tecnologia plug-and-play funciona na sua integra; você pode

conectar o dispositivo ao Hub e o sistema reconhece e carrega os device drivers
relacionados ao novo dispositivo, sem auxílio do usuário. Podemos conectar e
remover dispositivos sem ser preciso reiniciar o computador (Hot-Swap), ou mesmo
o sistema operacional.
Nas primeiras aulas iremos conhecer o sistema USB de um modo geral, para
nos capacitar a compreender as futuras aulas que tratarão da criação, programação
e desenvolvimento de circuitos usando os chipset da FTDI.
Optamos em utilizar os chipset da FTDI, por serem fáceis de utilizar; eficientes;

muito compactos (7, 2mm); uso opcional de uma memória flash para personalizar o
novo produto; bastante difundidos no mercado mundial; drivers e DLLs gratuitos
para vários sistemas operacionais e sem pagamento de Royalties; facilidades para
criar conversores RS232, RS422 e RS485.
Iremos também ter a oportunidade de programar um micro controlador PIC em

C, fazendo comunicação com a porta Serial para controle de dispositivos e aquisição
de dados.
Segue abaixo alguns produtos USB disponíveis atualmente no mercado:
Aula 01 – Módulo-USB / Página 1

Figura 1 - Auto Rádio MP3
Figuras 2 e 3
Figura 4 - Memória Flash

Figura 5 - Relógio com suporte USB Figura 6 - Pen drive
Figura 7 - Leitor/gravador de memory card Figura 8 - Impressora

Figura 9 – Multi acessórios Figura 10 - Mouse Figura 11- Câmera
Introdução ao Barramento USB
O USB (Universal Serial Bus) surgiu em 1995 com uma parceria entre várias
companhias de alta tecnologia (Compaq, Hewlett-Packard, Intel, Lucent, Microsoft,
NEC e Philips). Uma das primeiras versões foi a 1.0 com velocidade de 1,5Mbs
(Low-speed), logo em seguida foi concebida a 1.1 com velocidades que vai de
1,5Mbps a 12Mbps. Essa versão é conhecida com 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 trafego de
dados, chegando ao extremo de 480Mbps, equivalente a cerca de 60MBps (60
milhões de Bytes por segundos).
As primeiras versões do bus USB utilizavam/utilizam os Controladores Host

UHCI (Universal Host Controller Interface) e OHCI (Open Host Controller Interface).
O USB 2.0 utiliza o Controlador Host EHCI (Enhanced Host Controller Interface).
O barramento USB permite a conexão máxima de até 127 dispositivos em uma
única porta. Para isso ser possível utilizá-se de HUBs conectados em cascata.
Normalmente cada HUB USB dispõe de 4 a 8 portas onde podem ser plugados mais
HUBs ou dispositivos.
Os Hubs são componentes muito importantes na topologia de uma Rede USB.

Eles fornecem novos canais físicos para que se possam inserir novos dispositivos à
mesma.

Figura 12 - Mostra um Hub de 7 portas, sua fonte de alimentação e um cabo para conectar ao
Host/controlador
Os Hubs costumam ser ligados à Rede elétrica para alimentar seus circuitos e ao
mesmo tempo fornecer correntes suficientes para alimentar dispositivos conectados
às suas portas. Alguns Hubs não têem fontes externa, estes são parasitas,
alimentam-se da própria corrente do barramento USB. Esses Hubs não são uma boa
escolha se você pretende "plugar" dispositivos que também se alimentam através do
barramento.
Hubs sem fonte de alimentação chegam a ter 4 portas downstream, fornecendo

cada uma 100mA. Já Hubs com fontes de alimentação podem fornecer por porta,
500mA.
Se um dispositivo tentar consumir mais corrente do que o Hub pode fornecer

através de uma de suas portas, o mesmo permanecerá conectado fisicamente ao
barramento, mas não poderá se comunicar.

Figura 13 - Ilustração de um Hub e suas portas: primária e secundárias
Veja na figura acima, que a porta principal do Hub é chamada de Upstream, é

utilizada para conectá-lo ao Host (placa controladora/PC). As demais portas
secundárias são chamadas de Downstream, e servem para conectar outros Hubs ou
dispositivos (conhecidos também como função).
São através dos Hubs que o Host/controlador tem o poder de detectar se um

dispositivo (função) foi inserido ou removido do sistema, como também saber se o
mesmo funcionará em baixa ou alta velocidade.
Hubs também fornecem energia através de suas portas Downstream a

dispositivos que se alimentam do próprio Bus USB.

Figura 14 - Topologia USB (Tier star)
Num sistema USB existe apenas um HOST, os demais componentes são os

Hubs e os dispositivos (função).
Na figura acima temos 5 fileiras contando a partir do Host. Na especificação da

norma USB 1.1 fala-se que podemos enfileirar até 4 dispositivos/Hub após o Root
Hub, como mostra a figura acima (Hub1, Hub2, Hub4 e Node). Já na versão USB 2.0
é possível enfileirar até 6 dispositivos/Hub sem contar o Root Hub. É sempre bom
seguir essas regras quando for criar uma rede de dispositivos USB.
Também é importante saber que o comprimento do cabo USB é de 5m,

portanto, a distância máxima entre um Hub e um dispositivo/função fica limitada a
essa medida.

Figura 15 - Topologia física
A figura acima é um padrão da norma USB e mostra o esquema da topologia

física. No topo temos o Controlador Host (HC), mais abaixo o Root Hub, ou Hub
Raiz. É através das portas do Hub Raiz que conectamos Hub e dispositivos,
formando uma Rede USB.
Observe na figura acima que a combinação de um Hub e, um ou mais

dispositivos, é chamada de Compound Device (dispositivo composto).

Figura 16 - Arquitetura típica de um sistema USB
Veja na figura acima, que temos somente um Host (hospedeiro), alguns Hub e
vários dispositivos/funções pendurados ao sistema, em forma de uma árvore. Isso é
somente um exemplo de como agregar ao sistema USB, vários dispositivos distintos.
Dispositivos como: impressoras, áudio/vídeo, modem ADSL e WebCam,

consomem muita banda do sistema. Se você tiver esses equipamentos "plugados" e
funcionando simultaneamente em um Hub, observará uma queda na performance do
sistema; e quanto mais dispositivos forem sendo conectados, mais devagar será o
trafego de dados em todo o sistema. Esta perda de performance fica bem evidente
numa controladora OHCI/UHCI (USB 1.1 - 12Mbps máx.). Já numa controladora
EHCI (USB 2.0 - 480Mbps) a queda de performance é imperceptível, isso porque a
largura de banda da versão 2.0 é incomparavelmente maior que a da versão USB
1.1.

Figura 17 - Dispositivos com Hub incluso
Na configuração acima, vemos dispositivos conectados ao teclado e também ao

monitor, isso é possível porque alguns fabricantes incluem em seus dispositivos,
mini-hub, com uma ou mais portas downstream, tornando bastante prática a
conexão de webcams, joystick e mouses ao computador.
O hub/função do monitor tem sua própria fonte de alimentação, dessa forma

pode fornecer mais corrente para dispositivos conectados às suas portas. Já o
hub/função do teclado é alimentado pelo próprio Bus USB, fornecendo pouca
corrente às suas portas downstream. Nesse caso, o dispositivo conectado não pode
consumir mais que 100mA da porta.

Introdução ao Universal Serial Bus (USB)
CONTROLADOR HOST
O host USB se comunica com os dispositivos através do seu controlador

(chipset e outros componentes).
O controlador host pode ser encontrado na própria estrutura base da placa-mãe

do computador, ou pode ser adicionada num dos slots do barramento PCI. Na
maioria das placas controladoras USB PCI, além das portas externas, há uma
interna, que permite instalar periféricos USB dentro do gabinete do computador, se
isso for preciso.
É responsabilidade do Host:
• Detectar a inclusão e remoção de dispositivos;

• Gerenciar o fluxo de controle de dados entre os dispositivos conectados;
• Fornecer alimentação (tensão e corrente) aos dispositivos conectados;
• Monitorar os sinais do bus USB.
Figura 1 - Placa controladora USB 2.0 - 5 portas
Como já foi mencionado na aula anterior, o padrão USB foi desenvolvido por um
consórcio de empresas de tecnologia de ponta, destacando-se entre elas: Compaq,
Hewlett-Packard, Intel, Lucent, Microsoft, NEC e Philips.

Não foi fácil essas empresas chegarem a um acordo plausível sobre a

abordagem do controlador. Opiniões foram divididas e terminou formando-se dois
grupos diferentes:
UHCI - (Universal Host Controller Interface). Defendido e apoiado pela Intel, onde
uma parte do funcionamento do protocolo deveria ser processado no software
(driver), tornando o hardware do Controlador mais simples.
OHCI - (Open Host Controller Interface). Algumas empresas como a Compaq e a

Microsoft, concordavam e defendiam que a maior parte do processamento deveria
ser executado pelo hardware do Controlador, simplificando o driver (controlador
lógico).
Esse desacordo entre as empresas gerou incompatibilidade no padrão

USB.
EHCI - (Enhanced Host Controller Interface). Surgiu para unir o que de melhor tem
os dois modelos anteriores; como aumento significativo na velocidade de
comunicação (largura de banda) chegando ao extremo de 480Mbps, onde o driver
(software) e o hardware, trabalham dividindo o serviço para que dispositivos de
áudio e vídeo possam funcionar simultaneamente em alta velocidade.
Portanto, UHCI, OHCI, EHCI são modelos de controladores USB compostos de

software básico (driver) e hardware.
Um circuito Controlador consiste de duas partes: o Driver de Controle do Host

(HCD) que é um software básico (driver fornecido pelo fabricante), e um Controlador
Host (circuito que processa eletronicamente os sinais do barramento USB).
Controladores Host UHCI e OHCI estão associados à versão USB 1.1. Já o

controlador EHCI está associado à versão USB 2.0. O bus USB 2.0 também é
compatível com UHCI e OHCI. Sendo assim, o EHCI é agora um padrão USB
universal.

Figura 2 - Detalhes da placa controladora
É no Host onde o driver (software) do controlador é executado, dividindo o

processamento.
Na figura abaixo dá para se ter uma idéia geral do sistema USB, desde a
aplicação ou programa do cliente, ao driver do cliente; driver do sistema operacional;
driver do controlador; a placa do controlador (hardware) e, por fim, o dispositivo USB
do cliente, conectado a uma das portas USB do Root Hub.
Tanto a camada de software como a de hardware, está acomodada num único

Host (hospedeiro). Este hospedeiro tem que ser um computador (PC), mas já
existem dispositivos portáteis com características e poder de Host. Ou seja, podendo
acomodar camada de software e hardware como se fosse um PC. Essa tecnologia
atualmente é nova e se chama OTG (On-The-Go) e trataremos do assunto em aulas
futuras.

Figura 3 - Visão geral do sistema USB, camadas de software e hardware
Para entendermos melhor a ilustração gráfica acima, vamos partir da Aplicação

do Cliente (programa EXE). Imagine que o usuário a partir da sua Aplicação Cliente,
deseje enviar um comando para ligar um relê, no dispositivo USB (placa de controle
desenvolvida pelo usuário), mostrada na última camada de hardware (retângulo
azul). Observe os passos abaixo para entender melhor:
1 - A aplicação do cliente chama uma rotina da API passando-lhe parâmetros

de controle;
2 - A API por suas vez chama o Driver do Cliente. Ou seja, o software básico
do fabricante do Dispositivo USB. Este driver na maioria das vezes acompanha o
protudo adquirido pelo usuário; é instalado no sistema operacional tornando-se parte
do mesmo. Por exemplo, quando compramos uma máquina digital, vem com ela um
CD-ROM, contendo os drivers e a aplicação para visualizar fotos;
3 - O Driver USB (USBD) é um software básico que já vem agregado ao

sistema operacional, é ele quem garante ao Sistema Operacional suporte USB.
Versões mais antigas do Windows 95 e do Linux não dão suporte ao USB, porque
não agregam esses drivers em seus Kernel. Esse driver interpreta e traduz
comandos do Driver do Cliente e envia-os para o Driver do Controlador Host;

4 - O Driver do Controlador Host (HCD) é fornecido pelo fabricante da placa

do Controlador Host (HC). O HDC trabalha de forma direta com o HC, processando
a parte lógica do sistema USB;
5 - O Controlador Host (HC) ou placa controladora, onde contém o chipset,

Root Hub e demas componentes auxiliares, é a parte física do sistema USB onde
são conectados os dispositivos. O HC controla e detecta a inclusão e remoção de
dispositivos. Todos os sinais eletrônicos interpretados pelo HC são enviados para o
HCD, que por sua vez envia comandos para o USBD.
6 - Por último, temos o Dispositivo do Cliente, conectado ao Root Hob do HC.
Um dos nossos objetivos com esse curso, é criar a Aplicação (programa EXE) e
desenvolver o dispositivo (produto final), utilizando como base o chipset FT232BM
da FTDI. A API e os Drivers do Cliente são fornecidos pela própria FTDI sem
nenhum pagamento de royalties. Ou seja, podemos desenvolver um novo produto
USB, vender a um cliente e os drivers seguirem junto.
Estrutura elétricas do USB
Tipos de conectores
Há duas séries de conectores USB:
Série "A":
-Conector Tipo "A" Fêmea, encontrado no Host (PC), ou em portas Downstream de

Hub;
-Conector Tipo "A" Macho, encontrado em um dos extremos do cabo USB, onde
deve ser conectado ao Host/Root raiz, ou em portas Downstream de Hub.
Série "B":
-Conector Tipo "B" Fêmea, encontrado no dispositivo/função do cliente. Exemplos:

impressoras, máquinas digitais, modem ADSL, etc;
-Conector Tipo "B" Macho, encontrado em um dos extremos do cabo USB, onde
deve ser conectado a um dispositivo/função.
Veja abaixo na ilustração da Figura 4, os tipos de conectores da série "A" e "B".

Figura 4 - Cabos e conectores
Mecanicamente os conectores USB foram projetados de forma a não permitir

encaixes errados por parte do usuário. Só há uma possibilidade de conectá-los: a
correta! Tipo "A" macho com Tipo "A" fêmea e, Tipo "B" macho com Tipo "B" fêmea.
Qualquer outra combinação é impossível de unir-los
Figura 5 - Conector Tipo "A" (Fêmea

Figura 6 - Conector Tipo "B" (Fêmea Disp.)
Host)
Na Figura 5 acima temos o conector receptáculo Tipo "A", encontrado no Host e

nas portas Downstream de Hub. Observem que a identificação dos pinos começa a
partir da esquerda para a direita.
Já na Figura 6 é exibida uma figura do conector receptáculo Tipo "B",

encontrado em dispositivos/funções do cliente. A numeração dos pinos começa da
direita para a esquerda na parte superior, e continua na parte inferior da esquerda
para a direita. Verão mais adiante, que os conectores do cabo tem a numeração
invertida.

Figura 7 - Pinagem do conector Tipo "A"

Figura 8 - Pinagem do conector Tipo "B" (Fêmea Disp.)
(Fêmea Host)
Observem bem as figuras acima, elas mostram as partes inferiores dos

conectores e a identificação dos pinos. Essas identificações serão muito importantes
quando forem criar uma placa de circuito impresso, ou mesmo usá-los no proto-
board para criar protótipos de circuitos.
Figura 9 - Pinagem dos conectores Tipo "A" e "B" Machos do cabo USB
Veja agora, que nos conectores dos cabos, a identificação dos pinos são
diferentes. Observem também que os dois extremos do cabo dispõem de Tipos "B"
macho.

Estrutura elétrica e sinais do cabo USB
O cabo USB é composto por 4 fios e uma malha para eliminação de ruídos
simples. Desses, 2 são fios que transportam energia para alimentar dispositivos.
Essa energia é fornecida pela controladora e gerenciada pelo Driver do Controlador
Host.
O Cabo USB usa cores padrão para os fios, sendo assim, o fio de cor vermelha
é chamado Vbus (5v), ou seja, é o fio positivo de fornecimento de energia. O fio de
cor Preta é o GND (0v). Este é o pino negativo de energia do Bus.
O bus USB pode fornecer no máximo 5 Volt de tensão e 500mA de corrente

elétrica, isso para cada porta do Root Hub do host. A quantidade de corrente que
seu dispositivo irá precisar para funcionar pode ser configurada via software. Nos
circuitos que iremos criar usando o chipset da FTDI, a configuração de consumo de
corrente será armazenada numa memória Flash tipo 95C56.
Os outros dois fios D+(dado+) e D-(dado-) são usados pelo sistema USB para
transferência de dados entre o Host, hub e dispositivos. Todos os sinais de dados
trafegam apenas por esses dois fios usando a codificação NRZI (No Return to Zero
Inverted). Ou seja, o bit 1 é codificado através de uma transição ocorrendo da maior
voltagem para a menor, ou também o inverso, da menor para a maior. Já o bit 0 é
codificado sem haver transição. Durante o intervalo de um bit a voltagem é
constante.
Figura 10 - Exemplo de codificação de bits em NRZI
Só por curiosidade sobre a codificação NRZI, o gráfico acima mostra como um

sinal digital comum é codificado em NRZI. Na NRZI a transição só ocorre quando o
bit tem o valor 1. Quando o bit tem o valor 0 não ocorre transição para sua
codificação.

Figura 11 - Interior do cabo
Figura 12 - Foto de um cabo USB, nomes e numeração dos fios
As duas figuras acima mostram as cores dos fios, associadas aos números dos
pinos dos conectores, tanto do Tipo "A" como do Tipo "B".

Figura 13 - Organização interna dos fios
Figura 14 - Par de fios D+ e D- entrelaçados
Observem nas duas figuras acima, que o par de fios D+ e D- estão

entrelaçados, o objetivo é minimizar interferências.
Configuração de alta e baixa velocidade de comunicação
Figura 15 - Configuração de alta velocidade entre o dispositivo e o Host
Na figura acima temos uma configuração física entre o Host e o dispositivo.

Observem no dispositivo o resistor de Pull-up de 1k5 ohm ligado desde o sinal D+ a
uma tensão de 3,3V. Esta tensão pode ser conseguida através de um regulador de
tensão ligado ao Vbus e ao GND do bus USB. Este resistor pull-up é muito
importante, e serve para avisar ao controlador Host que um novo dispositivo foi
conectado ao bus USB e também informar que o dispositivo irá se comunicar com o
Host em alta velocidade. Para dispositivos que se comunicam em baixa velocidade,
como: mouses e teclados, o resistor de pull-up deve ser conectado ao sinal D-, em
vez do D+.
Para que o controlador host possa detectar a presença de um dispositivo, é

necessário que a tensão que circula entre o resistor de 1k5 até o D+ ou D- (alta ou
baixa velocidade), persista por mais que 2,5 microssegundos. Já a desconexão de
um dispositivo é detectada pela ausência da tensão que circula pelo resistor pull-up,
por mais que 2,5 microssegundos.
Esta configuração é a base para o funcionamento do sistema plug-and-play do

bus USB.

Tipos de interfaces
Há dois tipos de interfaceamento em que um dispositivo USB pode trabalhar:

Bus-powered e Self-powered. No Bus-powered o dispositivo é alimentado pelo
próprio Bus USB através dos pinos Vbus e Gnd podendo fornecer no máximo
500mA direto de uma Porta do Root Hub (host) ou de uma Porta de um Hub comum
que tenha sua própria fonte de alimentação. Se o Hub não tiver uma fonte de
alimentação, os dispositivos conectados a ele só poderão consumir cada um, no
máximo 100mA do Bus USB. Já o tipo self-powered não consome energia do Bus
USB, mas deve ser alimentado com uma fonte externa para que o circuito possa
funcionar.
Para que um dispositivo USB trabalhe no modo Bus-powered ou Self-powered,

é necessário que o desenvolvedor configure o circuito eletricamente para que possa
trabalhar da maneira desejada.
Dispositivos configurados para trabalhar no modo Bus-powered devem consumir

no máximo 100mA, podendo retirar essa corrente diretamente da porta do Root hub,
ou de qualquer tipo de Hub. Dispositivos Bus-powered que consomem 500mA
devem ser conectados somente no Root Hub ou na porta de um Hub que disponha
de sua própria fonte de alimentação.
Dispositivos Bus-powered são resetados/desligados involuntariamente quando o

computador é ligado ou desligado. Já dispositivos eletricamente configurados como
Self-powered mantém o circuito ligado mesmo que o computador seja
resetado/desligado, isso porque são alimentados através de uma fonte externa.
Esses tipos de interfaceamento devem ser levados em consideração quando criarem
circuitos críticos, como alarmes, controles de abrir e fechar portas, portões e
quaisquer outros dispositivos que, em hipóteses nenhuma, devem ser acionados
involuntariamente. Para esses tipos de dispositivos a Self-powered é a ideal.
Veja nas figuras abaixo exemplos de interfaceamento de dispositivos USB:
Figura 1 - Dispositivo Bus-powered

Veja na Figura 1 que o dispositivo é conectado direto em uma das portas do

Root hub (PC-host). Como aprendemos em aulas anteriores, uma porta do Root Hub
pode fornecer no máximo 500mA. Portanto, esse tipo de interfaceamento de
dispositivo pode consumir até 500mA.
Nesse tipo de interfaceamento temos a vantagem de não necessitarmos de

fonte externa, mas temos a desvantagem do dispositivo ser desligado quando o PC
for desligado.
Figura 2 - Dispositivo Self-powered
Na configuração mostrada no esquema acima, temos um dispositivo alimentado

como uma fonte externa, não necessitando da energia do Bus USB. Nesta
configuração o dispositivo poderá consumir quanto de corrente a fonte drenar.
Este tipo de configuração é a ideal para dispositivos que não podem ser
desligados após o corte da energia do PC.
Figura 3 - Dispositivo conectado a um Hub Bus-powered

Veja que na figura acima o dispositivo está ligado a um Hub Bus-powered, nesta
configuração cada porta do hub fornece no máximo 100mA. Assim, o dispositivo só
poderá extrair 100mA da porta.
Dos 500mA fornecidos por uma porta do Root hub, 100mA são para alimentar
seu próprio circuito.
Figura 4 - Dispositivo conectado a um Hub Self-powered
Na figura acima temos um dispositivo hub do tipo Self-powered (alimentado

através de uma fonte externa). Nesse tipo de configuração o hub poderá ter mais
que 5 portas, e fornecer em cada uma a corrente máxima. Portanto, cada dispositivo
conectado ao hub poderá extrair indiretamente corrente do Bus USB.
Interfaces Bus e Self Powered
As figuras 5 e 6 abaixo mostram os esquemas elétricos genéricos para se criar

dispositivos alimentados pelo próprio cabo USB (Bus-powered) ou por uma fonte
externa (Self-powered). Esses esquemas serão usados em todos os nossos projetos
aqui nesse curso. Em aulas posteriores irei explicar a função de cada pino do shipset
FT232BM.
É a partir de uma dessas configurações elétricas que iremos acrescentar um

microcontrolador para criarmos produtos USB específicos e com vários recursos.

Figura 5 - Interface para dispositivos Bus-powered
No esquema acima, o objetivo da ferrite é de eliminar interferências

eletromagnéticas geradas pelo computador. Os capacitores são usados como
desacopladores.

Através do resistor R4 de 1,5K é que o Host USB detecta se um dispositivo foi

conectado ou desconectado do sistema.
O LED TX acende quando enviamos dados do dispositivo para o computador.

Já o LED RX acende quando o dispositivo recebe dados do computador.
A memória 93C46 é opcional e seu objetivo é personalizar o novo produto

criado. Pode ser usados o mesmo modelo com terminações: 56 ou 66.
Observe também que a energia para alimentar o circuito é fornecida através do

pino 1 (Vbus) do conector USB. Todos os terminais VCC-USB no circuito devem ser
ligados entre si
Tabela 1 - Lista de componentes (Bus-powered)

Resistores Capacitores Diversos
R1: 27 Ohm C1: 10nF 1 Cristal 6 Mhz
R2: 27 Ohm C2: 10uF eletrolítico 1 Memória Flash 93C46 ou 56 ou 66
R3: 470 Ohm C3: 100nF 1 Chipset FT232BM
R4: 1,5K C4: 100nF 1 Conector tipo "B" fêmea PCI
R5: 220 Ohm C5: 100nF 1 Ferrite (*)
R6: 220 Ohm C6: 100nF 1 Cabo USB (padrão impressora)
R7: 2,2K C7: 33nF
R8: 10K C8: 27pF
C9: 27pF
Figura 6 - Ferrite Figura 7- Ferrite com uma volta de fio
O objetivo da ferrite no terminal VBus é de eliminar quaisquer interferências

eletromagnéticas geradas pelos componentes do computador como: fonte de
alimentação, processador, cristais etc. A ferrite pode ser semelhante as das figuras
acima, com uma volta de fio duro, tipo cabo de Rede, telefone ou outro.
A ferrite pode ter as seguintes características: NBT 4,5/2,6/6,7.

Figura 8 - Interface Self-powered
A diferença no esquema acima em relação ao do Bus-powered, é no acréscimo

dos resistores R5 de 4,7K e R8 10K; na eliminação da ferrite e do capacitor de 10nF;
e a ligação do pino 14 (PWRCTL) do FT232BM, que agora é conectado ao +5V da
fonte de alimentação externa.

Tabela 2 - Lista de componentes (Self-powered)

Resistores Capacitores Diversos
R1: 27 Ohm C1: 10uF eletrolítico 1 Cristal 6 Mhz
R2: 27 Ohm C2: 100nF 1 Memória Flash 93C46 ou 56 ou 66
R3: 470 Ohm C3: 100nF 1 Chipset FT232BM
R4: 1,5K C4: 100nF 1 Conector tipo "B" fêmea PCI
R5: 4,7K C5: 100nF 1 Cabo USB (padrão impressora)
R6: 220 Ohm C6: 33nF
R7: 220 Ohm C7: 27pF
R8: 10K C8: 27pF
R9: 2,2K
R10: 10K

Protocolo USB
O protocolo é uma das partes mais importantes do funcionamento do sistema

USB, é através dele que um ou mais dispositivos conversam e trocam informações
com o Host. No Host a pilha do protocolo está disponível em forma de drivers de
arquivos .sys, dll, drv, exe, etc. Já no dispositivo o protocolo pode ser encontrado
dentro de um microcontrolador específico, como por exemplo um PIC que disponha
de uma certa quantidade de memória. Nesse caso, o protocolo é escrito com base
na norma USB, em uma linguagem específica com: C ou Assembly; depois é
compilado e gravado na memória do microcontrolador através de um gravador de
PIC. Esta é umas das maneiras mais complexas, trabalhosa e não muito produtiva.
Há microcontroladores PIC como o 18F2450 e 18F4450 que internamente já dispõe
do protocolo, tornando assim mais fácil o desenvolvimento de aplicações. Uma outra
maneira é através de um chipset que carrega dentro de si toda a funcionalidade do
protocolo USB, livrando o microcontrolador de todo o trabalho pesado.
Diferente da Porta Serial ou Paralela onde simplesmente através dos sinais

elétricos dos pinos e um programa básico é possível se comunicar com um
dispositivo. No USB isso só é possível se o dispositivo carregar o protocolo USB
num chipset ou mesmo dentro de um microcontrolador. Assim, concluímos que o
combustível do sistema USB é seu protocolo, sem ele, não há troca de informação
entre os dispositivos.
Nessa aula irei trazer a nosso conhecimento alguns pontos importantes do

protocolo USB para nos ajudar a compreender algumas características de
funcionamento dos dispositivos que iremos criar. Também iremos usar alguns
softwares disponíveis no mercado (free) para visualizar o protocolo.
O protocolo USB tem vários recursos como: CRC (Cyclic Redundancy Check),
detecção e correção de erros, detecção de conexão e remoção de dispositivos,
controle de fluxo de dados assegurando transmissões isossíncronas (trafego
contínuo de dados), disponibilidade assegurada de largura de banda, entre outros.
4 tipos de transferências de dados USB
Controle: As transferências de controle são utilizadas pelo Host para configurar

um dispositivo e requisitar informações sobre o seu estado. Essas transferências são
usadas principalmente pelo sistema USB para configurar dispositivos durante a
primeira conexão.
Interrupção: Esse tipo de transferência é utilizado por dispositivos que usam

pouca banda do sistema USB, mais comumente usada por dispositivos como:
mouses, teclados, joysticks ou outros que precisam enviar e receber dados de
maneira não freqüente, mas com certos limites de latência. Nesse caso é o
dispositivo quem requisita dados do host.

Isossíncrona: Chamada também de transferência de correntes em tempo real

(Stream real-time transfers). Tipo de transferência composta somente de dados,
ideal para dispositivos que não necessitam checar se os dados chegaram
corretamente ao destino. Não tem detecção de erro e nem utiliza CRC. Esse tipo de
transferência é mais utilizada por dispositivos de vídeos, áudios e outros que
precisam de uma velocidade constante de transmissão, não importando a perda de
dados por erro ocasionais. As transferências isossíncronas têm prioridades em
termos de largura de banda.
Bulk: Transferências de grandes volumes de dados como: aquisição de dados de

dispositivos tipo scanners, impressoras, discos de memórias flash, Modems ADSL.
Nesse tipo de transferência há detecção e correção de erros, confirmação e
recuperação de pacotes de dados corrompidos.
A largura de banda para esse tipo de transferência pode variar se houver outras
atividades concorrentes sendo executadas no barramento USB. Esse tipo de
transmissão garante a segurança no tráfego de dados, mas não garante velocidade
constante em que os mesmos são transmitidos.
Toda as transmissões de dados no sistema USB são baseadas no envio de

pacotes. O Host é quem inicia todas as transações, o primeiro pacote gerado é o
Token para descrever o que seguirá no próximo pacote e, se a transação de dados é
uma escrita ou leitura. O próximo pacote geralmente é um pacote Data que leva a
carga útil de dados, é seguido por um pacote de Handshake, que informa se houve
sucesso na negociação da transação.
Cada transação USB consiste dos seguintes pacotes mostrados na figura abaixo:
Figura 1 - Pacotes de dados de transferência

Descrição dos campos dos pacotes
• SYNC - Todos os pacotes têem que começar com um campo de. Este campo
tem um tamanho de 8 bits para velocidades baixas e, 32 bits para altas
velocidades. É utilizado para sincronizar o relógio (clock) do transmissor com
o do receptor.
• PID - Representa Pacote ID (identificação). Este campo tem um tamanho de 8
bits, é usado para identificar o tipo de pacote que será enviado.
Figura 2 - Descrição dos bits do campo PID
Os bits (PID0 a PID1) indicam o tipo de pacote que pode ser: Token, Data,
Handshake e Special. Os bits (PID2 e PID3) acrescentam mais informações
sobre o tipo de pacote. Os bits (PID#0 a PID#3) são usados para checagem dos
dados (cálculo para verificação e prevenção de erros).

Tabela 1 - Tipos de PID

Tipo de Nome do
Descrição
PID PID
Endereço + número do Endpoint.
OUT Transação do Host para o
Dispositivo.
IN Transação do Dispositivo para o
Token Host.
SOF início e o número do Frame.
Transação de configuração para
SETUP controle do Pipe. Direção do Host
para o Dispositivo.
DATA0 Pacote de dados impar.
DATA1 Pacote da dados par.
Pacote da dados para tansação em
Data DATA2 alta-velocidade (high-speed)
Isossíncrona.
Pacote da dados para tansação em
MDATA alta-velocidade (high-speed)
Isossíncrona.
Reconhecimento. O pacote foi
ACK recebido corretamente.
Informa que o dispositivo
NAK temporariamente não pode enviar ou
Handshake receber dados.
O dispositivo encontra-se em um
STALL estado que requer intervenção do
Host.
NYET O receptor não responde.
PRE Preâmbulo para indicar low speed.
Utilizado somente em modo High
ERR speed. Erro em transação split.
Special
SPLIT Para transação split em High speed.
PING Verificação de Busy após um NYET.
• ADDR - Este campo define o endereço de destino do dispositivo ao qual o

pacote de dados será enviado. Tem um tamanho de 7 bits, podendo
endereçar no máximo até 127 dispositivos distintos, conectados no bus USB.
• ENDP - Este campo é conhecido como Endpoint e tem o tamanho de 4 bits,

permitindo 16 possíveis Endpoints diferentes. O Endpoint de número 0 (zero)
é usado pelo Host para se comunicar com todos os dispositivos conectados
ao bus USB, para configurá-los ou obter informações.

• DATA - São os dados propriamente dito para transferência. Este campo pode
armazenar até 1024 bytes.
• CRC - (Cyclic Redundancy Check). O objetivo deste campo é armazenar o

resultado de um cálculo em nível de bits executado em alguns campos do
pacote, para garantir a segurança dos dados transmitidos. Ou seja, se os
dados se alterarem durante a transmissão, o receptor poderá comparar o
valor deste campo, calculando o CRC do pacote recebido e correção do erro
se houver. O campo PID não é agregado a esse cálculo porque tem seu
próprio recurso de correção de erros. Para os pacotes Token esse campo tem
o tamanho de 5 bits (CRC5), e para pacotes de Dados, tem tamanho de 16
bits (CRC16).
• EOP - Este campo indica o fim de qualquer pacote. Ele é representado com
um simples zero (0) por aproximadamente 2 a 3 bits de tempo.
Pacote Token - Indica o início de uma transação USB.
Há 4 tipos de comandos Token:
Out - Informa ao dispositivo que o Host deseja enviar informações;

In - Informa ao dispositivo que o Host deseja ler informações;
Setup - Usado para iniciar transferências de controle;
SOF - Indica o início e o número do Frame.
Figura 2 - Representação gráfica de um pacote SOF
Os Pacotes SOF (Início de Frame) consiste em um número de 11 bits e

são enviados pelo Host entre 1ms a +/- 500ns num Bus Full speed, ou
entre 125us a +/- 0,0625us num Bus High speed. Esse pacote consiste
de um PID que indica um pacote do tipo SOF, e o campo Frame
Number que referencia o número do Frame (quadro).
Pacote de Dados - Contém a carga útil de dados a ser transportado.

Existem 4 tipos de pacotes de dados capaz de transmitir até 1024 bytes. Esses
pacotes são conhecidos como:
• DATA0
• DATA1
• DATA2
• MDATA
DATA 0 e DATA 1 são utilizados nos modos low speed e full speed;
DATA 2 e MDATA são utilizados somente no modo de alta velocidade (High Speed).

Pacote Handshake - Usado para reconhecer transações e prover meios de

correção de erros.
Como mostrado na Figura 1, o handshake é composto somente por um campo de

informação válida (PID).
Os comandos PID de handshake são: ACK, NACK, STALL ou NYET.

Protocolo USB
Endpoints e Pipes (interface lógica)
Endpoint (ponto final de um dispositivo) - Área de memória (Buffer) reservada no

Dispositivo para armazenar os dados que trafegam em um tubo (pipe).
Um dispositivo USB pode ter no máximo 16 Endpoins na versão 2.0 do USB. O

Endpoint 0 (zero) é reservado para o Host obter informações sobre cada dispositivo
conectado ao Bus USB. Através deste Endpoint, o Host pode enviar comandos de
controle em baixa velocidade para obter informações descritivas sobre o dispositivo,
como: número de série, fabricante, classe, subclasse, versão do Bus USB, nome do
produto, tipo do protocolo, números de Endpoints, interfaces, velocidade, tipo de
transferência, entre outras. Após a aquisição de todas estas informações sobre o
dispositivo, o Host estabelece realmente uma comunicação USB.
Figura 1 - Tipos de Endpoints
Pipe (tubo) - É uma associação entre um Endpoint no dispositivo e um software no

Host. Pipe não é algo físico, é uma via de comunicação virtual que só existe em nível
de software. Quando um dispositivo USB se conecta ao sistema, o Host cria uma
configuração para se comunicação com o dispositivo. Um Pipe pode ser descrito
também como uma via de comunicação unidirecional ou bidirecional, onde podem
existir Endpoints de entrada(In) e saída (Out). Os Pipes passam a existir quando um
dispositivo é configurado pelo Host. Enquanto um dispositivo estiver sendo
alimentado e conectado ao controlador Host, sempre existirá um Pipe de controle
padrão (Control Default) para que esse dispositivo possa fornecer acesso as
configurações, como, informações de controle e estado do mesmo.
Figura 2 - Ilustração de um Pipe entre o Host e o dispositivo

Figura 3 - Interface lógica entre o Host e os diversos dispositivos USB

através dos Pipes e Endpoints
Há dois tipos de Pipes:
• Stream (corrente de dados) - É uma via de comunicação unidirecional entre

um softwares no Host e um Endpoint que pode ser dos tipos: Interrupção,
Isossíncrono ou Bulk. Se um dispositivo precisar transferir de forma
bidirecional um dos tipos de Endpoint citados acima, o sistema deve
estabelecer dois Pipes: um definido com Endipoint de saída(Out), e outro com
Endpoint de entrada(In).
Figura 4 - Pipe Stream Out
Figura 5 -Pipe Stream In

• Mensagem ou controle - É uma via de comunicação bidirecional entre um

softwares no Host e dois Endpoints de Controle (control) em um dispositivo
USB. Ou seja, é um tubo com dois Endipoints: um de entrada (In) e outro de
saída (Out) que tem uma estrutura de dados bem definida. É através de um
Pipe deste que o Host usa o Endpoint 0, para obter os descritivos dos
dispositivos para configurá-los no sistema USB.
Figura 6 - Pepe de Mensagem ou Controle
Descritores
Todos os dispositivos USB têm uma hierarquia de descritores que informam ao

Host o que o dispositivo é, ou seja, sua "personalidade", suas características de
funcionamento, como; número de série do produto, identificação do fabricante, tipo
do dispositivo (impressora, scanner, modem, mouse, etc.), número de configurações,
número de Endpoint, tipo de transferência, tipo de interface, etc.
Animação - Envio dos descritores pelo dispositivo

Figura 7 - Janela do Gerenciador de Dispositivos do Windows
No windows, para executar o Gerenciador de Dispositivos, acesse o Painel de

Controle; dê duplo clique no Ícone Sistema; Clique na guia Hardware e depois no
botão Gerenciador de Dispositivos.
O programa Usbready.exe (de uso livre) criado pela Intel para testar se um
computador oferece suporte USB; pode-se fazer seu download clicando aqui.
Figura 8 - Janela do programa USBready para checar a existência do sistema USB no PC

• Descritores de Dispositivos - Informam ao Host de uma forma geral,

características sobre o dispositivo. Um dispositivo USB só pode ter um
Descritor de Dispositivo. Estas informações são muito importantes para o
Host saber qual a versão do USB, o dispositivo suporta. Um dos descritores
são: identificação do fabricante, número de série, ID do Vendedor e produto,
classe e subclasse do dispositivo.
Para visualizar os descritores de um dispositivo USB, faça download do

programa USB Monitor da HHD Softwares em:
http://www.hhdsoftware.com/download.html.
A Microsoft também disponibiliza um utilitário free (de uso livre), chamado

Usbview.exe para visualizar os descritores. Clique aqui para fazer download.
Figura 9 - Tela inicial do programa USB Monitor
Um dos inconvenientes do programa USB Monitor, é que ele não faz a

atualização dos dados automaticamente. Se for conectar um novo dispositivo, é
preciso fechar o programa e executá-lo novamente, para que os novos dados sejam
exibidos na janela.

Figura 10 - Tela inicial do programa USBview da Microsoft
Para que o programa USBview exiba todos os descritores dos dispositivos

conectados ao Bus USB, clique no Menu Options, e marque todos os itens,
conforme mostra a figura abaixo:
Figura 11 - Menu Options do USBview

Figura 12 - Exibição do Descritor de Dispositivo através do software USB Monitor
No Descritor de Dispositivo mostrado na figura acima, observe os campos

principais:
USB Version: 2.0 (dispositivo compatível com a versão 2.0 do USB)

Vendor: 0x0500 (código do vendedor do produto ou dispositivo)
Product ID: 0x2000 (identificação do produto ou dispositivo)
Product Version : 0x0400 (versão do produto ou dispositivo)
Manufacturer: 0x0409 "ROGERCOM" (fabricante do produto ou dispositivo)
Product: 0x0409 "Sensor de Temperatura" (nome do produto ou dispositivo)
SerialNumber: 0x0409 "RCNPMGL5" (número de série do produto ou dispositivo)
Os dados acima são gravados na memória opcional Flash 93C46 para

personalizar o produto (dispositivo).
O campo SerialNumber é gerado automaticamente por um algoritmo, através do

programa gravador de memória Flash.
São através dos campos acima que o driver USB do Sistema Operacional
carrega os drivers USB do dispositivo corretamente, após a leitura de um arquivo

.INF. Em aulas futuras iremos entender todo o processo de configuração do arquivo

.INF.
• Descritores de Configuração - Contém informações sobre as capacidades e

funcionalidades do dispositivo, como tipo de alimentação de energia (Bus-
powered ou Self-powered), máxima corrente consumida pelo dispositivo, entre
outras.
Veja na figura abaixo, algumas informações sobre o Descritor de

configuração de um dispositivo:
Figura 13 - Exibição do Descritor de Configuração através do software USB Monitor
Veja no campo Attributes da figura acima, o tipo de alimentação do

dispositivo: Bus Powered, e no campo Max Power, a corrente máxima
extraída do Bus USB pelo dispositivo: 400mA.
• Descritores de Interface - Contém informações sobre o número de Endpoint

que suporta, o protocolo utilizado e, algumas strings de texto especificando o
nome do produto. Veja mais detalhes na figura abaixo:

Figura 14 - Exibição do Descritor de Interface através do software USB Monitor
• Descritores de Endpoint - O sistema sempre assume que o Endpoint 0

(zero) é um endpoint de controle e, é configurado antes de qualquer descritor.
Fora o Endpoint 0, cada endpoint deve ser configurado e consiste no número
do Endpoint, direção da comunicação (In, Out) e tamanho do pacote de dados
a transmitir.
A figura abaixo mostra um descritivo de 2 Endpoint: um de entrada (Input) e

outro de saída (Output), do tipo Bulk (alto volume de dados).
Figura 15 - Exibição do Descritor de Endpoint através do software USB Monitor
Veja na figura acima os endereços de Endpoint In/Out, o tipo de transferência e

o tamanho máximo do pacote de dados. Esses descritores são de um dispositivo
que trabalha no modo Full-speed.

• Descritores de Classe - Determinam a classe do dispositivo. No sistema

USB cada dispositivo é identificado como sendo de uma classe. Veja abaixo
na Tabela 1:
Tabela 1 - Classe de dispositivos USB

Símbolo Classe Descrição
1 Áudio
Dispositivos de
2
comunicação.
Dispositivos de Interfaces
humanas: Mouse,
3
Teclados, Joysticks, leitor
código de barras, etc.
Imagem: Scanner,
6
câmera.
7 Impressoras.
Amazenamento de
massa: Floppy disk
8 driver, CD-ROM, DVD,
ATAPI, SCSI, memória
flash.
9 Hub.
10 Interface de Dados.
11 Chip/Smart card.
Vendor-Specific:
dispositivos que não
entram em qualquer outra
255
classe.
Interface Serial RS232,
Rede ponto-a-ponto, etc.
Processo de enumeração
No sistema USB o processo de enumeração se refere à conexão, detecção,

leitura dos descritivos dos dispositivos e desconexão. É uma atividade ininterrupta.
Isso tudo é gerenciado em tempo real pelo controlador Host e o software do sistema.
Do ponto de vista do usuário do computador, o processo de enumeração é
transparente, desde que se tenha antes instalado no sistema operacional, os drives
do fabricante do dispositivo. Após isso, o carregamento dos drives quando um
dispositivo é conectado, é automático.

Segue abaixo uma seqüência de passos que ocorrem no processo de

enumeração:
Figura 16 - Conexão do dispositivo
Figura 17 - Conexão do dispositivo ao Host
1. O dispositivo é conectado ao Host;

2. O controlador Host detecta o dispositivo através de seu sinal elétrico;
3. O Host provoca uma interrupção de Reset para que o dispositivo reinicie,
limpando as variáveis e registros para que se possa iniciar a enumeração;
4. O Host define um canal (Pipe) de comunicação com o dispositivo;
5. O Host habilita e configura o Endpoit 0 (In/Out) para aceitar transações do tipo
Setup;
6. O Host atribui um único endereço ao Dispositivo;
7. O Host requisita os Descritores do Dispositivo, interpreta-os, e carrega o
device driver (software) apropriado que irá interagir com a aplicação do
cliente.
Pronto, após todos os passos descritos acima terem sido efetuados, é

estabelecida a fase de gerenciamento do dispositivo e das comunicações de dados.
Após isso, o dispositivo estará apto a exercer sua função para ao qual foi criado.

Conhecendo o chipset FT232BM
O chipset FT232BM é uma solução ideal para construir dispositivos que se

comuniquem com o computador através do Bus USB, com velocidade de até 3Mbps
através de sinais TTL: RS422 e RS485 e no máximo 1Mbs para comunicação
através de drivers RS232. Ele pertence a uma segunda geração do popular
componente USB UART da FTDI (FT8U232AM). É compatível com controladores
Host USB versões 1.1 e 2.0.
A FTDI - Future Technology Devices International Ltd., fabricante do FT232BM,

disponibiliza no seu site http://www.ftdichip.com/FTDrivers.htm, os drivres de
controle, livres de pagamento de royalties, para os sistemas operacionais Windows
98/Me/200/XP/CE.NET, Linux e Mac OS-X/9/8.
A FTDI também disponibiliza outros chipset, como o FT245BM que disponibiliza

os dados USB em paralelo, (em 1 byte) através de 8 pinos de entrada e saída (bits
D0 a D7), para propósitos gerais, e mais 4 pinos de controle (RD#, WR, TXE# e
RXF#). O FT245BM pode ser usado sem a necessidade de um microcontrolador
para controlar dispositivos diretamente através de interfaces simples, com: relês,
motores, conversores ADC, entre outros.
Principais características
Um único chip manipula tanto transferências USB como Serial.

Interface para Modem com total suporte aos sinais de Handshake.
A UART suporta 7 e 8 bits de dados; 1/2 stop bits e paridade
par/impar/marca/espaço e nenhuma.
Taxa de transferência entre 300 a 3M Baud (TTL).
Taxa de transferência entre 300 a 1M Baud (RS232).
Taxa de transferência entre 300 a 3M Baud (RS422/RS485).
Timeout ajustável para o buffer RX.
Compatível com bus USB 1.1 e 2.0.
Tensão de alimentação entre 4,35V a 5,25V.
Regulador integrado de 3.3v para Entrada/Saída USB.
Compatível com os controladores Host: UHCI/OHCI/EHCI.
Suporte a uma memória EEPROM externa opcional para personalizar o
produto, onde pode ser armazenado os descritores do mesmo como:
VID, PID, e número de série.

Encapsulado em tamanho miniatura 32-LD LQFP.

EEPROM pode ser programada na própria placa via USB.
Suporte para alimentar dispositivos diretamente no Bus USB através do
pino PWREN#.
Modos de transferências USB Bulk e Isossíncrono.
Suporte para os recursos USB (suspend/resume) através dos pinos
SLEEP# e RI#.
Figura 1 - Diagrama interno do FT232BM
Na figura acima temos uma visão geral em blocos do chipset FT323BM, onde
podemos ver a célula do regulador de tensão que fornece 3.3v no pino 3v3OUT do
chipset; a célula (USB transeiver) que trata diretamente os sinais D+ e D- através do
meio físico (cabo) , o USB DPL que trata da codificação NRZI; o multiplicador de
sinal de clock, que a partir de uma freqüência de 6Mhz gera 48Mhz; a Interface
Serial avançada (SIE); a UART que disponibiliza os dados seriais para comunicação
externa (RS232/RS422/RS485); célula EEPROM que gerencia uma memória
externa 93C56, 93C66 ou 93C46 opcional para personalizar o produto USB; célula
para controle dos Buffers FIFO; o USB Protocol Engine, que trata da pilha de dados
do protocolo USB em baixo nível, como Pipes, Endpoints, etc.

Figura 2 - Pinagem do FT232BM
Tabela 1 - Descrição dos pinos do FT232BM

Pino Nome Tipo Descrição
1 EESK Saída Sinal de Clock para a EEPROM.
2 EEDATA Entrada/Saída Conexão de dados direta com a EEPROM.
3 VCC Alimentação Tensão de alimentação (+4,4V a +5,25V).
Através deste pino podemos realizar um
4 RESET# Entrada reset a partir do exterior. Se não for usado,
deve ser conectado ao VCC.
Saída do gerador interno de Reset. Este
5 RSTOUT# Saída pino não é afetado no caso de um reset no
Bus USB.
Saída do regulador LDO (Low Drop Out) de
3,3V. Este pino deve ser conectado a um
capacitor cerâmico de 33nF. Uma pequena
6 3V3OUT Saída
quantidade de corrente (<= 5mA) pode ser
tirada deste pino, para alimentar um circuito
a 3.3v se for preciso.
Sinal positivo de Dados (D+) USB. Requer
7 USBDP Entrada/Saída um resistor de pull-up de 1,5K conectado ao
pino 3V3OUT ou RSTOUT#.
8 USBDM Entrada/Saída Sinal negativo de Dados (D-) USB.
9 GND Alimentação Sinal negativo (massa).
Vai ao estado baixo enquanto está no modo
10 SLEEP# Saída
USB "Suspend".
LED indicador de recepção de dados. Este
11 RXLED# Saída pino quando está em nível baixo indica
recepção de dados.

LED indicador de transmissão de dados.

12 TXLED# Saída Este pino quando está em nível baixo indica
transmissão de dados.
Especifica os níveis de tensão utilizados na
13 VCCIO Alimentação
interface UART (3.0V - 5,25V).
Em nível baixo, o FT232BM é alimentado
através do bus USB (Bus-powered). Em
14 PWRCTL Entrada
nível alto é alimentado mediante conexão
externa (Self-powered).
Está em nível baixo quando se tem
configurado o FT232BM no modo Bus-
powered. Está em nível alto durante o
período de suspensão do bus USB. Pode-se
15 PRWEN# Saída
usar este pino para controlar a alimentação
de dispositivos externos, alimentados
diretamente através do bus USB, mediante a
utilização de um MOSFET Canal-P.
Habilita a transmissão de dados para
16 TXDEN Saída
RS485.
17 GND Alimentação Sinal negativo (massa).
18 RI# Entrada Indicador de Ring.
Data Carrier Detect (detecta a portadora de
19 DCD# Entrada
dados).
20 DSR# Entrada Data Set Ready (Dados pronto).
Data Terminal Ready (Terminal de dados
21 DTR# Saída
pronto).
22 CTS# Entrada Clear To Send.
23 RTS# Saída Request To Send.
24 RXD Entrada Pino de recepção.
25 TXD Saída Pino de transmissão.
26 VCC Alimentação Tensão de alimentação (+4,4V a +5,25V).
27 XTIN Entrada Entrada do oscilador de 6MHz.
28 XTOUT Saída Saída do oscilador de 6MHz.
Gnd analógico para o multiplicador x8 do
29 AGND Alimentação
Clock interno.
VCC analógico para o multiplicador x8 do
30 AVCC Alimentação
Clock interno.
Põe o FT232BM no modo teste. Para
31 TEST Entrada funcionamento normal, deve-se conectar ao
GND.
32 EECS Entrada/Saída EEPROM-Chip select (seleciona o chip).
Configuração da EEPROM 93C46 (56 ou 66)
A memória 93C46 é uma memória do tipo EEPROM serial (SPI), com 64

palavras de 16 bits de largura, podendo armazenar 1024 bits (128 bytes). O modelo
93C56 tem um tamanho de 2048 bits, e o 93C66, 4096 bits. O FT232BM requer uma
memória de 16 bits de largura e os modelos 93C46 /56 e 66 são ideais.
O uso da EEPROM 93C46 é opcional, seu objetivo é personalizar o novo

produto criado, armazenando nela o nome do fabricante, número de série, versão,

vendedor, etc. Se esta memória não for agregada ao circuito, serão assumidos os
dados padrão gravado no chipset pelo fabricante (FTDI), que são: Vendor ID (VID
0403) e Produtc ID (PID 6001), entre outros.
Figura 3 - Pinagem da memória 93C46 (56 ou 66)
Tabela 2 - Descrição dos pinos da memória 93C46 (56 ou 66)

Pino Descrição
CS Chip Select (Seleção do chip)
SK Serial Data Clock (Sinal de relógio)
Serial Data Input (Entrada de dado
DI
serial)
Serial Data Output (Saída de dado
D0
serial)
VCC Alimentação +5V
NC Não Conectado
GND 0v (massa)
Figura 4 - Conexão da memória 93C46 (56 ou 66) ao chipset FT232BM
A figura acima mostra a configuração da memória 93C46 (56 ou 66), e a

conexão com o FT232BM para personalizar o novo produto USB desenvolvido.

Configurando interfaces Bus-Powered e Self-powered
Nas Figuras 6 e 8 da aula 3, estão disponíveis as configurações completas das

interfaces Bus-powered e Self-powered. Aqui estamos mostrando claramente as
diferenças importantes entre as duas. Como já aprendemos anteriormente, as
diferenças visíveis ao usuário é que um dispositivo Bus-powered retira a energia do
próprio Host e, um dispositivo Self-powered precisa de uma fonte de energia externa
para alimentar seus componentes.
Além das configurações físicas mostradas nas Figuras 5 e 6 logo abaixo, na

hora de se programar os descritores do dispositivo na memória EEPROM, deve-se
informar em um dos seus campos, o tipo de interface em que o dispositivo irá
trabalhar.
Figura 5 - Configuração Bus-powered
Numa interface Bus-powered o pino 14-PWRCTL deve ser levado a nível baixo
(0v). A ferreite é ligada em série ao pino 1-Vbus (+5v do Bus USB) para eliminar
ruídos que possam afetar o bom funcionamento do dispositivo.

Figura 6 - Configuração Self-powered
Numa interface Self-powered o pino 14-PWRCTL deve ser levado a nível alto
(+5v). Deverão ser acrescentados dois resistores: um de 4K7 e outro de 10K para
gerar um sinal ao pino 4-RESET#.

Fazendo com que os pinos de I/O do UART do FT232BM trabalhe com 3.3v
Figura 7 - Interface Bus-powered com regulador 3.3v
O circuito Bus-powered configurado conforme exibido na figura acima usa um

regulador LDO (Low Drop Output), ou seja, é um tipo de regulador compacto e com
baixa queda e perda de tensão, ideal para nosso propósito. A partir de uma tensão
de entrada de 4.35 volts um regulador LDO 3.3V poder disponibilizar em sua saída
uma tensão estável de 3.3V. Esses 3.3V de saída é aplicado ao pino VCCIO para
fazer os pinos de I/O do UART do FT232BM trabalharem com apenas 3.3V. A saída
do LDO pode ser usada para alimentar o próprio microcontrolador e seus
componentes auxiliares, desde que não consumam mais que a corrente fornecida
pelo Bus USB e pela saída do regulador. Essa configuração é útil quando se está
trabalhando com microcontroladores que são alimentados com 3.3v.
Um regulador LDO recomendado pela FTDI é o TC55 fabricado pela Microchip,

mas outros podem ser usados.
Mais informações sobre o TC55, acesse o site da Microship(R) em

http://www.microchip.com.

Configurando o cristal ou resonador
Figura 8 - Oscilador com resonador cerâmico Figura 9 - Oscilador com cristal de quartzo
Temos duas opções de componentes para configurar um oscilador para o

FT232BM. A Figura 8 mostra uma configuração usando um resonador cerâmico de 3
pinos. Não são necessários capacitores auxiliares porque o resonador tem embutido
em si estes capacitores. A finalidade do resistor de 1M (mega) entre os pinos XTIN e
XTOUT é garantir uma maior precisão do oscilador.
Na Figura 9 temos uma configuração de oscilador usando um cristal de 6MHz e

dois capacitores de 27pF, entre os pinos XTIN, XTOUT e GND (massa).
Dentre estas configurações a mais econômica é a que usa o resonador. Já a

que usa o cristal torna a placa mais elegante. A melhor configuração fica por conta
do desenvolvedor.

Configurando os LEDs indicadores de comunicação (TX e RX)
Figura 10 - Configuração com 2 LEDs Figura 11 - Configuração com 1 LED
O FT232BM tem dois pinos indicadores de estado de dados transmitidos e

dados recebidos, onde podem ser conectados LEDs para indicar ao usuário. O pino
12 (TXLED) piscar intermitentemente quando dados são transmitidos pelo Bus USB
e, o pino 11 (RXLED) oscila quando dados são recebidos. Na Figura 11 temos uma
forma econômica de configurar o estado de transmissão e recepção de dados pelo
FT232BM, conectando os pinos RXLED# e TXLED# entre si, e usando um único
LED para indicar tanto transmissão como recepção. A desvantagem desta
configuração é que o usuário não poderá distinguir entre transmissão é uma
recepção de dados. Para contornar esse inconveniente, pode ser utilizado um LED
bi-color ou tri-color, com anodo comum, para representar os dois estados:
transmissão e recepção, como mostra a animação abaixo:

Animação 1 - Configuração com um único LED bi-color ou tri-color

Instalação e configuração de drivers relacionados aos chipsets FTDI
A FTDI disponibiliza dois tipos de drivers para se comunicar com nossas

aplicações, todos eles são distribuídos gratuitamente, através do site da empresa
em: http://www.ftdichip.com/FTDrivers.htm por qualquer usuário. Um dos drivers se
chama D2XX e usa uma DLL para se comunicar diretamente através do Bus USB
com dispositivos baseados nos chipsets da FTDI. Para se programar uma aplicação
usando a DLL é necessário saber usar suas funções (em aulas futuras iremos
programar em C++ e Delphi). O outro driver se chama VCP - Virtual COM Port (porta
virtual de comunicação serial). Emula uma porta padrão RS232 do PC. Uma vez
instalado no sistema operacional Windows, disponibiliza uma porta serial virtual
COMx para se comunicar de uma forma simples com o Bus USB.
Usando um driver VCP, qualquer aplicação que se comunique com a porta serial
RS232 pode se comunicar naturalmente com o Bus USB, sem nenhuma modificação
no programa. Para se criar um novo programa que acesse o Bus USB através do
driver virtual, as funções são as mesmas da API do windows usadas para programar
a porta serial. Se não quiser usar a API do windows a FTDI também disponibiliza
uma biblioteca de funções para facilitar a programação por parte do desenvolvedor.
Para instalar os drivers D2XX, confeccione o circuito Bus-powered da Figura 5 /

aula 3.
Observação ao instalar no windows XP:
A FTDI informa em seu site que alguns usuários dos drivers D2XX, usando o
VID(0x0403) e PID(0x6001) padrão, tiveram problemas ao instalar o mesmo no
Windows XP com Service Pack 1.
Para resolver esse problema, desconecte a Internet temporariamente antes de

instalar os drivers.
Passos para instalar os drivers D2XX da FTDI no Windows (como exemplo, o

2000)
1 Acesse o site da FTDI em: www.ftdichip.com, e faça download do driver

D2XX para a versão do Windows ou outros sistemas operacionais;
2 Na página principal da FTDI, clique no item Drivers do Menu; e depois no

subitem FT232 - FT245;

3 Após se abrir a nova página, clique no link D2XX. Apos isso é exibida a
seção . Clique no link D10620 correspondente ao seu
sistema operacional.
Na verdade, os arquivos de instalação para os sistemas operacionais Windows

98/Me/2000 e XP são idênticos. Portanto, pode-se fazer download a partir de
qualquer um dos links D10620 dessa página;
Download dos Drivers a partir da Rogercom.

Observação: para futuras atualizações, é bom sempre fazer download dos drivers a
partir da página da FTDI.
4 Após o download do arquivo D10620.ZIP, descompacte-o:
Figura 1 - Arquivos de drivers
Os arquivos FTD2XX.lib e FTD2XX.h são bibliotecas de funções para

programação. Os drivers são somente os arquivos marcados com retângulos
vermelhos.
5 Para começar a instalação do dispositivo USB FT232BM, conecte o cabo

USB ao Host/Root Hub (PC), ou em uma porta downstream de um Hub;
Figura 2 - Conexão do dispositivo baseado no FT232BM ao Host(PC)
Foto ilustrativa da placa Rogercom USB232RCOM-1 baseada no FT232BM

6 Alguns segundos após a conexão do cabo do dispositivo FT232BM ao Host,

são exibidas algumas janelas mostradas nas Figuras 3 e 4 logo abaixo:
Figura 3 - Janela exibida ao conectar o dispositivo pela primeira vez ao Host (PC)
A mensagem "USB <-> Serial" é o nome do dispositivo, e vem por padrão

gravada dentro do chipset FT232BM. Esta mensagem é enviada ao Host via
Descritores quando o novo dispositivo é conectado pela primeira vez ao Bus USB.
Para mudar esta mensagem, é preciso que o FT232BM seja configurado com uma
memória 93C46 (93C56 ou 93C66), e, através do programa MProg criado pela FTDI,
é possível personalizar o dispositivo. Se a memória 93Cxx do dispositivo estiver
vazia, é assumido o Descritor padrão do FT232BM.
Na próxima aula irei mostrar passo-a-passo como configurar os drivers e a

memória 93Cxx, para personalizar um dispositivo baseado nos chipsets
FT232BM/FT245BM.
Figura 4 - Assistente de instalação de um novo hardware do Windows - tela 1
Clique no botão Avançar para passar para o próximo passo...

7 Conforme a figura abaixo, marque a opção "(o)Procurar por um driver

adequado para o dispositivo (recomendado)";
8 Conforme a figura abaixo, marque a opção "[\/]Especificar um local" (pasta);

9 Conforme a figura abaixo, clique no botão Procurar... para localizar a pasta

onde se encontram os drivers;
Figura 7 - Janela para localizar a Pasta onde se encontram os Drivers D2XX
Clique no botão OK para passar para o próximo passo...
10 Após localizar e abrir a pasta dos drivers, selecione o arquivo ftd2xx.inf;

Figura 8 - Pasta onde se encontram os drivers
Clique no botão Abrir para passar para o próximo passo...
11 Após a localização correta dos arquivos, é exibida a janela abaixo:
Clique no botão Avançar para passar para a próxima etapa...

Figura 10 - Copiando os arquivos para as pastas do sistema windows
Figura 11 - Tela que indica sucesso na instalação dos drivers D2XX
Clique no botão Concluir para fechar o assistente de instalação.
Verificando se o dispositivo foi instalado corretamente no Windows
Ainda com o dispositivo conectado ao Host (PC), abra o Gerenciador de

dispositivos a partir do Painel de Controle do windows, fazendo assim:
Abra o Painel de Controle;

Localize o ícone Sistema;
Na janela Propriedades do Sistema, clique na Aba Hardware e depois no botão
Gerenciador de dispositivos;
Após ser exibida a janela abaixo, clique no item "Controladores Universal Serial
Bus" ;

Figura 12 - Janela do Gerenciador de dispositivos do Windows
Para ver as propriedades do novo dispositivo instalado, dê duplo clique no item

FTDI FT8U2XX. Será exibida a janela abaixo:
Figura 13 - Janela de Propriedades do novo dispositivo, FTDI FT8U2XX recentemente instalado
Clique no botão OK e depois feche todas as janelas.

Observação:
O Windows registra a instalação do dispositivo na janela Adicionar ou remover
programas do Painel de Controle. Para ver, abra o Painel de Controle e dê duplo
clique no Ícone Adicionar ou remover programas.
Figura 14 - Janela Adicionar ou remover programas do Windows
Na próxima aula irei explicar como instalar os drivers VCP, e também gravar a
memória 93Cxx para personalizar um dispositivo baseado no FT232BM para
comercialização.

Instalando os drivers da Porta Virtual COM (VCP)
Passos para instalar os drivers VCP da FTDI no Windows

(como exemplo, o 2000)
O objetivo dos drivers VCP é adicionar ao sistema operacional uma porta serial
COMx virtual, para possibilitar aos programas que se comuniquem com a porta
Serial, também se comunicarem com uma Porta USB. Sendo assim, um programa já
existente de comunicação Serial, poderá se comunicar com o Bus USB sem ser
necessário nenhuma alteração no seu código fonte. Novos programas podem ser
criados usando a API do Windows para programação da porta Serial, para se
comunicarem com o Bus USB, usando a mesma facilidade de programação da Porta
Serial. Os programas também podem ser criados usando a biblioteca de funções da
FTDI.
Segue abaixo os passos necessários para se instalar os drivers VCP:
Observação para se fazer uma nova instalação:
Se já encontra-se instalado um driver D2XX ou VCP no sistema, é preciso que o

mesmo seja removido. Faça isso a partir do Adicionar ou remover programas do
Painel de Controle do Windows.
1 Acesse o site da FTDI em: www.ftdichip.com, e faça download do driver

VCP para a versão do Windows ou outros sistemas operacionais;
2 Na página principal da FTDI, clique no item Drivers do Menu; e depois no

subitem FT232 - FT245;
3 Após se abrir a nova página, clique no link VCP. Apos isso é exibida a seção
. Clique no link R9052154 correspondente ao seu sistema
operacional.
Na verdade, os arquivos de instalação para os sistemas operacionais Windows

98/Me/2000 e XP são idênticos. Portanto, pode-se fazer download a partir de
qualquer um dos links R9052154 dessa página;
Download dos Drivers a partir da Rogercom.

Observação: para futuras atualizações, é bom sempre fazer download dos drivers a
partir da página da FTDI.

4 Após o download do arquivo R902154.ZIP, descompacte-o:
Figura 1 - Arquivos de drivers
Além dos arquivos de drivers de conversão Serial para USB (FTDIBUS), a FTDI
disponibiliza também um mini driver para controle de um mouse Serial.
5 Para começar a instalação do dispositivo USB FT232BM, conecte o cabo

USB ao Host/Root Hub (PC), ou em uma porta downstream de um Hub;
6 Alguns segundos após a conexão do cabo do dispositivo FT232BM ao Host,

são exibidas algumas janelas mostradas nas Figuras 2 e 3 logo abaixo:
Figura 2 - Janela exibida ao conectar o dispositivo pela primeira vez ao Host (PC)
Como já aprendemos na aula anterior, a mensagem "USB <-> Serial" é o nome

do dispositivo, e vem por padrão gravada dentro do chipset FT232BM.

7 Conforme a figura abaixo, marque a opção "(o)Procurar por um driver

adequado para o dispositivo (recomendado)";

8 Conforme a figura abaixo, marque a opção "[\/]Especificar um local" (pasta);

9 Conforme a figura abaixo, clique no botão Procurar... para localizar a pasta

onde se encontram os drivers;
Figura 6 - Janela para localizar a Pasta onde se encontram os Drivers VCP
Clique no botão OK para passar para o próximo passo...
10 Após localizar e abrir a pasta dos drivers, selecione o arquivo

FTDIBUS.INF;

Figura 7 - Pasta onde se encontram os drivers
Clique no botão Abrir para passar para o próximo passo...
11 Após a localização correta dos arquivos, é exibida a janela abaixo:

Clique no botão Avançar para passar para a próxima etapa...
Figura 9 - Copiando os arquivos para as pastas do sistema windows
Figura 10 - Tela que indica sucesso na instalação dos drivers VCP
Clique no botão Concluir para fechar o assistente de instalação.
Verificando se o dispositivo foi instalado corretamente no Windows
Ainda com o dispositivo conectado ao Host (PC), abra o Gerenciador de

dispositivos a partir do Painel de Controle do windows, fazendo assim:

Abra o Painel de Controle;

Localize o ícone Sistema;
Na janela Propriedades do Sistema, clique na Aba Hardware e depois no botão
Gerenciador de dispositivos;
Após ser exibida a janela abaixo, abra o item "Portas (COM e LPT)" ;
Figura 11 - Janela do Gerenciador de dispositivos do Windows
Para ver as propriedades do novo dispositivo instalado, dê duplo clique no item

USB Serial Port (COM4). Será exibida a janela abaixo, após clicar na Aba "Port
Settings":

Figura 12 - Janela de Propriedades do novo dispositivo, USB Serial Port (COMx)

recentemente instalado
Se desejar alterar o número da porta, ou simplesmente ver qual está associada ao

Bus USB, clique no botão "Advanced..." e veja no campo "COM Port Number".
Figura 13 - Configurações avançadas da Porta COM instalada
Clique no botão OK e depois feche todas as janelas para finalizar.

Observação:
O Windows registra a instalação do dispositivo na janela Adicionar ou remover
programas do Painel de Controle. Para ver, abra o Painel de Controle e dê duplo
clique no Ícone Adicionar ou remover programas.
Figura 14 - Janela Adicionar ou remover programas do Windows
Na próxima aula irei explicar como gravar a memória 93Cxx para personalizar
um dispositivo baseado no FT232BM para comercialização.

Usando o aplicativo MProg para gravar a EEPROM 93C46
Para personalizar o novo dispositivo criado, precisamos gravar na memória

93C46 alguns campos com informações sobre o tipo do dispositivo, como o nome, o
VID e o PID, a quantidade de corrente que será consumida, a versão do USB, Bus
powered ou Self powered, número de série, etc. Para gravarmos esses dados na
EEPROM, usaremos o programa Mprog de uso livre, criado pela FTDI. Além de
programarmos a EEPROM, precisaremos alterar algumas linhas dos arquivos INF e
INI de um dos drivers (D2XX ou VCP), escolhido para ser instalado no sistema
operacional.
Um arquivo INF está associado a um ou vários dispositivos, e contém

informações básicas para a instalação dos drivers apropriados. Se os números PID e
VID do dispositivo forem idênticos aos do conteúdo do arquivo INF, os drivers
especificados serão carregados na memória e a comunicação USB será
estabelecida. Caso contrário, o dispositivo ficará conectado ao Bus USB, mas sem
comunicação de dados.
Quando uma EEPROM externa não está configurada ao FT232BM, é assumido

o VID e o PID "default" ou padrão da FTDI, que são respectivamente os números:
0403 e 6001. Quando fazemos download dos drivers, estão gravados nos arquivos
INF e INI, o VID (0403) e o PID (6001). Portanto, se uma EEPROM externa for
configurada ao FT232BM e gravado um novo VID e um novo PID, são necessários
que eles também sejam gravados nos arquivos INF e INI para que o sistema consiga
instalar os drivers corretamente.
Se a memória EEPROM configurada ao FT232BM estiver vazia ou for apagada,

o FT232BM enviará ao sistema o VID e PID padrão FTDI (0403 e 6001).
O programa MProg só conseguirá gravar na memória EEPROM se os drivers

associados ao dispositivo tiverem sido previamente instalados no sistema. Se por
algum motivo não lembrarmos qual o VID ou PID gravados na EEPROM externa de
um dispositivo FT232BM, poderemos usar o programa de analises de protocolo USB
(Usbview.exe) para descobrirmos o VID e PID e, posterior inclusão destes nos
arquivos INF e INI.
Para fazer download do aplicativo MProg, clique em um dos ícones abaixo:
Download MProg 2.3 ou superior (FTDI).
Download MProg 2.3 (www.rogercom.com).
Para sua instalação são necessários os drivers D2XX.

Figura 1 - Tela parcial do MProg com dados padrão FTDI para o chipset FT232BM.
Descrição dos campos e botões do MProg
A - (Modo de edição). Quando um arquivo for aberto ou salvo e, após isso, for
necessário fazer uma alteração em um dos campos do MProg, é preciso clicar nesse
botão para habilitá-los;
B - (Salva as configurações). Salva num arquivo para futura recuperação, a

configuração atual;
C - (Procurar por dispositivos). Ao clicar nesse botão o MProg localiza todos os

dispositivos FTDI conectados ao Bus USB.
São exibidas informações sobre quantos dispositivos (EEPROM) foram
programados ou estão em branco;

D - (Apagar dispositivos). Apaga a memória EEPROM de todos os dispositivos

FTDI conectados ao Bus USB;
E - (Programar dispositivos). Grava a memória EEPROM de todos os dispositivos

FTDI conectados ao Bus USB.
1 - (Device Type). Selecione nesse campo o tipo de chipset FTDI: FT232BM,

FT245BM, etc;
2 - (USB VID/PID). Se você desejar gravar seu próprio VID e PID, selecione a
opção Own VID & PID. Se desejar manter o padrão FTDI (VID=0403 e PID=6001),
selecione a opção FTDI default;
3, 4 - (Campos VID e PID). Esses dois campos são muito importantes e

identificam o vendedor e o fabricante do dispositivo. É através desses campos que o
sistema operacional reconhece e carrega na memória, o driver apropriado. Por isso,
é preciso que sejam gravados os mesmos VID e PID no arquivo INF;
5 - (USB Power Options). Selecione como o seu dispositivo será alimentado. Bus-
powered (alimentado pelo Bus USB), ou Self powered (auto-alimentado, a energia
virá de uma fonte externa);
6 - (Max Bus Power). Se seu dispositivo foi configurado como sendo Bus powered,
digite neste campo a quantidade máxima de correntente que ele consumirá. O valor
máximo permitido é 500mA.
Já vimos em aulas anteriores que um Hub Bus powered só pode fornecer

100mA. Se estiver criando um dispositivo que consumirá mais que 100mA, é
importante que ele seja do tipo Self powered (com sua própria fonte de alimentação);
7 - (USB Serial Number Control). Todo dispositivo USB poder ter um número
Serial. Nessa opção poderemos definir nosso próprio número Serial ou pedir que o
MProg crie um automaticamente, iniciando a partir de um prefixo de dois caracteres;
8 - (USB Version Number). A versão do USB que seu dispositivo suporta.

Mantenha selecionado sempre USB 2.0, assim seu dispositivo será reconhecido
tanto na versão USB 1.1 como USB 2.0;
9 - (Disable USB Serial Number). Ao marcar essa opção o Número Serial não será
levado em conta. Ou seja, a opção 7 será desconsiderada;

10 - (Pull Down IO Pins in USB Suspend). Ao habilitar esta opção na EEPROM, o

pino PRWEN# do FT232BM poderá ser usado para controlar a alimentação de
dispositivos externos, alimentados diretamente através do bus USB, mediante a
utilização de um MOSFET Canal-P;
11 - (USB Remote Wake Up). Se esta opção for habilitada na EEPROM, será
possível a partir do pino RI# (em nível lógico baixo) do FT232BM, retomar o
Controlador Host USB do estado de dormência (Sleep);
12 - (Enable Plug And Play). Windows plug and Play. Usada somente para chips
da série FT232. Ao selecionar um chip do tipo FT245 esta opção é automaticamente
desabilitada;
13 - (Manufacturer). Nome do fabricante do dispositivo. Use poucos caracteres, ou

abrevie o nome da sua empresa;
14 - (Product Description). Descrição do produto (o que ele faz). Exemplo "Sensor

de Temperatura USB";
15 - (Only Program Blank Devices). Ao marcar esta opção, o MProg só gravará

dispositivos que estiverem em branco (vazio). Ou seja, a EEPROM que estiver com
conteúdo não será alterada. Para atualizar uma EEPROM, desmarque essa opção
antes de gravá-la;
16 - Área de exibição do estado de algumas ações executadas pelo usuário.
Analisando o conteúdo dos arquivos INF e INI para personalizar o Dispositivo
Como já foi escrito anteriormente no início desta aula, para personalizar um

dispositivo, além de gravar alguns campos de dados na memória EEPROM, são
necessários que os arquivos INF e INI associados aos drivers sejam também
modificados, com o mesmo VID e PID gravados nessa memória. Mas, antes de
fazermos as devidas alterações nesses arquivos, iremos analisar o conteúdo padrão
dentro deles.
Para facilitar a visibilidade, irei mostrar somente fragmentos do conteúdo de

cada arquivo, ou seja, somente as partes onde sofrerão alterações ou adições de
dados.

Arquivos dos Drivers D2XX
Figura 2 - Pasta com os arquivos dos Drivers D2XX
Na figura acima vemos os arquivos que contém informações sobre a instalação

(ftd2xx.inf), e a desinstalação (FTD2XXUN.INI) dos drivers D2XX. Somente estes
dois arquivos devem ser atualizados com o mesmo VID e PID que foram
programados na EEPROM do dispositivo. Os fragmentos dos arquivos abaixo
mostram as configurações padrão da FTDI.
Figura 3 - Fragmentos do arquivo FTD2XX.INF mostrando os segmentos que

sofrerão as devidas alterações
[FtdiHw]
%USB\VID_0403&PID_6001.DeviceDesc%=FTD2XX,
USB\VID_0403&PID_6001
[ControlFlags]
ExcludeFromSelect=USB\VID_0403&PID_6001
[FTD2XX.UnInst]
HKLM,%WINUN%,"FTD2XX"
HKLM,%WINUN%\FTD2XX , "UninstallString",,"%11%\FTDIUNIN.exe
%11%\FTD2XXUN.INI"
HKLM,%WINUN%\FTD2XX , "DisplayName",,"FTDI FTD2XX USB
Drivers"
[Strings]
Ftdi="FTDI"
USB\VID_0403&PID_6001.DeviceDesc="FTDI FT8U2XX Device"
FTD2XX.SvcDesc="FTD2XX.SYS FT8U2XX device driver"
WINUN="Software\Microsoft\Windows\CurrentVersion\Uninstall"
DriversDisk="FTDI FTD2XX Drivers Disk"
A string "DisplayName",,"FTDI FTD2XX USB Drivers" é exibida na janela

"Adicionar ou remover programas" do Painel de Controle do Windows.

Já a string DeviceDesc="FTDI FT8U2XX Device" é exibida na seção de

dispositivos USB instalados, no Gerenciador de Dispositivos do Windows, e na
janela de propriedades do mesmo.
Figura 4 - Fragmento do arquivo FTD2XXUN.INI de desinstalação

[Uninstall]
Device=VID_0403&PID_6001
Arquivos dos Drivers VCP
Na figura abaixo estão marcados com retângulos vermelhos, os arquivos que

contém informações sobre a instalação e a desinstalação dos drivers VCP. Somente
estes quatro arquivos devem ser atualizados com o mesmo VID e PID que foram
programados na EEPROM do dispositivo.
Figura 5 - Pasta com os arquivos dos Drivers VCP

Figura 6 - Fragmento do arquivo FTDIBUS.INF de instalação

[FtdiHw]
%USB\VID_0403&PID_6001.DeviceDesc%=FtdiBus,USB\VID_0403&PID_6001
[ControlFlags]
[Strings]
USB\VID_0403&PID_6001.DeviceDesc="USB Serial Converter"
Figura 7 - Fragmento do arquivo FTDIPORT.INF de instalação

[FtdiHw]
%VID_0403&PID_6001.DeviceDesc%=FtdiPort232,FTDIBUS\COMPORT&VID_0403&PID_6001
[Strings]
VID_0403&PID_6001.DeviceDesc="USB Serial Port"
Figura 8 - Fragmento do arquivo FTD2XXUN.INI de desinstalação

[Uninstall]
InfFiles=FTDIBUS,FTDIPORT,FTSERMOU
Key=FTDICOMM
Figura 9 - Fragmento do arquivo FTDIUN2K.INI de desinstalação

Converter=FTDIBUS
Serial=FTSER2K
Key=FTDICOMM
Dica: Quando criarmos o nosso primeiro dispositivo, o mesmo estará com a

EEPROM vazia, portanto, o FTDI232BM enviará para o sistema USB os descritores
de dispositivo, contendo o VID=0403 e PID=6001 (padrão da FTDI). Sendo assim,
na primeira instalação do dispositivo, os drivers têem que conter o mesmo VID=0403
e PID=6001.
Se for comercializar o novo dispositivo, grave seu VID e PID na EEPROM, e

também altere os arquivos INF e INI associados aos drivers que serão instalados
(D2XX ou VCP). São esses drivers que deverão ser enviados ao cliente junto com o
dispositivo (gravado com o novo VID/PID).
Como exemplo, na próxima aula iremos criar um novo PID e VID, gravá-los na
EEPROM do dispositivo e fazermos as devidas alterações nos arquivos INF e INI
dos drivers D2XX.

Programando a memória EEPROM 93C46 para personalizar o dispositivo
Nesta aula iremos usar o aplicativo MProg para gravar a memória EEPROM
93C46, e assim personalizar o novo dispositivo criado. Iremos também aprender a
remover do sistema, os drivers D2XX e VCP.
Para executar na prática, a maioria dos procedimentos contidos nesta aula, será
preciso que você confeccione o dispositivo Bus powered da Figura 5, Aula 3 (clique
aqui...).
Na Figura 1 logo abaixo, está visível a tela de edição do MProg onde constam
alguns campos marcados. Esses campos foram alterados conforme as
características do dispositivo que se quer personalizar.
Siga os passos abaixo para gravar a memória EEPROM de um novo dispositivo:
1 - Certifique-se se há uma pasta com os arquivos dos drivers D2XX em seu disco
rígido (HD):
Figura 1 - Pasta com os arquivos dos Drivers D2XX
2 - Dê duplo clique sobre o arquivo ftd2xx.inf, para abri-lo (no Bloco de Notas
do Windows). Altere ou adicione as linhas marcadas, conforme mostra a figura
abaixo:

Figura 2 - Fragmentos do arquivo FTD2XX.INF mostrando

as linhas que devem ser adicionadas/alteradas
[FtdiHw]
%USB\VID_0403&PID_6001.DeviceDesc%=FTD2XX, USB\VID_0403&PID_6001
%USB\VID_5000&PID_6000.DeviceDesc%=FTD2XX, USB\VID_5000&PID_6000
[ControlFlags]
[FTD2XX.UnInst]
HKLM,%WINUN%,"FTD2XX"
HKLM,%WINUN%\FTD2XX , "UninstallString",,"%11%\FTDIUNIN.exe
%11%\FTD2XXUN.INI"
HKLM,%WINUN%\FTD2XX , "DisplayName",,"ROGERCOM Controle Residencial -
Driver USB."
[Strings]
Ftdi="FTDI"
USB\VID_0403&PID_6001.DeviceDesc="FTDI FT8U2XX Device"
USB\VID_5000&PID_6000.DeviceDesc="Controle Residencial via USB."
FTD2XX.SvcDesc="FTD2XX.SYS FT8U2XX device driver"
WINUN="Software\Microsoft\Windows\CurrentVersion\Uninstall"
DriversDisk="FTDI FTD2XX Drivers Disk"
Este ícone indica que você deverá duplicar a linha e alterar o VID e o PID, iguais
àqueles que foram gravados na EEPROM do novo dispositivo. No nosso caso
VID=5000 e PID=6000.
Este ícone indica que você deverá alterar somente a string de cor verde daquela
linha.
A string "DisplayName",,"ROGERCOM Controle Residencial - Driver USB.", será exibida

na janela "Adicionar ou remover programas" do Painel de Controle do Windows.
Já a string DeviceDesc="Controle Residencial via USB.", será exibida na seção de
dispositivos USB instalados, no Gerenciador de Dispositivos do Windows e na janela
de propriedades do mesmo.
Figura 3 - Alteração do PID e VID do arquivo FTD2XXUN.INI

[Uninstall]
Converter=FTD2XX
Key=FTD2XX
O arquivo FTD2XXUN.INI é utilizado pelo programa de desinstalação dos

drivers.

3 - Após a alteração dos arquivos, salve-os;
4 - Conecte o seu novo dispositivo FT232BM a uma das portas do Root Hub do
Host PC;
Figura 4 - Foto ilustrativa do novo dispositivo conectado ao Host USB (PC)
5 - Abra o programa MProg;
6 - Clique no botão (Create New Programming Template), para criar um novo

template;
7 - Selecione no campo Device Type o dispositivo chamado FT232BM;
8 - Preencha os dados conforme a tela abaixo:

Figura 5 - Tela de edição de dados do MProg para gravar um novo dispositivo
9 - Após o preenchimento dos dados, clique no botão (Save Template As...) para
salvar o template em um arquivo (DispResid1.ept);

Figura 6 - Tela salvar template do MProg
10 - Clique no botão Salvar;
11 - Depois, clique no botão para gravar a memória EEPROM do dispositivo;
Se a gravação tiver tido sucesso, será exibida a seguinte mensagem na área de

status do MProg, mas com um número serial diferente:
Figura 7 - Tela de status do MProg
Dicas:
- Caso haja alguma dificuldade, desconecte o dispositivo do Bus USB e remova

os drivers. Para isso siga os passos da seção "Desinstalando os drives D2XX e
VCP", no final desta aula.
- Se por algum motivo você não lembrar qual é o número do VID e PID que
estão gravados na memória EEPROM do dispositivo, execute o aplicativo
Usbview.exe (analisador de protocolo USB).
Download do Usbview.exe.

Figura 8 - Tela do aplicativo Usbview
No programa Usbview, para se descobrir qual o VID e PID, clique sobre o nome
do dispositivo na janela da esquerda, na janela da direita são mostrados os campos
VID (idVendor) e PID (idProduct). Pronto, agora adicione o VID e PID no arquivo
ftd2xx.inf conforme exibido na Figura 2. Salve o arquivo e conecte o dispositivo ao
Host USB.
Desinstalando os drives D2XX e VCP
O método certo para remover os drivers da FTDI, é através do "Adicionar ou

remover programas" do Painel de Controle do Windows.
O Windows chama automaticamente o programa FTDIUNIN.EXE, passando

para ele alguns parâmetros, sobre o driver a ser removido, como os números VID e
PID.
Siga os passos abaixo para remover os drivers D2XX ou VCP:
1 - Desconecte fisicamente o dispositivo do Bus USB;
Figura 9 - Desconecta dispositivo
2 - Abra o utilitário "Adicionar ou remover programas" através do Painel de

Controle do Windows;

Figura 10 - Tela do Adicionar ou remover programas do Windows
3 - Selecione na listagem da figura acima, o nome do driver, depois clique no

botão Alterar/remover. Se você personalizou o dispositivo, o nome do driver será
igual àquele que escreveu na seção [FTD2XX.UnInst] do arquivo ftd2xx.inf.
Figura 11 - Tela de aviso do utilitário de remoção FTDIUNIN.EXE
4 - Clique no botão Continue para passar para o próximo passo;

Figura 12 - Tela de conclusão de remoção dos drivers
5 - Pronto, os drivers foram removidos, clique no botão Finish para finalizar.
Para remover os drivers VCP, os passos são os mesmos, só muda o nome

exibido na listagem do utilitário Adicionar e remover programas do Painel de
Controle do Windows.
Observação importante:
Se o VID e o PID gravados na EEPROM forem diferentes dos existentes no

arquivo ftd2xx.inf, ao conectar o dispositivo ao Bus USB, e tentar instalar os dirvers,
será exibida uma mensagem de erro, e a comunicação USB não será estabelecida.
O dispositivo ficará parcialmente conectado ao sistema USB. Para resolver esse
problema, desconecte o dispositivo; remova os drivers; abra o arquivo ftd2xx.inf e
acrescente os mesmos PID e VID gravados na EEPROM. Torne a conectar o
dispositivo ao Bus USB, e siga os procedimentos de instalação dos drivers.

Veja abaixo, a tela com a mensagem de erro na instalação dos drivers:
Figura 13 - Mensagem de erro ao instalar os drivers
A figura acima mostra a tela de mensagem de erro, exibida quando o VID e PID
dos drivers são diferentes daqueles existentes na memória EEPROM do dispositivo.

Introdução a Porta Serial
A partir desta aula iremos começar nossos estudos sobre a comunicação serial,
especificamente o padrão RS232 que tem mais de 40 anos de existência, mas ainda
é muito usado em vários dispositivos atuais, como computadores Modems, Mouses,
Microcontroladores, Impressoras etc. Como objetivo principal pretendo deixar
informações suficientes para que possam compreender o funcionamento da porta
serial e, a partir dessa compreensão, tornarem-se capacitados a criar, tanto software
de controle como o hardware, e assim implementar seus novos projetos.
A comunicação serial teve início com a invenção do telégrafo. Depois teve um

grande desenvolvimento com a invenção do Teletype (teletipo) pelo Francês Jean
Maurice Émile Baudot, em 1871. Baudot, além de criar toda a mecânica e elétrica do
Teletype, criou também um código para a transferência serial assíncrona de
informações, de forma totalmente digital.
No código de Baudot havia dois subconjuntos de códigos. Um era os das letras,

chamado por ele de LTRS, abreviatura da palavra LETRAS, e o outro era chamado
de FIGS, que significa FIGURAS. Os LTRS eram para codificar as letras, e os FIGS
para os dígitos de 0-9 e alguns símbolos e sinais de pontuação. Esse código
utilizava um sistema de 5 dígitos binários para representar um caracter. O dígito 1
era chamado de Mark (Marca) e o zero (0) de Space (Espaço). O aparelho de
Teletype recebia um caracter de forma assíncrona e o imprimia numa fita de papel,
onde a Marca era representada por um furo e o Espaço pela ausência do mesmo.
Na transmissão dos caracteres através da linha telegráfica, o sinal de Marca era
representado pela presença de corrente elétrica, e o Espaço pela ausência desta
corrente. Para que o Teletype conseguisse distinguir o início e o final de um caracter,
o mesmo era precedido com um sinal Espaço e finalizado com um sinal de Marca.
Entenda que o estado da linha ociosa (sem transmissão de dados) era o sinal de
Marca (presença de corrente elétrica). Foi baseado nesse sistema que o padrão de
transmissão RS232 evoluiu e se tornou no padrão atual, usado na maioria dos
computadores e equipamentos digitais diversos.
A finalidade de se escrever aqui, sobre o trabalho de Baudot, é mostrar a

relação de seu invento com o padrão serial RS232 atual. Alguns termos ainda
usados como: BAUD (Baudot), Mark, Space, Start bit, Stop bit com intervalo de 1,5

bit, tamanho dos dados de 5 bits, entre outras similaridades, iremos compreender
nesta aula.
Tabela 1 - Tabela parcial do código de Baudot

BITS DECIMAL LTRS FIGS
00011 3 A -
11001 25 B ?
01110 14 C :
01001 9 D $
00001 1 E 3
01101 13 F !
. . . .
. . . .
. . . .
01000 8 CR CR
Jean Maurice Émile 00010 2 LF LF Receptor Baudot
Baudot (1845-1903) 00100 4 SP SP Coleção de imagens
11111 31 LTRS LTRS Fons Vanden Berghen.
11011 27 FIGS FIGS
Para explicar como eram transmitidos os caracteres codificados no sistema de

Baudot, segue abaixo um exemplo de como enviar a palavra FADA!
LTRS F A D A FIGS !
11111 01101 00011 01001 00011 11011 01101
No exemplo acima, as letras da palavra FADA estão dispostas na primeira

coluna (LTRS) da tabela de códigos de Baudot. Portanto, para que o sistema
receptor de teletype entenda, o transmissor terá que informá-lo previamente através
do envio de um comando LTRS (11111), alertando que, os próximos caracteres
enviados serão letras. Para enviar o caracter "!", antes, se envia o código FIGS para
avisar ao receptor que interprete os códigos conforme os da segunda coluna (FIGS).
Na verdade, os códigos especiais LTRS e FIGS servem para combinar, e

portanto, enviar qualquer um dos caracteres da tabela de códigos de Baudot (Letras,
dígitos, sinais de pontuação e símbolos) num total de 64, incluindo os próprios LTRS
e FIGS.
Para assimilarmos o conceito dos códigos LTRS e FIGS no sistema de Baudot,

podemos comparar, grosso modo, com um teclado de computador onde o código de
cada tecla é transmitido serialmente e, para alternar entre letras maiúsculas e
minúsculas, pressiona-se a tecla CapsLock.

Figura 1 - Sinal elétrico para o caracter 'P' (10110) no código de Baudot
Na figura acima temos a representação gráfica de um caracter de 5 bits do

código Baudot, na relação corrente/tempo. Quando a linha está ociosa (nenhum
dado fluindo), a mesma fica no estado Marca (presença de corrente elétrica).
Como exemplo, para se transmitir o caracter 'P' (10110), primeiro envia-se um

START (ausência de corrente na linha - Espaço) por um determinado intervalo de
tempo (t). Depois se envia os impulsos representando as Marcas e os Espaços do
código do caracter. Após isso, envia-se um STOP (A linha é levada ao estado
Marca), e fica assim indeterminadamente até que um novo caracter seja enviado.
Figura 2 - Fita de papel com impressão do código de Baudot
A figura acima mostra uma fita de papel com impressões dos códigos de
Baudot. O bit 1 (Marca) é associado a um furinho, e o bit 0 (Espaço), a ausência do
mesmo, ou seja, um espaço.
Modos de transmissão serial
O modo da transmissão pode ser classificado em Simplex, Half-duplex e Full-

duplex. Ou seja, a informação pode fluir num único sentido, nos dois sentidos sendo
que somente um transmitindo a cada vez, ou nos dois sentidos simultaneamente.

Os sistemas de comunicações como: telefonia, satélite, Redes, sistemas

wireless, teleprocessamento, etc., usam um desses modos de transmissão. A
escolha de qual modo usar depende do que se pretende transmitir.
SIMPLEX
No modo Simplex, o fluxo de transmissão flui somente em um sentido, ou seja,
um dispositivo só envia os dados e o outro só recebe. Como exemplo, podemos citar
uma emissora de Rádio, onde ela só transmite.
Figura 3 - Modo SIMPLEX
HALF-DUPLEX
No modo Half-duplex ambos os dispositivos transmitem nos dois sentidos, mas,
não simultaneamente. Ou seja, um transmite enquanto o outro espera e vise versa.
Esse modo usa um único canal bidirecional. Como exemplos, podemos citar um
rádio Walk-Talk, onde ambas as pessoas podem falar e escutar, mas não ao mesmo
tempo.
Figura 4 - HALF-DUPLEX
FULL-DUPLEX
No modo de transmissão Full-duplex, há duas linhas independentes, onde uma
é usada para transmitir e a outra para receber os dados. Ambos os dispositivos
taransmitem simultaneamente. Como exemplo, podemos citar uma auto-estrada de
duas vias onde os veículos rodam nos dois sentidos.
A porta Serial RS232 trabalha em modo Full-duplex, através das duas linhas TX-
RX.
Figura 5 - FULL-DUPLEX

DTE / DCE
Diferente da porta USB, onde o Host é sempre um PC e um dispositivo não pode

se conectar com outro dispositivo diretamente (a não ser que um deles use
tecnologia OTG). No padrão RS232, um DTE (Data Terminal Equipment), ou seja,
um PC, pode ser conectado a um outro PC (DTE), ou a um DCE (Data Circuit-
Terminating Equipment), que pode ser um Modem ou qualquer outro dispositivo
serial RS232. É possível também um DCE estabelecer comunicação com outro
DCE. Como exemplo, posso citar dois dispositivos microcontrolados que disponham
de periféricos UART para estabelecer comunicação serial.
Figura 6 - Terminais DTE-DCE
A interface RS232 foi criada com o propósito inicial de conectar Equipamento de

Terminais de Dados (DTE), a aparelhos de Modem (DCE - Equipamentos de
Comunicação de Dados). Com o passar dos anos e a evolução da tecnologia,
surgiram novos equipamentos. Atualmente o RS232 é usado para conectar uma
grande variedade de dispositivos eletrônicos ao computador, como mouses,
dispositivos de telemetria, PDVs, balanças digitais, códigos de barra, impressoras,
Nobreaks, dispositivos microcontrolados em geral entre outros.
Quando estivermos estudando os sinais dos conectores RS232, iremos

perceber que os pinos são nomeados com termos técnicos referente as linhas de um
Modem.
Tipos de transmissão
Numa transmissão serial é preciso que o DTE entre em sincronismo como o

DCE para que os bits possam ser enviados pela linha. Dispositivos seriais podem
transmitir de forma síncrona ou assíncrona. O receptor, através de seus circuitos
dedicados, monitora o sinal enviado pelo transmissor e, dessa forma, obtém os bits
que estão sendo transmitidos, no mesmo intervalo de tempo.
Síncrona
No tipo de transmissão síncrona, o DTE fica constantemente enviando sinais
para o DCE, com o objetivo de manter a sincronização da comunicação. Esse tipo

de transmissão é mais rápido que a assíncrona, porque não necessita enviar sinais
de controle para cada byte transmitido, como, Start bit e Stop bits.
Na transmissão síncrona, envia-se um ou mais bytes de sincronismo antes do

início dos pacotes de dados, e depois, alguns bytes para indicar o final dos mesmos.
Após a transferência dos pacotes, o DTE continua enviando bytes de controle para
manter o sincronismo com o DCE.
Figura 7 - Exemplo didático de uma transmissão Síncrona
A figura acima mostra uma transmissão síncrona em nível físico (de hardware).
Observe que o DTE é quem envia o sinal de clock para manter o DCE em
sincronismo. Os bits dos pacotes são enviados um-a-um através da linha de Dados
a cada mudança do sinal de clock.
Como exemplo, vamos imaginar a transferência do pacote de dados: "Curso

USB/Serial". Veja:
sinc sinc sinc... INICIO_BLOCO "Curso USB/Serial" FIM_BLOCO sinc sinc sinc...
Muitos chips de memória usam a transmissão síncrona para ler e gravar dados.
Assíncrona
No tipo de transmissão assíncrona, o relógio do DTE e DCE são configurados
para oscilarem na mesma freqüência (velocidade de transmissão).
Numa transmissão assíncrona os dados são divididos em pequenos pacotes de

dados de tamanho entre 5 a 8 bits, para minimizar o risco do oscilador do
transmissor e do receptor variar. Se os dados não fossem divididos em pacotes
menores, os relógios iriam gradativamente perder o sincronismo, conforme fosse
passando o tempo, isso porque o temporizador (relógio) do DTE é independente do
que há no DCE. É por isso que na transmissão serial RS232 utiliza-se um bit de
início (Start bit), e alguns bits de parada (Stop bit), para garantir o sincronismo.
Figura 8 - Exemplo didático de uma transmissão Assíncrona

A figura acima mostra uma transmissão assíncrona; DTE e DCE teem relógios
de temporização independentes; são configurados com a mesma velocidade (Baud);
mas para garantir a sincronização ideal, os dados teem tamanho máximo de 8 bits (9
quando utilizá-se o bit de paridade), e são precedidos e finalizados com bits de
sincronismos, respectivamente (Start bit e Stop bit).
A figura abaixo mostra a formatação de um Frame (quadro) de 11 bits de

extensão, para envio numa transmissão assíncrona.
Figura 9 - Formatação de um Frame (Quadro) de 11 bits
Na figura acima temos um Frame de 11 bits formatado da seguinte forma: 1 bit

de Start (início); 8 bits de dado representado no exemplo como o caracter "A"; 1 bit
para a paridade e 1 bit de Stop (parada).
Quando a linha está ociosa (inativa, idle ou inoperante) ela permanece no

estado Marca ou "1" lógico, ou seja, com níveis de tensões entre -3v a -25v.
Para transmitir um caracter pela linha serial, o transmissor primeiramente envia

um 1 bit de Start com o objetivo de zerar e inicializar o temporizador do receptor,
avisando que um novo caracter está a caminho. Após os bits de dados e a paridade
(opcional) terem sido enviados, logo 1 Stop bit é transmitido para avisar ao receptor
o final do Frame, e manter a linha no estado inativa novamente.
Observe também na figura acima, o tempo de 1 bit (104uS). Ou seja, o intervalo

de tempo que o receptor terá para identificar o estado do sinal Marca (1) ou Espaço
(0). Esse tempo também é o mesmo usado pelo transmissor enviar um bit.
No exemplo da figura acima estamos usando uma taxa de transferência de 9600

Baud. Sendo assim, a cada 104uS um sinal é alternado, ou seja, passa de um
estado para outro.
Para saber o tempo de cada bit, divida o número 1 pela taxa de baud: 1/9600 =
104uS (arredondado). Este é o tempo de um bit.

Figura 10 - Exemplo de uma transmissão serial
A figura acima mostra a animação de uma transmissão serial bit-a-bit (DTE--

>DCE), usando como exemplo o caracter "A".
Bit de Paridade
O bit de paridade é utilizado numa transmissão serial assíncrona, como uma

solução primária em nível de hardware para detectar a ocorrência de erros na
transmissão de dados. A cada byte enviado, o receptor verifica se os bits do mesmo
não foram modificados. O hardware receptor verifica isso somando todos os bits "1"
que há no byte, mais o valor do bit de paridade. O resultado dessa soma deverá ser
Par ou ímpar. Se a paridade na configuração do DTE e DCE foi definida, por
exemplo, como PAR, a soma dos bits "1" do dado, mais o valor do bit de paridade
recebido tem que ser PAR para um dado correto. Se por acaso o resultado der
Ímpar, isso indica que o dado recebido sofreu alguma modificação em algum
momento da transmissão, ou seja, houve um erro.
Se a transmissão não for usar bit de paridade, isso deve ser avisado na
configuração do DTE e DCE.
Os tipos de paridades que podem ser usadas para configurar os terminais são:
Nenhuma, Ímpar, Par, Marca ou Espaço. As paridades Marca e Espaço não são
mais usadas, e ainda constam nas configurações para manter compatibilidade com
os antigos sistemas de transmissão serial.
Figura 11 - Exemplo 1 - paridade PAR

A figura acima demonstra o uso da paridade PAR. Temos um dado de 8 bits

00110100 (com um total de 3 bits "1", resultando em um número Ímpar). Para que a
soma dos bits de dado+paridade seja Par, o circuito transmissor adiciona o valor "1"
ao bit de paridade. Assim, a soma dos bits de dados+paridade fica igual a 4 (PAR).
Após isso, o transmissor envia o Frame ao receptor. Por sua vez, ao receber o
Frame, o receptor verifica se a soma dos bits de dado+paridade é um resultado
também PAR, confirmando o sucesso. Caso contrário, é detectado um erro de
transmissão.
A demonstração abaixo segue o mesmo princípio da anterior, para adicionar o

bit de paridade pelo transmissor e a verificação pelo receptor, levando em conta
também a paridade PAR. A diferença abaixo é que a soma dos bits do dado já é um
resultado Par. Nesse caso, o hardware do transmissor adiciona um valor "0" ao bit
de paridade, para que o resultado da soma dos bits dado+paridade seja um
resultado PAR.
Figura 12 - Exemplo 2 - paridade PAR
Interface RS232
O padrão RS232 foi criado em 1962 para conectar diretamente dois dispositivos.
Foi padronizado pela Associação de Indústria de Eletrônica (EIA). Originalmente era
usado para conectar dispositivos de teletipo que utilizavam o código ASCII para
transmitir dados de forma assíncrona. As letras "RS" quer dizer “Recomended
Standard” (padrão recomendado) e 232, é a versão. O padrão RS232 foi criado com
o objetivo de definir as características elétricas, temporização, mecânicas e funções
dos sinais da interface serial, para conectar dispositivos ponto-a-ponto.
Com o passar dos anos o padrão evoluiu e teve a terceira revisão em 1969 (RS-
232C) versão "C". EIA-232D e EIA-232E foram atualizadas respectivamente em
1987 e 1991.
Por volta de 1984 o único padrão de comunicação serial em computadores

pessoais IBM-PC era o RS232C. Mais tarde surgiram o irDA (Infra-vermelho), USB
entre outros.

Sinais elétricos
O gráfico abaixo mostra as tensões elétricas para representar os sinais lógicos

usados no padrão RS232. Observe que há uma região de transição do sinal onde a
tensão é utilizada para representar o "0" e o "1" lógico. Veja também que o "0" lógico
é associado a faixa de tensão positiva e o "1" a faixa de tensão negativa.
Figura 13 - Sinal elétrico do padrão RS232
As tensões máximas que a interface RS232 suporta é 25v. Um Espaço ou zero

(0) lógico, é representado por tensões positivas, entre +3v a +25v. Uma Marca ou o
um (1) lógico, é representado por tensões entre -3v à -25v. Já a faixa de tensões
entre -3v e +3v é conhecida como uma região de transição, sendo considerada
indefinida. Ou seja, esta região não representa nenhum estado lógico válido no
padrão RS232.
Algumas interfaces RS232 nos computadores atuais fornecem -12v e +12v, mas
suportam mínimas de -25v e máximas de +25v.

Conectores
Existem atualmente vários tipos de conectores seriais, como o RJ45,

parafusado, plug, etc. Essa diversidade é porque muitos fabricantes de dispositivos e
equipamentos de comunicação serial criam seus próprios conectores, seja por
questões de designer ou dimensões físicas, por não ter espaço para comportar um
conector padrão RS232. Mas o padrão RS232 define somente os tipos macho e
fêmea dos conectores DB9 e DB25. Aqui iremos tratar dos dois como sendo do tipo
Macho. Os do tipo furinho são fêmeas. Tanto o conector macho como o fêmea tem
seus pinos numerados. Cada pino tem um significado e esse significado está
associado a um periférico Modem.
Veja abaixo as características do conector DB9:
Figura 1 - Conector DB9 Macho

Tabela 1 - Significado e sentido dos sinais dos pinos do DB9 Macho

DB9 - No. Sentido
Sinal Descrição
Pino (DTE)
Pino 3 TXD Saída=> Transmit Data
Pino 2 RXD <=Entrada Receive Data
Pino 7 RTS Saída=> Request To Send
Pino 8 CTS <=Entrada Clear To Send
Pino 6 DSR <=Entrada Data Set Ready
Pino 5 SG - Signal Ground
Pino 1 DCD <=Entrada Data Carrier Detect
Pino 4 DTR Saída=> Data Terminal Ready
Pino 9 RI <=Entrada Ring Indicator
Obs.: Alguns pinos do DB25 não foram descritos aqui, isso porque não são muito
utilizados. Alguns cabos seriais usam o pino 1 para ligar um fio de malha. No DB9
não há um pino para ligar a malha e pode ser soldado na própria carcaça do cabo. O
objetivo do fio de malha é eliminar ruídos na transmissão entre o DTE e o DCE,
quando a mesma se faz em altas velocidades.

Figura 2 - Conector DB25 Macho
Tabela 2 - Significado e sentido dos sinais dos pinos do DB25 Macho

DB25 - No. Sentido
Sinal Descrição
Pino (DTE)
Pino 2 TXD Saída=> Transmit Data
Pino 3 RXD <=Entrada Receive Data
Pino 4 RTS Saída=> Request To Send
Pino 5 CTS <=Entrada Clear To Send
Pino 6 DSR <=Entrada Data Set Ready
Pino 7 SG - Signal Ground (terra)
Pino 8 DCD <=Entrada Data Carrier Detect
Pino 20 DTR Saída=> Data Terminal Ready
Pino 22 RI <=Entrada Ring Indicator

Observe que no conector DB9 o pino 2 é RXD, e o pino 3 é TXD. No DB25 isso
não é o mesmo, veja na tabela acima que é o inverso. Fique atento quando for fazer
conversões de conectores DB9 para DB25 ou vice versa.
Funções dos sinais de controle
As linhas de saídas >> DTR e RTS podem ser ligadas ou desligadas

independentemente, através do envio de um valor lógico "0" ou "1" para um
registrador específico da porta serial. O "0" liga e o "1" desliga.
Veja o sentido dos sinais, se o dispositivo conectado à porta serial for

um Modem:
Quando o DTR for ligado ("0") prepara o modem para ser conectado ao telefone.
Após a conexão o sinal se mantém. Para desconectar o modem da linha telefônica,
DTR deve ser levado a "1" (desligado).
Quando o RTS for ligado ("0") prepara o Modem para aceitar os dados
transmitidos pelo PC. Quando o Modem estiver pronto ele enviará um sinal ("0")
ativando a linha CTS no PC.
As linhas de entradas << CTS, DCD, DSR e RI podem ser lidas

independentemente uma das outras. São usadas pelos dispositivos externos para
enviar informações de aviso para o DTE (PC). Os sinais recebidos podem ser lidos
num registrador específico da porta serial. Esses valores podem ser "0" lógico
(ligado) ou "1" lógico (desligado).
O CTS é habilitado em ("0") pelo DCE para avisar ao DTE (PC) que ele já pode
transmitir.
O DCD é habilitado em nível lógico ("0") pelo DCE quando a linha telefônica
estiver fora do gancho ou uma conexão for completada. Quando não houver tom de
resposta, o DCE envia um lógico ("1") para o DTE (PC).
O DSR é habilitado em ("0") lógico pelo DCE para avisar sucesso na operação. Se
houver um erro o DCE sinaliza com um ("1") lógico.
O RI é habilitado em nível lógico ("0") quando for detectado um sinal de chamada
na linha telefônica. É desabilitado em ("1") quando não houver tom de chamada.
Funções dos sinais de dados
A linha de saída >> TXD é utilizada para enviar bits de dados numa velocidade
controlada pelo hardware da porta serial. Como sabemos, através dessa linha
podemos enviar um byte no formato (Start bit, bits de dados, paridade, Stop bit). Mas
também é possível usar essa linha como um simples liga/desliga, enviando um
comando break (ON/OFF) para um registrador da porta serial.

A linha de entrada << RXD é utilizada para receber bits de dados numa
velocidade controlada pelo hardware da porta serial. Através dessa linha podemos
receber um byte no formato (Start bit, bits de dados, paridade, Stop bit).
Na próxima aula iremos estudar os registradores da UART (Universal

Asynchronous Receiver Transmitter), para podermos manipular os sinais de controle
e de dados da linha serial.
Controle de Fluxo ou Handshaking
É uma forma de controlar a transmissão de dados numa comunicação entre dois

dispositivos serial. Ou seja, é uma maneira amigável de um dispositivo perguntar e o
outro responder. Freqüentemente os dispositivos enviam comandos ou sinais um
para o outro, perguntando se pode transmitir. O outro dispositivo responde negando
ou afirmando. O objetivo é eliminar a sobreposição de caracteres (erro de overrun)
no dispositivo receptor.
Controle de Fluxo por Software XON/XOFF
O controle de fluxo por software é conhecido como XON/XOFF (um conjunto de

caracteres especiais da tabela ASCII), usados para controlar a transmissão de
dados entre dois dispositivos. O caracter XON é igual ao código ASCII 17 e o XOFF
ao 19. Um caracter XOFF é enviado pelo dispositivo receptor ao dispositivo emissor
para pedir que ele pare momentaneamente de enviar, porque o buffer de recepção
está ficando sem espaço para armazenamento dos caracteres. Quando o buffer
estiver quase vazio, o receptor envia um caracter XON ao transmissor avisando-o
que está pronto para receber mais caracteres.
A vantagem de se utilizar o controle de fluxo XON / XOFF é que são

necessários somente 3 fios para conectar o DTE ao DCE. Há duas desvantagens:
uma delas é que um arquivo a ser transmitido não poderá conter os códigos ASCII
17 e 19, pois a transmissão será interrompida inesperadamente. A segunda é a
redução na velocidade de transmissão, pois os códigos de controle XON e XOFF
circulam pelas linhas de dados TXD e RXD.
Figura 3 - Cabo para handshaking por software XON/XOFF

Controle de Fluxo por Hardware RTS/CTS ou DTR/DSR
Para implementar o controle de fluxo por hardware é preciso adicionar mais linhas
entre o DTE e o DCE. Numa comunicação onde os dois lados tanto podem transmitir
como receber, utiliza-se um par de linhas RTS/CTS tanto no DTE como no DCE.
Quanto o DTE quer transmitir, ele ativa a linha RTS. Se o DCE puder receber os
dados ele avisa ao DTE ativando a linha CTS.
As vantagens de se implementar controle de fluxo via hardware é a ótima

performance na velocidade de comunicação, porque agora as linhas de dados TXD
e RXD não precisam dividir a Banda para enviar caracteres especiais de controle de
fluxo, como o XON e o XOFF. A outra vantagem é que um arquivo a ser enviado
pode conter quaisquer caracteres especiais, sem o inconveniente de a conexão ser
interrompida como no caso dos caracteres XON e XOFF de controle por software.
A desvantagem é o custo do cabo por conter mais fios.
Figura 4 - Cabo para handshaking por hardware RTS/CTS
Algumas vezes o controle de fluxo via hardware pode ser implementado através
dos sinais DTR/DSR da mesma forma como foi explicado usando os sinais
RTS/CTS. Veja na figura abaixo, a conexão das linhas para se confeccionar um
cabo serial com suporte a controle de fluxo via hardware, usando os sinais
DTR/DSR.
Figura 5 - Cabo para handshaking por hardware DTR/DSR

Cabo Null Modem
Se desejarmos fazer uma transmissão de dados PC-PC (DTE-DTE) sem a

utilização de Modems confecciona-se um cabo serial chamado Null Modem. Este
cabo só tem as linhas SG, TXD e RXD conectadas aos conectores do cabo serial.
Os outros sinais são interligados de forma a entrarem em círculo ou loop (loopback).
Assim os dois pontos (DTE-DTE) sempre estarão prontos para enviar e receber
dados.
Veja nas figuras abaixo, 3 maneiras de confeccioná-los, usando conectores

DB25 e DB9:
Figura 6 - Cabo Null Modem DB9-DB9

Confecção de cabos para controle de fluxo por Hardware
Os três cabos abaixo são usados para conectar dois dispositivos através de
controle de fluxo (handshaking) por Hardware. Veja que a diferença entre as três
figuras são os tipos de conectores:
Figura 9 - Cabo Handshaking por Hardware - DB25-DB9

Obs.: Além de confeccionarmos um cabo serial, é preciso, além de se desenvolver

um software serial, elaborar um protocolo. Alguns softwares de comunicação serial
usam protocolos padronizados como o simples XON/XOFF ou outros mais
sofisticados. Alguns protocolos usados são: ZMODEM, XMODEM, YMODEM,
XMODEM-CRC, YMODEM-G, etc.
Em nossos projetos iremos implementar nossos próprios protocolos.
Interligação LoopBack
As vezes precisamos testar um novo programa de comunicação serial que

criemos, sem que para isso seja preciso conectar dois pontos (DTE-DTE). Ou as
vezes não dispomos de dois computadores ou duas portas seriais no mesmo micro.
Se um desses for seu problema, confeccione um dos conectores LoopBack
mostrados nas figuras abaixo, soldando os pinos conforme indicado:

Figura 12 - Conector LoopBack DB9
Figura 13 - Conector LoopBack DB25

UART
(Universal Asynchronous Receiver Transmitter)
Transmissor e Receptor Assíncrono Universal
Um chip UART é um tipo de chip programável, que tem a função de gerenciar a

comunicação serial assíncrona num computador, ou quaisquer outros dispositivos
similares. Um chip UART converte dados paralelos em seriais e transmite
automaticamente os mesmos pelo pino TXD da Porta Serial, seguindo as
especificações do protocolo RS232 (start bit, bits de dado, bit de paridade e stop bit).
Também recebe os dados de forma serial pelo pino RXD e converte em paralelo (1
byte), mantendo o mesmo num registrador interno específico, para posterior leitura
pela aplicação do cliente. O UART também gerencia todos os sinais de controle e
estado como: DTS, DSR, RTS, CTS, DCD e RI.
Em 1991 a IBM introduziu no projeto do PC um chip UART 8250 da National.

Esse chip UART tinha a capacidade de receber e armazenar somente um byte, e
não era tão eficiente em questão de velocidade (aproximadamente 9600 baud). Para
que o caracter recebido pelo UART não fosse sobreposto por um novo caracter, o
software aplicativo tinha que ler esse dado rapidamente. Mais tarde surgiu o UART
16450, totalmente compatível com o UART 8250, mas com a vantagem de ser mais
rápido (aproximadamente 38400 baud). Depois lançaram o 16550 com mais espaço
para armazenar os caracteres recebidos. Buffer FIFO (First Input First Output - O
primeiro que entra é o primeiro que sai). Mas logo saiu de linha, pois esse buffer não
funcionava corretamente. Para corrigir esse problema, foi lançado o UART 16550
com finais A, AF ou AFN. Nesses modelos, o buffer FIFO tem um tamanho de 16
bytes, tanto para a transmissão como para a recepção dos dados. Todos são
compatíveis com o UART 8250.
Para usar um chip UART adequadamente para transmitir e receber dados,

primeiro teremos que programá-lo com parâmetros passados a alguns de seus
registradores. Esses parâmetros são valores como: velocidade de transmissão,
tamanho dos dados (5, 6, 7 ou 8), paridade (nenhuma, ímpar, par, marca ou espaço)
e stop bit (quantos bits de parada: 1, 1.5 ou 2). É possível programar outros
parâmetros como: habilitar o UART a gerar interrupções quando um erro de: Overrun
(sobreposição), Paridade ou Break ocorrer. Ou quando ocorrer mudanças em
qualquer uma das entradas: CTS, DCD, DSR ou RI.

A empresa StarTech fabrica o UART 16650, com buffer FIFOs de 32 bytes e

velocidade máxima de transmissão de 460.800 baud. Já Texas Instruments fabrica o
UART 16750, com FIFOs de 64 bytes e velocidade de até 921.600 baud. Esse último
não é compatível pino a pino com o UART 16550 da National.
Figura 1 - Pinagem de um chip UART 16550
A figura acima mostra um modelo de chip UART 16550, compatível com os

chips 8250 (diferente somente nos pinos 24 e 29), onde o pino 29 não é conectado e
o 24 é chamado de Select Out (CSOUT).
Os pinos D0-D7(Buffer de Bus de dados) são as entradas/saídas paralelas

usadas pela CPU para enviar/receber para o UART um byte de dado. Os pinos A0,
A1 e A2 são usados para endereçamento. O pino 10 (RD) recebe os bits serialmente
e o pino 11(TD) transmite-os. Os demais são conectados à CPU e ao circuito driver
da interface RS232.

Figura 2 - Diagrama do UART 16550
Na figura acima temos uma visão geral da estrutura interna do chip UART
16550. No lado esquerdo da figura observamos os pinos que serão conectados ao
Host (CPU), e ao lado direito, os pinos que serão conectados ao circuito driver da
interface RS232.
Tabela 1 - Os principais registradores do UART 16550

Porta Porta Nome do
Significado
COM1 COM2 Registrador
3F8h 2F8h THR Transmit Holding Register (Buffer de transmissão).
3F8h 2F8h RDR Receiver Data Register (Buffer de recepção).
3F8h 2F8h DLL Divisor Latch LOW (Byte LSB da taxa de transmissão).
3F9h 2F9h DLH Divisor Latch HIGH (Byte MSB da taxa de transmissão).
3F9h 2F9h IER Interrupt Enable Register (Habilita interrupções).
3FAh 2FAh IIR Interrupt Identification Register (Identifica a última int. ocorrida).
3FBh 2FBh LCR Line Control Register (Configura a comunicação serial).
3FCh 2FCh MCR MODEM Control Register (Controla os sinais do MODEM).
3FDh 2FDh LSR Line Status Register (Estado da linha serial).
3FEh 2FEh MSR MODEM Status Register (Estado dos sinais do MODEM).
Na tabela acima, temos nas duas primeiras colunas, os endereços das Portas:
COM1 e COM2. Esses endereços são fixos nos microcomputadores padrão IBM-PC
e similares. Observe também que um endereço está associado a um ou mais
Registradores do UART. Veja o endereço 3F8h, ele está associado aos
Registradores THR, RDR e DLL.
Todos os Registradores do UART são de 8 bits, portanto, os parâmetros

passados tem um tamanho de 1 byte.

A taxa de transmissão em Baud tem um tamanho de 16 bits, sendo assim, para

enviar esse valor para o UART o mesmo deve ser dividido em duas partes de 8 bits,
e passados como parâmetros em dois registradores distintos (DLL e DLH).
Segue abaixo os detalhes de cada registrador:
Registrador THR (Buffer de transmissão)
Quando uma aplicação deseja transmitir um caracter pela porta serial, ela
coloca um byte no registrador THR, ao detectar esse byte, automaticamente o UART
formata-o inserindo paridade (opcional) e Stop bit (criando um Frame). Após isso, o
Frame é movido para o registrador de deslocamento e depois transferido serialmente
pelo pino TXD da interface RS232.
Através do registrador de Status da linha LSR, é possível saber se o buffer de

transmissão THR está vazio, ou seja, se está pronto para aceitar um novo byte.
Registrador RDR (Buffer de recepção)
Quando o UART recebe um byte serialmente pelo pino RXD da interface RS232,
ele move o mesmo do registrador de deslocamento para o buffer de recepção RDR.
Para saber se há um dado no buffer de recepção RDR, nossa aplicação verifica se o
bit 0 do registrador LSR está ligado ("1"). Se um segundo byte for recebido sem que
o primeiro tenha sido lido, ocorrerá um erro de overrun.
Registradores DLH e DLL da taxa de transmissão
Para configurar o Gerador de Baud Rate, ou seja, a velocidade de transmissão

do UART, é preciso passar como parâmetro um valor chamado Divisor. O Divisor é o
resultado da seguinte operação: 1.843.200 / (bps * 16), onde: 1.843.200 é a
freqüência do cristal conectado ao UART; bps (a velocidade que desejamos que a
UART trabalhe, como:...2400, 9600, 19200, etc). O número 16 é um multiplicador.
Como o Divisor resulta em um número de 16 bits e cada registrador do UART é de 8
bits, então, temos que passar esse número em dois registradores: o DLH (Divisor
Latch High - Byte mais significativo) e o DLL (Divisor Latch Low - Byte menos
significativo).
Veja na tabela abaixo, alguns valores que podem ser passados como
parâmetros aos registradores DLH e DLL, para configurar a velocidade de
transmissão do UART:

Tabela 2 - Calculando os valores para atribuir aos registradores DLH e DLL

Velocidade DLH DLL
Divisor em decimal
(bps) MSB LSB
50 2304 = (1.843.200 / (50*16) 09h 00h
300 384 = (1.843.200 / (300*16) 01h 80h
600 192 = (1.843.200 / (600*16) 00h C0h
1200 96 = (1.843.200 / (1200*16) 00h 60h
2400 48 = (1.843.200 / (2400*16) 00h 30h
4800 24 = (1.843.200 / (4800*16) 00h 18h
9600 12 = (1.843.200 / (9600*16) 00h 0Ch
19200 6 = (1.843.200 / (19200*16) 00h 06h
38400 3 = (1.843.200 / (38400*16) 00h 03h
57600 2 = (1.843.200 / (57600*16) 00h 02h
115200 1 = (1.843.200 / (115200*16) 00h 01h
Como exemplo, usaremos a velocidade de 50 bps para configurar o UART. Veja

que o valor do Divisor em decimal é 2304, e em hexadecimal é 0900h. Para passá-lo
como parâmetro ao UART, primeiro habilita-se o bit 7 do registrador LCR, e depois
envia-se o primeiro byte (00h) no registrador DLL (byte menos significativo), e o
segundo byte (09h) no registrador DLH (byte mais significativo).
Registrador IER (Permite habilitar interrupções)
Através do registrador IER é possível configurar o UART para gerar um sinal de

interrupção quando alguns eventos ocorrerem. Assim, nossa aplicação poderá
identificar através do registrador IIR qual foi o evento que gerou a interrupção. A
interrupção pode ser definida ativando-se em "1", um dos bits (0 a 3) do registrador
IER mostrado na tabela abaixo:
Registrador IER - (leitura e escrita)

Bits Função Valor Descrição
0 Não habilita interrupção.
Habilita int. RDR 1 Uma interrupção é gerada pela UART para informar quando
0
(recebe) um dado estiver disponível no Registrador de recepção
(RDR).
Habilita int. THR 1 Uma interrupção é gerada quando a UART estiver preparada
1
(envia) para aceitar um novo dado no Registrador de transmissão
(THR).
Habilita Int. Status da
2 1 Uma interrupção é gerada quando ocorrer um erro de
linha
Overrun, Paridade ou Break.
Habilita Int. Status do
3 1 Uma interrupção é gerada quando ouver qualquer mudanças
Modem
em uma das entradas (CTS, DSR, DCD e RI) da porta serial.
4-7 indefinidos 0000 Não usados.

Como exemplo, para habilitar a interrupção de estado do Modem e interrupção

do RDR, o byte a ser enviado para o registrador IER é este: 00001001b (9 em
decimal).
Registrador IIR (Identifica a última interrupção ocorrida)
O Registrador IIR especifica quais interrupções foram geradas ou estão

pendentes. Se houve a ocorrência de uma interrupção, o bit 0 desse registrador
estará em "0". A especificação da interrupção pode ser obtida nos bits 1 e 2 do IIR.
Se não ocorreu interrupção o bit 0 do IIR estará em "1".
Registrador IIR - (Somente leitura)

Interrupção 0 O UART gerou um sinal de interrupção.
0
ON/OFF 1 Sem interrupção.
00 Linha de status do modem mudou (RI, DCD, DSR, CTS).
Identifica a 01 Buffer de transmissão (THR) vazio .
1,2
interrupção 10 Um byte foi recebido e está disponível no RDR.
11 Ocorreu um erro ou um Break foi recebido.
Reservados no Usados para configurar FIFOs nos UARTs 16550 ou mais
3-7 -
8250 e 16450 novos.
Como exemplo, se obtermos no registrador IIR um byte com o valor: 00000100b

(4 em decimal), isso indica que o UART gerou uma interrupção, porque recebeu um
byte, e este se encontra no buffer RDR.
Registrador LCR (Configura canal de comunicação serial)
É a partir desse registrador, que configuramos as características da

comunicação do UART, como: bit de dados, paridade, stop bit, break e habilitar o
DLAB (Divisor Latch Access Bit), ou seja, fazer com que os registradores DLL e DLH
recebam os bytes baixo e alto da taxa de transmissão (valor do Divisor).
Uma vez feita a configuração do UART e, uma conexão tenha sido estabelecida,
não é mais possível fazer mudanças, a não ser que se faça uma desconexão.
Depois é possível alterar as características e fazer uma nova conexão. Ou seja,
enquanto uma aplicação estiver conectada em uma porta serial COMx, não é
possível alterar as características da comunicação, pois ocorrerá erros.

Registrador LCR - (leitura e escrita)

00 5 bits de dado.
01 6 bits de dado.
0,1 Bits de dado
10 7 bits de dado.
11 8 bits de dado.
0 1 stop bit.
2 Stop bit 1 2 stop bits (somente se Bits de dado for 6, 7 ou 8 bits).
1,5 stop bit (somente se Bits de dado for 5 bits).
000 Nenhuma.
001 Ímpar.
3,4,5 Paridade 011 Par.
101 Marca.
111 Espaço.
0 Desativado.
6 Set break 1 Após a transmissão do caracter, a linha serial é forçada a ir
a condição Espaço (0 lógico).
0 Acesso normal dos registradores do UART para leituras e
Taxa de
1 escritas.
7 transmissão
Habilita o THR para receber o valor de configuração do
DLAB
Baud Rate (DLL e DLH).
Como exemplo, para configurar as características da comunicação com os

parâmetros: 8 bits de dado, paridade nenhuma, 1 stop bit e set break desabilitado,
escreve-se no registrador LCR o byte: 00000011b (3 em decimal).
Registrador MCR (Controla os sinais do MODEM)
É através do registrador MCR que são controlados os sinais do Modem como:

DTR e RTS. Também é possível fazer com que o UART execute um auto-teste
(Loopback).
Uma aplicação que usa controle de fluxo por hardware, acessa este registrador
para enviar sinais de controle DTR e RTS, e assim controlar o fluxo de dados na
transmissão.
Registrador MCR - (leitura e escrita)

A linha DTR é levada a 1, sinalizando ao MODEM que o
0
terminal não está pronto.
0 DTR
A linha DTR é levada a 0, sinalizando ao MODEM que o
1
terminal está pronto.
0 A linha RTS é levada a 1, sinalizando ao MODEM que o
computador não está pronto.
1 RTS
1 A linha RTS é levada a 0, sinalizando ao MODEM que o
computador está pronto.
2 Output 1 0 Sempre zero.
0 Controle de Interrupção do UART desativado.
3 Output 2
1 Controle de Interrupção do UART ativado.

Loopback - modo 0 Não executa testes no UART.

4
teste 1 Executa testes no UART.
5,6,7 Reservados 000 Sempre zeros.
Como exemplo, para ativar a linha DTR ponha o bit 0 em "0". Para desativá-la
ponha o bit 0 em "1". Para ativar a linha CTS ponha o bit 1 em "0". Para desativá-la
ponha o bit 1 em "1".
Registrador LSR (Estado da linha serial)
O registrador LSR é usado para obter informação sobre o estado da

transmissão e recepção dos dados. Checando alguns bits deste registrador, é
possível saber se há um caracter no buffer de recepção RDR, ou no buffer de
transmissão THR. Também é possível saber, se um caracter foi recebido com algum
tipo de erro como: overrun, frame, paridade, ou mesmo se um sinal de break foi
recebido.
Registrador LSR - (leitura e escrita)

0 Nenhum dado foi recebido. Buffer de recepção (RDR) vazio.
Data ready 1 Indica que o UART recebeu um dado. Esse bit permanecerá
0
(Dados Prontos) ligado enquanto o dado estiver no Buffer de recepção
(RDR).
0 Nenhum erro de Overrun foi detectado.
Overrun error
1 Um dado foi sobreposto sobre o anterior no Buffer de
1 (Erro de
recepção (RDR). Ou seja, os dados estão sendo recebidos
sobreposição)
mais rápido que a CPU ou a aplicação possa processá-los.
Parity error 0 Nenhum erro de paridade.
2 1 O dado recebido veio com erro de paridade.
(Erro de paridade)
0 Nenhum erro de Stop bit.
Framming error
3 1 O dado recebido não tem o número de Stop bit
(Erro de quadro)
especificado.
0 Nenhuma interrupção por break.
Break interrupt
1 Um break foi recebido (condição space da linha). Ou seja,
4 (Interrupção por
foram recebidos mais bits zeros que o tamanho dos bits de
break)
dados especificado.
THR empty 0 Há dado no buffer de transmissão (THR).
5 (Buffer de trans. 1 Buffer de trans. vazio. Um novo dado pode ser enviado para
vazio) o THR.
TSR empty 0 Há dado no registro de deslocamento de transferência
6 (Reg. de 1 (TSR).
transferência vazio) Registro de deslocamento de transferência (TSR) vazio.
FIFO data error 0 Este bit sempre está em zero para UARTs 8250 e 16450.
7 somente (16650 a
16750)

Registrador MSR (Estado dos sinais do MODEM)
O registrador MSR é usado para obter informações sobre o estado das linhas do
Modem, ou seja, as linhas de handshaking (CTS, DSR, RI e DCD). Estas linhas são
todas entradas, e podem ser lidas no DTE ou no DCE como níveis lógicos um ("1")
ou zero ("0"). Já os bits de 0 a 3 registram se houve mudanças de estado nas linhas:
CTS, DSR, RI e DCD, desde o último acesso ao registrador MSR.
Registrador MSR - (leitura e escrita)

Delta Clear to 0 Nenhuma mudança no CTS.
0 Send 1 Houve mudança no CTS desde a última leitura no MSR.
(DCTS)
Delta Data Set 0 Nenhuma mudança no DSR.
1 Ready 1 Houve mudança no DSR desde a última leitura no MSR.
(DDSR)
Trailing Edge Ring 0 Nenhuma mudança no RI.
2
Indicator (TERI) 1 Houve mudança no RI desde a última leitura no MSR.
Delta Data Carrier 0 Nenhuma mudança no CTS.
3
Detect (DDCD) 1 Houve mudança no CTS desde a última leitura no MSR.
0 O Modem não está pronto para receber dados do
4 CTS 1 computador.
O Modem está pronto para receber dados do computador
0 O Modem não está preparado.
5 DSR
1 O Modem está preparado.
0 Nenhum sinal de ring detectado.
6 RI
1 Sinal de ring detectado.
0 Nenhum sinal de portadora detectado.
7 DCD
1 Sinal de portadora detectado.
Passos iniciais para configurar o UART, preparando-o para enviar e receber

dados
1 - Escolher a porta a ser utilizada: COM1=3F8h, COM2=2F8h...

2 - Escolher a velocidade de transmissão (bps): 9600, 4800, 19200...
3 - Calcular o valor do Divisor: 1.843.200/(bps*16);
4 - Ativar em "1" o bit 7 (DLAB) do registrador LCR;
5 - Escrever no registrador DLL o byte menos significativo (LSB) do Divisor;
6 - Escrever no registrador DLH o byte mais significativo (MSB) do Divisor;
7 - Configurar os bits de 1 a 6 do registrador LCR, para definir as
características da comunicação.
Pronto, após o UART ser configurado, é possível usar os demais registradores

para enviar e receber dados, obter o estado da linha e do Modem, entre outros.

Comentário
No desenvolvimento de programas de comunicação serial RS232 para o
sistema operacional Windows, não precisamos manipular bit-a-bit os registradores
do UART para criar um aplicativo, programaremos em nível de API do Windows,
onde há um conjunto de funções que podem ser usadas com facilidade, para passar
parâmetros de configuração ao UART, enviar e receber dados, ativar e desativar os
sinais de controle DTR e RTS, lê o estado dos sinais da linha e do Modem (CTS,
DSR, RI e DCD), entre outras.
Em compiladores como: C++Builder, Delphi, VisualBasic, entre outros, podem

ser instalados componentes de terceiros para facilitar ainda mais o desenvolvimento
de programas para acessar a porta serial.
Na próxima aula iremos aprender a usar a API do Windows para controlar a

porta serial.

Funções da API do windows para acessar a Porta Serial
Para acessar a Porta Serial iremos utilizar algumas funções da API (Application
Programming Interface) - Interface de programação de aplicativos do Windows, que
tornam nossos programas compatíveis com as versões 95/98/Me/NT/2000 e XP.
Nesta aula, exemplos do uso das funções e programas estão escritos tanto em
Delphi com C++Builder. Como as funções da API são padronizadas, os exemplos
escritos em C++ são muito semelhantes aos do Delphi.
Veja algumas das funções da API do Windows, usadas nos programas e

exemplos aqui apresentados, com o objetivo de acessar a Porta Serial.
Essas funções eliminam o trabalho árduo de se programar em níveis de bits, os
registradores do UART, tornando a programação muito mais fácil e produtiva.
São estas as funções que iremos explorar nesta aula:
CreateFile()
CloseHandle()
GetCommState()
SetCommState()
BuildCommDCB()
ReadFile()
WriteFile()
GetCommTimeouts()
SetCommTimeouts()
EscapeCommFunction()
SetCommBreak()
ClearCommBreak()
TransmitCommChar()
GetCommModemStatus()
CreateFile()
Utilizada para abrir a Porta Serial ou quaisquer outras. Veja abaixo, exemplos
em Delphi e C++Builder de como usar esta função.

Exemplo 1 C++ - Uso da função CreateFile() da API do windows
HANDLE hCom; // Handle para a Porta Serial (identificador).

char *NomePorta = "COM1"; //COM1, COM2...COM9 ou portas virtuais "\\.\COMx".
hCom = CreateFile(
NomePorta, //Nome da porta.
GENERIC_READ | GENERIC_WRITE, //Para leitura e escrita.
0, //(Zero) Nenhuma outra abertura será permitida.
NULL, //Atributos de segurança. (NULL) padrão.
OPEN_EXISTING, //Criação ou abertura.
0, //Entrada e saída sem overlapped.
NULL //Atributos e Flags. Deve ser NULL para COM.
);
if(hCom == INVALID_HANDLE_VALUE)
return false; //Erro ao tentar abrir a porta especificada.
else
return true;
Exemplo 1 DELPHI - Uso da função CreateFile() da API do windows

Var
hCom : THANDLE; // Handle para a Porta Serial (identificador).
NomePorta : String; // Nome da porta COM1, COM2....
Begin
NomePorta := 'COM1'; //COM1, COM2...COM9 ou portas virtuais.
hCom := CreateFile(
PChar(NomePorta), //Nome da porta (tipo caracteres).
GENERIC_READ or GENERIC_WRITE, //Para leitura e escrita.
0, //(Zero) Nenhuma outra abertura será permitida.
nil, //Atributos de segurança. (nil) padrão.
OPEN_EXISTING, //Criação ou abertura.
0, //(Zero) Entrada e saída sem overlapped.
0 //Atributos e Flags. Deve ser 0 para COM.
);
if hCom = INVALID_HANDLE_VALUE then

result := false //Erro ao tentar abrir a porta especificada.
else
result := true;
End;
A função CreateFile() da API do windows é responsável pela abertura da Porta

Serial. Ela aceita vários parâmetros, sendo o primeiro, o nome da porta "COM1",
"COM2", etc. O segundo especifica o tipo de acesso: leitura (GENERIC_READ),
escrita (GENERIC_WRITE) ou leitura e escrita (GENERIC_READ |
GENERIC_WRITE); o caracter "|" do C++ é idêntico ao operador (OR) do Delphi e
sua função no Exemplo 1 é combinar as duas constantes formando um novo valor. O
terceiro parâmetro especifica o compartilhamento, se for definido como 0 (zero), a
Porta não será compartilhada, ou seja, enquanto seu programa estiver usando a
Porta Serial nenhum outro poderá abri-la. Os outros parâmetros serão usados como
padrão.

hCom é uma variável do tipo HANDLE (identificador) que armazenará todas as

informações necessárias sobre o dispositivo aberto, no nosso caso, a Porta Serial.
Esta variável será utilizada como parâmetro para as funções que irão configurar,
alterar, lê e escrever na Porta Serial. Para facilitar a programação, a variável hCom
poderá ser declarada com Global.
Se houver algum tipo de erro na abertura da Porta Serial, a função CreateFile()

retornará um valor do tipo INVALID_HANDLE_VALUE para a variável hCom. Portanto, é
imprescindível que o programa teste a variável hCom para checar se houve erro,
antes de usar as demais funções de acesso a Porta Serial.
GetCommState() e SetCommState()
Essas duas funções são utilizadas para obter e alterar as configurações da Porta
Serial como: velocidade em que os dados são transmitidos, bit de dados, paridade,
bit de parada, etc.
Exemplo 2 C++ - Uso das funções GetCommState() e SetCommState()

DCB dcb; //Estrutura DCB é utilizada para definir todos os parâmetros da
comunicação.
if( !GetCommState(hCom, &dcb) ) // Obtém a configuração atual da Porta Serial.

return false; // Erro na leitura de DCB.
//Define novos parâmetros

dcb.BaudRate = CBR_19200;
dcb.ByteSize = 8;
dcb.Parity = NOPARITY;
dcb.StopBits = ONESTOPBIT;
//Define nova configuração.

if( SetCommState(hCom, &dcb) == 0 )
return false; //Erro ao tentar gravar configuração.
else
return true;

Exemplo 2 DELPHI - Uso das funções GetCommState() e SetCommState()

//Estrutura DCB é utilizada para definir todos os parâmetros da comunicação.
Var
dcb: TDCB;
Begin
if not GetCommState(hCom, dcb) then //Obtém a configuração atual da Porta
Serial.
result: false; //Erro na leitura de DCB.
//Define novos parâmetros

dcb.BaudRate := CBR_19200;
dcb.ByteSize := 8;
dcb.Parity := NOPARITY;
dcb.StopBits := ONESTOPBIT;

if not SetCommState(hCom, dcb) then
result:= false //Erro ao tentar gravar configuração.
else
result:= true;
End;
As funções GetCommState() e SetCommState() trabalham juntas e têem como

objetivos, obter as configurações atuais da Porta Serial encontradas na estrutura
DCB (Device Control Block), como também alterar seus atributos.
Para obter os parâmetros atuais armazenados no UART, utiliza-se a função

GetCommState(), que pega e grava esses parâmetros na estrutura/registro dcb. A
partir da leitura desta estrutura é possível saber o valor de cada parâmetro do UART
como: bps, bits de dados, paridade, stop bit, etc.
Para mudar as configurações atuais da Porta Serial, utiliza-se a função

SetCommState() conforme o Exemplo 2. A função BuildCommDCB() também pode
ser usada com a mesma finalidade.
A tabela abaixo mostra as constantes definidas pela API do windows, para

configurar as características de comunicação no UART.

Tabela 1 - Constantes e valores da API do Windows utilizadas para configurar a Porta Serial
BaudRate ByteSize Parity StopBits

Tamanho
Velocidade Paridade Bits de parada
dos dados
CBR_110 CBR_38400 5 EVENPARITY (par) ONESTOPBIT (1)
CBR_300 CBR_56000 6 MARKPARITY (marca) ONE5STOPBITS (1.5)
CBR_600 CBR_57600 7 NOPARITY (nenhuma) TWOSTOPBITS (2)
CBR_1200 CBR_115200 8 ODDPARITY (ímpar)
CBR_2400 CBR_128000
CBR_4800 CBR_256000
CBR_9600
CBR_14400
CBR_19200
BuildCommDCB()
Utilizada para preencher os campos da estrutura DCB com valores
especificados numa string de caracteres. O formato desta string deve ter esta
seqüência: bps, paridade, bits de dados e stop bits, como neste exemplo:
"19200,N,8,1". A letra 'N' significa dizer, sem paridade (No parity). Para configurar
outros parâmetros do UART, use a função SetCommState() em vez da
BuildCommDCB().
Exemplo 3 C++ - Uso da função BuildCommDCB()

DCB dcb; //Estrutura DCB é utilizada para definir todos os parâmetros da
comunicação.
if( !GetCommState(hCom, &dcb)) //Obtém a configuração atual.

return false; //// Erro na leitura de dcb.
BuildCommDCB("19200,N,8,1", &dcb); //Atribui os parâmetros à estrutura dcb.

if( SetCommState(hCom, &dcb) == 0 )
return false; //Erro ao tentar gravar configuração.
else
return true;

Exemplo 3 DELPHI - Uso da função BuildCommDCB()

//Estrutura DCB é utilizada para definir todos os parâmetros da comunicação.
Var
dcb: TDCB;
Begin
if not GetCommState(hCom, dcb) then //Obtém a configuração atual da Porta
Serial.
result: false; //Erro na leitura de DCB.
BuildCommDCB('19200,N,8,1', dcb); //Atribui novos valores à estrutura DCB.

if not SetCommState(hCom, dcb) then
result:= false //Erro ao tentar gravar configuração.
else
result:= true;
End;
No exemplo acima, a função BuildCommDCB() atribui a string "19200,N,8,1", para

determinados campos da estrutura/registro DCB.
GetCommTimeouts() e SetCommTimeouts()
Utilizadas para obter e alterar os parâmetros atuais dos Timeouts associados às
funções WriteFile() e ReadFile().
Exemplo 4 C++ - Uso da função GetCommTimeouts() e SetCommTimeouts()

COMMTIMEOUTS CommTimeouts;
if( GetCommTimeouts(hCom, &CommTimeouts) == 0 ) //Obtém os Timeouts

atuais.
return false; //se houve erro.
//Atribui novos valores.

CommTimeouts.ReadIntervalTimeout = 2;
CommTimeouts.ReadTotalTimeoutMultiplier = 0;
CommTimeouts.ReadTotalTimeoutConstant = 2;
CommTimeouts.WriteTotalTimeoutMultiplier = 5;
CommTimeouts.WriteTotalTimeoutConstant = 5;
if( SetCommTimeouts(hCom, &CommTimeouts) == 0 )

return false; //se houve erro.

Exemplo 4 DELPHI - Uso da função GetCommTimeouts() e SetCommTimeouts()

Var
CommTimeouts: TCOMMTIMEOUTS;
Begin
if not GetCommTimeouts(hCom, CommTimeouts) then //Obtém os Timeouts
atuais.
result:= false; //se houve erro.
//Atribui novos valores.

CommTimeouts.ReadIntervalTimeout := 2;
CommTimeouts.ReadTotalTimeoutMultiplier := 0;
CommTimeouts.ReadTotalTimeoutConstant := 2;
CommTimeouts.WriteTotalTimeoutMultiplier := 5;
CommTimeouts.WriteTotalTimeoutConstant := 5;
if not SetCommTimeouts(hCom, CommTimeouts) then //Configura Timeouts.

result:= false //se houve erro.
else
result:= true;
End;
As funções GetCommTimeouts() e SetCommTimeouts() trabalham juntas, e

têem como objetivos, obter e modificar as configurações atuais dos timeouts da
Porta Serial. Quaisquer mudanças nos valores dos atributos da estrutura
COMMTIMEOUTS afetarão consideravelmente os tempos de leitura e escrita na
Porta Serial. Os valores de tempos definidos no Exemplo 4 foram os mais
adequados para enviar e receber dados através das funlçoes WriteFile() e
ReadFile().
ReadFile()
Utilizada para lê dados através da Porta Serial. Para seu funcionamento, é
preciso que a função CreateFile() tenha retornado um identificador válido associado
com a Porta Serial especificada.
Exemplo 5 C++ - Uso da função ReadFile()

#define LEN_BUFFER 100; //Define o tamanho do buffer de recepção de dados..
DWORD BytesLidos = 0; //Para retornar a quantidade de bytes realmente lidos.

char BufferRecebe[LEN_BUFFER]; //Para armazenar a string a ser lida.
//Lê uma String da Porta Serial.
ReadFile( hCom, BufferRecebe, LEN_BUFFER, &BytesLidos, NULL );

Exemplo 5 DELPHI - Uso da função ReadFile()

Const
LEN_BUFFER = 100; //Tamanho do Buffer de recepção de dados.
Var
BytesLidos: DWORD; //Para retornar a quantidade de bytes realmente lidos.
BufferRecebe: array [0..LEN_BUFFER] of char; //Para armazenar a string a ser
lida.
Begin
//Lê uma String da Porta Serial.
ReadFile( hCom, BufferRecebe, LEN_BUFFER, BytesLidos, nil);
End;
É através da função ReadFile() que é feita a leitura dos dados que chegam na
Porta Serial. Esta função aceita 5 parâmetros, sendo o primeiro (hCom), o
identificador da Porta Serial retornado na abertura da mesma através da função
CreateFile(). O segundo é um buffer (BufferRecebe), ou seja, é um local temporário
na memória onde os dados lidos da Porta Serial serão armazenados. O terceiro
(LEN_BUFFER), informa à função ReadFile() qual o tamanho do buffer de dados
(BufferRecebe). O quarto (BytesLidos), é uma variável do tipo ponteiro longo, onde a
função ReadFile() armazenará a quantidade exata de bytes lidos. O quinto e último é
um ponteiro para uma estrutura "overlapped", no nosso caso não será utilizada,
portanto, definimos este parâmetro com (nulo).
A cada chamada à função ReadFile(), os dados lidos da Porta Serial são

armazenados na variável BufferRecebe, e a quantidade total de bytes são
armazenados na variável BytesLidos. Se ReadFile() retornar um valor igual a 0
(zero), isso indica um erro. Se após uma chamada à função ReadFile() a variável
BytesLidos for maior que zero (BytesLidos > 0), isso quer dizer que a Porta Serial
recebeu dados.
WriteFile()
Esta função é utilizada para enviar dados através da Porta Serial. Para seu
funcionamento é preciso que a função CreateFile() tenha retornado um identificador
(handle) válido, associado à Porta Serial especificada.
Exemplo 6 C++ - Uso da função WriteFile()

#define LEN_BUFFER 100; //Define o tamanho do buffer.
DWORD BytesEscritos=0; //Para retornar a quantidade de bytes realmente

escritos.
int TamaString; //Para calcular o tamanho da String.
char BufferEnvia[LEN_BUFFER]; //Para armazenar a string a ser enviada.
strcpy(BufferEnvia, "Curso USB/Serial"); //A tribui uma string à variável.
TamaString = strlen(BufferEnvia); //Calcula o tamanho da string a ser enviada.
WriteFile( hCom, BufferEnvia, TamaString, &BytesEscritos, NULL );

Exemplo 6 DELPHI - Uso da função WriteFile()

Var
BytesEscritos: DWORD; //Para retornar a quantidade de bytes realmente escritos.
TamaString: integer; //Para calcular o tamanho da String.
BufferEnvia: AnsiString; //Para armazenar a string a ser enviada.
BufferEnvia := 'Curso USB/Serial'; //A tribui uma string à variável.
TamaString := Length(BufferEnvia); //Obtém o tamanho da string a ser enviada.
WriteFile( hCom, PChar(BufferEnvia)^, TamaString, BytesEscritos, nil);
É através da função WriteFile() que nossos programas enviam dados pela Porta
Serial. Esta função aceita 5 parâmetros, sendo o primeiro (hCom) o identificador da
Porta Serial retornado na abertura da mesma através da função CreateFile(). O
segundo é um buffer de dados (BufferEnvia), ou seja, é um local na memória onde
deverá está armazenados os dados a serem enviados para a Porta Serial. O terceiro
(TamaString) informa à função WriteFile(), qual o tamanho do buffer de dados
(BufferEnvia). O quarto (BytesEscritos), é uma variável do tipo ponteiro longo, onde
a função WriteFile() retorna a quantidade exata de bytes escritos. O quinto e último é
um ponteiro para uma estrutura "overlapped", no nosso caso não será utilizada,
portanto, definimos este parâmetro com (nulo).
A cada chamada à função WriteFile(), os dados armazenados no buffer

(BufferEnvia) são enviados para a Porta Serial. Se ocorrer um erro após a chamada
da função WriteFile(), é retornado um 0 (zero).
Obs.: As funções ReadFile() e WriteFile() devem ser chamadas a partir de

Threads (linhas de execução ou processos que rodam paralelo ao programa).
Assim, obtém-se uma boa performance em programas que trabalham com a Porta
Serial. Em breve, na seção de projetos iremos aprender a usar Threads.
CloseHandle()
Esta função é utilizada para fechar a Porta Serial, aberta pela função
CreateFile().
Exemplo 7 C++ e DELPHI - Uso da função CloseHandle()

CloseHandle( hCom ); //Fecha a porta aberta anteriormente por
CreateFile().
A função CloseHandle() fecha a Porta Serial aberta pela função CreateFile(),

disponibilizando-a para que outros programas possam acessá-la, abri-la.

EscapeCommFunction()
EscapeCommFunction() deve ser usada se um programa deseja controlar o

fluxo diretamente. Ou seja, controlar as linhas DTR e RTS. Através desta função
também é possível gerar e limpar um sinal de Break na linha TXD. Use como
parâmetro a constante SETBREAK para gerar um sinal de Break; CLRBREAK para
limpar um sinal de Break; SETDTR para ativar a linha DTR; CLRDTR para desativar
a linha DTR. SETCTS para avivar a linha CTS, e CLRCTS para desativá-la.
Exemplo 8 C++ e DELPHI - Uso da função EscapeCommFunction()

EscapeCommFunction(hCom, SETBREAK); //Gera um sinal de Break na linha TXD.
EscapeCommFunction(hCom, CLRBREAK); //Limpa o sinal de Break na linha TXD.
//-------------------------------------------------------------------------------------------------------------------
EscapeCommFunction(hCom, SETDTR); //Liga a linha DTR.
EscapeCommFunction(hCom, CLRDTR); //Desliga a linha DTR.
//-------------------------------------------------------------------------------------------------------------------
EscapeCommFunction(hCom, SETCTS); //Liga a linha CTS.
EscapeCommFunction(hCom, CLRCTS); //Desliga a linha CTS.
A utilização da função EscapeCommFunction() para gerar (SETBREAK) e limpar

(CLRBREAK) um Break na linha TXD, pode ser substituída respectivamente pelas
funções SetCommBreak() e ClearCommBreak().
SetCommBreak() e ClearCommBreak()
Através dessas duas funções é possível gerar e limpar um sinal de Break na

linha TXD. Um Break é um sinal especial gerado fora do Frame, ou seja, é como se
um bit de start fosse mantido na linha por um intervalor maior que o tempo de um
caracter. Esse sinal altera o estado Marca (tensão positiva) da linha para Espaço
(tensão negativa), mantendo-a assim enquanto não for enviado um sinal para
retorná-la ao normal.
Exemplo 9 C++ - Uso das funções SetCommBreak() e ClearCommBreak()

SetCommBreak(hCom); //Gera um sinal de Break na linha TXD.
ClearCommBreak(hCom); //Limpa o sinal de Break na linha TXD.
Use SetCommBreak() para gerar um sinal de Break, e ClearCommBreak() para

limpá-lo.
TransmitCommChar()
Esta função e usada para transmitir um caracter através da linha TXD. Ela
coloca o caracter a ser transmitido a frente de quaisquer caracteres existentes no
buffer de transmissão. Se houver sucesso na transmissão, TransmitCommChar()

retorna um valor diferente de zero, caso contrário, retorna um valor igual a zero.
Ela é útil também para enviar caracter de interrupção de transmissão (como um
CTRL+C) diretamente para a porta serial.
Exemplo 10 C++ - Uso da função TransmitCommChar()

TransmitCommChar(hCom, 'A' ); //Transmite o caracter 'A' pela porta
Serial.
Exemplo 10 DELPHI - Uso da função TransmitCommChar()

TransmitCommChar(hCom, char('A') ); //Transmite o caracter 'A' pela
porta Serial.
GetCommModemStatus()
A função GetCommModemStatus() está associada ao registrador de estado do

Modem (MSR). Através dela podemos monitorar os estados das linhas de entrada:
DCD, DSR, CTS e RI.
Após uma chamada à função GetCommModemStatus(), o estado das linhas do

Modem fica disponível numa variável. Para verificar se uma determinada linha está
ligada, executa-se uma operação AND (E) em nível de bits nesta variável.
Veja abaixo as constantes definidas na API do windows:
Tabela 2 - Constantes usadas para testar o estado das linhas do Modem

Valor em
Constante Descrição
decimal
MS_CTS_ON 16 Usado para testar se o CTS está ligado.
MS_DSR_ON 32 Usado para testar se o DSR está ligado.
MS_RING_ON 64 Usado para testar se o RI está ligado.
MS_RLSD_ON 128 Usado para testar se o DCD está ligado.

Exemplo 11 C++ - Uso da função GetCommModemStatus()

DWORD COMStatus; //Status do Modem (API).
GetCommModemStatus(hCom, &COMStatus); //Obtém estado da linha.

//----------------------------------------------------------------------------------------------
if(COMStatus & MS_RLSD_ON) //Se DCD está ligado.
//DCD Ligado.
else
//DCD desligado.
//-------------------------------------------------------------------------------------------
if(COMStatus & MS_DSR_ON) //Se DSR está ligado.
//DSR ligado.
else
//DSR desligado.
//-------------------------------------------------------------------------------------------
if(COMStatus & MS_CTS_ON) //Se CTS está ligado.
//CTS ligado.
else
//CTS desligado.
//-------------------------------------------------------------------------------------------
if(COMStatus & MS_RING_ON) then //Se RI está ligado.
//RI ligado.
else
//RI desligado.
Exemplo 11 DELPHI - Uso da função GetCommModemStatus()

Var
COMStatus: DWORD; //Status do Modem (API).
Begin
GetCommModemStatus(hCom, COMStatus); //Obtém estado da linha.
//----------------------------------------------------------------------------------------------
if(COMStatus and MS_RLSD_ON) = MS_RLSD_ON then //Se DCD está ligado.
//DCD Ligado.
else
//DCD desligado.
//-------------------------------------------------------------------------------------------
if(COMStatus and MS_DSR_ON) = MS_DSR_ON then //Se DSR está ligado.
//DSR ligado.
else
//DSR desligado.
//-------------------------------------------------------------------------------------------
if(COMStatus and MS_CTS_ON) = MS_CTS_ON then //Se CTS está ligado.
//CTS ligado.
else
//CTS desligado.
//-------------------------------------------------------------------------------------------
if(COMStatus and MS_RING_ON) = MS_RING_ON then //Se RI está ligado.
//RI ligado.
else
//RI desligado.
end;

Interface para testar as linhas do Modem
Para colocarmos em prática a maioria das funções aqui apresentadas, foi

desenvolvido um programa para controlar as linhas: DTR, RTS, TXD, DCD, DSR,
CTS e um circuito auto-alimentado pela porta serial, que mostrar o estado das linhas
através de LEDs. Também é possível enviar sinais para a porta serial através dos
botões liga/desliga.
O programa explora o uso das seguintes funções: CreateFile(),

GetCommModemStatus(), EscapeCommFunction(), CloseHandle(),
GetCommState(), SetCommState() e GetLastError().
Figura 1 - Circuito auto-alimentado para testar os sinais de status da RS232
No circuito acima o LED TXD vermelho é aceso quando um SETBREAK é

enviado pelo programa. Assim, a tensão da linha TXD fica positiva "+" (estado
Space). Quando o programa envia um CLRBREAK, o LED TXD verde acende, e a
linha é levada ao estado Mark "-" (tensão negativa).
Os LEDs DTR e RTS são controlados respectivamente pelas linhas DTR e RTS.
Já para enviar sinais para as linhas DCD, DSR, CTS e RI é preciso ativar a linha
TXD (enviando um SETBREAK), para que a mesma fique positiva (+), e possa
alimentar qualquer uma das entradas quando um dos botões for pressionado.

Figura 2 - Tela do programa para testar os sinais do Modem
Clique aqui para fazer download do programa EXE e dos fontes em DELPHI;
Clique aqui para fazer download do programa EXE e dos fontes em

C++BUILDER.
O programa abaixo acessa os registros do windows para descobrir quais os

nomes das portas seriais estão instaladas no sistema. Os nomes das portas estão
armazenados na chave:
HKEY_LOCAL_MACHINE —> HARDWARE\\DEVICEMAP\\SERIALCOMM
Figura 3 - Tela do programa para lê as portas instaladas no windows
Clique aqui para fazer download do programa EXE e dos fontes em DELPHI;
Clique aqui para fazer download do programa EXE e dos fontes em

C++BUILDER.

Convertendo sinais padrão RS232 em TTL
Interface foto-acoplada usando o CI 4N25
Para interfacear a porta RS232 de um PC com um dispositivo microcontrolado, é

preciso converter os sinais RS232 em TTL. É possível fazer isso através de
transistores, resistores ou foto-acopladores, mas a velocidade de transmissão fica
comprometida.
A interface mostrada na Figura 1 isola totalmente o PC, do dispositivo, através

de foto-acopladores. Uma interface foto-acoplada pode ser útil quando for preciso
isolar dispositivos que trabalhem em alta tensão ligado à Rede elétrica; conectado à
linha telefônica ou quaisquer outros que possam danificar o PC.
Figura 4 - Interface RS232 foto-acoplada com o CI 4N25
No circuito acima, a parte ligada ao PC é auto-alimentada pela RS232 (PC-

DB9F). Já no outro lado do circuito (pinos 1 e 2; 5 e 4 dos 4N25 são alimentados
com 5v da mesma fonte que será alimentado o dispositivo.
Interface usando o driver MAX232
O Max232 é um pequeno circuito integrado capaz de converter os níveis de

tensão positiva e negativa de uma porta RS232, em sinais TTL (0v e 5v). Ele
necessita de quatro capacitores eletrolíticos num arranjo externo para gerar as
tensões positivas e negativas, necessárias para o seu funcionamento.
Numa interface do tipo Null-modem, utiliza-se somente os pinos 13-->12 e 14<--

11 do Max232. Se a pretensão for criar uma interface que use controle de fluxo por
hardware, além dos pinos de dados, utiliza-se também os pinos: 8--->9 e 7<---10 do
Max232.

Figura 5 - Pinagem e configuração do circuito integrado MAX232
Figura 6 - Interface para converter níveis de sinais RS232 em TTL
A interface da figura acima pode ser usada para conectar um PC a um circuito

microcontrolado, alimentado com 5v.
Para o Max232A os valores dos capacitores são todos de 0.1uF / 50v. Para
qualquer outra versão do Max232, use capacitores com valores de 1uF / 50v.

Trabalhando com o microcontrolador PIC 16F877
A partir desta aula irei dar informações importantes sobre as ferramentas

necessárias para se programar um microcontrolador PIC 16F877. O objetivo aqui
não é ensinar sobre os detalhes dos microcontroladores, pois seria necessário
escrever um outro módulo para falar sobre o assunto. O que irei ensinar são noções
básicas sobre as ferramentas necessárias para se programar e gravar um
microcontrolador PIC, usando a linguagem C.
A linguagem nativa de programação de microcontroladores é o Assembly, pois

seus comandos de programação estão associados diretamente a endereços de
memória e registradores do microcontrolador. Por esse motivo, um programa escrito
em Assembly será compacto e, assim, será executado mais rapidamente. Há
algumas desvantagens em se programar todo um código em Assembly, como a
demora na programação (pois, temos que programar endereço por endereço de
memória), dificuldade em se dar manutenção no código futuramente, pois a
programação é baseada em saltos GOTOs, as rotinas ficam todas "amarradas"; não
é um código portável (por exemplo, se for preciso migrar para um outro modelo de
microcontrolador, é preciso criar um novo programa a partir do zero, pois a maioria
das rotinas estão associadas a endereços físicos de memória,do modelo do
microcontrolador anterior.
Antigamente os microcontrolaores tinham pouco espaço de memória para

armazenar programas e, portanto, era necessário economizá-la ao máximo, para
que se pudesse armazenar o código do programa. Nessa condição o compilador
Assembler era de suma importância para gerar um código pequeno. Mas, com a
evolução da microeletrônica, hoje em dia, os microcontroladores dispõem de uma
quantidade muito maior de memória de programa. Agora, com os microcontroladores
podendo armazenar mais códigos de programa, é muito mais produtivo e seguro,
programar usando uma linguagem de alto nível como o C, que é portável, rápida,
compacta e eficiente, sem falar na facilidade em se dar manutenção no código
futuramente.
O Assembly nunca deve ser desprezado, pois, quando necessitarmos de uma

rotina que precise de toda a velocidade que o hardware dispõe para melhorar a
eficiência de uma rotina, poderemos criar esta em Assembly e chamá-la a partir da
linguagem C.
Para o desenvolvimento de nossos projetos iremos usar o PIC 16F877, pois

este tem 33 I/O (entradas/saídas), e vários periféricos como: USART, EEPROM,
Timers, PWM, A/Ds, PSP, comunicação síncrona e assíncrona. Assim, poderemos
controlar relês, LEDs, sensores A/C, comunicação serial, I2C, Paralela, etc., usando
um único modelo de microcontrolador para desenvolvermos todos os projetos
propostos neste curso. Quem desejar poderá criar os projetos usando outros
microcontroladores e compiladores disponíveis no mercado.

Neste tópico do curso iremos usar as seguintes ferramentas para programar o

microcontrolador PIC 16F877:
O ambiente MPLAB IDE da Microchip versão 7.21 ou superior;

O compilador PCW C Compiler IDE da CCS versão Trial 30 dias;
Uma gravador serial que dê suporte ao PIC 16F877 e grave a partir
do MPLAB (PICStart Plus).
Obs.: Os programas dessa aula foram gravados no PIC 16F877, usando o gravador
McFlash da Mosaico (www.mosaico-eng.com.br).
Antes de começarmos a programar, vamos conhecer algumas características do

microcontrolador PIC 16F877, como, as portas disponíveis, o nome e o número de
cada pino, o tamanho da memória de programa entre outras.
Quem deseja se aprofundar na programação de microcontroladores PIC usando

a linguagem C, pode aprender muito através do livro "Microcontroladores PIC -
Programação em C" escrito pelo autor Fábio Pereira - Editora Érica. Todos os
programas exemplos desse livro foram escritos com base nos compiladores da CCS,
onde há uma biblioteca de funções para facilitar a programação.
Nesta aula são apresentados vários circuitos exemplos e seus respectivos

programas fonte. Já na próxima aula iremos aprender a usar o compilador da CCS e
o MPLAB para efetuar a gravação no PIC 16F877.
Características básicas do PIC 16F877:
- 33 pinos de I/O;
- 8k de memória de programa FLASH;
- 368 bytes de memória RAM;
- 256 bytes de memória EEPROM;
- Velocidade máxima de trabalho 20Mhz;
- Watchdog timer (WDT);
- 3 Timers;
- 8 canais A/D de 10 bits;
- 1 USART síncrona/assíncrona;
- Porta Paralela escrava (PSP);
- Porta serial síncrona SSP, SPI e I2C;
Entre outras.

Figura 1 - Pinagem do PIC 16F877
A figura acima mostra todos os pinos do PIC 16F877, com seus respectivos
nomes/funções. Os pinos (RA0 a RA5) estão associados a porta 'A'. (RE0, RE1 e
RE2) a porta "E". (RC0 a RC7) a porta "C". (RD0 a RD7) a porta "D". E por último, os
pinos (RB0 a RB7) associados a porta "B". Cada um destes pinos pode ser usado
como entrada ou saída e são definidos na programação. Observe que a maioria dos
pinos teem mais de uma função. Como exemplo veja o pino 10 que teem as funções
de entrada/saída digital (RE2) e de selecionar um chip SPI (CS); ou a função de um
canal A/D (AN7).
Figura 2 - Simples diagrama interno do PIC16F877
Como um simples exemplo didático da estrutura interna do microcontrolador PIC

16F877, é possível observar na figura acima, que ele é composto de vários módulos
como: uma unidade lógica e de controle, memórias RAM e ROM, Portas de entradas
e saídas e também vários periféricos de grande utilidade para a implementação de
muitos projetos interessantes. Grosso modo, um microcontrolador tem várias

características de um microcomputador. Sendo assim, em alguns projetos, não

necessitamos de um computador para executar determinadas funções, pois o
microcontrolador dispõe do que é preciso para o projeto funcionar.
Se desejarmos obter uma informação processada pelo microcontrolador de

forma visual, poderemos conectar a ele um display LCD, LEDS ou mesmo conectar
a um microcomputador através de uma de suas portas: Serial, Paralela, USB etc.
Descrição de algumas funções do compilador CCS usadas aqui em nossos

exemplos:
Função set_timer0()
Altera o conteúdo interno do timer0. Esta função aceita como parâmetro uma
variável ou uma constante de 8 bits.
Exemplo:
set_timer0(131); //inicializa o valor do timer0 em 131.
Função get_timer0()
Obtém o valor interno do timer0. Ela retorna um valor de 8 bits.
Exemplo:
int8 valor;
valor = get_timer0();
Função set_tris_d()
Escrita e leitura na porta D. Ou seja, define se um ou vários pinos são entradas ou
saídas na porta D.
Um bit '1' indica que o respectivo pino associado a uma porta será usado como
entrada (Input). E um bit '0', saída (Output). O parâmetro pode ser passado à função
set_tris_d() também no sistema de numeração binário usando a constante 0b.
Exemplo:
set_tris_d(0b01000001); //Os pinos RD6 e RD0 são definidos como entradas e os demais como
saídas.
ou em hexadecimal:
set_tris_d(0x41);
Função setup_timer_0()
Configura o prescaler do timer0. O parâmetro passado é uma constante
predeterminada usada para dividir o sinal de contagem por um prescaler (divisor de
freqüência).
Exemplo:
setup_timer_0(RTCC_INTERNAL | RTCC_DIV_64); //Informa que o timer0() usa
interrupção interna, e que a freqüência é dividida por 64 (prescaler).
Função enable_interrupts()
Usada para habilitar uma interrupção.
Exemplos:
enable_interrupts( GLOBAL ); //Habilita o sistema de interrupção geral.

enable_interrupts( int_timer0 ); //Habilita interrupção do timer0().

enable_interrupts( int_rda ); //Habilita interrupção para leitura de caracter pela USART.
ou
enable_interrupts(GLOBAL | int_timer0 | int_rda); //Ou todas através do operador OR ' |'.
Função input()
Lê o estado de um pino de uma determinada porta.
Exemplo:
boolean estado;
estado = input(pin_d2); //Lê o estado do pino RD2 da porta D.
Se o valor da variável estado for '0' (false), isso indica que o nível lógico do pino RD2
é baixo (low). Se for '1' (true), o nível lógico no pino RD2 é alto (high).
Função output_bit()
Liga ou desliga um determinado pino.
Essa função aceita dois parâmetros: o primeiro é o pino e o segundo é se ele será
ligado ou desligado.
Exemplos:
output_bit(pin_d0, 1); //Põe pino RD0 em nível alto (high). Pode-se usar a constante true em
vez de '1'.
output_bit(pin_d0, 0); //Põe pino RD0 em nível baixo (low). Pode-se usar a constante false em
vez de ' 0'.
Função output_high()
Liga (põe em nível alto) um determinado pino.
Exemplos:
output_high(pin_d2); //Põe o pino RD2 da porta D em nível Alto.
É o mesmo que usar:
output_bit(pin_d2, true);
Função output_low()
Desiga (põe em nível baixo) um determinado pino.
Exemplos:
output_low(pin_d2); //Põe o pino RD2 da porta D em nível Baixo.
É o mesmo que usar:
output_bit(pin_d2, false);
Função delay_ms()
Retarda o processamento do programa em milisegundos.
Exemplos:
delay_ms(15); //Aguarda 15 milisegundos.
delay_ms(1000); //Aguarda 1 segundo.
Função getc()
Aguarda e chegada de um caracter na porta serial (USART).
Exemplo:
char valor;
valor = getch(); //Espera a chegada de um caracter na Serial e armazena-o na variável valor.

Função printf()
Envia um ou mais caracteres formatados, pela porta serial (USART). Usa os
mesmos caracteres padrão de formatação da função printf() ANSI.
Exemplos:
printf("Curso USB/Serial.\r\n"); //Envia uma sting constante.
printf("%d", 85); //Envia um número decimal.
int valor = 0x3F;

printf("%X", valor); //Envia um número hexadecimal.
char *texto = "Teste de transmissão.\r\n";

printf("%s", texto); //Envia uma string a partir de uma variável
Diretivas
#int_rda
Usada para definir uma função de interrupção para leitura dos caracteres que
chegam no buffer da porta serial.
#include <16F877.h>
inclui o arquivo cabeçalho usado para se trabalhar com o PIC 16F877. Esse arquivo
contém várias constantes e definições úteis.
#use delay(clock=4000000)
Define o valor do relógio do PIC. Este valor tem que ser idêntico ao da freqüência do
cristal ou resonador externo. Para usar as funções delay_us(), delay_ms(),
delay_cycles() é necessário definir #use delay().
#fuses XT, PUT, NOWDT, NOBROWNOUT, NOLVP

Esta diretiva define quais fusíveis interno do PIC são configurados. Os parâmetros
são armazenados no arquivo .HEX e são usados somente na hora da gravação.
Veja o significado de alguns fusíveis:
Tipo de osciladores:
LP - Low Power (oscilador < 200Khz);

RC - Oscilador Resistor/Capacitor;
XT - Oscilador a cristal <= 4Mhz;
HS - High Speed (alta velocidade) > 4Mhz.
Outros fusíveis:
PUT ---> (Power Up Timer). Temporizador de power up ligado;

NOPUT ---> (No Power Up Timer). Temporizador de power up desligado;

WDT ---> (Watch Dog Timer) habilitado. O programa é resetado se por algum
motivo, travar;
NOWDT ---> (No Watch Dog Timer) desabilitado. Se travar, o programa não é
resetado;
BROWNOUT ---> Reset por queda de tensão habilitado. Sempre que a alimentação
cai a um valor mínimo;
NOBROWNOUT ---> Reset por queda de tensão desabilitado. O PIC não é
resetado;
LVP ---> Programação em baixa tensão habilitada;
NOLVP ---> Programação em baixa tensão desabilitada;
PROTECT ---> Protege todo o código do programa contra leitura;
NOPROTECT ---> Desabilita a proteção do código do programa contra leitura.
Obs.: Nem todos os modelos de PIC aceitam todas as constantes de fusíveis.
#use rs232(BAUD=9600, PARITY=N, BITS=8, XMIT=pin_c6, RCV=pin_c7)

Configura os parâmetros da comunicação serial.
BAUD ---> Velocidade da transmissão (depende da freqüência do cristal).

PARITY ---> Paridade (N=nenhuma, E=par, O=ímpar);
BITS ---> Bits de dados (5, 6, 7, 8 ou 9);
XMIT ---> Especifica o pino que irá transmitir os dados ( no 16F877 o pin_c6 é fixo
usando o USART);
RCV ---> Especifica o pino que irá receber os dados ( no 16F877 o pin_c7 é fixo
usando o USART);
Obs.: É possível escolher outros pinos para XMIT e RCV, porém, todo o processo
de transmissão e recepção de dados ficará por conta do software.
Definindo a direção dos pinos de I/O
No PIC, os pinos de I/O podem ser definidos tanto como entradas como saídas,
sendo assim, através de um único pino, podemos envia ou receber um sinal, para
isso, é preciso definir a direção do pino através da função set_tris_X(). No nosso
exemplo abaixo estamos usando a porta D. Se desejarmos definir todos os pinos da
porta D como entradas, usamos a função set_tris_d(0b11111111). Para definirmos
todos os pinos da porta D como saídas, usamos set_tris_d(0b00000000) com todos
os bits zeros. Os bits estão associados aos pinos (RD7 a RD0) da direita para a
esquerda, ou seja, bit mais significativo igual a RD7, e menos significativo igual a
RD0.

Figura 3 - Direção dos pinos da porta D
Exemplos de circuitos e programação usando o PIC16F877
Para assimilarmos mais conhecimentos sobre o PIC 16F877, vamos praticar

através do desenvolvimento de pequenos circuitos, para ligar/desligar LEDs e lê
botões. Isso é suficiente para quem nunca programou um microcontrolador, para
levar adiante um estudo mais abrangente e preciso sobre o assunto.
Um bom conhecimento da linguagem C ou do Assembly é de suma importância

para o desenvolvimento de projetos eficientes e seguros. Mas tudo precisa de um
começo. Aproveite, pois o começo é agora.
Figura 4 - Circuito para piscar um LED
O circuito acima esquematiza a configuração básica para fazer o PIC 16F877

funcionar eletricamente. Os capacitores C1 e C2 podem assumir valores entre 15 a
33pF e são usados em paralelo com o cristal de 4Mhz para estabilizá-lo. O pino 1
ligado ao +5v da fonte de alimentação através do resistor de 1K é usado para
resetar o PIC.
O LED1 conectado ao pino 21 (RD2) será controlado pelo programa mostrado

no Fonte 1 logo abaixo:

Fonte 1 CCS Compiler - faz o LED da figura 4 piscar (uso de loop while() e delay_ms())
#include <16F877.h>
void main(void)
{
set_tris_d(0b00000000); //Todos os pinos da porta 'D' como saídas.
while( true ) //Loop infinito.

{
output_high(pin_d2); //Liga LED.
delay_ms(1000); //espera 1 segundo.
output_low(pin_d2); //Desliga LED.
}
}
O programa Fonte 1 acima deve ser compilado e gravado no PIC 16F877 para
controlar o circuito da Figura 4, fazendo com que o LED1 pisque em intervalos de 1
segundo.
A função set_tris_d(0b00000000); define todos os pinos da porta D como

saídas. A função output_high(pin_d2) liga o LED1, e output_low(pin_d2) desliga-o.
Delay_ms(1000) mantém o LED1 aceso ou apagado por 1 segundo. While() entra
num loop infinito para manter o programa em execução.
Fonte 2 - CCS Compiler - faz o LED da figura 4 piscar (uso do Timer0)

#include <16F877.h>
#int_timer0
void MeuTimerPiscaLED()
{
static boolean PiscaLed; //para piscar o led.
static int contador; //para contar o tempo de 1 segundo.
set_timer0(131-get_timer0());
contador++;
if(contador == 125) //Se contou 125 (1 segundo).
{
contador=0; //zera contagem.
PiscaLed = !PiscaLed; //Inverte bit;
output_bit(pin_d0, PiscaLed); //Liga/desliga LED.
}
}
//----------------------------------------------------------------------
//Programa principal.
//----------------------------------------------------------------------
void main(void)
{
set_tris_d(0b00000000); //Todos os pinos da porta 'D' como saídas.
setup_timer_0(RTCC_INTERNAL | RTCC_DIV_64); //Define
prescaler.

set_timer0(131); //Inicializa timer0 com 0 valor 131.

enable_interrupts( global|int_timer0 ); //Habilita interrupções.
while( true ) //Loop infinito - aguarda interrupção acontecer.

{
//Aqui pode ser executado o fluxo normal do programa
//independente do Timer0.
}
}
O programa Fonte 2 acima faz o mesmo que o programa Fonte 1. A diferença é

que este usa o Timer0, para fazer o LED1 piscar independente do fluxo normal no
corpo do programa principal main(). Ou seja, é como se dois programas estivessem
sendo executados ao mesmo tempo. Quanto mais veloz for o cristal usado, melhor
será a performance da execução das instruções pelo PIC.
Os parâmetros das funções setup_timer_0() e set_timer0() definem o prescaler

e o valor que inicializa o Timer0. Os parâmetros da função enable_interrupts()
habilitam o sistema de interrupção geral e a interrupção do Timer0.
Figura 5 - Circuito para lê o estado de um botão e acender um LED
O circuito acima usa dois pinos do PIC: o pino 27 (RD4) é conectado ao botão
(interruptor K) e ligado a um resistor pull-up para manter a estabilidade do sinal de
entrada no pino. O pino 21 (RD2) é usado para controlar o acendimento do LED1.
Para comprovar o funcionamento do circuito, o botão (interruptor K) deverá ser

pressionado para que o LED1 acenda e, solto para que o mesmo se apague.

Fonte 3 - CCS Compiler - Programa para gravar o PIC e controlar o circuito da Figura 5
#include <16F877.h>
//---------------------------------------------------------------------------
//Programa Principal.
//---------------------------------------------------------------------------
void main(void)
{
boolean TravaPress = true; //Inicia variável para controle do botão.
set_tris_d(0b00010000); //somente o pino d4 da porta 'D' como entrada.

{
if( input(pin_d4) == 0) //Se leu '0' (zero) o botão foi pressionado.
{
if(TravaPress == true) //Para executar o código abaixo uma única vez.
{
TravaPress = false; //Nega a condição acima.
delay_ms(15); //bounce - retardo para eliminar ruído ao pressionar botão.
}
}else{ //Se o botão foi solto.
if(TravaPress == false) //Para executar o código abaixo uma única vez.
{
TravaPress = true; //Nega a condição acima.
}
}
}
}
O programa acima deve ser compilado para gravar o PIC 16F877 e controlar o
circuito da Figura 5. O funcionamento é simples: quando o botão (interruptor K) é
mantido pressionado, o LED1 permanece aceso. Quando o interruptor é solto o
LED1 é apagado.
Já o programa funciona assim: enquanto input(pin_d4) retorna o valor '0' (botão

pressionado) a variável TravaPress se torna false, e a função output_high(pin_d2)
liga o LED1. Mesmo que o botão permaneça pressionado as funções dentro do
corpo do if(TravaPress == true){ } não são mais processadas. Quando o botão
(interruptor K) for solto, a função input(pin_d4) retornará um valor '1' fazendo com
que as instruções dentro do corpo { } do 'else' sejam processadas, executando a
função output_low(pin_d2) desligando o LED1.

Figura 6 - Conectando o PIC 16F877 na porta RS232 do PC
O circuito acima é conectado à porta RS232 do computador por meio do driver

Max232. O LED1 é ligado ou desligado através do computador. O botão (interruptor
K) é usado para enviar uma string através da RS232 quando o mesmo é
pressionado ou solto.

Figura 7 - Conectando o PIC 16F877 no Bus USB através do FT232BM
O circuito da Figura 7 acima funciona da mesma forma que o circuito da Figura

6, com a única diferença de que este acima funciona conectado ao Bus USB,
através do circuito Bus powered da Aula 3 - Figura 5, que usa o chip FT232BM.
Fonte 4 - CCS Compiler - Programa para controlar os circuitos das Figuras 6 e 7.

#include <16F877.h>
#use rs232(BAUD=9600, parity=N, BITS=8, XMIT=pin_c6, RCV=pin_c7)
//---------------------------------------------------------------------------
//Interrupção de recebimento de caracter pela UART.
//---------------------------------------------------------------------------
#int_rda
void Serial_Detecta_Car()
{
char ch;
ch = getc(); //Pega o caracter no registrador da UART.
if( ch == 'l' ) //Se recebeu o caracter L.
{
}
if( ch == 'd' ) //Se recebeu o caracter D.
{
}
}
//---------------------------------------------------------------------------
//---------------------------------------------------------------------------

void main(void)
{
enable_interrupts(int_rda); //Habilita interrupção de recebimento.
enable_interrupts(GLOBAL); //Habilita registrador de interrupção.
set_tris_d(0b00000100); //somente o pino 2 da porta 'D' como entrada.

{
{
{
printf("Botão pressionado.\r\n"); //Envia para a porta rs232.
}
{
printf("Botão solto.\r\n"); //Envia para a porta rs232.
}
}
}
}
O programa acima funciona de forma semelhante ao do Fonte 3, mas com

algumas diferenças: o LED1 é aceso quando o caracter 'l'-ligado for enviado pelo
computador, tanto pela RS232 como pelo Bus USB. Esse LED é apagado quando
for enviado o caracter 'd'-desligado. A leitura desses caracteres é feita pela função
getc() que lê um caracter através do buffer do USART do PIC 16F877. Quando o
botão (interruptor K) for pressionado, a string "Botão pressionado.\r\n" é enviada ao
computador através do USART, pela função printf(). Quando for solto, é enviada a
string "Botão solto.\r\n".
Após a compilação, use o programa Fonte 4 para gravar o PIC16F877 nos

circuitos da Figura 6 e da Figura 7.
Na próxima aula iremos usar o MPLAB da Microchip ®, o compilador da CCS ®

e uma placa para gravar o PIC 16F877.

Instalando o CCS® C Compiler (versão Trial Evaluation 30 dias)
Nesta aula iremos aprender a gravar um programa escrito na linguagem C,

dentro de um microcontrolador PIC16F877 para que o mesmo possa controlar
nossos circuitos. Mas para isso é necessário termos em mãos as ferramentas
necessárias para que possamos executar esta tarefa. Uma dessas ferramentas é o
compilador, que converte o código escrito na linguagem C, num código de máquina
(seqüência lógica de endereços de memória e instruções internas próprias do
microcontrolador). Para essa tarefa iremos usar o compilador C da CCS (demo),
onde podemos usá-lo por 30 dias gratuitamente (funciona somente com os PICs:
16F877, PIC16C544 e 18F458 com no máximo 2K de código de programa). A
versão completa trabalha com muitos modelos de PIC, e explora toda a sua
capacidade de memória.
É possível editar o código fonte e compilar usando o ambiente IDE do próprio

compilador, só não há um recurso para a gravação do PIC.
Iremos usar o ambiente MPLAB® IDE da Microchip para editar o código fonte e
gravar o PIC. O MPLAB® chama automaticamente o compilador PCW da CSS para
compilar o código, desde que configuremos o mesmo adequadamente. Dessa forma
só precisamos de um único ambiente para: editar, compilar e gravar o PIC, tornando
mais fácil a tarefa de se programar um PIC.
Veja na figura abaixo o processo para se gravar o PIC16F877:
Figura 1 - Processo de edição, compilação e gravação do PIC 16F877
No MPLAB®, após a edição do código fonte, o processo de compilação e

gravação é automático. Após alguns clique do mouse, o PIC estará gravado e pronto
para ser inserido em nosso circuito.
Após o processo de compilação é gerado um arquivo com o mesmo nome do

arquivo fonte, mas com a extensão (.HEX) (arquivo compilado, próprio para ser
gravado no PIC pelo dispositivo gravador).

Figura 2 - Código Fonte (.C) Figura 3 - Código compilado (.HEX)

#include <16F877.h>
:1000000000308A00192800002230840000080319FB
#fuses XT, PUT, NOWDT, NOBROWNOUT, :1000100018280130F800F701F70B0C28F80B0B2813
NOLVP :100020004A30F700F70B122800000000800B092867
:10003000003484011F30830583161F149F141F157D
void main(void) :100040009F11003088000811831208150430A100A8
{ :10005000FA30A2000420A10B28288316081183126D
set_tris_d(0b00000000); //Todos saídas. :1000600008110430A100FA30A2000420A10B3328AB
while( true ) //Loop infinito. :0600700083162328630043
{ :02400E00313F40
output_high(pin_d2); //Liga LED. :00000001FF
delay_ms(1000); //espera 1 segundo. ;PIC16F877
}
}
Siga os passos abaixo para fazer download e instalar o compilador

PCWH da CCS
1 - Acesse o site da CCS em: www.ccsinfo.com;
2 - No menu da página da CCS selecione o item Compiler Information e depois

clique no item Free Demo;
3 - Após a abertura da página, preencha seu nome no campo Your Name, depois
clique no botão Download Demo. Salve o arquivo demoupd.exe em seu disco
rígido;
4 - Após o download, dê duplo clique no arquivo demoupd.exe para abrir o

programa de instalação. Siga as instruções nas telas do programa instalador.
Obs.: O compilador é instalado na pasta: \Arquivos de programas\PICC
Figura 4 - Tela do compilador PCW C da CCS

Para agregar o compilador PCW ao MPLAB, siga os próximos passo...
Obs.: Para que o MPLAB (versão 6 ou superior) consiga identificar o

compilador PCW, é necessário instalar um Plug-in (programa de recurso
auxiliar) no seu computador.
Siga os passos abaixo para fazer download e instalar o Plug-In
1 - Acesse novamente o site da CCS em: www.ccsinfo.com;
2 - No menu da página da CCS selecione o item Customer Download e depois

clique no item MPLAB 6.x Plugin-In;
3 - Após a abertura da página, vá até a seção MPLAB® Plug-In e clique no link

MPLAB® Plug-in. Salve o arquivo mplab-ccs-plugin-install.exe em seu disco
rígido;
4 - Após o download, dê duplo clique no arquivo mplab-ccs-plugin-install.exe para

abrir o programa de instalação. Siga as instruções nas telas do programa instalador.
Siga os passos abaixo para fazer download e instalar o MPLAB® IDE
Obs.: antes de instalar uma nova versão do ambiente MPLAB®, remova do sistema
quaisquer versões antigas do mesmo.
1 - Acesse o site da Microchip em: www.microchip.com; após a abertura da

página, clique no menu Products e depois no submenu Development;
2 - Na página da Microchip, clique no link: MPLAB® IDE e faça download da

versão completa MPLAB IDE v7.21 ou superior;
4 - Após o download, dê duplo clique no arquivo MP721_full.zip para abrir o

programa de instalação. Siga as instruções nas telas do programa instalador até
concluir.

Figura 5 - Tela inicial do programa de instalação do MPLAB® Tools
Para continuar a instalação clica-se no botão Next >...
Criando um novo projeto no MPLAB® IDE para o microcontrolador PIC16F877
Como exemplo de um novo projeto, faça download do Fonte1.zip (Aula 15).

Após o download, faça a descompactação do mesmo:
Figura 6 - Pasta Fonte1 após descompactação
1 - No Windows, clique em: Iniciar-->Programas-->Microchip-->MPLAB IDE

v7.21--> MPLAB IDE. Ao abrir o ambiente MPLAB, siga os próximos passos:
2 - Clique no menu Project do MPLAB v7.21;

Figura 7 - Ambiente MPLAB
Após clicar no menu Project será exibida a tela abaixo:
Figura 8 - Tela inicial do Wizard para instalar o MPLAB
Clique no botão Avançar > para passar para o próximo passo...
3 - No campo Device da próxima tela, selecione o modelo do PIC a ser usado no

projeto. No nosso caso selecione o PIC16F877;

Figura 9 - Seleção do modelo de PIC
4 - No campo Active Toolsuite da tela abaixo, selecione CCS C Compiler for

PIC12/14/16/18. No campo Toolsuite Contents selecione CCS C Compiler
(ccsc.exe]. Já no campo Location, clique no botão Browse... para localizar a pasta
PICC, selecionado em seguida o programa Ccsc.exe;

Figura 10 - Seleção do compilador da CCS
É preciso que o Plug-In tenha sido instalado para que apareça o nome do
compilador CCS nos campos 1 e 2.
Depois clique no botão Avançar > para passar para o próximo passo...
5 - Na próxima tela clique no botão Browse...

Figura 11 - Seleção da pasta onde serão gravados os arquivos do projeto
Após clicar no botão Browse... será exibida a tela abaixo para localizar a pasta
onde será gravado o novo projeto. No nosso caso iremos selecionar a pasta Fonte1,
aquela que foi criada anteriormente quando descompactamos o arquivo Fonte1.zip.
Figura 12 - Procurando a pasta
Clique no botão OK e depois no botão Avançar > para passar para o próximo
passo...

6 - Na próxima tela, selecione o arquivo Fonte1.c na pasta Fonte1. Depois clique

no botão Add >> para adicionar o arquivo fonte ao novo projeto;
Figura 13 - Adicionando um arquivo fonte ao projeto

Figura 14 - Tela de conclusão da criação do projeto
Clique no botão Concluir para finalizar a criação do projeto.
Figura 15 - Janela do MPLAB mostrando os arquivos do projeto e o editor de código fonte

A partir de agora o compilador PCW da CCS está agregado ao ambiente

MPLAB®, sendo possível compilar e gerar o arquivo Fonte1.hex. Na próxima aula
iremos configurar o MPLAB® para usar o gravador McFlash da Mosaico conectado
à porta serial para gravar o PIC 16F877.

Configurando o MPLAB® IDE e escolhendo uma placa para gravar o PIC16F877
Pronto, agora iremos configurar o MPLAB® para gravar o PIC16F877 através da

placa McFlash da Mosaico®. Esta placa grava uma grande variedade de modelos de
PICs das famílias 12F, 16F e 18F de 8 a 40 pinos (DIP). A McFlash é uma das
placas mais básicas do fabricante, mas bastante eficiente. Para mais informações
acesse o site www.mosaico-eng.com.br.
Tem gravadores que não usam o protocolo de comunicação da MPLAB®. Para

contornar isso, abra o arquivo compilado ".HEX" do seu projeto a parir do software
que acompanha o seu gravador de PIC. É possível até construir um gravador de PIC
básico a partir de informações disponíveis em alguns sites na Internet.
Para começar escolha um gravador que seja eficiente, prático e barato.
Siga os passos abaixo para configurar o MPLAB para gravar o PIC16F877
Conforme a Figura 1 abaixo:
1 - Abra o projeto ProFonte1.mcp da aula anterior, ou o faça novamente seguindo

àqueles passos;
2 - Para selecionar um padrão de programador no MPLAB®, clique no menu

Programmer--->Select Programmer e marque a opção 1 (PICSTART Plus);
Figura 1 - Escolhendo um programador no MPLAB
3 - Vamos agora selecionar uma porta serial COMx no MPLAB, onde o gravador
McFlash ou outro será conectado para transferir o arquivo ".HEX" para gravar o
PIC16F877. Para isso, clique no menu Programmer e depois no item Settings;

Figura 2 - Escolhendo uma porta de comunicação serial
4 - Ao abrir a tela abaixo, clique na guia Communications e selecione a porta serial

onde o gravador de PIC será conectado ao computador;
Figura 3 - Selecionando uma porta COMx
Clique no botão no botão OK para confirmar a seleção
5 - Para executar esse passo é necessário que um gravador de PIC esteja

conectado a COMx selecionada. Clique no menu Programmer e depois no item
Enable Programmer;

OBS.: Quando não há um gravador de PIC conectado na porta serial selecionada, é

exibida a seguinte mensagem:
"Cannot Transmit. Please verify connection and retry the

previous operation."
(Não é possível transmitir. Por favor, verifique a conexão e tente novamente)
Quando um gravador de PIC compatível com PICSTART Plus está conectado e

operando normalmente, é exibida a seguinte mensagem:
Figura 4 - Mensagem de sucesso quando um gravador compatível está conectado corretamente na

COMx
6 - Para compilar o programa Fonte1.c clique no menu Project e depois no item

Compile, ou simplesmente pressione a tecla F10;

Figura 5 - Tela mostrando o processo de compilação do PCM C Compiler
Obs.: Após o processo de compilação, na guia Build da janela Output, são exibidas
algumas mensagens, onde podemos observar se ouve erro ou sucesso na
compilação. Se houve erro, mensagens esclarecedoras são exibidas. Também é
informado o número da linha onde ocorreu o erro, assim fica mais fácil corrigi-lo.
Figura 6 - Botões na barra de ferramentas do MPLAB para comandar o gravador de PIC
Na figura abaixo estão em destaque os botões usados para comandar a placa

gravadora de PIC. Os comandos também podem ser acessados através do menu
Programmer.

Figura 7 - Descrição dos botões de comando do gravador de PIC
Veja abaixo algumas mensagens que são exibidas quando um dos botões
acima é pressionado.
Quando clicamos no botão Program

Mensagem: "Sucesso na gravação" - Programming/Verification completed
successfully!.
Quando clicamos no botão Blanck Check

Mensagem 1: "Há dados gravados no PIC" - Device is NOT blank.
Mensagem 2: "Não há dados gravados no PIC" - Device is blank.
7 - Para visualizar ou modificar os bits (fusíveis) do PIC, clique no menu Configure

e depois no item Configuration Bits...
As mudanças são atualizadas na janela Configuration Bits quando compilamos
o projeto.
Figura 8 - Configuração dos fusíveis do PIC

As configurações de bits mostradas na figura acima correspondem

respectivamente aos mesmos comandos da diretiva abaixo:
#fuses XT, NOWDT, PUT, NOBROWNOUT, NOLVP, NOWRT, NOCPD, NOPROTECT
Há vários recursos no MPLAB®, como: debugger, simulação de programas,

gravação da memória EEPROM interna, entre outros. Para mais informações faça
download da documentação do MPLAB®, no site da Microchip (www.microchip.com).

Testando os circuitos da Aula 15
Agora que aprendemos a usar as ferramentas básicas para trabalhar com o

PIC16F877, poderemos testar os exemplos da Aula 15. Para facilitar nossos testes
iremos usar o programa RcomSerial. A versão desse programa, disponível aqui para
download, suporta velocidades de até 921.600 pbs. Essa velocidade será
configurada quando formos testar os conversores RS485 e interfaces USB<=>USB
(laplink PC-PC).
Nesta aula, o programa RComSerial será usado simplesmente para testar os

exemplos. Nas aulas seguintes iremos desenvolver programas específicos para
cada projeto.
Para testar os circuitos das Figuras 6 e 7 da Aula 15, siga os passos

abaixo:
1 - Compile o código Fonte 4 da Aula 15 e grave-o no PIC16F877;
2 - Conecte um dos circuitos das Figuras 6 ou 7 da Aula 15 ao computador;
3 - Faça download do RComSerial clicando aqui;
4 - Após o download, descompacte o arquivo RComSerial.zip e rode o programa

RComSerial.exe, configurando-o conforme detalhes na Figura 1.
Obs.: Se o driver VCP ainda não foi instalado, ou não saiba qual a Porta COMx deve
ser configurada no RComSerial, retorne a Aula 8 para obter informações.

Figura 1 - Tela do RComSerial.exe para testar os circuitos das Figuas 6 e 7 / Aula 15
Após ter configurado o RComSerial conforme a Figura 1 acima, clique no botão

"Abrir Porta". Na janela "TX-Enviar Mensagem:" digite a letra 'l' para ligar o LED1 do
circuito, e 'd' para desligá-lo. No circuito, pressione o Interruptor K para enviar a
mensagem "Botão pressionado." à caixa "RX-Recebe Mensagem:" do RComSerial.
Ao soltar o Interruptor K, é enviada a mensagem "Botão solto.".
Projetos Práticos - Conversores
Através de uma interface bus-powered ou self-powered baseadas no chipset

USB FT232BM, é possível fazer vários tipos de interfaceamento. O objetivo do
chipset FT232BM é converter sinais USB em Serial (TTL). Se desejarmos criar um
conversor USB<==>RS232 para conectar dois PCs ou outro aparelho, temos que
criar um circuito usando um componente driver, que converta os sinais seriais (TTL),
em RS232. Da mesma forma que é possível converter os sinais seriais TTL em
RS232, é possível também converter em RS485, RS422, etc.
Vamos agora analisar alguns conversores RS232 e RS485:

Conversores RS232
O circuito da Figura 2 abaixo usa um driver MAX213CAI ou SP213EHCA para

converter os sinais seriais TTL do FT232BM em sinais seriais padrão RS232.
A diferença entre os dois está na velocidade. O SP213EHCA permite

velocidades de até 500k baud, enquanto que o MAX213CAI suporta no máximo
115.200 baud. Os dois são compatíveis pino a pino. Se a velocidade não for um fator
importante para o projeto, o MAX213CAI é uma alternativa mais em conta.
Observe que esses drivers disponibilizam todos os sinais de Handshaking (RTS,

CTS, DTR, DSR, DCD e RI), necessários para se projetar circuitos de Modem ou RF
modem, entre outros.
Figura 2 - Conversor USB<==>RS232 (Full) usando o MAX213CAI ou SP213EHCA
Se o objetivo não for o de criar circuitos de Modem que utilizam todos os sinais
de handshaking, é possível usar um simples MAX232 para converter os sinais TTL,
em sinais padrão RS232. O MAX232 pode operar numa velocidade de até 115.200
baud. Ele dispõe de dois sinais de handshaking (RTS e CTS), usados por algumas
interfaces seriais para controle de fluxo por hardware.

Figura 3 - Conversor USB<==>RS232 (Parcial) usando o MAX232
Conversores RS485
Interfaces USB e RS232 não foram projetadas para transmitir dados a longas
distâncias. O padrão RS232 estabelece um cabo em torno de 15m de distância entre
dois pontos. Quanto maior for a distância e a velocidade, mais suscetível a erros fica
a transmissão.
A distância de um cabo USB não pode passar dos 5m, distâncias maiores
tornam o sistema inviável. Para solucionar esse problema poderemos usar drivers
RS485 para transmitir dados a uma distância de até 1200m.
O Padrão RS485 estabelece apenas características elétricas. Usa somente 2

fios; trabalha em modo half-duplex; é multiponto (até 32 nós) e, voltagem diferencial.
A velocidade numa linha RS485 pode chegar até 10Mbps dependendo do driver
utilizado. É um padrão largamente usado em automação industrial por ser imune a
ruídos. A implementação do protocolo de comunicação fica por conta do usuário, o
padrão RS485 não especifica um. Sendo assim, uma interface RS485 de um
fabricante pode não "conversar" com a de um outro. A não ser que elas
implementem o mesmo protocolo.

Figura 4 - Circuito RS485
O esquema acima mostra um circuito RS485 ponto-a-ponto para transmissão de

dados a uma distância de até 1200m usando dois drivers MAX485. O CI MAX485
suporta até 2,5Mbps de velocidade.
O pino 2 do MAX485 é usando para habilitar a recepção de dados, já o pino 3 é

usado para habilitar a transmissão. Quando é aplicado um sinal em nível lógico
baixo (0) ao pino 2 (habilita receptor), a linha RX fica preparada para receber dados.
Quando um sinal em nível lógico alto (1) é aplicado ao pino 3 (habilita transmissor),
dados podem ser transmitidos pela linha TX. Como o padrão RS485 é half-duplex
(transmissão e recepção não ocorrem simultaneamente), é comum conectar o pino 2
com o pino 3 transformando-os em um único pino (te-transmite enable). Quando for
aplicado nível lógico 1 a linha (te), o transmissor (pino 3) habilita a linha TX, e o
receptor (pino 2) desabilita a linha RX.
No fim do cabo mais distante do circuito mestre, deve ser colocado um resistor
de terminação de 120 ohm, em paralelo com as duas linhas de dados TX/RX.
Figura 5 - Interface RS485 entre dois circuitos FT232BM
O circuito acima é um conversor USB/TTL<=>RS485<=>TTL/USB para se

transmitir dados entre dois Host USB (PC-PC). O FT232BM usa o pino 16-TXDEN
para habilitar a transmissão, sendo transparente para o software. Ou seja, quando
nosso programa transmite dados via FT232BM, este habilita (põe em nível alto 1) a
linha (te) automaticamente, habilitando a transmissão no CI RS485. Assim que for

finalizada a transmissão dos dados, o FT232BM põe o pino 16-TXDEN em nível

lógico 0, fazendo com que o MAX485 fique preparado para receber dados (linha "te"
em nível 0).
Para testar o circuito acima usando um único computador, faça assim: conecte
dois circuitos FT232BM e depois instale seus driveres VCP. Rode duas cópias do
RComSerial.exe e configure as duas com a mesma velocidade (460.800 baud). As
portas têem que ser diferentes (veja no Gerenciador de Dispositivos do Windows,
quais estão disponíveis após a instalação dos drivers VCP).
Figura 6 - Cópia (1) do programa RComSerial Figura 7 - Cópia (2) do programa RComSerial
Figura 8 - Interface RS485 entre o FT232BM e um PIC16F877-20/P
O esquema acima usa o padrão RS485 para transmitir dados a longas

distâncias entre um circuito baseado no chipset FT232BM e um microcontrolador
PIC16F877-20/P.
O PIC 16F877-20/P pode ser configurado para trabalhar com um driver do tipo
MAX485 como se fosse uma comunicação RS232. Para isso é preciso especificar

um parâmetro a mais na função #use rs232(). Esse parâmetro é o ENABLE, usado

para definir um pino para habilitar a transmissão numa linha RS485.
Veja abaixo como usá-lo na função:
#use delay(clock=20000000) //20Mhz.

#use rs232(BAUD=256000, parity=N, BITS=8, XMIT=pin_c6, RCV=pin_c7, ENABLE=pin_c5)
Obs. Usando um cristal de 20Mhz com o PIC16F877-20/P, é possível estabelecer

uma transmissão RS485 numa velocidade de até 256.000 bps.
Para testar o circuito da Figura 8, siga os passos abaixo:
1 - Confeccione o circuito da Figura 8 (bus-porwered ou self-powered),

substituindo o PIC16F877-20/P que consta no circuito B, pelo circuito da figura
abaixo, conectando-o à linha RS485 do mesmo circuito B:
Figura 9 - Esquema detalhado da configuração do PIC16F77-20/P do circuito B da Figura 8
2 - Compile e grave no PIC16F877-20/P, o programa abaixo:

Dowload do Programa 1.
Programa 1 - Código para gravar o PIC16F877-20/P

#include <16F877.h>
#use delay(clock=20000000) //20Mhz.
#fuses HS, PUT, NOWDT, NOBROWNOUT, NOLVP
#use rs232(BAUD=256000, parity=N, BITS=8, XMIT=pin_c6, RCV=pin_c7, ENABLE=PIN_c5)
//Comunicação RS485.
//---------------------------------------------------------------------------
//---------------------------------------------------------------------------
#int_rda
void Serial_Detecta_Car()
{
char ch;
if( ch == 'l' ) //Se recebeu o caracter L.
{
}
if( ch == 'd' ) //Se recebeu o caracter D.
{
}
}
//---------------------------------------------------------------------------
//---------------------------------------------------------------------------
void main(void)
{
set_tris_d(0b00000100); //somente o pino 2 da porta 'D' como entrada.

{
{
{
printf("Botão pressionado.\r\n"); //Transmite via rs485.
printf("Teste de transmissão RS485.\r\n");
printf("Curso USB/Serial ROGERCOM.\r\n");
printf("www.rogercom.com.\r\n\r\n");
}
{
printf("Botão solto.\r\n"); //Transmite via rs485.

printf("Transmissão USB<->RS485\r\n");
printf("Microcontrolador PIC16F877-20/P.\r\n");
printf("FT232BM.\r\n\r\n");
}
}
}
}
3 - Rode o RComSerial em seu computador e configure-o assim:
Porta: COM4 (verifique no Gerenciador de Dispositivos do Windows qual foi a porta criada pelo driver VCP);
Velocidade: 256000 baud;
Paridade: Nenhuma;
Bits de dados: 8.
Bits de parada: 1.
4 - Depois de configurado o RComSerial, clique no botão "Abrir Porta" para

estabelecer comunicação;
5 - Para transmitir dados para o RComSerial, pressione e solte o Interruptor K no

circuito.
Projetos Práticos - Interfaces foto-acopladas
As vezes é preciso isolar eletricamente dois circuitos, seja para protege-los ou

mesmo eliminar ruídos. Se você for projetar algum circuito para controle de
dispositivos via Rede telefônica, é preciso isolá-lo, pois os circuitos de altas
freqüências do computador geram um grande zumbido na Rede, inviabilizando
projetos do tipo URA (Unidade de Resposta Audível).
Nas próximas figuras são mostradas 3 interfaces foto-acopladas usando o

acoplador óptico 6N136. Este CI permite comutações de até 1Mbps de velocidade.
Os circuitos mostrados abaixo estão limitados a uma velocidade máxima de

128.000 bps. É possível também combinar estes circuitos numa linha RS485.

Figura 10 - Circuito TX/RX foto-acoplado
O circuito acima pode ser usado para isolar eletricamente qualquer interface
(USB/232TTL, RS232, RS485, entre outras) de uma maneira simples. É possível
também adicionar mais CIs 6N136 para permitir mais linhas como as de
handshaking da interface RS232 (RTS, CTS, DTR, DSR, DCD e RI).
Os terminais de "Entrada" do circuito acima são usados para conectar uma linha
TX, e os terminais de "Saída" para conectar uma linha RX.
Lembre-se que o circuito acima está limitado a uma velocidade máxima de

128.000 bps.
Figura 11 - Interface TX/RX foto-acoplada entre um circuito FT232BM e um PIC16F877

Figura 12 - Interface TX/RX foto-acoplada entre dois circuitos FT232BM
A partir da próxima aula começaremos a desenvolver alguns projetos práticos

para assimilarmos os ensinamentos passados no curso.

Programando através das funções da dll FTD2XX
Essa aula explora muita das funções da dll FTD2xx para acesso direto ao Bus
USB. A partir de suas funções é possível saber se um dispositivo FT232BM está
conectado ao bus USB; quantos estão; obter os descritores, como: nome do
fabricante, identificação do fabricante, número serial; enviar e receber dados; gravar,
lê e apagar a EEPROM para personalizar o dispositivo. Há também um conjunto de
funções usadas para manipular a área de memória EEPROM do usuário (espaço
restante da EEPROM usado pelo usuário para gravar algumas configurações do seu
circuito, se desejar). A função FT_EE_UASize( ) retorna o tamanho em bytes do espaço
livre do usuário. As funções que manipulam a área livre do usuário não interferem
nos dados armazenados no restante da EEPROM. Quanto menos caracteres
escrever na descrição do produto, maior será a área livre do usuário.
Há funções que abrem o dispositivo pelo seu número (0 para o primeiro

conectado, 1 para o segundo...), pelo Local ID, pela Descrição do Produto ou pelo
Número Serial do mesmo.
Há também funções para fazer o FT232BM trabalhar de forma paralela (8 pinos

de I/O) no modo Bit Bang. Dessa forma é possível controlar até 8 entradas ou saídas
sem a necessidade de usar um microcontrolador. A velocidade das entradas/saídas
pode ser configurada para trabalhar em alta velocidade.
A FTD2xx.DLL disponibiliza um conjunto de funções para se trabalhar com o

FT232BM, compatíveis com àquelas da API do Windows que dá acesso à Porta
Serial, mas próprias para controlar o FT232BM. Estas funções usam o pré-fixo
FT_W32 e estão detalhadas na guia de programação da FTDI: D2XXPG30.pdf.
Observação:
Para fazer os exemplos dessa aula é necessário ter montado um dispositivo

FT232BM configurado como Bus-powered ou Self-powered;
Se em seu computador estão instalados os drivers VCP, remova-os através
do Adicionar ou remover programas do Painel de Controle do Windows;
Baixe do site da FTDI os drivers FTD2xx mais atuais que encontrar, ou clique
aqui para baixar a partir do curso.
Conecte o dispositivo FT232BM numa Porta USB livre do PC. Siga
normalmente o processo de instalação.
Os exemplos estão escritos em C++Builder e Deplhi.
C++Builder:
Para compilar todos os exemplos em C++ usamos a biblioteca FTD2xx.LIB e o
arquivo cabeçalho FTD2xx.H. Se seu compilador C++ indicar uma incompatibilidade,
use o programa implib.exe que acompanha seu compilador para criar uma
FTD2xx.LIB a partir da FTD2xx.DLL; assim:

C:\Implib.exe FTD2xx.LIB FTD2xx.DLL
O comando acima cria o arquivo FTD2xx.LIB usado para compilar os exemplos em

C++
Delphi:
Em Delphi só precisamos adicionar o arquivo FTD2xxUnit.pas para compilar os
exemplos.
Não se preocupem, pois em cada pasta dos exemplos estão as bibliotecas

necessárias para a compilação.
Segue abaixo a descrição de cada função usada em nossos exemplos:
Funções Clássicas da FT2DXX
FT_ListDevices( )
Obtém informações atualmente relativa aos dispositivos conectados. Esta função devolve o número
de dispositivos conectados, a descrição, o número serial e o ID local dos dispositivos conectados.
FT_STATUS FT_ListDevices(PVOID pvArg1, PVOID pvArg2, DWORD dwFlags)
Parâmetros:
pvArg1 - Significando depende de dwFlags.
pvArg2 - Significando depende de dwFlags.
dwFlags - Determina o formato da informação retornada.
Retorna:
Um valor FT_OK se teve sucesso. Qualquer outro valor retornado indica que a função não teve êxito.
Em sua forma mais simples, pode ser usado para devolver o número de dispositivos conectados
atualmente. Se a constante de bit FT_LIST_NUMBER_ONLY é fixada em dwFlags, o parâmetro
pvArg1 é interpretado como um ponteiro do tipo DWORD para armazenar o número de dispositivos
atualmente conectados.
Pode ser usada para retornar informação do dispositivo. Se bit FT_OPEN_BY_SERIAL_NUMBER é

setado em dwFlags, será retornado uma string como o Número de Série; se bit
FT_OPEN_BY_DESCRIPTION é setado em dwFlags, será retornado uma string com a Descrição do
Produto; se FT_OPEN_BY_LOCATION é setado em dwFlags, o Local ID será retornado; se nenhum
destes bits for setados em dwFlags, por padrão, será retornado o número de Série do Dispositivo.
Pode ser usada para retornar informação string para um único dispositivo. Se FT_LIST_BY_INDEX e
FT_OPEN_BY_SERIAL_NUMBER ou FT_OPEN_BY_DESCRIPTION são setados em dwFlags, o
parâmetro pvArg1 é interpretado como o índice do dispositivo, e o parâmetro pvArg2 é interpretado
como um ponteiro para um buffer que contém uma string apropriada. Índices são iniciados em 0, e o
código de erro FT_DEVICE_NOT_FOUND é devolvido para um índice inválido.
Pode ser usada para retornar informação string de todos dispositivos conectados. Se FT_LIST_ALL e
FT_OPEN_BY_SERIAL_NUMBER ou FT_OPEN_BY_DESCRIPTION são setados em dwFlags, o
parâmetro pvArg1é interpretado como um ponteiro para uma array de ponteiros de buffers para conter
a string apropriada e, o parâmetro pvArg2 é interpretado como um ponteiro para uma variável do tipo

DWORD, onde é armazenado o número de dispositivos atualmente conectados. Note que para
pvArg1, a última entrada na ordem de ponteiros para array deverá ser um ponteiro NULL.
O local ID de um dispositivo é devolvido se FT_LIST_BY_INDEX e FT_OPEN_BY_LOCATION são

setados em dwFlags. Neste caso o parâmetro pvArg1 é interpretado como o índice do dispositivo, e o
parâmetro pvArg2 é interpretado como um ponteiro para uma variável de tipo DWORD para conter o
local ID. Índices são baseados em zero, e o código de erro FT_DEVICE_NOT_FOUND é retornado
para um índice inválido.
São retornados os Local ID de todos os dispositivos conectados se FT_LIST_ALL e

FT_OPEN_BY_LOCATION são setados em dwFlags. Neste caso, o parâmetro pvArg1 é interpretado
como um ponteiro para a um array de variáveis do tipo DWORD para conter os Local ID, e o
parâmetro pvArg2 é interpretado como um ponteiro para uma variável DWORD para armazenar o
número de dispositivos atualmente conectados.
FT_Open() - Exemplos 1, 2, 3 e 4
Delphi C++
FT_Open( )
Abre um dispositivo e retorna um identificador (handle) para ser usado pela maioria das funções.
FT_STATUS FT_Open(int iDevice, FT_HANDLE *ftHandle)
Parâmetros:
iDevice - Zero (0) para abrir o primeiro dispositivo plugado, um (1) para o segundo e, para mais, siga
a seqüência numérica.
ftHandle - Ponteiro para uma variável de tipo FT_HANDLE onde a Handle será armazenado. Este
handle deve ser usado pelas funções para ter acesso ao dispositivo.
Retorna:
FT_Open() - Exemplo 1
Delphi C++
FT_OpenEx( )
Abre um dispositivo e retorna um identificador (handle) para ser usado pela maioria das funções.
FT_STATUS FT_OpenEx(PVOID pvArg1, DWORD dwFlags, FT_HANDLE *ftHandle)
Parâmetros:
pvArg1 - O significando depende de dwFlags, mas regularmente será interpretado como um ponteiro
a uma string terminada em NULL.
dwFlags - FT_OPEN_BY_SERIAL_NUMBER, FT_OPEN_BY_DESCRIPTION ou
FT_OPEN_BY_LOCATION.
ftHandle - Ponteiro para uma variável de tipo FT_HANDLE onde a Handle será armazenado. Este
handle deve ser usado pelas funções para ter acesso ao dispositivo.
O significado de pvArg1 depende de dwFlags: se dwFlags é setado em

FT_OPEN_BY_SERIAL_NUMBER, pvArg1 é interpretado como um ponteiro a uma string terminada
em NULL que representa o número de série do dispositivo; se dwFlags for setado em
FT_OPEN_BY_DESCRIPTION, pvArg1 é interpretado como um ponteiro para uma string terminada
em NULL que representa a descrição de dispositivo; se dwFlags é setado em
FT_OPEN_BY_LOCATION, pvArg1 é interpretado como um valor DWORD que contém o Local ID do
dispositivo.
Retorna:

FT_OpenEx() - Exemplos 1, 2, 3 e 4
Delphi C++
FT_Close( )
Fecha um dispositivo aberto pelas funções FT_Open() ou FT_OpenEx().
FT_STATUS FT_Close(FT_HANDLE ftHandle)
Parâmetro:
ftHandle - Identificador do dispositivo.
Retorna:
FT_SetDivisor( )
Esta função define a velocidade da comunicação com o dispositivo. Ela é usada para definir uma
velocidade em Baud rate não padronizada.
FT_STATUS FT_SetDivisor(FT_HANDLE ftHandle, USHORT usDivisor)
Parâmetros:
usDivisor - Divisor.
Retorna:
FT_SetDivisor() - Exemplo 1
Delphi C++
FT_SetBaudRate( )
Esta função define a velocidade da comunicação com o dispositivo.
FT_STATUS FT_SetBaudRate(FT_HANDLE ftHandle, DWORD dwBaudRate)
Parâmetros:
dwBaudRate - Velocidade (Baud rate).
Retorna:
FT_SetBaudRate() - Exemplo 1
Delphi C++
FT_SetDataCharacteristics( )
Esta função define as características da comunicação com o dispositivo.
FT_STATUS FT_SetDataCharacteristics(FT_HANDLE ftHandle, UCHAR uWordLength, UCHAR
uStopBits, UCHAR uParity)
Parâmetros:
uWordLength - Tamanho do dado: FT_BITS_7 ou FT_BITS_8.
uStopBits - Número de stop bits: FT_STOP_BITS_1 ou FT_STOP_BITS_2.
uParity - Paridade: FT_PARITY_NONE, FT_PARITY_ODD, FT_PARITY_EVEN, FT_PARITY_MARK,
FT_PARITY_SPACE.
Retorna:

FT_SetDataCharacteristics() - Exemplo 1
Delphi C++
FT_SetTimeouts( )
Esta função seta os timeouts de leitura e escrita do dispositivo.
FT_STATUS FT_SetTimeouts(FT_HANDLE ftHandle, DWORD dwReadTimeout, DWORD
dwWriteTimeout)
Parâmetros:
dwReadTimeout - Timeout de leitura em milisegundos.
dwWriteTimeout - Timeout de escrita em milisegundos.
Retorna:
FT_SetTimeouts() - Exemplo 1
Delphi C++
FT_Purge( )
Esta função limpa os bufferes de transmissão e recepção no dispositivo. Use-a antes de uma
transmissão ou recepção, dependendo dos bits setados em dwMask.
FT_STATUS FT_Purge(FT_HANDLE ftHandle, DWORD dwMask)
Parâmetros:
dwMask - podem ser usadas as constantes FT_PURGE_RX ou FT_PURGE_TX. Ou uma
combinação das duas.
Retorna:
FT_Purge() - Exemplo 1
Delphi C++
FT_GetStatus( )
Obtém o estado do dispositivo, inclusive o número de caracteres recebidos na fila, número de
caracteres transmitidos na fila, e o estado atual do evento.
FT_STATUS FT_GetStatus(FT_HANDLE ftHandle, LPDWORD lpdwAmountInRxQueue, LPDWORD
lpdwAmountInTxQueue, LPDWORD lpdwEventStatus)
Parâmetros:
lpdwAmountInRxQueue - Ponteiro para uma variável do tipo DWORD para obter o número de
caracteres da fila de recepção.
lpdwAmountInTxQueue - Ponteiro para uma variável do tipo DWORD para obter o número de
caracteres da fila de transmissão.
lpdwEventStatus - Ponteiro para uma variável do tipo DWORD para obter o estado do evento atual.
Retorna:

FT_Read( )
Lê dados de um dispositivo.
FT_STATUS FT_Read(FT_HANDLE ftHandle, LPVOID lpBuffer, DWORD dwBytesToRead,
LPDWORD lpdwBytesReturned)
Parâmetros:
lpBuffer - Ponteiro para um buffer armazenar os dados lidos do dispositivo.
dwBytesToRead - Número de bytes que será lido do dispositivo.
lpdwBytesReturned - Ponteiro para uma variável do tipo DWORD, para obter o número de bytes lidos
no dispositivo.
Retorna:
Exemplos: FT_GetStatus() e FT_Read( )
Delphi C++
FT_Write( )
Escreve dados para um dispositivo.
FT_STATUS FT_Write(FT_HANDLE ftHandle, LPVOID lpBuffer, DWORD dwBytesToWrite,
LPDWORD lpdwBytesWritten)
Parâmetros:
lpBuffer - Ponteiro para um buffer onde contém os dados a serem escritos no dispositivo.
dwBytesToWrite - Número de bytes a serem escritos no dispositivo.
lpdwBytesWritten - Ponteiro para uma variável do tipo DWORD, para obter o número de bytes
escritos no dispositivo.
Retorna:
Exemplo 1 - FT_Write()
Delphi C++
FT_GetDeviceInfo( )
Obtém informações sobre o dispositivo.
FT_STATUS FT_GetDeviceInfo(FT_HANDLE ftHandle, FT_DEVICE *pftType, LPDWORD lpdwID,
PCHAR pcSerialNumber, PCHAR pcDescription, PVOID pvDummy)
Parâmetros:
pftType - Ponteiro para um DWORD para armazenar o tipo do dispositivo.
lpdwId - Ponteiro para um DWORD para armazenar o ID.
pcSerialNumber - Ponteiro para uma string terminada em NULL, para armazenar o Número de Série
do dispositivo.
pcDescription - Ponteiro para uma string terminada em null, para armazenar a Descrição.
pvDummy - Reservado para uso futuro. Atribuir NULL.
Retorna:
Exemplo 1 - FT_GetDeviceInfo( )
Delphi C++

FT_CreateDeviceInfoList( )
Esta função cria uma lista de informações sobre os dispositivos e retorna o numero de dispositivos
conectados ao sistema. Esta lista contém informações sobres os dispositivos abertos.
FT_STATUS FT_CreateDeviceInfoList(LPDWORD lpdwNumDevs)
Parâmetros:
lpdwNumDevs - Ponteiro para uma variável do tipo DWORD para armazenar o número de
dispositivos conectados.
Retorna:
Exemplo 1 - FT_CreateDeviceInfoList( )
Delphi C++
FT_GetDeviceInfoList( )
Esta função retorna uma lista de informações e o número de dispositivos conectados.
FT_STATUS FT_GetDeviceInfoList(FT_DEVICE_LIST_INFO_NODE *pDest, LPDWORD
lpdwNumDevs)
Parâmetros:
pDest - Ponteiro para uma estrutura de array FT_DEVICE_LIST_INFO_NODE.
lpdwNumDevs - Ponteiro para o número de elementos no array (número de dispositivos conectados).
Retorna:
Exemplo 1 - FT_GetDeviceInfoList( )
Delphi C++
FT_GetDeviceInfoDetail( )
Esta função devolve uma entrada da lista de informação de dispositivo.
FT_STATUS FT_GetDeviceInfoDetail(DWORD dwIndex, LPDWORD lpdwFlags, LPDWORD
lpdwType, LPDWORD lpdwID, LPDWORD lpdwLocId, PCHAR pcSerialNumber, PCHAR
pcDescription, FT_HANDLE *ftHandle)
Parâmetros:
dwIndex - Índice da entrada na lista de informações de dispositivos.
lpdwFlags - Ponteiro para um DWORD para armazenar o valor do Flag.
lpdwType - Ponteiro para um DWORD para armazenar o tipo do dispositivo.
lpdwID - Ponteiro para um DWORD para armazenar o ID do dispositivo.
lpdwLocId - Ponteiro para um DWORD para armazenar o ID local do dispositivo.
pcSerialNumber - Ponteiro para uma string terminada em NULL, para armazenar o Número de Série
do dispositivo.
pcDescription - Ponteiro para uma string terminada em null, para armazenar a Descrição.
ftHandle - Ponteiro para uma variável de tipo FT_HANDLE onde a Handle será armazenado.
Retorna:
Exemplo 1 - FT_GetDeviceInfoDetail( )
Delphi C++

Funções da FT2DXX para controle das linhas do Modem
FT_GetModemStatus( )
Obtém o estado das linhas do modem do dispositivo.
FT_STATUS FT_GetModemStatus(FT_HANDLE ftHandle, LPDWORD lpdwModemStatus)
Parâmetros:
lpdwModemStatus - Ponteiro para uma variável do tipo DWORD para receber o estado das linhas do
modem do dispositivo.
Retorna:
Exemplo 1 - FT_GetModemStatus( )
Delphi C++
FT_ClrRts( )
Esta função limpa o sinal de controle RTS (Request To Send).
FT_STATUS FT_ClrRts(FT_HANDLE ftHandle)
Parâmetro:
Retorna:
FT_SetRts( )
Esta função seta o sinal de controle RTS (Request To Send).
FT_STATUS FT_SetRts(FT_HANDLE ftHandle)
Parâmetro:
Retorna:
FT_ClrDtr( )
Esta função limpa o sinal de controle DTR (Data Terminal Ready).
FT_STATUS FT_ClrDtr(FT_HANDLE ftHandle)
Parâmetro:
Retorna:
FT_SetDtr( )
Esta função seta o sinal de controle DTR (Data Terminal Ready).
FT_STATUS FT_SetDtr(FT_HANDLE ftHandle)
Parâmetro:
Retorna:
FT_SetBreakOn( )
Seta uma condição de BREAK para o dispositivo.
FT_STATUS FT_SetBreakOn(FT_HANDLE ftHandle)
Parâmetro:
Retorna:

FT_SetBreakOff( )
Reseta uma condição de BREAK para o dispositivo.
FT_STATUS FT_SetBreakOff(FT_HANDLE ftHandle)
Parâmetro:
Retorna:
Exemplos: FT_ClrRts(), FT_SetRts(), FT_ClrDtr(), FT_SetDtr(),

FT_SetBreakOn() e FT_SetBreakOff( )
Delphi C++
Funções da FT2DXX para programação da EEPROM
FT_EE_Program( )
Programa a EEPROM.
FT_STATUS FT_EE_Program(FT_HANDLE ftHandle, PFT_PROGRAM_DATA lpData)
Parâmetros:
lpData - Ponteiro para uma estrutura do tipo FT_PROGRAM_DATA.
Retorna:
FT_EE_Program() - Exemplos 1 e 2
Delphi C++
FT_EE_ProgramEx( )
Programa a EEPROM passando strings separadamente.
FT_STATUS FT_EE_ProgramEx(FT_HANDLE ftHandle, PFT_PROGRAM_DATA pData, char
*Manufacturer, char * ManufacturerId, char *Description, char *SerialNumber)
Parâmetros:
pData - Pointer to a structure of type FT_PROGRAM_DATA.
Manufacturer - Ponteiro para uma string terminada em NULL, que contém o Nome do fabricante.
ManufacturerID - Ponteiro para uma string terminada em NULL, que contém o ID do fabricante.
Description - Ponteiro para uma string terminada em NULL, que contém a Descrição do dispositivo.
SerialNumber - Ponteiro para uma string terminada em NULL que contém o Número Serial do
dispositivo.
Retorna:
FT_EE_ProgramEx() - Exemplo 1
Delphi C++

FT_EE_Read( )
Lê o conteúdo da EEPROM.
FT_STATUS FT_EE_Read(FT_HANDLE ftHandle, PFT_PROGRAM_DATA lpData)
Parâmetros:
lpData - Ponteiro para uma estrutura do tipo FT_PROGRAM_DATA.
Retorna:
FT_EE_Read() - Exemplo 1
Delphi C++
FT_EE_ReadEx( )
Lê o conteúdo da EEPROM passando strings separadamente.
FT_STATUS FT_EE_ReadEx(FT_HANDLE ftHandle, PFT_PROGRAM_DATA pData, char
*Manufacturer, char *ManufacturerId, char *Description, char *SerialNumber)
Parâmetros:
pData - Pointer to a structure of type FT_PROGRAM_DATA.
Manufacturer - Ponteiro para uma string terminada em NULL, que contém o Nome do fabricante.
ManufacturerID - Ponteiro para uma string terminada em NULL, que contém o ID do fabricante.
Description - Ponteiro para uma string terminada em NULL, que contém a Descrição do dispositivo.
SerialNumber - Ponteiro para uma string terminada em NULL que contém o Número Serial do
dispositivo.
Retorna:
FT_EE_ReadEx() - Exemplo 1
Delphi C++
FT_ReadEE( )
Lê um valor num determinado endereço da EEPROM.
FT_STATUS FT_ReadEE(FT_HANDLE ftHandle, DWORD dwWordOffset, LPWORD lpwValue)
Parâmetros:
dwWordOffset - Endereço a ser lido na EEPROM.
lpwValue - Ponteiro para uma variável DWORD armazenar o valor lido na EEPROM.
Retorna:
FT_EE_ReadEE() - Exemplo 1
Delphi C++
FT_WriteEE( )
Escreve um valor num determinado endereço da EEPROM.
FT_STATUS FT_WriteEE(FT_HANDLE ftHandle, DWORD dwWordOffset, WORD wValue)
Parâmetros:
dwWordOffset - Endereço para escrever na EEPROM.
wValue - Valor a ser escrito na EEPROM.
Retorna:

FT_EE_WriteEE() - Exemplo 1
Delphi C++
FT_EraseEE( )
Apaga TODO o conteúdo da EEPROM, inclusive o espaço livre do usuário.
FT_STATUS FT_EraseEE(FT_HANDLE ftHandle)
Parâmetro:
Retorna:
FT_EraseEE() - Exemplo 1
Delphi C++
Funções da FT2DXX para programação da EEPROM (área livre do usuário)
FT_EE_UASize( )
Obtém o tamanho EEUA (área livre da EEPROM para uso pelo usuário).
FT_STATUS FT_EE_UASize(FT_HANDLE ftHandle, LPDWORD lpdwSize)
Parâmetro:
lpdwSize - Ponteiro para uma variável do tipo DWORD que receberá o tamanho em bytes da EEUA.
Retorna:
FT_EE_UAWrite( )
Escreve dados dentro da EEUA (área livre da EEPROM para uso pelo usuário).
FT_STATUS FT_EE_UAWrite(FT_HANDLE ftHandle, PUCHAR pucData, DWORD dwDataLen)
Parâmetros:
pucData - Ponteiro para um buffer que contém os dados a serem escritos.
dwDataLen - Tamanho em bytes do buffer que contém os dados a serem escritos.
Retorna:
FT_EE_UARead( )
Lê o conteúdo da EEUA (área livre da EEPROM para uso pelo usuário).
FT_STATUS FT_EE_UARead(FT_HANDLE ftHandle, PUCHAR pucData, DWORD dwDataLen,
LPDWORD lpdwBytesRead)
Parâmetros:
pucData - Ponteiro para um buffer para armazenar os dados lidos.
dwDataLen - Tamanho em bytes do buffer que irá armazenar os dados lidos.
lpdwBytesRead - Ponteiro para uma variável do tipo DWORD que contém o número de bytes lidos.
Retorna:
Exemplos: FT_EE_UASize( ), FT_EE_UAWrite( ) e FT_EE_UARead( )
Delphi C++

Funções de programação em modo Bit Bang
É possível através do FT232BM, enviar e receber 8 bits de forma paralela,

usando o modo bit bang. Esse recurso do chip é uma mão-na-roda para àqueles que
não desejam usar um microcontrolador em seus projetos, com o objetivo de utilizar o
UART do mesmo, para se comunicar de forma serial com o FT232BM, através dos
pinos TXD e RXD.
No modo bit bang é como se estivéssemos trabalhando com a Porta Paralela

bidirecional EPP do PC, ou ainda, com se estivéssemos usando uma porta de um
microcontrolador (PIC, ATMEL etc), onde se é possível definir independentemente,
um pino do outro, como entrada ou saída. Fazemos isso da mesma forma no modo
bit bang, com a diferença de que no FT232BM é possível também definir uma
velocidade (baud rate) para a porta.
Ao trabalhar com o FT232BM no modo bit bang, ficam disponíveis 8 pinos para
uso como entradas ou saídas.
Veja abaixo a relação dos pinos com a ordem dos bits:
Tabela 1 - Pinos do FT232BM no modo bit bang

Pinos no FT232BM Ordem dos bits
TXD D0
RXD D1
RTS# D2
CTS# D3
DTR# D4
DSR# D5
DCD# D6
RI# D7
Obs.: Alguns pinos da tabela cima são resetados no FT232BM quando o

computador é reiniciado, mesmo que o circuito seja Self powered (alimentado com
fonte externa). Se desejar construir um circuito que não seja resetado quando o
computador é reiniciado, use microcontrolador para receber e validar somente os
comandos pré-estabelecidos no programa.
FT_SetBitMode( )
FT_STATUS FT_SetBitMode(FT_HANDLE ftHandle, UCHAR ucMask, UCHAR ucEnable)
Parâmetros:
ucMask - Valor requerido para a máscara de bits.
ucEnable - Habilita valor, 0 = FALSE, 1 = TRUE.
Retorna:
Um valor FT_OK se teve sucesso. Qualquer outro valor retornado indica que a função não teve
êxito.

FT_GetBitMode( )
Obtém instantaneamente um valor do Bus de dados.
FT_STATUS FT_GetBitMode(FT_HANDLE ftHandle, PUCHAR pucMode)
Parâmetros:
pucMode Ponteiro para UCHR (unsigned char) para armazenar o valor dos bits lido.
Retorna:
FT_SetLatencyTimer( )
Seta a latência do timer.
FT_STATUS FT_SetLatencyTimer(FT_HANDLE ftHandle, UCHAR ucTimer)
Parâmetros:
ucTimer - Valor em milisegundos da latência do timer. Limite válido: 2 - 255ms.
Retorna:
FT_GetLatencyTimer( )
Obtém o valor corrente da latência do timer.
FT_STATUS FT_GetLatencyTimer(FT_HANDLE ftHandle, PUCHAR pucTimer)
Parâmetros:
pucTimer - Ponteiro para uma variável do tipo UCHAR (unsigned char) para armazenar o valor da
latência do timer.
Retorna:
Exemplos: FT_SetBitMode( ), FT_GetBitMode( ) e

FT_SetLatencyTimer( )
Delphi C++
Figura 1 - Tela do programa para controlar o Circuito 1

Figura 2 - Circuito controlado pelo modo Bit Bang
No circuito acima, os pinos 25, 24, 23 e 22 são usados como saídas, e os pinos
21, 20, 19 e 18 como entradas. Os pinos estabelecidos como entradas ou saídas
são definidos no segundo parâmetro da função FT_SetBitMode() no programa.
Os resistores pull-down de 10K conectados aos pinos 21, 20, 19 e 18 do

FT232BM são usados para fazer com que as entradas trabalhem com lógica
positiva.
Para conhecer mais funções da dll FTD2xx, faça download da guia de

programação D2XXPG30.pdf no site da FTDI:
http://www.ftdichip.com/Documents/ProgramGuides/D2XXPG30.pdf

Projetos práticos
Nesta aula estão disponíveis dois projetos onde foram aplicados os

conhecimentos adquiridos nas aulas anteriores. São projetos básicos que pode ser
agregados a projetos maiores.
Um dos projetos apresentado aqui é um controle de Relês que poderá ser

usado como base para ligar ou desligar qualquer outro atuador. O outro é um
termômetro que utiliza o sensor de temperatura LM35 da National Semiconductor,
conectado a uma entrada analógica do PIC16F877.
Com algumas mudanças é possível agregar aos projetos um protocolo mais

eficiente para garantir a segurança, tendo certeza de que o dispositivo tenha sido
ligado ou desligado corretamente, ou obtido a informação sem erro.
Controlando Relês
O objetivo desse projeto é ligar e desligar até 8 relês através de um circuito

microcontrolado, conectado ao Bus USB e controlado por um programa no PC.
Para esse projeto são necessários dois programas: um que irá rodar no
PIC16F877 e o outro no PC.

Figura 1 - Tela do programa controle de relês
O programa acima pode ligar ou desligar até 8 dispositivos, e funciona da

seguinte forma: quando pressionamos um botão, uma string de comandos é enviada
pelo programa ao FT232BM, esse por sua vez envia a string para o PIC16F877. O
programa que está em execução dentro do PIC16F877 compara se a string recebida
é válida, se for, executa uma ação que depende do conteúdo da mesma (ligar ou
desligar o dispositivo). Se a string de comando foi válida, o PIC16F877 envia uma
resposta ao programa no PC, informando que o relê foi ligado ou desligado.
O programa no PIC só garante se um pino foi ligado ou desligado corretamente,

mas não se realmente o relê foi ligado ou desligado. Para isso, seria necessário
adicionar mais componentes ao projeto, como sensores ligados aos relês para
informar ao PIC através de pinos de entradas, que os relês foram de verdade ligados
ou desligados.
Download do programa:
Delphi C++

Figura 2 - Circuito para controle de Relês
No circuito acima foi usado um driver ULN 2803 com 8 entradas TTL e 8 saídas
que podem controlar até 45v/500mA. No nosso caso o ULN2803 é alimentado com
12v para poder controlar os Relês também de 12v. Cada relê consome em torno de
50mA; quando todos os relês estiverem acionados o consumo total é de 400mA (8
relês x 50mA). Assim o ULN2803 trabalha com uma folga de 100mA.
O dispositivo FT232BM deve ser configurado para trabalhar como self-powered

(alimentado com uma fonte externa). Uma configuração self-powered é necessária
para que os relês não sejam resetados quando o computador for desligado/ligado.
O botão Reset e o LED1 são opcionais. O Reset serve para reiniciar o PIC e o
LED1 para informar que o programa gravado no PIC está em execução.

Figura 3 - Driver para controle de um Relê
Se desejar controlar 8 relês, adicione 8 circuitos idênticos ao da Figura 3 às

saídas (RL1 a RL8) do ULN2803.
Os relês são acionados com 12v e seus contatos suportam até 10A/220v.
Figura 4 - Regulador de tensão
O circuito acima é um regulador de tensão usado para alimentar o PIC e o

dispositivo FT232BM a partir de uma fonte de 12v. Os 12v são usados somente para
alimentar os Relês e as saídas do ULN2803.
Observe com atenção, pois temos duas voltagens (5v e 12v). O PIC e o
FT232BM devem ser alimentados com 5v. O 0v deve ser comum em todos os
circuitos.
DownLoad do programa Controle de Relês para gravar o PIC16F877.

Fonte 1 CCS Compiler - Programa para ser compilado e gravado dentro do PIC16F877
//Controle de Relês
//Curso USB/Serial
//www.rogercom.com
//-------------------------------------------------------------------------------------------------------
#include <16F877.h>
#include <stdio.h>
#include <stdlib.h>
#include <string.h>
#define MAX_BUFFER 15
char BufferRX[MAX_BUFFER+1];
boolean CHEGOU_COMANDO = false;
//--------------------------------------------------------------------------
//---------------------------------------------------------------------------
#int_rda
void Serial_Recebe_Car()
{
static unsigned char ch;
static int IndexBuf=0;
BufferRX[IndexBuf] = ch; //Guarda o caracter no buffer.
if( BufferRX[IndexBuf] == '*' ) //Se é o fim da string de comando.

{
BufferRX[IndexBuf+1] = '\0'; //Finaliza sting.
IndexBuf = 0;
CHEGOU_COMANDO = true; //Avisa que chegou uma string de comando.
}else{
IndexBuf++;
}
if( (BufferRX[0] != '>' ) || (IndexBuf >= MAX_BUFFER) )
{
IndexBuf = 0;
}
}
//--------------------------------------------------------------
//Para fazer o LED piscar.
#int_timer0
void MeuTimer()
{
static boolean led;
static int conta;
conta++;
if(conta == 125)

{
conta=0;
led = !led;
output_bit(pin_d1, led); //pisca o LED1
}
}
//--------------------------------------------------------------
void main(void)
{
char COMANDO[15];
set_timer0(131);
setup_timer_0(RTCC_INTERNAL | RTCC_DIV_64);
enable_interrupts(int_timer0);
set_tris_d(0b00000000); //Todos os pinos da porta D como saídas.

set_tris_b(0b00000000); //Todos os pinos da porta B como saídas.
output_b(0b00000000); //Desliga todos os pinos da porta B.

{
if(CHEGOU_COMANDO == true)
{
CHEGOU_COMANDO = false;
strcpy(COMANDO,">CMD#01#ON*");
if( strcmp(BufferRX,COMANDO) == 0)
{
output_high(pin_b0); //Liga Relê 1.
printf("Relê #1 LIGADO\r\n");
continue; //volta para o início do loop while().
}
strcpy(COMANDO,">CMD#01#OFF*");
if(strcmp(BufferRX,COMANDO) == 0)
{
output_low(pin_b0); //Desliga Relê 1.
printf("Relê #1 DESLIGADO\r\n");
continue;
}
//--------------------------------------------------------------
{
output_high(pin_b1); //Liga LED.
continue;
}
{
output_low(pin_b1); //Desliga LED.
continue;

}
//--------------------------------------------------------------
{
continue;
}
{
continue;
}
//--------------------------------------------------------------
{
continue;
}
{
continue;
}
//--------------------------------------------------------------
{
continue;
}
{
continue;
}
//--------------------------------------------------------------
{
continue;
}
{


continue;
}
//--------------------------------------------------------------
{
continue;
}
{
continue;
}
//--------------------------------------------------------------
{
continue;
}
{
continue;
}
//--------------------------------------------------------------
}
}
}
O programa acima lê uma string de comandos através da interrupção #int_rda

(pino RX do PIC) até encontrar o caracter asterisco '*', que indica final de string em
nosso simples protocolo. Após detectar esse caracter, a variável global
CHEGOU_COMANDO fica igual a true, e a string BufferRx contém o comando recebido.
No loop while() do programa principal o comando if(CHEGOU_COMANDO == true) se
torna verdade e um processo de comparação é acionado. Se uma string, por
exemplo: ">CMD#08#ON*" for igual ao conteúdo recebido e armazenado na variável
BufferRx, o pino pin_b7 vai a nível alto, ligando o Relê #8 e logo em seguida é
enviada a string de confirmação: "Relê #8 LIGADO\r\n" para o programa no PC.
Não era necessário usar o comando strcpy() no programa acima, mais foi
preciso pois a função strcmp() da CCS só compara duas variáveis e não constantes
" ". Poderiamos ter armazenado as constantes na memória para eliminar a função
strcpy() mas a versão Trial 30 dias da CCS só reserva o mínimo de memória RAM
para os programas.

Sensor de Temperatura
O projeto termômetro aqui apresentado é baseado no sensor de temperatura

LM35.
Existem no mercado vários tipos de sensores de temperatura como NTSCs,

diodos e muitos outros. O LM35 é um sensor de temperatura de altíssima precisão
fabricado pela National Semiconductor. Sua gama de precisão é de 10mV (milivolts)
por cada grau Celsius de temperatura, e pode trabalhar com voltagens entre 4 a 30v.
Drena menos de 60uA.
Para mais informações técnicas sobre o LM35, acesse o site do fabricante em:
http://www.national.com e faça download do Datasheet.
Figura 5 - Tela do programa sensor de Temperatura
O programa acima exibe numa ampola (componente ProgressBar) a

temperatura ambiente a cada 1 segundo após o botão "Abrir USB" ter sido
pressionado. A partir desse ponto qualquer alteração na temperatura o sensor LM35
detecta, e através do pino RA0 (analógico) do PIC 16F877, a temperatura é
convertida em dados digitais e transferidos para o computador através do FT232BM
usando o Bus USB. A temperatura é mostrada em graus Celsius (ºC).

Download do programa:
Delphi C++
Figura 6 - Pinagem LM35
Figura 7 - Circuito sensor de temperatura através do LM35
No circuito acima, a saída do sensor de temperatura LM35 está conectado ao

pino 2 - RA0 (Canal 0) do PIC16F877.

Como no circuito de Controle de Relês o botão Reset e o LED1 são opcionais.
DownLoad do programa Sensor de Temperatura para gravar o PIC16F877.
Fonte 2 - CCS Compiler - Programa que ler o canal 0 analógico e envia os dados para o FT232BM
//Curso USB/Serial.
//Sensor de temperatura usando o CI LM35
//www.rogercom.com
#include <16F877.h>
#device ADC=10 //Canal analógico de 10 bits.
#include <stdio.h>
//Para fazer o LED piscar.

#int_timer0
void MeuTimer()
{
static boolean led;
static int conta;
conta++;
if(conta == 125)
{
conta=0;
led = !led;
output_bit(pin_d1,led);
}
}
//---------------------------------------------------------------------------
//---------------------------------------------------------------------------
long Temperatura;
long valor;
void main(void)
{
setup_adc(ADC_CLOCK_INTERNAL);
setup_adc_ports(RA0_ANALOG); //Todas as porta A como analógicas
set_adc_channel(0); //Canal 0 selecionado como entrada analógica.
set_timer0(131);
setup_timer_0(RTCC_INTERNAL | RTCC_DIV_64);
enable_interrupts(int_timer0);
set_tris_d(0b00000000); //todos os pinos da porta D como saídas.

{
delay_ms(1000); //A cada 1 segundos.

valor = read_adc(); //Lê o canal 0 - pino RA0 analógico.

Temperatura = 2+100 * valor / 303; //Calcula a temperatura em graus Celsius.
//Temperatura = 5 * valor * 100 / 1023; //Calcula a temperatura em graus Celsius.
//printf("%2Lu ºC - %2Lu\r\n", Temperatura, valor);
printf("%2Lu\r\n",Temperatura); //Envia para a porta serial.
}
}
No programa acima o comando #device ADC=10 define que o PIC usa um

conversor analógico/digital de 10 bits de resolução. Já a função
setup_adc_ports(RA0_ANALOG); define que o pino 2 (Canal 0) é uma entrada analógica.
A função setup_adc(ADC_CLOCK_INTERNAL) diz ao PIC que o sistema de

conversão usa um sinal de clock interno.
O valor da temperatura é obtido através da função read_adc(). A fórmula

(Temperatura = 5 * valor * 100 / 1023) é a responsável por converter o valor digital
obtido, em Graus Celsius (ºC). Os dados são enviados para o FT232BM pela função
printf("%2Lu\r\n",Temperatura);. "Lu" significa unsigned long (número inteiro longo sem
sinal).

Curso USB Serial

Enviado por

Dados do documento

Direitos autorais

Formatos disponíveis

Compartilhar este documento

Compartilhar ou incorporar documento

Opções de compartilhamento

Você considera este documento útil?

Este conteúdo é inapropriado?

Direitos autorais:

Formatos disponíveis

Curso USB Serial

Enviado por

Direitos autorais:

Formatos disponíveis

ROGERCOM – Curso USB/Serial – www.rogercom.

Bem vindo ao Curso USB - Universal Serial Bus

No sistema USB a tecnologia plug-and-play funciona na sua integra; você pode

Optamos em utilizar os chipset da FTDI, por serem fáceis de utilizar; eficientes;

Iremos também ter a oportunidade de programar um micro controlador PIC em

Segue abaixo alguns produtos USB disponíveis atualmente no mercado:

Aula 01 – Módulo-USB / Página 1

Figura 1 - Auto Rádio MP3

Figura 4 - Memória Flash

Aula 01 – Módulo-USB / Página 2

Figura 5 - Relógio com suporte USB Figura 6 - Pen drive

Figura 7 - Leitor/gravador de memory card Figura 8 - Impressora

Aula 01 – Módulo-USB / Página 3

Figura 9 – Multi acessórios Figura 10 - Mouse Figura 11- Câmera

Introdução ao Barramento USB

As primeiras versões do bus USB utilizavam/utilizam os Controladores Host

Os Hubs são componentes muito importantes na topologia de uma Rede USB.

Aula 01 – Módulo-USB / Página 4

Hubs sem fonte de alimentação chegam a ter 4 portas downstream, fornecendo

Se um dispositivo tentar consumir mais corrente do que o Hub pode fornecer

Aula 01 – Módulo-USB / Página 5

Figura 13 - Ilustração de um Hub e suas portas: primária e secundárias

Veja na figura acima, que a porta principal do Hub é chamada de Upstream, é

São através dos Hubs que o Host/controlador tem o poder de detectar se um

Hubs também fornecem energia através de suas portas Downstream a

Aula 01 – Módulo-USB / Página 6

Figura 14 - Topologia USB (Tier star)

Num sistema USB existe apenas um HOST, os demais componentes são os

Na figura acima temos 5 fileiras contando a partir do Host. Na especificação da

Também é importante saber que o comprimento do cabo USB é de 5m,

Aula 01 – Módulo-USB / Página 7

Figura 15 - Topologia física

A figura acima é um padrão da norma USB e mostra o esquema da topologia

Observe na figura acima que a combinação de um Hub e, um ou mais

Aula 01 – Módulo-USB / Página 8

Figura 16 - Arquitetura típica de um sistema USB

Dispositivos como: impressoras, áudio/vídeo, modem ADSL e WebCam,

Aula 01 – Módulo-USB / Página 9

Figura 17 - Dispositivos com Hub incluso

Na configuração acima, vemos dispositivos conectados ao teclado e também ao

O hub/função do monitor tem sua própria fonte de alimentação, dessa forma

Aula 01 – Módulo-USB / Página 10

Introdução ao Universal Serial Bus (USB)

O host USB se comunica com os dispositivos através do seu controlador

O controlador host pode ser encontrado na própria estrutura base da placa-mãe

• Detectar a inclusão e remoção de dispositivos;

Figura 1 - Placa controladora USB 2.0 - 5 portas

Aula 02 – Módulo-USB / Página 11

Não foi fácil essas empresas chegarem a um acordo plausível sobre a

OHCI - (Open Host Controller Interface). Algumas empresas como a Compaq e a

Esse desacordo entre as empresas gerou incompatibilidade no padrão

Portanto, UHCI, OHCI, EHCI são modelos de controladores USB compostos de

Um circuito Controlador consiste de duas partes: o Driver de Controle do Host

Controladores Host UHCI e OHCI estão associados à versão USB 1.1. Já o

Aula 02 – Módulo-USB / Página 12

Figura 2 - Detalhes da placa controladora

É no Host onde o driver (software) do controlador é executado, dividindo o

Tanto a camada de software como a de hardware, está acomodada num único

Aula 02 – Módulo-USB / Página 13

Figura 3 - Visão geral do sistema USB, camadas de software e hardware

Para entendermos melhor a ilustração gráfica acima, vamos partir da Aplicação

1 - A aplicação do cliente chama uma rotina da API passando-lhe parâmetros

3 - O Driver USB (USBD) é um software básico que já vem agregado ao

Aula 02 – Módulo-USB / Página 14