Posts com Tag ‘linguagem’

Caro(a) Colega,

a minha experiência profissional é baseada no desenvolvimento de software básico (firmware) para microprocessadores, microcontroladores de 8 ou 16 bits e DSPs (Digital Signal Processors). Qual o sistema operacional que costumo utilizar? Nenhum desses tradicionais. Na verdade, em geral desenvolvo os sistemas para os meus projetos. Para os tipos de processadores citados dificilmente tem algum sistema operacional que seja enxuto e eficiente.  Afinal, processadores de 8 ou 16  bits são relativamente lentos, possuem pouca memória interna, mas têm grandes vantagens, dependendo da aplicação em que são utilizados: são simples, baratos, diminutos no seu tamanho físico e extremamente eficientes para pequenas aplicações. Tem algumas versões de microcontroladores PIC, por exemplo,  com encapsulamento de 8 pinos.

Retornando ao assunto do sistema operacional, no meu caso, de certa forma, um loop infinito é um sistema operacional de alta eficiência se associado a outros recursos dos processadores, tais como temporizações e interrupções por hardware. É uma maneira de se unir as vantagens citadas dos microcontroladores e conseguir um desempenho em tempo real adequado para algumas aplicações.

Quando se fala de software de tempo real, deve-se lembrar que isso não implica na necessidade de se realizar as tarefas no menor tempo possível, mas sim em que a velocidade de processamento, monitoramento e controle do seu projeto deve ser suficientemente veloz  e compatível com a velocidade de resposta do sistema para o qual ele foi projetado. Existem processos, principalmente os térmicos,  que levam horas ou até dias para progredirem ou mudarem de estado. Neste caso, não é necessário que o processador execute todo o seu programa em frações de segundos. Poderia até levar horas para isso, pois não afetaria o desempenho do sistema como um todo e ainda assim seria um sistema de tempo real.

Para poder ilustrar o que foi dito até aqui com um resultado prático e real do uso dessas boas práticas, vou apresentar rapidamente algumas características de um projeto que desenvolvi. Trata-se de um equipamento que faz uma varredura periódica em até 32 detectores de vazamento de combustíveis e cuja principal função é a proteção ambiental na medida em que previne a contaminação do solo de postos de combustíveis.

Algumas características do equipamento:

  • Permite a  reconfiguração sempre que necessário;
  • É capaz de detectar curto-circuitos ou rompimento dos cabos dos sensores;
  • Sinaliza a varredura por meio de LEDs;
  • Sinaliza falhas por meio de códigos apresentados em displays de 7 segmentos;
  • Gera um registro em memória não volátil a cada evento anormal, gravando a data e hora dessa ocorrência e a data/hora de quando o a ocorrência foi solucionada;
  • Quando solicitado, gera um relatório formatado para uma  impressora;
  • Gerencia um teclado;
  • Gerencia um relógio de tempo real;
  • Conecta-se em rede a um computador ou à internet para permitir um monitoramento remoto.

Tudo isso  e algumas coisinhas a mais, sendo executado num microcontrolador de 8 bits da família MCS-51, com clock de 4 MHz, 12 kBytes de memória EEPROM, 256 Bytes de RAM e  que custa em torno de R$ 20,00 no varejo.

O software foi todo escrito em C. Seu código fonte tem em torno de 8.000 linhas de programa.  É incrível? Mágica? Nem tanto…

Vale ressaltar que até hoje, 10 anos depois da primeira versão, tive que realizar apenas uma pequena correção no software e alterações decorrentes do upgrade do microprocessador para versões mais atualizadas.

Mas voltemos ao tema. Essas práticas funcionam muito bem se aplicadas a microcontroladores.  Pode ser que não sirva para você, se acaso você trabalha com um software de alto nível, Visual C por exemplo. Desenvolvo meus projetos de software na forma estruturada, aplicando práticas de encapsulamento de entradas e saídas, essas típicas de software orientado a objetos.

O que é um software estruturado?

Para quem não conhece, discorrendo resumidamente sobre o assunto, um software estruturado é organizado em blocos, o fluxo é muito bem definido e tem regras rígidas  para a recursão. Em princípio cada bloco tem uma entrada e uma saída e não se utiliza o recurso do “GOTO” em hipótese alguma, pois ele destrói e corrompe qualquer organização que se tenha realizado no software. A linguagem C, por exemplo, é na sua essência uma linguagem computacional com características de software estruturado. Difícil, não é? A seguir vou explicar e fundamentar porque se deve dar preferência à programação estruturada no caso de microcontroladores e alguns DSPs.

Representação gráfica de um programa estruturado.

Fonte: DEVMEDIA

Porque não usar programação orientada a objeto?

O principal motivo para não usar programação orientada a objeto é o tamanho do código gerado. Outro motivo é o fato de se  perder um pouco o controle de como o código é gerado e de como a memória é utilizada. Isso complica muito quando é necessário otimizar o código principalmente quando a velocidade de processamento é crítica. Quando se utiliza a linguagem C, depois de algum tempo você aprende a escrever seu código de forma a favorecer a sua otimização. Na hora do aperto, dá até para inserir inline pequenos trechos de código em Assembly (Não é recomendado, mas às vezes não há alternativa…).  Isso te dá o controle quase total sobre o que vai ser gerado no final, o quanto de memória vai ser utilizado, como vai ser utilizada essa memória, etc.

Reconheço as qualidades do software orientado a objetos, tais como a portabilidade, velocidade de desenvolvimento de código e, facilidade de manutenção , até porque aproveitei o encapsulamento de dados, típico de programação orientada a objetos,  para melhorar o software estruturado. Apenas afirmo que para o uso em microprocessadores de 8 e 16 bits, frequentemente não é a melhor alternativa. Acredito também, que com o avanço das tecnologias dos compiladores de linguagens orientadas a objeto, pode ser apenas uma questão de tempo para que esses compiladores se tornem mais eficientes e produzam resultados melhores que os compiladores de linguagens estruturadas.

O que é encapsulamento de entradas e saídas?

É um método  de organização do software que determina regras rígidas para o acesso aos parâmetros ou recursos de um determinado periférico. O acesso tem que ser realizado sempre por meio de um mesmo conjunto de rotinas. Por exemplo: suponhamos que você tenha previsto a utilização de um canal de comunicação serial no seu projeto e que haja a necessidade de se utilizar uma rotina para transmitir dados e outra para receber dados. Se o canal de comunicação for organizado de forma encapsulada, qualquer acesso ao canal serial deverá obrigatoriamente se dar por meio dessas mesmas rotinas de qualquer ponto do seu programa. Assemelha-se muito ao conceito de objeto e métodos associados, conforme definido na programação orientada a objetos, não é mesmo? A diferença é que esse objeto e os métodos associados não são genéricos, mas feitos sob medida para essa aplicação. Por isso que ela tem todas as vantagens decorrentes dessa forma de organização aliada às vantagens de ser específica: enxuta, veloz entre outras.

Vale ressaltar que a aplicação desse método a um programa estruturado deve ser realizada por iniciativa e disciplina do desenvolvedor, uma vez que os compiladores de linguagens estruturadas não oferecem ferramentas ou facilidades para fazê-lo.

Qual a vantagem dessa forma de organização?

Uma vez depuradas as rotinas que administram o seu periférico, você não precisa mais se preocupar com elas ou com o funcionamento dele. Se acaso for detectada alguma falha nesse conjunto, você corrige essas rotinas e todo o seu programa volta a funcionar corretamente.

Para ilustrar o que foi dito até aqui, no final desse artigo, disponibilizei o código de duas rotinas que escrevi para acessar uma E2PROM serial. Essas rotinas têm outros elementos recomendados de boas práticas, que discutiremos nos próximos artigos.

Talvez o jovem profissional, já habituado a utilizar ferramentas de produção de software orientadas a objeto ou de alto nível, não perceba a diferença. Isso porque as ferramentas orientadas a objeto já encapsulam os dados naturalmente. É que é muito comum o programador de software básico ou firmware, por pressa ou preguiça, não organizar o programa desse jeito e acessar diretamente o seu periférico de diversos pontos do seu programa.  É uma grande tentação fazer isso e confesso, que se o programa é pequeno, talvez até seja uma solução rápida. Quando funciona bem, que maravilha!!!!! Mas quando dá “pau” …. É um inferno!!! Fica quase impossível encontrar o problema no código e evitar que a correção do problema eventualmente mal planejada se propague de forma negativa e gere  outros defeitos imprevistos em outras partes do código.

Nos próximos artigos são abordadas algumas sugestões de como proceder para dar nomes a rotinas, variáveis e constantes de forma a aumentar a sua eficiência na produção e manutenção do seu software. Vou comentar um pouco sobre a notação húngara. Parece grego?

Também é apresentada uma ferramenta de produtividade pouco conhecida, que porém, para mim, foi um divisor de águas. Não sei como eu conseguia programar antes de utilizar essa ferramenta. Minha velocidade de produção multiplicou-se.

Confira:

Abraço!

Henrique

consulte sempre um engenheiro eletrônico

 

Licença Creative Commons
Esta obra, “Boas práticas para o desenvolvimento de software – Algumas ideias de como organizar o seu software – I“, de Henrique Frank W. Puhlmann, foi licenciada sob uma Licença Creative Commons Atribuição-NãoComercial-CompartilhaIgual 3.0 Não Adaptada.

=================================================================================================

Rotina para escrever na E2PROM:

Rotina em C para escrita na E2PROM

Rotina em C para escrita na E2PROM – Parte 1

Rotina em C para escrita na E2PROM - segunda parte

Rotina em C para escrita na E2PROM – Parte 2

=============================================================================

Rotina para Leitura da E2PROM

Rotina em C para leitura de uma E2PROM - parte 1

Rotina em C para leitura de uma E2PROM – parte 1
Rotina em C para leitura de uma E2PROM - parte 2

Rotina em C para leitura de uma E2PROM – Parte 2

Rotina em C para leitura de uma E2PROM - parte 3

Rotina em C para leitura de uma E2PROM – Parte 3

Caros amigos e colegas!

Este artigo relata um pouco da minha experiência pessoal com desenvolvimento de software, predominantemente de firmware embarcado. Como muitos profissionais de minha geração, iniciei o meu aprendizado de programação preenchendo planilhas em papel para a posterior geração de cartões perfurados no padrão da IBM.  As correções e alterações do programa eu fazia perfurando manualmente novos cartões. A linguagem de programação era o FORTRAN IV e o programa era executado num computador de grande porte (Um Burroughs, se não me engano).

Cartão perfurado padrão IBM

Cartão perfurado no padrão da IBM, contendo uma linha de programa em FORTRAN IV

Mais tarde passei a programar calculadoras científicas, depois surgiram os primeiros microcomputadores pessoais, com programação em BASIC, em seguida passei a programar microcontroladores e microprocessadores em linguagem Assembly. Um montador de linguagem Assembly ou simplesmente um Assembler, era o máximo do luxo que podíamos ter. Em geral o código era convertido manualmente consultando-se a tabela de mnemônicos do microprocessador, traduzindo esse código e transferindo-o para o processador com auxílio de um equipamento programador apropriado. Era muito sofrido (apesar de divertido também).

Intellec MDS-80

Foto: Digibarn Computer Museum

Enquanto trabalhava no desenvolvimento de um SDCD (sistema digital de controle distribuído) tive meu primeiro contato com uma linguagem de alto nível para desenvolvimento de software para microprocessadores. O fantástico PL/M (Programming Language for Microcomputers) da Intel, rodado num sistema denominado MDS 80 (Microcomputer Development System for 8080) que utilizava discos flexíveis de 8 polegadas. Era pouco eficiente na geração de código, mas acelerava muito a produção do programa e facilitava a sua manutenção.

Depois de algum tempo, começaram a aparecer os  Apples, PCs, Microsoft, Compiladores C com interfaces amigáveis para geração e depuração de software para processadores, apareceram até os primeiros simuladores! (Um verdadeiro paraíso para um desenvolvedor). Quem entra na profissão nos dias de hoje, não imagina a sorte que tem! Atualmente um compilador C gera um código de máquina melhor do que muitos programadores experientes em assembly poderiam gerar. Só se programa em assembly no caso de extrema necessidade de otimização de código. (Ainda bem!!!)

8051

Exemplo de uma programa de desenvolvimento para o microcontrolador  8051 com simulador

Agora falando de boas práticas… Dificilmente pode-se falar em unanimidade quando o assunto é boas práticas. O que vou abordar aqui são as práticas que tive a sorte de conhecer e algumas eu mesmo desenvolvi. Para mim funcionaram muito bem! Talvez também sejam boas para você!

Eu sou, por natureza, organizado ao extremo com relação aos meus trabalhos profissionais. Quase sempre trabalhei em projetos de longo prazo e frequentemente com uma equipe reduzida. Há alguns anos trabalho praticamente só e por isso que eu acho que muitos dos meus colegas que trabalham por conta, ou são freelancers, podem tirar um bom proveito dessa minha experiência. Para profissionais como nós é essencial ter produtividade, mas também é necessário e essencial gastar algum tempo com um bom preparo, conforme já abordado no artigo “Projetos de Desenvolvimento: antes de começar – (Parte I)”. Deve-se investir também um pouco mais de tempo para aplicar algumas das boas práticas ao seu software, de forma que ele saia “redondo” e no final não se tenha que gastar muito tempo para fazer a manutenção dele e eventualmente “queimar” o seu bom nome como profissional Mais vale você investir algum tempo no desenvolvimento de um software de qualidade do que gastar um tempo longo na manutenção e reparo desse mesmo software.

Nos próximos artigos vou descrever as práticas propriamente ditas e apresentar algumas ferramentas de produtividade muito interessantes. Confira:

Se você tiver sugestões e críticas, por favor faça-as que serão muito bem vindas.

 Abraço!

Henrique

consulte sempre um engenheiro eletrônico

Licença Creative Commons
Esta obra, “Boas práticas para o desenvolvimento de software – Introdução“, de Henrique Frank W. Puhlmann, foi licenciada sob uma Licença Creative Commons Atribuição-NãoComercial-CompartilhaIgual 3.0 Não Adaptada.