Olá visitante!
No final do mês de Junho aconteceu o Seminário de Sistemas Embarcados e IoT, organizado pela galera top do Embarcados!
O evento aconteceu nos dias 27 e 28 de Junho. Foi um fim de semana muito legal, aprendi muito com as outras palestras, conheci muitas pessoas e tive a oportunidade de palestrar e de falar um pouco de como eu estruturo os firmwares que eu trabalho!
A palestra foi gravada pelo pessoal do Embarcados e ainda está disponível! Não assistiu ainda?
Sobre o que você falou, Andre?
A minha palestra foi um resumo de como é importante fazer a estruturação do seu software embarcado e expliquei o conceito de duas grandes arquiteturas, a Inter e a Intra. Cada uma dá propriedades muito importantes para o software e, juntas, permitem que ele seja flexível, robusto, escalável e testável.
Eu fiquei muito surpreso de como foi a resposta do pessoal que assistiu! A conversa foi bem animada durante o chat do vídeo e muitas perguntas foram feitas, não somente lá, mas também depois, nos outros dias!
Desta forma, eu acho que vale a pena pegar algumas delas e comentar um pouco neste post. Vamos lá!
Como seriam tratadas as especificidades de cada hardware? Por exemplo, tenho uma aplicação em PIC24 e quero portar para um MSP430, ambos micros de 16 bits, mas de fabricantes diferentes…
As especificidades seriam tratadas com implementações específicas, que atendem um mesmo cabeçalho público. Este cabeçalho é genérico e todos os outros módulos do produto dependem só dele e não das implementações per si.
Por exemplo, digamos que você quer fazer um driver de SPI. Como o SPI funciona em um PIC24 é diferente de como é em um MSP430. Assim, você precisará implementar código para funcionar em um e também implementar outro código para operar no outro. Quando o projeto compilar para um dos micros você compila a implementação dele necessária.
Mas as duas implementações devem ter as rotinas presentes no cabeçalho público e atender elas corretamente. Assim, se o micro for trocado apenas o driver é trocado. Todo o resto do seu produto será o mesmo.
Todos os módulos do meu software embarcado precisam ser estruturados na arquitetura Intra?
Bem… não. O ideal é que a maioria deles seja, mas em algumas situações é interessante seguir outros formatos:
- O módulo é muito simples: Se o módulo é muito simples (como um driver de GPIO, por exemplo) então pode não valer a pena fazer toda aquela estruturação e adicionar tantos complicadores.
- O módulo é auxiliar: Alguns módulos serão apenas um conjunto de rotinas que outros módulos vão utilizar. Por exemplo, é interessante concentrar funções como CRCs e criptografias em um local central, em um módulo auxiliar. Sendo assim, é melhor deixar essas rotinas mais simples possível.
- Bibliotecas de terceiros: Quando for utilizar implementações de terceiros o ideal é deixar a implementação como está e apenas adicionar a lógica necessária para encapsular essa biblioteca na sua plataforma.
Claro, seguindo ou não a arquitetura Intra, o seu módulo deve atender o cabeçalho público. Também, é muito importante lembrar que nos casos acima as suas implementações ficam vulneráveis à problemas de concorrência (como expliquei na palestra). Assim… muito cuidado!
Andre, com essas arquiteturas podemos abstrair nossas lógicas e prover uma implementação pro PC que usa um “mock”, certo? O que voce usa para teste?
Certo! A arquitetura Intra é feita pensando em deixar o seu módulo testável, separando a lógica em submódulos e dando pontos de acesso (cabeçalhos) para a sua ferramenta de testes unitários!
Para os testes, eu gosto de usar o Ceedling, que é um build system que utiliza do Unity, CMock, FFF para fazer os testes unitários.
Já ouviu falar do Projeto Zephyr? O que acha dele?
Eu confesso que não tinha ouvido falar deste projeto e foi só durante o seminário que fui tomar conhecimento dele!
Fui dar uma estudada e parece ser um projeto muito legal, é algo que está crescendo muito rápido, open source e, o mais importante, tem muitas pessoas trabalhando nele. Então, usando ele, você pode ter muita coisa pronta, desenvolvida, “fácil”. Ele parece ser promissor e certamente irei estudá-lo mais a fundo.
Apesar de tudo isso, é importante entender que o projeto Zephyr é uma plataforma de desenvolvimento e por mais que ele entregue muita coisa pronta, as regras de negócio do seu produto ainda serão você e sua equipe que irão desenvolver.
Vocês precisarão desenvolver módulos e aplicações customizados para as suas necessidades e, se eles não estiverem bem estruturados e desenvolvidos, vocês continuarão com os mesmos problemas que descrevi na apresentação. Então, com ou sem Zephyr, é importante que vocês se preocupem em fazer um bom design de seus módulos. Os conceitos que estou apresentando são validos em todos os projetos, com ou sem Zephyr.
Você teria algum material para indicar sobre como evitar o uso de variáveis globais?
Durante a palestra falei sobre concorrência e como que, em particular, as variáveis globais podem ser prejudicadas com esse problema. Assim, posso ter erroneamente passado a impressão de que elas são “ruins”.
Variáveis globais são perigosas em ambientes com concorrência porque nessas situações seus dados podem ser modificados por outras partes antes que seu código principal termine de usá-las. Assim, nesses lugares seu uso é desencorajado.
Mas em ambientes sem concorrência – que são aqueles que a arquitetura Intra oferece – usar essas variáveis é seguro e o seu código assim pode ser mais simples!
As empresas que ainda não desenvolvem assim, se quiserem mudar, vão precisar começar do zero?
Claro que não! É possível fazer um trabalho para gradualmente portar tudo que foi feito para esta estrutura, mas preciso deixar claro que não é fácil. É preciso planejamento e utilizar de ferramentas como testes unitários para ir realizando todas as modificações, uma a uma.
O mais importante aqui é que trabalhar desta maneira é uma mudança cultural muito grande e a empresa (e a equipe) precisa estar disposta a passar por algumas ‘turbulências’!
Andre, eu tenho uma dúvida!
A apresentação e os comentários que fiz acima são apenas uma introdução, um apanhado geral dessa matéria, que quero falar mais no futuro.
Tem alguma dúvida? Ótimo! Por gentileza, entre em contato comigo, ficarei feliz em te ajudar com elas! Utilize o formulário de contato, envie um email ou me procure no LinkedIn!
Obrigado visitante e até a próxima!
Uma visita satisfatoria, superou minhas expectativas, voltarei
em breve..! Bom Trabalho..!
Não é possível comentar.