Nos últi­mos dias 24 e 25 de março acon­te­ceu em São Paulo o II Work­shop Pro­je­tando Sis­temas Embar­ca­dos com Jack Ganssle. E foram 13 horas de muita “sabedo­ria embar­cada Jackiniana”!

Jack é uma figura sim­pática, sim­ples e que sabe pas­sar muito bem sua exper­iên­cia de mais 40 anos na área. Sua palestra abrangeu temas tão vari­a­dos quanto gestão de pro­je­tos de soft­ware, mel­ho­ria de proces­sos de desen­volvi­mento, uso de fer­ra­men­tas, engen­haria de hard­ware e muita, mas muita esco­v­ação de bits.

E como sua palestra fluía de um tema a outro de forma con­stante mas ao mesmo tempo imper­cep­tível, ele con­seguiu pren­der nossa atenção durante todo o sem­i­nário, e quase não vimos o tempo passar!

ONDE ESTAMOS E PARA ONDE VAMOS

Uma boa dis­cussão sobre a evolução das CPUs deu iní­cio ao sem­i­nário, desta­cando a cres­cente capaci­dade de proces­sa­mento e CPU’s cada vez menores e mais acessíveis (hoje você con­segue um ARM a “míseros” $0.65). Jack nos aler­tou para um dos fatores lim­i­tantes da evolução das CPU’s: o con­sumo. A Intel esper­ava chegar a 20GHz em 2010, mas não con­seguiu por causa deste “pequeno” prob­lema. E o con­sumo é ainda mais impor­tante em sis­temas embar­ca­dos, já que alguns equipa­men­tos pre­cisam rodar por anos ape­nas com uma pequena bateria.

Um dos pon­tos altos da palestra foi a apre­sen­tação de um vídeo onde um repórter saiu às ruas per­gun­tando às pes­soas se elas sabiam o que eram sis­temas embar­ca­dos. Este vídeo ren­deu boas risadas. Quem tra­balha nesta área e já não teve difi­cul­dades em explicar para família ou ami­gos o que faz da vida? :)

Diver­sas pesquisas foram mostradas indi­cando um prob­lema com a qual­i­dade dos pro­du­tos que desen­volve­mos, o que resulta numa alta taxa de bugs, seja por pra­zos cur­tos ou prob­le­mas com fer­ra­men­tas de desen­volvi­mento ou debug­gers. E depois de vários exem­p­los ficou a con­statação de que o firmware é a coisa mais cara do universo!

GESTÃO DE PROJETOS

“Bugs são a prin­ci­pal causa de pro­je­tos atrasa­dos!”. Jack não can­sou de dizer isso. Assim como as pes­soas não casaram de dizer: “Como eu que­ria que meu chefe estivesse aqui!”, ape­sar de muitos ali serem chefes. E tenho certeza que o chefe do chefe diria a mesma coisa! O prob­lema é que só existe um chefe: o cliente!

A mel­hor forma de acabar com os bugs é evitá-los em primeiro lugar. Mas esta­mos sem­pre envolvi­dos com o dilema: “Não lib­erar o pro­duto no prazo, ou lib­erar no prazo, mas com bugs”. É como se estivésse­mos “cor­rendo atrás do próprio rabo”.

Então Jack nos apre­sen­tou téc­ni­cas de gestão de pro­je­tos e o uso de fer­ra­men­tas para aumen­tar a pro­du­tivi­dade e a qual­i­dade, como man­ter um ambi­ente pro­du­tivo e pes­soas moti­vadas (regado a muitas tir­in­has engraçadas de Dil­bert), como esti­mar pro­je­tos de soft­ware e tra­bal­har com trade­offs de prazo, qual­i­dade e fun­cional­i­dade; além de apre­sen­tar mod­e­los e práti­cas de desen­volvi­mento como o CMMI, PSP e XP.

PROJETO E ARQUITETURA

O lema aqui é “Dividir para con­quis­tar”. Deve­mos dividir o pro­jeto em pequenos blo­cos e decidir o que ter­ce­i­rizar e o que desen­volver em casa, o que será resolvido com hard­ware e o que será desen­volvido com software.

Qual lin­guagem de pro­gra­mação usar foi outro tema inter­es­sante. A grande parte dos pro­je­tos ainda é desen­volvida em C. Mas o uso de C++ cresceu nos últi­mos anos, ape­sar de pesquisas mostrarem que poucos usam con­ceitos como her­ança ou polimor­fismo. Então qual a grande van­tagem? Reuso de código? Encap­su­la­mento? Um código bem pro­je­tado em C con­segue isso tam­bém. De qual­quer forma, na prática, o que vemos é que as duas lin­gua­gens tem seu nicho de mer­cado, e que na maio­ria das vezes o design é mais impor­tante que a lin­guagem usada.

Uma pesquisa sobre o uso de RTOS nos mostrou que muitas empre­sas sequer usam um sis­tema opera­cional, e que out­ras tan­tas resolvem desen­volver seu próprio SO, o que con­tribui para ele­var a taxa de bugs, além de atrasar os pro­je­tos de soft­ware embarcado.

Jack deixou claro tam­bém a difi­cul­dade para reusar código. Tudo deve começar com uma mudança de par­a­digma dos mem­bros da equipe para incen­ti­var o reuso e a cri­ação de código sem dependên­cias entre si, essen­ci­ais para ter­mos uma base de código que possa ser reutilizável.

MALDITOS INSETOS

O fato é que pas­samos metade do tempo do pro­jeto debugando o código, então foram apre­sen­tadas téc­ni­cas de debug­ging com BDM e JTAG.

Mas ficou claro que pre­cisamos resolver o prob­lema na origem, então o Jack nos apre­sen­tou a mel­hor fer­ra­menta para evi­tar bugs: inspeção de código! Todo código desen­volvido deve ser inspe­cionado por outra pes­soa. E con­cordo ple­na­mente com esta téc­nica. Duas ou mais cabeças sem­pre pen­sam mel­hor do que uma.

Além disso, ele nos deu out­ras dicas para evi­tar bugs no código, den­tre elas:

1. Cor­rija o prob­lema quando iden­ti­fi­cado, não deixe para depois!
2. Não ignore warn­ings: se o com­pi­lador esta com medo, você tam­bém dev­e­ria estar!
3. Use um padrão de cod­i­fi­cação e/ou um padrão de soft­ware como o MISRA-C.
4. Evite var­iáveis globais.
5. Use anal­isadores estáti­cos de código como o PC-LINT ou o Splint.

ESCOVANDO BITS

Um prato cheio para os esco­v­adores de bits: como tra­bal­har com inter­rupções e desen­volver uma rotina de trata­mento de inter­rupção, como enten­der o código ger­ado a par­tir de um código em C (uma linha de código em C pode gerar 3 instruções em uma arquite­tura, mas pode gerar 15 instruções em outra arquite­tura!), dicas sobre matemática de ponto fixo e ponto flu­tu­ante, como usar o hard­ware para debugar o sis­tema, diver­sas dicas em C (ajus­tar tamanho estru­turas em potên­cia de 2, declarar funções peque­nas inline, preferir int ao invés de short e char, etc), os cuida­dos ao com­par­til­har var­iáveis entre tare­fas, e por aí vai.

Uma atenção espe­cial foi dada ao uso do heap para alo­cação dinâmica de memória, o uso inteligente do watch­dog, testes de memória e téc­ni­cas de debouncing.

LIVROS

Durante a apre­sen­tação, Jack recomen­dou diver­sos livros, den­tre eles:

1. Con­fes­sions of a Used Pro­gram Sales­man — Will Tracz
2. An Embed­ded Soft­ware Primer — David E. Simon
3. High Speed Dig­i­tal Design — Howard John­son and Mar­tin Graham
4. Best Kept Secrets of Peer Code Review (www.smartbearsoftware.com)
5. Test Dri­ven Devel­op­ment for Embed­ded C — James W. Grenning
6. Peo­ple­ware — Tom DeMarco and Tim­o­thy Lis­ter
   

A PROGRAMMER’S DRINKING SONG

E para ter­mi­nar, deixo aqui uma canção que expressa a infe­liz real­i­dade do desen­volvi­mento de pro­je­tos 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!

Ser­gio Prado e Jack Ganssle — 25/03/2011

Um abraço,

Ser­gio Prado

Sem posts relacionados.