Voando Alto e Rápido

Outra razão pela qual mais potência nem sempre é uma boa coisa

O texto citado abaixo não é de minha autoria.  Foi escrito por um piloto americano, e eu apenas o traduzi algum tempo atrás.  Mandei-o por e-mail para vários amigos, mas nunca o publiquei, e nunca vi nada semelhante publicado em português.  Acho bastante interessante que meus amigos pilotos o leiam. Embora ele fale especialmente de um modelo de aeronave - o Van's RV-4 - ele é válido para qualquer aeronave.

"Eu me considero um piloto medianamente experiente, tendo cerca de 1400 horas em meu RV-4, 3000 em F-16 e muitas mais em outras (não tão divertidas) aeronaves. Entretanto, minha volta para casa do trabalho foi um pouco diferente hoje, e eu aprendi algo novo.

Eu estava no meu próprio RV-4 de 150 HP, retornando para a Flórida de um fim de semana voando F-16 no Alabama. Estava cruzando a 11.500’ em ar calmo e frio. Faltavam apenas 235 milhas para casa, mas o caminho à frente estava crivado de tempestades. Passando Thomasville, GA, as formações ficaram mais juntas, forçando-me a voar em curvas em volta dos cúmulos que iam muito acima da minha altitude. O controle de JAX estava me fornecendo atualizações contínuas do tempo, e com sua ajuda e boa visibilidade eu estava quase gostando dos meus zig-zags em volta das nuvens. Então, saindo de trás de uma nuvem, eu vi que minha passagem à frente havia ficado bem estreita e abaixo de minha altitude. Havia céu azul além dela.

Olhei para cima por alguns segundos para julgar as nuvens enquanto fazia um 360º em descida como já tinha feito um milhão de vezes antes no ar mais denso de 5.000’. Mas desta vez senti algo diferente – uma vibração de muito alta frequência. O stick sacudia na minha mão e toda a estrutura vibrava como se algo tivesse se soltado (Sintomas sugerindo fortemente flutuação dos profundores... N.E). Olhando o painel, descobri que estava com o nariz 15º baixado, inclinado para a direita 30º, cruzando 10.800’, com cerca de 2G e 185 nós. Imediatamente reduzi a potência e, suavemente, nivelei as asas. Abaixo de 175 nós a vibração cessou, então continuei através da passagem e aproei para casa. Passei uma boa parte do tempo restante olhando para trás, para ver se a cauda ainda estava lá. Após pousar, retirei a empenagem e examinei todos os pontos de fixação, cabos, dobradiças e a estrutura. Nem um arranhão.

Epílogo: fui para a Internet e pesquisei flutuação em aeronaves leves. Há alguns bons artigos sobre o assunto. Aparentemente eu devia saber que a 10.800’ minha Va a 2º Celsius e 185 nós indicados era acima de 236 nós. Isso é mais de 30 nós acima da Vne do RV-4!

Bem, eu sou um mimado piloto de F-16. Não há restrições de velocidade no F-16. Conheço meu RV-4 bastante bem, mas quantos de nós conhecemos nossas aeronaves acima de 10.000’? Eu sei que existe uma razão para o meu RV-4 ter uma Vne, e agora entendo porque esse limite muda com a altitude.

Há uma tendência atualmente para RVs mais potentes e velozes. Talvez os pilotos devam considerar cargas de projeto e limites antes de fazer isso. Minha experiência poderia ter acontecido com qualquer um. Eu tive sorte. O próximo talvez não tenha."

Nunca ouvi nenhum de meus instrutores chamar a atenção para este simples fato: a Vne se refere à Va, e NÃO à Vi!  Estamos acostumados a ler um intrumento que nos indica Vi, e quase todos os parâmetros importantes de vôo se referem à Vi: Stall (início dos arcos verde e branco), Cargas de Rajada (topo do arco verde), Velocidade de Manobra (linha azul).

Mas NÃO a Vne.  Esta depende da velocidade real de escoamento do ar sobre as superfícies, e é portanto expressa em Va.  Em um exemplo simples, a 8000' (que nem é uma altitude tão grande assim) uma Vi de 200kt corresponde à Va de 225kt.  Esta diferença pode facilmente nos levar acima da Vne sem nosso conhecimento, a não ser que tenhamos pleno conhecimento disto!

...e mais Velocidade!

...e como dizíamos... ainda temos que considerar os periféricos!

Em um computador de grande porte, periféricos como memória volátil, memória de massa e interface de vídeo têm uma enorme influência no desempenho do sistema.

Tratando-se de microcontroladores, normalmente memória de massa e vídeo são bem menos importantes.  Mesmo assim, a influência dos periféricos pode ser importante:

• Memória Volátil: ela deve ser rápida o suficiente para acompanhar a maior velocidade de acesso do processador, e em quantidade suficiente para manter todos os dados mais acessados disponíveis.  Se for lenta, seu acesso irá atrasar o processador.  Se for muito pequena, obrigará que algumas informações fiquem armazenadas em outras áreas, certamente ainda mais lentas, como uma memória "flash";
• Memória de Massa: no caso do microcontrolador, ela será quase certamente uma "flash".  Essa memória é destinada a armazenar maiores quantidades de dados, especialmente os pouco voláteis, já que, embora apresente boa velocidade de leitura, sua gravação costuma ser bem mais lenta.  É comum as "flash" utilizarem interfaces seriais, e se essa interface não tiver boa velocidade pode prejudicar ainda mais o desempenho deste periférico;
• Comunicação: É muito comum a necessidade de um microcontrolador comunicar-se com outro, ou com um grande computador que controle o sistema.  Caso a interface utilizada para isso seja muito lenta, ou exija muitos recursos do processador, isso irá certamente degradar o desempenho de todo o sistema;
• Captura de Eventos: o software de controle de uma máquina automatizada precisa com frequência capturar eventos externos, ocorridos em qualquer lugar da máquina.  Caso o microcontrolador não disponha de hardware especializado para essa captura, o processador gastará um tempo considerável observando esses eventos, o que também irá causar grande degradação em seu desempenho;

Em um computador de maior porte é comum se utilizar, por exemplo, um programa de reprodução de mídia, cuja função principal é atualizar o vídeo em alta velocidade e definição.  Num sistema microcontrolado, ao contrário, as interfaces humanas (vídeo e/ou teclado) não são normalmente utilizadas para desempenho das funções principais do sistema, sendo seus requisitos de volume e velocidade bem menores.  Pode-se, assim, utilizar interfaces menos rápidas e complexas.

A otimização do desempenho de um sistema microcontrolado, como se pode ver por esta discussão, não é um problema simples ou banal.  Depende de um bom conhecimento da aplicação a ser desenvolvida e das famílias de controladores disponíveis.  Além do ingrediente mais importante de todos: uma boa dose de experiência e de bom senso por parte do engenheiro de software.

Velocidade...

... de processamento!  Não vamos falar aqui da Suzuki Hayabusa, nem da Bugatti Veyron, mas sim de velocidade da execução de código em computadores - mais especificamente, em microcontroladores.

Um grande problema quando se fala em computadores, ou controladores, está em escolher o modelo que nos trará os recursos e o desempenho desejados.

O problema começa porque, diferente de um carro ou de uma moto, um computador não é um sistema fixo e completo.  Quando escolhemos um carro, temos para cada modelo no máximo duas ou três opções de motorização... talvez dois câmbios... e fim!  Passa a régua!  Para cada combinação (e são poucas) teremos um teste de desempenho feito, se não pela fábrica, pelo menos pelas revistas especializadas!

Mas em se tratando de computadores... qual o modelo do processador?  Quanta memória "cash" L1 e L2?  Que velocidade de "clock" vamos utilizar?  Qual a quantidade e tipo de memória RAM?  Qual o "chipset" utilizado?  Qual a velocidade e a largura do barramento de IO?  Qual a capacidade do HD, e qual sua velocidade de transferência?  Que adaptador de vídeo, e com quanta memória?  Que adaptador de rede... e qual a rede?  Vamos utilizar Flash?  Com interface paralela ou serial, e que velocidade?

Ufa...

Mesmo em se falando apenas de microcontroladores, que usualmente não utilizam HD, video ou redes, a multiplicidade de escolhas assusta.  E o número de combinações não permite um "benchmark" de cada uma em especial.  Aí só o bom senso e a experiência podem nos ajudar.  Por isso, vamos falar aqui dos principais fatores, e sua influência no desempenho de um controlador.

Para começar, o processador, que é o "core", o ponto central do controlador:

A primeira grande classificação que se observa é a largura do seu barramento de dados interno.  Existem hoje microcontroladores de 8, 16 e 32 bits.  É provável que breve vejamos microcontroladores de 64 bits, já que essa largura é utilizada nos computadores já há algum tempo.  Quanto maior a largura do barramento, maior o desempenho do processador.  Mas essa relação não é fixa, dependendo da arquitetura do próprio processador e da aplicação executada.  Se o processador for utilizado, por exemplo, em uma aplicação de controle de automação, com atuadores simples, e sem cálculos com grandes números, a maior largura de barramento em muito pouco vai influenciar o desempenho.  Ao contrário de uma aplicação com atuadores complexos e cálculos envolvendo grandes números, onde essa maior largura terá um impacto significativo sobre o desempenho.

O segundo parâmetro mais utilizado costuma ser a velocidade de "clock".  Como todo processador atual utiliza um sinal de "clock" para sincronizar toda a sua atividade, esse sinal nos dá uma boa noção de seu desempenho.  Só que também não é tão simples como parece!  Um modelo de processador pode executar uma instrução em cada ciclo de "clock", enquanto outro precisa de 2 ou 3 ciclos para cada instrução.  A IBM, lá pelos idos de 1970, introduziu uma medida que chamou de MIPS - milhões de instruções por segundo - que media a velocidade de instruções realmente executadas, não apenas de "clock".  Mas nem isso resolve o problema, já que diferentes arquiteturas de processadores têm diferentes instruções, e tarefas diferentes são realizadas em uma instrução.  Assim o MIPS só faz realmente sentido para comparar vários processadores de uma mesma família.

Para complicar ainda mais as coisas, a largura de barramento pode não ser constante - é comum, por exemplo, um processador de 16 bits (barramento interno) comunicar com seus periféricos externos através de um barramento de 8 bits.  O desempenho será de 16 bits nas operações internas, mas de apenas 8 bits em operações que envolvam esses periféricos.  Da mesma forma, o barramento externo pode ter velocidade diferente (geralmente menor) do que o interno.

A para finalizar, complicando ainda mais: em um processador moderno, existe uma boa quantidade de processamento paralelo.  Interrupções são tratadas por um módulo separado, e o processador central só é interrompido já com todos os elementos da interrupção processados, hierarquizados e prontos para tratamento.  Transferências em memória são executadas por um DMA, módulo especializado nisso, e o processador só é comunicado ao fim de uma transferência completa.  Comunicação serial é tratada em outro módulo, e o processador só entra na festa depois de uma mensagem recebida, verificada e classificada.  E assim por diante.  Portanto o desempenho final vai depender em muito de existirem os módulos para processamento paralelo adequados à aplicação que está sendo executada.  Reparem que, mais uma vez, a escolha depende da aplicação.

Não percam o próximo capítulo, onde falaremos dos módulos periféricos que, junto com o processador, compõem a totalidade de um microcontrolador.

Expoentes do Conhecimento

Vocês já devem ter reparado como é difícil prever a evolução do conhecimento e da tecnologia.  Todo fim de ano algum "expert" faz suas previsões para os próximos anos... e de cada vez erra em quase tudo!

Para mim um exemplo clássico é o livro/filme "2001 - A Space Odissey".  O livro, da década de '60, foi escrito por Arthur C. Clarke, talvez um dos melhores escritores científicos até hoje.  E o filme foi feito por Stanley Kubrick, com consultoria do próprio Clarke!  No entanto, suas tentativas de prever o estado do conhecimento em 2001 - pouco mais de 30 anos no futuro - foram completamente fora do alvo.  O filme mostra naves comerciais indo e vindo da Lua, com colônias lá estabelecidas... hoje, 10 anos além da época retratada, até as missões científicas à Lua deixaram de existir.  Mostra uma enorme nave tripulada indo ao sistema de Saturno - bem além de nossas possibilidades hoje.  No entanto, mostra um computador enoooorme nessa mesma nave, sem nada da miniaturização alcançada em 2001, e nele não existem telefones celulares, computadores pessoais, e muito menos algo como a Internet.

E por que um cientista experiente e visionário tem tanta dificuldade em prever o futuro próximo?

Uma das razões disso é o desenvolvimento exponencial do conhecimento humano.  Cada desenvolvimento é baseado na soma do conhecimento já estabelecido, e este é cada vez maior.  Portanto o desenvolvimento é cada vez mais acelerado, de forma exponencial.

Vamos fazer uma brincadeira simples para ilustrar a crescente velocidade desse desenvolvimento:  Se a História Ocorresse em um Dia...

Imaginemos os 5.000 anos de história documentada que temos hoje ocorrendo em um único dia.  Estamos assistindo ao pôr do sol, e relembrando tudo o que aconteceu nesse dia...

• A Roda foi inventada ao amanhecer...
• O Alfabeto, por volta das 9:20 horas...
• A Bússola, pouco depois do meio dia...
• A Imprensa, pouco antes das 5 horas da tarde...
• O primeiro Automóvel e o primeiro Avião apareceram quase juntos, faltando 15 minutos para o por do sol...
• O Homem pousou na Lua há uns 5 minutos...
• e a Internet existe há pouco mais de 2 minutos!

Impressionante, não?  Reparem que em metade de todo esse tempo mal tínhamos chegado à Bússola.  Faltando uma hora, das 12 horas do dia, para o pôr do sol, a imprensa tinha acabado de aparecer.

É essa incrível aceleração na velocidade do desenvolvimento que torna quase impossível prever o que vai acontecer a seguir, e quando.

Há menos de um século as pessoas compravam, por exemplo, um toca-discos (discos de vinil, claro...), e sabiam que o utilizariam por décadas.  Mais recentemente, eu mesmo comprei um CD-player que durou pouco mais de 10 anos antes de ficar obsoleto.  Comecei a usar um DVD, e menos de 5 anos depois o BluRay o tornou obsoleto.  Troquei uma TV antiga, com CRT, por uma LCD, e... raios, a OLED está ali na esquina me olhando!

Chega a ser estressante... imaginem daqui a mais 10 anos?

Sei lá... não faço a menor idéia do que vai acontecer!!!  Só sei que tenho uma enorme curiosidade para ver!  E enquanto houver essa curiosidade estou tranquilo... ainda estou vivo!

A Terceirização do Mal

Desta vez o assunto é sério, galera...

Por que será que as pessoas têm uma capacidade tão grande de negar suas responsabilidades, e sempre terceirizar o mal?

Tenho pensado muito sobre isto, mas a gota d'agua para escrever sobre o assunto foi a manchete do Jornal de Santa Catarina desta semana (mais uma sobre o assunto):

"Gaspar cobra do Dnit solução para trevo onde seis já morreram este ano"

Como foi mesmo?  Mais uma vez um motorista incompetente desrespeitou as leis de trânsito e da segurança.  Mais uma vez isso causou a morte de inocentes.  Mais uma vez todos põem a culpa num inocente pedaço de asfalto???

Vamos combinar, gente!  Que essa rodovia precisa ser duplicada, ninguém tem dúvidas!  Que sua manutenção é sofrível, ok!  Que isso causa desconforto, poluição e prejuízo econômico e para o saco de todos, concordamos!  Mas daí a ser causa de mortes?

A notícia dessa semana é sobre um acidente no trevo de Gaspar.  Para quem não conhece, a rodovia ali é reta, com boa visibilidade, e nesse local há um entroncamento com a entrada para a cidade de Gaspar.  As faixas são contínuas, há uma faixa (abrigo) central para aceleração e desaceleração, para que que os automóveis entrando e saindo da cidade não precisem cruzar ambas as pistas ao mesmo tempo.  Há placas sinalizadoras.  O "descaso" das autoridades se limita à inexistência de lombadas ou de uma rotatória.

Pera aí, não entendi!  Então temos que por uma rotatória em cada derivação da estrada, para obrigar os motoristas a reduzir a velocidade, porque respeitar a lei está fora de cogitação?  Onde está o bom senso, gente?

E aí fico me lembrando de outros exemplos (nem todos ligados ao trânsito).

Outra matéria, meses atrás, sobre outra morte nessa mesma rodovia - a foto do local e depoimentos de testemunhas mostravam claramente uma ultrapassagem em local proibido... culpa da rodovia, claro!

Um religioso que matou um amigo em uma discussão... foi o diabo que o "atentou" para matar, ele não teve culpa.  Aliás, de acordo com alguns religiosos, qualquer obra má é "coisa do Demo".  Coitado do Demo... que costas largas, não?  Tem que responder por todo o mal da humanidade!

Um bêbado que agrediu a mulher e filhos.  Foi a "maldita", ele não estava em seu juízo!!  Como é mesmo??  Ele toma um litro da "maldita", sabendo exatamente seus efeitos, e a culpa não é dele???

Quando é que vamos crescer?  Quando vamos tomar vergonha na cara e assumir nossas responsabilidades?  Essa história de apontar pro coleguinha e dizer "a culpa foi dele" é coisa de criança, gente!  E criança mal orientada, porque se eu fizesse isso em criança apanhava em dobro - pelo mal feito e por tentar por a culpa nos outros!  Cedo aprendi que atenuante para meus "crimes" infantis era encarar meus pais e assumir a culpa.  Aí sim, tudo se resolvia com um papo, uma bronca ou o castigo adequado à falta atenuada.

Ahhhh, desculpem... esqueci que dar uma palmada no filho agora é "politicamente incorreto"... causa traumas!  Coitadinho!  Tem que ser criado sem traumas, para que depois de adulto a sociedade o eduque, e talvez o mate no processo!

Tem horas em que fico com muito medo pelo futuro de nossa sociedade... sinto o frio dos primeiros ventos invernais, trazendo a decadência de nossa cultura, nossa retidão moral e nosso valores.

Uma questão de Nivel...

Estou atualmente ministrando um curso de programação de microcontroladores.  E como sempre surge a polêmica:  Linguagem de alto nivel?  Baixo nivel?  O que é isso?  O que utilizar, e quando?

Bom... "nivel" é um conceito relativo.  Todos concordam que as linguagens Assembly são baixo nivel.  Mas a partir daí, o cenário fica muito mais confuso!

Essa classificação foi criada quando só existiam os Assemblers e os compiladores procedurais.  Nesse cenário, as linguagens Assembly foram consideradas "baixo nivel", porque seus comandos descrevem código nativo de máquina, numa relação um-para-um, portanto estamos na camada mais baixa possível de interação com o hardware.  As linguagens compiladas foram, como um todo, consideradas de "alto nivel", pois seus comandos são compilados para código de máquina numa relação um-para-N, e o programador não vê mais os detalhes desse código.

Mas depois as coisas começaram a se complicar.  Apareceram as linguagens não-procedurais, nas quais o programador descreve tarefas, e os compiladores se encarregam da geração de comandos.  Como chamar isso?  Altíssimo nivel?  Além disso, apareceram linguagens como o "C", hoje largamente empregado em microcontroladores.  O "C", embora compilado, conserva uma relação muito mais direta entre código fonte e código de máquina.  Ele "disfarça" muito menos o hardware, e protege muito menos o programador de seus erros de lógica - e nesse aspecto lembra bastante um Assembler.  Tanto que alguns programadores que nunca usam Assembler passaram a chamar o "C" de "baixo nivel".

De qualquer forma, eu falava de programação de microcontroladores.  E nesse tipo de programação eu nunca vi serem utilizadas linguagens não-procedurais, já que isso nos colocaria longe demais da camada de hardware, o que é inviável nesse tipo de ambiente.  Mesmo linguagens de alto nivel são poucas nesse ambiente.  Quase exclusivamente "C".  E assim voltamos ao princípio de tudo.  Num microcontrolador, Assembly é baixo nivel.  Linguagem compilada é alto nivel.  Ponto.

E agora, depois de falar tudo isso, podemos responder à pergunta.  Repetindo o que já disse em ocasiões anteriores:  Aconselho sempre meus alunos a estudar cuidadosamente cada "core" de microcontrolador que forem utilizar.  E para isso, nada melhor do que programar em Assembler.  Depois que conhecerem bem o "core", o "C" é uma boa pedida, pois vai economizar bastante em esforço e tempo de programação.

Ahhh... mas não se esqueçam de dar uma olhada no código de máquina gerado pelo compilador... até hoje não inventaram um compilador tão esperto quanto um programador, e se vocês forem bons nisso sempre poderão otimizar o código gerado!

Icarus

- papa uniform juliet lima delta, autorizada decolagem imediata!

Estendo a mão para a manete de potência... aquele movimento firme até o fim.  Ouço o motor acordando... a pressão no assento, a pista começa a correr.

Olho para o lado e ali, ao lado da pista, está uma enorme fila de pioneiros acenando para mim, cada um com um largo sorriso no rosto.  Ícaro.  Da Vinci.  Santos Dumont.  Orville Wright.  Charles Lindbergh.  Amelia Earhart.  Chuck Yeager.  E tantos outros que não consigo mais reconhece-los.

A máquina parece mais ansiosa do que eu para deixar o solo.  Nem preciso puxar, ela sai do chão, o nariz levanta... somos livres!  Livres como todos esses pioneiros sonharam um dia.

Curvo para a proa desejada, e o céu gira ao meu redor.  A majestade do dia começando.  O sol mal nasceu, o horizonte está em fogo.  Uns poucos cirrus, bem lá no alto, tingem o céu de vermelho.

Ao meu lado, minha melhor amiga e companheira de viagem (esta e aquela maior, a Vida) sorri em silêncio.  Ela sente, como eu, a reverência a este ambiente celeste.

A máquina sobe como se quisesse alcançar o Sol, e como Ícaro derreter suas asas de cera.  Tenho que segurar seu ímpeto e estabilizar no nivel correto.

O motor caiu para um ronronar suave.  Parece satisfeito, contente de estar aqui.  O ar frio, o céu limpo, a visão do mundo passando abaixo de nós.  Não me parece estranho que em tantas culturas diferentes o céu seja o lugar dos deuses.  Nossa recompensa após a vida.

Relaxo curtindo o vôo.  Só quem voa conhece aquele relaxamento atento (parece incoerente, não?).  Você está relaxado, curtindo a vista e a sensação do vôo.  Mas qualquer grau de diferença na proa já é corrigido antes que você tenha consciência do que fez.  Qualquer diferença de meio tom no ronronar do motor e você corrige a manete sem nem notar.  Os olhos, curtindo toda a paisagem, ainda assim capturam qualquer variação anormal no painel.

E ainda tem gente que tem medo de voar... medo do paraíso???

- controle Rio, papa uniform juliet lima delta ingressando na terminal conforme plano
- juliet lima delta, mantenha corredor visual a dois mil pés
- ciente, manterá dois mil pés, lima delta
. . .
- juliet lima delta, chame torre sierra bravo juliet romeu em uno uno oito decimal quatro zero
- ciente, uno uno oito decimal quatro zero, obrigado e bom dia, lima delta livrando frequência
- torre sierra bravo juliet romeu, aqui papa uniform juliet lima delta ingressando no circuito
- juliet lima delta, pista em uso dois zero, autorizado o pouso
- ciente, pista dois zero para pouso, lima delta

A alegria do breve reencontro com os amigos se mistura com a tristeza do fim do vôo.  Deixar o céu.  Voltar ao mundo dos que não têm asas.

Tocamos o solo, o controle solo nos orienta, taxiamos para o pátio.

Ao fundo, junto ao terminal, os amigos nos acenam, alegres.

Junto a eles, vejo novamente os largos sorrisos.  Ícaro.  Da Vinci.  Santos Dumont.  Orville Wright...

Obrigado a essa longa fila de pioneiros que tornaram tudo isso possível.