Nos últimos dias 24 e 25 de março aconteceu em São Paulo o II Workshop Projetando Sistemas Embarcados com Jack Ganssle. E foram 13 horas de muita “sabedoria embarcada Jackiniana”!

Jack é uma figura simpática, simples e que sabe passar muito bem sua experiência de mais 40 anos na área. Sua palestra abrangeu temas tão variados quanto gestão de projetos de software, melhoria de processos de desenvolvimento, uso de ferramentas, engenharia de hardware e muita, mas muita escovação de bits.

E como sua palestra fluía de um tema a outro de forma constante mas ao mesmo tempo imperceptível, ele conseguiu prender nossa atenção durante todo o seminário, e quase não vimos o tempo passar!

ONDE ESTAMOS E PARA ONDE VAMOS

Uma boa discussão sobre a evolução das CPUs deu início ao seminário, destacando a crescente capacidade de processamento e CPU’s cada vez menores e mais acessíveis (hoje você consegue um ARM a “míseros” $0.65). Jack nos alertou para um dos fatores limitantes da evolução das CPU’s: o consumo. A Intel esperava chegar a 20GHz em 2010, mas não conseguiu por causa deste “pequeno” problema. E o consumo é ainda mais importante em sistemas embarcados, já que alguns equipamentos precisam rodar por anos apenas com uma pequena bateria.

Um dos pontos altos da palestra foi a apresentação de um vídeo onde um repórter saiu às ruas perguntando às pessoas se elas sabiam o que eram sistemas embarcados. Este vídeo rendeu boas risadas. Quem trabalha nesta área e já não teve dificuldades em explicar para família ou amigos o que faz da vida? :)

Diversas pesquisas foram mostradas indicando um problema com a qualidade dos produtos que desenvolvemos, o que resulta numa alta taxa de bugs, seja por prazos curtos ou problemas com ferramentas de desenvolvimento ou debuggers. E depois de vários exemplos ficou a constatação de que o firmware é a coisa mais cara do universo!

GESTÃO DE PROJETOS

“Bugs são a principal causa de projetos atrasados!”. Jack não cansou de dizer isso. Assim como as pessoas não casaram de dizer: “Como eu queria que meu chefe estivesse aqui!”, apesar de muitos ali serem chefes. E tenho certeza que o chefe do chefe diria a mesma coisa! O problema é que só existe um chefe: o cliente!

A melhor forma de acabar com os bugs é evitá-los em primeiro lugar. Mas estamos sempre envolvidos com o dilema: “Não liberar o produto no prazo, ou liberar no prazo, mas com bugs”. É como se estivéssemos “correndo atrás do próprio rabo”.

Então Jack nos apresentou técnicas de gestão de projetos e o uso de ferramentas para aumentar a produtividade e a qualidade, como manter um ambiente produtivo e pessoas motivadas (regado a muitas tirinhas engraçadas de Dilbert), como estimar projetos de software e trabalhar com tradeoffs de prazo, qualidade e funcionalidade; além de apresentar modelos e práticas de desenvolvimento como o CMMI, PSP e XP.

PROJETO E ARQUITETURA

O lema aqui é “Dividir para conquistar”. Devemos dividir o projeto em pequenos blocos e decidir o que terceirizar e o que desenvolver em casa, o que será resolvido com hardware e o que será desenvolvido com software.

Qual linguagem de programação usar foi outro tema interessante. A grande parte dos projetos ainda é desenvolvida em C. Mas o uso de C++ cresceu nos últimos anos, apesar de pesquisas mostrarem que poucos usam conceitos como herança ou polimorfismo. Então qual a grande vantagem? Reuso de código? Encapsulamento? Um código bem projetado em C consegue isso também. De qualquer forma, na prática, o que vemos é que as duas linguagens tem seu nicho de mercado, e que na maioria das vezes o design é mais importante que a linguagem usada.

Uma pesquisa sobre o uso de RTOS nos mostrou que muitas empresas sequer usam um sistema operacional, e que outras tantas resolvem desenvolver seu próprio SO, o que contribui para elevar a taxa de bugs, além de atrasar os projetos de software embarcado.

Jack deixou claro também a dificuldade para reusar código. Tudo deve começar com uma mudança de paradigma dos membros da equipe para incentivar o reuso e a criação de código sem dependências entre si, essenciais para termos uma base de código que possa ser reutilizável.

MALDITOS INSETOS

O fato é que passamos metade do tempo do projeto debugando o código, então foram apresentadas técnicas de debugging com BDM e JTAG.

Mas ficou claro que precisamos resolver o problema na origem, então o Jack nos apresentou a melhor ferramenta para evitar bugs: inspeção de código! Todo código desenvolvido deve ser inspecionado por outra pessoa. E concordo plenamente com esta técnica. Duas ou mais cabeças sempre pensam melhor do que uma.

Além disso, ele nos deu outras dicas para evitar bugs no código, dentre elas:

1. Corrija o problema quando identificado, não deixe para depois!
2. Não ignore warnings: se o compilador esta com medo, você também deveria estar!
3. Use um padrão de codificação e/ou um padrão de software como o MISRA-C.
4. Evite variáveis globais.
5. Use analisadores estáticos de código como o PC-LINT ou o Splint.

ESCOVANDO BITS

Um prato cheio para os escovadores de bits: como trabalhar com interrupções e desenvolver uma rotina de tratamento de interrupção, como entender o código gerado a partir de um código em C (uma linha de código em C pode gerar 3 instruções em uma arquitetura, mas pode gerar 15 instruções em outra arquitetura!), dicas sobre matemática de ponto fixo e ponto flutuante, como usar o hardware para debugar o sistema, diversas dicas em C (ajustar tamanho estruturas em potência de 2, declarar funções pequenas inline, preferir int ao invés de short e char, etc), os cuidados ao compartilhar variáveis entre tarefas, e por aí vai.

Uma atenção especial foi dada ao uso do heap para alocação dinâmica de memória, o uso inteligente do watchdog, testes de memória e técnicas de debouncing.

LIVROS

Durante a apresentação, Jack recomendou diversos livros, dentre eles:

1. Confessions of a Used Program Salesman – Will Tracz
2. An Embedded Software Primer – David E. Simon
3. High Speed Digital Design – Howard Johnson and Martin Graham
4. Best Kept Secrets of Peer Code Review (www.smartbearsoftware.com)
5. Test Driven Development for Embedded C – James W. Grenning
6. Peopleware – Tom DeMarco and Timothy Lister
   

A PROGRAMMER’S DRINKING SONG

E para terminar, deixo aqui uma canção que expressa a infeliz realidade do desenvolvimento de projetos de software:

100 little bugs in the code,
100 bugs in the code,
 
Fix one bug, compile it again,
101 little bugs in the code.
 
101 little bugs in the code...
 
(Repeat until BUGS == 0)

Valeu Jack! Agora, que venha o ESC Brazil 2011!

Um abraço,

Sergio Prado