Esta aberto o credenciamento para o ESC Brazil 2012, que irá acontecer nos dias 26 e 27 de junho de 2012.

Este ano o evento parece estar bem maior, com mais expositores, dentre eles AMD, Intel, ARM, Atmel, Freescale, IAR, Microchip, NI, NXP, Renesas, ST, Texas e Wind River.

Será também em um local maior, no Transamérica Expo Center, e deverá acontecer junto com a feira de equipamentos médicos MDM (Medical Design & Manufacturing).

No primeiro dia os keynotes serão de dois brasileiros, Marcelo Zuffo da USP e Henrique Miguel do MCTi. No segundo dia teremos keynotes internacionais, com Bill Gatliff, consultor de Android e Linux embarcado, e Chris Shore da ARM.

A grade de palestras me parece também estar muito boa. Desta vez teremos algumas palestras com foco em hardware, o que faltou no ano passado. E a quantidade de palestrantes brasileiros ultrapassou a de estrangeiros (10 x 8), o que é ótimo!

Não deixe de ir. É uma oportunidade de se atualizar, fazer networking com as principais empresas da áreas, e mostrar a força do Brasil na área de sistemas embarcados. Além do mais, você não pode perder minha palestra sobre o FreeRTOS… Prometo algumas surpresas! :)

A inscrição para a feira é gratuita e pode ser feita aqui. Já o credenciamento para a conferência pode ser feito aqui.

Nos vemos lá!

Um abraço,

Sergio Prado

Posts relacionados:

1. Call for Papers para o ESC Brazil 2011
2. Pesquisa para o TI Tech Day 2012
3. Creative Commons e ESC 2012

Sergio Prado atua com desenvolvimento de software para sistemas embarcados há mais de 15 anos. É sócio-fundador da Embed­ded Lab­works, uma empresa focada em te aju­dar a desen­volver soft­ware de qual­i­dade para sis­temas embar­ca­dos. Se você pre­cisa de ajuda para desen­volver seu pro­duto, ou quer saber mais sobre o que a Embed­ded Lab­works pode fazer por você, acesse http://e-labworks.com/servicos.

Este post foi originalmente publicado em Credenciamento para o ESC Brazil 2012.

O uso de microntroladores ARM da linha Cortex-M3 tem crescido bastante nos últimos tempos. Ele preenche bem um espaço que fica entre as aplicações mais simples, que podem se desenvolvidas em 8/16 bits, e as aplicações mais complexas que exigem um sistema operacional completo.

E você não precisa necessariamente de uma ferramenta paga como a da IAR ou a da Keil para trabalhar com um Cortex-M3. Uma das grandes vantagens da arquitetura ARM é o enorme ecossistema de ferramentas e soluções de código aberto existentes.

Neste artigo iremos aprender a configurar um ambiente de desenvolvimento em Linux com o GCC e utilizá-lo para desenvolver uma aplicação para o LPC1768, um Cortex-M3 da NXP.

NOSSO AMBIENTE

O ambiente de desenvolvimento será uma máquina Linux com a distribuição Ubuntu 12.04.

Para os testes, utilizaremos o kit de desenvolvimento mbed, uma plataforma cri­ada pelos engen­heiros da própria ARM para diminuir a curva de apren­diza­gem em pro­je­tos com ARM. O kit é baseado no NXP LPC1768, um ARM Cortex-M3 com 512K de memória Flash, 32K de RAM e diver­sas inter­faces como CAN, SPI, I2C e Eth­er­net.

O legal deste kit é a facilidade de gravar o firmware. Não é necessário nenhum gravador especial ou interface JTAG. Quando você pluga ele na USB, ele se transforma em um pendrive. Basta então copiar o firmware (arquivo .bin) para lá!

Se você quiser ler mais sobre o mbed, escrevi um tempo atrás o artigo “Projetando na nuvem com o kit mbed”.

PREPARANDO O AMBIENTE

Crie um diretório no seu HOME para a realização dos trabalhos:

$ mkdir -p ~/workspace

Precisamos de um toolchain para gerar código bare-metal para o Cortex-M3. Se você não sabe o que é um toolchain, leia o artigo “Desmistificando toolchains em Linux embarcado”.

Vou te dar duas opções para a configuração de um toolchain para Cortex-M3, uma “sem emoção”, e outra “com emoção”! :)

TOOLCHAIN “SEM EMOÇÃO”

Basta baixar e instalar o toolchain pronto da CodeSourcery (agora Mentor Graphics Sourcery Tools):

$ sudo mkdir -p /opt/toolchain/codesourcery/
$ sudo chown -R $USER:$USER /opt/toolchain
$ cd /opt/toolchain/codesourcery/
$ wget https://sourcery.mentor.com/sgpp/lite/arm/portal/package8734/public/arm-none-eabi/arm-2011.03-42-arm-none-eabi-i686-pc-linux-gnu.tar.bz2
$ tar xjfv arm-2011.03-42-arm-none-eabi-i686-pc-linux-gnu.tar.bz2
$ rm *.tar.bz2

Pronto! Toolchain instalado!

Agora, para os corações mais fortes…

TOOLCHAIN “COM EMOÇÃO”

Vamos usar o crosstool-ng para gerar um toolchain para Cortex-M3 bare-metal. Para quem não esta familiarizado com o termo, “bare-metal” é basicamente um firmware que roda direto na CPU sem o suporte de um sistema operacional. E se você não conhece o crosstool-ng, ou não sabe como usá-lo, leia o artigo “Gerando e usando toolchains em Linux embarcado”.

Execute os comandos abaixo para baixar e instalar a ferramenta:

$ cd ~/workspace
$ wget http://crosstool-ng.org/download/crosstool-ng/crosstool-ng-1.15.0.tar.bz2
$ tar jxfv crosstool-ng-1.15.0.tar.bz2 && rm *.tar.bz2
$ cd crosstool-ng-1.15.0/
$ ./configure
$ make
$ sudo make install
$ ct-ng arm-bare_newlib_cortex_m3_nommu-eabi

É a última linha que configura o crosstool-ng para trabalhar com bare-metal em Cortex-M3. Agora abra o menu de configuração:

$ ct-ng menuconfig

Vamos fazer algumas modificações no toolchain que será gerado:

Paths and misc options --->
    (/opt/toolchain/${CT_TARGET}) Prefix directory
    (8) Number of parallel jobs
Toolchain options --->
    (arm-cortexm3-bare) Tuple's alias
Debug facilities --->
    [*] gdb ---> 
    [*] Cross-gdb
    [*] Enable 'sim'
    [*] Enable python scripting

Ajuste a opção “Number of parallel jobs” de acordo com a quantidade de núcleos da CPU da sua máquina de desenvolvimento. Depois é so compilar com o comando abaixo:

$ ct-ng build

Dependendo da sua máquina, o processo de compilação do toolchain deve levar de 20 à 60 minutos. Quando terminar, verifique se as ferramentas foram geradas corretamente:

$ cd /opt/toolchain/arm-bare_newlib_cortex_m3_nommu-eabi/bin/
$ ls arm-cortexm3-bare-*
arm-cortexm3-bare-addr2line arm-cortexm3-bare-c++filt arm-cortexm3-bare-g++ arm-cortexm3-bare-gdb arm-cortexm3-bare-nm arm-cortexm3-bare-run
arm-cortexm3-bare-ar arm-cortexm3-bare-cpp arm-cortexm3-bare-gcc arm-cortexm3-bare-gdbtui arm-cortexm3-bare-objcopy arm-cortexm3-bare-size
arm-cortexm3-bare-as arm-cortexm3-bare-ct-ng.config arm-cortexm3-bare-gcc-4.4.1 arm-cortexm3-bare-gprof arm-cortexm3-bare-objdump arm-cortexm3-bare-strings
arm-cortexm3-bare-c++ arm-cortexm3-bare-elf2flt arm-cortexm3-bare-gccbug arm-cortexm3-bare-ld arm-cortexm3-bare-ranlib arm-cortexm3-bare-strip
arm-cortexm3-bare-cc arm-cortexm3-bare-flthdr arm-cortexm3-bare-gcov arm-cortexm3-bare-ld.real arm-cortexm3-bare-readelf

NEWLIB

Tanto o toolchain da CodeSourcery quanto o toolchain gerado pelo crosstool-ng usam a newlib, uma biblioteca C padrão com foco em sistemas embarcados.

Criada originalmente pela Cygnus Solutions (que mais pra frente foi adquirida pela Red Hat), ela é hoje bastante usada em boa parte dos toolchains livres e comerciais baseados no GCC para sistemas embarcados.

CMSIS

O CMSIS (Cortex Microcontroller Software Interface Standard) é uma camada de software que abstrai o acesso à microcontroladores de arquitetura ARM Cortex-M. É um padrão desenvolvido pela própria ARM com o objetivo de facilitar o acesso aos periféricos, reduzir a curva de aprendizado e simplificar o reuso de código.

A idéia aqui é ter uma camada de software que permita migrar facilmente sua aplicação usando um Cortex-M para diferentes fornecedores de chip (Freescale, TI, NXP, ST, etc), desde que cada um deles tenha implementado o padrão. Na prática, são dois arquivos-fonte C e cinco arquivos de cabeçalho que padronizam o nome de funções de inicialização, manipuladores de interrupção, nomes dos registradores, etc.

Com o toolchain preparado, vamos então baixar e instalar os fontes do CMSIS para usá-los depois na nossa aplicação.

$ cd ~/workspace
$ mkdir -p cmsis && cd cmsis
$ wget http://ics.nxp.com/support/lpcxpresso/zip/CMSISv2p00_LPC17xx.zip
$ unzip CMSISv2p00_LPC17xx.zip && rm CMSISv2p00_LPC17xx.zip

Talvez você precise alterar as definições de clock no arquivo “system_LPC17xx.c” do CMSIS (XTAL, RTC_CLK e IRC_OSC). No meu caso, eu precisei alterar o RTC_CLK para 32768UL, já que esta é a frequência do oscilador do RTC no kit mbed.

CRIANDO O PROJETO

Vamos criar agora o nosso projeto “na unha”! O segredo aqui é preparar o Makefile para usar corretamente o cross-compiler e ter um script de linker bem configurado.

Mas vamos começar primeiro pelos fontes da aplicação.

A APLICAÇÃO

Vamos desenvolver o famoso “Hello World” de sistemas embarcados: um pisca led!

Precisamos de um código de inicialização e da função main() da aplicação, que irá efetivamente piscar o led.

O código de inicialização é bem simples. Segue um trecho abaixo (o código completo você poderá baixar no fim do artigo):

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

/* startup.c */
#include 
 
/* extern symbols */
extern unsigned int _end_stack;
...
 
/* extern functions */
extern int main(void);
extern void SystemInit(void);
 
/* Cortex M3 core interrupt handlers */
void Reset_Handler(void);
void NMI_Handler(void) __attribute__ ((weak, alias ("Dummy_Handler")));
...
 
/* LPC13xx specific interrupt handlers */
void WDT_IRQHandler(void) __attribute__ ((weak, alias ("Dummy_Handler")));
void TIMER0_IRQHandler(void) __attribute__ ((weak, alias ("Dummy_Handler")));
...
 
/* prototypes */
void Dummy_Handler(void);
 
/* interrupt vector table */
void *vector_table[] __attribute__ ((section(".vectors"))) = {
    &_end_stack,
    Reset_Handler,
    NMI_Handler,
    ... 
};
 
/* startup function */
void Reset_Handler(void) 
{
    unsigned int *src, *dst;
 
    /* Copy data section from flash to RAM */
    src = &_end_text;
    dst = &_start_data;
    while (dst < &_end_data)
        *dst++ = *src++;
 
    /* Clear the bss section */
    dst = &_start_bss;
    while (dst < &_end_bss)
        *dst++ = 0;
 
    SystemInit();
 
    main();
}
 
/* default interrupt handler */
void Dummy_Handler(void)
{
 
}

O código de inicialização basicamente inicializa a tabela de vetores de interrupção (linha 26) e declara a função Reset_Handler(), que será executada no boot da CPU (linha 34). Esta função prepara as regiões de memória DATA (dados inicializados) e BSS (dados não inicializados), inicializa a placa (registradores, periféricos, etc) e chama a função main().

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

/* main.c */
 
...
 
int main (void) 
{
    /* set system tick for 1ms interrupt */
    SystemCoreClockUpdate();
    if (SysTick_Config(SystemCoreClock / 1000)) { 
        while (1);
    }
 
    /* set led GPIO port */
    LPC_GPIO1->FIODIR = (1<<LED_GPIO);
 
    /* blink led */
    while(1) {
        LPC_GPIO1->FIOSET = (1<<LED_GPIO);
        Delay (300);
        LPC_GPIO1->FIOCLR = (1<<LED_GPIO);
        Delay (300);
    }
}

A função main() inicializa o clock, configura o SysTick para gerar interrupção a cada 1 milisegundo, e entra em um loop para piscar o led.

O MAKEFILE

Já o Makefile é bem mais extenso, mas nada muito complexo. Segue um trecho dele:

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

# project name
PRJNAME = blinkled
 
# toolchain configuration
PATH := ${PATH}:/opt/toolchain/arm-bare_newlib_cortex_m3_nommu-eabi/bin/
TOOLCHAIN_PREFIX = arm-cortexm3-bare-
 
# cpu configuration
THUMB = -mthumb
MCU = cortex-m3
 
...
 
# C source files
C_SRC := $(CMSISSRCDIR)/core_cm3.c $(CMSISSRCDIR)/system_LPC17xx.c $(SRCDIR)/main.c $(SRCDIR)/startup.c
 
# C flags
CFLAGS += -mcpu=$(MCU)
...
 
# Linker flags
LDFLAGS +=-T$(PRJDIR)/lpc1768.ld
...
 
# Define programs and commands.
CC = $(TOOLCHAIN_PREFIX)gcc
OBJCOPY = $(TOOLCHAIN_PREFIX)objcopy
OBJDUMP = $(TOOLCHAIN_PREFIX)objdump
NM = $(TOOLCHAIN_PREFIX)nm
 
...
 
all: createdirs build
 
createdirs:
        @mkdir -p $(OUTDIR)
        @mkdir -p $(OUTDIR)/dep
 
# targets for the build-sequence
build: elf lss sym hex bin
 
...
 
# Link: create ELF output file from object files.
.SECONDARY : $(PRJNAME).elf
.PRECIOUS : $(ALL_OBJ)
%.elf: $(ALL_OBJ) $(BUILDONCHANGE)
        $(CC) $(THUMB) $(CFLAGS) $(ALL_OBJ) --output $@ -nostartfiles $(LDFLAGS)
 
...
 
# compile C source code
define COMPILE_C_TEMPLATE
$(OUTDIR)/$(notdir $(basename $(1))).o : $(1) $(BUILDONCHANGE)
        $(CC) -c $(THUMB) $$(CFLAGS) $$< -o $$@ 
endef
$(foreach src, $(C_SRC), $(eval $(call COMPILE_C_TEMPLATE, $(src))))
 
...

Configure o PATH e o TOOLCHAIN_PREFIX de acordo com o seu toolchain. Perceba que para compilar são passadas para o GCC as opções –mcpu=cortex-m3 e –mthumb. Desta forma o cross-compiler sabe que queremos gerar código para um cortex-m3. No linker, indicamos que não queremos usar arquivos de inicialização com a opção –nostartfiles (linha 48), e passamos o script de linker lpc1768.ld (linha 22).

LINKER SCRIPT

O linker script indica como o linker irá organizar as diversas seções de código e dados do programa (TEXT, DATA, BSS, etc) na memória do microcontrolador. Segue a listagem completa do script:

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

/* lpc1313.dld */
ENTRY(Reset_Handler)
 
MEMORY
{
	sram	:	ORIGIN = 0x10000000, LENGTH = 32k
	flash	:	ORIGIN = 0x00000000, LENGTH = 512k
}
 
_end_stack = 0x10007FF0;
 
SECTIONS {
	. = ORIGIN(flash);
 
	vectors :
	{
		*(.vectors)
	} >flash
 
	.text :
	{
		*(.text)
		*(.rodata)
		*(.rodata*)
		*(.ARM.extab* .gnu.linkonce.armextab.*)
		*(.eh_frame_hdr)
		*(.eh_frame)
		_end_text = .;
	} >flash
 
	__exidx_start = .;
	.ARM.exidx :
	{
		*(.ARM.exidx* .gnu.linkonce.armexidx.*)
	} >flash
	__exidx_end = .;
 
	.data : 
	{
		_start_data = .;
		*(.data)
		_end_data = .;
	} >sram AT >flash
 
	.bss :
	{
		_start_bss = .;
		*(.bss)
		_end_bss = .;
	} >sram
 
	. = ALIGN(4);
 
	_start_stack = .;
}
 
_end = .;
PROVIDE(end = .);

Agora é só compilar!

$ make
arm-cortexm3-bare-gcc -c -mthumb -mcpu=cortex-m3 -Wall -Wextra -Werror -Wcast-align -Wpointer-arith -Wredundant-decls -Wcast-qual -Wa,-adhlns=/home/sprado/workspace/dev/mbed/projects/blinkled/out/core_cm3.lst -MMD -MP -MF /home/sprado/workspace/dev/mbed/projects/blinkled/out/dep/core_cm3.o.d -I. -I/home/sprado/workspace/dev/mbed/projects/blinkled/inc -I/home/sprado/workspace/dev/mbed/projects/blinkled/../../cmsis//inc/ /home/sprado/workspace/dev/mbed/projects/blinkled/../../cmsis//src//core_cm3.c -o /home/sprado/workspace/dev/mbed/projects/blinkled/out/core_cm3.o 
arm-cortexm3-bare-gcc -c -mthumb -mcpu=cortex-m3 -Wall -Wextra -Werror -Wcast-align -Wpointer-arith -Wredundant-decls -Wcast-qual -Wa,-adhlns=/home/sprado/workspace/dev/mbed/projects/blinkled/out/system_LPC17xx.lst -MMD -MP -MF /home/sprado/workspace/dev/mbed/projects/blinkled/out/dep/system_LPC17xx.o.d -I. -I/home/sprado/workspace/dev/mbed/projects/blinkled/inc -I/home/sprado/workspace/dev/mbed/projects/blinkled/../../cmsis//inc/ /home/sprado/workspace/dev/mbed/projects/blinkled/../../cmsis//src//system_LPC17xx.c -o /home/sprado/workspace/dev/mbed/projects/blinkled/out/system_LPC17xx.o 
arm-cortexm3-bare-gcc -c -mthumb -mcpu=cortex-m3 -Wall -Wextra -Werror -Wcast-align -Wpointer-arith -Wredundant-decls -Wcast-qual -Wa,-adhlns=/home/sprado/workspace/dev/mbed/projects/blinkled/out/main.lst -MMD -MP -MF /home/sprado/workspace/dev/mbed/projects/blinkled/out/dep/main.o.d -I. -I/home/sprado/workspace/dev/mbed/projects/blinkled/inc -I/home/sprado/workspace/dev/mbed/projects/blinkled/../../cmsis//inc/ /home/sprado/workspace/dev/mbed/projects/blinkled/src/main.c -o /home/sprado/workspace/dev/mbed/projects/blinkled/out/main.o 
arm-cortexm3-bare-gcc -c -mthumb -mcpu=cortex-m3 -Wall -Wextra -Werror -Wcast-align -Wpointer-arith -Wredundant-decls -Wcast-qual -Wa,-adhlns=/home/sprado/workspace/dev/mbed/projects/blinkled/out/startup.lst -MMD -MP -MF /home/sprado/workspace/dev/mbed/projects/blinkled/out/dep/startup.o.d -I. -I/home/sprado/workspace/dev/mbed/projects/blinkled/inc -I/home/sprado/workspace/dev/mbed/projects/blinkled/../../cmsis//inc/ /home/sprado/workspace/dev/mbed/projects/blinkled/src/startup.c -o /home/sprado/workspace/dev/mbed/projects/blinkled/out/startup.o 
arm-cortexm3-bare-gcc -mthumb -mcpu=cortex-m3 -Wall -Wextra -Werror -Wcast-align -Wpointer-arith -Wredundant-decls -Wcast-qual -Wa,-adhlns=/home/sprado/workspace/dev/mbed/projects/blinkled/out/core_cm3.lst -MMD -MP -MF /home/sprado/workspace/dev/mbed/projects/blinkled/out/dep/blinkled.elf.d -I. -I/home/sprado/workspace/dev/mbed/projects/blinkled/inc -I/home/sprado/workspace/dev/mbed/projects/blinkled/../../cmsis//inc/ /home/sprado/workspace/dev/mbed/projects/blinkled/out/core_cm3.o /home/sprado/workspace/dev/mbed/projects/blinkled/out/system_LPC17xx.o /home/sprado/workspace/dev/mbed/projects/blinkled/out/main.o /home/sprado/workspace/dev/mbed/projects/blinkled/out/startup.o --output /home/sprado/workspace/dev/mbed/projects/blinkled/out/blinkled.elf -nostartfiles -Wl,-Map=/home/sprado/workspace/dev/mbed/projects/blinkled/out/blinkled.map,--cref -L. -L/home/sprado/workspace/dev/mbed/projects/blinkled/lib -lc -lgcc -T/home/sprado/workspace/dev/mbed/projects/blinkled/lpc1768.ld
arm-cortexm3-bare-objdump -h -S -C -r /home/sprado/workspace/dev/mbed/projects/blinkled/out/blinkled.elf > /home/sprado/workspace/dev/mbed/projects/blinkled/out/blinkled.lss
arm-cortexm3-bare-nm -n /home/sprado/workspace/dev/mbed/projects/blinkled/out/blinkled.elf > /home/sprado/workspace/dev/mbed/projects/blinkled/out/blinkled.sym
arm-cortexm3-bare-objcopy -O ihex /home/sprado/workspace/dev/mbed/projects/blinkled/out/blinkled.elf /home/sprado/workspace/dev/mbed/projects/blinkled/out/blinkled.hex
arm-cortexm3-bare-objcopy -O binary /home/sprado/workspace/dev/mbed/projects/blinkled/out/blinkled.elf /home/sprado/workspace/dev/mbed/projects/blinkled/out/blinkled.bin

Será gerado o arquivo blinkled.bin que você pode copiar e testar no kit de desenvolvimento mbed.

CÓDIGO-FONTE

O código-fonte completo da aplicação pode ser baixado aqui.

TRABALHANDO COM OUTROS CORTEX-M3

Os testes aqui foram feitos com o mbed, que usa o LPC1768 da NXP, mas o processo é o mesmo em qualquer outro chip, você só vai precisar substituir o linker script, ajustar o arquivo de inicialização e reescrever o main.c. Normalmente, o arquivo de inicialização e o script de linker são fornecidos nas aplicações de exemplo disponibilizadas pelo fabricante.

Próximo passo? Colocar o FreeRTOS para rodar no kit!

Até lá!

Um abraço,

Sergio Prado

Posts relacionados:

1. Novos brinquedos no pedaço: mbed e LPCXpresso
2. Projetando na nuvem com o kit mbed

Sergio Prado atua com desenvolvimento de software para sistemas embarcados há mais de 15 anos. É sócio-fundador da Embed­ded Lab­works, uma empresa focada em te aju­dar a desen­volver soft­ware de qual­i­dade para sis­temas embar­ca­dos. Se você pre­cisa de ajuda para desen­volver seu pro­duto, ou quer saber mais sobre o que a Embed­ded Lab­works pode fazer por você, acesse http://e-labworks.com/servicos.

Este post foi originalmente publicado em Mbed — Desenvolvendo em Cortex-M3 com o GCC.

Um tempo atrás escrevi um artigo sobre o desenvolvimento com Qt em Linux embarcado, mas não cheguei a tratar do Qt Creator.

O Qt Creator é uma IDE completa e multi-plataforma para desenvolvimento em Qt, com suporte total à design de interface gráfica. Sim, com ela você consegue desenvolver uma aplicação gráfica em Qt, criando janelas e arrastando botões e campos de texto! Simples assim!

Para desenvolvimento nativo, ela é plug’n play. Ou seja, basta baixar e usar. Já para desenvolvimento em Linux embarcado, você precisará de um ambiente configurado e de alguns ajustes na ferramenta. É o que veremos neste artigo.

PREPARANDO O TERRENO

O kit de desenvolvimento (target) que usaremos para os testes será a Beagleboard-xM, mas o mesmo processo deve funcionar em qualquer outra plataforma.

Para começar, você vai precisar de um toolchain. Não sabe o que é um toolchain? Então você deve ler o artigo “Desmistificando toolchains em Linux embarcado”.

Porque precisamos de um toolchain? Porque iremos cross-compilar as bibliotecas do Qt para o kit de desenvolvimento.

Então como eu consigo um toolchain, Sergio? Fácil, já respondi esta pergunta para você no artigo “Gerando e usando toolchains em Linux embarcado”.

Meu conselho é você usar o toolchain da CodeSourcery ou gerar um toolchain para ARM genérico com a glibc. Prometo que isso irá evitar muita dor de cabeça e algumas noites mal dormidas.

Digo isso porque já tive alguns problemas tentando compilar o Qt manualmente com um toolchain baseado na uClibc. Mas se você quer insistir nessa idéia, sugiro usar o Buildroot para compilar o Qt. Ele usa uma versão mais antiga do Qt, e já possui todos os patches para compilar sem problemas com um toolchain baseado na uClibc. À propósito, já expliquei como fazer isso no artigo “Compilando Qt e aplicações gráficas em Linux embarcado”.

Com o toolchain preparado, mãos à obra!

COMPILANDO O QT

O primeiro passo é baixar e compilar as bibliotecas do Qt. Esse processo vai lhe exigir muita paciência e algumas xícaras de café.

Para baixar e extrair os fontes do Qt:

$ wget http://get.qt.nokia.com/qt/source/qt-everywhere-opensource-src-4.8.1.tar.gz
$ tar zxfv qt-everywhere-opensource-src-4.8.1.tar.gz
$ cd qt-everywhere-opensource-src-4.8.1

Antes de compilar, vamos setar a variável de ambiente PATH para que possamos usar as ferramentas do toolchain (ajuste de acordo com a localização do seu toolchain):

$ export PATH=/opt/toolchain/arm-linux/bin:$PATH

Agora vamos configurar o Qt:

$ ./configure -opensource -confirm-license -embedded arm -xplatform qws/linux-arm-g++ -little-endian -qt-zlib -qt-libtiff -qt-libpng -qt-libmng -qt-libjpeg -prefix /usr/local/qt-arm

Esta configuração irá preparar o Qt para ser compilado para um sistema ARM little-endian, cujo cross-compiler tem o prefixo arm-linux–. Se sua plataforma for diferente desta configuração, precisará alterar a opção –xplatform. Este link explica melhor o processo.

Se o toolchain que você esta usando não é o mesmo toolchain que gerou o rootfs do seu kit de desenvolvimento, sugiro incluir no comando acima a opção “–static” (sem os parênteses). Se você esta em dúvida, ou não faz a menor idéia do que eu quiz dizer, use-o mesmo assim.

Depois de configurado é só compilar. Prepare-se, porque vai levar (literalmente) algumas horas. Faça isso à noite. Digite o comando abaixo, e até amanhã…

$ make

Bom dia! Agora mais alguns minutos para instalar:

$ sudo make install

Agora é só copiar as bibliotecas para o kit de desenvolvimento. Este procedimento vai depender bastante de como você montou o seu rootfs. Se estiver em uma memória flash, você vai precisar de uma ferramenta de rede como o scp para copiar os arquivos. Se estiver em um cartão SD, basta copiar para o cartão. Mas se você for mesmo esperto, terá montado seu rootfs via NFS (o rootfs fica disponibilizado localmente na sua máquina, e é acessado remotamente via rede pelo kit de desenvolvimento).

Mas Sergio, eu não sei como montar um rootfs via NFS. Vai me dizer que você também escreveu um artigo sobre isso? Sim, escrevi. Como adivinhou? :) É só acessar o artigo “Montando o rootfs no Linux via NFS”. Não se esqueça de adaptar os parâmetros para o seu target (kit de desenvolvimento).

Com o rootfs disponível localmente e montado via NFS, basta copiar as bibliotecas do Qt. Para fins didáticos, vou considerar que o meu rootfs encontra-se no diretório /mnt/rootfs (ajuste de acordo com o seu):

$ sudo mkdir -p /mnt/rootfs/usr/local/qt-arm/
$ sudo cp -av /usr/local/qt-arm/lib /mnt/usr/local/qt-arm/

Como as bibliotecas do Qt foram instaladas em um diretório que não é padrão no Linux, precisamos incluir seu caminho na variável de ambiente LD_LIBRARY_PATH. Coloque a linha abaixo no arquivo /etc/profile do target e reinicie-o:

export LD_LIBRARY_PATH=/usr/local/qt-arm/lib:$LD_LIBRARY_PATH

Você pode testar a instalação do Qt escrevendo uma aplicação simples. Dá uma olhada novamente neste artigo aqui.

INSTALANDO E CONFIGURANDO O QT CREATOR

A versão do Qt Creator que usaremos aqui é a 2.2.1. Para instalá-lo, basta usar o gerenciador de pacotes da sua distribuição. No Ubuntu, execute o comando abaixo:

$ sudo apt-get install qtcreator

Agora vamos configurá-lo para cross-compilar nossa aplicação. O primeiro passo é configurar o qmake, o gerenciador do sistema de build do Qt:

1. Abra o Qt Creator e acesse o menu “Tools -> Options -> Qt4″.
2. Clique em “Add”.
3. Configure o campo “Version” com “Beagleboard Qt 4.8.1″.
4. Configure o campo “qmake location” com o local de instalação do qmake, que no nosso caso é “/usr/local/qt-arm/bin/qmake”.
5. Clique em “OK”.

Agora vamos configurar o toolchain:

1. Acesse o menu “Tools -> Options -> Tool Chains”.
2. Clique em “Add”
3. Configure o caminho completo do compilador C++ e do GDB do seu toolchain conforme a imagem abaixo.
4. Clique em “OK”.

Agora vamos criar um projeto para testar:

1. Acesse o menu “File -> New File”.
2. Selecione a opção “Project -> Qt Widget Project -> Qt GUI Application”.
3. Clique em “Choose…”, dê um nome para seu projeto e confirme o restante das opções até o “Finish”.

Agora vamos configurar o projeto para usar as ferramentas de cross-compilação:

1. Selecionar “Projects” à esquerda.
2. Configurar o campo “Qt Version” com “Beagleboard Qt 4.8.1″.

Agora é só desenvolver! À propósito, arrastar e alinhar botões e labels me trouxeram boas lembranças do saudoso Delphi… :)

Salve e compile. Será gerado um binário com o mesmo nome do projeto. Copie o binário para o target e execute-o (lembre-se de passar o parâmetro –qws):

$ /usr/sbin/qt_beagle -qws

Fácil, não? :) Agora não tem desculpa para não desenvolver aplicações gráficas facilmente em Linux embarcado!

Até a próxima!

Um abraço,

Sergio Prado

Posts relacionados:

1. Desmistificando toolchains em Linux embarcado
2. Gerando e usando toolchains em Linux embarcado
3. Configurando e usando o Eclipse em Linux embarcado

Sergio Prado atua com desenvolvimento de software para sistemas embarcados há mais de 15 anos. É sócio-fundador da Embed­ded Lab­works, uma empresa focada em te aju­dar a desen­volver soft­ware de qual­i­dade para sis­temas embar­ca­dos. Se você pre­cisa de ajuda para desen­volver seu pro­duto, ou quer saber mais sobre o que a Embed­ded Lab­works pode fazer por você, acesse http://e-labworks.com/servicos.

Este post foi originalmente publicado em Desenvolvendo com o Qt Creator em Linux embarcado.

No dia 29 de agosto vai acontecer em São Paulo o 10° TI Tech Day, um evento anual da Texas Instruments, onde ela reúne todos os seus fornecedores e parceiros para um dia repleto de palestras, hands-on e exposições.

O evento ainda esta em fase de planejamento, e como são os clientes e parceiros da Texas que decidem seu conteúdo, esta no ar uma pesquisa para definir a grade de palestras que serão apresentadas no evento.

Fui convidado para ministrar o hands-on de Linux embarcado com a Beaglebone. Portanto, se você quiser participar de um hands-on de Linux embarcado com Sergio Prado, e fazer algumas coisas bem interessantes com nosso querido Pinguim Tux na Beaglebone, é só responder a pesquisa e selecionar o hands-on “Linux nos processadores AM335x (Beagle Bone)”. Apenas os hands-on’s mais votados farão parte da grade de palestras do evento.

A pesquisa só vale até o dia 10 de Abril. Para responder à pesquisa, basta clicar na imagem abaixo!

Um abraço,

Sergio Prado

Posts relacionados:

1. Pesquisa sobre curso de Linux embarcado
2. Call for Papers para o ESC Brazil 2011

Sergio Prado atua com desenvolvimento de software para sistemas embarcados há mais de 15 anos. É sócio-fundador da Embed­ded Lab­works, uma empresa focada em te aju­dar a desen­volver soft­ware de qual­i­dade para sis­temas embar­ca­dos. Se você pre­cisa de ajuda para desen­volver seu pro­duto, ou quer saber mais sobre o que a Embed­ded Lab­works pode fazer por você, acesse http://e-labworks.com/servicos.

Este post foi originalmente publicado em Pesquisa para o TI Tech Day 2012.

Acabou!

No quarto dia assisti quase todas as apresentações do Black Hat, conferência focada em segurança para dispositivos embarcados.

O dia começou com a ótima palestra de Joe Grand da Grand Idea Studio com o tema “The Current State of Hardware Hacking”.

Foi uma apresentação bem descontraída, onde ele mostrou a evolução das técnicas e mecanismos de hardware hacking, incluindo extração e engenharia reversa de firmware, sniffing de barramentos e interfaces de comunicação, quebras de senha, criptografia, etc. Ele ressaltou que a quantidade de hacks em hardware aumentou bastante, principalmente pela facilidade de obter informações e pela quantidade de ferramentas disponíveis. Segundo ele, o problema esta na tendência de pensarmos mais como engenheiros do que como hackers, principamente pela pressão de orçamento e time-to-market dos produtos que colocamos no mercado.

Ele mostrou como boa parte destas técnicas são aplicadas facilmente, às vezes por pessoas que nem possuem conhecimento técnico avançado. Seus exemplos de hardware hacking passaram por mouses, teclados e máquinas de votação; até celulares, videogames e bombas de insulina. O que podemos fazer? Mudar a mentalidade, pensar como um hacker, aceitar os riscos e aprender com o passado.

Logo depois fui assistir ao keynote de Robert Vamosi da Mocana com o tema “An Inconvenient Truth: Embedded Security 2012″. O keynote bateu novamente na tecla “segurança em sistemas embarcados”, focando nos riscos de segurança em dispositivos conectados à Internet como TVs, videogames, impressoras, automóveis, etc. Ele mostrou uma pesquisa onde 25% das empresas sabem que existem problemas de segurança em seus dispositivos, mas 39% delas decidiram não fazer nada. É um problema ainda pouco perceptível para muita gente, mas que com a migração para o IPv6, até uma torradeira poderá colocar em risco a rede que temos em casa!

Aproveitei depois para dar uma última volta no salão de exposições, e tive a oportunidade de conhecer Koen Kooi (core developer do OpenEmbedded) e Gerald Coley (projetista do hardware da Beagleboard).

Da esquerda para a direita: Gerald Coley, Marcelo Sousa, Koen Kooi,
Sergio Prado e Jason Kridner

Depois de uma almoço rápido, mais algumas palestras de hacking. Barnaby Jack mostrou na sua palestra “Life Threatening Vulnerabilities” que falhas de segurança em equipamentos médicos podem matar com facilidade, através de uma demonstração ao vivo e à cores de uma aplicação que ele mesmo desenvolveu para controlar remotamente uma bomba de insulina.

O EVENTO

No geral, foi um ótimo evento. Palestras altamente técnicas e ótima oportunidade de networking com as principais empresas da área. Os dois únicos pontos negativos: ausência de sinal Wi-Fi em quase todas as salas das apresentações e falta de opções para almoço (apenas salada ou lanche).

Volto ao Brasil com uma perspectiva melhor do mercado, e com várias idéias, contatos e possibilidades de futuros projetos para a comunidade de sistemas embarcados no Brasil.

Que venha agora o ESC Brasil 2012!

Um abraço,

Sergio Prado

Posts relacionados:

1. ESC Silicon Valley 2012 — Dia 3
2. ESC Silicon Valley 2012 — Dia 1
3. ESC Silicon Valley 2012 — Dia 2

Sergio Prado atua com desenvolvimento de software para sistemas embarcados há mais de 15 anos. É sócio-fundador da Embed­ded Lab­works, uma empresa focada em te aju­dar a desen­volver soft­ware de qual­i­dade para sis­temas embar­ca­dos. Se você pre­cisa de ajuda para desen­volver seu pro­duto, ou quer saber mais sobre o que a Embed­ded Lab­works pode fazer por você, acesse http://e-labworks.com/servicos.

Este post foi originalmente publicado em ESC Silicon Valley 2012 — Dia 4.

Hoje o dia foi tranquilo. Depois da “andança” de ontem, fiquei basicamente assistindo às palestras do ESC e do Android Summit.

Comecei o dia assistindo à palestra “Mixed-Criticality Embedded System Architectures on Android”, que apesar do nome grande, tinho foco no uso do Android em sistemas críticos, que requerem certo nível de segurança. A idéia principal da palestra era o fato de que você não consegue atingir aos requisitos de segurança usando apenas a versão padrão (vanilla) do Android.

Depois de uma apresentação do Android, seu sucesso na área de embarcados, e os desafios envolvidos, o palestrante mostrou as diversas falhas de segurança existentes no SO, e os diversos mecanismos para corrigir o problema, como encriptação, multiboot e uso de hypervisors e microkernels.

Assisti depois duas seções patrocinadas pela NXP.

A palestra “Easy Dual-Core Development and Debugging with Cortex-M4/M0″ falou sobre a linha LPC4300, um dual-core Cortex-M4 e Cortex-M0 da NXP, que é uma opção interessante para separar processamento e controle. O processamento pode ser feito através de um Cortex-M4, que é basicamente um Cortex-M3 com capacidades de DSP, e o controle fica por conta do Cortex-M0. Os dois cores se comunicam via interrupção e memória compartilhada. De brinde, todos os participantes levaram o kit LPC4330-Xplorer para casa.

A segunda palestra patrocinada pela NXP foi a “Getting Started with FreeRTOS on NXP’s LPC1769 Microcontroller”, ministrada pelo próprio criador do FreeRTOS, Richard Barry. O tempo era escasso, mas o Richard conseguiu passar uma visão geral de seu RTOS, e executar algumas aplicações demo no kit LPCXpresso, um Cortex-M3 da NXP. Também fomos presenteados com um kit LPCXpresso. No fim da palestra, bati um papo rápido com o Richard, já que na ESC Brasil deste ano minha palestra será exatamente sobre o FreeRTOS.

Logo após o almoço participei de um (lotado) hands-on da Freescale usando o seu interessante Tower System:

Bem parecido com o hands-on da Micrium, só que com menos tempo disponível, o objetivo era usar o MQX (RTOS da Freescale), para aprender sobre criação de tarefas e mecanismos de sincronização.

Logo depois fui para a palestra “Optimization for Embedded System”, que falava basicamente sobre técnicas de hardware e software para otimizar sistemas embarcados por tamanho, tempo de execução, consumo de energia e custo. Achei a palestra um pouco fraca, muita teoria e blá-blá-blá, mas nada muito prático.

Fui então dar uma volta no hall de expositores, e acabei assistindo à apresentação “Geeks DIY Lab & Giveaways from Raspberry Pi”, que era basicamente uma competição entre 7 participantes pelo melhor projeto DIY (Do-it yourself). A decisão era do público. Foi bem divertido.

A última palestra que assisti foi “Advanced Compiler Optimizations for the Smallest, Fastest Code”, onde o palestrante Greg Davis, diretor da área de compiladores da Green Hills, falou sobre técnicas usadas por compiladores para otimizar o código por tamanho e por tempo de execução.

Amanhã é o último dia do evento, e provavelmente irei assistir todas palestas do Black Hat. Até lá!

Um abraço,

Sergio Prado

Posts relacionados:

1. ESC Silicon Valley 2012 — Dia 1
2. ESC Silicon Valley 2012 — Dia 2
3. Creative Commons e ESC 2012

Sergio Prado atua com desenvolvimento de software para sistemas embarcados há mais de 15 anos. É sócio-fundador da Embed­ded Lab­works, uma empresa focada em te aju­dar a desen­volver soft­ware de qual­i­dade para sis­temas embar­ca­dos. Se você pre­cisa de ajuda para desen­volver seu pro­duto, ou quer saber mais sobre o que a Embed­ded Lab­works pode fazer por você, acesse http://e-labworks.com/servicos.

Este post foi originalmente publicado em ESC Silicon Valley 2012 — Dia 3.

Como diria um recente amigo meu de Santa Rita, hoje o dia ficou entre fantástico e excepcional! Fiz ótimos contatos, e também contei um pouco com a sorte. Mas vamos “começar pelo começo”!

OLHA O JACK AÍ!

Pois é, Jack Ganssle é sinônimo de ESC e vice-versa. E lá estava ele mais uma vez com suas palestras sobre boas práticas de desenvolvimento de software embarcado. Esta manhã, ele apresentou o tema “Mars ate my spacecraft”, um tema já batido, mas que eu ainda não havia assistido. Então fui lá.

Como sempre, as palestras do Jack são sempre informativas e engraçadas. O tema principal era sobre as falhas em projetos da Nasa. E como eles (não) aprenderam com os erros. Jack falou basicamente sobre a importância de inspeção de código, qualidade dos testes, tratamento de exceções e uso de watchdogs, uso de ferramentas de controle de versão, etc. A mensagem final era a seguinte: “Focar em corrigir bugs não é o melhor caminho para desenvolver um software de qualidade”.

No fim, fui dar um olá para o Jack, que me disse não ir ao ESC Brasil este ano, já que junho é o mês que ele costuma velejar com a família. Boa viagem Jack!

KEYNOTE

Gostaria de pular esta parte, se vocês me permitirem, porque o primeiro keynote do evento foi … Bem, na verdade não foi. Um músico sem muito carisma falando (e cantando) em uma conferência de sistemas embarcados… Deixa pra lá.

Cinco minutos após o início do keynote tirei a foto abaixo e voltei para o universo dos geeks!

JASON KRIDNER

Foi quando liguei para o Jason Kridner para ver se ele estava disponível para um bate-papo. Para quem não sabe, Jason trabalha na Texas e é o cara responsável pelo projeto e pela comunidade da Beagleboard e da Beaglebone.

A conversa foi fantástica, e vocês podem aguardar que em breve terei algumas novidades sobre o meu treinamento de Linux embarcado com os “cachorrinhos” da Texas… :)

MUITO BATE-PAPO

O centro de exposições abriu às 11:30, e não saí mais de lá. Esqueci que estava rolando uma conferência com mais de 50 palestras lá fora. Todas as principais empresas da área de embarcado estavam lá. Tentei bater um papo com cada uma delas, incluindo NXP, TI, Freescale, Renesas, Atmel, Microchip, NI, Micrium, Mentor Graphics, Wind River, Intel, AMD, IAR e ARM.

Em cada uma das conversas, enfatizei bastante o tamanho do mercado de embarcados no Brasil. Em algumas delas, acredito que tenha “plantando uma sementinha”. Quem sabe não colhemos algo num futuro próximo? :)

PURA SORTE

Tenho certeza que tem gente que só vai no ESC para ganhar os brindes, que eles chamam de “giveaways”. Ou vocês acham que a senhora de vestido azul escondida na imagem abaixo estava interessada na arquitetura ARM?

Na verdade ela estava esperando (assim como eu) os intermináveis 15 minutos da palestra para o sorteio de um Kindle Touch. Não foi desta vez.

Mas para mim foi em outras 3!

Ontem ganhei no hands-on do Matt Gordon o livro do uC/OS-III baseado na plataforma da Renesas. Hoje fui sorteado em uma mini-palestra da ExpressLogic e ganhei uma lupa!

Mas olhem só, durante o dia participei de um mini-curso sobre a IDE de desenvolvimento para Linux embarcado da Mentor Graphics, onde todos os participantes estavam concorrendo à uma Pandaboard. No fim do dia recebi uma ligação do pessoal da Mentor dizendo que fui sorteado! Era a que faltava na minha coleção! :) Portanto, aguardem que em breve escreverei um artigo sobre ela…

Lá mesmo no estande de Mentor tive o prazer de conhecer pessoalmente Colin Walls, que entrevistei um tempo atrás. Ele cumpriu uma promessa que fez a mim por e-mail, e me deu o nova edição de seu livro “Embedded Software — The Works”. Obrigado Collin!

Amanhã tem mais!

Um abraço,

Sergio Prado

Posts relacionados:

1. ESC Silicon Valley 2012 — Dia 1

Sergio Prado atua com desenvolvimento de software para sistemas embarcados há mais de 15 anos. É sócio-fundador da Embed­ded Lab­works, uma empresa focada em te aju­dar a desen­volver soft­ware de qual­i­dade para sis­temas embar­ca­dos. Se você pre­cisa de ajuda para desen­volver seu pro­duto, ou quer saber mais sobre o que a Embed­ded Lab­works pode fazer por você, acesse http://e-labworks.com/servicos.

Este post foi originalmente publicado em ESC Silicon Valley 2012 — Dia 2.

O primeiro dia do evento foi bem tranquilo. Na verdade, a própria cidade de San Jose é bem tranquila. Talvez seja o frio!

Uma multidão e muito tumulto às 08:00

Mas lá dentro do centro de convenções as coisas estavam bem quentes. Enquanto as empresas preparavam seus quiosques para a exposição que só começa amanhã, o dia foi recheado de mini-cursos.

E o problema era exatamente escolher qual mini-curso participar. Eram oito na parte da manhã, sete na parte da tarde, mais dois o dia inteiro. Na parte da manhã, participei do Hands-on do uCOS-III com o Matt Gordon da Micrium, com o tema “Fundamentals of Real-Time Kernels”. Na parte da tarde, assisti à ótima apresentação de Dan Saks com o tema “The Most Misunderstood Features of C”.

UCOS-III

A seção começou com pouca gente, talvez por causa do horário (começou pontualmente às 08:00). Logo de cara a infraestrutura me chamou a atenção. Como o mini-curso era no formato de hands-on, tinhamos cerca de 60 laptops, cada um com um kit bem legal da Renesas, que ao fim pudemos levar para casa.

O treinamento foi aplicado pelo Matt Gordon (quem foi no último ESC Brasil deve se lembrar dele), e estava dividido entre teoria e quatro atividades práticas:

1. Usando o nova IDE da Renesas E2Studio (baseado em Eclipse).
2. Criando e executando tarefas.
3. Trabalhando com interrupções.
4. Mecanismos de sincronização.

Labworks em tempo real!

Foram 4 horas muito bem aproveitadas, com exercícios bastante didáticos, principalmente para quem esta começando ou pretende começar a trabalhar com RTOSs.

No final da apresentação conversei com o Matt, e ele me disse que tem a intenção de trazer este mesmo mini-curso para o ESC Brasil. Vamos torçer!

C NA VEIA

A palestra do Dan foi fantástica. Saí de lá querendo escrever meu próprio compilador! :)

O tema, numa tradução livre, foi “As funcionalidades mais obscuras da linguagem C”. Ele expôs com propriedade diversos conceitos da linguagem, mas num formato claro e direto. Definição e declaração de funções, passagens de parâmetros, qualificadores de tipo, declarações abstratas, strings, ponteiros e arrays, escopo, linkage e storage location, etc.

Se você acha que conhece tudo de C ou C++, devia assistir à uma palestra do Dan e rever seus conceitos! Eu o fiz! :) 

E com certeza o aprendizado que obtive nesta palestra irá gerar alguns artigos bem interessantes por aqui.

Hora de descansar. Amanhã tem mais!

Um abraço,

Sergio Prado

Posts relacionados:

1. Creative Commons e ESC 2012

Sergio Prado atua com desenvolvimento de software para sistemas embarcados há mais de 15 anos. É sócio-fundador da Embed­ded Lab­works, uma empresa focada em te aju­dar a desen­volver soft­ware de qual­i­dade para sis­temas embar­ca­dos. Se você pre­cisa de ajuda para desen­volver seu pro­duto, ou quer saber mais sobre o que a Embed­ded Lab­works pode fazer por você, acesse http://e-labworks.com/servicos.

Este post foi originalmente publicado em ESC Silicon Valley 2012 — Dia 1.

As últimas duas semanas foram realmente bastante agitadas para mim. Coloquei o site da Embedded Labworks no ar, formei a primeira turma de Linux embarcado na Mosaico e passei uma semana em Santa Rita/MG treinando a equipe da Leucontron, claro, em Linux embarcado! :)

Enquanto continuo minha missão de disseminar o ensino de Linux e software livre em sistemas embarcados, neste post vou fazer apenas alguns anúncios. Prometo que os posts voltarão com tudo em abril!

CREATIVE COMMONS

A partir desta data todo o blog é oficialmente licenciado pelo Creative Commons BY-NC-SA 3.0.

Isso significa que você tem o direito de copiar, modificar, adaptar e distribuir as alterações que realizar nos trabalhos que publico aqui no blog.

Da mesma forma, você precisa atribuir a autoria do trabalho original, e qualquer alteração que fizer precisa ser liberada sob a mesma licença. Além disso, você não pode usar nenhum trabalho que publico aqui para fins comerciais sem minha prévia autorização.

Com isso, espero que mais pessoas continuem a usar meu trabalho para dissseminar o conhecimento em sistemas embarcados e software livre, ajudando a capacitar e motivar os profissionais e aspirantes da área.

ESC SILICON VALLEY 2012

Este ano estarei no ESC SV 2012, que acontece entre os dias 26/03 e 29/03. À propósito, estou escrevendo este post no aeroporto de Houston esperando o embarque para San Jose/CA!

Neste ano o evento chama-se Design West, e trás além da convencional conferência de sistemas embarcados, os eventos Android Summit, Black Hat Summit, DesignMED, Multicore DevCon, EDN’s Designing with LEDs e Sensors in Design.

Será realmente um evento recheado de assuntos da nossa área. Pretendo publicar no blog um post por dia de evento. Portanto, não percam!

ESC BRASIL 2012

No ano passado o ESC Brasil superou as expectativas de muita gente. Para quem perdeu, escrevi um relato sobre os dois dias do evento aqui e aqui.

Este ano o ESC Brasil será bem maior, com mais expositores, e a possibilidade única de fazer bons networkings na área.

A grade de palestras ainda não foi divulgada, mas posso confirmar à vocês que eu estarei lá apresentando o tema “Desenvolvendo com o FreeRTOS”. Vocês terão mais informações sobre o evento e sobre minha palestra em breve!

Por enquanto é só. Hora de embarcar. Por hora, que venha o ESC Silicon Valley 2012!

Um abraço,

Sergio Prado

Sem posts relacionados.

Sergio Prado atua com desenvolvimento de software para sistemas embarcados há mais de 15 anos. É sócio-fundador da Embed­ded Lab­works, uma empresa focada em te aju­dar a desen­volver soft­ware de qual­i­dade para sis­temas embar­ca­dos. Se você pre­cisa de ajuda para desen­volver seu pro­duto, ou quer saber mais sobre o que a Embed­ded Lab­works pode fazer por você, acesse http://e-labworks.com/servicos.

Este post foi originalmente publicado em Creative Commons e ESC 2012.

Na parte 1 desta série de artigos, vimos uma intro­dução à sis­temas de arquivo em Linux embar­cado, incluindo os prin­ci­pais tipos de sis­temas de arquivo para dis­pos­i­tivo de bloco, e quando usar cada um deles, além de sis­temas de arquivo com­prim­i­dos, voláteis e via rede.

Nesta segunda parte, estudaremos as memórias flash, o sub-sistema MTD do kernel, os principais sistemas de arquivo para flash, e por fim, veremos como selecionar o melhor sistema de arquivo para o seu produto com Linux embarcado.

AS MEMÓRIAS FLASH

Algumas limitações diferem as memórias flash de dispositivos de bloco tradicionais como HDs e floppy disks.

As memórias flash só podem ser apagadas em blocos. Estes blocos são chamados de erase blocks, e podem variar de algumas dezenas para algumas centenas de kB. Quando você apaga um bloco da flash, todos os bits assumem tipicamente o valor 1. Com um bloco apagado, você pode escrever em qualquer posição da flash. Porém, se você escrever 0 em qualquer um dos bits de qualquer posição da flash, você só consegue fazê-lo voltar para 1 apagando todo o bloco correspondente da flash!

Outra limitação das memórias flash é a quantidade de vezes que você pode apagar e escrever nela (program/erase cycles). Esta limitação, dependendo do modelo e do fabricante da flash, pode variar entre 100.000 e 1.000.000 ciclos. Parece muito, mas basta você deixar sua aplicação fazendo log em memória flash para transformá-la em um peso de papel! É por este motivo que existe uma funcionalidade chamada wear leveling, que pode ser implementada por software ou diretamente em chips controladores de flash.

Imagine um arquivo armazenado em determinado bloco da flash. Agora imagine que este arquivo é atualizado constantemente. Em pouco tempo, aquele bloco da flash será inutilizado. Com o “wear leveling”, este arquivo é remapeado de tempos em tempos para outros blocos da flash, melhorando a vida útil da memória flash consideravelmente.

Mesmo assim, depois de certo tempo de uso da flash, um ou mais blocos serão inutilizados. Por este motivo, existe uma técnica chamada de BBM (Bad Block Management). Quando sai de fábrica, as memórias flash já possuem gravada nelas uma tabela de bad blocks. Toda camada de software que trabalha com memórias flash deve ser capaz de ler e identificar estes bad blocks para não utilizar regiões inválidas da flash.

As memórias flash podem ainda ser divididas em dois tipos principais:

• As memórias flash NOR, que possuem acesso aleatório para leitura de dados (conseguem endereçar byte a byte), velocidade alta para leitura mas lenta para escrita, baixa densidade (cada byte ocupa mais espaço), menor durabilidade e alto custo por MB. É usada principalmente para armazenar código (substituir as antigas memórias ROM).
• As memórias flash NAND, que possuem acesso de leitura apenas em blocos (para ler um byte precisa ler o bloco correspondente), velocidade baixa para leitura mas alta para escrita, alta densidade (cada byte ocupa menos espaço), maior durabilidade e baixo custo por MB. É usada principalmente para armazenar dados.

Muito bem, vimos que as memórias flash são bem diferentes quando comparadas com os tradicionais dispositivos de bloco. É por este motivo que dentro do Linux as memórias flash são gerenciadas por um sub-sistema separado, chamado de MTD (Memory Technology Devices).

O SUB-SISTEMA MTD

O sub-sistema MTD é dividido basicamente em duas camadas:

A camada de baixo (MTD chip drivers) conversa diretamente com o hardware, enquanto que a camada de cima (MTD User modules) implementa os diferentes sistemas de arquivo e mecanismos de acesso à flash.

Cada memória deve ter o seu “MTD chip driver”, para possibilitar o acesso ao hardware da flash. Mas cada sistema pode usar um ou mais “MTD User modules”. Cada um deles irá tratar de forma diferentes a flash. É neste contexto que as memórias flash também são chamadas de dispositivos MTD. As partições de todos os dispositivos MTD do sistema podem ser listadas no Linux com o comando abaixo:

$ cat /proc/mtd
dev:  size     erasesize   name
mtd0: 00080000 00020000  "X-Loader"
mtd1: 001e0000 00020000  "U-Boot"
mtd2: 00020000 00020000  "U-Boot Env"
mtd3: 00400000 00020000  "Kernel"
mtd4: 0f980000 00020000  "File System"

O driver mtdchar implementa o módulo “char device” da flash. Ele cria um dispositivo de caractere para cada dispositivo MTD no sistema, normalmente chamado de /dev/mtdX, onde X é o número da partição. Com este módulo, você tem acesso sequencial (byte-a-byte) em toda a flash. Além disso, ele disponibiliza comandos ioctl() para você poder manipular a flash (ler informações, apagar/gravar na flash, etc). A principal utilidade deste módulo é no gerenciamento da flash, quando usamos o pacote mtd-utils. Este pacote possui algumas ferramentas como flash_eraseall para apagar todo o dispositivo, flashcp para escrever em memórias flash NOR e nandwrite para escrever um memórias flash NAND. Para mais informações, visite a página do projeto em http://www.linux-mtd.infradead.org/.

O driver mtdblock implementa o módulo “block device” da flash. Ele cria um dispositivo de bloco para cada dispositivo MTD no sistema, normalmente nomeado /dev/mtdblockX, onde X é o número da partição. Este módulo permite acesso de leitura/escrita por bloco, como se fosse um HD mesmo, mas não gerencia bad blocks e também não trabalha com wear leveling em escritas. Ele pode ser usado para montar um sistema de arquivo read-only como o squashfs.

Já se você quiser um sistema de arquivo que trabalhe com todas as limitações da flash, incluindo bad blocks e wear leveling, você vai precisar de um sistema de arquivo específico para flash.

SISTEMAS DE ARQUIVO PARA FLASH

O YAFFS2 é um sistema de arquivo mais antigo, e suporta basicamente memórias flash NAND. Tem um tempo de boot rápido, trabalha com wear leveling e algoritmo ECC (Error Checking and Correction) para garantir a confiabilidade dos dados. Sua única desvantagem é o fato de não possuir a capacidade de comprimir os dados.

É por isso que aos poucos ele foi substituido pelo JFFS2, o mais usado e padrão atual. O JFFS2 possui todas as caracteristicas do YAFFS2, além de suportar memórias flash NOR e comprimir os dados em tempo de execução, economizando espaço na flash. Sua única deficiência é no tempo de boot. O JFFS2 não armazena informações da estrutura de diretórios, isso significa que para o kernel identificar a estrutura de diretórios e montar uma partição JFFS2, ele precisa varrer toda a flash. Por este motivo, o tempo de boot fica realmente lento em memórias flash muito grandes. Habilitando no kernel a opção CONFIG_JFFS2_SUMMARY reduz drasticamente este tempo de montagem.

Já o UBIFS (Unsorted Block Images Filesystem) é um sistema de arquivo para flash mais recente. É considerado a evolução do JFFS2, e trabalha com volumes lógicos em cima de dispositivos MTD. Tem todas as vantagens do YAFFS2 e do JFFS2. Sua única desvantagem é o overhead de metadados. Ou seja, a quantidade de dados que ele precisa armazenar para controlar as partições pode ser muito grande quando trabalhamos com memórias flash com pouca capacidade de armazenamento. Mas com a capacidade das memórias flash aumentando cada vez mais, deve se tornar nos próximos anos o sistema de arquivo padrão para dispositivos MTD.

CUIDADOS COM MEMÓRIAS FLASH

Mesmo trabalhando com um sistema de arquivo voltado à memórias flash, você precisa tomar alguns cuidados para aumentar a vida útil do dispositivo, dentre eles:

• Não use a memória flash como região de swap!
• Não use a memória flash para armazenamento volátil como logs e arquivos temporários (use tmpfs nestes casos).
• Monte seu rootfs como apenas leitura, ou use o squashfs, quando possível.
• Use a opção de montagem ”noatime” para evitar a escrita na flash toda vez que você ler um arquivo.
• Não use a opção de montagem ”sync” (com esta opção habilitada, uma atualização no sistema de arquivos atualiza imediatamente a flash).
• Você pode decidir se quer ou não usar um sistema de arquivo com journal. Com ele aumenta-se a quantidade de escritas, mas deixa-se o sistema mais resistente à problemas de queda de energia.

EMULANDO DISPOSITIVOS DE BLOCO

Pendrives e cartões SD/MMC trabalham com memórias flash. Mas como é que o kernel os identifica e gerencia como dispositivos de bloco? Como conseguimos montar nestes dispositivos sistemas de arquivo voltados à dispositivos de bloco como o ext3?

Isso é possível porque estes dispositivos possuem uma controladora implementada em hardware/firmware que emula um dispositivo de bloco em cima da memória flash. Esta controladora é que faz o controle de bad blocks e wear leveling. No nível do sistema operacional, não temos nenhum controle sobre esta controladora, nem podemos acessar diretamente a memória flash. Ou seja, como não conhecemos a qualidade desta controladora, é altamente recomendável limitar o número de escritas nestes dispositivos.

ESCOLHENDO UM SISTEMA DE ARQUIVO

Vimos nestes dois artigos diversas soluções de sistemas de arquivo para Linux embarcado. Como escolher o melhor para sua aplicação?

O diagrama abaixo disponibilizado pelo pessoal da Free Electrons ilustra muito bem este processo de decisão, dependendo das necessidades do seu projeto:

Pois é, não tem segredo!

Procurei expor nesta série de artigos os detalhes e as características dos principais sistemas de arquivo usados em Linux embarcado. Agora é só analisar os requisitos do seu produto e escolher o mais adequado para sua aplicação.

Um abraço,

Sergio Prado

Posts relacionados:

1. Sistemas de arquivo em Linux embarcado — Parte 1
2. Linux Device Drivers — Parte 1

Sergio Prado atua com desenvolvimento de software para sistemas embarcados há mais de 15 anos. É sócio-fundador da Embed­ded Lab­works, uma empresa focada em te aju­dar a desen­volver soft­ware de qual­i­dade para sis­temas embar­ca­dos. Se você pre­cisa de ajuda para desen­volver seu pro­duto, ou quer saber mais sobre o que a Embed­ded Lab­works pode fazer por você, acesse http://e-labworks.com/servicos.

Este post foi originalmente publicado em Sistemas de arquivo em Linux embarcado — Parte 2.