sábado, setembro 27, 2008

Polyopticon

Lembrando mais um brinquedo educativo da minha infância, eis o Polyopticon:


O Polyopticon existiu por bastante tempo. O meu tio tinha um que imagino ser do início dos anos 60. O modelo acima foi comprado pelo meu pai para os netos, provavelmente no início dos anos 90. O meu modelo era algo no meio, os tubos eram cinzas, tinha uma quantidade maior de peças e dava para montar mais coisas.

Este modelo tem 8 lentes e permite montar alguns modelos de telescópio, um binóculo, um microscópio e um caleidoscópio.

A foto abaixo é uma luneta com um prisma para a imagem não parecer invertida.


O Polyopticon era fabricado pela DFV. A empresa parece ainda existir (site aqui, requer IE), mas o Polyopticon já se foi. Ainda se encontra unidades usadas a venda (procure Polyopticon no Google).

quinta-feira, setembro 25, 2008

A Lei do Tamanho 12

Começo admitindo que toda vez que alguém fala em contrato, o que me vem à mente é o Groucho Marx explicando um contrato para o Chico Marx em A Night at the Opera (quem quiser ver procure sanity clause no YouTube).

O fato é que o Congresso aprovou e o presidente em exercício sancionou uma lei que altera o Código de Defesa do Consumidor obrigando o uso em contratos de letras tamanho 12 ou maior.

Na minha opinião (e pelas reações até o momento parece que sou minoria) é mais uma lei excessiva:
  • a redação anterior já exigia que a letra fosse legível.
  • tamanho 12 diz respeito apenas à altura da célula das letras.
  • o tamanho percebido das letras muda muito conforme o tipo de letra
  • se todo o texto usar o mesmo tamanho de letra a leitura fica mais monótona e aumenta a probabilidade de se ignorar um trecho (ou, colocando de uma outra forma, antigamente quando tinha letras miúdas era onde se devia prestar mais atenção).
  • mais importante que o tamanho da letra é a digramação.
  • existe o grande risco destas falhas da lei levarem à preparação de um nova lei, provavelmente com novas falhas.
Mais do que nunca, continua valendo o conselho de ler bem antes de assinar (exceto se você for o Bill Gates negociando com a IBM).

quarta-feira, setembro 24, 2008

Microcontroladores - parte 15

Vamos examinar agora o processo de depuração do firmware, que pode ser a tarefa mais demorada e desgastante de um projeto.

Recursos de Depuração dos Ambientes de Desenvolvimento

A maioria dos ambientes de desenvolvimento possuem um depurador e muitas vezes um simulador. O simulador é mais uma ferramenta didática que de depuração, pois não simula o hardware do projeto.

O depurador é também de uso limitado, pois a maioria dos sistemas embarcados funciona em tempo real e após uma parada em um breakpoint pode não fazer sentido prosseguir a execução.

Interface Serial

Quando disponível, uma interface serial é um recurso extremamento útil para a depuração, principalmente se operar com baixa interferência no restante do firmware. Alguns exemplos de técnicas de depuração baseadas em uma interface serial:
  • monitoração: dados transmitidos e recebidos por um meio de comunicação são tão enviados para uma serial. Um programa de PC pode capturar estes dados, consistí-los e decodificá-los. Ferramenta essencial quando é difícil fazer uma monitoração externa de uma comunicação complexa.
  • trace: envio de indicações de por onde o firmware está passando. Um simples envio de um caracter em determinados pontos e um Hyperterminal na outra ponta da serial pode fazer maravilhas.
  • log: muitas vezes não é possível capturar a serial em tempo real. Nestes casos pode ser possível registrar eventos importantes em um log (na Ram ou, melhor ainda, em memória não volátil) e depois "puxar" estes dados pela serial.
LEDs e Buzzers

Na falta de um serial, sempre se pode colocar um LED em uma saída digital (ou mudar o significado de um LED já existente no projeto). Outra possibilidade (mais complicada e incômoda) é usar sinais sonoros.

Sinais e Osciloscópio

Um osciloscópio é um recurso importante não somente para a depuração do hardware como o do firmware. Um osciloscópio pode inclusive ser utilizado como alternativa ao uso de um LED. É um pouco mais complicado de montar mas tem a vantagem de permitir, por exemplo, verificar tempos com precisão.

Cuidado com o Hardware

Quando estamos desenvolvendo software para PC costumamos confiar totalmente no hardware. No desenvolvimento de firmware isto n]ão costuma ser verdade, pois o hardware está sendo desenvolvido em conjunto com o firmware.

Quando o hardware tem problemas os problemas mais estranhos ocorrem.

terça-feira, setembro 23, 2008

Jogo Grátis: Quest for Glory II

Este lançamento do mês passado passou desapercebido: o mesmo pessoal que fez os remakes do King Quest I e II lançou um terceiro: o Quest for Glory II.


Este jogo é uma Aventura, com algumas noções de RPG (role-playing game, não Reeducação Postural Global ou lança-granadas-foguete).

O jogo pode ser baixado diretamente do site oficial:

http://www.agdinteractive.com/homepage/homepage.html

segunda-feira, setembro 22, 2008

Microcontroladores - Parte 14

Nest post vamos ver alguns critérios para a escolha de um modelo de microcontrolador para um projeto.

Critérios Técnicos

1) Capacidades Necessárias

As características do projeto definem capacidades essenciais de hardware, como quantidade de entrada/saída digitais, entradas ADC, seriais, timers, memória não volátil, etc. Dependendo do modelo selecionado, podem 'sobrar' recursos que permitam acrescentar funções adicionais (não essenciais) ao projeto.

Um pouco mais complicado é avaliar a memória Ram necessária, principalmente quando ela é pouca. Mais complicado ainda é prever o tamanho que terá o código (e portanto a necessidade de Flash). No caso dos microcontroladores mais acanhados em memória, é bom prever uma reavaliação ao longo do projeto.

2) Desempenho

Desempenho tem normalmente duas facetas: velocidade de processamento e consumo de energia. Alguns cálculos na ponta do lápis podem dar uma idéia do que esperar com cada microprocessador, mas uma medida real durante o projeto pode ser necessária.

3) Arquitetura e Ferramentas de Desenvolvimento

Embora estes pontos sejam importantes, na maioria dos casos não são determinantes na escolha. Boas ferramentas de desenvolvimento podem minimizar desvantagens da arquitetura.

Critérios Não-Técnicos

1) Preço

Este é um fator crítico em muitos casos, pois um preço elevado pode inviabilizar um produto. É preciso não ter uma visão estreita do preço, olhando somente o preço do microcontrolador. A escolha do microcontrolador pode afetar o custo dos demais componentes, do desenvolvimento e da manutenção. O recurso de atualização do firmwar em campo, em particular, pode ter um peso significativo.

2) Relação com o Distribuidor

O bom relacionamento técnico e/ou comercial com um distribuidor pode se sobrepor a vantagens técnicas. Em alguns casos é preferível comprar o microcontrolador de um distribuidor que já fornece outros componentes críticos do que iniciar relações comerciais com outra empresa.

3) Uso em Outros Projetos

Se uma determinada família já é utilizada em outros projetos, isto significa que já se tem o conhecimento e as ferramentas. Dependendo dos volumes relativos, pode até fazer sentido usar um microcontrolador "superdimensionado" e manter um item único em estoque.

domingo, setembro 21, 2008

O Sistema Operacional da HP para PCs

A grande notícia da semana passada seria o sistema operacional sendo desenvolvido pela HP. Seria, se não tivesse sido negado. A notícia, entretanto, justifica alguns comentários.

Boa notícia para o Linux?

A notícia foi aplaudida por muita gente (antes de ser desmentida), principalmente pelos fãs do Linux (entre outros motivos por que supostamente o novo sistema seria baseado no núcleo do Linux).

Na minha (muitas vezes errada) opinião, o fato do anúncio de um novo sistema ser recebido com entusiasmo mostra um certo descontentamente com as opções atuais. E isto coloca o Linux ao lado do Windows.

A HP desenvolvendo Sistemas Operacionais?

Provavelmente a geração atual enxerga a HP como um fabricante de impressoras que também fabrica PCs e notebooks. Em compensação, o meu pai se lembra da HP como um fabricante de equipamentos de teste e medição. Na verdade a HP tem uma das mais belas histórias entre as empresas de tecnologia (enquanto comandada pelos seus fundadores), desde que começaram a trabalhar literalmente na garagem (garagem esta que foi agraciada em 1989 como o 'berço do Vale do Silício').

Em 1966 a HP lançou o seu primeiro minicomputador, voltado para o controle automático de equipamentos de medição. Embarcou em seguida em um projeto ambicioso que, após uma traumática mudança de curso, resultou no HP3000. Que tinha um sistema operacional desenvolvido pela própria HP, o MPE.

A HP atuou intensamente no mercado de minicomputadores. Alguns consideram até que a HP criou os primeiros micros, porém preferiu (por motivos de marketing) lança-los como calculadoras programáveis ao invés de micros.

Os mini mais recentes da HP utilizam uma variação própira do Unix, o HP-UX. Com a fusão com a Compaq, a HP adquiriu o espólio da DEC (que ironicamente ela quase comprou no início dos anos 60) e com isto o OpenVMS.

Portanto, o desenvolvimento de sistemas operacionais não seria algo inédito na HP (porém é bom lembrar que a HP não é mais a mesma após a passagem da Carly Fiorina).

Uma Camada Sobre o Windows?

No desmentido do desenvolvimento de um novo sistema operacional, a HP confirmou o trabalho em uma camada para facilitar o uso do Windows.

Por curiosidade, não é a primeira vez que a HP faz isto.

Sugestão de Leitura

Para quem quiser saber um pouco mais sobre o passado da HP, recomendo o livro "The HP Way" de David Packard.

quarta-feira, setembro 17, 2008

Microcontroladores - Parte 13

Concluindo os meus exemplos de microcontroladores, vou falar um pouco sobre dois modelos baseados na arquitetura ARM (que eu já comentei anteriormente).

A arquitetura ARM é uma arquitetura RISC de 32 bits que é utilizada por vários fabricantes.

Como empresas que comercializam microcontroladores baseados na arquitetura ARM podemos citar Intel, Texas, ATMEL, ST e NXP.

Um primeiro exemplo é o microcontrolador ATMEL AT91R40008, que conta com os seguintes recursos:
  • Clock de 0 a 70MHz
  • 256Kbytes de Ram interna ao microcontrolador
  • Não possui Flash interna (deve ser usada uma Flash externa)
  • Até 32 E/S digitais
  • 3 Timers
  • 2 UARTs
  • 1 interface SPI
Como segundo exemplo temos o STR731F da ST:
  • Clock até 36MHz
  • 16Kbytes de Ram
  • 256Kbytes de Flash
  • Até 72 E/S digitaus
  • 6 Timers (com capacidade de PWM)
  • 12 canais ADC 10 bits
  • 4 UARTs
  • 2 interfaces I2C e 3 interfaces SPI
Estamos, portanto, falando de microcontroladores poderosos (e mais caros).

Toda a memória é acessada diretamente por um endereço de até 32 bits. A arquitetura ARM utiliza um conjunto de 16 registradores de 32 bits:


Todas as instruções são codificadas em uma palavra de 32 bits:

Maiores detalhes sobre a arquitetura ARM podem ser encontrados nos meus posts anteriores.

Nos dois projetos que trabalhei com esta arquitetura, o compilador C utilizado era o GCC, através do GNU ARM. O GCC é um compilador bastante estável (e um software livre), porém nem sempre o código gerado está bem otimizado.

Com o microcontrolador da Atmel, utilizei uma IDE proprietária de uma empresa chamada Embest. A IDE era fraca e a biblioteca de funções para manipulação do hardware continha alguns erros (felizmente os fontes são fornecidos). A documentação era um exemplo clássico de engrish.

No caso da ST, a IDE fornecida pelo fabricante era a Eclipse. A biblioteca era bem razoável, porém a documentação estava apenas nos fontes.

terça-feira, setembro 16, 2008

Livro: From Fish To Colossus - Parte 2

Continuando o post anterior, vamos ver como a cifra Lorenz foi quebrada e alguns comentários sobre o livro.

A Quebra da Cifra Lorenz

A quebra da cifra foi obtida graças a conhecimentos de criptografia, erros de projeto ou operação das máquinas Lorenz e, principlamente, muita tentativa e erro.

O primeiro passo era ter uma idéia de como a máquina era internamente. Os ingleses conheciam patentes públicas e protótipos de máquinas com rotores, e deduziram que a Lorenz usava uma máquina deste tipo para codificar independentemente cada um dos 5 canais do código Baudot. As mensagens encriptadas eram sempre precedidas por uma lista de 12 nomes não criptografados. Isto sugeria que a chave da mensagem (posição inicial dos rotores) tinha tamanho doze e portanto esta era a quantidade de rotores na máquina. Era razoável supor que eram usados dois rotores para cada canal e que os dois rotores restantes controlavam o movimento dos demais. Somente no final de 1945 uma máquina Lorenz foi capturada e estas deduções confirmadas.

O passo seguinte era tentar determinar o número de posições para os pinos em cada rotor. Isto era facilitado pelo fato dos canais serem codificados independentemente e dos rotores Sn serem movidos bem espaçadamente. Desta forma, durante o período de tempo que o rotor Sn ficava parado cada canal era criptografado apenas pelo rotor Xn. Mais importante, um operador alemão cometeu um erro crasso em 30 de agosto de 1941: ele digitou duas vezes uma mesma mensagem longa usando a mesma chave. Devido a pequenas diferenças na segunda digitação os ingleses ficaram com dois textos parecidos codificados com a mesma chave.

Fazendo o xor das duas mensagens criptografadas a chave foi cancelada e restou somente o xor das mensagens originais. Assumindo que o início do texto de uma delas era "SPRUCHNUMMER" (mensagem número em alemão), John Tiltman descobriu que o a outra começava com "SPRUCHNR" (o operador abreviou na segunda vez). Com uma das mensagens "andando na frente" da outra, pôde pacientemente recuperar as duas mensagens e, a partir delas, a chave. As chaves foram analisadas (à mão, ao longo de dois meses) por Bill Tutte que verificou repetições de padrão em cada canal e com isto determinou a quantidade de posições em cada rotor e como eles estavam interligados.

Uma máquina eletrônica foi construída para emular a Lorenz. Construída com reles, foi chamada de Tunny.

Análises estatísticas revelaram algumas fraquezas na criptografia Lorenz, o que permitiu a descoberta das chaves por tentativa e erro automatizados. Um primeiro tipo de máquina foi denominada Heath Robinson. Basicamente esta máquina processava duas fitas perfuradas (uma com a mensagem criptografada e a outra com uma possível chave) e apresentava contadores com estatísticas. Repetindo o processo variando a fita com a possível chave, o resultado nos contadores indicava a chave correta. Esta máquina era bastante complicada do ponto de vista mecânico, dada a necessidade de mover em sincronismo e em alta velocidade as duas fitas.

O Colossus foi a evolução da Robinson. Ela gerava a chave eletrônicamente, dispensando a segunda fita. Embora seja considerado um ancestral dos computadores, o Colossus era mais uma calculadora, não tendo capacidade de programação ou decisão. Por outro lado, ele possuia alguns circuitos digitais básicos, como XOR, shift e contadores, implementados com válvulas eletrônicas.

O Livro

Um primeiro aspecto negativo é a apresentação, que mais parece um trabalho acadêmico encadernado em casa. Considerando-se os recursos atuais de editoração eletrônica, o livro poderia ter um acabamento melhor e uma formatação gráfica mais sofisticada.

Deve-se louvar o esforço de pesquisa do autor (Harvey G. Cragon). O livro contém muita teoria e uma grande quantidade de fotos, diagramas e esquemos elétricos.

Infelizmente, o livro é bastante confuso. Em alguns momentos parece que os capítulos não seguem uma ordem totalmente lógica e que trechos são repetidos. O autor não conseguiu explicar de forma clara (pelo menos para mim) a teoria por trás da quebra da criptografia.

Em resumo, o assunto é muito interessante mas o livro acaba sendo cansativo pela falta de clareza.

Para quem quiser saber um pouco mais, sugiro dar uma olhada na seguinte página:

http://www.codesandciphers.org.uk/lorenz/fish.htm

segunda-feira, setembro 15, 2008

Livro: From Fish To Colossus - Parte 1

A Segunda Guerra Mundial teve inúmeros segredos. É no mínimo curioso comparar a bomba atômica com a criptografia. A maior parte da teoria da bomba atômica foi rapidamente divulgada, ficando o segredo mais restrito aos aspectos práticos de construção da bomba. Já o uso da criptografia na Segunda Guerra ficou em sigilo por praticamente meio século.

A partir da metade dos anos 90 é que começaram a ser liberados documentos sobre o assunto, o que gerou uma leva de livros. O maior destaque foi dado à quebra da criptografia da máquina alemã conhecida como Enigma. Somente mais recentemente surgiram livros sobre uma outra cifra alemã, a Lorenz.

Li recentemente o livro 'From Fish To Colossus' de Harvey G. Cragon sobre a quebra da Lorenz e as máquinas desenvolvidas para isto. Nesta primeira parte vamos ver um pouco sobre o assunto do livro.

Criptografia I

Os princípio básicos da criptografia surgiram quase junto com a escrita e são hoje bastante conhecidos. A forma mais simples de codificação, chamada às vezes de Código de César, consiste na substituição simples de uma letra por outra, segundo uma tabela fixa. Este tipo de código se mostrou bastante vulnerável a ataques baseados na frequência de ocorrência das letras e das sequências de letras (vide, por exemplo, "A Adventura dos Dançarinos" em "O Retorno de Sherlock Holmes" de Conan Doyle).

Uma forma de deixar este tipo de criptografia (cifra de substituição) mais segura é utilizar várias tabelas de substituição (a chamada cifra polialfabética). Levando esta idéia ao limite, temos uma tabela diferente para cada caracter da mensagem - o chamado "one time pad".

A dificuldade prática de ter um número infinito (ou pelo menos muito grande) de tabelas de substituição levou ao uso de sequências pseudo-aleatórias, geradas automaticamente a partir de um valor inicial. Nos tempos da Segunda Guerra estas sequências eram geradas mecanicamente através de discos (ou rotores) que viravam a cada caracter codificado.

A Maquina Lorenz

A máquina criptográfica Lorenz era um dispositivo eletro-mecânico instalado entre um transmissor/receptor e uma teleimpressora.

A teleimpressora era capaz de transmitir caracteres digitados no seu teclado (ou a partir de uma fita perfurada) e de imprimir em papel os caracteres recebidos (ou perfurar uma fita com eles). Em um modo "off-line" era possível perfurar uma fita diretamente com os caracteres digitados no teclado. Para codificação dos caracteres era usado o código Baudot, com 5 bits (ou canais) para cada caracter.

A máquina Lorenz recebia os 5 canais e gerava 5 canais criptografados (e vice versa). Cada rotor possuia um número de posições (variando de 23 a 61) que podiam ou não conter um pino. Cada canal era criptografado de forma independente, através de um ou-exclusivo (XOR) com os valores definidos por dois rotores (chamados de Xn e Sn no livro). Dois rotores adicionais (M1 e M2) controlavam a rotação dos rotores Sn: M1 e os rotores Xn eram rodados a cada caracter, M2 era rodado a cada pino de M1 e os rotores Sn eram rodados a cada pino de M2. Eram portanto 12 rotores, com um total de 501 pinos, permitindo gerar uma sequência de 1.6x 10^19 caracteres sem repetição. Como comparação, a máquina Enigma possuia 3 rotores e gera uma sequência de 17.576 caracteres.

A segurança da criptografia Lorenz era fornecida por duas formas independentes. A primeira era a posição dos pinos nos rotores; inicialmente os rotores S eram alterados a cada 3 meses, os rotores X uma vez por mês e os rotores M diariamente (com o andar da guerra as posições dos pinos foram sendo trocadas cada vez mais frequentemente, até serem todas trocadas diariamente a vartir do verão de 1944). A segunda forma era a posição inicial dos rotores, que era escolhida alatoriamente pelo operador da máquina origem; esta informação tinha que ser transmitida para o operador da máquina destino.

Fish

Em 1940 a Alemanha começou a montar um conjunto de links de comunicação ponto-a-ponto, usando teleimpressoras, entre o quartel general de Hitler e os quarteis generais do exército. Quando os ingleses descobriram estes links, o codinome Fish foi dado ao sistema.

Após um breve período de teste, com transmissões abertas, os alemães passaram a usar as máquinas Lorenz. No final da guerra existiam cerca de 40 links em operação.

A quantidade de máquinas Lorenz e de mensagens criptografadas com elas foi bem menor que com a Enigma. Por outro lado, elas continham informações mais valiosas, por se tratar da comunicação entre os quarteis generais alemães.

domingo, setembro 14, 2008

Engenheiro Eletrônico Philips

Continuando as minhas recordações de brinquedos educativos que não se encontram mais, apresento o Engenheiro Eletrônico Philips.

Considerando que eu acabei me formando como Engenheiro Eletrônico, pode-se dizer que foi um brinquedo bastante influente para mim.

O Engenheiro Eletrônico Philips era um kit que permitia montar 22 "fascinantes" circuitos, entre os quais:
  • Receptor de rádio (com 1, 2 ou 3 transistores)
  • Orgão eletrônico
  • Aparelho de telegrafia "Morse"
  • Alarme eletrônico
  • Intercomunicador (o favorito da família)
  • Detector de luz
  • Detector de ruído
  • Iluminação automática
O manual (à esquerda na imagem) continha a aplicação dos circuitos, um resumo de teoria e uma descrição do funcionamento dos circuitos. Detalhe: o manual (em português) era impresso na Holanda.

A montagem (vide a parte direita da imagem) utilizava grampos com molas para dispensar a soldagem e permitir a desmontagem e montagem inúmeras vezes (se bem que não era fácil prender mais de dois fios em um grampo e era comum dar mau contato).

Aqui no Brasil este tipo de brinquedo parece não mais existir. Nos EUA ainda existem vários modelos:





sábado, setembro 13, 2008

Eventos da Comunidade C / C++

A comunidade de usuários de C e C++ do Brasil conta com dois eventos nos próximos meses:

5o Encontro de Programadores de C & C++

Será no dia 4 de outrubro de 2008, no prédio da Microsoft aqui em SP. Evento gratuito. Maiores detalhes em

http://www.ccppbrasil.org/wiki/Grupo:Encontro_V

O site www.ccppbrasil.org contém detalhes dos encontros anteriores.

C & C++ para Sistemas Embarcados

No dia 8 de novembro de 2008, também aqui em SP. Evento organizado pela Tempo Real Eventos. Detalhes em

http://www.temporealeventos.com.br/?area=118

(aviso: uma das palestras será minha)

terça-feira, setembro 09, 2008

FUNBEC e os Kits Científicos

Este post nasceu da idéia de preparar uma lista de sugestões de presentes "diferenciados" para o dia da criança. Infelizmente, parece que está indo mais para a linha de lembranças de grandes brinquedos do passado que sumiram com os anos.

Uma das minhas lembrança de infância são os kits científicos da FUNBEC, particularmente o computador "Gabriela I".


A FUNBEC era uma fundação privada, com apoio inconstante do governo, que criou uma série de kits científicos no final dos anos 60 e nos anos 70. O seu ponto alto foi a coleção "Os Cientistas", publicada pela Editora Abril.


Foram 50 kits lançados a cada duas semanas. Cada kit continha a biografia de um cientista e material para realizar experiências relacionadas. Tínhamos a coleção completa em casa, mas admito que fiz apenas parte das experiências. Uma lembrança eram os ocasionais passos aparentemente simples, descritos em uma frase curta, que se mostravam quase impossíveis na prática!

Uma pesquisa na internet revela o quanto se esqueceu deste empreendimento. Um artigo curto pode ser encontrado em

http://www.inova.unicamp.br/inventabrasil/kitcienc.htm

Uma entrevista com o principal dirigente da FUNBEC, Isaias Raw, está em

http://www.revistapesquisa.fapesp.br/?art=2860&bd=1&pg=1

A FUNBEC faliu em 1988.

sábado, setembro 06, 2008

Microcontroladores - parte 12

Continuando com os exemplos, vamos examinar o MSP430 da Texas (que eu já comentei antes).

A família MSP430 tem uma arquitetura tradicional (Von Neuman) de 16 bits (registradores e unidade lógica/aritmética de 16 bits).

O microcontrolador na foto, o MSP430F2011, tem as seguintes características:
  • Clock de 10Hz a 20KHz
  • Flash de 2KBytes (para o programa) mais 4 segmentos de 64 bytes (normalmente usados para configurações e outros dados não voláteis)
  • Ram de 128bytes
  • Até 10 E/S digitais
  • WDT
  • 2 Timers
Toda a memória é acessada direta ou indiretamente através de um endereço de 16 bits:

Na figura acima, Info são os quatro segmentos de flash, Bootloader é uma área fixa de fábrica (Rom) que contém um bootloader serial e Periféricos são registradores de controle do funcionamento dos periféricos do microcontrolador.

A estrutura de registradores é bastante versátil, com 16 registradores de 16 bits:
Os registradores R0, R1 e R2 tem funções específicas (ponteiro de instruções, ponteiro da pilha e status). O registrador R3 é um pseudo-registrador que permite gerar algumas constantes comuns (como 0, 1 e 2).

Um dos ambientes disponíveis para programação C é o IAR Embedded Workbench (uma versão limitada é fornecida pela Texas junto com um dispositivo de programação e debug de baixo custo).

O IAR Embedded Workbench dispõe de uma IDE bem razoável, assembler, compilador, linker, locate e debug. Uma diferença em relação aos que vimos anteriormente é o suporte a C++.

Como de costume o IAR Embedded Workbench possui uma biblioteca padrão C e mais rotinas específicas para uso dos recursos do MSP430.

sexta-feira, setembro 05, 2008

Google Chrome - Mais Considerações

Não param as repercussões sobre o anúncio do Chrome e a liberação da primeira versão beta. Seguem abaixo mais algumas considerações a respeito.

Presença do Chrome na Internet

Os vários sistemas de medição de navegação estão reportando uma "presença significativa" nestes primeiros dias. O StatCounter fala em 1% no dia do lançamento. Dos últimos 500 acessos a este humilde blog, 34 foram com o Chrome:

Clique para ampliar

Uma curiosidade no gráfico acima: IE6 e I7 empatados enquanto que o FF3 dá um banho no FF2. Isto reforça a visão de que os usuários de IE relutam em mudar de browser e os de FF são muito abertos a mudanças. Como consequência, o Firefox poderá ser muito mais afetado pelo Chrome que o IE. Aliás, é o que mostram os novos números do StatCounter.

A presença atual do Chrome se dá mais por curiosidade; faltam ainda uma série de coisas para ser um navegador a usar no dia-a-dia (como extensões, mas já tem o plugin do Flash).

Mais um Browser para Testar?

Algumas pessoas argumentam que os programas deveriam seguir os padrões e não se preocuparem com os browsers. É uma postura no mínimo ingênua. Mesmo que num futuro próximo a maioria dos browsers siga fielmente aos padrões, existe todo o parque instalado (veja lá em cima o IE6). A história mostra também que padrões sempre tem alguma ambigüidade.

Outro argumento é que como o Chrome usa o 'mesmo' rending engine que o Safari, basta testar em um. O próprio gibi-propaganda da Google menciona que a compatibilidade do Chrome com o teste Acid3 foi mudando ao longo do projeto. Existem mais coisas envolvidas na apresentação de páginas Web que o rending engine, não esquecendo também que o interpretador JavaScript é totalmente novo. E, aliás, o Chrome está usando uma versão mais antiga do webkit.

Portanto, desenvolvedores de aplicações web para o grande público, comecem a renegociar os prazos de testes.

A Polêmica da EULA

Uma teoria minha é que na medida em que crescem as empresas de tecnologia americanas a visão do que vai ser feito vai saindo da Engenharia e indo para o Marketing e o Financeiro. Silenciosamente, a decisão final vai parar no Jurídico. Podem-se discutir as posições dos três primeiros, mas poucos tem coragem de peitar o último quando ele diz que algo não deve ser feito ou deve ser feito de uma determinada forma. Como a tirinha do Dilbert já mostrou repetidas vezes, nenhuma boa intenção passa ilesa pela revisão do Jurídico.

As EULAs são um exemplo clássico. O objetivo principal de uma EULA moderna não é definir o que o usuário pode fazer com o software, mas sim proteger a empresa de processos.

No caso Chrome, originalmente a EULA estipulava que você dava à Google licença para usar na promoção do Chrome todo o material que você gerasse ou enviasse através dele (alguma interpretações são ainda mais genéricas, mas mesmo essa já dá para assustar muita gente).

Com a gritaria chegando às manchetes, a Google tirou esta cláusula da EULA e explicou que estava lá por engano por ter sido copiada da EULA de outros serviços (hora de muita gente rever o que andou assinando por aí).

Acessibilidade

Existem muitas complexidades em fazer um software hoje em dia. Uma delas é "acessibilidade" e a versão beta do Chrome ainda deixa a desejar neste quesito.

Código Aberto é Solução para Tudo?

Os paranóicos de plantão (e devem ser todos, pois eles não vão confiar o plantão para outras pessoas) estão preocupados com eventuais malvadezas no Chrome. Coisas como enviar para o Google informações sobre a navegação do usuário sem ele saber ou impedir que anúncios sejam bloqueados.

A primeira defesa da Google é que o código do Chrome é aberto. Certamente que grandes malvadezas seriam percebidas rapidamente.

Entretanto, o comando do projeto é primariamente da Google. É ela quem vai dar a palavra final sobre o que entre e o que não entra no Chrome. E se ela tomar uma decisão que não agrade muita gente? A licença de uso dos fontes produzidos pela Google é a BSD que é permissiva o suficiente para uso em produtos derivados com código aberto ou fechado, portanto um fork deve ser legalmente viável (deve ser, pois existem outros aspectos como patentes que podem complicar).

Entretando, provavelmente vai ser uma divisão muito desequilibrada. De um lado a Google investindo pesado na evolução do Chrome e do outro uma comunidade nem sempre unidade tentando acompanhar. Basta ver que a simples disponibilidade do webkit não gerou outros browsers de destaque além do Safari (e agora o Chrome).

A Velocidade do JavaScript

Não há dúvida que o Chrome tem o mais rápido JavaScript entre os browsers em campo (porém o Firefox tem algo comparável em laboratório).

A grande questão é: será que isto é mesmo preciso? Não existem outros pontos que deveriam ser mais prioritários nos browsers?

Está bem claro que a visão Google é colocar cada vez mais código JavaScript nas suas aplicações. Com o Gears existe a possibilidade deste código usar mais recursos locais, ficando até independente da web.

Alguns (e eu me encaixo em parte neste grupo) acham que existe um certo exagero no uso de JavaScript. Assusta ver que o gibi-anúncio do Chrome (que basicamente é conjunto de imagens estáticas) depende do JavaScript (mas pelo menos agora tem navegação pelas páginas).

Corrigido às 13:00: existe sim plugin para o Flash.

quinta-feira, setembro 04, 2008

Livro: Pérolas Dão Azar

Aconteceu de eu precisar matar algum tempo, dar uma olhada em uma banca de revistas e encontrar este livro. Já mencionei antes Raymond Chandler, que foi um dos mestres do estilo noir. Este livro é uma coletânea de histórias (relativamente) curtas; folheando tive a impressão de já conhecer algumas (e realmente, várias delas estão na coletânea The Simple Art of Murder).

Estas histórias não são tão elaboradas quanto as histórias longas com Philip Marlowe e me pareceram bem mais violentas (exceto a última).

Seguem alguns comentários sobre cada uma delas.

Tragédia em Bay City - Bay City Blues

"Contemplei o último raio de sol escorregar do peitoril da janela e cair no beco escuro lá em baixo."

O detetive particular Johnny Dalmas recebe uma indicação de cliente do policial Violets M'Gee - e começa a achar corpos. Como de costume neste tipo de romance policial, ele vai longe movido apenas por lealdade ao cliente.

O Jade do Mandarim - Mandarin's Jade

"O corpo estava estendido de costas junta a uma moita, os membros jogados de um jeito que sempre indicava a mesma coisa."

Novamente M'Gee indica um cliente para Johnny Dalmas, que e novamente os corpos se amontoam.

O Crime Errado - Smart-Aleck Kill

"O sedã marrom arrancou, atravessando o cruzamento como um gato perseguido por um cão policial."

Mais uma história com Dalmas, mais um cliente fazendo besteiras. Como diz Dalmas no final: "Vamos apenas beber".

O Carro da Morte - Nevada Gas

"Havia certa tensão em sua imobilidade, como se fosse um animal prestes a dar o bote."

A história mais estranha (e violenta) do livro, demora um pouco até se perceber quem é o protagonista principal (que diz ao final "Chame-me apenas de otário").

Pérolas Dão Azar - Pearls Are a Nuisance

"A hora do crepúsculo está chegando. Os pintarroxos estão chamando, os esquilos começam a se recolher e todas as glórias do dia põem-se a recuar, em busca do sono noturno."

Uma tradução mais precisa do título seria "Pérolas são um incômodo". Uma história bem-humorada, onde ninguém morre.


Resumindo, não é o ápice do autor mas são histórias bem escritas e que merecem ser lidas por quem aprecia o estilo.

Atualizado às 16:00: acertados erros de digitação, trocado estória por história (tendo visto as considerações neste artigo).

quarta-feira, setembro 03, 2008

Google Chrome: Uma Análise

O anúncio do browser da Google (Google Chrome) está gerando bastante barulho, aqui está a minha contribuição para esta cacofonia.

O Aspecto de Marketing

Na virada do século eu trabalhei por um ano em Marketing de Produto, o que incluiu um curto curso sobre o assunto. Uma das coisas que aprendi é que a tendência natural dos mercados ditos maduros é ser dominado por duas empresas: a líder e a desafiante (aspirante a líder). Um cololário disto é que a pior coisa para uma empresa é ficar na terceiro posição (ou abaixo). Quem está nesta situação tem duas estratégicas básicas: forçar uma mudança de paradígma (criando algo revolucionário e voltando o jogo para o zero-a-zero) ou fracionar o mercado criando uma nova categoria em que seja líder.

Atualmente o mercado de browser tem como lider o IE e como desafiante o Firefox (considerações de merecimento à parte). Google é hoje uma marca extremamente forte e, salvo pisadas na bola fenomenais, irá entrar nesta briga. No "gibi-anúncio" do Chrome fica evidente que a Google está tentando posicioná-lo como revolucionário (considerações de mercimento também á parte).

O Aspecto Econômico I

Porque a Google resolveu criar o seu browser? Existem pelo menos dois grandes motivos, um de curto prazo e outro de média/longo prazo.

No curto prazo, a Microsoft declarou guerra ao Google no mercado de busca. O passado mostra que a Microsoft não hesita em usar os seus produtos estabelecidos como armas para ganhar novos mercados (e em algumas ocasiões a justiça americana julgou que ela passou dos limites). Prevalecendo o domínio do IE a Google fica vulnerável.

No médio/longo prazo, existe o velho conceito do browser como sistema operacional. A teoria é que com as aplicações rodando dentro de um browser padrão o S.O. sob o qual o browser roda passa a ser irrelevante. Oracle e Sun tentaram usar isto no passado para derrubar o domíno do Windows. Não tiveram sucesso, mas as aplicações Web continuam ficando mais sofisticadas.

O Aspecto Econômico II

Numa outra faceta, cada vez mais pessoas se preocupam com o avanço da Google. O medo de um monopólio das aplicações intenet é cada vez maior. Dominando o browser, a Google ocupa mais um pedaço do teritório e proteje um pouco mais a parte já conquistada.

Da mesma forma que no passado os desenvolvedores reclamavam que a equipe de desenvolvimento do Windows passava informações privelegiadas para os desenvolvedores das outras outras aplicações Microsoft, surge a preocupação das aplicações Google estarem prontas para aproveitar novos recursos do Chrome antes das outras.

O Aspecto Técnico

Esta minha análise se baseia principalmente no gibi-anúncio. É claro que ele foi concebido mais pelo departamento de Marketing que pela Engenharia, portanto é preciso dar algum desconto.

De uma forma geral não existem idéias revolucionárias no Chrome. Fãs dos outros browser certamente irão dizer que características do Chrome já existem ou estão em desenvolvimento no seu favorito. Sigo abaixo a ordem do gibi-anúncio.

Logo na primeira página, fala-se em "partir do zero". Embora grande parte possivelmente seja nova, partes importantes vem de código já existente (como já é dito logo na página seguinte) e é claro que o Chrome precisa seguir os padrões já existentes e suportar as aplicações que já estão aí.

Tenho minhas dúvidas sobre até que ponto os browsers são single-threaded. O Firefox onde estou digitando este texto possui 18 threads no momento. O uso de múltiplos processo é uma idéia intrigante. Certamente aumenta o isolamento porém segue o caminho inverso do mundo *nix (o Unix tinha inicialmente somente processos, threads foram introduzidos para melhorar a performance). Uma das novidades anunciadas no IE8 é uma maior resistência à "morte" de uma aba, que é uma das vantagens apontadas para o modelo multi-processo. A vantagem de liberar tudo quando uma aba é fechada ou quando se navega para outro domínio é relativa. Um botão "back" rápido é essencial e uma das características aplaudidas no IE8 (e já existente no Firefox há anos) é reabrir rapidamente uma aba que tinha sido fechada.

A idéia de um task manager no browser parece ótima, porém não ficaria muito otimista quanto a isto permitir identificar o culpado por travadas (a Microsoft luta com drivers hostís há décadas e continuam culpando somente ela).

Os procedimentos de testes são interessantes, mas nada de supreendente. Ousaria dizer que é o mínimo que se espera dos vários desenvolvedores de browser (testes unitários, testes automáticos, testes aleatórios, etc).

Uma parte crítica em um browser é a rending engine e o Chrome utiliza a webkit, que é a mesma usada no Safari da Apple. Um destaque da webkit é gabaritar nos testes Acid2 e Acid3. Por outro lado, passar em testes de aderência a padrões não é um quesito necessário nem suficiente para um browser (basta ver que o IE é quem sai pior nestes testes).

JavaScript é hoje a base da chamada "Web 2.0" e abusada para limites nunca sonhados inicialmente. É um dos pontos em que a Google decidiu investir mais, criando um novo interpretador (V8). Como outros interpretadores modernos, o V8 dispõe (ou disporá?) de compilação JIT e garbage collection eficiente. Não por acaso, o Firefox também tem um novo interpretador de JavaScript em desenvolvimento.

A interface com operador será a parte mais notada pelos usuários. Seguindo a linha dos demais browser, a área no topo é reduzida, ampliando a área útil. As caixas de endereço e busca foram juntadas em uma só, o tempo dirá se isto facilita ou complica. Um recurso que me fará falta é a facilidade de mudança de máquina de busca (eu mudo toda hora entre o Google e a Wikipedia).

As abas recém abertas apresentarão miniaturas das nove páginas mais visitadas. Este é mais um recurso já existente em outros browsers. Eu uso em casa o plugin fast dial do Firefox; por outro lado prefiro uma página fixa no trabalho.

O Chrome vai incluir um modo de maior privacidade, que já existe em alguns browser e causou algum barulho no beta do IE8. Basicamente este modo tenta evitar registrar no micro as páginas acessadas, para permitir "escolher presentes" (interessante, é o mesmo eufemismo da Microsoft, o uso real deste recurso é obvio). Não custa lembrar que nos dois casos registros da navegação podem estar sendo registrados externamente (por exemplo no proxy de acesso à internet na rede da empresa) ou mesmo no próprio micro em locais acessíveis por um investigador persistente.

Como todo browser moderno, o Chrome terá recursos para bloquear pop-ups. É claro que continuará existindo gente tentando burlar e pop-ups legitimos sendo bloqueados.

A parte de segurança também não me parece ter nada revolucionário. Existe a promessa de um maior bloqueio a ações indevidas e uma excessão já criada para os plugins.

Por último temos o Gears que é uma expansão do browser para fornecer funções locais mais avançadas (o que poderíamos dizer ter sido a mesma motivação para os controles ActiveX da Microsoft).

Como Será a Briga?

Para quem pensa que o Chrome vai triunfar fácil desde o começo, um dos primeiros relatos de testes mostra que a versão liberada hoje ainda não está totalmente ao nível do hype. Além de achar lento, o reporter conseguiu travar todas as abas ao tentar ver um vídeo em uma delas. Nada inesperado numa primeira versão beta, mas vale como uma lembrança das dificuldades pela frente.

Não há dúvida que a Microsoft irá reagir fortemente ao Chrome, investindo ainda mais no IE8 (tanto em aspectos técnicos como de marketing).

Meu palpite é que quem vai sofrer mais com a entrada do Google vão ser os menores, particularmente o Firefox, que não terão fôlego para enfrentar mais este desafiante.

Uma coisa é certa: os desenvolvedores web vão sofrer mais no curto e médio prazo, tendo mais um browser para suportar.

terça-feira, setembro 02, 2008

Google Chrome - A Revista

A grande notícia da semana é certamente o anúncio do browser da Google. Pretendo fazer um post mais longo com os meus comentários sobre ele, mas para isto pretendo ler e reler o comic book com a descrição do projeto.

Infelizmente, a versão oficial não permite a fácil navegação entre as páginas. Entretanto a revista foi inicialmente distribuída impressa para jornalistas e mentes empreendedoras repararam que a licença para o material permite cópias sem fins comerciais desde o autor seja identificado e trataram de digitalizar as páginas. Uma versão on-line com endereçamento direto das páginas está aqui. Mais interessante para mim, aqui tem um pdf (link obtido deste blog).

Seis Problemas com Lojas On-line

Embora as lojas on-line (ou lojas virtuais ou etc) não sejam nenhuma novidade, é frequente me defrontar com alguns problemas. Segue abaixo uma lista desorganizada de alguns deles:

Buscas excêntricas
Vários sites são extremamente sensíveis à grafia dos termos de busca. Outros são sensíveis de menos e acabam retornando uma quantidade imensa de itens não relevantes. Para complicar, poucos possuem uma "busca avançada" com critérios adicionais de busca.

Emails de confirmação não confiáveis
Todos os sites dizem que estão enviando um e-mail de confirmação do pedido, porém em várias compras num site "famoso" não veio nada. Para contrabalançar, teve um outro site que enviou a confirmação uma meia dúzia de vezes. O que parece não falhar são os e-mails de propaganda.

Endereços de entrega
Normalmente eu prefiro receber o que compro no trabalho, onde eu estou na maior parte do horário comercial (que é o horário de entrega do Sedex e da maioria das empresas). Ocasionalmente eu quero que a compra seja entregue em um outro endereço (por exemplo, quando é presente). Não creio que estas necessidades sejam somente minhas. Entretanto, a maioria dos sites assume que a entrega será sempre no endereço do cadastro (que normalmente é o residencial) e te obrigam a re-digitar o endereço.

O prêmio vai para um site onde eu fiz uma compra hoje. Para entrar na tela de cadastro, ele pergunta o CEP (obviamente entrei com o da minha casa). No cadastro tem lugar somente para o endereço de entrega, que veio preenchido conforme o CEP. Felizmente o site permitia mudar os dados inclusive o CEP. Infelizmente o site montou o endereço de entrega com os dados que eu digitei mais o CEP inicial (ignorando o CEP digitado junto com o endereço). O jeito foi ligar por telefone e pedir para corrigir (ponto positivo: a correção apareceu na hora na internet).

Bugs - Alguém testa site antes de por no ar?
Esta foi na semana passada. Procurando um DVD, encontrei por um bom preço em um site em que eu já tinha feito compras. Na hora de confirmar o pedido, o site informou que o meu cadastro estava incompleto: faltava a cidade. Na tela estava o CEP, a rua e o estado. Ok, alguém não pensou em pegar a cidade a partir do CEP. Tudo bem, é só selecionar na drop-list, clicar em Salvar... e obter um erro dizendo que a cidade 0 não pertence ao estado. Santo nenhum fez a site aceitar a cidade. Experiementei até entrar com outro CEP: novamente veio a rua e o estado e nada da cidade.

O site tem uma ajuda on-line: sou o oitavo da fila. Felizmente anda rápido (desconfio que é gente desistindo). Quando explico o problema para a atendente, ela dá um cut-and-paste de uma explicação de como apagar os cookies no IE. Explico que não estou usando IE e que não pretendo apagar os meus cookies. Impasse, acabei comprando em outra loja.

No dia seguinte entrei novamento no cadastro e a cidade estava magicamente preenchida...

Status incompletos e desatualizados
Fica muito bonito colocar na tela um "acompanhe o seu pedido", porém pouca gente se preocupa em deixar claro qual o encaminhamento de um pedido e/ou atualizar com frequência razoável o andamento. Já ocorreu do pedido ser entregue antes do site indicar que ele tinha sido expedido. As indicações do andamento são muita vezes vagas, dúbias ou enigmáticas. O que nos leva ao ponto seguinte...

Os loucos administrando o hospício
Regra número 1 de usabilidade: lembre-se que o usuário não é um desenvolvedor. Muitos sites insistem em apresentar mensagens extremamente técnicas. Menção (des)honrosa para o site que indica com "transação não concluída" quando o pedido foi aceito, a mercadoria separada e despachada mas ainda não entregue.

segunda-feira, setembro 01, 2008

Microcontroladores - Parte 11

Como exemplo seguinte de microcontrolador, vamos examinar o 8051.

Este microcontrolador foi projetado pela Intel porém sua arquitetura é utilizada por vários fabricantes (Texas, Atmel, ST, NXP e outros). É uma arquitetura Harvard (como o PIC) porém "amenizada" em vários aspectos.

Como exemplo de microcontrolador derivado do 8051 escolhi o Texas CC1010:
  • Clock de 3 a 24MHz
  • Flash de 32KB (organizada em 128 páginas de 256 bytes, cada página pode ser apagada e regravada separadamente, inclusive por controle do firmware)
  • Ram de 128bytes + 2KB (veremos isto melhor adiante)
  • até 26 E/S digitais
  • ADC de 10 bits
  • RTC
  • WDT
  • 4 timers (2 com PWM)
  • 2 UARTS
  • SPI
A figura abaixo mostra o mapa da memória do CC1010:
A memória está dividida em três regiões distintas (DATA, XDATA e CODE); instruções diferentes são utilizadas para acessar cada uma delas. As regiões DATA e XDATA são de memória Ram e a CODE de memória Flash. Todas as regiões estão organizadas em bytes; no caso do código (região CODE) as instruções tem tamanho variável.

Somente a região DATA permite acesso direto (com o endereço codificado diretamente na instrução). O acesso às outras duas regiões é indireto: o endereço deve ser colocado em um registrador, o que torna o acesso mais complicado e lento (para acesso a variáveis individuais).

Como no PIC, uma região de endereçamento da Ram corresponde a registradores de controle do microprocessador - é a que está marcada como SFR na figura.

Do ponto de vista de registradores de uso geral, o CC1010 possui uma quantidade bem maior que o PIC:
Os registradores R0 a R7 podem ser usados livremente. O registrador PSW é o status do processador e ACC o acumulador. SP é o stack pointer; o stack no 8051 reside na área DATA e pode ter, teoricamente, até 128 bytes. Ao contrário do PIC, o stack não está limitado a endereços de código. Para acesso indireto a XDATA é o usado o Data Pointer DP. Existem dois pares de DP no CC1010 e em cada um deles a parte alta e baixa pode ser acessada individualmente, resultando nos registradores DPH0, DPL0, DPH1 e DPL1.

Resumindo, o 8051 possui algumas excentricidades mas é um processador bem mais agradável de programar em Assembler que o PIC.

Como exemplo de ambiente de desenvolvimento em C, vamos examinar o Keil uVision2 (que não é a versão mais recente). A Keil é uma empresa alemã bastante tradicional neste segmento. O uVision é um produto extremamente profissional e tem uma documentação excelente.

O pacote inclui uma boa IDE (faz falta somente algo parecido ao Intelisense do Visual Studio), assembler, compilador, linker, locator (aplicativo que define os endereços absolutos onde ficarão código e dados) e debugger.

O compilador C possui uma biblioteca padrão boa e mais bibliotecas específicas para vários modelos de microcontroladores baseados na arquitetura 8051.

Para suportar as várias regiões de memória a Keil utiliza os modificadores DATA, XDATA e CODE:
char *p;
char code *p;
char xdata * data p;
Na primeira linha temos um ponteiro genérico para um char. Como este char pode estar em qualquer uma das regiões, o Keil aloca três bytes para este ponteiro: um para indicar a região referênciada e dois para o endereço na região. Embora genérico, este tipo de ponteiro é muito ineficiente: a cada acesso é preciso testar qual região está sendo endereçada e desviar para as intruções adequadas. Desta forma um simples *p vira uma lenta chamada de subrotina.

Na segunda linha estamos informando que p aponta para um char que está na área CODE. isto permite gerar código bem mais eficiente.

É claro que o ponteiro em si também está armazenado em algumas das regiões; o Keil permite dizer em qual delas. Na terceira linha temos um ponteiro p armazenad na região DATA que aponta para um char na região XDATA.