Meu treinamento de Linux embarcado já esta com quase 8 meses de vida. Desde novembro de 2011 formei 13 turmas, ou aproximadamente 140 alunos entre estudantes e profissionais da área.

Sei que esta minha missão de desmistificar o Linux e disseminar o uso de software livre em sistemas embarcados está longe do fim. Muito pelo contrário. Cada turma que abro tem as inscrições encerradas em menos de duas semanas. E quanto mais as pessoas e as empresas percebem o valor de soluções abertas como o Linux em sistemas embarcados, maior é a demanda por capacitação. Por isso me sinto bem em saber que tenho ajudado muitas pessoas e empresas a vencer esta barreira inicial.

Mas sei também que estou ajudando apenas uma parcela das pessoas que trabalham com sistemas embarcados. O uso do Linux vem da exigência de projetos mais complexos, com características de conectividade e interfaces multimedia, que exigem CPUs mais potentes, rodando à 600/800/1GHz, com 256/512MB de RAM, etc.

Mas e aquelas pessoas envolvidas com microcontroladores, que rodam à 20MHz, 40MHz, 100MHz no máximo? Onde as memórias são medidas em KB, não em MB? Como trazer as vantagens do uso de um sistema operacional para estes tipos de projeto? A resposta está no uso de um RTOS. E é para estas pessoas que criei o primeiro treinamento de FreeRTOS do Brasil!

Mas antes de falar do treinamento, vamos responder à algumas perguntas…:)

RTOS? POR QUÊ?

Antes de mais nada, quem não conhece os conceitos de um RTOS pode ler dois artigos que escrevi sobre o assunto um tempo atrás. Tem uma introdução sobre o tema no artigo “Sistemas de Tempo Real – Parte 1” e uma aplicação prática no artigo “Sistemas de Tempo Real – Parte 2“.

Mas Sergio, eu sempre trabalhei sem um RTOS. Por que agora eu preciso de um?

Bom, sabemos que o principal objetivo de um RTOS é garantir que as restrições de tempo da aplicação sejam atendidas. Mas mesmo que sua aplicação não tenha requisitos de tempo real, um RTOS traz diversas outras vantagens. Vamos começar pelo…

… LADO TÉCNICO DA COISA

Sem um RTOS, nosso firmware é basicamente um monte de rotinas de tratamento de interrupção (ISR), mais um loop infinito na função main() para gerenciar todas as funcionalidades providas pelo software. Este loop infinito pode ou não ser implementado através de uma máquina de estados. Esse é o máximo que conseguimos chegar em termos de arquitetura de software para nosso firmware sem um sistema operacional para gerenciar os recursos da máquina. Mais do que isso, você já começou a implementar seu próprio kernel de sistema operacional.

À grosso modo, é mais ou menos assim que estamos acostumados a desenvolver firmware:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15

void main(void)
{
    init_hardware();
 
    init_system();
 
    for (;;) { 
        read_sensors();
        read_usb();
        read_rede();
        check_gpios();
        update_display();
        ...
    }
}

E pra falar a verdade, esta solução é mais do que suficiente para aquele produto baseado em 8 bits que tem apenas algumas funcionalidades básicas. Como um RTOS consome recursos da máquina, adicionando overhead de processamento, consumo de flash e RAM, não é a melhor solução para projetos pequenos com microcontroladores mais modestos. Então aquele seu PIC, AVR ou 8051 com 4KB de flash e 128B de RAM pode não servir para um projeto com RTOS.

O problema é que cada vez mais os projetos que trabalhamos estão ficando mais complexos, o que exige também microcontroladores mais complexos, com maior capacidade de flash e RAM, e recheados de recursos como interfaces gráficas, portas USB, comunicação sem-fio e conexão com a Internet. E trabalhar nestes sistemas com o “paradigma de 8 bits” trazem alguns desafios.

Como precisamos tratar tarefas prioritárias dentro de uma ISR, adicionamos uma latência (tempo de resposta) maior ao sistema, principalmente se a ISR for muito longa. E este problema se multiplica devido ao fato de termos mais interfaces de I/Os do que o normal, e consequentemente mais interrupções acontecendo ao mesmo tempo. Um RTOS facilita a divisão do trabalho entre interrupções e tarefas, melhorando a performance e diminuindo consideravelmente o tempo de latência do sistema.

Outro problema está no loop principal da aplicação. Se uma das funções do loop principal demorar mais do que o esperado, todo o sistema será impactado. Adicionar mais funcionalidades significa aumentar o tempo de resposta, piorando a performance do sistema como um todo. O problema fica maior ainda se você tiver diversos desenvolvedores trabalhando no mesmo código. Existe um sentimento de medo para dar manutenção na aplicação: “Será que se eu adicionar esta funcionalidade aqui, vou impactar aquela outra funcionalidade lá?” Com um RTOS, o fato de termos um kernel gerenciando as tarefas com base em suas prioridades, garantimos uma melhor gestão dos recursos de CPU, memória e I/O. A aplicação irá escalar muito melhor, porque fica muito mais fácil adicionar novas funcionalidades sem se preocupar tanto com o impacto no restante do sistema.

Uma outra grande vantagem do RTOS é que a tendência à trabalhar com eventos é muito maior.

Em sistemas convencionais, é comum fazer polling em tudo:

1
2
3
4
5
6

void le_adc()
{
    ...
    while (!adc_ready);
    ...
}

Trabalhar com polling é desperdiçar preciosos recursos da CPU. Com um RTOS, a arquitetura do software pode ser toda baseada em eventos e interrupções, economizando processamento e melhorando a eficiência. E isso traz uma outra vantagem menos percebida…

Neste mundo cada vez mais móvel e conectado, o assunto “consumo de energia” está em moda. E com um sistema todo orientado à eventos, você pode imaginar como fica mais fácil colocar a CPU para dormir e acordá-la quando necessário.

MAIS ALGUMAS VANTAGENS

Existem ainda mais algumas vantagens não tão fáceis de mensurar quando trabalhamos com um RTOS.

Devido ao fato de precisarmos dividir a aplicação em tarefas, automaticamente o software fica muito melhor estruturado e muito mais modular. Fica fácil dar manutenção no código, pois temos uma visão clara do relacionamento entre as tarefas. Facilita também os testes, já que cada tarefa é uma entidade independente. E facilita o desenvolvimento em equipes com múltiplos desenvolvedores. E incentiva o reuso de código. E facilita o porte do software para outra plataforma. E …

… MAIS UM MOTIVO

Só mais um motivo para você avaliar o uso de um RTOS. E é esse o motivo que você irá usar para convencer seu chefe! :)

Dá uma olhada nas imagens abaixo, que retirei do site da Farnell na data em que publiquei este artigo (clique nas imagens para vê-las no tamanho original).

PIC18F87, 8 bits, 48MHz de clock, 128K de flash, 3.8K de RAM – Custo: 4.85 euros:

LPC1754, 32 bits, 100MHz de clock, 128K de flash, 32K de RAM – Custo: 4.69 euros:

Sim, é isso mesmo. O LPC1754 é um ARM Cortex-M3 da NPX, uma CPU de 32 bits que roda a 100MHZ e tem 128K de flash e 32K de RAM. Ele está mais barato que o PIC18F87, uma CPU de 8 bits que roda à metade da velocidade e tem apenas 1/8 da quantidade de RAM do LPC1754! Sim, uma CPU de 32 bits, com clock maior e mais RAM esta mais barata que uma CPU de 8 bits com clock menor e menos RAM!

Se eu acho que os microcontroladores de 8 bits vão morrer? Não, não acho. Mas boa parte dos projetos que são desenvolvidos hoje em 8 bits estão migrando ou migrarão para 32 bits num futuro próximo. E se você quiser fazer parte deste futuro, e aproveitar todas as vantagens de uma CPU de 32 bits, vai precisar entrar no mundo do RTOS.

AGORA SIM, O TREINAMENTO

O meu treinamento é um convite para você entrar neste mundo. Ele será baseado no FreeRTOS, o sistema operacional de tempo real (RTOS) de código aberto mais usado no mundo. Ainda não defini o kit de desenvolvimento que utilizarei nas atividades práticas, mas a idéia é que ele seja baseado em um ARM Cortex-M3.

Será um treinamento de 3 dias. A idéia é introduzir o aluno no desenvolvimento com um RTOS, e depois cobrir toda a API do FreeRTOS, sempre apoiado em exercícios e atividades práticas focadas do mundo real.

A primeira turma deverá acontecer em agosto. Também ainda não tenho definido o valor do treinamento, mas assim como o treinamento de Linux embarcado, a idéia é do investimento ser abaixo de R$1.000,00.

Mais informações sobre o treinamento e uma visão inicial da agenda podem ser vistos na página oficial de divulgação do treinamento.

Se você tem interesse em participar das primeiras turmas, pode preencher um formulário de pré-inscrição sem compromisso e entrar na fila de espera. Os primeiros que realizarem a pré-inscrição terão prioridade na formação das primeiras turmas. Para acessar o formulário de pré-inscrição clique aqui.

Qualquer dúvida, crítica ou sugestão, mande um e-mail para treinamentos@e-labworks.com ou deixe um comentário neste post.

Um abraço!

Sergio Prado