Site menu A saudosa porta paralela

A saudosa porta paralela

Acontece algo interessante na informática. Padrões de hardware que atingiram uma certa massa crítica de popularidade, dificilmente vão embora. (Pode-se argumentar que o mesmo acontece com software.)

Portas PS/2, portas VGA, portas seriais, todas essas ainda podem ser encontradas em PCs novos. Todos os conectores USB desde a versão 1.0 (A, B, mini-A, Mini-B, etc.) ainda são encontráveis esporadicamente em aparelhos novos. Cabos de alimentação, mesma cantiga. Então, para os bisonhos, fica a dica: nunca jogue fora um cabo ou um adaptador, porque cedo ou tarde você vai precisar dele.

Uma exceção notável é a porta paralela. Foi imensamente popular, era muito versátil, e mesmo assim morreu.

Na época do MS-DOS, para o usuário médio, a porta paralela era mais importante que a porta serial. Nem todo mundo tinha mouse, mas todo mundo tinha impressora.

Com o tempo, descobriram que a porta paralela podia fazer comunicação bidirecional, e era muito mais rápida que a porta serial. Isso abriu a porteira para muitos outros periféricos: scanners, drivers Zip, até adaptadores de rede. Era possível formar uma rede entre dois computadores com PLIP. (Acho que guardei meu cabo PLIP por uns 17 anos após o último uso...)

Finalmente, a porta paralela era o meio mais fácil de molhar os pés em IoT com um PC padrão, sem nenhum hardware adicional, e de forma muito simples do lado do software. Bastava enviar bytes para uma porta de I/O, e podia-se controlar LEDs, motores de passo, servos... Esta era uma época em que não havia Arduino, só havia PIC e 8051, tudo complicado de se usar e mesmo de se obter.

Sem dúvida a porta USB foi a "assassina" da porta paralela. Bidirecional, mais rápida, mais prática, também fornece energia, pode ser conectada e desconectada com o computador ligado sem risco de queimar nada. Uma vez que há adaptadores USB para qualquer outra porta, a migração foi gradual. Ninguém teve de jogar fora sua impressora paralela nesse interim.

Origens

A porta paralela teve origem bastante humilde. Não foi inventada no contexto de um comitê, SIG ou entidade internacional. Ela é o resultado da consolidação de diversos padrões de fato. Sua primeira versão foi criada pela Centronics, fabricante de impressoras, com dois objetivos em mente.

Um objetivo era tornar o circuito o mais simples e barato possível. Usar um canal paralelo era mais simples, pois a impressora podia receber e imprimir um byte de cada vez, direto do computador para a cabeça de impressão, enquanto um canal serial implica em haver algum tipo de memória ou buffer intermediário.

Outro objetivo era dar destino a um certo conector de 36 pinos, que a Centronics possuía em estoque e não sabia o que fazer com ele. E assim nasceu o "Conector Centronics" que todo cabo paralelo ostenta na ponta da impressora. Menos da metade dos contatos são realmente utilizados.

Neste ponto da história, o cabo paralelo não tinha conector padronizado na ponta ligada ao computador. Cada fabricante adotava o seu. O conector DB-25 que minha geração conheceu foi introduzido pelo IBM PC em 1981.

Figura 1: Cabo paralelo entre computador e impressora. Uma verdadeira quimera, resultado de escolhas feitas em diferentes épocas, por diferentes fabricantes, com diferentes motivações.

Para aumentar a confusão, esse DB-25 é o mesmo conector da porta serial de 25 vias. Em tese, isso aumenta o risco de conectar o cabo no lugar errado, se o computador estiver equipado com esse tipo de porta serial. Mas, no IBM PC, creio que o "sexo" da porta serial era invertido em relação à porta paralela, diminuindo esse risco.

A interface paralela do IBM PC não era totalmente compatível com o "padrão" elétrico Centronics; foi concebida para conectar exclusivamente com impressoras IBM. Porém os fabricantes logo se mexeram e tornaram suas impressoras compatíveis com IBM PC.

No IBM PC original, a interface paralela possuía capacidade muito limitada de comunicação bidirecional, usando os sinais de controle como canal de retorno. Esse tipo de porta é denominada "clássica" ou "apenas para impressora".

No IBM PS/2 de 1987, a porta paralela tornou-se 100% bidirecional. Como muitos padrões introduzidos pelo PS/2, esse tipo de porta logo apareceu nos "clones" de PC. É conhecida pela sigla "SPP" (Standard Parallel Port).

Com o tempo, outros fabricantes introduziram diversos padrões de fato, tanto nas técnicas de controle por software das portas, como no próprio hardware das mesmas, visando aumentar sua velocidade e bidirecionalidade. Surgiram as portas paralelas "ECP" e "EPP", a segunda visando o uso geral, a primeira otimizada para impressoras.

Em 1994, todos esses padrões de fato foram consolidados num padrão de verdade: IEEE 1284. Este padrão prescreve inclusive um método de autonegociação, para que computadores e periféricos usem o melhor modo disponível sem exigir que o usuário meta a mão em configurações.

Na minha lembrança, não era comum haver problemas de compatibilidade entre portas e dispositivos. O pior que podia acontecer era ter de entrar na BIOS e configurar a porta paralela para ECP, EPP ou SPP. Essa configuração de BIOS existia para acomodar dispositivos paralelos problemáticos ou antigos, que só funcionavam com um tipo específico de porta paralela.

Por que morreu?

A porta paralela tinha diversas desvantagens. Cabo grosso, alcance limitado, aplicação limitada à impressora e a uns poucos periféricos.

O objetivo original da porta paralela era baratear o circuito da impressora. Comunicação serial implica em circuitos mais elaborado. Por exemplo, a porta de teclado do IBM PC usa um protocolo serial, e todo teclado desde o primeiríssmo Model F já possuía microcontrolador (e custava tanto quanto hoje custa um computador inteiro).

Mas qualquer impressora fabricada mais recentemente — e por "recentemente" eu quero dizer no meu tempo de vida — também possui microcontrolador, e é mecanicamente complexa demais para ser comandada diretamente a partir do computador, então essa raison d'être da porta paralela já não existe faz tempo.

Ela podia queimar se conectada ou desconectada com algo ligado. Todas as portas "antigas" do PC (exceto a serial) tinham esse problema. E realmente queimavam. Pessoalmente, ao longo da vida, queimei pelo menos uma porta paralela e um teclado por este processo. Computadores mais novos são (paradoxalmente) mais robustos neste quesito que os antigos.

Outros modelos de computador (workstations UNIX, Macs) nunca tiveram porta paralela, então quando o monopólio do IBM PC começou a ruir no fim dos anos 1990, o ecossistema da porta paralela foi de embrulho junto.

Tudo que a porta paralela fazia, a porta serial RS-232 fazia melhor. Porém, a velocidade da primeira (até uns 4Mbps) era um trunfo frente à segunda (0.15Mbps). Com o tempo, 2Mbps não eram mais suficientes, e o USB 1.0 com seus 12Mbps logo tomou seu lugar. Na outra ponta, aplicações de banda ultra-baixa continuaram a usar comunicação serial, como sempre usaram.

Um problema inerente de comunicação paralela, não apenas da porta Centronics, mas de qualquer tecnologia que transmita bits em paralelo e.g. o contemporâneo SCSI, é o sincronismo entre os diversos bits de dados. Eles nunca vão chegar exatamente ao mesmo tempo. Quanto mais comprido o cabo, pior. É necessário um sinal de clock — STROBE em portas SPP, bem como uma janela de tempo entre o envio de dados e o STROBE para garantir que todos os bits chegaram.

Tudo isso limita a velocidade máxima e a distância admissível. Faz sentido num cabo de 1 metro, sem blindagem, barato e de qualidade imprevisível. Conforme aumenta o produto velocidade × distância, canais seriais se saem melhor. Finalmente, é mais fácil "traduzir" um sinal serial de par metálico para fibra ótica e vice-versa.

De fato, toda tecnologia de rede é serial, e toda tecnologia de conectividade minimamente recente é serial, até mesmo dentro da placa-mãe de um computador (SATA, PCI Express e DDR4/5 são todos seriais).

A desvantagem disso, que não afeta o usuário típico, é mais um problema filosófico, é a complexidade irredutível de qualquer equipamento. Não admira tanta gente esteja mexendo com "retrocomputaria" por hobby, em equipamentos que podiam ser diagnosticados com um osciloscópio e consertados com componentes adquiridos na loja de eletrônica...

Portas de I/O

Tradicionalmente, dispositivos de hardware são mapeados em memória: certos endereços de RAM não são memória de verdade, mas quando lidos ou gravados, causam efeitos colaterais no hardware.

Os processadores Intel e Z80 possuem o recurso das "portas de I/O": basicamente um espaço de endereçamento em separado, só para este fim. Era um mecanismo muito utilizado nos periféricos do IBM PC, bem como nas placas de expansão ISA, por ser muito mais simples que mapeamento em memória. É considerado obsoleto desde o advento do barramento PCI.

Cada porta paralela "clássica" precisa de três portas de I/O. Configura-se a "porta-base" — na BIOS ou por jumpers — e as demais portas acompanham. Por exemplo, num PC típico com apenas uma porta paralela na placa-mãe, a porta-base é comumente 0x378, e as portas adicionais são então 0x379 e 0x37A.

Se houver mais de uma porta paralela, cada uma tem de ocupar uma faixa diferente de portas. As portas-base mais comuns eram 0x3BC (porta inclusa em placa de vídeo), 0x378 (primeira porta) e 0x278 (segunda porta). Mas havia computadores diferentões, como máquinas registradoras, cuja porta-base da impressora era 0x300 ou 0x303.

A beleza da porta "clássica" para hobbyistas de eletrônica era a simplicidade. As portas de I/O davam acesso direto aos sinais da porta paralela. Bastava enviar um valor para a porta 0x378, e os respectivos bits acendiam lá na saída. Se fosse necessário input (e.g. chave, tecla ou encoder) bastava obter um valor da porta 0x379, o que causava a leitura dos sinais de status.

Por um curto período, por volta de 2007, fui professor num curso de engenharia mecatrônica. No final do semestre ensinava-se uns rudimentos de interação com hardware. Era basicamente uma caixinha com LEDs conectada à porta paralela, mais algumas explicações de como aquilo podia ser extrapolado para um motor de passo. Os olhos dos alunos brilhavam, quando viam um comando abstrato de software ter efeitos colaterais no mundo real. Hoje, teria utilizado esse "IoT" improvisado desde o primeiro dia, para atiçar a curiosidade dos estudantes.

Antes que alguém pergunte "por que vocês não usavam Arduino?", devo lembrar que o Arduino começou a ganhar popularidade por volta de 2009, 2010. O Raspberry I foi lançado em 2012. Para mexer com IoT sem ter de lidar com os áridos microcontroladores PIC ou 8051, a saída era literalmente a porta paralela.

O pessoal chegava a construir "placas de som", ou seja, um conversor DAC grosseiro com resistores. Para quem só tinha o alto-falante de 1 bit do PC, uma saída de som de 8 bits era o paraíso. Se não me engano, havia até drivers Windows e Linux para esse tipo de "placa de som" improvisada.

Em MS-DOS, manipular portas de I/O era algo trivial. Mas isso tinha um preço. Não era muito difícil queimar uma porta paralela, tanto por acidente quanto por programá-la incorretamente. A sensibilidade à queima variava de acordo com o fabricante, mas o risco estava sempre lá. E se queimar a placa paralela embutida na placa-mãe, obviamente não tem como trocar.

A porta SPP usa as mesmas 3 portas de I/O da porta "clássica". A bidirecionalidade é controlada por alguns bits de I/O vacantes no modo "clássico". A porta EPP utiliza um bloco de 5 a 8 portas de I/O. A porta ECP utiliza 6 portas divididas em dois blocos: as 3 portas clássicas, e 3 portas "altas" com endereços 0x400 acima.

Por padrão, as portas EPP e ECP iniciam emulando uma porta SPP, entrando em modos avançados apenas mediante configuração.

Programar a porta paralela diretamente via portas de I/O não é mais algo viável hoje em dia. Os sistemas operacionais não permitem mais fazer isso diretamente, é preciso instalar um driver. Como os PCs não vêm mais com portas paralelas, teríamos de usar adaptadores USB, mas estes servem exclusivamente para interfacear com impressoras, não expõem seu funcionamento interno via portas de I/O.

Sinais

A porta paralela possui os seguintes sinais de saída (do computador para o dispositivo):

E temos os seguintes sinais de status de entrada ou retorno (do dispositivo para o computador):

Na literatura, os sinais de controle emitidos pelo computador são chamados simplesmente de "sinais de controle" enquanto os sinais emitidos pelo periférico são chamados de "sinais de status".

Numa porta paralela IBM PC clássica com porta-base de I/O 0x378, os bits de dados estão mapeados na porta 0x378, e os sinais de controle estão mapeados nos bits LSB da porta 0x37A. Os sinais de status estão mapeados nos bits MSB da porta 0x379.

Nos modos "clássico" e SPP, todos os sinais de controle são controlados por software. Os rótulos dos sinais são meras sugestões, e o protocolo de comunicação pode usá-los como bem entender, embora as impressoras tendem a respeitar o padrão para máxima compatibilidade.

Mesmo assim, acredito que quase ninguém respeitava todos os sinais em sua totalidade, pois há muita coisa redundante e/ou obsoleta. Além do exemplo BUSY x nACK já citado, sinais como PRIME, AUTO_LF, SELECT_IN, nERROR não fazem muito sentido para muitos tipos de impressora. Por exemplo: o que significa o sinal PAPER_OUT quando a impressora tem três gavetas de papel?

Nos modos ECP e EPP, os sinais de controle e de status mudam totalmente de significado e passam a ser controlados por hardware. No modo EPP, dois sinais de status ficam sem uso oficial, e permanecem livres para uso via software.

Os protocolos ECP e EPP prevêem a comunicação de bytes de controle pelo barramento de dados, num estilo que lembra o protocolo I2C. Isto supre as necessidades de controle de forma infinitamente flexível (e.g. a impressora pode dizer qual das três gavetas de papel está vazia), obsoletando de vez o uso de fios extras para reportar condições de erro.

Uma vez que cada modo (clássico/SPP, ECP, EPP) usa os sinais de forma diferente, computador e periférico precisam estar alinhados para conseguirem comunicar-se. O padrão IEEE 1284 resolve o problema especificando um esquema de autonegociação através do uso "criativo" dos sinais de controle e status.

LapLink e PLIP

LapLink era um software de transferência de dados entre PCs, muito popular no início dos anos 1990, quando redes ainda eram relativamente raras. O LapLink suportava comunicação via porta serial, ou via porta paralela usando um cabo especial, com duas pontas DB-25, fornecido junto com o pacote.

Embora fosse uma gambiarra, o "cabo LapLink" era inegavelmente muito mais rápido que um cabo serial, e acabou virando um padrão de fato. Qualquer um com um ferro de solda podia construir o seu, e ele foi empregado em inúmeras outras soluções de transferência de dados.

Já o PLIP é um protocolo de rede ponto-a-ponto através da porta paralela, implementado no Linux, baseado numa implementação anterior de uma empresa chamada Crynwr.

A sigla é um trocadilho com o protocolo SLIP. Não era particularmente rápido (500kbps) mas era uma forma de brincar com rede e TCP/IP sem possuir hardware de rede (que era muito caro nos anos 1990). O driver PLIP ainda está presente em distribuições recentes, acredito eu que mais em respeito à história do que por real necessidade.

O "modo 0" do PLIP é compatível com o produto da Crynwr e com o cabo LapLink, que transfere apenas 4 bits de cada vez. Os bits D0 a D4 de um lado são conectados aos sinais de status ERROR, SELECT, PAPER OUT, nACK e BUSY do outro lado, respectivamente, estabelecendo um canal full-duplex de 4 bits mais handshake.

O "modo 1" tira partido de portas paralelas bidirecionais SPP ou melhores, transfere 8 bits de cada vez, porém pede um cabo diferente e com mais vias — e é apócrifo ao quadrado.

Referências

https://computer.howstuffworks.com/parallel-port2.htm
https://en.wikipedia.org/wiki/Parallel_port
https://en.wikipedia.org/wiki/IEEE_1284
http://wearcam.org/seatsale/programs/www.beyondlogic.org/spp/parallel.htm
http://wearcam.org/seatsale/programs/www.beyondlogic.org/epp/epp.htm
http://wearcam.org/seatsale/programs/www.beyondlogic.org/ecp/ecp.htm
https://docs.kernel.org/networking/plip.html
https://rus-linux.net/MyLDP/BOOKS/nag/node51.html https://www.plantation-productions.com/Webster/www.artofasm.com/DOS/ch21/CH21-1.html https://www.cs.unc.edu/~porter/courses/comp630/ref/an062_Updating_the_parallel_port.pdf