Já tenho o livro Linux Kernel Development do Robert Love há algum tempo, mas só agora terminei minha leitura da primeira à última página. É um livro ao mesmo tempo denso e didático. Bastante teoria, e muito código do kernel. Sei que ainda irei ler e reler muitas partes do livro, conforme avanço meus estudos e trabalho com projetos em Linux embarcado, mas seu conteúdo me ajudou a entender uma série de conceitos, e a identificar o porquê de certas decisões na implementação do kernel, incluindo:

• como o Linux gerencia internamente os processos, e que dentro do kernel processos e threads são a mesma coisa — a diferença esta no compartilhamento de recursos, e como o Linux implementa tudo isso através da chamada de sistema clone().
• a modularidade do escalonador de tarefas do Linux, podendo ter diferentes classes de escalonadores de tarefas, com diferentes algoritmos, rodando ao mesmo tempo para diferentes classes de processos!
• como o escalonador de tarefas padrão do Linux (CFS — Completely Fair Scheduler) calcula por quanto tempo cada processo deve rodar, usando o nice do processo para definir um peso proporcional ao total de processos disponíveis para execução.
• como a implementação das chamadas de sistema são feitas no nível do hardware.
• como implementar um manipulador de interrupção (interrupt handler).
• a diferença entre os dois contextos de execução do kernel do Linux: contexto de processo e contexto de interrupção, explicando porque você não pode usar uma função que pode dormir (i.e. que gera mudança de contexto) dentro de uma interrução.
• quando e como usar softirqs, tasklets e work queues para deferir trabalho no tratamento de interrupção e em módulos do kernel (no caso de work queues).
• como usar mecanismos de sincronização e proteger o acesso à recursos compartilhados com operações atômicas usando o tipo atomic_t, spinlocks, semáforos, mutexes e variáveis completion.
• que o significado de BogoMIPS (aquela mensagem que a gente sempre vê no início do boot do kernel) é uma medida de quão rápido é o processador em não fazer nada!
• como funciona o gerenciador de memória virtual e a camada slab.
• como funciona a implementação de cache de disco (page cache) e qual o algoritmo usado para propagar as alterações (page writeback).
• etc!

Tudo isso exemplificado com muito código! Às vezes me pego pensando porque um recurso tão valioso e disponível gratuitamente como o kernel do Linux não é usado como ferramenta de ensino de sistemas operacionais em instituições de ensino Brasil afora.

É realmente um livro que todo aquele que pretende trabalhar no kernel do Linux (seja profissionalmente ou por hobby) deveria ter.

CONTRIBUINDO

Aproveitando que estamos falando sobre o kernel, recentemente assisti um vídeo do Greg Kroah-Hartman sobre como “Escrever e submeter seu primeiro patch do kernel”.

Para quem não conhece, Greg é o mantenedor oficial da árvore estável do kernel e de alguns sub-sistemas, incluindo a árvore staging de drivers. Suas palestras são sempre didáticas e bem humoradas. Ele fala não só apenas sobre como submeter um patch, mas dá o caminho das pedras para quem quer se aventurar no desenvolvimento do kernel do Linux.

À propósito, o Greg é também o autor do livro Linux Kernel in a Nutshell, disponível gratuitamente no blog dele.

Recursos para estudo temos de sobra. Informações acessíveis sobre tudo. Software open-source e hardware open-source. De uma coisa tenho certeza. O futuro também será open-source. Me parece uma evolução natural. E você? Vai fazer parte deste futuro?

Um abraço,

Sergio Prado

Posts relacionados:

1. Kernel Linux 2.6.35

Sou fã confesso da Beagleboard. Na minha opinião, é hoje a melhor plataforma para se aprender Linux embarcado e trabalhar com software livre. Muitos projetos, boa documentação e custo acessível.

Já escrevi aqui alguns artigos sobre esta plataforma, e já trabalhei também em alguns projetos comerciais baseados nela. E quando fiquei sabendo do lançamento da Beaglebone, não pensei duas vezes em comprar. Um mês e meio depois (sim, ela ficou um bom tempo presa na alfândega!), cá estou eu e o Arthur com nosso novo brinquedinho!



A Beaglebone, assim como a Beagleboard, também é um projeto de hardware aberto, porém com um design um pouco mais simples, e consequentemente mais barato. É uma plataforma de prototipação, e nesse sentido tem objetivos bem parecidos com o Arduino, já que usa o conceito de shields (no caso da Beaglebone veremos que estas placas de expansão chamam-se capes). Mas ela não veio para substituir ou competir com o Arduino, muito menos com a Beagleboard ou com a Raspberry Pi — falaremos sobre isso mais adiante. Por hora, que tal darmos olhada no hardware?

HARDWARE

A Beaglebone é baseada no processador AM3359, um ARM Cortex-A8 da Texas Instruments que roda em até 720MHz, e possui 32K de cache L1, 256K de cache L2, 176K de ROM e 64K de RAM interna. Além disso, possui acelerador gráfico 3D, controlador LCD de 24 bits e controlador para a interface touchscreen.



A placa vem com 256MB de SDRAM, e assim como a Beagleboard-xM, não possui memória flash. Você precisa usar o cartão SD como unidade de armazenamento. Pode ser alimentada tanto por uma fonte externa quanto pela porta USB device. Esta mesma porta USB serve também de conexão serial (console), graças ao adaptador USB->Serial/JTAG incluido no design do hardware. Possui uma E2PROM de 32KB ligada ao barramento I2C, além das interfaces USB host, Ethernet, cartão SD/MMC e 4 leds que podem ser controlados pelo usuário.



O restante das interfaces de I/O estão disponíveis em 2 conectores de expansão de 46 pinos que podem fornecer diferentes conexões e barramentos como SPI, I2C, GPIO, LCD, HDMI, VGA, MMC, RS232, CAN, A/D, carregador de bateria, etc!

São nesses conectores que você pode plugar as placas de expansão, chamadas de capes. Cada beaglebone aceita até 4 capes, e cada cape deve ter uma E2PROM endereçável ligada ao barramento I2C, que vai ajudar o sistema operacional a identificá-la e configurar os I/Os de acordo.

Cape com saídas de áudio e vídeo

No momento em que escrevo este artigo, o preço da Beaglebone varia de $79 a $89 (FOB), dependendo do distribuidor e se você quer adquirir apenas a placa ou o kit completo. Convertendo para nossa moeda, e incluindo frete e impostos, deve sair em torno de R$350,00. A lista oficial de distribuidores encontra-se em http://beagleboard.org/buy.

O kit completo vem com a placa, um cabo USB e um cartão SD de 4G com a documentação e uma imagem do Angstrom pré-instalada.

E por falar em imagem, que tal colocar esta plaquinha pra funcionar?

SOFTWARE

Alimente a Beaglebone diretamente com o cabo USB, ou ligue uma fonte externa de 5V. O led de Power irá acender, e os leds USER0 e USER1 começarão a piscar. A Beaglebone será identificada na sua máquina de desenvolvimento como um dispositivo de armazenamento (como se fosse um pendrive). Você verá um dispositivo chamado BEAGLE_BONE com um monte de arquivos, incluindo as imagens do bootloader e do kernel, documentação e drivers para sistemas operacionais menos evoluidos :)

O primeiro passo é abrir o arquivo README.htm no seu navegador e dar uma lida. Este arquivo contém algumas orientações gerais sobre o funcionamento da Beaglebone.

Neste momento, a distribuição Angstrom que vem com a placa já esta rodando. E você pode acessá-la de algumas formas.

ACESSANDO VIA CONSOLE

Para acessar via console no Linux, você vai precisar inserir o modulo ftdi_sio, conforme abaixo:

$ sudo modprobe ftdi_sio vendor=0x0403 product=0xa6d0

Serão criados dois dispositivos tty (no meu caso foram criados o ttyUSB0 e o ttyUSB1). O segundo (ttyUSB1) é a console. Configure sua aplicação de terminal favorita com 115200 8N1 e teste o acesso à console:

U-Boot SPL 2011.09-00000-gf63b270-dirty (Nov 14 2011 - 10:37:14)
Texas Instruments Revision detection unimplemented
OMAP SD/MMC: 0
reading u-boot.img
reading u-boot.img
 
U-Boot 2011.09-00000-gf63b270-dirty (Nov 14 2011 - 10:37:14)
 
...
 
.---O---.                                           
|       |                  .-.           o o        
|   |   |-----.-----.-----.| |   .----..-----.-----.
|       |     | __  |  ---'| '--.|  .-'|     |     |
|   |   |  |  |     |---  ||  --'|  |  |  '  | | | |
'---'---'--'--'--.  |-----''----''--'  '-----'-'-'-'
                -'  |
                '---'
 
The Angstrom Distribution beaglebone ttyO0
 
Angstrom v2011.10-core - Kernel 3.1.0+
 
beaglebone login:

O usuário é root e a senha vazia.

Se você tiver problemas, ou estiver usando outro sistema operacional, o arquivo README.htm mencionado mais acima possui algumas instruções adicionais que podem ajudá-lo.

CONECTANDO VIA REDE

A Beaglebone tem um cliente DHCP rodando, então quando você ligá-la na sua rede (supondo-se que sua rede tenha um servidor DHCP), ela irá pegar um IP automaticamente.

Você pode consultar o IP atribuído à Beaglebone acessando-a via console, verificando o arquivo info.txt ou listando os logs do seu servidor DHCP.

Com a conexão de rede funcionando, você consegue acessar a Beaglebone por SSH (usuário root e sem senha):

$ ssh root@192.168.1.107
The authenticity of host '192.168.1.107 (192.168.1.107)' can't be established.
RSA key fingerprint is d6:67:cf:08:d0:87:12:d9:12:c9:37:d9:81:bd:aa:db.
Are you sure you want to continue connecting (yes/no)? yes
Warning: Permanently added '192.168.1.107' (RSA) to the list of known hosts.
root@192.168.1.107's password:
root@beaglebone:~#

A Beaglebone tem um servidor rodando na porta 80 que disponibiliza uma apresentação do projeto. Supondo que o IP da Beaglebone seja “192.168.0.7″, você consegue acessar este servidor simplesmente digitando no seu navegador “http:/192.168.0.7/”:


A Beaglebone tem também um outro servidor na porta 443 provendo acesso à console do equipamento via SSH de dentro do seu navegador! Supondo novamente que o IP da Beaglebone seja “192.168.0.7″, você consegue acessar este servidor digitando no seu navegador “https:/192.168.0.7/”. Obs: a Beaglebone usa o GateOne, um terminal e cliente SSH desenvolvido em HTML5. Portanto, você precisa de um navegador com suporte à HTML5.



Mas o mais legal mesmo é a IDE embarcada no dispositivo e que pode ser acessada pelo navegador na porta 3000. Supondo mais uma vez que o IP da Beaglebone seja “192.168.0.7″, você consegue acessar esta IDE digitando no seu navegador “http:/192.168.0.7:3000“


Esta IDE embarcada na Beaglebone é a Cloud9 IDE, uma interface que roda no seu navegador, e que possibilita escrever, executar e debugar aplicações escritas em JavaScript e baseadas em um framework chamado node.js.

O conceito é bem parecido com o do projeto mbed que recebeu um artigo um tempo atrás. Em ambos os projetos, a IDE roda no navegador. No caso do mbed, a IDE roda em um servidor na Internet. E no caso da Beaglebone, a IDE roda dentro dela mesmo!

E o que é esse tal de node.js? Segundo a página do projeto, o node.js é uma plataforma que roda em cima do V8 (engine de JavaScript do Google) desenvolvida para se construir aplicações de rede rápidas e escaláveis. Na prática, você escreve programas em JavaScript que são interpretados e executados dentro da Beaglebone por uma aplicação chamada “node”. Ou seja, você trabalha com uma linguagem de script, mais amigável e com bibliotecas prontas para interfacear com o hardware e com o sistema operacional.

Por exemplo, esta é uma aplicação escrita em node.js que faz o led USER3 da Beaglebone piscar:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20

var bb = require('./bonescript');
 
var ledPin = bone.P8_3;
var ledPin2 = bone.USR3;
 
setup = function() {
    pinMode(ledPin, OUTPUT);
    pinMode(ledPin2, OUTPUT);
};
 
loop = function() {
    digitalWrite(ledPin, HIGH);
    digitalWrite(ledPin2, HIGH);
    delay(1000);
    digitalWrite(ledPin, LOW);
    digitalWrite(ledPin2, LOW);
    delay(1000);
};
 
bb.run();

BEAGLEBONE X ARDUINO

A Beaglebone veio para preencher uma lacuna existente em desenvolvimento rápido e prototipagem para soluções high-end com Linux. Por esse motivo, não tem como deixar de fazer uma comparação com o Arduino. Ambos foram projetados com o conceito de expansão para facilitar a prototipagem: o Arduino com seus shields e a Beaglebone com seus capes. Ambos também possuem um ambiente de desenvolvimento que roda em qualquer SO, linguagem mais user-friendly, bibliotecas prontas, etc.

Mas não creio que seja uma questão de concorrência. O Arduino continuará sendo usado para acender leds, controlar motores e fazer seu robô andar. Agora, se você precisar de um sistema de reconhecimento facial dentro do seu robô, é aí que pode entrar a Beaglebone.

BEAGLEBONE X BEAGLEBOARD-XM

De forma alguma a Beaglebone é uma evolução da Beagleboard-xM. Muito pelo contrário, o hardware da Beagleboard-xM é melhor. Eles apenas são projetos com conceitos diferentes. Se você quer mais processamento, memória, portas USB e conexão de vídeo, vai de Beagleboard-xM. Já se o que você quer é um hardware fácil de expandir e de baixo custo, vai de Beaglebone.

BEAGLEBOARD X RASPBERRY PI

Também não faz sentido a comparação. O objetivo do projeto Raspberry Pi é o de ser um PC de baixo custo. Tá certo que, devido ao seu baixíssimo custo ($25 na versão normal e $35 na versão com Ethernet), muita gente vai querer tirar uma casquinha e até usar em algum projeto. Ou seja, se o que você precisa é de algo próximo à um computador pessoal (porta USB, saídas de áudio e vídeo) e de baixissimo custo, você pode pensar em usar a Raspberry Pi. Se você quer algo com mais capacidade de processamento, com diferentes interfaces de I/O e capacidade de expansão, pode pensar em usar a Beaglebone.

O negócio agora é esperar a evolução do projeto, as placas de expansão que serão lançadas (ainda não me acostumei com o nome “capes”), e se o uso do framework node.js em Linux embarcado vai se popularizar.

Enquanto isso, diz aí: o que você achou da Beaglebone? Tem intenção de comprá-la para usar em algum projeto?

Um abraço,

Sergio Prado

Sem posts relacionados.

Muito bem pessoal, chegou a hora de conhecer os 3 vencedores da promoção para ganhar o livro de RTOS da Micrium!

Primeiramente, gostaria de agradecer à todos pela participação. Recebi 85 respostas, e deu um pouco de trabalho corrigir tudo! :)

A maioria acertou pelo menos 3 dos 4 desafios, e 38 acertaram tudo. Dentre estas 38 pessoas, fiz o sorteio lá no http://www.random.org/.

Mas antes de dizer quem são os 3 felizardos, que tal darmos uma olhada novamente nos desafios?

DESAFIO 1

O desafio 1 dizia o seguinte:

O código abaixo tem um erro. Qual é este erro?

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21

#include <stdlib.h>
#include <stdio.h>
 
#define SIZE 15 
 
int main()
{
    int *a, i;
 
    a = malloc(SIZE*sizeof(int));
 
    for (i = 0; i < SIZE; i++)
        *(a + i) = i * i;
 
    for (i = 0; i < SIZE; i++)
        printf("%dn", *a++);
 
    free(a);
 
    return 0;
}

A maioria acertou este desafio. Na linha 10 alocamos uma região de memória e armazenamos o endereço no ponteiro “a”. Na linha 16 este ponteiro é alterado, e quando tentamos desalocá-lo na linha 18 teremos problemas na certa, já que o ponteiro “a” não armazena mais o endereço inicial retornado por malloc(). A solução aqui seria não alterar este ponteiro. O código abaixo resolve o problema:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21

#include <stdlib.h>
#include <stdio.h>
 
#define SIZE 15 
 
int main()
{
    int *a, i;
 
    a = malloc(SIZE*sizeof(int));
 
    for (i = 0; i < SIZE; i++)
        *(a + i) = i * i;
 
    for (i = 0; i < SIZE; i++)
        printf("%dn", *(a + i));  // CORREÇÃO
 
    free(a);
 
    return 0;
}

Algumas pessoas apontaram ainda que faltou checar o retorno da função malloc() e fazer o cast para (int *). É verdade! O cast é necessário principalmente se você tentar compilar em C++. Mas não considerei estes fatores para validar a resposta como certa.

DESAFIO 2

O desafio 2 dizia o seguinte:

O código abaixo tam­bém tem um erro. Qual?

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

#include <stdio.h>
 
int main()
{
    int* ptr1, ptr2;
 
    ptr1 = malloc(sizeof(int));
 
    ptr2 = ptr1;
 
    *ptr2 = 10;
 
    return 0;
}

A maioria também acertou este exercício. Uma coisa que aprendi deste quando comecei a estudar C é que devemos colocar o “*” sempre do lado do nome do ponteiro, e não do lado do tipo. No código acima, ptr2 é um inteiro, e não um ponteiro para inteiro como pretendiamos, causando erro na linha 11. Para corrigir este código, basta declarar ptr2 como ponteiro:

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

#include <stdio.h>
 
int main()
{
    int *ptr1, *ptr2;  // CORREÇÃO
 
    ptr1 = malloc(sizeof(int));
 
    ptr2 = ptr1;
 
    *ptr2 = 10;
 
    return 0;
}

Assim como no primeiro exercício, algumas pessoas também apontaram a ausência da checagem do retorno da função malloc() e do cast para (int *). Mas também não considerei estes fatores para validar a resposta como certa.

Outros falaram da ausência do free(). Sim, é sempre uma boa prática usar o free(), mas sua ausência nem sempre significa erro. No nosso caso, como a aplicação aloca e depois encerra, não teremos problema com memory leak pela ausência do free().

DESAFIO 3

O desafio 3 dizia o seguinte:

A função abaixo recebe um vetor de números inteiros e tem o obje­tivo de retornar o menor número inteiro deste vetor. Imple­mente esta função sem usar nen­hum oper­ador de com­para­ção! Ou seja, você não pode usar nen­hum destes oper­adores: “==”, “!=”, “>”, “<”, “>=”, “<=”.

1
2
3
4

unsigned int menor(unsigned int buf[], size_t size)
{
 
}

Aqui o bicho pegou! Este é o típico “exercício bombril”, que pode ser resolvido de 1001 maneiras. Recebi implementações de 5 linhas e outras de 50 linhas! :)

Esta é a minha sugestão de implementação:

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

unsigned int menor(unsigned int buf[], size_t size)
{
    unsigned int m = 0;
    int i;
 
    while(1) {
 
        for (i = size; i; i--) {
            if (!buf[i - 1]) return m;
            buf[i - 1]--;
        }
 
        m++;
    }
}

Eu faço uma varredura do vetor em um loop e decremento, um a um, cada elemento deste vetor. A quantidade de decrementos realizados é armazenada na variável “m”. Quando um dos elementos do vetor atingir o valor 0, significa que descobri qual era o elemento de menor valor dentro do vetor, e retorno este valor, que é exatamente a quantidade de decrementos realizada, armazenada na variável “m”.

Recebi algumas implementações que usavam esta lógica, mas também recebi outras implementações bem interessantes.

Achei bem legal esta implementação do Paulo Daniel:

1
2
3
4
5
6
7
8

unsigned int menor(unsigned int buf[], size_t size)
{
   unsigned int min = UINT_MAX;
   while(size) 
      if(!(buf[--size]/min))
         min = buf[size];
   return min;
}

Ele conseguiu resolver em 5 linhas, usando apenas uma operação de divisão de inteiros!

Atualização: Como bem observado pelos leitores Fernando Barboza e Уθя¡ςκ, esta implementação tem uma falha, já que existe o risco de divisão por 0 na linha 5. Mas a forma como o problema foi resolvido não deixa de ser bem interessante.

Já o Douglas Drumond preferiu escovar alguns bits e trabalhar com complemento de 2:

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

unsigned int menor(unsigned int buf[], size_t size)
{
    unsigned int shamt =  (sizeof(unsigned int) * 8 - 1);
    unsigned int mask = 0x01;
 
    size_t i = size - 1;
 
    unsigned int menor_item = buf[i];
    while (i--) {
        if(((buf[i] - menor_item) >> shamt) && mask) menor_item = buf[i];
    }
 
    return menor_item;
}

DESAFIO 4

Este desafio dizia o seguinte:

Escreva um pro­grama em C que imprima “Quero o meu livro!”, mas sem usar nen­hum ponto-e-vírgula no arquivo “.c”! Obs: o pro­grama deve com­pi­lar e fun­cionar nor­mal­mente.

A solução é bem simples:

1
2
3
4
5
6

#include <stdio.h>
 
void main()
{
    if (printf("Quero o livro!n")) {}
}

Você pode trocar o “if” pelo “while” também.

Teve gente que queria tanto o livro que colocou em um loop infinito! :)

1
2
3
4

void main()
{
    while(printf("Quero o meu livro!n")){}
}

Mas aqui o pessoal resolveu usar a criatividade. Como falei apenas que não podia usar “;” no arquivo “.c”, e não mencionei nada sobre o uso de arquivo “.h”, recebi respostas do tipo:

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

// Author: Celso
// imprime.c
#include <stdio.h>
#include <stdlib.h>
 
#include "imprime.h"
void main()
{
  IMPRIME
}
 
// imprime.h
#define IMPRIME   printf("Quero o meu livro!n");

Ou então trocando o “;” por um define passado pelo compilador:

1
2
3
4
5
6
7
8
9
10
11

/* Author: Fernando Martines
 *
 * Compilacao: gcc -DSPECIAL=";" desafio4.c -o desafio4
 */
#include <stdio.h>
 
int main()
{
    printf("Quero o meu livro!n") SPECIAL
    return 0 SPECIAL
}

Bom, gostei muito do resultado destes desafios. Aprendi bastante e espero que vocês tenham aprendido também. Afinal, o que importa é participar. Ganhar é só um detalhe, não é verdade? O quê? Não!? :)

OK, chega de enrolação, estes são os três participantes que acertaram os 4 desafios e foram sorteados para receber o livro:

• Rodrigo (a.k.a. Skhaz)
• Eduardo Vieira
• Rodolfo Pereira Araujo

Para aqueles que não ganharam, não desanimem! Vocês podem baixar gratuitamente o PDF do livro no site da Micrium aqui.

Ou então vocês podem esperar o próximo concurso. Eu havia falado que tinha 3 livros, não é verdade? Então… eu estava escondendo o jogo! :)

Na verdade, alem destes 3, tenho mais 1! E logo mais teremos um novo desafio por aqui. Mas desta vez não será tão fácil assim! :)

Um abraço!

Sergio Prado

Posts relacionados:

1. Quer ganhar o livro uC/OS-III The Real-Time Kernel?
2. Resultado do concurso para ganhar o convite VIP
3. Sistemas de Tempo Real — Parte 2

Quem é leitor assíduo do blog sabe que de vez em quando deixo de lado os bits e bytes do dia-a-dia para me meter em assuntos mais “analógicos” como atitudes, gestão de carreira e filosofia de vida.

Não que eu seja um especialista em psicologia comportamental, ou que tenha passado anos meditando com monges budistas, longe disso! :) Mas acredito que tenho um compromisso de compartilhar aquilo em que acredito com àqueles que acompanham o blog.

E já recebi de pessoas que me acompanham inúmeras mensagens e perguntas sobre como criar um blog. Sobre o que escrever? Que domínio escolher? Como e onde hospedar? Que ferramentas usar? Qual o melhor layout? E por aí vai…

Vou tentar responder todas estas perguntas, dentro daquilo que tenho experienciado nestes mais de dois de blog. Mas antes quero falar sobre algo fundamental. Algo o qual você precisa estar preparado. Porque tão importante quanto iniciar um projeto, é ter disciplina para mantê-lo.

POKE THE BOX

Recentemente li mais um ótimo livro do Seth Godin, chamado Poke the Box. O livro é sobre como tomar initiativas. Iniciar projetos. Mas é também sobre entregas. Finalizar projetos. E como se preparar para o que acontecer neste meio tempo.

O problema principal aqui é o medo. Medo de fracassar. As pessoas tem medo de fracassar. E lidam com isso de duas formas. 

Alguns vão ao extremo. Iniciam tantos projetos que não acabam nenhum. É um meio de fugir das responsabilidades. De arranjar desculpas para não terminar aquilo que começou.

Mas a maioria não inicia nenhum projeto, por medo de falhar. Afinal, começar algo maximiza as chances de fracasso. Na prática, o fracasso é o mesmo. Na verdade, pior, já que deixamos de aprender com os erros.

Portanto, se você quer começar seu blog. Simplesmente comece. Dê o primeiro passo.

OS PRIMEIROS PASSOS

Tomar a decisão é difícil. Executar é fácil. Crie uma conta no Blogger ou no WordPress. Em questão de minutos seu blog estará pronto para o primeiro post. Vai lá!

Mas sobre o que você quer escrever? Escreva sobre o que você gosta. Escreva sobre o que te motiva. E não invente. Os leitores são inteligentes. Por outro lado, também não tenha medo de expressar sua opinião. É ela que faz a diferença.

PEDE PRA SAIR!?

Depois de alguns posts você começará a ouvir dentro de sua cabeça a voz do Capitão Nascimento: “Pede pra sair!”.

Você esta disposto a investir horas por semana para escrever um post de qualidade? Porque você vai começar a reclamar de falta de tempo (seria prioridade?) para escrever no blog.

Esteja preparado também para enfrentar opiniões divergentes dos leitores. Você vai precisar ter jogo de cintura. Aprender a “ouvir” diferentes pontos de vista. Assumir seus erros e bola pra frente. Mas aproveita. Você vai aprender bastante, eu garanto.

PORQUE COMPARTILHAR?

Simplesmente pelo fato de que você tem o que compartilhar. E porque vai contribuir com sua própria experiência. E com seu próprio aprendizado. E também porque se você não o fizer, quer goste ou não, esta tirando algo de todos nós. Algo que só você sabe. E que poderia estar fazendo a diferença para muita gente.

MAIS ALGUNS DETALHES

Conforme você mantém a disciplina e a regularidade na publicação de conteúdo, a quantidade de leitores irá crescer, e você vai querer migrar para seu próprio domínio.

Mas qual dominio usar? Use seu nome, um apelido ou algum nome abstrato. Hospedagem? Eu uso o GoDaddy, mas existem muitos outros por aí. Layout? Prefira algo limpo, que facilite a leitura. Propagandas? Evite ao máximo. Ou use em lugares que não atrapalhem a leitura dos posts.

Mas não se preocupe com isso. São apenas alguns “detalhes”. Difícil mesmo é dar o passo inicial. E depois continuar andando.

Portanto, dedique-se à pratica de iniciar projetos. Frequentemente. E sempre. Esqueça a idéia de que existe um mapa pronto, e que você precisa seguir este mapa. Desenhe seu próprio mapa. Siga-o. E mude a rota quando necessário. Faça a diferença.

“There are two mistakes one can make along the road to truth. Not going all the way, and not starting.” Siddhartha Gautama

E aí, pronto pra compartilhar?

Um abraço,

Sergio Prado

Sem posts relacionados.

Como vocês podem ver, tenho aqui comigo algumas cópias de capa-dura do livro sobre o novíssimo uC/OS-III da Micrium!

Arthur esta louco para começar a usar o uC/OS-III no seu ARM Cortex-M3!

O livro é muito bom, extremamente didático, fácil de acompanhar e entender. Traz os conceitos principais de sistemas operacionais de tempo real como o escalonador de tarefas, tratamento de interrupções, mecanismos de sincronização, comunicação entre tarefas, etc. São 820 páginas de muito RTOS na veia!

Os livros foram gentilmente doados pela NXP para serem sorteados aqui no blog. Mas é claro que não vai ser tão fácil assim! :)

Se você quer receber este livro no conforto da sua casa (frete por minha conta para qualquer lugar do Brasil) precisa resolver os 4 desafios abaixo.

Cada desafio vale um ponto. As 3 (três) pessoas que pontuarem melhor levarão um livro para casa. Se houver empate, farei um sorteio. O concurso vale até o dia 24/01/2012 às 23:59.

Mandem as respostas para contato@sergioprado.org com o assunto “Concurso livro Micrium”.

Atualização: O concurso esta encerrado. O resultado foi publicado aqui.

DESAFIO 1

O código abaixo tem um erro. Qual é este erro?

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21

#include <stdlib.h>
#include <stdio.h>
 
#define SIZE 15 
 
int main()
{
    int *a, i;
 
    a = malloc(SIZE*sizeof(int));
 
    for (i = 0; i < SIZE; i++)
        *(a + i) = i * i;
 
    for (i = 0; i < SIZE; i++)
        printf("%d\n", *a++);
 
    free(a);
 
    return 0;
}

DESAFIO 2

O código abaixo também tem um erro. Qual?

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

#include <stdio.h>
 
int main()
{
    int* ptr1, ptr2;
 
    ptr1 = malloc(sizeof(int));
 
    ptr2 = ptr1;
 
    *ptr2 = 10;
 
    return 0;
}

DESAFIO 3

A função abaixo recebe um vetor de números inteiros e tem o objetivo de retornar o menor número inteiro deste vetor. Implemente esta função sem usar nenhum operador de comparação! Ou seja, você não pode usar nenhum destes operadores: “==”, “!=”, “>”, “<”, “>=”, “<=”.

1
2
3
4

unsigned int menor(unsigned int buf[], size_t size)
{
 
}

DESAFIO 4

Escreva um programa em C que imprima “Quero o meu livro!”, mas sem usar nenhum ponto-e-vírgula no arquivo “.c”! Obs: o programa deve compilar e funcionar normalmente.

Um abraço e boa sorte!

Sergio Prado

Posts relacionados:

1. Quer ganhar um convite VIP para o Seminário Linux Embarcado 2011?
2. Sistemas de Tempo Real — Parte 2

Neste artigo irei responder uma pergunta que recebo frequentemente no blog e no dia-a-dia do trabalho que realizo na minha empresa:

“Sergio, como faço para configurar um ambiente de desenvolvimento de aplicações para Linux embarcado?”

A resposta? Mais fácil do que você imagina.

Existem algumas ferramentas de ambiente de desenvolvimento integrado (IDE) disponíveis para quem trabalha com Linux, dentre elas o KDevelop e o Eclipse.

Eu particularmente gosto bastante do KDevelop, mas o Eclipse é definitivamente a IDE open-source mais popular do mercado. E aqui nós iremos aprender a configurá-la como ambiente de desenvolvimento para Linux embarcado.

HISTÓRICO

No fim da década de 90, a IBM iniciou o desenvolvimento do Eclipse, inicialmente como um ambiente de desenvolvimento para a linguagem Java. Em 2001, para alavancar o desenvolvimento do projeto, a IBM doou o código para a comunidade de software livre. E em 2004, foi criada a Fundação Eclipse. Desde então, o projeto evoluiu bastante, e hoje ele esta bem maduro para ser utilizado em projetos de diferentes propósitos.

Mas Sergio, o que vou fazer com um ambiente de desenvolvimento para Java se irei programar em C?

É aí que esta o segredo do Eclipse. Sua arquitetura baseada em plugins possibilitou a expansão das suas funcionalidades, como por exemplo a adição de um editor C/C++.

Então algumas empresas começaram a pensar: porque vou criar um ambiente de desenvolvimento do zero, se posso pegar uma ferramenta pronta, madura e funcional, e apenas adaptá-la ao meu produto?

Daí surgiram muitas ferramentas de desenvolvimento baseadas no Eclipse. Quer alguns exemplos?

• DevRocket da Montavista.
  
• TimeStorm da Timesys
  
• Sourcery CodeBench da Mentor Graphics
  
• LPCXpresso’s IDE da Code Red (para uCs da NXP)
  
• AVR32 Studio 2.6 da Atmel
  
• E por aí vai!

PORQUE UMA IDE? PORQUE O ECLIPSE?

Dependendo do tamanho e da complexidade do seu projeto, você vai precisar de uma ferramenta para agilizar seu trabalho. Em se tratando de Linux embarcado, uma IDE pode te ajudar bastante, principalmente se tiver:

1. Um bom editor de código-fonte, com suporte a highlighting de sintaxe, auto-complete de código e navegação entre os objetos do projeto (funções, estruturas, variáveis, etc).
   
2. Um gerenciador de build do projeto para gerar automaticamente o arquivo de build a partir do código-fonte.
3. Um debugger decente.
4. Um mecanismo de gerenciamento remoto do dispositivo alvo (seu produto, kit de desenvolvimento, etc).
   

Conseguimos tudo isso (e muito mais) através do Eclipse e de dois plugins, o CDT (C/C++ Development Toolkit) e o RSE (Remote Systems Explorer).

E configurar este ambiente nao tem muito segredo.

INSTALANDO

A versão mais atual do Eclipse no momento em que escrevo este artigo é a Eclipse Indigo. É ela que utilizaremos para nossos testes.

Pela página de downloads você pode baixar a ferramenta em diferentes “sabores” (IDE para java, java EE, javaScript, modelagem de dados, testes de software, etc).

Nós queremos a versão com suporte a C/C++ para Linux: Eclipse IDE for C/C++ Linux Developers. Nesta versão já estão empacotados todos os plugins que mencionei acima.

Você pode executar os comandos abaixo para baixar, instalar e executar o eclipse:

$ wget http://eclipse.c3sl.ufpr.br/technology/epp/downloads/release/indigo/SR1/eclipse-linuxtools-indigo-SR1-incubation-linux-gtk.tar.gz
$ tar zxfv eclipse-linuxtools-indigo-SR1-incubation-linux-gtk.tar.gz
$ cd eclipse/
$ ./eclipse

Agora vamos começar a configurar a ferramenta, começando pelo Remote System Explorer.

TESTANDO E USANDO O RSE

O RSE (Remote System Explorer) é uma ferramenta que vai possibilitar o acesso e gerenciamento remoto do hardware. Através de uma conexão remota via rede com o dispositivo, você poderá manipular o sistema de arquivos, copiar/remover/editar arquivos, obter acesso ao shell, tudo pela interface do Eclipse!

Para começar, abra a perspectiva do RSE em “Window->Open Perspective->Other->Remote System Explorer”.

À sua esquerda vai aparecer uma janela com as conexões disponíveis. Por padrão, a única conexão disponível é uma local com o sistema de arquivos da sua máquina de desenvolvimento:

Vamos criar agora uma conexão remota via SSH com o equipamento. Esta configuração exige que seu equipamento esteja conectado em rede com sua máquina de desenvolvimento.

1. Clique com o botão direito na janela à esquerda que contém as conexões disponíveis e selecione “New->Connection”.
2. Selecione “SSH Only” e clique em “Next”.
3. Digite o IP do equipamento no campo “Host name” e um nome que você quer dar para a conexão no campo “Connection name”.
4. Clique em “Finish”.

Uma outra conexão com o nome que você configurou aparecerá à esquerda. Clique com o botão direito nela, selecione “Connect”, digite e usuário e senha, e pronto! Se você não receber nenhuma mensagem de erro, seu acesso remoto esta configurado e funcionando. Com ele você terá acesso ao shell do equipamento via SSH. Mas o mais interessante é o acesso remoto ao rootfs do equipamento:

Facilita bastante nosso trabalho quando precisamos navegar pelo rootfs do equipamento e alterar algum arquivo, não é verdade?

Obs: Esta conexão criada exige um servidor SSH com suporte à SFTP instalado no equipamento. O OpenSSH serve bem para este propósito, mas em alguns casos ele é grande demais para ser embarcado no dispositivo. Então você pode usar o Dropbear e um outro servidor SFTP. Você pode também querer usar o FTP ao invés do SFTP. Neste caso, você vai precisar criar no Eclipse duas conexões, uma para o SSH e outra para o FTP.

CROSS-COMPILANDO UMA APLICAÇÃO

Cross-compilar uma aplicação no Eclipse é muito simples, basta ter um toolchain configurado para a sua plataforma. Você pode baixar um toolchain pronto ou gerar seu próprio toolchain.

Escrevi dois artigos que podem te ajudar a entender o que são e como gerar toolchains para o seu equipamento. Se você quer entender o que são toolchains clique aqui e se quiser saber com gerar um toolchain clique aqui.

Agora vamos criar um projeto no Eclipse preparado para cross-compilar uma aplicação para seu equipamento:

1. Vá para a perspectiva C/C++ em “Window->Open Perspective->C/C++”.
2. Crie um novo projeto em “File->New->C Project”.
3. Dê um nome ao seu projeto, selecione a opção “Executable->Cross-Compile Project” e clique em “Next”.
4. Agora vem o segredo: precisamos configurar o toolchain. Na opção “Tool command prefix” configure o prefixo das ferramentas do toolchain, e na opção “Tool command path” configure o diretório onde se encontram as ferramentas do toolchain. A minha configuração ficou assim:
   
   
   
   
5. Clique em “Finish”.

Crie uma aplicação simples para testar (File->New->Source File):

/*
 * hello.c
 *
 *  Created on: Dec 30, 2011
 *      Author: sprado
 */
 
#include "stdio.h"
 
int sum(unsigned char a, unsigned char b)
{
    return a + b;
}
 
int main()
{
    printf("Hello Embedded World! Sum = %d\n", soma(1, 1));
 
    return 0;
}

Agora é só compilar em “Project->Build Project” e pronto! Para testar, abra novamente a perspectiva Remote System Explorer e arraste o binário gerado da pasta do projeto do Eclipse para o target através da conexão SFTP. Teste abrindo um terminal via SSH. Assim fica fácil, não é verdade? :)

DEBUGGING REMOTO

Que tal agora debugar remotamente a aplicação rodando no dispositivo?

1. Acesse “Run->Debug Configurations”.
2. Clique duas vezes em “C/C++ Remote aplications”
3. No campo “Connection”, selecione o nome da conexão remota que você criou com o Remote System Explorer.
4. Configure o caminho completo onde será salva a aplicação no target, incluindo o nome da aplicação, no campo “Remote Absolute File Path”.

Por último, configure na aba “Debugger” o nome da ferramenta de debugging do seu toolchain, e salve:

Agora é só clicar no inseto verde!

Nunca foi tão fácil configurar debugging remoto em Linux embarcado, não é verdade? :)

O que mostrei neste artigo foi apenas o básico da configuração do Eclipse para iniciar o desenvolvimento em Linux embarcado. Esta IDE é cheia de plugins e funcionalidades interessantes. Vale a pena dar uma olhada, estudar, testar.

Para aqueles que se aventurarem, ou já tiveram experiências com o Eclipse (boas ou ruins), deixem seus comentários aqui!

Um abraço,

Sergio Prado

Posts relacionados:

1. Gerando e usando toolchains em Linux embarcado

O kit de desenvolvimento LPC3250 da Embedded Artists vem equipado com o microcontrolador LPC3250 da NXP, e pode ser uma boa escolha se você quer boa performance, alto nível de integração de periféricos e baixo consumo.

Se sua aplicação precisa de uma capacidade de processamento maior do que a oferecida pelas CPUs ARM Cortex-M3, com necessidades de display gráfico e conectividade, mas não quer uma solução tão high-end como as linhas i.MX da Freescale ou Sitara da TI, talvez o LPC3250 seja o que você procura.

O kit é composto basicamente por uma placa com CPU e memória RAM/Flash (LPC3250 OEM Board) conectada à uma placa-base (QVGA Base Board), com o display e um conjunto de periféricos para acesso.

O microcontrolador LPC3250 é um ARM9 rodando à 266MHz com 256kB de SRAM, interface para flash NAND e barramento para SDRAM, Ethernet MAC e um controlador de display LCD integrados, além de diversas interfaces de comunicação como USB, UART, I2C, SPI, I2S, PWM, ADC, etc.

O kit vêm com 128MB de flash NAND, 4MB de flash NOR e 64MB de SDRAM. Pode ser alimentado por USB ou uma fonte externa de 9-15V. Possui interfaces Ethernet, USB host/OTG, cartão SD/MMC, display LCD de 3.2″, JTAG, RS232, IrDA, acelerômetro, E2PROM, botões, leds e conectores para expansão de I/O.

O manual do usuário pode ser baixado aqui e o datasheet aqui.

O kit pode ser adquirido no site da Embedded Artists por $340 FOB (no momento em que escrevo este artigo), ou em um de seus distribuidores como a Digi-Key, a Future Electronics e a Mouser. No Brasil, a Microgenios é a distribuidora oficial da Embedded Artists.

LINUX

Com MMU e boa capacidade de memória (Flash e RAM), conectividade e interface com displays gráficos, o kit é uma boa plataforma para se trabalhar com Linux.

A comunidade Linux para os microcontroladores da NXP gira em torno do site http://www.lpclinux.com, com seções de download, tutoriais, blogs, forums, etc.

PROCESSO DE BOOT

O microcontrolador LPC3250 possui uma ROM interna de 32K com um código de boot que é executado sempre que você liga o equipamento. Este código de boot procura por um bootloader em 4 diferentes fontes: UART, SPI, NOR e NAND.

Quando você liga o equipamento, este código de boot em ROM verifica a entrada SERVICE (GPI_1) do microcontrolador. Se esta entrada estiver em nível baixo, o codigo de boot inicia um processo de recuperação para baixar um programa pela UART e carregá-lo para a SRAM. Se esta entrada estiver em nível alto, ele irá procurar por um bootloader nas seguintes interfaces, nesta ordem: SPI, NOR e NAND. Se ele encontrar, irá carregar os primeiros 54kB para a SRAM.

Este código carregado para a SRAM é o bootloader de 1o. estágio, chamado de Kickstarter, responsável basicamente por carregar e iniciar um bootloader de 2o. estágio, o S1L. Este bootloader de 2o. estágio é o responsável por inicializar o hardware (GPIO, clock, SDRAM, etc) e carregar o bootloader de 3o. estágio, o U-Boot. Ufa!

Daí é o processo normal de qualquer sistema Linux embarcado, o U-Boot carrega o kernel e então temos nosso sistema Linux rodando no kit.

USANDO O KIT

Para usar o kit, basta alimentá-lo com o cabo USB, conforme figura abaixo:

Você só vai precisar de uma fonte externa se for ligar dispositivos de consumo alto no barramento USB.

Como a placa possui o chip FT232 da FTDI, ao mesmo tempo que o cabo USB serve para alimentar o kit, ele será sua conexão serial (console) com o equipamento!

Configure seu programa de comunicação serial preferido com 115200-8N1, ligue o kit na sua máquina de desenvolvimento pelo cabo USB, e veja o menu do bootloader de 2o. estágio (S1L):

Embedded Artist 3250 Board (S1L 2.0)
Build date: Nov 23 2010 13:21:19
 
EA3250#

Com este bootloader você é capaz de bootar do cartão SD, da UART ou da NAND Flash. Mas é claro que você vai querer bootar o Linux, não é verdade? Então você vai precisar gravar o U-Boot na flash NAND.

Você pode baixar o u-boot daqui, renomeá-lo para u-boot.bin e salvá-lo em um cartão SD.

Coloque o cartão SD no kit, reinicie-o e na linha de comandos do bootloader S1L, carregue o U-Boot do cartão SD para a RAM:

EA3250# load blk u-boot.bin raw 0x83fa0000

Salve na flash:

EA3250# nsave

E configure o bootloader S1L para automaticamente carregar o U-Boot no boot do equipamento:

EA3250# aboot flash raw 0x83fa0000

Configure também um delay de 2 segundos no boot do S1L:

EA3250# prompt EA3250# 2

Reinicie e pronto! Você receberá o prompt do U-Boot no terminal:

Embedded Artist 3250 Board (S1L 2.0)
Build date: Nov 23 2010 13:21:19
Autoboot in progress, press any key to stop
 
U-Boot 2009.03-rc1 (Sep 28 2009 - 09:38:20)
 
DRAM:  64 MB
NAND:  128 MiB
*** Warning - bad CRC or NAND, using default environment
 
In:    serial
Out:   serial
Err:   serial
Hit any key to stop autoboot:  0
uboot#

TREINAMENTO

Este é o kit que utilizarei nas minhas primeiras seções do treinamento de Linux embarcado. Os kits foram gentilmente cedidos pela NXP para a realização do treinamento.

Busquei desenvolver uma metodologia de ensino de forma que as atividades de laboratório fossem independentes de hardware. Nada de receitas de bolo. O que você aprender com este kit, poderá aplicar em qualquer outro hardware com suporte à Linux. Mas espero que possamos nos divertir bastante com este kit, desenvolver alguns projetos legais durante (e depois) do treinamento, e claro, aprender Linux embarcado!

Para quem já se inscreveu, vejo vocês lá!

Um abraço!

Sergio Prado

Posts relacionados:

1. Kit de desenvolvimento FriendlyARM mini2440
2. Linux embarcado com o SAM9M10 da Atmel

A idéia de escrever este artigo surgiu da necessidade de um projeto que trabalhei algumas semanas atrás.

O objetivo era implementar um teclado virtual, de forma que um processo ou aplicação pudesse simular o pressionamento de uma tecla, sem que esta tecla tivesse sido realmente pressionada em um teclado físico.

Até aí tudo bem, qualquer biblioteca ou toolkit gráfico decente (X11, DirectFB, Qt, etc) possui algum mecanismo para emular entrada de teclado. Mas o objetivo era ser independente de biblioteca gráfica, e funcionar também em ambiente somente texto. Ou seja, precisavamos de algo implementado dentro do kernel.

Mas não vamos “colocar a carroça na frente dos bois”! Antes de pensar na solução, vamos pensar no problema…

PURA MÁGICA?

Não, não é mágica. Mas uma tecla pressionada dentro do kernel do Linux passa por algumas camadas até você vê-la ecoando na tela do seu monitor.

CAMADA 0: HARDWARE

Tudo começa no hardware, claro. A controladora do teclado conectado ao seu PC varre e decodifica a matriz de teclas e cuida de detalhes como o controle de debouncing.

Quando você pressiona uma tecla, essa tecla é transformada em um código chamado de scancode. Cada tecla possui um scancode quando é pressionada e outro quando é liberada (o bit mais significativo é setado). Por exemplo, a letra ‘x’ emite o scancode 0x2d quando é pressionada e 0xad quando é liberada (no meu teclado USB).

Se você quiser, pode usar a ferramenta “showkey” para fazer o dump e exibir o scancode das teclas pressionadas no seu PC:

$ sudo showkey -s
press any key (program terminates 10s after last keypress)...
0x2d 0xad

Portanto, para cada tecla pressionada, uma interrupção é gerada para a CPU, e os scancodes são enviados via barramento de comunicação, dependendo do hardware do seu teclado (PS2, USB, etc).

Logo após, a rotina de tratamento de interrupção do teclado é acionada, sendo responsável por receber e tratar estes scancodes, conforme veremos a seguir.

CAMADA 1: DEVICE DRIVER

Aqui já estamos no kernel do Linux. Um device driver vai conversar com o hardware do seu teclado, receber e tratar os scancodes.

E dependendo do hardware que você esta usando (teclado USB, PS2, etc), um diferente device driver será o responsável por ler estes scancodes. Por exemplo, a implementação do teclado PS2 padrão encontra-se nos fontes do kernel em drivers/input/keyboard/atkbd.c. Vai lá dar uma olhada, eu espero!

Após ler os scancodes, o device driver irá convertê-los em um outro código chamado keycodes. Cuidado para não confundir! Scancode é um código dependente do hardware do teclado e tratado pelo device driver. Keycode é um código que representa uma tecla dentro de um sistema Linux.

Você já viu que cada tecla pressionada gera dois scancodes (pressionada e liberada). Mas ela possui um único keycode. Por exemplo, no meu PC, quando pressiono a tecla ‘x’, é gerado o keycode 45:

$ sudo showkey -k
press any key (program terminates 10s after last keypress)...
keycode  45 press
keycode  45 release

Mas como então o kernel diferencia teclas pressionadas e liberadas se o keycode é o mesmo? Fácil. O device driver gera dois eventos para o kernel. Um para teclas pressionadas e outro para teclas liberadas. E estes eventos são enviados para camada input do kernel.

CAMADA 2: INPUT SUBSYSTEM

É nesta camada que percebemos toda a capacidade de modularização do kernel do Linux. 

A camada input foi criada para abstrair a captura de eventos de dispositivos de entrada como mouse, teclado, joysticks, touch screens, etc. Enquanto que cada um destes dispositivos possui seu respectivo device driver, cada device driver exporta os eventos para a camada input. Por sua vez, a camada input trata e exporta estes eventos em um formato padrão para arquivos de dispositivo em /dev/input/:

$ ls /dev/input
event0  event1  event2  event3  event4  event5  mice  mouse0

Cada um destes arquivos de dispositivo representam um dispositivo de entrada.

Você pode usar a ferramenta “evtest” para verificar qual o dispositivo relacionado à determinado arquivo:

$ sudo evtest /dev/input/event4
Input driver version is 1.0.1
Input device ID: bus 0x3 vendor 0x1c4f product 0x2 version 0x110
Input device name: "USB USB Keykoard"
...

Veja que, na minha máquina, /dev/input/event4 é o arquivo de dispositivo que gera os eventos do teclado USB.

A ferramenta “evtest” também é capaz de monitorar os eventos de dispositivos de entrada. Execute novamente o comando acima, pressione uma tecla e veja os eventos que foram exportados para userspace através deste arquivo de dispositivo:

...
Event: time 1323720735.849223, type 1 (Key), code 45 (X), value 1
Event: time 1323720735.849225, -------------- Report Sync ------------
Event: time 1323720735.905222, type 1 (Key), code 45 (X), value 0
Event: time 1323720776.880210, -------------- Report Sync ------------
...

Perceba o keycode 45 para a tecla ‘x’ e os valores 1 para tecla pressionada e 0 para tecla liberada.

Por fim, as bibliotecas gráficas monitoram os eventos nestes arquivos de dispositivos e exportam estes eventos para as aplicações. E assim você vê uma tecla ecoando em seu terminal!

Linux é ou não é um dos SOMLTT — sistemas operacionais mais legais de todos os tempos? :-)

Apenas um detalhe aqui: no caso do teclado, além de exportar os eventos para “/dev/input/”, a camada input também exporta os eventos de teclas pressionadas para a camada TTY ativa no momento. Desta forma, se você estiver em um terminal conectado à /dev/tty2, por exemplo, irá receber este evento. Se quiser saber mais sobre a camada TTY, leia o artigo “Por dentro da console em sistemas Linux”.

VOLTANDO AO NOSSO PROBLEMA…

Depois de todas estas explicações, espero que você não tenha se esquecido do nosso problema original: emular um teclado virtual independente de biblioteca gráfica, e que funcione em modo texto.

Agora ficou mais fácil pensar numa solução, não é verdade?

Reveja as camadas. A camada 0 é hardware, e não temos hardware no nosso caso. A camada 2 é genérica, e não é uma boa prática mexer nela. Potanto, é na camada 1 que trabalharemos.

Vamos desenvolver um device driver (no nosso caso, um módulo do kernel, já que não falaremos com nenhum hardware) que irá gerar eventos de teclado para a camada input. Simples assim!

A SOLUÇÃO

Para não complicar muito, vamos escrever um modulo simples que irá emular a digitação de uma frase a cada 10 segundos. Assim que carregado, uma frase será “digitada” pelo módulo a cada 10 segundos. E para deixar o trabalho mais divertido, a frase será “segmentation fault”!

Sem mais enrolação, este é o código completo do nosso módulo do kernel:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96

#include "linux/fs.h"
#include "linux/cdev.h"
#include "linux/module.h"
#include "linux/kernel.h"
#include "linux/delay.h"
#include "linux/kthread.h"
#include "linux/device.h"
#include "linux/slab.h"
#include "linux/tty.h"
#include "linux/tty_flip.h"
#include "linux/kbd_kern.h"
#include "linux/input.h"
 
/* vtkbd kernel thread struct */
static struct task_struct *vtkbd_thread_task;
 
/* vtkbd input device structure */
static struct input_dev *vtkbd_input_dev;
 
const char str_keys[] = { KEY_S, KEY_E, KEY_G, KEY_M, KEY_E, KEY_N,
                          KEY_T, KEY_A, KEY_T, KEY_I, KEY_O, KEY_N,
                          KEY_SPACE, KEY_F, KEY_A, KEY_U, KEY_L,
                          KEY_T, KEY_ENTER };
 
/* kernel thread */
static int vtkbd_thread(void *unused)
{
    int i;
 
    while (!kthread_should_stop()) {
 
        for (i = 0; i < sizeof(str_keys); i++) {
 
            input_report_key(vtkbd_input_dev, str_keys[i], 1);
            input_report_key(vtkbd_input_dev, str_keys[i], 0);
            input_sync(vtkbd_input_dev);
 
        }
 
        /* wait 10 seconds */
        msleep(10000);
    }
 
    return(0);
}
 
/* driver initialization */
static int __init vtkbd_init(void)
{
    static const char *name = "Virtual Keyboard";
    int i;
 
    /* allocate input device */
    vtkbd_input_dev = input_allocate_device();
    if (!vtkbd_input_dev) {
        printk("vtkbd_init: Error on input_allocate_device!\n");
        return -ENOMEM;
    }
 
    /* set input device name */
    vtkbd_input_dev->name = name;
 
    /* enable key events */
    set_bit(EV_KEY, vtkbd_input_dev->evbit);
    for (i = 0; i < 256; i++)
        set_bit(i, vtkbd_input_dev->keybit);
 
    /* register input device */
    input_register_device(vtkbd_input_dev);
 
    /* start thread */
    vtkbd_thread_task = kthread_run(vtkbd_thread, NULL, "%s", "vtkbd_thread");
 
    printk("Virtual Keyboard driver initialized.\n");
 
    return 0;
}
 
/* driver exit */
void __exit vtkbd_exit(void)
{
    /* stop thread */
    kthread_stop(vtkbd_thread_task);
 
    /* unregister input device */
    input_unregister_device(vtkbd_input_dev);
 
    printk("Virtual Keyboard driver.\n");
}
 
module_init(vtkbd_init);
module_exit(vtkbd_exit);
 
MODULE_LICENSE("GPL");
MODULE_AUTHOR("Sergio Prado sergio.prado@embeddedlabworks.com");
MODULE_DESCRIPTION("Virtual Keyboard driver");

O módulo tem basicamente 3 funções: vtkbd_init() para inicializar o módulo, vtkbd_exit() para fazer a limpeza ao descarregar o módulo e vtkbd_thread() que faz a mágica de digitar a frase periodicamente.

Na função de inicialização, o primeiro passo é alocar um dispositivo de input com a função input_allocate_device() na linha 54. Essa função vai devolver uma estrutura que vai nos possibilitar conversar com a camada input e gerar os eventos de teclado. Nas linhas 64 a 66 habilitamos a geração de eventos em todas as teclas (veja o loop) e na linha 69 registramos o dispositivo de input com a função input_register_device(). Por último, criamos e iniciamos a thread do kernel que irá fazer o “trabalho sujo”. Se você quiser ler mais sobre Kernel Threads, leia o artigo “Linux Device Drivers — Trabalhando com Kernel Threads”

Na função de limpeza, paramos a thread e removemos o dispositivo de input que registramos na inicialização.

A thread vtkbd_thread() é bem simples e faz toda a mágica. Ela é basicamente um loop infinito que, a cada 10 segundos, gera os eventos para emular a digitação. O vetor str_keys[] contém os keycodes para a frase “segmentation fault”. Esses keycodes estão definidos em include/linux/input.h. Para cada keycode, geramos dois eventos com a função input_report_key(), simulando a tecla pressionada na linha 34 e a tecla liberada na linha 35 (veja os parâmetros 1 e 0, respectivamente). Por último, executamos a função input_sync(), notificando a camada input da existência de novos eventos a serem tratados.

Simples, não?

Para compilar, crie um Makefile com o conteúdo abaixo:

KVER := $(shell uname -r)
KDIR := /usr/src/linux-headers-$(KVER)
PWD  := $(shell pwd)
 
obj-m += vtkbd.o
 
default:
        $(MAKE) -C $(KDIR) SUBDIRS=$(PWD) modules
 
clean:
        @rm -Rf *.o *.ko *.mod.c modules.order Module.symvers Module.markers

E compile:

$ make

Para carregar o módulo:

$ sudo insmod vtkbd.ko

E para remover o módulo:

$ sudo rmmod vtkbd

Como o módulo ficará digitando “segmentation fault” a cada 10 segundos, este é o tempo que você terá para digitar o comando de remoção do módulo antes dele bagunçar seu shell!

E lembre-se de que você esta trabalhando em kernel space, com acesso total e irrestrito à memória e I/Os. Portanto, o ideal aqui é trabalhar em uma máquina virtual. É mais seguro e pode evitar muitos acidentes, principalmente para aqueles que estão começando os estudos do Kernel do Linux.

PEGADINHA DO MALANDRO

Agora pegue este módulo, e quando seu amigo deixar a seção aberta para tomar um café, instale e cronometre o tempo que ele vai levar para encontrar a causa do “segmentation fault”! Isso se ele encontrar… :)

Um abraço,

Sergio Prado

Posts relacionados:

1. Linux Device Drivers — Parte 1
2. Linux Device Drivers — Parte 2
3. Por dentro da console em sistemas Linux

Vocês pediram, e depois de bastante trabalho e esforço, estou abrindo a primeira turma do treinamento “Desenvolvendo Sistemas Linux Embarcado”, que será realizado em 3 sábados consecutivos a partir do dia 28 de janeiro de 2012.

A idéia do treinamento é capacitá-los a desenvolver e customizar uma distribuição Linux embarcada completa, de forma que possam chegar em casa e ter os conhecimentos necessários para embarcar Linux em qualquer hardware.

Para quem ainda não teve a oportunidade de ler, o conteúdo do treinamento inclui:

• Enten­der, con­fig­u­rar e gerar seu próprio tool­chain para cross-compilação.
• Con­fig­u­rar e com­pi­lar o Boot­loader para o kit de desenvolvimento.
• Estu­dar, con­fig­u­rar e com­pi­lar um ker­nel Linux cus­tomizado para o kit de desenvolvimento.
• Com­pi­lar e tes­tar módu­los do kernel.
• Criar um rootfs do zero usando ape­nas pacotes de soft­ware aberto e livre.
• Desen­volver usando um servi­dor NFS.
• Gravar ima­gens na memória flash e no cartão SD do kit de desenvolvimento.
• Enten­der e usar os difer­entes tipos de sis­tema de arquivo para memória flash e dis­pos­i­tivos de bloco.
• Usar o Buil­d­root como sis­tema de build para autom­a­ti­zar a ger­ação de um sis­tema Linux completo.
• Enten­der licenças de soft­ware e apren­der a aplicar patches.
• Desen­volver e cross-compilar apli­cações para Linux embarcado.
• Desen­volver apli­cações bási­cas com Qt em Linux embarcado.
• Debugar apli­cações com GDB, strace e ltrace.
• Desen­volver um pro­jeto com­pleto de Linux embar­cado (qual­quer pro­jeto, use sua imaginação!).

O investimento será de R$700,00 por participante. Fiz bastante esforço para chegar neste valor, que acredito ser razoável e acessível.

Consegui uma boa parceria com a NXP, que gentilmente doou os kits de desenvolvimento para a realização do treinamento. Utilizaremos neste treinamento o kit de desen­volvi­mento LPC3250 Developer’s Kit da Embed­ded Artists.

Também consegui um ótimo local para a realização do treinamento. Será em São Paulo, na Ka Solution, unidade Centro, próximo ao metrô São Bento. Salas limpas, máquinas de última geração, ar-condicionado, café, suco e refrigerantes à vontade, e dois coffee-breaks por dia!

Decidi trabalhar com uma turma de 10 pessoas ao invés de 12. Acredito que será mais produtivo. Portanto, se você tem interesse, não perca tempo! :)

Para maiores informações sobre o treinamento e os procedimentos para realizar a inscrição, clique aqui.

Atualização: As inscrições para a primeira turma estão encerradas. Para informações sobre o treinamento e as próximas turmas, clique aqui.

Um abraço,

Sergio Prado

Sem posts relacionados.

No último artigo vimos os principais conceitos de toolchain em Linux embarcado: o que é um toolchain, os tipos de toolchain e seus componentes básicos.

Neste artigo iremos aprender a gerar e utilizar um toolchain para cross-compilar aplicações e projetos open-source para Linux embarcado.

ONDE POSSO ENCONTRAR UM TOOLCHAIN?

Você tem duas opções: usar um toolchain pronto ou gerar (compilar) seu próprio toolchain. Cada uma destas opções tem suas vantagens e desvantagens.

Usar um toolchain pronto é fácil. Normalmente vem junto com o BSP (Board Support Package) da sua plataforma de desenvolvimento. Existem também versões gratuitas disponibilizadas por empresas como a Code Sourcery (que foi adquirida pela Mentor Graphics). Mas usar um toolchain pronto engessa sua solução. Como o toolchain depende das bibliotecas do sistema, você vai precisar adaptar seu produto às bibliotecas de sistema usadas no toolchain. Se o toolchain não tem um compilador C++, você não conseguirá desenvolver aplicações nesta linguagem. Conclusão: em vez da ferramenta se adaptar às suas necessidades, você é que vai precisar se adaptar à ferramenta. O que na maioria das vezes não é muito bom, certo?

A segunda opção, gerar um toolchain, pode dar um pouco mais de trabalho, mas te traz toda a flexibilidade necessária para adaptar a ferramenta às necessidades do seu projeto. É o que faremos a seguir.

GERANDO SEU PRÓPRIO TOOLCHAIN

O processo de geração de um toolchain, como você deve imaginar, é bem complicado. Mas existem ferramentas que automatizam este processo. 

Boa parte das ferramentas de Build System, como o OpenEmbedded e o Buildroot, fazem isso. Mas existem algumas ferramentas específicas para gerar toolchains. Dentre elas, a mais famosa é o crosstool-ng, que usaremos para gerar um toolchain para cross-compilar aplicações Linux para ARM.

O crosstool-ng pode ser baixado da página do projeto em http://crosstool-ng.org/. Crie uma pasta de trabalho na sua máquina, baixe e descompacte o crosstool-ng:

$ cd /opt/toolchain
$ wget http://crosstool-ng.org/download/crosstool-ng/crosstool-ng-1.13.1.tar.bz2
$ tar jxfv crosstool-ng-1.13.1.tar.bz2
$ cd crosstool-ng-1.13.1/

Primeiramente, precisamos configurar e compilar o crosstool-ng:

$ ./configure --local
$ make && make install

O processo acima deve ter gerado o script “ct-ng”, que será usado para configurar o toolchain.

O crosstool-ng vem com algumas configurações de toolchain por padrão, que podem ser visualizadas com o comando abaixo:

$ ./ct-ng list-samples
Sample name                           Status
alphaev56-unknown-linux-gnu           [L X]
alphaev67-unknown-linux-gnu           [L X]
arm-bare_newlib_cortex_m3_nommu-eabi  [L X]
arm-cortex_a15-linux-gnueabi          [L X]
arm-cortex_a8-linux-gnueabi           [L  ]
arm-davinci-linux-gnueabi             [L  ]
armeb-unknown-eabi                    [L  ]
armeb-unknown-linux-gnueabi           [L X]
armeb-unknown-linux-uclibcgnueabi     [L X]
arm-iphone-linux-gnueabi              [L X]
...

A listagem acima esta exibindo apenas uma parte das configurações disponíveis por padrão no crosstool-ng. Ele é capaz de gerar toolchains para ARM, MIPS, PPC, x86 e AVR, dentre outras arquiteturas e plataformas.

Você pode se aventurar a criar uma configuração do zero, mas o mais comum é usar uma das configurações pré-definidas, e então trabalhar em cima dela. No nosso caso, usaremos o “arm-unknown-linux-uclibcgnueabi” e faremos algumas pequenas modificações.

Portanto, carregue esta configuração com o comando abaixo:

$ ./ct-ng arm-unknown-linux-uclibcgnueabi

Vamos agora abrir o menu de configuração do crosstool-ng e fazer alguns ajustes:

$ ./ct-ng menuconfig

Entre na opção “Paths and misc options” e configure a quantidade de threads de execução. Essa configuração ajuda a diminuir o tempo de compilação e geração do toolchain. Multiplique a quantidade de núcleos da sua CPU por dois:

(2) Number of parallel jobs

Ainda neste menu, configure o diretório de instalação do toolchain na opção “Prefix directory”:

(/opt/toolchain/x-tools/${CT_TARGET}) Prefix directory

Volte à tela principal e entre na opção “Toolchain options” para configurar o “alias”: 

(arm-linux) Tuple’s alias

Configurando “arm-linux” como alias, todas as ferramentas começarão com o prefixo “arm-linux”. Por exemplo, o gcc do toolchain terá o nome “arm-linux-gcc”.

Salve e saia. Agora é só iniciar a geração do toolchain com o comando abaixo:

$ ./ct-ng build

Obs: No momento em que escrevo este artigo, o site do kernel do Linux não esta 100% no ar (os caras tiveram alguns problemas de segurança que tiraram o site do ar durante um bom tempo). Por este motivo, o crosstool-ng deu um erro ao tentar baixar o kernel do Linux (arquivo linux-2.6.33.19.tar.gz). Neste caso, vá para a página do github do kernel, baixe a versão requisitada pelo crosstool-ng, e salve-a no diretório “.build/tarballs/”.

O processo de compilação pode demorar um pouco. No final, verifique o toolchain gerado no diretório abaixo:

$ ls /opt/toolchain/x-tools/arm-unknown-linux-uclibcgnueabi/bin
arm-linux-addr2line     arm-linux-g++        arm-linux-ldd       arm-linux-size                             arm-unknown-linux-uclibcgnueabi-c++filt       arm-unknown-linux-uclibcgnueabi-gdb       arm-unknown-linux-uclibcgnueabi-ranlib
arm-linux-ar            arm-linux-gcc        arm-linux-nm        arm-linux-strings                          arm-unknown-linux-uclibcgnueabi-cpp           arm-unknown-linux-uclibcgnueabi-gprof     arm-unknown-linux-uclibcgnueabi-readelf
arm-linux-as            arm-linux-gcc-4.4.3  arm-linux-objcopy   arm-linux-strip                            arm-unknown-linux-uclibcgnueabi-ct-ng.config  arm-unknown-linux-uclibcgnueabi-ld        arm-unknown-linux-uclibcgnueabi-run
arm-linux-c++           arm-linux-gccbug     arm-linux-objdump   arm-unknown-linux-uclibcgnueabi-addr2line  arm-unknown-linux-uclibcgnueabi-g++           arm-unknown-linux-uclibcgnueabi-ldd       arm-unknown-linux-uclibcgnueabi-size
arm-linux-cc            arm-linux-gcov       arm-linux-populate  arm-unknown-linux-uclibcgnueabi-ar         arm-unknown-linux-uclibcgnueabi-gcc           arm-unknown-linux-uclibcgnueabi-nm        arm-unknown-linux-uclibcgnueabi-strings
arm-linux-c++filt       arm-linux-gdb        arm-linux-ranlib    arm-unknown-linux-uclibcgnueabi-as         arm-unknown-linux-uclibcgnueabi-gcc-4.4.3     arm-unknown-linux-uclibcgnueabi-objcopy   arm-unknown-linux-uclibcgnueabi-strip
arm-linux-cpp           arm-linux-gprof      arm-linux-readelf   arm-unknown-linux-uclibcgnueabi-c++        arm-unknown-linux-uclibcgnueabi-gccbug        arm-unknown-linux-uclibcgnueabi-objdump
arm-linux-ct-ng.config  arm-linux-ld         arm-linux-run       arm-unknown-linux-uclibcgnueabi-cc         arm-unknown-linux-uclibcgnueabi-gcov          arm-unknown-linux-uclibcgnueabi-populate

Sempre que você for usar o toolchain, vai precisar configurar a variável de ambiente PATH:

$ export PATH=/opt/toolchain/x-tools/arm-unknown-linux-uclibcgnueabi/bin:$PATH

Agora teste o toolchain gerado:

$ arm-linux-gcc
arm-linux-gcc: no input files

USANDO O TOOLCHAIN

Usar o toolchain para cross-compilar uma aplicação é muito fácil. Crie um programa simples em C:

1
2
3
4
5
6
7
8

// main.c
#include "stdio.h"
 
int main()
{
    printf("Hello Embedded Universe!\n");
    return 0;
}

Se você quisesse compilar nativamente sua aplicação, bastaria usar o gcc conforme abaixo:

$ gcc main.c -o main

Para confirmar que a aplicação foi compilada nativamente, use o comando “file”:

$ file main
main: ELF 32-bit LSB executable, Intel 80386, version 1 (SYSV), dynamically linked (uses shared libs), for GNU/Linux 2.6.15, not stripped

Para cross-compilar, basta trocar o gcc pelo compilador do toolchain, que no nosso caso é o arm-linux-gcc:

$ arm-linux-gcc main.c -o main

Obs: Lembre-se de que a variável PATH deve estar configurada corretamente para o bash encontrar as ferramentas do toolchain.

Use o comando “file” para confirmar que a aplicação foi compilada para ARM:

$ file main
main: ELF 32-bit LSB executable, ARM, version 1 (SYSV), dynamically linked (uses shared libs), not stripped

Fácil, não?

CROSS-COMPILANDO APLICAÇÕES MAIS COMPLEXAS

Mas Sergio, compilar um arquivo “.c” é fácil. E no caso de um projeto mais complexo, com diversos arquivos-fonte?

Um projeto deste porte é normalmente baseado em um ou mais Makefiles, ou em um conjunto de ferramentas chamadas de autotools.

Para um projeto baseado em Makefile, você pode abrir o arquivo de Makefile, encontrar a definição das variáveis que definem as ferramentas de compilação (AR, AS, LD, CC, GCC, CPP, CXX, STRIP) e substituir pelas do seu toolchain. Não se esqueça de que a variável PATH também deve estar configurada corretamente.

Para um projeto baseado em autotools, o procedimento comum para compilar nativamente a aplicação é este:

$ ./configure
$ make
$ make install

Mas para cross-compilar um projeto baseado em autotools, alguns cuidados adicionais devem ser tomados, como configurar o compilador através da variável de ambiente CC, e indicar o “host” ao executar a ferramenta “configure”.

Para estudar este processo, vamos cross-compilar o lighttpd, um web server bastante usado em Linux embarcado, e cujo projeto é baseado em autotools.

Baixe e descompacte o pacote:

$ cd /opt/toolchain/
$ wget http://download.lighttpd.net/lighttpd/releases-1.4.x/lighttpd-1.4.29.tar.gz
$ tar zxfv lighttpd-1.4.29.tar.gz
$ cd lighttpd-1.4.29/

Para cross-compilar usando o toolchain que geramos, basta executar os comandos abaixo:

$ export PATH=/opt/toolchain/x-tools/arm-unknown-linux-uclibcgnueabi/bin:$PATH
$ export CC=arm-linux-gcc
$ ./configure --host=arm-linux --without-pcre --without-zlib --without-bzip2 --disable-ipv6
$ make

Na primeira linha configuramos a variável de ambiente PATH. Na segunda linha configuramos o compilador do toolchain através da variável de ambiente CC. Na terceira linha configuramos o software indicando qual é o host (máquina que irá executar a aplicação), e desabilitando algumas bibliotecas que não temos disponíveis. Por último, executamos o make para compilar a aplicação.

Confirme se o lighttpd foi compilado para ARM:

$ file ./src/lighttpd
./src/lighttpd: ELF 32-bit LSB executable, ARM, version 1 (SYSV), dynamically linked (uses shared libs), not stripped

Percebam que a geração e o uso de toolchains não envolve nenhum tipo de “magia negra”. Quanto menos uma ferramenta for uma “caixa preta” para você, melhor. Você será mais produtivo, e resolverá eventuais problemas muito mais rapidamente.

Um abraço,

Sergio Prado

Posts relacionados:

1. Desmistificando toolchains em Linux embarcado