Firmware para microcontroladores

Euripedes Rocha
This book is for sale at http://leanpub.com/firmwarec

This version was published on 2016-02-20

This is a Leanpub book. Leanpub empowers authors and publishers with the Lean Publishing
process. Lean Publishing is the act of publishing an in-progress ebook using lightweight tools and
many iterations to get reader feedback, pivot until you have the right book and build traction once
you do.

This work is licensed under a Creative Commons Attribution-NonCommercial-ShareAlike 3.0

Unported License
Conteúdo

Sobre este livro . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1

Objetivos desse livro . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1
Interagindo com esse livro . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1
Este livro é grátis? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1

Introdução . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
O que é firmware? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
A linguagem C . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
Microcontroladores . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
Pela união dos seus poderes… . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5

Ferramentas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
Versionamento e controle . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
Editor de texto/IDE . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
Placa de desenvolvimento . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
Ferramentas de compilação . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
O sistema de build . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
Debug . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
O datasheet e documentações . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10

Iniciando os trabalhos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
Objetivos do capítulo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
Criando o repositório . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
Versionando o nosso repositório . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11

Iniciando o microcontrolador . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
Mapa de memória . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
A função main() . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
Antes da função main() . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
The PowerLoop! . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18
Iniciando o hardware . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18

Periféricos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20

Timers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21
CONTEÚDO

Conversores . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22

Seriais . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23

Interrupções . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24

State machines . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25
Sobre este livro
Objetivos desse livro
Antes de iniciar propriamente o texto do livro é preciso estabelecer os modestos objetivos do
mesmo. Este livro pretende ser uma introdução ao projeto de firmware para sistemas embarcados
microcontrolados. A ideia é que ele sirva de texto introdutório e amplie o conhecimento sobre
microcontroladores e a linguagem C.
É um livro dedicado aos iniciantes e aos iniciados com pouca estrada, embora eu tenha esperança
de também fornecer alguma informação útil aos que tem mais experiência.

Interagindo com esse livro

O propósito desse livro é se manter como um norteador e uma forma de ajudar iniciantes no mundo
do projeto de firmware. A jornada certamente é longa e em conjunto é melhor. Por isso iniciei um
chat¹ para que as questões que venham a aparecer possam ser mais facilmente respondidas.
Além disso tenho plena certeza que muitas modificações e correções irão acontecer ao longo da
produção deste livro e pretendo que o mesmo seja desenvolvido em parceria com os que resolvam
dedicar algum tempo a leitura deste livro. Assim qualquer falha encontrada, sugestão de melhoria
e de tópico a ser abordado nas revisões tem um canal facilitado usando as próprias ferramentas que
vamos discutir ao longo do texto nesse painel².
Como ilustrado acima, acredito que esse livro será melhor aproveitado em seu formato digital, como
um guia ao longo de algum projeto. Que tal inciar sugerindo um projeto completo para realizarmos
ao longo do livro( ou de um próximo dedicado exclusivamente a ele)?
Você pode ainda facilitar nossa comunicação me permitindo entrar em contato diretamente seleci-
onando a opção de compartilhar o seu email na página da sua biblioteca do LeanPub.

Este livro é grátis?

Sim e não. O livro pode ser obtido sem nenhum gasto financeiro da sua parte mas ele certamente
custará todas as horas de trabalho que eu dedico a escrita e a interagir no chat. Isso não quer dizer
que eu exija pagamento mas também não ficarei triste se você resolver contribuir financeiramente
¹http://bit.ly/chatfirmware
²http://bit.ly/1PiUQbK

1
Sobre este livro 2

com a causa. Talvez você se pergunte o motivo de adotar esse modelo, e essa resposta é a parte mais
importante desta parte do livro. Eu acredito que o acesso a informação e conhecimento deva possuir
o mínimo de barreiras para aquisição, mas também sei que produzir material com alguma qualidade
custa muito tempo e algum dinheiro. Espero que essa iniciativa tenha sucesso e que isso fomente a
ideia de outras pessoas produzirem conteúdo em português sobre outros assuntos.
Introdução
O que é firmware?
A primeira questão que temos de sanar é o que raios é o firmware.
Quando tratamos de sistemas programáveis é comum estabelecer uma divisão bem clara entre o
elemento físico e a lógica envolvida.
Ao elemento físico damos o nome de hardware. No hardware estão os sensores de temperatura, o
transistor que irá acionar o relé e o led que acende indicando um problema. Esses elementos são
mais difíceis de modificar uma vez finalizado o projeto.
A parte que complementa esses elementos é o software. Nesse ponto temos estabelecida a lógica sob
a qual irá funcionar o produto. O que diferencia o software do firmware?
A diferença não é muito definida e estabelecida, mas o firmware lida com a atividade mais básica
de interface com o hardware e faz o papel de comandar e coordenar as ações do mesmo. O termo
software é comumente deixado para elementos de mais alto nível.

A linguagem C
A despeito de todos os anos passados desde a sua criação nos anos 70 o C ainda é predominante
quando se trata de desenvolvimento de sistemas embarcados e código que faz interface com o
hardware. Por possuir características que permitem o interfaceamento direto com a memória e não
colocar muitas camadas entre o código e sua execução essa hegemonia está aparentemente longe
de ser posta a prova. Mesmo o C++ está há vários anos nessa jornada e ainda não atingiu a mesma
utilização que o C.

Microcontroladores
Um microcontrolador é um dispositivo que possui internamente um microprocessador permite a
execução de um programa em sua linguagem nativa(o assembly) e que contém ainda no mesmo
encapsulamento uma memória pra guardar esse programa, uma memória que será utilizada durante
a execução do programa.
Hoje em dia temos diversos fabricantes, modelos e arquiteturas e é preciso alguma experiência na
hora de fazer a escolha de que microcontrolador utilizar em um determinado projeto, discutir essa
escolha está além do escopo desse livro.
Vamos brevemente discutir cada uma das partes dessa nossa definição de microcontrolador.

3
Introdução 4

Microprocessador
O microprocessador é quem de fato possui a capacidade de executar tarefas programadas interface-
ando com o mundo exterior através de seus periféricos. Um processador pode de maneira resumida
e simplificada definir seu funcionamento através do ciclo:
1 - Busca
Uma tarefa é retirada de uma lista de tarefas previamente determinado. Essa lista de tarefas é o
programa em execução e o local pré determinado é um endereço na memória que guarda o programa.
2 - Decodificação
A tarefa é analisada pelo processador para que o mesmo saiba o que exatamente ele deve fazer.
Embora exista uma infinitude de aplicações as tarefas que o processador é capaz de executar, suas
instruções, são limitadas. A esse conjunto chamamos de Arquitetura do conjunto de Instruções (ISA
na sigla em inglês).
3 - Execute
Uma vez que a instrução foi interpretada a mesma deve ser executada. As instruções envolvem
acessos a memória, operações aritméticas e lógicas. Algumas arquiteturas apresentam instruções
especializadas para acelerar a execução de uma determinada classe de algoritmos.
Esse ciclo é executado a cada nova instrução do processador, ou seja, pra cada endereço do nosso
programa o ciclo se repete e nos processadores modernos esse ciclo ocorre alguns milhões de vezes
por segundo!³
ignora conceitos mais avançados no funcionamento do processador. Um livro específico sobre
arquitetura de computadores tratará melhor o assunto que está além do escopo deste livro.

Memória de programa
Essencialmente é o lugar onde está guardado o programa que será executado pelo processador.
Essa memória em microcontroladores é não volátil, ou seja, ela não seu conteúdo ao desligarmos
a alimentação do circuito. Nos microcontroladores atuais essa memória é do tipo flash na maioria
dos casos. O tamanho varia de 1kB até 2MB (é possível que uma ou outra exceção apareça mas esses
são valores típicos).

Memória de dados
Nessa memória estão os dados utilizados durante a execução do programa. Essa memória é volátil
e portanto os dados são perdidos quando a alimentação do circuito é removida. Essa memória é
usualmente muito menor que a memória flash do microcontrolador, chegando a algumas dezenas
de kB.
³É importante destacar que essa é uma visão simplificada que
Introdução 5

Periféricos
Nesse ponto está o que considero o grande poder dos microcontroladores. A presença de elementos
de hardware dedicados as mais diversas funções é o que provê a versatilidade encontrada nos
microcontroladores. Entre os periféricos estão timers,interfaces de comunicação SPI, I2C e UART,
conversores analógico digital e em alguns casos elementos mais especializados. Para o processador,
que é quem faz o controle de todos os elementos os periféricos são somente mais endereços de
memória a serem acessados.

Pela união dos seus poderes…

Quando tomamos um sistema microcontrolado completo, um robozinho por exemplo, nós temos o
microprocessador como cérebro lógico do sistema. No mesmo circuito integrado temos um PWM,
periférico interno, que controla a velocidade de um motor. Além do motor temos o uso de um
integrado como o MPU6050⁴ que nos dá informações sobre a posição de algum elemento do nosso
robozinho. A maneira como nos comunicamos com o periférico externo, MPU6050, é através do
periférico interno I²C.
⁴http://www.invensense.com/products/motion-tracking/6-axis/mpu-6050/
Ferramentas
Antes de colocar a mão na massa e escrever código vamos destacar algumas ferramentas essenciais
durante as várias fases do desenvolvimento do firmware. Uma nota que devo destacar é que a ferra-
mentas aqui descritas são utilizadas em ambiente Linux que é o meu ambiente de desenvolvimento,
isso não impede o uso deste livro por usuários de outros sistemas operacionais mas neste momento eu
só posso cobrir o uso de um SO dada a disponibilidade de recursos de tempo e da presença exclusiva
de computadores rodando Linux ao meu dispor. O chat pode ser usado para discussão sobre outros
SOs bem como tutoriais irão surgir a partir da demanda dos leitores.

Versionamento e controle
Imagine a seguinte cena. Você acabou de escrever uma parte do seu código e resolveu testar o
funcionamento do mesmo mas nada aconteceu, o que fazer? Você levanta alguma teoria e vai testá-
la, mas não pretende perder o trabalho feito. Ou mesmo quando no meio do projeto você ou algum
responsável pelo mesmo resolve mudar o comportamento do sistema. Como salvar sem perder o
trabalho realizado?
Em um mundo de trevas e caos em que eu já vivi seria criada uma nova pasta com o nome
projetodataxxxx ou mesmo projetoversaofinal, ou projetoagoravai(quem nunca :) ).
Após algum tempo com esse sofrimento descobri existem sistemas inteiros dedicados a solução desse
problema. Aqui vou dedicar algumas linhas ao git, sistema de versionamento desenvolvido para
facilitar o desenvolvimento do kernel do Linux.
Existem outros sistemas de versionamento disponíveis mas focaremos no git. Você pode usar o
sistema que melhor se adaptar, menos o da mudança de nomes de arquivos e diretórios descrito
acima ;).

Versionando com o git

Primeiramente precisamos entender o que queremos com o uso de um sistema de versionamento.
1 - Manter um registro do que está sendo escrito. Este livro mesmo usa um repositório, privado por
enquanto. 2 - Ser capaz de aplicar correções sem afetar o fluxo de desenvolvimento. 3 - Mesclar
diferentes versões do mesmo fonte( merge )

Plataformas

Primeiramente vamos deixar claro. Já passamos de 2010 e para cada necessidade que pode ser
resolvida com um computador há pelo menos uma plataforma online. Salvo o caso em que há

6
Ferramentas 7

propriedade intelectual com questões de segurança de estado há pouca justificativa pra manter uma
base de código local somente.
Há para o caso de repositórios de código baseado no git algumas opções.
1 - Github
github.com⁵
O Github é basicamente uma rede social de programadores. Há muitos projetos de grande porte que
usam o Github para versionamento e controle de sua base. O github possui repositórios públicos
gratuitos e para que o repositório seja privado é preciso migrar para o plano pago.
2 - Bitbucket
bitbucket.org⁶
Uma alternativa ao github, oferece repositórios privados e públicos, mas os repositórios privados
possuem limite de colaboradores e é preciso migrar para panos pagos caso o número de desenvol-
vedores seja maior que 10.
Além do git oferece suporte ao uso do mercurial como controle de versão.
3 - Gitlab
gitlab.com⁷
Outra alternativa que permite a criação de repositórios privados no plano gratuito.
As três plataformas que foram listadas atendem aos projetos mais básicos e profissionais e possuem
diferenças que dependem do uso e da necessidade de cada projeto/equipe. É preciso usar por um
tempo pra definir a escolha. No nosso caso iremos utilizar o Github, mas eu mantenho projetos nas
três plataformas, o livro é mantido no Bitbucket e o nosso conjunto de tickets ( issues ) para controle
de atividades está no github.

Controle do projeto com Issues

É importante ao desenvolver um projeto identificar que tarefas devem ser realizadas e manter
algum controle sobre a prioridade das mesmas. O Github, e as outras plataformas oferecem sistemas
similares, possui o sistema de Issues. Uma issue pode ser utilizada como uma tarefa a ser realizada,
indicando um feature nova, ou um bug que precisa ser corrigido.
Quando o repositório utiliza o github o serviço waffle.io⁸ é uma alternativa para um gerenciamento
mais visual do repositório.
⁵github.com
⁶bitbucket.org
⁷gitlab.com
⁸waffle.io
Ferramentas 8

Editor de texto/IDE
Essa é de fato a nossa ferramenta de trabalho enquanto desenvolvedores. A escolha é um tanto
pessoal mas é importante escolher um editor que possua ao menos destaque de sintaxe. Uma boa
interface de debug é algo igualmente importante dado que boa parte do nosso tempo é dedicado a
encontrar os problemas que nós mesmos inserimos no código.
Uma opção comum é o uso do Eclipse com plugins que facilitam o desenvolvimento de sistemas
embarcados. Alguns fabricantes disponibilizam ambientes de desenvolvimento dedicados aos seus
microcontroladores e algumas pessoas, eu entre elas, possuem a preferência pelo uso de ferramentas
de linha de comando. A questão aqui é automatizar o máximo de tarefas e tornar menos complexas
as atividades de suporte como compilação, debug de código e gravação do microcontrolador. Voltarei
ao assunto mais vezes.

Placa de desenvolvimento
Quando comecei nessa brincadeira alguns anos atrás as placas de desenvolvimento eram muito mais
caras que são hoje em dia e poucos fabricantes possuíam kits com preço acessível. Aliás era difícil
inclusive comprar alguns microcontroladores.
O cenário evoluiu bastante e há muitas opções para placas de desenvolvimento.
Algumas opções para seguir com o assunto desse livro:
A Texas Instruments possui as placas [launchpad] A NXP possui as placas [Freedom] A ST possui
as placas [Discovery]
Note que os três links apontam para placas com microncontroladores cujo processador é um ARM
Cortex-M4. Nesse texto vamos tratar o uso desses processadores por uma questão de acesso as
ferramentas. Embora os exemplos estejam focados nessas plataformas não acredito que isso seja
um limitante para levar os conceitos a outras plataformas.

Ferramentas de compilação
Quando escrevemos o código no editor de texto que escolhemos ele é somente uma descrição da
lógica que pensamos ao iniciar o nosso projeto. O processador integrado ao microcontrolador não é
capaz de executá-lo. Conforme disse anteriormente o processador só possui capacidade de executar
seu limitado conjunto de instruções. Precisamos de um tradutor.
Quando finalizamos a escrita do código temos um conjunto de caracteres gerando um texto. O
processador interpretará suas instruções no formato de palavras binárias com códigos de operação
e operandos, qual o processo de tradução entre os dois idiomas?
Ferramentas 9

No primeiro passo temos a compilação. Nesse estágio o texto que criamos é transformado em
arquivos objeto. Esse arquivo é a tradução direta do que está escrito para a linguagem do processador
em questão. Esse arquivo ainda não poderá ser executado.
No segundo estágio o linker entra em ação. O linker irá juntar essas peças em seus endereços corretos
e montar uma sequência que permita que o código execute e as chamadas de função ocorram de
maneira correta. Voltaremos ao assunto em mais detalhes quando formos de fato utilizar essas
ferramentas.
No decorrer desse texto iremos utilizar este compilador⁹ e portanto é importante que o mesmo
seja instalado. Acredito que todas as distribuições Linux possuam um pacote para a instalação do
compilador.

O sistema de build
O projeto de sistemas vai ficando mais complexo conforme vamos adicionando novas bibliotecas e
algoritmos. Juntar todo o código manualmente e gerar os artefatos para gravação do microcontrola-
dor se torna uma tarefa tediosa e sujeita a muitos erros. Para solucionar essa questão um conjunto
de ferramentas dedicadas a construção de software foi desenvolvida. No decorrer do texto iremos
utilizar makefiles.
O make é uma ferramenta que data dos anos 70 e possui uma linguagem própria para descrever
como devem ser construídos os sistemas.
Há diversas outras ferramentas dedicadas a essa tarefa de automação de construção de código e do
mesmo modo que o editor você pode escolher a sua. Atualmente tenho iniciado o uso do ceedling
como ferramenta de build em substituição ao make por sua integração com ferramentas de testes
unitários automatizados.

Debug
Não vou estabelecer uma estatística precisa, mas o fato é que a maior parte do tempo em que estamos
trabalhando em um projeto é dedicado a encontrar e corrigir problemas no código. Esse processo é
denominado debugging.
Precisamos deixar uma coisa bem clara. Em um sistema microcontrolado o seu código é escrito em
um ambiente e executado em outro, isso é denominado cross development. Essa características torna
as coisas mais interessantes no momento de encontrar os problemas.
Ao longo dos anos as ferramentas de debug se tornaram mais evoluídas e já há algum tempo é
possível controlar a execução do firmware a partir do ambiente de desenvolvimento. Para isso
precisamos de dois componentes.
⁹http://bit.ly/booktask1
Ferramentas 10

O primeiro deles é um hardware que faça a interface com o controlador interno de debug do
microcontrolador. A maior parte das placas de desenvolvimento atual integra uma interface dessas,
as três listadas acima possuem, permitindo a gravação da memória de programa e a execução de
código passo a passo para a depuração e remoção de erros.
O segundo elemento é o software que executado no ambiente de desenvolvimento irá traduzir os
comandos para essa interface e nos apontar no código em que estágio da execução estamos.
Essa é a interface que deve ser melhor escolhida e a ferramenta que devemos conhecer mais a fundo
pois é ela quem irá nos servir na maior parte do tempo.

O datasheet e documentações
Não é usual listar datasheets como ferramentas, mas qualquer um que já passou algum tempo
desenvolvendo sabe que é importante manter a documentação do microcontrolador em uso com
fácil acesso. Vou deixar duas notas sobre o assunto.
Primeiro que a documentação dos microcontroladores tem se tornado muito complexa e crescido
bastante. Um efeito disso é que ao longo dos anos a documentação tem se tornado cada vez pior isso
é um sofrimento enorme para quem depende de utilizar um microcontrolador.
O segundo ponto que se relaciona ao primeiro é que com a complexidade dos microcontroladores
a documentação se dividiu em vários documentos. Usualmente iremos encontrar um datasheet
contendo informações elétricas e úteis ao projeto do hardware e um reference manual que contém
as informações relevantes dos periféricos e que será utilizada por nós ao desenvolver a interface com
os periféricos.
Iniciando os trabalhos
Objetivos do capítulo
Nesse capítulo iremos tratar o início de um projeto e a estrutura que utilizaremos para o trabalho.
Trataremos da criação e o uso básico do git como sistema de versionamento com um repositório
no github. Vamos aproveitar para tratar do boot do microcontrolador e como o código vai do
processador de texto até a memória do microcontrolador.

Criando o repositório
No capítulo anterior tratamos rapidamente das ferramentas que são utilizadas no decorrer de
um projeto e agora vamos colocar em prática o uso. O primeiro passo é criar o repositório para
mantermos o trabalho e facilitar o compartilhamento de código e informação entre nós.
Vá até o github.com e crie uma conta e um novo repositório, escolha o .gitignore para a linguagem
C e a licença que você se sentir a vontade, usualmente eu escolho MIT. Qualquer problema nesse
processo use o chat¹⁰ para pedir auxílio.
O arquivo .gitignore vai nos permitir listar os artefatos que não queremos salvar, como os binários
gerados por exemplo.

Versionando o nosso repositório

Agora que foi criado o repositório vamos ao uso. Abaixo uma lista sucinta de comandos do git.

Comandos básicos para o uso do git

Não pretendo fornecer aqui um guia completo do uso do git. Um livro que pode ser baixado
gratuitamente é o Pro Git¹¹ o link aponta para a versão em português.

• Clonando

O git é um sistema distribuído, ou seja, a sua cópia local irá conter todo o histórico e para iniciar o
trabalho é preciso obter os arquivos do repositório.
Para isso usamos:
¹⁰http://bit.ly/chatfirmware
¹¹https://git-scm.com/book/pt-br/v1

11
 Iniciando os trabalhos 12

1 git clone caminho_para_o_repositório

• Branch

Uma vez que a sua cópia local foi sincronizada com o repositório é hora de trabalhar nas
modificações. Uma boa prática é criar um branch local para executar as alterações necessárias no
código.
Um branch é uma variação, um ramo, do tronco principal do seu código. Ao criar o repositório há
inicialmente o branch master. Executando o comando:

1 git checkout -b novo_codigo

Será criado o branch novo_codigo e seremos movidos pra lá. Esse branch é exatamente o master. Se
fizermos alguma modificação no código e commitarmos voltando ao master com:

1 git checkout master

As modificações não estarão presentes. Isso porque elas pertencem ao branch novo_codigo.
Repare no uso da opção -b no primeiro comando. Ao informar essa opção ao git nós estamos
solicitando a criação de um novo branch. O checkout para o master não necessita do -b pois o
branch já existe.

• Commit

Quando fazemos alguma alteração no código, existe o momento em que temos de dizer para o sistema
de versionamento que ele deve registrar o estado atual do código. Esse momento é o commit.
Enquanto estamos trabalhando no código usando o editor de texto e validando usando as demais
ferramentas para o sistema de versionamento nenhuma das modificações existe. Uma vez que exista
uma modificação que deve ser salva devemos indicar ao sistema de versionamento que deve salvar
o status atual do branch. O comando é:

1 git commit -am "Mensagem de registro"

• Add

Para que o git saiba que deve manter o registro das modificações em um determinado arquivo ou
pasta devemos dizer ao sistema:
 Iniciando os trabalhos 13

1 git add nome_do_arquivo_ou_diretorio

• Merge

Após finalizarmos o trabalho no branch queremos que esse trabalho seja incorporado ao branch
master e pra isso usamos o comando merge. O comando merge irá misturar as duas versões deixando
com as versões mais recentes de cada arquivo. A sequência de comandos é:

1 git checkout master

2 git merge novo_codigo

Com isso as modificações do branch novo_codigo estarão incluídas no branch master.

Um destaque importante, caso esteja trabalhando com outras pessoas no mesmo código sempre
faça o update do seu branch master antes de fazer o merge.

• Push

Até esse ponto todas as modificações estão somente na cópia local e salvas somente no nosso
computador de trabalho. Nenhuma das plataformas listadas foi usada. É o momento de salvarmos o
trabalho no repositório remoto.

1 git push origin master

origin é o nome típico do remoto utilizado. O comando:

1 git remote -v

Nos mostra uma lista dos remote disponíveis.

master é o nome do branch que estamos enviando.

• Pull

Se estamos trabalhando em um projeto cujo repositório remote teve atualizações é importante

sincronizar com o comando pull:

1 git pull

Pondo em prática.
Vamos clonar o repositório criado no início do capítulo. Se tudo correu corretamente você terá uma
página com o seu repositório contendo 3 arquivos:

• .gitignore - lista de tipos de arquivo que o git vai ignorar.

• LICENSE - a licença escolhida
• README.md - uma descrição do repositório. É o conteúdo desse arquivo que o github mostra.

Observe o caminho do repositório e execute:

 Iniciando os trabalhos 14

1 git clone https://github.com/SEUNOMEDEUSUARIO/NOMEDOSEUREPOSITORIO

Após isso há uma cópia local do repositório. Voltaremos ao uso do git adiante.
Iniciando o microcontrolador
Quando tratamos do processo de funcionamento do microprocessador listamos as tarefas que ele
executa para saber qual a instrução a ser executada:
1 - Busca 2 - Decodificação 3 - Execução
Mas esse processo deve se iniciar em algum ponto. Antes de tratarmos o código de inicialização do
nosso programa vamos dar uma olhada no espaço de memória do nosso processador.

Mapa de memória
Quando descrevemos o que é um microcontrolador em essência foi dito que temos um microproces-
sador com um conjunto de periféricos integrado. Para o processador tudo que há é um conjunto de
endereços de memória. Cabe ao fabricante do microcontrolador preencher os endereços e acrescentar
algum significado aos mesmos¹².
Busque por port mapped i/o para entender as diferenças do outro método.
Quando utilizamos um microcontrolador cujo núcleo é um Cortex-Mx o mesmo possui algumas
características comuns para todos os fabricantes. O mapa de memória por exemplo é similar para
todos eles. O mapa de memória é uma informação encontrada nos manuais do microcontrolador
indicando a distribuição dos endereços de memória e seu significado.
Os processadores ARM Cortex-Mx possuem um endereço pra memória com 32 bits, com isso é
possível endereçar 2ˆ32 posições de memória, e a ARM já fez a divisão desse latifúndio previamente.
¹²Tratamos aqui somente de entrada e saída mapeada em memória.

15
Iniciando o microcontrolador 16

Mapa de memória simplificado

O mapa de memória simplificado da figura destaca somente as partes que nos interessam nesse
momento. Como dito anteriormente o processador do nosso microcontrolador somente é capaz de
manipular conteúdos de memória e esse mapa começa a refletir o conteúdo dessa memória.
A parte que se inicia no endereço 0x00000000 é dedicada ao código. Esse espaço pode se estender
até o endereço 0x20000000, o que nos daria 0,5GB de espaço para o nosso código! Mas não se
 Iniciando o microcontrolador 17

anime tanto, esse é o espaço reservado para a memória flash entretanto esse espaço não é ocupado
completamente pelos fabricantes. Para efeitos práticos, a depender do microcontrolador escolhido,
podemos considerar algo entre 32KB e 2MB para gravar os programas que escreveremos, acredite
isso é bastante coisa.
O setor seguinte possui o mesmo tamanho e do mesmo modo não é completamente ocupado pelo
fabricante. Nesse ponto temos o espaço de memória dedicado a SRAM, que é a nossa memória de
dados. Aqui estarão os dados que manipulamos na execução da função do nosso sistema embarcado.
Na sequência temos o espaço dedicado aos periféricos. Nesses endereços estarão os registradores
de configuração dos diversos periféricos presentes no microcontrolador. Essa seção da memória é
dividida novamente entre os periféricos e cada endereço representa um registrador com os vários
bits de configuração. Trataremos novamente dessa região e olharemos em detalhe alguns periféricos
para compreender melhor a leitura dos manuais e interface quando tratarmos a escrita de drivers.

A função main()
Nesse ponto do texto chegamos a parte que todos esperavam, código! Nesse ponto vamos tratar
superficialmente a estrutura do nosso programa. Na linguagem C o início de tudo é sempre através
da função main().
Assim o nosso programa terá necessariamente a seguinte estrutura na sua inicialização:

1 int main(){
2 return 0;
3 }

Nesse ponto possuímos um código que não executa absolutamente e não possui qualquer relação
com o hardware que será utilizado, mas já nos dá a semente do nosso trabalho.
Trataremos funções com mais detalhes no próximo capítulo.

Antes da função main()

Ao ligarmos o microcontrolador algumas coisas acontecem antes de a nossa função main ser de fato
chamada.
No momento em que o processador é ligado é há uma interrupção de reset e o handler da mesma
é chamado¹³, logo após dois endereços são lidos da memória 0x00000000 e 0x00000004. O primeiro
contém o conteúdo do registrador MSP(Main Stack Pointer) e o segundo contém o endereço do reset
vector, ou seja o local onde de fato começa o nosso programa.
¹³Trataremos de interrupções em um ponto no futuro
 Iniciando o microcontrolador 18

Os fabricantes fornecem um código de inicialização que é responsável por colocar a casa em

ordem antes de chamar a nossa função main. Esse código inicializa algumas partes da memória,
as que guardam as variáveis que vamos declarar para a execução do nosso programa, e a tabela de
interrupções.

The PowerLoop!
Voltemos agora a estruturar o nosso código. Em sistemas embarcados é pouco provável que a
execução do nosso programa termine. O nosso sistema deve permanecer funcionando o tempo em
que estiver ligado. Imagine se o controlador do freio ABS de um carro estivesse desligado durante o
processo de frenagem do carro?
Assim é típico encontrar um loop infinito, uma sequência de tarefas que são executadas por tempo
indeterminado. Assim o nosso código inicial fica assim:

1 int main(){
2 while(1) {
3 coisas fantásticas acontecem;
4 };
5 return 0;
6 }

O bloco while é o responsável por estabelecer o loop comentado. No próximo capítulo vamos tratar
as estruturas da linguagem C e discutir todas essas questões com mais detalhes.

Iniciando o hardware
Nos microcontroladores há tipicamente várias opções e configurações que devemos fazer para
utilizá-los da maneira que precisamos no nosso projeto. Tipicamente eu dedico um conjunto de
funções para essa tarefa e concentro tudo em um arquivo e uma única chamada de função no código
principal.
 Iniciando o microcontrolador 19

1 #include "hardware.h"
2
3
4 int main(){
5 hw_init();
6
7 while(1) {
8 coisas fantásticas acontecem;
9 };
10 return 0;
11 }

Temos aqui o aparecimento de dois novos elementos.

A diretiva #include diz ao nosso sistema de compilação que nós pretendemos usar o arquivo
hardware.h e as definições e funções contidas no mesmo.
Na chamada hw_init() temos o uso da função hw_init que está declarada no arquivo hardware.h,
essa é uma maneira que organizarmos o nosso código e de controlar o acesso a determinadas funções
e variáveis.
Periféricos

20
Timers

21
Conversores

22
Seriais

23
Interrupções

24
State machines

25