Começando um novo projeto!
Olá pessoal!
Estou de volta, já se passou um tempo desde o seminário de Sistemas Embarcados e IoT, que aconteceu no final de Julho! Neste evento eu apresentei uma introdução sobre a estruturação de softwares embarcados em linguagem C, tanto operando com RTOS quanto com baremetal. O feedback que recebi de vocês foi sensacional, eu fiquei muito feliz com o resultado do evento e um dos pontos que combinei com vocês era de que eu ia trazer um exemplo de tudo o que eu falei.
Sem mais delongas, vamos começar um projeto de exemplo para o design robusto de firmwares multiplataforma!
O projeto
Vou apresentar um projeto de exemplo para mostrar o que expliquei sobre arquiteturas Inter e Intra. Esse projeto consiste em uma série de artigos e de código fonte de exemplo. Os artigos serão periodicamente publicados aqui e no meu repositório estarão todos os códigos-fonte, sendo atualizado conforme o nosso projeto avança.
Aplico os conceitos deste projeto todos os dias na minha main quest, na V2COM. Lá eu sou o coordenador do departamento de software embarcado, aonde trabalho com uma equipe show de bola no desenvolvimento de produtos conectados. Estamos empenhados para conectar o máximo de ‘coisas’ a fim de que elas sejam facilmente acessíveis pelas pessoas. Um dos nossos maiores projetos é o Conera, um pacote de software para ajudar as empresas a conectarem as suas ‘coisas’ de maneira rápida e segura.
Estes serão os nossos temas para as próximas semanas:
- Apresentação do projeto e organização do repositório (este artigo!)
- Definição das interfaces (aplicações, RTOS, drivers).
- Preparando os testes unitários e as IDEs.
- Elaboração dos drivers.
- Submódulos de interface e de sistema das aplicações.
- Submódulos de operação das aplicações e conclusão do projeto.
Ainda não assistiu a palestra? Sem problemas! Aqui está:
E aqui respondi algumas perguntas sobre ela!
A palavra de ordem neste nosso primeiro projeto é de simplicidade. Não é legal começarmos com aplicações mais elaboradas se com as mais simples já podemos aprender muitos conhecimentos importantes. Software embarcado é complicado, a sua curva de aprendizado é grande, então não faz sentido adicionarmos complicadores. Vamos por partes!
Como cereja do bolo, vamos adicionar um pouco de contexto ao nosso projeto, um ‘caso real’ fictício, um produto a ser comercializado com o nosso trabalho. Sendo assim… parabéns pelo seu novo emprego!
Meu novo... emprego?
Você foi contratado pela Brinquedos Inteligentes (BI para os mais chegados), uma startup em fase de nascimento, inovadora, revolucionária, com potencial para mudar a indústria de brinquedos para crianças pequenas. Afinal, toda startup promete isso né! Mas divago…
Sua posição é de arquiteto de software embarcado. Você será o(a) responsável por montar do zero o repositório de software embarcado dos brinquedos da BI, que serão adquiridos por milhões de famílias ao redor do planeta e vai tornar mais feliz a vida de crianças (e dos seus pais, consequentemente)! Uma grande responsabilidade, né!
No seu primeiro dia na empresa, aconteceu uma reunião com a liderança e ‘todos’ os detalhes que você precisa foram esclarecidos… só que não. As informações dadas foram escassas, a empresa alegou que os detalhes ainda estão sendo fechados para a primeira linha de produtos, mas nas próximas semanas mais informações devem chegar. Claro que você não vai ficar parado nesse meio tempo, então vamos trabalhar com o que temos!
As primeiras informações
Você saiu da reunião com as seguintes informações:
- A primeira linha de produtos será de… ursinhos de pelúcia.
- Esses ursinhos irão ‘piscar luzes’ e quando apertados essas luzes vão mudar de padrão.
- Será colocado uma plataforma embarcada microcontrolada neles para que no futuro se possa colocar funções mais complexas.
- A startup está prospectando clientes em toda a América Latina.
- Por questões comerciais, em alguns países será enviado uma versão com um microcontrolador e em outros países com um outro.
- São eles: Um da família ST STM32F103 e outro da família NXP KL25Z.
- Outros times são responsáveis pela mecânica e hardware. Nossa preocupação é ‘apenas’ do software embarcado.
Parece pouco, né? Mas essas informações são mais que suficientes para você criar o seu repositório e trabalhar na primeira versão do produto! O que já podemos concluir:
- Precisamos de um repositório escalável:
- Mais produtos estão para vir.
- As funções dos produtos vão aumentar e/ou mudar.
- Um mesmo produto vai ter diferentes plataformas (placas, microcontroladores…)
- O produto piscará luzes e, num movimento mecânico, mudar o padrão. Então podemos começar com:
- Um LED piscando,
- Um push-button e
- Quando este botão for pressionado, o período que o LED pisca é alterado.
- O hardware não está pronto ainda, então vamos trabalhar com placas de desenvolvimento disponíveis no mercado.
As nossas placas
Felizmente os microcontroladores dos ursinhos têm placas de desenvolvimento disponíveis para nós. São elas:
- Placa Blue Pill, com um STM32F103.
- Placa FRDM-KL25Z, com um KL25Z.
Estas placas de desenvolvimento já têm tudo que precisamos, com exceção dos push-buttons. Assim, eles serão os únicos componentes que precisaremos adicionar.
Aqui está o nosso projeto:
Simples, né?
Claro que esses microcontroladores não foram escolhidos ao acaso aqui. Estas placas são bem conceituadas aqui na comunidade (inclusive, para a Blue Pill, existe no Embarcados muito conteúdo legal sobre ela). Elas são mais que suficientes para apresentar os conceitos que trouxe na palestra! Isso sem falar que as duas são suportadas por ótimas IDEs que são fornecidas pelos seus fabricantes! Vamos começar os trabalhos….
O repositório e diretórios
Começamos definindo como que vamos organizar os nossos arquivos. Vou apresentar aqui uma organização simples o suficiente para o nosso projeto mas que atende a grande maioria dos casos por aí.
É importante salientar que esta é apenas uma de diversas maneiras diferentes de organizar um repositório de software embarcado e que talvez você queira fazer de maneira diferente. Isso não tem problema nenhum, mas atente-se como que esta organização promove ter os códigos fontes fora dos projetos específicos, buscando ter eles disponíveis para futuros produtos. O que quero dizer é:
Aqui está:
Cada uma destas pastas tem o objetivo de armazenar uma categoria específica de códigos fontes e/ou outros arquivos dos nossos projetos. Seguindo a sequência de nossa árvore:
workspaces
Diretório para os nossos workspaces de Eclipse. As IDEs que vamos usar são baseadas nele.
O Eclipse trabalha com o conceito de ‘workspace’ e cada IDE baseada nele tem arquivos distintos. Assim, é necessário que cada um tenha o seu diretório e é aqui que eles vão ficar.
Lembrando que as configurações de workspace são específicas para cada usuário – é o seu workspace – e assim não deve ser parte do repositório.
docs
Documentações e outros arquivos relevantes para os projetos. Por exemplo, datasheets, reference manuals, por aí vai.
repository
O nosso repositório, onde ficará todo o código fonte das nossas soluções embarcadas, junto com os seus projetos e quaisquer outros arquivos necessários.
É natural que tudo comece sob um mesmo diretório e, conforme o desenvolvimento for crescendo, outros repositórios são criados para separar, por exemplo, código de drivers, de libs, de produtos. Mas para o nosso projeto e para a situação atual da BI, só um repositório é mais que suficiente.
repository/hal
Este diretório contém todas as abstrações de hardware, sejam elas relacionadas diretamente à periféricos dos microcontroladores, a dispositivos externos ou até mesmo a outros tipos de implementações.
repository/hal/drivers
Diretório dos drivers, que são os módulos relacionados ao controle de um ou mais periféricos dos microcontroladores para atuação destes em seus meios.
Vamos aproveitar das APIs que as fabricantes dos microcontroladores fornecem para desenvolver estes módulos.
repository/hal/board
Diretório com módulos voltados especificamente para a operação em placas eletrônicas específicas. Rotinas de inicialização das placas e outras coisas específicas dos microcontroladores delas estarão aqui.
Aqui também vamos aproveitar dos recursos que as fabricantes fornecem.
repository/libs
Diretório para as bibliotecas, que são os módulos que serão compartilhados com um ou mais produtos. Não só seus códigos fonte ficam aqui, mas também quaisquer outros binários necessários para seus funcionamentos.
Esta pasta é a que mais vai crescer conforme os trabalhos da nossa equipe forem avançando, pois aqui que estará a maioria dos módulos que implementam as regras de negócios dos produtos da nossa empresa.
repository/libs/os
Nosso primeiro módulo, contendo a abstração do sistema operacional.
Este módulo possibilitará que os outros possam ser desenvolvidos independente do OS, seja este um RTOS ou até mesmo baremetal.
Falaremos mais sobre ele nos nossos próximos artigos.
repository/products
Diretório para os nossos produtos, contendo seus códigos fonte, projetos, testes unitários, etc.
repository/products/blinky
Nosso primeiro produto! Aqui neste diretório ficará tudo que é relacionado exclusivamente a ele.
repository/products/blinky/source
Todo o código fonte específico do nosso produto.
repository/products/blinky/tests
Diretório com os setups de testes unitários, para testar os códigos fontes específicos do nosso produto.
repository/products/blinky/projs
O nosso produto irá ser desenvolvido para diferentes microcontroladores e para diferentes placas.
Para cada configuração específica, um projeto será criado neste diretório.
Perceba que o código fonte do produto não está neste diretório.
repository/products/blinky/projs/st_bluepill
Configurações e projeto Eclipse para compilar o nosso produto para operar na Blue Pill.
repository/products/blinky/projs/nxp_frdmkl25z
Configurações e projeto Eclipse para compilar o nosso produto para operar na FRDM-KL25Z.
repository/sdk
Diretório contendo bibliotecas de terceiros, bibliotecas estas que iremos utilizar sem fazer nenhuma edição nas mesmas. Geralmente seus subdiretórios são nomeados de acordo com as empresas fornecedoras dessas bibliotecas, mas isso não é mandatório.
repository/sdk/stm32
Bibliotecas fornecidas pela ST para seus STM32, como as suas bibliotecas de abstração de hardware.
repository/sdk/nxp
Bibliotecas fornecidas pela NXP para seus microcontroladores, como as suas bibliotecas de abstração de hardware.
repository/sdk/cmsis
Módulos da biblioteca CMSIS que utilizaremos em nossos produtos.
repository/tests
Arquivos para a operação dos testes unitários e códigos-fonte para auxiliar a construção dos testes.
repository/helpers
Último mas não menos importante, aqui ficarão os cabeçalhos e outros módulos simples, mas que são usados por vários lugares em nosso repositório. As definições dos tipos utilizados pelos nossos módulos, por exemplo, ficarão aqui.
Qual o próximo passo?
No nosso próximo artigo vamos definir todas as interfaces dos módulos do nosso projeto.
Essas interfaces são os cabeçalhos públicos que tanto falei na palestra. Todas as dependências serão definidas por eles. Através deles poderemos trocar implementações de módulos sem afetar as outras partes do seu produto. Eles vão ser o ‘esqueleto’ do nosso software embarcado.
Como sempre, perguntas, comentários e sugestões são sempre bem vindos!
Até lá, pessoal!
Parabéns pelas informações, artigo de ótima qualidade. Aguardando a continuação. Meu nome é José Adriano, tenho 56 anos e sempre sonhei em criar uma startup de hardware, apesar da idade decidi buscar conhecimento e em 2017 conclui minha formação em engenharia de computação, estou agora na batalha para desenvolver meu MVP, sem dinheiro, mas com muita vontade estou estudando tudo que posso, principalmente sobre sistemas embarcados. Desenvolvi alguns projetos para familiares e acredito que estou pronto para esta grande luta. Novamente parabéns pela iniciativa.
Olá, José!
Obrigado pelo contato e parabéns pela sua iniciativa! Espero que os artigos sejam úteis para o seu MVP e próximos projetos! Mande novidades!
Primeiro quero deixar aqui meu agradecimento pelo que vc ensinou na palestra. Perdi a conta de quantas vezes assisti o vídeo para ir tomando nota de tudo e entender cada detalhe e te digo que isso mudou radicalmente a forma que eu trabalhava no desenvolvimento, já estou aplicando esses conceitos nos novos projetos. Agora com esse projeto “mão na massa” vai ser bacana ver como vc implementa tudo isso na prática e sem duvida vai ajudar muito a aperfeiçoar o aprendizado… não vejo a hora de ver os próximos artigos rs… Forte abraço e muito obrigado !
Boa tarde Wagner,
Muito obrigado, fico feliz que o conteúdo que estou trazendo esteja lhe sendo útil! Nas próximas semanas entrarei em mais detalhes e logo logo teremos código fonte! Continue acompanhando, grande abraço!
Não é possível comentar.