Blog do Sergio Prado

Credenciamento ESC Brazil 2013

Sergio Prado — Tue, 18 Jun 2013 23:57:10 +0000

Foi aberto o credenciamento para o ESC Brazil 2013, que será realizado nos dias 27 e 28 de agosto em São Paulo/SP.

Este ano o evento promete ser maior que a edição do ano passado, com a participação das maiores fabricantes de chip do mundo, distribuidores e provedores de soluções em sistemas embarcados.

O programa de conferências ainda não esta disponível, mas posso adiantar a vocês que estarei lá novamente! Desta vez falarei sobre os desafios de portar o sistema operacional Android para uma plataforma de hardware.

Assim que a grade de palestras da conferência for divulgada, publicarei aqui no blog.

O credenciamento para a feira pode ser realizado aqui.

Um abraço,

Sergio Prado

Sergio Prado atua com desenvolvimento de software para sistemas embarcados há mais de 15 anos. É sócio-fundador da Embedded Labworks, uma empresa focada em te ajudar a desenvolver software de qualidade para sistemas embarcados. Se você precisa de ajuda para desenvolver seu produto, ou quer saber mais sobre o que a Embedded Labworks pode fazer por você, acesse http://e-labworks.com/servicos.

Este post foi originalmente publicado em Credenciamento ESC Brazil 2013.

Promoção de case para a Raspberry Pi

Sergio Prado — Fri, 14 Jun 2013 01:10:35 +0000

Alguns meses atrás divulguei um case brasileiro, de qualidade e preço acessível, para a Raspberry Pi.

Esta semana recebi um novo contato da Spon Web Store, empresa responsável por sua produção e comercialização, sobre uma nova promoção deste case.

O preço foi reduzido para R$35,90, com frete grátis e gravação personalizada de brinde para os leitores do blog. :-)

O case pode ser adquirido aqui.

Obs: Este blog não tem nenhuma relação com a Spon Web Store. Estou divulgando apenas porque o trabalho é bem feito e o preço acessível.

Para mais informações ou dúvidas vocês podem entrar em contato diretamente com o Ricardo Colchete por email.

Um abraço!

Sergio Prado

Este post foi originalmente publicado em Promoção de case para a Raspberry Pi.

User Space Device Drivers no Linux — Parte 2

Sergio Prado — Fri, 07 Jun 2013 10:51:07 +0000

Na parte 1 deste artigo estudamos as vantagens e desvantagens de um driver de dispositivo para Linux rodando em espaço de usuário, e cobrimos algumas possíveis soluções através da chamada de sistema mmap() e do framework UIO.

Neste artigo estudaremos alguns frameworks do kernel que possibilitam acessar diretamente algumas interfaces de hardware e barramentos, incluindo GPIO, USB, SPI e I2C.

Vamos então começar com o framework de GPIO do kernel.

GPIO

O Linux possui uma interface no sysfs capaz de exportar para o usuário os GPIOs disponíveis no sistema. Para usar esta funcionalidade, basta habilitar a opção CONFIG_GPIO_SYSFS no menu de configuração do kernel.

Com esta funcionalidade habilitada, o acesso aos GPIOs será disponibilizado em /sys/class/gpio/. Neste diretório teremos um arquivo chamado export, que possibilita exportar para o usuário um GPIO do sistema.

Se eu quiser por exemplo usar o GPIO 10 do sistema, devo escrever 10 neste arquivo:

$ echo 10 > /sys/class/gpio/export

Neste mesmo diretório temos o arquivo unexport, que desfaz o export:

$ echo 10 > /sys/class/gpio/unexport

Mas como sei o número do GPIO no sistema? No Linux, os GPIOs possuem uma numeração única. Por exemplo, imagine uma CPU com 4 portas de GPIO, cada uma contendo 32 GPIOs, totalizando 128 GPIOs. O GPIO 1 da porta 1 (GPIO1.1) representa o GPIO 1 no Linux. O GPIO 32 da porta 1 (GPIO1.32) representa o GPIO 32 no Linux. Já o GPIO 1 da porta 2 (GPIO2.1) representa o GPIO 33 no Linux. O GPIO 32 da porta 2 (GPIO2.32) representa o GPIO 64 no Linux. E a contagem continua até 128.

Portanto, para descobrir o número do GPIO que você deve usar para fazer o export, basta olhar no esquemático da placa qual a porta e o GPIO que pretende utilizar e fazer o cálculo.

Com o GPIO exportado, será criado o diretório /sys/class/gpio/gpioN, onde N é o número do GPIO exportado. Neste diretório teremos alguns arquivos, dentre eles:

direction: configura o GPIO como entrada (“in”) ou saída (“out”).
value: quando configurado como entrada, serve para ler o GPIO. Quando configurado como saída, serve para escrever no GPIO (“0” ou “1”).

Se eu quiser por exemplo setar o GPIO 35, basta executar os comandos abaixo:

$ echo 35 > /sys/class/gpio/export
$ echo out > /sys/class/gpio/gpio35/direction
$ echo 1 > /sys/class/gpio/gpio35/value
$ echo 35 > /sys/class/gpio/unexport

E se eu quiser ler o GPIO 47, os comandos abaixo fazem isso:

$ echo 47 > /sys/class/gpio/export
$ echo in > /sys/class/gpio/gpio47/direction
$ cat /sys/class/gpio/gpio47/value
$ echo 47 > /sys/class/gpio/unexport

Podemos perceber então que esta interface permite acessar diretamente qualquer dispositivo de hardware conectado à um GPIO do sistema. E nada te impede de criar uma aplicação e usar as APIs de leitura e escrita em arquivo para acessar os GPIOs da placa.

A documentação desta interface esta disponivel nos fontes do kernel em Documentation/gpio.txt.

USB

O Linux é capaz de exportar para o usuário o acesso ao barramento USB do sistema, possibilitando escrever drivers de dispositivos USB em espaço de usuário.

Nas versões mais antigas do kernel, o acesso ao barramento USB era realizado via usbfs, montado em /proc/bus/usb. Nas versões mais novas do kernel o acesso ao barramento USB é exportado para o usuário em /dev/bus/usb/.

$ tree /dev/bus/usb/
/dev/bus/usb/
├── 001
│   ├── 001
│   ├── 002
│   ├── 003
│   ├── 004
│   ├── 005
│   ├── 009
│   └── 010
├── 002
│   ├── 001
│   ├── 002
│   └── 003
├── 003
│   ├── 001
│   └── 002
└── 004
└── 001

Cada diretório dentro de /dev/bus/usb/ representa um barramento USB do sistema, e cada arquivo dentro destes diretórios representa um dispositivo conectado ao barramento.

Uma aplicação pode acessar diretamente estes arquivos para conversar com o dispositivo conectado ao barramento USB.

Como as regras para comunicação com os dispositivos usando esta interface são mais complexas, existe uma biblioteca que abstrai e facilita o acesso chamada libusb. É bastante comum encontrar drivers em espaço de usuário para impressoras, scanners e adaptadores JTAG usando esta biblioteca. E se você pretende desenvolver um driver em espaço de usuário para um dispositivo USB, provavelmente também deverá usá-la.

I2C

O kernel possibilita o acesso ao barramento I2C através da funcionalidade i2c-dev. Para usá-la, basta habilitar a opção CONFIG_I2C_CHARDEV no menu de configuração do kernel.

Com esta funcionalidade habilitada, os barramentos I2C serão exportados em /dev/i2c-X, onde X é o número do barramento.

Exemplo de um sistema com dois barramentos I2C:

$ ls /dev/i2c*
/dev/i2c-0 /dev/i2c-1

O acesso ao barramento pode ser realizado normalmente com a API de acesso à arquivos. Por exemplo, este é o código para ler o primeiro registro de um dispositivo conectado ao barramento I2C no endereço 0x1C:

void main(void)
{
    int fd, val;
 
    fd = open("/dev/i2c-0", O_RDWR);
 
    ioctl(fd, I2C_SLAVE, 0x1C);
 
    read(fd, &val, 4);
 
    close(fd);
}

A documentação sobre como utilizar esta interface encontra-se nos fontes do kernel em Documentation/i2c/dev-interface.

Existe ainda um projeto chamado i2c-tools que provê um conjunto de ferramentas e uma biblioteca de funções para facilitar o desenvolvimento de drivers I2C em user space.

Por exemplo, a ferramenta i2cdetect permite detectar todos os dispositivos conectados à um determinado barramento I2C:

$ i2cdetect -y 0
0 1 2 3 4 5 6 7 8 9 a b c d e f
00: -- -- -- -- -- -- -- -- -- -- -- -- --
10: -- -- -- -- -- -- -- -- -- -- -- -- UU -- -- --
20: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
30: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
40: -- -- -- -- -- -- -- -- 48 -- -- -- -- -- -- --
50: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
60: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
70: -- -- -- -- -- -- -- --

As ferramentas i2cset e i2cget permitem escrever e ler o barramento I2C, respectivamente:

$ i2cset -f -y 0 0x48 10 0xA5
$ i2cget -f -y 0 0x48 10
0xA5

E a ferramenta i2cdump permite fazer um dump de todos os registros de um determinado dispositivo conectado ao barramento I2C:

$ i2cdump -f -y 0 0x48
No size specified (using byte-data access)
0 1 2 3 4 5 6 7 8 9 a b c d e f 0123456789abcdef
00: 00 29 21 00 00 40 01 00 00 02 ff 00 00 c0 ef 3a .)!..@?..?...??:
10: 66 10 70 99 61 40 07 00 00 77 77 07 77 03 a5 56 f?p?a@?..ww?w??V
20: 63 a3 13 55 24 35 aa 00 b0 64 1b fe dd dd 5e 62 c??U$5?.?d????^b
30: 57 7e 4e 5c 7f 6a 42 42 5f 4c 45 42 60 00 9b 2b W~N\?jBB_LEB`.?+
40: b7 00 b5 01 0f 0e 36 cf 00 5f 00 00 00 00 00 00 ?.????6?._......
50: 00 08 00 00 00 00 2b 00 08 06 ff 00 00 ff 09 00 .?....+.??....?.
60: e0 10 00 e0 10 00 bb 42 62 c0 00 00 00 00 00 00 ??.??.?Bb?......
70: 00 00 01 01 00 80 00 01 01 00 00 00 00 00 00 00 ..??.?.??.......
80: 00 a3 18 00 00 00 00 00 00 00 00 00 00 00 00 00 .??.............
90: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
a0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
b0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
c0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
d0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
e0: 00 99 00 0a 44 44 00 40 00 00 00 00 00 00 00 00 .?.?DD.@........
f0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................

SPI

O kernel possibilita o acesso ao barramento SPI através da funcionalidade spidev. Para usar esta funcionalidade, basta habilitar a opção CONFIG_SPI_SPIDEV no kernel.

Com esta funcionalidade habilitada, os barramentos SPI são exportados em /dev/spidevB.C, onde B é o número do barramento e C é o chip-select do slave conectado ao barramento. O acesso também é feito através da API de arquivos (open(), read(), write(), ioctl(), etc).

A documentação sobre como utilizar esta interface encontra-se nos fontes do kernel em Documentation/spi/spidev.

E TEM MAIS?

Sim! Se você procurar, vai encontrar muitos outros mecanismos para desenvolver um device driver no Linux em user space, cada um com seus casos de uso:

uinput: criar e manipular dispositivos de input em user space.
gadgetfs: desenvolver um driver de gadget USB (USB device).
fuse: implementar um sistema de arquivo em user space.
fusd: framework para rotear o acesso à arquivos de dispositivo para uma aplicação rodando em user space.
cuse: criar drivers de dispositivo de caractere em user space.
buse: criar drivers de dispositivos de bloco em user space.

Pronto para desenvolver seu primeiro driver em user space?

Divirta-se!

Sergio Prado

Este post foi originalmente publicado em User Space Device Drivers no Linux — Parte 2.

UBM 2013 Embedded Market Study

Sergio Prado — Wed, 05 Jun 2013 16:34:07 +0000

No começo deste ano a UBM realizou sua pesquisa anual sobre o mercado mundial de sistemas embarcados, incluindo projetos desenvolvidos, tecnologias utilizadas, processos e ferramentas de desenvolvimento, sistemas operacionais, microcontroladores e processadores utilizados, etc.

A pesquisa foi enviada por email para os inscritos nos sites da UBM e da EE Times de 18 de janeiro de 2013 a 13 de fevereiro de 2013. Foram recebidas 2.098 respostas válidas, vindas em sua grande maioria dos EUA e Canadá (61%), com uma parcela na Europa e Ásia (33%), e alguns poucos na América do Sul (3%).

Algumas informações interessantes que pude identificar nesta pesquisa:

A linguagem de programação mais utilizada ainda é a linguagem C com 60%, seguidas por C++ com 21% e Assembly com 5%. Nenhuma indicação de que esta estatística mudará nos próximos anos.
Ainda precisamos de boas ferramentas de debugging. Ela é considerada a ferramenta mais importante, e ao mesmo tempo uma tecnologia que ainda requer muitas melhorias. Concordo!
O uso de sistemas operacionais diminuiu em 4% nos últimos 5 anos (a maioria diz que não precisa!). E assustadoramente, daqueles que usam um RTOS, 19% ainda usam um RTOS desenvolvido internamente!
O uso de um RTOS comercial tem diminuído nos últimos 5 anos (47% para 35%), enquanto que o uso de RTOS de código aberto aumentou (27% para 34%). E para novos projetos, a preferência por um RTOS de código aberto ganha disparado com 37%, contra 29% de RTOS’s comerciais. A resposta para esta tendência esta em uma outra pergunta, sobre o fator principal para a escolha de um sistema operacional. A resposta? A disponibilidade do código-fonte!
Android é o SO mais utilizado, com 16% (aumento de 3% com relação ao ano anterior), e o FreeRTOS é o RTOS mais utilizado com 13%. Os mesmos ainda lideram as estatísticas de sistemas operacionais a serem utilizados em novos projetos, com 28% para o Android e 21% para o FreeRTOS.
A grande maioria dos projetos (60%) são baseados em processadores de 32 bits, enquanto que processadores de 8 e 16 bits ficam na faixa de 16% cada um. À propósito, o que o Arduino esta fazendo na lista de microcontroladores de 8 bits???
A Texas liderou a maioria das pesquisas sobre os fabricantes de chips, incluindo o melhor ecosistema (software, ferramentas, suporte, etc) e chip mais utilizado, mas seguida de perto por Freescale, Microchip e Atmel.
WiFi é disparada a tecnologia wireless mais utilizada em projetos embarcados, seguida na ordem por Bluetooth, redes celulares e Zigbee.
A maioria usa o SVN como ferramenta de controle de versão (41%), seguido pelo Git com 21% (boa!) e CVS com 20%. Como alguém pode ainda estar usando o CVS como ferramenta de controle de versão? :)
3,9% dos que responderam pretendem participar do ESC Brazil 2013 (1,8% a mais que a última pesquisa). E pelas conversas que tenho tido com o pessoal da UBM Brasil, este ano o evento deve ser bem maior que o ano passado!

Enfim, pesquisas nem sempre refletem a realidade, pois dependem de diversas variáveis como o público-alvo, sua localização e mercado de atuação. De qualquer forma, elas podem mostrar (e até influenciar) algumas tendências. Vale a pena dar uma olhada na pesquisa completa, que pode ser baixada de forma gratuita (após um cadastro) aqui.

Um abraço,

Sergio Prado

Este post foi originalmente publicado em UBM 2013 Embedded Market Study.

User Space Device Drivers no Linux — Parte 1

Sergio Prado — Sat, 01 Jun 2013 00:52:58 +0000

Desenvolver um driver para Linux requer conhecimentos multidisciplinares. Quem já participou de uma seção do meu treinamento de drivers sabe muito bem do que estou falando…:)

Sim, você precisa saber ler datasheets e escovar bits. Precisa saber (muito bem) linguagem C, principalmente trabalhar com ponteiros e estruturas de dados mais complexas. Precisa conhecer também arquitetura de sistemas operacionais, e entender como o Linux escalona processos, gerencia a memória e controla o acesso aos dispositivos de I/O. Precisa conhecer os múltiplos sub-sistemas do kernel e sua API, frameworks e infraestruturas de barramento. Enfim, não será do dia para a noite que você se transformará em um desenvolvedor de drivers para o kernel Linux. O processo de aprendizado vai exigir de você muita força de vontade e perseverança.

Mas nem tudo são drivers em kernel space… Sim, é possível escrever uma aplicação em Linux que possa acessar diretamente um dispositivo de hardware! À essa aplicação (ou biblioteca) damos o nome de user space device driver.

E FUNCIONA?

Sim, funciona! E tem algumas vantagens:

Mais fácil de implementar, já que temos acesso às ferramentas e bibliotecas que estamos acostumados a usar no desenvolvimento de aplicações.
Pode ser desenvolvido em qualquer linguagem de programação: C, C++, até Java e Python!
Qualquer bug no driver rodando em espaço de usuário não vai impactar o funcionamento do kernel.
Processo de debugging fica bem mais fácil.
Facilita a distribuição e manutenção do driver, já que o mesmo binário pode rodar em diferentes versões do kernel.
A memória de processo pode ir para swap (o que também pode ser uma desvantagem!).
Se você precisa escrever um driver proprietário, pode evitar problemas com licenças de módulos do kernel.
O driver pode ter processamento intensivo, pois em user space sempre haverá preempção.
Um driver em user space tem acesso completo ao sistema de arquivos.

Mas se fossem apenas vantagens, não existiriam drivers rodando em kernel space! Drivers que rodam em espaço de usuário possuem algumas desvantagens:

Dependendo do acesso realizado pelo driver pode ser necessário ter privilégios de root.
Se não for feito da forma correta, é possível ter problemas de segurança.
Maior latência no tratamento de eventos e overhead de processamento devido às trocas de contexto, cópias de buffers entre kernel space e user space, swap de páginas de memória em disco, etc.
Mais difícil de implementar acesso concorrente aos dispositivos de hardware (o driver deve ter uma arquitetura cliente/servidor).
Sem as vantagens de ter um driver mantido pela comunidade (manutenção, revisão de código, etc).
Problemas de portabilidade do driver em diferentes sistemas, já que cada driver poderá ter seu padrão de comunicação com as camadas mais altas da aplicação.

De qualquer forma, pela facilidade na implementação, um driver em user space pode ser a solução para aquele problema simples que você precisa resolver. Vamos ver então como isso funciona?

COMO FUNCIONA?

O kernel provê alguns mecanismos de acesso direto à um dispositivo de hardware por uma aplicação, dentre eles:

Mapeamento de arquivo em memória com a função mmap().
Userspace I/O (UIO).
Frameworks do kernel (GPIO, USB, I2C, SPI).

Vamos dar uma olhada nestes mecanismos separadamente.

MMAP

O mmap é uma chamada de sistema que possibilita o mapeamento de um arquivo em memória. Tá, mas para que serve isso?

Um exemplo. Todo sistema Linux possui normalmente o arquivo /dev/mem. Esse arquivo é exportado por um módulo do kernel, e possibilita o acesso direto à memória física do hardware! Isso significa que, se você abrir este arquivo e escrever na posição 0 dele, estará escrevendo na primeira posição da memória física do seu hardware! Você precisa ter privilégios de root para executar tal operação.

Desta forma, fica fácil trabalhar com dispositivos de hardware que mapeiam seus registradores em memória. É só identificar o endereço do registrador mapeado em memória, abrir e indexar o /dev/mem, e voilá! Você tem acesso ao seu dispositivo de hardware diretamente de uma aplicação.

Mas abrir, indexar e acessar um arquivo é um procedimento bem mais complicado que simplesmente referenciar um ponteiro. Ele exige o uso da API de acesso à arquivos (open(), read(), write(), lseek(), etc), além de adicionar um overhead de processamento, já que toda operação de acesso à arquivo irá gerar uma chamada de sistema, passando obrigatoriamente pelo kernel.

E se você pudesse ter um ponteiro para referenciar diretamente esta região de memória? É aí que entra a chamada de sistema mmap(). Ela possibilita o mapeamento de qualquer região de um arquivo em memória!

Veja por exemplo o código abaixo:

#define MAP_SIZE 4096UL 
#define MAP_MASK (MAP_SIZE - 1) 
 
void main(void) 
{
    unsigned int *reg;
    void *map_base;
    int fd;
    off_t target = 0x53F04000;
 
    fd = open("/dev/mem", O_RDWR | O_SYNC);
 
    map_base = mmap(0, MAP_SIZE, PROT_READ | PROT_WRITE, MAP_SHARED, fd, 
                    target & ~MAP_MASK);
 
    reg = (int *)(map_base + (target & MAP_MASK));
    reg &= 0x01;
 
    munmap(map_base, MAP_SIZE);
 
    close(fd);
}

Na linha 11 o arquivo /dev/mem é aberto. Na linha 13 mapeio a região de memória que se encontra o registrador 0x53F04000, e na linha 17 eu seto o bit 1 deste registrador! Fácil!

Este mecanismo permite que uma aplicação acesse qualquer dispositivo de I/O mapeado em memória.

Obs: o exemplo acima não verifica o retorno das funções para simplificar o código. Se você for usar este código como base, não se esqueça de verificar o retorno das funções!

O acesso ao framebuffer por exemplo também funciona desta forma. Os drivers de interfaces de vídeo exportam um arquivo em /dev/fbX, possibilitando que uma aplicação ou driver em user space acesse diretamente a memória de vídeo do display.

Existe até uma ferramenta chamada devmem2 (ou devmem no Busybox) para facilitar este acesso na linha de comandos. Por exemplo, o comando abaixo escreve 0x10 no registrador 0x550F00010:

$ devmem2 0x550F00010 b 0x10

Para mais informações sobre a chamada de sistema mmap(), dê uma olhada em sua página de manual:

$ man mmap

O uso do mmap para desenvolver um driver em espaço de usuário tem algumas deficiências. Se você precisar de acesso simultâneo ao dispositivo, precisará implementar um mecanismo cliente/servidor (é o que os drivers de placa de vídeo em user space implementam). Seu uso, se não for bem implementado, pode deixar o sistema inseguro e instável. Além disso, esta interface não provê nenhum mecanismo para tratar interrupções.

É aí que entra o Userspace I/O (UIO).

UIO

O UIO é um framework do kernel, disponível desde a versão 2.6.23, que possibilita acesso direto à um dispositivo de hardware, com suporte básico ao processamento de interrupções.

É composto por um pequeno componente em kernel space responsável pelo mapeamento de memória e pelo registro das interrupções, deixando a lógica do driver para ser implementada em user space. E diferentemente do mmap, permite mapear apenas a memória do dispositivo, e não de todo o sistema. Portanto, é mais seguro de usar.

Mas como ele funciona? Ele exporta um arquivo em /dev/uioX (onde X é o número do device) possibilitando mapear e acessar a memória do dispositivo em espaço de usuário, também via mmap(). E permite capturar interrupções lendo este mesmo arquivo, via funções read() ou select() por exemplo. Uma biblioteca chamada libuio esta disponível para facilitar o uso deste framework.

Veja o exemplo abaixo:

void main(void)
{
    int32_t irq_count, enable_int = 1;
    void *map_addr
    int fd;
 
    fd = open("/dev/uio0", O_RDWR);
 
    map_addr = mmap(NULL, 4096, PROT_READ | PROT_WRITE, 
                    MAP_SHARED, fd, 0);
 
    write(fd, &enable_int, 4);
 
    while (read(fd, &irq_count, 4) == 4) {
        printf("Interrupted!");
    }
 
    munmap(map_addr, 4096);
 
    close(fd);
}

Na linha 7 o arquivo é aberto e na linha 9 o arquivo é mapeado em memória, retornando na variável map_addr um ponteiro para acessar diretamente a região de memória do dispositivo de hardware. Na linha 12 a interrupção é habilitada e na linha 14 o processo bloqueia esperando por uma interrupção.

Obs: este exemplo também não verifica o retorno das funções para simplificar o código. Se você for usar este código como base, não se esqueça de verificar o retorno das funções!

Para mais informações sobre o UIO, dê uma olhada na documentação do kernel aqui.

O UIO tem alguma deficiência? Sim, algumas. Ele só funciona quando o acesso ao dispositivo pode ser mapeado em memória. E não funciona com alguns tipos de dispositivos que precisam se integrar às camadas do kernel como placas de rede, dispositivos seriais, dispositivos USB e dispositivos de bloco. Além disso, o tempo de resposta para atender uma interrupção em user space pode ser um impeditivo, e ele não suporta DMA.

Na segunda parte deste artigo veremos como alguns frameworks do kernel para acesso à interfaces de hardware e barramentos (GPIO, USB, SPI, I2C, etc) possibilitam o desenvolvimento de drivers em user space.

Até lá!

Sergio Prado

Este post foi originalmente publicado em User Space Device Drivers no Linux — Parte 1.

Hacking the Xbox

Sergio Prado — Wed, 15 May 2013 01:54:11 +0000

Aos 14 anos, Aaron Swartz ajudou no desenvolvimento da especificação do RSS. Aos 19, sua empresa fundiu com o Reddit, um site de notícias de cunho social, que foi comprado em seguida, deixando-o bem financeiramente ainda jovem. E então tornou-se um ativista e defensor da livre circulação de informações na Internet.

Em 2011, liderou uma campanha para previnir o SOPA, um conjunto de leis com o objetivo de aplicar censura na Internet. Neste mesmo ano, foi acusado de hackear os servidores do MIT para roubar milhões de arquivos da biblioteca de artigos acadêmicos. Swartz era contrário à prática de compensar financeiramente as editoras, e não os autores, e de cobrar o acesso aos artigos, limitando o accesso para finalidades acadêmicas. Foi perseguido durante quase dois anos pelo governo federal americano. Um julgamento marcado para abril deste ano poderia levá-lo para a prisão por até 35 anos!

Mas este julgamento não aconteceu. Em 11 de janeiro de 2013, ele se suicidou em seu apartamento no Brooklyn. De forma trágica, tornou-se um dos símbolos da liberdade de informações na Internet. Mais informações sobre a vida de Swartz aqui, aqui e aqui.

Acontece que Andrew “bunnie” Huang, em homenagem à Aaron Swartz, resolveu liberar gratuitamente seu livro Hacking the Xbox. Das palavras de bunnie, traduzidas livremente por mim:

“Enquanto você lê este livro, espero que se lembre do quanto a liberdade é importante para a comunidade de hacking, e que esteja disposto à apoiar as mesmas crenças defendidas por Aaron.”

E o livro é realmente muito bom! Ele descreve desde os elementos mais básicos do hardware do XBox, explicando seu sistema de segurança, e passando por diversas técnicas de engenharia reversa. Inclusive, um dos últimos capítulos ensina a fazer um upgrade no XBox, ou seja, instalar o Linux! :)

Confesso que fiquei com vontade de comprar o XBox depois de folhear este livro, e tenho certeza que você também ficará!

O livro pode ser baixado aqui ou no site da No Starch Press aqui.

Happy Hacking!

Sergio Prado

Este post foi originalmente publicado em Hacking the Xbox.

Aberta nova turma de Linux embarcado em Porto Alegre/RS

Sergio Prado — Mon, 06 May 2013 13:32:38 +0000

Estão abertas as inscrições para uma nova turma do treinamento de Linux embarcado com o i.MX53, realizado em parceria com a Freescale, desta vez em Porto Alegre.

O treinamento tem um investimento de apenas R$100,00, e será realizado nos dias 6 e 7 de junho na sede da Softsul, na Rua Padre Chagas, 79, bairro Moinhos de Vento, Porto Alegre/RS.

Para quem estiver interessado, envie um e-mail para treinamentos@e-labworks.com com seu nome completo, empresa que trabalha e e-mail de contato.

Um abraço,

Sergio Prado

Este post foi originalmente publicado em Aberta nova turma de Linux embarcado em Porto Alegre/RS.

Beaglebone Black

Sergio Prado — Tue, 23 Apr 2013 02:07:22 +0000

Hoje começaram as vendas da Beaglebone Black, o novo filhote da família de cachorrinhos 100% open-source que levam os chips da Texas.

De baixíssimo custo, ela deve bater de frente com a Raspberry Pi, principalmente para o público brasileiro. Continue lendo para saber o porquê!

A PLACA

A Beaglebone Black é baseada no Sitara AM335x da Texas Instruments, composta por um ARM Cortex-A8 de 1GHz, um acelerador gráfico 3D POWERVR SGX e uma unidade de processamento programável de tempo real (PRU-ICSS), possibilitando desenvolver separadamente do core principal, aplicações e protocolos de tempo real como EtherCAT, PROFINET, EtherNet/IP, PROFIBUS e Ethernet Powerlink.

A placa possui 512MB de RAM, flash interna de 2GB (eMMC) e entrada para cartão MicroSD, portas USB host e device, interface Ethernet, saída HDMI via um conector microHDMI, leds e botões, e pode ser alimentada pela porta USB ou por uma fonte externa de 5V. Possui ainda 2 barramentos de 46 pinos, sendo totalmente compatível com os capes da Beaglebone.

Comparada à Beaglebone antiga, a Beaglebone Black é muito melhor, com CPU mais rápida, dobro de memória, saída HDMI e flash interna (eMMC). Porém, agora a UART esta disponível apenas no barramento de pinos. Veja a tabela abaixo para maiores detalhes:

O hardware da Beaglebone Black é 100% open-source, com todos os arquivos disponíveis (esquemático, BOM, PCB, etc). Mais detalhes neste link.

E três distribuições famosas já estão preparadas para a Beaglebone Black: Angstrom, Android e Ubuntu.

COMO COMPRAR?

Agora vai ser difícil comprar, a Farnell e a Mouser colocaram um lote à venda, que acabou rapidamente.

Segundo o site do projeto, a produção deve estar com 100% de capacidade até o fim de maio.

Agora a boa notícia para nós brasileiros: a Texas pretende vender a Beaglebone Black na TI eStore. Quem já comprou lá sabe que, para compras até $50, a Texas banca o frete e possíveis impostos. Ou seja, quando a Beaglebone Black começar a ser vendida na TI eStore, você vai conseguir comprá-la por R$100,00!

Isso significa também que, se a Texas fizer um marketing legal da Beaglebone Black no Brasil, muitos que estão avaliando o uso da Raspberry Pi mudarão de idéia. A nova Beagle possui muito mais recursos, é 100% open source, e baseada em um chip da Texas, cujo suporte aos engenheiros e hobbystas nem se compara com a Broadcom.

Agora é só esperar a oportunidade de colocarmos a mão neste brinquedinho…:)

Um abraço!

Sergio Prado

Este post foi originalmente publicado em Beaglebone Black.

Nova turma do treinamento de Linux em São Paulo por R$100,00!

Sergio Prado — Sun, 14 Apr 2013 15:31:22 +0000

Abri oficialmente a próxima turma em São Paulo do treinamento de Linux embarcado com o i.MX53, realizado em parceria com a Freescale (mais informações sobre o conteúdo do treinamento aqui).

O treinamento tem um investimento de apenas R$100,00, e será realizado nos dias 23 e 24 de maio na Av. Paulista, 1009, São Paulo/SP.

~~Para quem estiver interessado, envie um e-mail para treinamentos@e-labworks.com com seu nome completo, empresa que trabalha e e-mail de contato.~~

Atualização: As inscrições para este treinamento já se encerraram.

Um abraço,

Sergio Prado

Este post foi originalmente publicado em Nova turma do treinamento de Linux em São Paulo por R$100,00!.

Wandboard e i.MX6 da Freescale

Sergio Prado — Thu, 04 Apr 2013 00:43:25 +0000

A tecnologia realmente evolui a passos largos. Quem diria há alguns anos atrás que estaríamos andando hoje com sistemas multicore dentro de nossos bolsos!

E a evolução do mercado mobile já esta impactando em diversos aspectos o design de aplicações e produtos em sistemas embarcados. Seja o custo cada vez mais atrativo destes SoCs multicore, seja o interesse em sistemas operacionais com “fome de processamento” como o Android.

Por este motivo, em breve estaremos projetando produtos com CPUs multicore. Principalmente aqueles que exigem uma interface com o usuário mais rica e cheia de recursos.

Seguindo esta tendência estão os fabricantes de semicondutores, seja a TI com as linhas OMAP4 e OMAP5, a Freescale com as linhas i.MX6 e Vybrid, e outras mais voltadas à mobile como a Nvidia e sua plataforma Tegra ou a Qualcomm e sua plataforma Snapdragon.

Dentro desta nova linha de SoCs multicore esta o i.MX6 da Freescale, baseado na arquitetura ARM Cortex-A9, e disponível nas versões single, dual e quad-core.

Já existem alguns kits de desenvolvimento bem interessantes para trabalhar com esta família de SOCs, incluindo o SABRE Lite, o Nitrogen6X e a Wandboard.

Achei a Wandboard em especial bem interessante. Por apenas $99 você leva um kit de desenvolvimento com ARM-Cortex A9 dual-core, 1G de RAM, com todas as interfaces que estamos acostumados a encontrar em outros kits de desenvolvimento, mas incluindo uma interface Ethernet Gigabit, Wi-Fi e Bluetooth!

WANDBOARD

A Wandboard é um projeto sem fins lucrativos, desenvolvido por alguns engenheiros em seu tempo livre, e vem em dois sabores:

A Wandboard Solo é baseada no i.MX6 Solo, um core Cortex-A9, 512M de RAM DDR3, entradas e saídas de áudio (incluindo uma saída ótica S/PDIF), saída de vídeo HDMI (1080p), interface de câmera, porta serial, interface Ethernet Gigabit, USB host e OTG, interface SATA, cartão micro SD e alguns conectores de expansão. Esta placa custa $79.
A Wandboard Dual possui tudo o que a Solo tem, porém é baseada no i.MX6 Duallite, um ARM Cortex-A9 dual-core, com 1G de RAM DDR3 e interfaces WiFi e Bluetooth! Esta realmente me interessou, principalmente pelas características do hardware e preço, já que por apenas $99 você leva esta plaquinha. Para você ter uma idéia, ela é muito parecida com a Pandaboard, que no momento em que escrevo este artigo, esta saindo por $181 na Mouser.

No site do projeto tem um comparativo completo entre estas duas placas.

Uma característica legal da Wandboard é que ela é composta pelo módulo com CPU e memória (SOM) e pela placa com os periféricos, possibilitando o upgrade da Solo para a Dual apenas trocando o módulo da CPU.

O guia de usuário da placa, incluindo o esquemático, pode ser visualizado aqui.

O projeto da Wandboard disponibiliza no momento em que escrevo este artigo os portes do Android Jellybean 4.1.2 e do Ubuntu 11.10. Como tenho aqui comigo uma Wandboard Solo, vamos fazer alguns testes e ver como fica a performance destes sistemas operacionais na placa?

ANDROID JELLYBEAN 4.1.2

A placa não possui memória flash, então todo o sistema deve ser gravado no cartão SD.

Para instalar o Android no cartão SD, basta baixar do site, descompactar e copiar para o cartão SD (substitua /dev/sdX no comando abaixo pelo arquivo de dispositivo do seu cartão SD):

$ wget http://www.wandboard.org/images/downloads/android-4.1.2-wand-solo-20130314.zip
$ unzip android-4.1.2-wand-solo-20130314.zip
$ sudo dd if=android-4.1.2-wand-solo-20130314.img of=/dev/sdX bs=1M

O primeiro boot levou em torno de 3 minutos para exibir a tela inicial:

Logo de cara percebi que o porte ainda não esta 100%. Na verdade, esta bem longe disso. As aplicações rodam muito lentamente no device, apresentando muitos erros como este abaixo:

De tanto insistir para que o navegador abrisse uma página web, O Android abriu o bico, gerou um kernel oops, iniciou o low-memory killer e começou a matar um monte de processos!

[ 802.583548] Backtrace: 
[ 802.587007] [] (dump_backtrace+0x0/0x10c) from [] (dump_stack+0x18/0x1c)
[ 802.596426] r6:00000000 r5:000000d1 r4:00000001 r3:00000002
[ 802.603633] [] (dump_stack+0x0/0x1c) from [] (warn_alloc_failed+0xec/0x10c)
[ 802.613394] [] (warn_alloc_failed+0x0/0x10c) from [] (__alloc_pages_nodemask+0x5e8/0x640)
[ 802.624505] r3:00000000 r2:00000000
[ 802.628848] r7:00000007 r6:00000001 r5:971a4000 r4:000000d1
[ 802.635714] [] (__alloc_pages_nodemask+0x0/0x640) from [] (__dma_alloc+0xcc/0x2bc)
[ 802.646331] [] (__dma_alloc+0x0/0x2bc) from [] (dma_alloc_coherent+0x5c/0x68)
[ 802.656530] [] (dma_alloc_coherent+0x0/0x68) from [] (vpu_alloc_dma_buffer+0x34/0x5c)
[ 802.667825] r7:00000026 r6:971a4000 r5:805d0268 r4:805d0290
[ 802.675159] [] (vpu_alloc_dma_buffer+0x0/0x5c) from [] (vpu_ioctl+0x5dc/0x7e0)
[ 802.684515] r4:2bc281c0 r3:00000000
[ 802.688940] [] (vpu_ioctl+0x0/0x7e0) from [] (do_vfs_ioctl+0x4ec/0x560)
[ 802.697828] r8:8003cd84 r7:00000026 r6:874c61e0 r5:2bc281c0 r4:9a0b3d60
[ 802.705846] [] (do_vfs_ioctl+0x0/0x560) from [] (sys_ioctl+0x40/0x64)
[ 802.714455] r9:971a4000 r8:8003cd84 r7:00000026 r6:00005608 r5:2bc281c0
[ 802.725120] r4:874c61e0
[ 802.728036] [] (sys_ioctl+0x0/0x64) from [] (ret_fast_syscall+0x0/0x30)
[ 802.737872] r7:00000036 r6:2bc281c0 r5:00000000 r4:2bc281c0
[ 802.744629] Mem-info:
[ 802.746996] Normal per-cpu:
[ 802.750254] CPU 0: hi: 90, btch: 15 usd: 28
[ 802.755712] active_anon:60703 inactive_anon:57 isolated_anon:0
[ 802.755718] active_file:7528 inactive_file:7555 isolated_file:0
[ 802.755723] unevictable:157 dirty:0 writeback:6 unstable:0
[ 802.755728] free:929 slab_reclaimable:718 slab_unreclaimable:1783
[ 802.755733] mapped:11602 shmem:64 pagetables:2130 bounce:0
[ 802.788202] Normal free:3684kB min:2400kB low:3000kB high:3600kB active_anon:242840kB inactive_anon:228kB active_file:30032kB inactive_file:30112kB unevictable:628kB isolated(anon):0kB isolated(file):0kB present:360320kB mlocked:0kB dirty:0kB writeback:24kB mapped:46248kB shmem:256kB slab_reclaimable:2872kB slab_unreclaimable:7132kB kernel_stack:3744kB pagetables:8520kB unstable:0kB bounce:0kB writeback_tmp:0kB pages_scanned:0 all_unreclaimable? no
[ 802.830078] lowmem_reserve[]: 0 0 0
[ 802.834020] Normal: 21*4kB 78*8kB 127*16kB 28*32kB 1*64kB 0*128kB 0*256kB 0*512kB 0*1024kB 0*2048kB 0*4096kB 0*8192kB 0*16384kB 0*32768kB = 3700kB
[ 802.851148] 15257 total pagecache pages
[ 802.855780] 0 pages in swap cache
[ 802.859508] Swap cache stats: add 0, delete 0, find 0/0
[ 802.865419] Free swap = 0kB
[ 802.868691] Total swap = 0kB
[ 802.891393] 131072 pages of RAM
[ 802.895273] 1567 free pages
[ 802.898145] 44904 reserved pages
[ 802.902257] 1766 slab pages
[ 802.905348] 132655 pages shared
[ 802.909233] 0 pages swap cached
[ 802.912645] Physical memory allocation error!
[ 808.849260] select 3178 (droid.provision), adj 15, size 5413, to kill
[ 808.856114] select 3426 (ndroid.contacts), adj 15, size 6077, to kill
[ 808.862769] send sigkill to 3426 (ndroid.contacts), adj 15, size 6077
[ 809.078749] select 3178 (droid.provision), adj 15, size 5409, to kill
[ 809.085393] send sigkill to 3178 (droid.provision), adj 15, size 5409
[ 812.159744] select 2911 (ndroid.settings), adj 13, size 6814, to kill
[ 812.166375] select 3199 (ndroid.calendar), adj 14, size 5823, to kill
[ 812.172915] select 3552 (com.android.mms), adj 14, size 5886, to kill

Realmente, pedir para o Android 4.1 rodar em uma CPU com 512M de RAM e apenas um core pode ser muito! É bem provável que na versão dual-core da placa, com 1G de RAM, a performance esteja bem melhor. Vamos então para o Ubuntu…

UBUNTU 11.10

Para instalar o Ubuntu no cartão SD, o processo é o mesmo. Basta baixar a imagem do site, descompactar e copiar para o cartão SD (não esqueça de substituir /dev/sdX no comando abaixo pelo arquivo de dispositivo do seu cartão SD):

$ wget http://www.wandboard.org/images/downloads/ubuntu-11.10-wand-solo-20130226.zip
$ unzip ubuntu-11.10-wand-solo-20130226.zip
$ sudo dd if=ubuntu-11.10-wand-solo-20130226.img of=/dev/sdX bs=1M

O Ubuntu também levou uns 3 minutos para iniciar:

O Ubuntu me pareceu bem mais estável, com as aplicações abrindo rapidamente, e com um tempo de resposta bom. Mas não cheguei a fazer testes mais pesados como tocar um vídeo em full HD.

MAIS UMA OPÇÃO?

Sim, esta plataforma é mais uma opção interessante para prototipar e desenvolver novos projetos, com um custo benefício fantástico.

Como o projeto ainda é recente, veremos como ele vai evoluir nos próximos meses. Gostaria por exemplo de ver um módulo com i.MX6 Quad-core.

COMO COMPRAR?

A Wandboard é vendida por algumas distribuidoras, incluindo Digi-Key, Future e Mouser. Não existe um preço tabelado, então consulte o preço antes de comprar. Por exemplo, no momento em que escrevo este artigo, a Wandboard Dual sai por $114,55 na Digi-Key e $93,95 na Mouser! Para comprar, este é o link.

Bom divertimento!

Sergio Prado

Este post foi originalmente publicado em Wandboard e i.MX6 da Freescale.