Para quem não conhece, o Projeto Gutenberg reune textos que estão no domínio público (na sua maioria) e foram digitados por voluntários.
Comemorando o seu 35o (!) aniversário, está sendo organizado o World eBook Fair. De 4 de julho a 4 de agosto mais de 300.000 eBooks estarão disponíveis para download gratuito. Além dos eBooks do projeto Gutenberg (que já são e continuarão sendo gratuitos), outras editoras estarão disponibilizando obras, como a Baen Books. A previsão é repetir o evento nos próximos anos, aumentando a quantidade de obras a cada ano.
quarta-feira, junho 28, 2006
NCSD.Net - Oficialmente
Novamente demorou somente 2 dias para o resultado do exame chegar à Microsoft. Já solicitei o "Welcome Kit" (certificado, cartão e broche) .
segunda-feira, junho 26, 2006
MCSD.Net
Passei hoje na prova que faltava para ser um Microsoft Certified Software Developper for Microsoft .Net. A prova foi "Developing and Implementing Windows-based Applications with Microsoft Visual C# .NET". Acabei não estudando muito devido ao curto tempo desde a prova anterior, um acúmulo de serviço e, principalmente, uma gripe irritante. Felizmente grande parte da matéria também fazia parte das provas anteriores. O resultado não foi brilhante, mas bem satisfatório (e mais que suficiente para a aprovação).
Próximos exames de certificação (upgrade para MCPD) só daqui a alguns meses. A família agradece...
Próximos exames de certificação (upgrade para MCPD) só daqui a alguns meses. A família agradece...
quarta-feira, junho 07, 2006
MCAD - Oficialmente
Desta vez as coisas funcionaram rápido e o resultado do exame que eu fiz dois dias atrás já chegou na Microsoft (teoricamente poderia demorar até duas semanas e no exame anterior demorou três).
Agora só falta receber o diploma pelo correio.
Agora só falta receber o diploma pelo correio.
terça-feira, junho 06, 2006
C# x VB.Net
Estou estudando para a prova de desenvolvimento de aplicações Windows pelo Self-Paced Training Kit da Microsoft, primeira edição. Não é um bom livro (mais sobre isto adiante), mas tem a curiosidade de abordar simultaneamente C# e VB.Net.
É claro que a maior parte de programação .Net consiste em usar as classes do .Net Framework, que são as mesmas para as duas linguagens. Entretanto, mesmo as construções normais das linguagens são quase idênticas, recursos que existem somente em uma delas são raras excessões. A diferença fica na somente sintaxe. Dada a minha vivência com C, não é surpresa que eu ache a sintaxe do VB.Net esquisita, particularmente o uso do fim de linha como terminador de comando.
O mais curioso foi que recentemente perguntei a um desenvolvedor que usa o VB.Net no dia a dia porque ele preferiu VB .Net a C# e a resposta foi que o C# oferece mais controle, sendo mais adequado para o desenvolvemento de componentes, porém o VB.Net tem maior produtividade, permitindo fazer mais coisas com menos linhas de código. Acredito que seja a manifestação de um efeito relatado no clássico The Hidden Persuaders, um livro da década de 50 sobre o marketing científico. Um fabricante de sabão em pó colocou o mesmo produto em duas embalagens, uma em suaves tons de azul e outra em um violento vermelho, e entregou para várias donas de casa testarem. Ao final do teste, quem recebeu a caixa azul disse que o produto era excelente, porém não tinha força suficiente para tirar as manchas mais pesadas. Já quem recebeu a caixa vermelha disse que o produto excelente, mas que não devia ser usado com roupas frágeis pois era muito forte!
Voltando ao livro, ele possui uma grande quantidade de erros de revisão, principalmente nos exemplos. Mais preocupante, encontrei um erro grave: na descrição de propriedades, o livro afirma que uma propriedade read-only precisa obrigatoriamente estar associada a um campo readonly da classe (no C# e VB .Net um campo readonly pode ser iniciado apenas na declaração ou no construtor da classe). Em primeiro lugar, é possível ter uma propriedade read-only que dá acesso de apenas leitura a um campo não readonly. Mais importante, uma propriedade não precisa estar associada a um campo. Uma propriedade é uma abstração que cria um membro que se comporta como um campo independente da forma como é implementado internamente.
Para quem tiver a curiosidade de saber porque comprei este livro, foi logo após o lançamento do Visual Studio .Net, em junho de 2002. Neste época existia pouca oferta de livros sobre C# e a descrição do livro é bastante interessante. O problema todo é na implementação...
21/jun/06: acertados alguns erros de digitação.
É claro que a maior parte de programação .Net consiste em usar as classes do .Net Framework, que são as mesmas para as duas linguagens. Entretanto, mesmo as construções normais das linguagens são quase idênticas, recursos que existem somente em uma delas são raras excessões. A diferença fica na somente sintaxe. Dada a minha vivência com C, não é surpresa que eu ache a sintaxe do VB.Net esquisita, particularmente o uso do fim de linha como terminador de comando.
O mais curioso foi que recentemente perguntei a um desenvolvedor que usa o VB.Net no dia a dia porque ele preferiu VB .Net a C# e a resposta foi que o C# oferece mais controle, sendo mais adequado para o desenvolvemento de componentes, porém o VB.Net tem maior produtividade, permitindo fazer mais coisas com menos linhas de código. Acredito que seja a manifestação de um efeito relatado no clássico The Hidden Persuaders, um livro da década de 50 sobre o marketing científico. Um fabricante de sabão em pó colocou o mesmo produto em duas embalagens, uma em suaves tons de azul e outra em um violento vermelho, e entregou para várias donas de casa testarem. Ao final do teste, quem recebeu a caixa azul disse que o produto era excelente, porém não tinha força suficiente para tirar as manchas mais pesadas. Já quem recebeu a caixa vermelha disse que o produto excelente, mas que não devia ser usado com roupas frágeis pois era muito forte!
Voltando ao livro, ele possui uma grande quantidade de erros de revisão, principalmente nos exemplos. Mais preocupante, encontrei um erro grave: na descrição de propriedades, o livro afirma que uma propriedade read-only precisa obrigatoriamente estar associada a um campo readonly da classe (no C# e VB .Net um campo readonly pode ser iniciado apenas na declaração ou no construtor da classe). Em primeiro lugar, é possível ter uma propriedade read-only que dá acesso de apenas leitura a um campo não readonly. Mais importante, uma propriedade não precisa estar associada a um campo. Uma propriedade é uma abstração que cria um membro que se comporta como um campo independente da forma como é implementado internamente.
Para quem tiver a curiosidade de saber porque comprei este livro, foi logo após o lançamento do Visual Studio .Net, em junho de 2002. Neste época existia pouca oferta de livros sobre C# e a descrição do livro é bastante interessante. O problema todo é na implementação...
21/jun/06: acertados alguns erros de digitação.
segunda-feira, junho 05, 2006
Desenvolvedor de Aplicativos Certificado Microsoft (MCAD)
Bem, ainda falta a minha nota chegar até a Microsoft (da última vez demorou algumas semanas e precisou de um cutucão), mas com a prova de hoje (exame 70-320 - Developing XML Web Services and Server Components with Microsoft Visual C#) completei os requisitos.
Eu estudei principalmente pelo Training Guide da Que, de autoria do Amit Kalani. O livro é muito bom, mas não deixa de ser um resumo. Cada um dos onze captítulos merece um livro a parte (e tenho quase certeza que existem todos estes livros). O livro contém uma quantidade generosa de exercícios práticos e vem com um CD com uma versão eletrônica do livro e um simulado demo (com 60 questões).
Eu estava muito confiante na vespera, tendo ido muito bem no simulado impresso do livro e razoavelmente bem no simulado do CD. No início da prova, como de costume, deu aquele susto de ver algumas coisas que eu nem sabia o que era... No final eu estava confiante de ter passado, mas por pouco. Nova surpresa ao ver o resultado: aparentemente a cultura geral e o bom senso (e provavelmente um pouco de sorte) funcionaram e um tirei um notão (devo ter errado somente três ou quatro questões das 43).
A principal dificuldade do exame é que ele cobre muita coisa e várias questões são sobre detalhes. Além disso, a redação das perguntas é muitas vezes confusa. Teve uma única questão que eu achei bastante fora do assunto (dizia respeito a uma propriedade de uma classe não relacionada diretamente a Web Services ou Server Components).
Bem, daqui a 3 semanas faço o último exame para obter a certificação MCSD .Net. Só para não esquecer, estas duas certificações já ficaram obsoletas com o lançamento do .Net Framework 2.0. No segundo semestre tento a sorte com os exames de upgrade.
Eu estudei principalmente pelo Training Guide da Que, de autoria do Amit Kalani. O livro é muito bom, mas não deixa de ser um resumo. Cada um dos onze captítulos merece um livro a parte (e tenho quase certeza que existem todos estes livros). O livro contém uma quantidade generosa de exercícios práticos e vem com um CD com uma versão eletrônica do livro e um simulado demo (com 60 questões).
Eu estava muito confiante na vespera, tendo ido muito bem no simulado impresso do livro e razoavelmente bem no simulado do CD. No início da prova, como de costume, deu aquele susto de ver algumas coisas que eu nem sabia o que era... No final eu estava confiante de ter passado, mas por pouco. Nova surpresa ao ver o resultado: aparentemente a cultura geral e o bom senso (e provavelmente um pouco de sorte) funcionaram e um tirei um notão (devo ter errado somente três ou quatro questões das 43).
A principal dificuldade do exame é que ele cobre muita coisa e várias questões são sobre detalhes. Além disso, a redação das perguntas é muitas vezes confusa. Teve uma única questão que eu achei bastante fora do assunto (dizia respeito a uma propriedade de uma classe não relacionada diretamente a Web Services ou Server Components).
Bem, daqui a 3 semanas faço o último exame para obter a certificação MCSD .Net. Só para não esquecer, estas duas certificações já ficaram obsoletas com o lançamento do .Net Framework 2.0. No segundo semestre tento a sorte com os exames de upgrade.
sexta-feira, maio 26, 2006
Sério ou Brincadeira?
Vi no Newsgroups do Technet o link abaixo
http://www.certifai.xpg.com.br/index.php
dei uma olhada no site e não consegui decidir se é ou não uma brincadeira. Será que alguém pagaria R$50 por um transcript MCP falso? (Para quem não conhece, o transcript MCP é uma folha com a relação das provas de certificação Microsoft que você fez, você imprime no seu próprio micro acessando um site da Microsoft).
Ah sim, é claro que ser for sério é ilegal, imoral, etc.
Agora vou voltar aos meus estudos para obter o meu certificado à moda antiga.
http://www.certifai.xpg.com.br/index.php
dei uma olhada no site e não consegui decidir se é ou não uma brincadeira. Será que alguém pagaria R$50 por um transcript MCP falso? (Para quem não conhece, o transcript MCP é uma folha com a relação das provas de certificação Microsoft que você fez, você imprime no seu próprio micro acessando um site da Microsoft).
Ah sim, é claro que ser for sério é ilegal, imoral, etc.
Agora vou voltar aos meus estudos para obter o meu certificado à moda antiga.
sexta-feira, maio 12, 2006
Certificação
Como mencionei em 10 de janeiro, estou a um exame da certificação MCAD e a dois exames da MCSD .Net (ambas já obsoletas). Graças às promoções do TechNet Brasil, tenho vouchers para exames gratuitos válidos até 1/julho. Portanto criei coragem e marquei o exame 70-320 para o começo de junho. Se sobrar fôlego, vou tentar também o 70-316.
Portanto, agora é "crunch time" e os posts aqui e no Wiki C/C++ Brasil vão ficar ainda mais escassos.
Portanto, agora é "crunch time" e os posts aqui e no Wiki C/C++ Brasil vão ficar ainda mais escassos.
sexta-feira, maio 05, 2006
sexta-feira, abril 28, 2006
Bugs Terríveis de Achar - Execução Paranormal de Código
Os dois últimos dias foram de uma busca frenética atrás de um bug.
O bug se apresentou em um firmware que estamos desenvolvendo para um dispositivo e que roda em um microcontrolador. A programação deste tipo (sistema embarcado) é bem diferente da programação normal para PC. Como é comum nestes casos, o firmware é gravado em uma memória não volátil (memória Flash) dentro do próprio microcontrolador. Esta gravação é feita por um software de PC, através de um gravador ligado à porta paralela do PC e a determinados pinos do microcontrolador.
Uma segunda memória não volátil (EEProm), externa ao microcontrolador, é usada para manter dados não voláteis, alguns deles extremamente críticos para a operação (como o número de série do dispositivo). A gravação na EEProm requer uma série de passos: é preciso habilitar a gravação, enviar o comando de gravação, o endereço e o dado. Não é algo que possa acontecer por conta própria.
No processo de produção dos dispositivos, é gravado primeiro um software de teste no microcontrolador. Através de uma serial de debug, são feitos testes e gravadas as informações críticas. Após isto é gravado o firmware normal.
Bem, após a produção de 140 dispositivos, verificou-se que cerca de uma dúzia estava com número de série incorreto. Pânico! Uma primeira hipótese, erro de operação na produção, parece improvável dado a taxa de erros. Restam o software de teste estar gravando algo errado ou, pânico maior, o firmware normal estar destruindo as informações na EEProm. Por outro lado, este efeito nunca tinha sido observado com as duas dezenas de protótipos.
Uma primeira revisão do firmware mostra que a EEProm é gravada em poucos pontos. Segue-se uma discussão filosófica sobre a necessidade e conveniência destes pontos. Faz sentido colocar um número de série default em caso erro de checksum na EEProm? A conclusão é que o firmware normal deve evitar ao máximo gravar na região onde estão os parâmetros mais críticos. Entretanto, mudar isto antes de descobrir o que está acontecendo pode apenas mascarar um problema sério.
A decisão é acrescentar um teste para tentar pegar se o número de série está danificado. Se sim, acender um LED de erro e preservar o conteúdo da EEProm para ver se dá uma pista do que ocorre. Em seguida, tentar reproduzir o problema, refazendo o procedimento de produção com esta nova versão.
Feito o procedimento com 20 dispositivos, em 2 ocorre o erro. É uma boa notícia: o problema pode ser reproduzido.
Alguns testes mostram que o software de teste está gravando os valores corretos na EEProm. Hora de ativar os traces do firmware e observar as informações enviadas pela serial. Após alguma tentativas, verifica-se que a corrupção da EEProm ocorre logo após a carga do firmware.
O teste começa a ficar mais complicado. É preciso prestar atenção no trace enviado pelo dispositivo quando ele é re-iniciado após a carga. É um problema esporádico, às vezes ocorre apenas após muitas tentativas. Para dificultar, às vezes ocorre um erro na verificação feita após a gravação. Outras vezes, a execução do firmware não acontece ao final da gravação e verificação, sendo preciso esticar o braço e desligar e re-ligar o dispositivo.
Prestando mais atenção, percebe-se que o firmware executa mesmo quando ocorre um erro na verificação. Em uma destas ocasiões, o conteúdo da EEProm é danificado. Primeira teoria: o firmware executado estava danificado de uma forma que causou a gravação incorreta da EEProm. Segue-se uma discussão de como o firmware pode descobrir que está gravado errado e não executar neste caso (a técnica tradicional é colocar um checkum no código, obviamente não resolve se a rotina de verificação estiver danificada).
Segue-se mais bateria de testes, tentando ver se sempre que a EEProm é danificada ocorreu erro na verificação. Alguns minutos depois, teoria abalada: a EEprom foi corrompida sem que tivesse ocorrido erro de verificação.
Para tentar cercar mais o problema, coloquei na rotina de gravação da EEProm (no mais baixo nível) um teste do endereço de gravação. Se for o endereço do número de série, ao invés de gravar envia um ! para a serial. Mais algumas tentativas e aparece !!! isolado, sem os demais traces...
Olhando com mais atenção ainda, percebemos que existe alguma atividade no dispositivo durante a verificação da gravação, quando o processador devia estar parado. Nova teoria: existe algo errado no processo de gravação e verificação, que faz o processador iniciar a execução antes da hora e de forma "meio torta".
Para comprovar, coloquei uma variável que é iniciada com zero e incrementada a cada passo da iniciação do software. Na rotina de escrita na EEProm, acrescentei um teste: se não tiverem sido executados todos os passos da iniciação, envia pela serial @ seguido do valor do contador. Alguns poucos testes são suficientes para ver alguns @0 e @1 surgirem durante a verificação. Execução paranormal: a rotina de gravação está sendo executada desrespeitando o fluxo normal da execução.
Hora de reclamar do gravador para o projetista do hardware. Aparentemente o processador está recebendo um sinal de reset fora de hora. Após algumas tentativas de achar uma explicação no software para o comportamento anormal, decide-se colocar um capacitorzinho no sinal de reset que vem do gravador (algo como dar um tempinho em software). Antes de soldar o capacitor, o técnico decidiu verificar o cabo. Tinha um mau contato no pino de reset. Testes com um outro cabo e com o cabo com o mau contato eliminado confirmam que o problema sumiu.
Resumindo, um mau contato no cabo usado para gravar o firmware fazia com que ocasionalmente o sinal de reset "balança-se" durante a verificação da gravação. Isto deixava o processador meio "bêbado" e ele saia executando errado o firmware.
Agora é só eliminar todos os problemas potenciais que identificamos enquanto procurávamos o bug que não existia.
O bug se apresentou em um firmware que estamos desenvolvendo para um dispositivo e que roda em um microcontrolador. A programação deste tipo (sistema embarcado) é bem diferente da programação normal para PC. Como é comum nestes casos, o firmware é gravado em uma memória não volátil (memória Flash) dentro do próprio microcontrolador. Esta gravação é feita por um software de PC, através de um gravador ligado à porta paralela do PC e a determinados pinos do microcontrolador.
Uma segunda memória não volátil (EEProm), externa ao microcontrolador, é usada para manter dados não voláteis, alguns deles extremamente críticos para a operação (como o número de série do dispositivo). A gravação na EEProm requer uma série de passos: é preciso habilitar a gravação, enviar o comando de gravação, o endereço e o dado. Não é algo que possa acontecer por conta própria.
No processo de produção dos dispositivos, é gravado primeiro um software de teste no microcontrolador. Através de uma serial de debug, são feitos testes e gravadas as informações críticas. Após isto é gravado o firmware normal.
Bem, após a produção de 140 dispositivos, verificou-se que cerca de uma dúzia estava com número de série incorreto. Pânico! Uma primeira hipótese, erro de operação na produção, parece improvável dado a taxa de erros. Restam o software de teste estar gravando algo errado ou, pânico maior, o firmware normal estar destruindo as informações na EEProm. Por outro lado, este efeito nunca tinha sido observado com as duas dezenas de protótipos.
Uma primeira revisão do firmware mostra que a EEProm é gravada em poucos pontos. Segue-se uma discussão filosófica sobre a necessidade e conveniência destes pontos. Faz sentido colocar um número de série default em caso erro de checksum na EEProm? A conclusão é que o firmware normal deve evitar ao máximo gravar na região onde estão os parâmetros mais críticos. Entretanto, mudar isto antes de descobrir o que está acontecendo pode apenas mascarar um problema sério.
A decisão é acrescentar um teste para tentar pegar se o número de série está danificado. Se sim, acender um LED de erro e preservar o conteúdo da EEProm para ver se dá uma pista do que ocorre. Em seguida, tentar reproduzir o problema, refazendo o procedimento de produção com esta nova versão.
Feito o procedimento com 20 dispositivos, em 2 ocorre o erro. É uma boa notícia: o problema pode ser reproduzido.
Alguns testes mostram que o software de teste está gravando os valores corretos na EEProm. Hora de ativar os traces do firmware e observar as informações enviadas pela serial. Após alguma tentativas, verifica-se que a corrupção da EEProm ocorre logo após a carga do firmware.
O teste começa a ficar mais complicado. É preciso prestar atenção no trace enviado pelo dispositivo quando ele é re-iniciado após a carga. É um problema esporádico, às vezes ocorre apenas após muitas tentativas. Para dificultar, às vezes ocorre um erro na verificação feita após a gravação. Outras vezes, a execução do firmware não acontece ao final da gravação e verificação, sendo preciso esticar o braço e desligar e re-ligar o dispositivo.
Prestando mais atenção, percebe-se que o firmware executa mesmo quando ocorre um erro na verificação. Em uma destas ocasiões, o conteúdo da EEProm é danificado. Primeira teoria: o firmware executado estava danificado de uma forma que causou a gravação incorreta da EEProm. Segue-se uma discussão de como o firmware pode descobrir que está gravado errado e não executar neste caso (a técnica tradicional é colocar um checkum no código, obviamente não resolve se a rotina de verificação estiver danificada).
Segue-se mais bateria de testes, tentando ver se sempre que a EEProm é danificada ocorreu erro na verificação. Alguns minutos depois, teoria abalada: a EEprom foi corrompida sem que tivesse ocorrido erro de verificação.
Para tentar cercar mais o problema, coloquei na rotina de gravação da EEProm (no mais baixo nível) um teste do endereço de gravação. Se for o endereço do número de série, ao invés de gravar envia um ! para a serial. Mais algumas tentativas e aparece !!! isolado, sem os demais traces...
Olhando com mais atenção ainda, percebemos que existe alguma atividade no dispositivo durante a verificação da gravação, quando o processador devia estar parado. Nova teoria: existe algo errado no processo de gravação e verificação, que faz o processador iniciar a execução antes da hora e de forma "meio torta".
Para comprovar, coloquei uma variável que é iniciada com zero e incrementada a cada passo da iniciação do software. Na rotina de escrita na EEProm, acrescentei um teste: se não tiverem sido executados todos os passos da iniciação, envia pela serial @ seguido do valor do contador. Alguns poucos testes são suficientes para ver alguns @0 e @1 surgirem durante a verificação. Execução paranormal: a rotina de gravação está sendo executada desrespeitando o fluxo normal da execução.
Hora de reclamar do gravador para o projetista do hardware. Aparentemente o processador está recebendo um sinal de reset fora de hora. Após algumas tentativas de achar uma explicação no software para o comportamento anormal, decide-se colocar um capacitorzinho no sinal de reset que vem do gravador (algo como dar um tempinho em software). Antes de soldar o capacitor, o técnico decidiu verificar o cabo. Tinha um mau contato no pino de reset. Testes com um outro cabo e com o cabo com o mau contato eliminado confirmam que o problema sumiu.
Resumindo, um mau contato no cabo usado para gravar o firmware fazia com que ocasionalmente o sinal de reset "balança-se" durante a verificação da gravação. Isto deixava o processador meio "bêbado" e ele saia executando errado o firmware.
Agora é só eliminar todos os problemas potenciais que identificamos enquanto procurávamos o bug que não existia.
quinta-feira, abril 20, 2006
Sinais de Um Programa Ruim
Esbarrei com um artigo interessante sobre sinais no código fonte que indicam um programa problemático. Para quem não tiver paciência de ler o artigo todo, eis a lista de sinais:
Se você precisar dar manutenção em um software, verifique antes os sinais. Se forem muitos, considere seriamente fazer um refactoring (mas pense muito antes de reescrever tudo).
- Comentários ausentes ou ruins
- Nomes inapropriados
- Formatação inconsistente do fonte
- Falta de teste de códigos de retorno e de erros em geral
- Repetições de código
- Falta de clareza
- Complicações desnecessárias
- Condições assumidas não documentadas
- Substituição das funções das bibliotecas padrões por funções próprias
- Falta de suporte à depuração
Se você precisar dar manutenção em um software, verifique antes os sinais. Se forem muitos, considere seriamente fazer um refactoring (mas pense muito antes de reescrever tudo).
quarta-feira, abril 19, 2006
GPF - Grilo Pulsante Fantasma
A foto acima é do brinqedinho que levei no Segundo Encontro de Programadores C/C++ em São Paulo. Como a regua e o cartão mostram, é um circuito bastante pequeno, onde os maiores componentes são a bateria, o buzzer (uma espécie de alto falante sem imã) e o resistor sensível a luz (LDR).O componente mais importante, entretanto, é o PIC 12F675. Trata-se de um microcontrolador, um computardor quase completo dentro de um chip. Este modelo possui 1024 palavras para armazenamento de programa (Flash), 64 bytes de Ram para variáveis e 128 bytes de memória não volátil para dados (EEProm). O processador utiliza um conjunto de apenas 35 instruções. Neste projeto usei o clock interno de 4 MHz, o componente permite usar um cristal externo de até 20MHz. Possui um modo sleep, útil a circuitos a bateria, que reduz o consumo de energia a quase zero.
O microcontrolador possui uma quantidade grande de recursos. Possui internamente dois timers, que podem ser usados para gerar interrupções periódicas, fornecendo uma base tempo para o software. Seis dos oito pinos podem ser tratados como entrada ou saída digital (isto é, serem colocados em nível lógico "0" ou "1" por controle do software). Quatro dos pinos podem ser usados como entradas analógicas (o software pode ler o nível do sinal do pino como um valor digital de 8 ou 10 bits).
O objetivo do circuito era mostar os potenciais do microcontrolador e o fato dele poder até ser programado em C. Inspirado em um exemplo do fabricante do PIC, é um circuito para ser escondido em um lugar e perturbar as pessoas presentes. O circuito fica a maior parte do tempo dormindo. Em tempos aleatórios ele acorda e faz um pequeno bip (daí o grilo pulsante). Para tornar a detecção mais difícil, o bip é feito somente se o circuito estiver no escuro (daí o fantasma). O LED (que também só é acionado no escuro), permite confirmar que o circuito está ligado. Por último, um botão permite testar o circuito, soando o bip e piscando o LED. Desta forma, o cicuito usa:
- uma entrada digital (o botão)
- duas saídas digitais (o LED e o buzzer)
- uma entrada analógica (o sensor de luz)
- um timer para acordar o circuito periodicamente
- um timer para fornecer a temporização para a geração da frequência enviada ao buzzer.
O custo total do circuito fica abaixo de R$50. O PIC custa menos de R$15, comprado unitariamente em uma loja. O preço USA, para 100 peças é USD 1,19.
Quando se fala em microprocessadores, a maioria das pessoas pensa imediatamente em computadores de mesa. Entretanto a grande revolução está nos microcontroladores, que permitem acrescentar inteligência a equipamentos por um baixo custo. A nossa casa está repleta deles, escondidos em geladeiras, máquinas de lavar, micro-ondas, TVs, DVDs, etc.
segunda-feira, abril 17, 2006
Livros do mês
Um dos meus motivadores para aprender inglês foi a coleção de livros do meu pai, principalmente os de fição científica. A minha primeira leitura de verdade em inglês foi a trilogia original da Fundação de Isac Asimov (Foundation, Foundation and Empire e Second Foundation).
Embora isto tenho sido há muito tempo atrás, ainda existem alguns livros da coleção do meu pai que não tinha lido. Um deles era o clássico (infelizmente esgotado) The Weapon Shops of Isher de A. E. Van Vogt. Algumas idéias podem hoje parecer chavão, mas provavelmente eram novidade quando o livro foi escrito. É um daqueles livros que prende o leitor, você fica sempre querendo saber o que vai acontecer. De quebra tem um tradicional paradoxo de viagem no tempo, com o personagem que só existe no curto intervalo de tempo entre ele chegar do futuro e voltar ao passado.
Ao devolver este livro acabei pegando para reler The Double Helix de James D. Watson. São as recordações da descoberta da estrutura do DNA (que de forma não esperada esclareceu o processo de duplicação dos genes). O livro não se limita aos aspectos técnicos, tratando muito da questão do relacionamento entre os envolvidos e da concorrência versus cooperação. Mostra um pouco como funciona internamente o meio científico e as suas motivações.
Resumindo uma longa história em um único parágrafo, a estrutura do DNA foi descoberta por James Watson e Francis Crick após um período relativamente curto de estudos, a partir de dados experimentais (fotografias por raio-X de cristais de DNA) obtidos por Maurice Wilkins e Rosalind Franklin num trabalho bem mais demorado. Watson e Crick utilizaram principalmente a montagem de modelos, técnica usada anteriormente por Linus Pauling para descobrir a estrutura dos amino-ácidos e desprezada por Wilkins e Rosalind. Para complicar mais a situação, as principais fotografias usadas foram tiradas por Rosalind, e usadas sem o seu conhecimento, devido a problemas de relacionamento com os demais. Watson, Crick e Wilkins vieram ganhar o prêmio Nobel por esta descoberta (e outras relacionadas), porém Rosalind morreu alguns anos antes. Embora alguns considerem Rosalind uma injustiçada, prefiro a versão presente na Wikipedia.
Embora isto tenho sido há muito tempo atrás, ainda existem alguns livros da coleção do meu pai que não tinha lido. Um deles era o clássico (infelizmente esgotado) The Weapon Shops of Isher de A. E. Van Vogt. Algumas idéias podem hoje parecer chavão, mas provavelmente eram novidade quando o livro foi escrito. É um daqueles livros que prende o leitor, você fica sempre querendo saber o que vai acontecer. De quebra tem um tradicional paradoxo de viagem no tempo, com o personagem que só existe no curto intervalo de tempo entre ele chegar do futuro e voltar ao passado.
Ao devolver este livro acabei pegando para reler The Double Helix de James D. Watson. São as recordações da descoberta da estrutura do DNA (que de forma não esperada esclareceu o processo de duplicação dos genes). O livro não se limita aos aspectos técnicos, tratando muito da questão do relacionamento entre os envolvidos e da concorrência versus cooperação. Mostra um pouco como funciona internamente o meio científico e as suas motivações.
Resumindo uma longa história em um único parágrafo, a estrutura do DNA foi descoberta por James Watson e Francis Crick após um período relativamente curto de estudos, a partir de dados experimentais (fotografias por raio-X de cristais de DNA) obtidos por Maurice Wilkins e Rosalind Franklin num trabalho bem mais demorado. Watson e Crick utilizaram principalmente a montagem de modelos, técnica usada anteriormente por Linus Pauling para descobrir a estrutura dos amino-ácidos e desprezada por Wilkins e Rosalind. Para complicar mais a situação, as principais fotografias usadas foram tiradas por Rosalind, e usadas sem o seu conhecimento, devido a problemas de relacionamento com os demais. Watson, Crick e Wilkins vieram ganhar o prêmio Nobel por esta descoberta (e outras relacionadas), porém Rosalind morreu alguns anos antes. Embora alguns considerem Rosalind uma injustiçada, prefiro a versão presente na Wikipedia.
segunda-feira, abril 03, 2006
C e C++
No Wiki do "C/C++ Brasil" está em discussão o nome do grupo. Um ponto sempre lembrado é o desejo de manter o C no nome, e nesta hora me sinto meio culpado, já que às vezes sinto que sou o único do grupo que programa no dia a dia em C.
Isto não significa que eu não tenha estudado e continue estudando C++. Ainda outro dia eu tomei um susto ao abrir um livro de C++ (de 94) e descobrir que eu não só tinha lido como tinha feito correções nos exemplos. E afinal, eu passei no exame de Visual C++ da Microsoft.
Na verdade, comecei a ter algum interesse em C++ no final dos anos 80. Nesta época chegamos a comprar na Humana uma cópia de um dos primeiros compiladores C++ para o DOS, o Zortech (que alguns anos depois foi comprada pela Symantec). A Borland foi uma grande divulgadora do C++, com o Turbo C++ e o Borland C++; lembro de um vídeo da Borland chamado "The World of Objects" (ou algo parecido). Em 92 a Humana fez um primeiro projeto em C++, usando o Microsoft C/C++ 7.0 (o primeiro compilador C++ da Microsoft).
Na Seal, fizemos alguns projetos com o Visual C++ 2.0 para serem rodados no NT 3.1 (ambos novidade na época). Alguns dos meu programas usavam até a MFC (então na versão 3.0). A maioria dos desenvolvimentos na Seal era feito em Visual C++ 1.5, para coletores de dados com sistema DOS. Eventualmente alguem teve a idéia de fazer uma biblioteca de classes para facilitar o desenvolvimento para os coletores. Embora eu não estivesse na época trabalhando na área de software, alguem me passou a especificação para dar os meus palpites. A especificação começava com uma classe CString (como se o VC 1.5 já não tivesse duas classes de string) e terminava com uma classe CUtil cujos membros eram funções diversas (para deixar tudo orientado a objeto?). No final a classe CUtil foi abandonada, mas a CString ficou lá.
Foi lendo esta especificação e a coluna de dúvidas de C++ do Microsoft System Journal que eu concluí que conceitualmente o C++ é bem mais pesado que o C. Recentemente escrevi um artigo sobre construtores no Wiki, e foi um trabalho bastante árduo para descrever algo que é simplesmente básico (quem usa C++ no dia a dia tem que ter tudo isto e muito mais na ponta da lingua). Talvez por isso eu continue usando C mesmo quando o C++ é uma opção disponível. O fato de eu estar cercado de outros programadores C também contribui, principalmente porque eu sempre tenho a esperança de deixar a manutenção para eles.
Isto não significa que eu não tenha estudado e continue estudando C++. Ainda outro dia eu tomei um susto ao abrir um livro de C++ (de 94) e descobrir que eu não só tinha lido como tinha feito correções nos exemplos. E afinal, eu passei no exame de Visual C++ da Microsoft.
Na verdade, comecei a ter algum interesse em C++ no final dos anos 80. Nesta época chegamos a comprar na Humana uma cópia de um dos primeiros compiladores C++ para o DOS, o Zortech (que alguns anos depois foi comprada pela Symantec). A Borland foi uma grande divulgadora do C++, com o Turbo C++ e o Borland C++; lembro de um vídeo da Borland chamado "The World of Objects" (ou algo parecido). Em 92 a Humana fez um primeiro projeto em C++, usando o Microsoft C/C++ 7.0 (o primeiro compilador C++ da Microsoft).
Na Seal, fizemos alguns projetos com o Visual C++ 2.0 para serem rodados no NT 3.1 (ambos novidade na época). Alguns dos meu programas usavam até a MFC (então na versão 3.0). A maioria dos desenvolvimentos na Seal era feito em Visual C++ 1.5, para coletores de dados com sistema DOS. Eventualmente alguem teve a idéia de fazer uma biblioteca de classes para facilitar o desenvolvimento para os coletores. Embora eu não estivesse na época trabalhando na área de software, alguem me passou a especificação para dar os meus palpites. A especificação começava com uma classe CString (como se o VC 1.5 já não tivesse duas classes de string) e terminava com uma classe CUtil cujos membros eram funções diversas (para deixar tudo orientado a objeto?). No final a classe CUtil foi abandonada, mas a CString ficou lá.
Foi lendo esta especificação e a coluna de dúvidas de C++ do Microsoft System Journal que eu concluí que conceitualmente o C++ é bem mais pesado que o C. Recentemente escrevi um artigo sobre construtores no Wiki, e foi um trabalho bastante árduo para descrever algo que é simplesmente básico (quem usa C++ no dia a dia tem que ter tudo isto e muito mais na ponta da lingua). Talvez por isso eu continue usando C mesmo quando o C++ é uma opção disponível. O fato de eu estar cercado de outros programadores C também contribui, principalmente porque eu sempre tenho a esperança de deixar a manutenção para eles.
quinta-feira, março 30, 2006
Yes, nós temos livrarias!
Sou fã de longa data da Amazon, e costumo elogiá-la com frequência. Entretanto, sou fã de mais longa data da Livraria Cultura, desde quando não existia a Internet e a única loja deles era no Conjunto Nacional.
Dando uma olhada ontem, percebi uma novidade: livros usados. Diferente da Amazon, que somente intermedia a venda de livros usados, a Cultura recompra livros em bom estado (comprados nos últimos 6 meses) por 25% do preço original e os revende. Fiz uma experiência com o mais recente Asterix e recebi um exemplar em excelente condições pela metade do preço. E a entrega foi no mesmo dia (coloquei o pedido às 12:50, saiu de lá às 15:14 e foi entregue no começo da noite).
Reforço a minha sugestão de sempre: antes de comprar um livro na Amazon, dê uma pesquisada nas livrarias nacionais.
Dando uma olhada ontem, percebi uma novidade: livros usados. Diferente da Amazon, que somente intermedia a venda de livros usados, a Cultura recompra livros em bom estado (comprados nos últimos 6 meses) por 25% do preço original e os revende. Fiz uma experiência com o mais recente Asterix e recebi um exemplar em excelente condições pela metade do preço. E a entrega foi no mesmo dia (coloquei o pedido às 12:50, saiu de lá às 15:14 e foi entregue no começo da noite).
Reforço a minha sugestão de sempre: antes de comprar um livro na Amazon, dê uma pesquisada nas livrarias nacionais.
quarta-feira, março 29, 2006
Covers, versões, remakes etc
Ontem (28/mar/06) , o Jornal da Tarde falava um pouco sobre covers, na esteira de apresentações no Sesc Santana de bandas covers dos Beatles, The Who e Mutantes.
Conforme detalhado no link acima, covers não são uma novidade e existe uma certa polêmica sobre como catalogá-los. Alguns interpretes tentam copiar até a aparência do interprete original (como a maioria dos Elvis impersonators). Outras se concentram em procurar reproduzir ao vivo o som original (por exemplo, o The Australian Pink Floyd Show). Alguns grupos até tentam reproduzir mais de uma banda ao mesmo tempo (como a Beatallica).
Em alguns casos, o material original é usado apenas como ponto de partida. Isto funciona particularmente bem com as músicas dos Beatles, onde é bastante difícil fazer algo melhor com um arranjo parecido com o original. Como exemplo, recomendo o disco Tribute do Rick Wakeman, que você encontra por aí por menos de R$10.
Conforme detalhado no link acima, covers não são uma novidade e existe uma certa polêmica sobre como catalogá-los. Alguns interpretes tentam copiar até a aparência do interprete original (como a maioria dos Elvis impersonators). Outras se concentram em procurar reproduzir ao vivo o som original (por exemplo, o The Australian Pink Floyd Show). Alguns grupos até tentam reproduzir mais de uma banda ao mesmo tempo (como a Beatallica).
Em alguns casos, o material original é usado apenas como ponto de partida. Isto funciona particularmente bem com as músicas dos Beatles, onde é bastante difícil fazer algo melhor com um arranjo parecido com o original. Como exemplo, recomendo o disco Tribute do Rick Wakeman, que você encontra por aí por menos de R$10.
sexta-feira, março 17, 2006
Segundo Encontro de Programadores C e C++ em São Paulo
Já está agendado o Segundo Encontro de Programadores C e C++ em São Paulo: Sábado, 25/03/06 a partir das 14:00 na Casa do Espeto. Maiores detalhes no Wiki C/C++.
quarta-feira, março 15, 2006
A Dura Vida de Usuário de Computador
Nos artigos americanos é bastante comum se referirem à mãe com um exemplo de usuário comum. No meu caso, minha mãe (felizmente) não usa computador. Entretanto, meu pai usa. Não é um exatamente um usuário comum, mas sofre com frequência com as coisas incompreensíveis que os softwares fazem.
Há pouco mais de um ano, ele comprou o Norton System Works. No começos dos anos 80, Peter Norton era um colunista da recém criada PC magazine que colocou à venda um utilitário para recuperar arquivos apagados. Ao primeiro utilitário se seguiram outros, surgindo o Norton Utilities. Com o passar dos anos os utilitários passaram do DOS para o Windows, a empresa foi comprada pela Symantec e até a tradicional foto do Peter Norton de braços cruzados sumiu dos anúncios e embalagens.
Algum tempo atrás o System Works começou a reclamar que uma assinatura estava vencida. segundo as instruções da tela, meu pai acabou caindo na loja on line, onde comprou e fez o download de uma atualização do System Works. Entretanto, o software continuou reclamando da assinatura e meu pai acabou comprando também a renovação de assinatura do antivirus em separado (ele achou que era apenas R$39, mas no caso da renovação de assinatura os preços no site brasileiro são em US$!). Entretanto, o software continuou reclamando que a assinatura estava vencida. Além disso, volta e meia aparecia uma tela do Windows Installer, tentando instalar algo. Após algum tempo aparecia uma mensagem de erro dizendo que o arquivo de instalação devia ser rodado a partir do Setup. Foi neste ponto que ele entregou os pontos e me chamou.
O primeiro ponto que eu percebi foi que o System Works não estava atualizado. A primeira ideia foi tentar rodar novamente o instalador. Entretanto, meu pai não sabia aonde ele tinha sido colocado. Na FAQ do site da Symantec as soluções para este problema (aparentemente comum) são olhar no diretório selecionado no Save As ou então, se o usuário souber o nome do arquivo do instalador, usar o File Search. É claro que se meu pai soubesse em qual diretório tinha recebido o arquivo nós não precisaríamos olhar no FAQ. E se eles próprios não sabem dizer o nome do arquivo, como esperar que nós soubessemos? (No final o arquivo se chama Setup.exe, como dezenas de outros, portanto o File Search não seria muito útil). O e-mail de confirmação do pedido tem um link para refazer o download, com as instruções de digitar o número do pedido e a senha. É claro que na página apontada pelo link não tinha nenhum lugar para fazer downloda ou entrar com estas informações. Após navegar por algumas páginas achamos a página de download, conseguimos lembrar a senha e fazer o download do Setup.exe.
O Setup instala um gerenciador de download que faz o download do software propriamente dito (quase 100M). Pausa para visitar a geladeira. Terminado o download é hora da instalação (seguida de um tradicional restart). O passo seguinte (automático, como tudo mais) é ativar e registrar o produto. Entretanto, o micro do meu pai não se conecta diretamente à internet quando entra no ar, é preciso chamar o "discador" do Speedy manualmente (um procedimento teoricamente sensato). Logo a primeira tentativa não teve sucesso. Feita a conexão à internet, foi preciso umas 3 tentativas para ter sucesso na conexão ao servidor da Symantec. O programa apresenta então um a lista de providências 'urgentes' a serem tomadas. A primeira é atualizar o software que acabou de ser baixado. É claro que isto não inclui as definições atualizadas de virus, que são um download a parte.
Bem, resumindo uma longa história, foram cerca de 2 horas para conseguir instalar o System Works. O Windows Installer parou de reclamar, a assinatura está renovada. Tem agora um ícone imenso na barra de programas e o tempo de boot passou de imenso para quase insuportável.
E daqui a 12 meses a assinatura vai acabar de novo...
Há pouco mais de um ano, ele comprou o Norton System Works. No começos dos anos 80, Peter Norton era um colunista da recém criada PC magazine que colocou à venda um utilitário para recuperar arquivos apagados. Ao primeiro utilitário se seguiram outros, surgindo o Norton Utilities. Com o passar dos anos os utilitários passaram do DOS para o Windows, a empresa foi comprada pela Symantec e até a tradicional foto do Peter Norton de braços cruzados sumiu dos anúncios e embalagens.
Algum tempo atrás o System Works começou a reclamar que uma assinatura estava vencida. segundo as instruções da tela, meu pai acabou caindo na loja on line, onde comprou e fez o download de uma atualização do System Works. Entretanto, o software continuou reclamando da assinatura e meu pai acabou comprando também a renovação de assinatura do antivirus em separado (ele achou que era apenas R$39, mas no caso da renovação de assinatura os preços no site brasileiro são em US$!). Entretanto, o software continuou reclamando que a assinatura estava vencida. Além disso, volta e meia aparecia uma tela do Windows Installer, tentando instalar algo. Após algum tempo aparecia uma mensagem de erro dizendo que o arquivo de instalação devia ser rodado a partir do Setup. Foi neste ponto que ele entregou os pontos e me chamou.
O primeiro ponto que eu percebi foi que o System Works não estava atualizado. A primeira ideia foi tentar rodar novamente o instalador. Entretanto, meu pai não sabia aonde ele tinha sido colocado. Na FAQ do site da Symantec as soluções para este problema (aparentemente comum) são olhar no diretório selecionado no Save As ou então, se o usuário souber o nome do arquivo do instalador, usar o File Search. É claro que se meu pai soubesse em qual diretório tinha recebido o arquivo nós não precisaríamos olhar no FAQ. E se eles próprios não sabem dizer o nome do arquivo, como esperar que nós soubessemos? (No final o arquivo se chama Setup.exe, como dezenas de outros, portanto o File Search não seria muito útil). O e-mail de confirmação do pedido tem um link para refazer o download, com as instruções de digitar o número do pedido e a senha. É claro que na página apontada pelo link não tinha nenhum lugar para fazer downloda ou entrar com estas informações. Após navegar por algumas páginas achamos a página de download, conseguimos lembrar a senha e fazer o download do Setup.exe.
O Setup instala um gerenciador de download que faz o download do software propriamente dito (quase 100M). Pausa para visitar a geladeira. Terminado o download é hora da instalação (seguida de um tradicional restart). O passo seguinte (automático, como tudo mais) é ativar e registrar o produto. Entretanto, o micro do meu pai não se conecta diretamente à internet quando entra no ar, é preciso chamar o "discador" do Speedy manualmente (um procedimento teoricamente sensato). Logo a primeira tentativa não teve sucesso. Feita a conexão à internet, foi preciso umas 3 tentativas para ter sucesso na conexão ao servidor da Symantec. O programa apresenta então um a lista de providências 'urgentes' a serem tomadas. A primeira é atualizar o software que acabou de ser baixado. É claro que isto não inclui as definições atualizadas de virus, que são um download a parte.
Bem, resumindo uma longa história, foram cerca de 2 horas para conseguir instalar o System Works. O Windows Installer parou de reclamar, a assinatura está renovada. Tem agora um ícone imenso na barra de programas e o tempo de boot passou de imenso para quase insuportável.
E daqui a 12 meses a assinatura vai acabar de novo...
segunda-feira, março 13, 2006
Protocolos de Comunicação
Um dos trabalhos que andei fazendo envolveu implementar o protocolo XModem em coletores de dados. Os protocolos de comunicação são algo que me facinam há muito tempo (afinal, os meus dois primeiros empregos estavam relacionados a comunicação de dados).
Um protocolo de comunicação é um conjunto de convenções usado para mover informações entre dois equipamentos. Os principais objetivos de um protocolo é cuidar do endereçamento (no caso de ligações multiponto) e garantir a integridade das informações. Embora isto não seja muito visível atualmente, a comunicação à distância está sujeita a grande quantidade de erros. A maioria dos equipamentos atuais (inclusive modems) possuem protocolos embutidos que detectam e recuperam erros de forma quase transparente. No começo da comunicação via modem, os erros de comunicação eram mais evidentes. Antes da internet, a vida on-line era feita através das BBSs (computer Bulletin Board Systems) que enviavam os textos sem protocolo, era comum caracteres sumirem, mudarem ou mesmo surgirem do nada. Um bom protocolo de comunicação precisa ter uma boa resistência a estas ocorrências.
A maioria dos protocolos de comunicação se baseiam nos mesmos conceitos. O primeiro destes conceitos é um pacote. O início de um pacote é normalmente marcado por um caracter especial. O final de um pacote pode ser determinado de três formas básicas: tamanho fixo em função do tipo de pacote, um campo de tamanho dentro do pacote ou um caracter especial no fim. Para detectar erros, é comum acrescentar-se ao final do pacote um ou mais bytes que são calculados a partir dos demais. O receptor recalcula estes bytes e confere com os recebidos, se não forem iguais é porque um erro ocorreu. Exemplos comuns de detecção de erro são os checksums (soma desprezando vai-um) e os crcs (cyclic redundancy codes). Alguns sistemas utilizam códigos de correção de erro (ECC) que além de detectar erros pode corrigir uma parte deles. O mais comum entretanto, é recuperar uma situação de erro solicitando a retransmissão do pacote. Na forma mais simples, a cada pacote recebido o receptor envia um caracter que indica se o pacote foi recebido corretamente (ACK - Acknoledge) ou com erro (NAK - NonAcknoledge). Para tratar o caso em que um ACK, NAK ou pacote é perdido no meio do caminho normalmente os pacotes são numerados e as recepções são temporizadas. Por exemplo, se o transmissor envia o pacote 31 e o receptor o recebe corretamente mas o ACk é perdido, o transmissor irá dar um timeout e re-enviar o pacote 31. O receptor ignora o pacote duplicado e re-envia o ACK para que o transmissor envie o pacote seguinte.
Como descrito acima, é comum os protocolos darem significado especial para alguns códigos. A tabela ASCII reflete isto, reservando os primeiros 32 códigos para os caracteres de controles, alguns como nome como Start of Transmission (STX), Start of Header (SOH), End of Text (ETX), Acknoledge (ACK) e Non-Acknoledge (NAK). Existem dois tratamentos comuns para os códigos de controle presentes no interior dos pacotes (nos dados). O mais comum é permitir a presença de caracteres de controle dentro de pacotes; isto é mais simples e eficiente porém pode causar problemas quando ocorre algum erro e um caracter de dado é tratado erroneamente como caracter de controle. Outra opção é utilizar um caracter de prefixo (o código ASCII tem o DLE com esta finalidade). Por exemplo, um protocolo pode convencionar que para enviar um SOH nos dados deve ser enviado DLE A e que para enviar DLE deve ser enviado DLE P ou DLE DLE.
Uma outra coisa impressionante é como determinados protocolos criados de forma despretenciosa acabam virando padrões e se mantendo vivos por décadas. O protocolo XModem foi criado nos anos 70, por uma pessoa que queria passar arquivos de um micro para outro e permanece em uso até hoje, apesar de ter uma série de limitações.
A implementação de protocolos envolve conceitos e técnicas interessantes de programação. Em ambientes sem multiprogramação muitas vezes o programa precisa analisar os caracteres recebidos um a um; após examinar cada caracter precisa retornar a um loop principal onde outras funções são tratados. Exemplificando em um pseudo C:
// loop principal
while ( )
{
TrataTeclado ();
AtualizaTela ();
if (RecebeuCaracter)
TrataCaracter ();
...
}
Neste caso é inevitável implementar o protocolo como uma máquina de estados. Por exemplo, o pacote básico do XModem começa com um caracter SOH e tem 132 caracteres:
enum { ESPERANDO_SOH, RECEBENDO_PACOTE } estado = ESPERANDO_SOH;
byte pacote [132];
int i;
TrataCaracter (byte c)
{
switch (estado)
{
case ESPERANDO_SOH:
if (c == SOH)
{
estado = RECEBENDO_PACOTE;
i = 0;
pacote[i++] = c;
}
break;
case RECEBENDO_PACOTE:
pacote[i++] = c;
if (i == 132)
{
TrataPacote();
estado = ESPERANDO_SOH;
}
break;
}
}
Em um ambiente multitarefa, é possível fazer algo mais legível como:
byte pacote [132];
int i;
RecebePacote ()
{
While (RxCar() != SOH)
;
pacote[0] = SOH;
for (i = 1; i < 132; i++)
pacote[i] = RxCar ();
TrataPacote ();
}
(Obviamente estes exemplos são artificialmente simples, existem variações do XModem , não estou tratando timeouts, etc.)
No caso de você estar desenvolvendo para um sistema sem sistema operacional (um com sistema capenga como o DOS), você provavelmente vai ter uma fila para sincronizar a recepção em tempo de interrupção com o consumo dos bytes. Se você quiser implementar multitarefa por contra própria, vai ter que implementar um semáfaro para a fila (neste caso o RxCar() acima faz uma operação P na fila e fica bloqueado se a fila estiver vazia, até que a interrupção coloque um caracter na fila e faça um operação V).
Se tudo isto parece longe do seu dia a dia, lembre-se que você está lendo isto em um site através (no mínimo) dos protocolos TCP/IP.
Um protocolo de comunicação é um conjunto de convenções usado para mover informações entre dois equipamentos. Os principais objetivos de um protocolo é cuidar do endereçamento (no caso de ligações multiponto) e garantir a integridade das informações. Embora isto não seja muito visível atualmente, a comunicação à distância está sujeita a grande quantidade de erros. A maioria dos equipamentos atuais (inclusive modems) possuem protocolos embutidos que detectam e recuperam erros de forma quase transparente. No começo da comunicação via modem, os erros de comunicação eram mais evidentes. Antes da internet, a vida on-line era feita através das BBSs (computer Bulletin Board Systems) que enviavam os textos sem protocolo, era comum caracteres sumirem, mudarem ou mesmo surgirem do nada. Um bom protocolo de comunicação precisa ter uma boa resistência a estas ocorrências.
A maioria dos protocolos de comunicação se baseiam nos mesmos conceitos. O primeiro destes conceitos é um pacote. O início de um pacote é normalmente marcado por um caracter especial. O final de um pacote pode ser determinado de três formas básicas: tamanho fixo em função do tipo de pacote, um campo de tamanho dentro do pacote ou um caracter especial no fim. Para detectar erros, é comum acrescentar-se ao final do pacote um ou mais bytes que são calculados a partir dos demais. O receptor recalcula estes bytes e confere com os recebidos, se não forem iguais é porque um erro ocorreu. Exemplos comuns de detecção de erro são os checksums (soma desprezando vai-um) e os crcs (cyclic redundancy codes). Alguns sistemas utilizam códigos de correção de erro (ECC) que além de detectar erros pode corrigir uma parte deles. O mais comum entretanto, é recuperar uma situação de erro solicitando a retransmissão do pacote. Na forma mais simples, a cada pacote recebido o receptor envia um caracter que indica se o pacote foi recebido corretamente (ACK - Acknoledge) ou com erro (NAK - NonAcknoledge). Para tratar o caso em que um ACK, NAK ou pacote é perdido no meio do caminho normalmente os pacotes são numerados e as recepções são temporizadas. Por exemplo, se o transmissor envia o pacote 31 e o receptor o recebe corretamente mas o ACk é perdido, o transmissor irá dar um timeout e re-enviar o pacote 31. O receptor ignora o pacote duplicado e re-envia o ACK para que o transmissor envie o pacote seguinte.
Como descrito acima, é comum os protocolos darem significado especial para alguns códigos. A tabela ASCII reflete isto, reservando os primeiros 32 códigos para os caracteres de controles, alguns como nome como Start of Transmission (STX), Start of Header (SOH), End of Text (ETX), Acknoledge (ACK) e Non-Acknoledge (NAK). Existem dois tratamentos comuns para os códigos de controle presentes no interior dos pacotes (nos dados). O mais comum é permitir a presença de caracteres de controle dentro de pacotes; isto é mais simples e eficiente porém pode causar problemas quando ocorre algum erro e um caracter de dado é tratado erroneamente como caracter de controle. Outra opção é utilizar um caracter de prefixo (o código ASCII tem o DLE com esta finalidade). Por exemplo, um protocolo pode convencionar que para enviar um SOH nos dados deve ser enviado DLE A e que para enviar DLE deve ser enviado DLE P ou DLE DLE.
Uma outra coisa impressionante é como determinados protocolos criados de forma despretenciosa acabam virando padrões e se mantendo vivos por décadas. O protocolo XModem foi criado nos anos 70, por uma pessoa que queria passar arquivos de um micro para outro e permanece em uso até hoje, apesar de ter uma série de limitações.
A implementação de protocolos envolve conceitos e técnicas interessantes de programação. Em ambientes sem multiprogramação muitas vezes o programa precisa analisar os caracteres recebidos um a um; após examinar cada caracter precisa retornar a um loop principal onde outras funções são tratados. Exemplificando em um pseudo C:
// loop principal
while ( )
{
TrataTeclado ();
AtualizaTela ();
if (RecebeuCaracter)
TrataCaracter ();
...
}
Neste caso é inevitável implementar o protocolo como uma máquina de estados. Por exemplo, o pacote básico do XModem começa com um caracter SOH e tem 132 caracteres:
enum { ESPERANDO_SOH, RECEBENDO_PACOTE } estado = ESPERANDO_SOH;
byte pacote [132];
int i;
TrataCaracter (byte c)
{
switch (estado)
{
case ESPERANDO_SOH:
if (c == SOH)
{
estado = RECEBENDO_PACOTE;
i = 0;
pacote[i++] = c;
}
break;
case RECEBENDO_PACOTE:
pacote[i++] = c;
if (i == 132)
{
TrataPacote();
estado = ESPERANDO_SOH;
}
break;
}
}
Em um ambiente multitarefa, é possível fazer algo mais legível como:
byte pacote [132];
int i;
RecebePacote ()
{
While (RxCar() != SOH)
;
pacote[0] = SOH;
for (i = 1; i < 132; i++)
pacote[i] = RxCar ();
TrataPacote ();
}
(Obviamente estes exemplos são artificialmente simples, existem variações do XModem , não estou tratando timeouts, etc.)
No caso de você estar desenvolvendo para um sistema sem sistema operacional (um com sistema capenga como o DOS), você provavelmente vai ter uma fila para sincronizar a recepção em tempo de interrupção com o consumo dos bytes. Se você quiser implementar multitarefa por contra própria, vai ter que implementar um semáfaro para a fila (neste caso o RxCar() acima faz uma operação P na fila e fica bloqueado se a fila estiver vazia, até que a interrupção coloque um caracter na fila e faça um operação V).
Se tudo isto parece longe do seu dia a dia, lembre-se que você está lendo isto em um site através (no mínimo) dos protocolos TCP/IP.
quarta-feira, março 08, 2006
Delphi has left the building
A notícia é velha, mas só a vi agora; a Borland vai sair do mercado de IDE (Ambiente Integrado de Desenvolvimento) e está procurando um comprador para o Delphi, JBuilder e C++ Builder.
A Borland é uma empresa que nasceu mais ou menos na mesma época que o PC e nos anos 80 conseguiu criar uma imagem muito boa. Seus primeiros produtos (Turbo Pascal, Sidekick e SuperKey) logo se tornaram best sellers, com preços acessíveis (olhando numa revista de 86, o Turbo Pascal 3.0 custava $99.95 enquanto que o Microsoft C 4.0 custava $319) e o "Borland No-nonsense License" (trate o software como um livro). A Borland popularizou algumas categorias de software, como IDE (o Microsoft C 4.0 funcionava por linha de comando) e TSR (Terminate e Stay Resident).
No final dos anos 80, a Borland sonhou alto e lançou não somente outras linguagens (como o Turbo C, Turbo Prolog e até o Turbo Basic) como uma planilha (Quattro), um gerenciador de banco de dados (Paradox) e um editor de texto (cujo nome me falha). No começo dos anos 90 (antes do surgimento do Visual Basic, abrindo a programação Windows para todos), a Borland conseguiu a façanha de ter o melhor ambiente de desenvolvimento para o Windows 16 bits, com o Borland C++. Ainda nesta época, lançou o Turbo Pascal for Windows, que veio a se tornar o Delphi.
O Delphi sempre contou com características de respeito. Juntou à facilidade RAD do Visual Basic uma linguagem estruturada orientada a objeto. Fez a transição dos 16 para os 32 bits e, mais recentemente para o .Net (algo que o Visual Basic não conseguiu). Desde o começo foi capaz de gerar código nativo e de pequeno tamanho (para ter uma idéia, a primeira versão Windows do software de imposto de renda cabia num disquete, a versão deste ano tem 3 Mbytes). Até mesmo suporte a Linux o Delphi chegou a ter. Apesar disto, a popularidade do Delphi nunca foi imensa.
Embora ainda exista uma esperança da Borland voltar atrás (como foi na mudança de nome para Inprise) ou de achar um comprador que consiga pelo menos manter a base atual de fãs do Delphi, o mais provável é que o Delphi passe a ser um produto de nicho, se defasando ao longo do tempo. É claro que vai demorar muito para acabar (afinal, ainda vemos aplicações Clipper em uso), mas vai ser cada vez mais arriscado desenvolver em Delphi.
E com isto as opções para desenvolvimento de aplicações "nativas" ficarão ainda mais limitadas. Tirando as alternativas "livres", não sobra muita coisa além do Visual C++ da Microsoft. Para aplicações do tipo formulários + banco de dados, o futuro parece ser Java e .Net. Daqui a alguns anos, para usar o programa de imposto de renda muita gente terá que fazer um download de dezenas de megabytes para instalar a máquina virtual Java ou o framework .Net atualizado.
Um último ponto a pensar é a questão da influência do código "livre" na decisão da Borland. No caso do JBuilder, parece bastante claro que a Borland perdeu clientes para o Eclipse. Apesar do discurso anti-Microsoft de muitos proponentes do "software livre", as empresas menores e os produtos de nicho sofrem muito mais com esta "concorrência". E, como resultado, se acentua mais a concentração do mercado em um ou poucos produtos.
Assinar:
Postagens (Atom)