Programando um Arduino em estilo old-school

Talvez o nome mais apropriado fosse "Programando um Arduino da maneira errada" ou "... da maneira mais difícil", mas o fato é que desde que comecei a brincar com Arduinos eu queria "meter a mão na massa" e programar ele à moda antiga, sem IDEs e tal, usando assembly e pior, codificando os opcodes binários manualmente. Sei lá, acho que é cacoete de quem começou com os processadores de 8bits e acostumou a "assemblar" seus próprios programas. Eu sei bem que o objetivo do Projeto Arduino não é esse, que o código não será compatível com outras placas, que será incrivelmente mais difícil, etc etc etc. Não interessa, um fuçador tem que fuçar. :-)

Para começar, a gente precisa olhar a plaquinha Arduino (neste caso, a Uno) pelo que ela realmente é: uma forma simplificada e prática de usar o microcontrolador ATmega328P. Então o próximo passo é ir lá no site da Atmel e baixar o datasheet do microcontrolador (aqui em versão completa, são 36MB), e depois disso baixar também a referência do conjunto de instruções da família AVR (à qual o Atmega328P pertence). Com estes dois documentos, já conseguimos entender bem como é que o bichinho funciona, e como são as suas instruções. Imprima e leia algumas vezes.

O próximo passo é instalar as ferramentas que serão usadas para gravar o programa na plaquinha e para manipular os arquivos de código. O bom é que elas são as mesmas ferramentas usadas pela interface IDE do Arduino: o avrdude para gravar na flash do ATmega328 e as GNU binutils (cross-compilando para AVR). Se você tem o ambiente do Arduino instalado (no Fedora, sudo yum install arduino) está tudo pronto. Uma maneira legal de começar a sujar as mãos com bits crus devagarinho é compilar um programa de exemplo qualquer na interface do Arduino, e depois ir no /tmp olhar os arquivos intermediários no diretório de build. Arrisque-se a digitar "avr-objdump -d foobar.elf" e olhar o código gerado pelo compilador. :-)

Para o meu primeiro teste eu quis fazer um pouco mais do que o tradicional Hello World do Arduino, que é piscar um led. Então resolvi fazer um programa que pisque 8 leds em zigue-zague, usando 8 pinos digitais. Decidi usar os primeiros 8 pinos, D0 a D7, porque eles são todos bits da mesma porta D para o ATmega328, o que facilita a programação. O programa basicamente seta um bit em um registrador e o envia para a porta, esperando um delay rápido e depois deslocando o registrador um bit para a direita e escrevendo na porta, em laço até zerar o registrador. Depois disso, recarrega um valor com um bit setado no registrador e faz o mesmo deslocando para a esquerda, até zerar (quando o bit "cair fora" do registrador:-).

Li algumas páginas relacionadas a sintaxe padrão de assembly AVR, e depois resolvi fazer tudo manualmente, em um formato livre. Então abri o vim e criei este arquivo, que chamei de teste.asm.

; Teste de programação do Arduino "assemblando" manualmente os opcodes
; DDRD = 0a
; PORTD = 0b
; Os opcodes precisam ser convertidos para little-endian no .bin
addr    opcode    instruction
0000    ef0f    ldi r16, 0xff    ; programa porta D como saídas
0001    b90a    out DDRD, r16
0002    e000    ldi r16, 0x00    ; limpa registradores de contagem dos delays
0003    e010    ldi r17, 0x00
0004    e440    ldi r20, 0x40    ; inicio
0005    b94b    out PORTD, r20   ; loop1, led para a direita
0006    e024    ldi r18, 0x04
0007    9503    inc r16          ; delay1
0008    f7f1    brne delay1
0009    9513    inc r17
000a    f7e1    brne delay1
000b    952a    dec r18
000c    f7d1    brne delay1
000d    9546    lsr r20
000e    f7b1    brne loop1
000f    e042    ldi r20, 0x02
0010    b94b    out PORTD, r20   ; loop2, led para a esquerda
0011    e024    ldi r18, 0x04
0012    9503    inc r16          ; delay2
0013    f7f1    brne delay2
0014    9513    inc r17
0015    f7e1    brne delay2
0016    952a    dec r18
0017    f7d1    brne delay2
0018    0f44    lsl r20
0019    f7b1    brne loop2
001a    cfe5    rjmp inicio

Claro que eu não saí digitando tudo direto. Eu comecei cada linha com dois tabs, e comecei a listar as instruções aos poucos, pensando em como ia usar os registradores. Acabei decidindo usar os registradores "altos" (r16 em diante) para poder usar a instrução LDI (Load Immediate), que só manipula de r16 a r31. Quando eu tiver mais experiência com o conjunto de instruções acho que vou começar a usar mais os registradores baixos também. Depois de prontas as instruções, preenchi a primeira coluna com os endereços, e então fui aos poucos olhando cada uma das instruções na referência do AVR Instruction Set.

Aqui cabem duas observações interessantes:

1. O AVR é um processador RISC de 8 bits, e os opcodes têm um tamanho fixo de 16 bits (algumas instruções precisam 32, mas isso fica como tema para casa). Embora na referência eles sejam demonstrados como números binários de 16 bits, na hora de gravar na flash eles precisam ser convertidos para little-endian. Minha primeira tentativa de criar o arquivo "binário" com o código acabou dando errado, e tive que digitar tudo de novo invertendo os bytes de cada opcode. :-)
2. Embora cada instrução ocupe 2 bytes, o Program Counter do AVR aponta para instruções, e não para bytes. Isso significa que os offsets de branches e jumps são offsets em instruções, e não em bytes. Então para pular 4 instruções pra cima, se usa um offset de -4, mesmo que na verdade se esteja pulando 8 bytes para trás. Pra completar a confusão, o objdump mostra o disassembly com endereços de bytes, e ele mostra os opcodes invertidos, já em formato little-endian.

Feita a tradução dos mnemônicos para os opcodes binários (e calcular os offsets de branches contando em hexa em complemento de 2 nos dedos), agora a tarefa é digitar todos os opcodes em um arquivo, que será o "binário compilado" desse nosso esforço manual. Eu uso o hexedit, que é simples e direto, mas qualquer editor hexadecimal serve. Lembre-se de digitar os opcodes convertendo para little-endian. Fazendo um hexdump do "código compilado" teste.bin fica assim:

$ hexdump -C teste.bin
00000000  0f ef 0a b9 00 e0 10 e0  40 e4 4b b9 24 e0 03 95  |........@.K.$...|
00000010  f1 f7 13 95 e1 f7 2a 95  d1 f7 46 95 b1 f7 42 e0  |......*...F...B.|
00000020  4b b9 24 e0 03 95 f1 f7  13 95 e1 f7 2a 95 d1 f7  |K.$.........*...|
00000030  44 0f b1 f7 e5 cf 00 00  00 00 00 00 00 00 00 00  |D...............|

No total são 54 bytes, para 27 instruções de máquina. Eu completei com uns zeros no final, só para fechar 64 bytes e ficar tudo alinhado. :) O opcode do NOP em AVR é 0x0000 então tá tranquilo. :-)

Um passo interessante, agora, é transformar esse arquivo contendo opcodes de AVR em um arquivo que o avr-objdump entenda e possa desassemblar, para que a gente confira o código e principalmente os offsets de branches, que o objdump nos ajuda a entender. Não é um passo necessário, mas é bom pra ter certeza que o código que montamos está realmente fazendo o que pretendemos que ele faça. Eu não consegui achar uma maneira de convencer o objdump a desmontar o binário "cru" diretamente, então usei o objcopy para transformá-lo em um ELF comum:

$ avr-objcopy -I binary -O elf32-avr --rename-section .data=.text,contents,code teste.bin \
    teste.elf
$ avr-objdump -d teste.elf

teste.elf:     file format elf32-avr

Disassembly of section .text:

00000000 _binary_teste_bin_start:
   0:    0f ef           ldi    r16, 0xFF    ; 255
   2:    0a b9           out    0x0a, r16    ; 10
   4:    00 e0           ldi    r16, 0x00    ; 0
   6:    10 e0           ldi    r17, 0x00    ; 0
   8:    40 e4           ldi    r20, 0x40    ; 64
   a:    4b b9           out    0x0b, r20    ; 11
   c:    24 e0           ldi    r18, 0x04    ; 4
   e:    03 95           inc    r16
  10:    f1 f7           brne    .-4          ; 0xe _binary_teste_bin_start+0xe
  12:    13 95           inc    r17
  14:    e1 f7           brne    .-8          ; 0xe _binary_teste_bin_start+0xe
  16:    2a 95           dec    r18
  18:    d1 f7           brne    .-12         ; 0xe _binary_teste_bin_start+0xe
  1a:    46 95           lsr    r20
  1c:    b1 f7           brne    .-20         ; 0xa _binary_teste_bin_start+0xa
  1e:    42 e0           ldi    r20, 0x02    ; 2
  20:    4b b9           out    0x0b, r20    ; 11
  22:    24 e0           ldi    r18, 0x04    ; 4
  24:    03 95           inc    r16
  26:    f1 f7           brne    .-4          ; 0x24 _binary_teste_bin_start+0x24
  28:    13 95           inc    r17
  2a:    e1 f7           brne    .-8          ; 0x24 _binary_teste_bin_start+0x24
  2c:    2a 95           dec    r18
  2e:    d1 f7           brne    .-12         ; 0x24 _binary_teste_bin_start+0x24
  30:    44 0f           add    r20, r20
  32:    b1 f7           brne    .-20         ; 0x20 _binary_teste_bin_start+0x20
  34:    e5 cf           rjmp    .-54         ; 0x0 _binary_teste_bin_start
    ...

Legal, com isso já consigo verificar que eu calculei os opcodes corretamente, e que meus offsets de branches e jumps estavam certos. Agora só falta gravar no Arduino. Para isso, temos que converter o binário em um arquivo no formato Intel Hex, com extensão .hex. Este é o formato usado pelo avrdude, que é quem conversa com o bootloader do Arduino e grava o nosso programa lá. Os comandos abaixo deram conta do recado:

$ avr-objcopy -I binary -O ihex teste.bin teste.hex
$ avrdude -P /dev/ttyUSB0 -p ATmega328P -b 115200 -c arduino -U flash:w:teste.hex:i

O avrdude gera bastante saída na tela, dá pra ir acompanhando os passos da gravação. Note que eu usei um Garagino com uma porta serial FTDI que o acompanha, e ela é detectada como /dev/ttyUSB0. Uma plaquinha Arduino Uno, por exemplo, é detectada como /dev/ttyACM0, então o comando acima deverá ser adaptado. Feita a programação e montado o circuito, voilà! Está tudo funcionando como esperado, em apenas 27 instruções de código!

Estou muito feliz de finalmente ter escovado estes bits, que estavam me esperando desde que comprei a primeira Arduino Uno. Só não tinha dado tempo ainda de pensar num projetinho simples porém não tão trivial, sentar e começar a codar. Levei horas codificando os opcodes manualmente, e é claro que não pretendo mais fazer isso. Meus próximos testes serão utilizando o GNU Assembler para facilitar as coisas. Estou commitando estes e outros testes com Arduino neste repositório no github, para facilitar a publicação e utilização pelos interessados.

Ah, antes que me esqueça: desde que a gente não sobrescreva o bootloader do Arduino, que ocupa os últimos 512 bytes da flash, vai continuar funcionando tudo normalmente, e a placa continua compatível com a IDE do Arduino. Continua sendo possível criar e gravar um programa pelas vias normais, usando a IDE e clicando botõezinhos. :-) Se o nosso programa tiver menos do que 32256 bytes não vai sobrescrever o bootloader e tá tudo certo.

Update 2014-06-20: Na verdade nem precisa converter o arquivo binário para ihex. O avrdude também pode ler arquivos binários sem formato, especificando a opção "raw". Agora mesmo eu mudei um pouco o padrão dos leds e escrevi o teste.bin direto usando "-U flash:w:teste.bin:r". O ":r" no final é que indica o tipo, sendo 'i' Intel Hex, e 'r' raw. Só o que se perde com isso é a possibilidade de especificar o endereço de carga. O ihex pode especificar endereços, para o caso de querermos gravar um conteúdo na flash a partir de um ponto específico. O raw sempre vai ser gravado a partir de 0 na flash. Bom saber que nem precisa fazer a dança do objcopy, embora seja mais reconfortante fazer um objdump e confirmar o código antes de gravar. :-)

Encontro de LibreOffice, Arduino Day e FLISoL: OeSC-Livre em movimento!

Mas bah! Fazem semanas que eu queria vir postar alguma coisa, pelo menos desde o Arduino Day. Os últimos meses foram de muito movimento divertido aqui no Oeste Catarinense, começando pelo 3º Encontro Catarinense de LibreOffice que aconteceu no dia 15 de Março lá na UnC em Concórdia. O Klaibson Ribeiro e o Jackson Laskoski estão de parabéns pela iniciativa de trazer este evento pra cá. Aliás, é muito legal ver eventos cada vez mais diferenciados e específicos acontecendo aqui no bom e velho oeste. Acredito que estamos colhendo os frutos de sementes que vêm sendo plantadas nos últimos anos, com otimismo, tranquilidade e perseverança.

O Arduino Day organizado lá na UNOESC Chapecó foi um sucesso total. Tivemos laboratórios lotados e muita gente fuçando nas plaquinhas, aprendendo a lidar com bits físicos. Desde os piscadores de LED até gente fazendo sensores de temperatura e mexendo com displays LCD, tinha de tudo e todos os envolvidos saíram de lá tendo aprendido muita coisa. Valeu muito a pena participar. Pra variar eu apresentei uma daquelas palestras que acaba em um terminal aberto cheio de números hexadecimais, e o público adorou! Hahahah evento nerd é assim: projeta uma tela preta com letras e números enigmáticos e o pessoal fica maluco. Eu queria ter melhorado um pouco os slides antes de disponibilizar aqui, já que o código em si eu mostrei no terminal, mas faltou tempo. Fica pra próxima palestra deste assunto.

No sábado passado tivemos o segundo FLISoL realizado em Chapecó, desta vez sediado pela UNOESC. Foi um sucesso novamente. Muita gente que já conhecia Software Livre (e Hardware Livre, que tem estado sempre presente) aproveitou pra trocar idéias e renovar conhecimentos, e também muita gente nova nesse mundo aproveitou pra instalar uma distribuição de Linux pela primeira vez com a ajuda dos mais experientes. O Álisson Bertochi e o Tiago Zonta estão de parabéns pelo excelente evento, muito bem organizado. Também foi muito legal o engajamento de pessoas como o Éderson Szlachta (que fez o layout dos crachás) e o Eliezer Bernart, que falou sobre FirefoxOS, apresentou oficina de desenvolvimento pra esse novo Sistema Operacional, e ainda trouxe muitos swags da Mozilla pra distribuir pra gurizada.

No FLISoL eu apresentei uma palestra sobre Software e Hardware Livres, para dar uma base conceitual às conversas, palestras e oficinas que viriam depois, e mais tarde como é de praxe apresentei o Projeto Fedora. No InstallFest da tarde ajudei uma pessoa a instalar Fedora 20 em seu laptop em dual-boot com o Windows 8. Tive um pouco de medo no início, e é claro que deu um probleminha (o Fedora bootava legal, mas o Windows não queria mais ligar), mas desabilitando o SecureBoot deu tudo certo. Deve ter uma maneira de deixar os dois funcionando bem com SecureBoot, mas não deu tempo de investigar mais. Distribuimos mídias de Fedora e criamos pendrives para alguns que iam instalar em casa. No geral foi tudo muito legal.

Fico muito feliz de ver que já podemos dizer que temos uma comunidade de Software e Hardware Livre estabelecida e ativa na região. Muitos eventos, encontros e outros movimentos interessantes vêm acontecendo, como os Hackerspaces que estão tomando forma e se concretizando. Também é muito legal ver que todos estes eventos tiveram apoios variados, inclusive com a Editora Novatec se fazendo presente em todos eles, com códigos promocionais e itens para sorteio. Tanto no Arduino Day quanto no FLISoL a empresa local Fazolo Componentes Eletrônicos também apoiou, com kits de componentes a preços promocionais e sortendo um kit por evento.

Agora vem o FISL e fechamos o primeiro semestre do ano com chave de ouro. Teremos muita gente do grupo lá, pra celebrarmos juntos e representarmos nossa região, que cada vez mais demonstra que está caminhando com passos firmes no mundo da tecnologia.

Gambiarra do dia: protoboard com bateria "embutida"

Fazia tempos que eu queria "cometer" algo parecido com isso. Quem usa protoboards pra montar circuitos divertidos ganha muito em agilidade e mobilidade, principalmente pra quem fuça em arduinos, garaginos (meu preferido pra protoboard) e outros inos. Por outro lado, sempre existe o desconforto de andar com uma fonte pra alimentar o circuito à partir da tomada, ou adaptadores de pilhas e outras incomodações. Não seria ótimo se a própria protoboard pudesse ter baterias embutidas, que fornecessem energia pro nosso projeto? Fica muito mais fácil, inclusive pra carregar o projeto na mochila e demonstrar onde for necessário de forma imediata.

Pois bem, hoje eu estava testando um projetinho simples pra configurar e testar o ambiente arduino do Fedora (sudo yum install arduino, pronto), e novamente fiquei de olho em umas baterias velhas de celular que estavam guardadas junto com outras tranqueiras. Dessa vez eu pensei: "quer saber, essa gambiarra vai sair é hoje!". No fim nem ficou tão feio :-), eu só tive um pouco de medo que as baterias aquecessem demais e estragassem na hora em que eu soldei os fios. Pra ficar uma coisa robusta e com boa capacidade, eu soldei duas baterias de 3.7V e 1000mAh em paralelo, colei-as (com fita adesiva mesmo) na parte de baixo da protoboard, e puxei os fios com jacarés através de um dos furos para bornes de alimentação, de forma que fica fácil plugá-los nos bornes que sobraram. A minha idéia original era colocar os fios ligados direto nos bornes, com um interruptor pra ligar, mas não achei um interruptorzinho decente nas minhas sucatas aqui. Por enquanto vai de jacaré mesmo. Inclusive com os jacarés fica fácil plugar no carregador universal de baterias que vou usar nelas.

Elas por enquanto estão fornecendo 4.1V, o que é mais do que suficiente pra alimentar o garagino, que pode receber de 1.8V a 5V. Com os 2000mAh resultantes, acho que ele vai alimentar circuitos simples por alguns dias. :-) Quando der eu faço um teste de deixar um circuito alimentado pelas baterias e cuido até quando ele aguenta. Bem que as fabricantes de protoboard poderiam criar produtos assim, com alimentação embutida (em baterias, nada de fontes que precisem de tomada) e regulada de 3.3V e/ou 5V.  Aliás, eu acho que enviei uma sugestão dessas pra ICEL, há algum tempo. Pelo menos isso é o tipo de coisa eu eu faria, hehehe. Não vou abrir uma empresa pra fazer baterias plugáveis em protoboards, porém eu certamente compraria se alguma empresa as fizesse. :-)

Ótimo livro: CODE do Charles Petzold

No início de janeiro eu estava pra sair de férias, e perguntei para os meus colegas que livros eles sugeriam para ler. Queria alguma coisa técnica porém leve, que fosse menos bit e mais história. A sugestão do mestre Rafael Aquini não poderia ter sido melhor: CODE, do Charles Petzold. Ao terminar de ler o livro eu cheguei à conclusão que lê-lo equivale a ter nascido na década de 70 e estudado computadores de 8 bits. Sério, é muito bom mesmo!

Vale muito a pena mesmo para quem já domina o lado técnico, pois a contextualização histórica que ele apresenta, na medida certa, enriquece a compreensão de qualquer um a cerca dos bits e seus significados. Não tem como ler este livro e não enxergar os bits. Eles estão lá, nus e crus, esperando que o leitor os apreenda, e de repente toda a computação digital faz sentido.

Você sabia que as raízes da computação binária remontam ao século 19? Os bits são os mesmos, só mudou o substrato. A grande sacada veio no início do século 20, com o Claude Shannon, usando tecnologia de telégrafos do século 19. Eu já tinha lido alguma coisa dele quando estudei algoritmos de compressão, mas agora compreendo o papel muito mais fundamental que ele teve na Grande Sacada de unir no sistema de numeração binário a aritmética, a lógica e a sua expressão automatizada por meio de circuitos elétricos (na época eletromecânicos). A partir daí a tecnologia só se miniaturizou e se tornou mais rápida, mas o princípio é o mesmo.

Claude Shannon agora figura entre Ken Thompson, Dennis Ritchie, Donald Knuth e muitos outros no meu panteão pessoal da Computação. :-)

Semeando perguntas

Acabo de voltar bem energizado do segundo dia de Capacitação Docente na UNOESC, totalmente convencido de que uma das coisas que mais gosto de fazer é ensinar, explicar, desmistificar. Durante o mestrado na UFRGS, em 1998 e 1999, tive uma curta experiência docente na UCPel, onde me formei em Ciência da Computação. Depois disso, fui para a "indústria" e desde então tenho apenas apresentado palestras, talvez ministrado pequenos cursinhos aqui e ali (que já nem lembro bem), e, claro, ajudado muita gente por email e IRC através do TcheLinux e do OeSC-Livre. Mas hoje vejo que a prática do ensino e o ambiente universitário estavam me fazendo falta.

Vou ministrar a disciplina de Introdução ao Hardware, no primeiro semestre do nascente curso de Engenharia da Computação da UNOESC Chapecó, e também ministrar uma disciplina sobre a pilha de redes do kernel Linux, no curso de Pós-Graduação em Administração de Redes da UnC em Concórdia. Estou muito feliz e motivado, e agradeço muito aos colegas Jackson Laskoski e Tiago Zonta por me darem estas oportunidades. :-)

Num momento da capacitação se falou sobre usar perguntas, e lembrei de uma prova de Arquitetura de Computadores que eu apliquei há muitos anos lá na UCPel. No rodapé da prova, eu escrevi para os alunos: Nunca abandone a dúvida, pois quem motiva é a pergunta, não a resposta. Alguns anos depois eu assisti ao filme The Matrix e fiquei alguns momentos me sentindo inteligente :-), ao ver a cena em que a Trinity cochicha para o Neo: It's the question that drives us, Neo.

Esta noite me veio à cabeça uma versão mais ambientada ao Oeste Catarinense: Assim como na colheita, reserve um pouco das suas respostas para semear novas perguntas. É isso aí alunado! Será um prazer enchê-los de perguntas, e ajudá-los a transformá-las não apenas em respostas, mas em mais e melhores perguntas para o próximo plantio!

Criando um pendrive com vários Fedoras Live

O fim de semana passado foi de backups e reinstalações de Fedora aqui em casa, para atualizar os laptops da família. Sim, eu conheço o Fedup, preupgrade e outras formas de atualizar o nosso Sistema Operacional favorito, obrigado. Ainda assim, de tempos em tempos eu gosto de fazer backup, chutar tudo o que tem no disco e reinstalar do zero, para dar uma sensação maior de "alívio refrescante". Cada um sabe de si. :-)

Eu tinha as ISOs Live do Fedora 20 Beta RC5, em 32 e 64 bits, e pensei em dar um jeito de colocar as duas co-existindo no mesmo pendrive, pra facilitar a minha vida (um dos laptops antigos é 32b). Tinha recém tentado usar um DVD multi-Live e multi-arch, do Fedora 19, que o Wolnei Tomazelli havia me dado quando nos encontramos por sorte no aeroporto de Floripa. Infelizmente o DVD estava meio arranhado e travava a instalação no meio do caminho, então decidi começar a usar apenas pendrive mesmo.

Eu já criei outros pendrives com Lives ou Installs do Fedora, usando o comando livecd-iso-to-disk, do pacote livecd-tools, porém nunca com várias versões no mesmo pendrive. No fim o processo não foi totalmente automático como eu esperava, mas também não foi nenhuma dor de cabeça arrumar os detalhes do syslinux (boot loader usado na pendrive). Pra quem nunca mexeu mais diretamente nisso pode ser um bom aprendizado.

Preparando o pendrive

Um ponto importante a se cuidar antes de preparar um pendrive de Fedora, é que grande parte dos pendrives não vem com um MBR apropriado, ou vem com uma descrição da partição meio quebrada que o Sistema Operacional entende porém o BIOS se perde na hora de dar boot. Me desculpem a explicação nada técnica, mas minha impressão é essa e só sei que "formatando resolve". ;-)

Para deixar a pendrive preparada, entre no utilitário Discos (gnome-disks), selecione a pendrive, selecione a partição, desmonte-a (ícone de stop, é um quadradinho preto) se estiver montada, e remova-a (ícone que é um sinal de menos). Depois clique no ícone das engrenagens na parte de cima da janela, que se referem ao disco todo, e formate a pendrive no padrão MBR (compatível com a maioria dos computadores). Isso na verdade só zera a tabela de partições do bichinho, reescrevendo o setor 0.

Depois disso, adicione uma nova partição no padrão FAT, clicando no ícone que é um sinal de mais. Por último, clique no ícone de engrenagem que aparece abaixo da representação do disco, e escolha editar o tipo da partição. Para garantir, mude o tipo da partição para W95 FAT32 LBA (0x0c), e marque a partição como bootável. UFA! Falta pouco.

Os comandos a partir de agora usam o dispositivo /dev/sdb para representar a pendrive. TOME CUIDADO E VERIFIQUE QUAL DISPOSITIVO REPRESENTA A SUA PENDRIVE. Para garantir que o pendrive tenha um MBR que funcione, rode o comando abaixo:

$ sudo dd if=/usr/share/syslinux/mbr.bin of=/dev/sdb

Agora falta apenas colocar o syslinux no bicho. Rode mais este comando:

$ sudo syslinux -i /dev/sdb1

Pronto, finalmente o pendrive está seguramente pronto pra bootar em qualquer máquina. É possível testar o setup até agora usando o qemu, rodando:

$ sudo qemu-kvm -hda /dev/sdb

A janela do qemu vai mostrar o prompt do syslinux (boot:), indicando que o pendrive está bootando corretamente. Feche o qemu e siga adiante.

Gravando as imagens na pendrive

Bom, partindo do ponto em que o pendrive está plugado porém desmontado e pronto pra bootar (lembre de sempre desmontar pelo utilitário Discos ou manualmente no shell), que tu sabes qual é o dispositivo a ser utilizado e que baixastes as ISOs que queres usar, rode estes comandos:

$ sudo   livecd-iso-to-disk   --multi   --livedir   F20_32   \
        Fedora-Live-Desktop-i686-20-Beta-5.iso    /dev/sdb1

$ sudo   livecd-iso-to-disk   --multi   --livedir   F20_64   \
        Fedora-Live-Desktop-x86_64-20-Beta-5.iso    /dev/sdb1

Cada um vai demorar vários minutos, enquanto eles copiam as imagens. Em princípio estaria tudo pronto, porém fica faltando um pedaço que o livecd-iso-to-disk não faz, que é criar uma configuração de syslinux que boote qualquer uma das imagens. Na verdade, neste ponto, a pendrive nem boota corretamente, pois fica no prompt do syslinux sem se ter muito o que fazer ali, a não ser que se saiba de cor a linha gigantesca de boot das imagens Live. O problema é que o livecd-iso-to-disk coloca os diretórios do syslinux dentro do diretório de cada imagem Live, porém quando o syslinux boota ele espera encontrar os seus arquivos de configuração e comandos dentro do diretório syslinux, ou na raiz do pendrive (configuração padrão).

Arrumando a configuração do syslinux

A correção é bem fácil, basta montar a pendrive e copiar o diretório syslinux (copiar, não mover) de um dos diretórios de imagem Live para o raiz do pendrive. Eu copiei o diretório syslinux que achei dentro do F20_64, desmontei e bootei, e funcionou. MAS, funcionou só para as imagens de 64 bits. O problema é que o livecd-iso-to-disk não é esperto o suficiente pra juntar as duas configurações de syslinux das duas imagens Live, então essa tarefa fica pra nós. :)

Dentro do diretório syslinux copiado, haverá um arquivo chamado syslinux.cfg. É este arquivo quem descreve o que o syslinux vai fazer quando boota, inclusive montar o menu que é interpretado pelo vesamenu.c32 do mesmo diretório. Abra esse arquivo no gedit, e passe alguns minutos lendo e entendendo o que ele faz.

Depois de se familiarizar um pouco com a sintaxe, note as linhas que contém "label linux0" e "kernel /F20_64/syslinux/vmlinuz0", por exemplo. Estas são as linhas que descrevem como bootar os kernels e imagens de disco live presentes na pendrive. O que precisamos é abrir o syslinux.cfg da OUTRA imagem live, e copiar estas entradas para o syslinux.cfg global do pendrive. É importante mudar o nome do label, para que o syslinux não se perca. Basta mudar de "label linux0" pra "label linux1".

Na minha pendrive eu copiei também a seção "label basic0" da imagem 32 bits, para ser possível bootar a imagem de 32 bits com driver de vídeo vesa, mudando-a para "basic1". É importante mudar também a descrição das linhas "label" para identificar qual imagem é de 32 bits e qual é de 64 bits.

A primeira parte do syslinux.cfg ficou assim:

label linux0
  menu label ^Start Fedora Live 64b
  kernel /F20_64/syslinux/vmlinuz0
  append initrd=/F20_64/syslinux/initrd0.img root=live:UUID=E6F0-8DA8 rootfstype=vfat ro rd.live.image live_dir=F20_64 quiet  rhgb rd.luks=0 rd.md=0 rd.dm=0
  menu default

label linux1
  menu label ^Start Fedora Live 32b
  kernel /F20_32/syslinux/vmlinuz0
  append initrd=/F20_32/syslinux/initrd0.img root=live:UUID=E6F0-8DA8 rootfstype=vfat ro rd.live.image live_dir=F20_32 quiet  rhgb rd.luks=0 rd.md=0 rd.dm=0

Note como cada label aponta para um diretório específico. Facilita testar com o qemu-kvm (de preferência passando -m 1024 para ele ter bastante memória) até ter certeza que tudo está perfeito.

Adicionando ainda mais uma imagem

Pra completar, resolvi baixar ainda uma terceira imagem Live, dessa vez a Fedora-Live-LXDE-i686-20-Beta-5.iso para testar em sistemas mais antigos. Vamos rever como adicionar ela ao pendrive, que agora terá 3 imagens Live diferentes:

$ sudo   livecd-iso-to-disk   --multi   --livedir   F20_LX32   \
        Fedora-Live-LXDE-i686-20-Beta-5.iso    /dev/sdb1

Quando estiver pronto, monte o pendrive de novo, e faça o esquema de copiar as seções do syslinux.cfg dessa nova imagem para o syslinux.cfg "global" da pendrive. Agora as seções "label linux*" ficaram assim:

label linux0
  menu label ^Start Fedora Live 64b
  kernel /F20_64/syslinux/vmlinuz0
  append initrd=/F20_64/syslinux/initrd0.img root=live:UUID=E6F0-8DA8 rootfstype=vfat ro rd.live.image live_dir=F20_64 quiet  rhgb rd.luks=0 rd.md=0 rd.dm=0
  menu default

label linux1
  menu label ^Start Fedora Live 32b
  kernel /F20_32/syslinux/vmlinuz0
  append initrd=/F20_32/syslinux/initrd0.img root=live:UUID=E6F0-8DA8 rootfstype=vfat ro rd.live.image live_dir=F20_32 quiet  rhgb rd.luks=0 rd.md=0 rd.dm=0

label linux2
  menu label ^Start Fedora Live LXDE 32b
  kernel /F20_LX32/syslinux/vmlinuz0
  append initrd=/F20_LX32/syslinux/initrd0.img root=live:UUID=E6F0-8DA8 rootfstype=vfat ro rd.live.image live_dir=F20_LX32 quiet  rhgb rd.luks=0 rd.md=0 rd.dm=0

A seção que contiver "menu default" será a que estará selecionada por default no menu criado pelo vesamenu.c32 do syslinux. Para finalizar os últimos retoques, se pode remover alguns arquivos agora inúteis, como os "boot.cat", as cópias extras do memtest, etc. Para servir de referência, aqui está o arquivo syslinux.cfg que eu criei até agora, separado com linhas extras pra facilitar a compreensão.

Novamente, lembre de sempre desmontar pelo utilitário Discos ou manualmente no shell, ao invés de "ejetar", pois o "ejetar" desliga o pendrive, e será necessário retirá-lo e plugá-lo novamente, e aí desmontar de novo. :-) E teste sempre com "sudo qemu-kvm -m 1024 -hda /dev/sdb", para facilitar a vida.

Para fazer um pendrive com syslinux ainda mais útil, se pode inclusive copiar alguns módulos extras do syslinux para dentro do diretório syslinux na raiz do pendrive. Eles estão em /usr/share/syslinux e podem ser acessados no prompt de boot do syslinux, quando se sai do menu apertando ESC. No meu pendrive eu copiei também os módulos hdt.c32, ls.c32, meminfo.c32, poweroff.com, reboot.c32 e rosh.c32. Experimentá-los fica como tema para casa. ;-)

TecLand, palestras, Fedora e novos hábitos

Este fim de semana foi bastante corrido mas muito proveitoso. Muita coisa legal aconteceu. Eu e o Marcelo Barbosa participamos do IV Encontro TecLand, com uma palestra sobre Fedora em arquitetura ARM, e o Marcelo também apresentou uma outra palestra sobre o oVirt (nessa eu só dei pitaco). O evento foi ótimo, provavelmente o melhor que o TecLand já fez. O Álisson e o  Éder, do TecLand, e a Fabiane Erlo, da UnC, realizaram um evento muito legal, bem planejado e executado, e com público ao redor de 100 pessoas.

Mas antes e depois do evento aconteceu muita coisa legal também, pois o Marcelo veio aqui pra minha casa já na sexta-feira, então batemos altos papos sobre ARM e etc. Sexta no final da tarde o Álisson passou aqui pra nos pegar, pegamos também o Paulo Klaus e fomos pra Concórdia. Depois de alguns ajustes e testes no auditório da UnC, o Jackson Laskoski e o Adinarte nos levaram pra uma janta buenacha, onde ficamos até meia-noite em altos papos filosóficos e nerds. :)

No sábado rolou o evento lá na UnC, onde tivemos até um tradicional "pão com salsichão" para os participantes, cortesia do Prox. Max Pezzin, apresentações muito legais e um público bem interessado. Terminada a "ordem do dia", voltamos pra Chapecó, e no domingo passeamos bastante com o Marcelo na cidade pra fazer um  pouco de turismo. No meio da tarde resolvemos libertar o laptop do Álisson, que rodava um Windows qualquer, então fomos pra uma sorveteria (estava quente pacas aqui) com um pendrive do Fedora 20 (Beta RC5) e um modem 3G.

Acabamos não apenas ajudando o Álisson a reinstalar seu laptop e fazer tudo funcionar a contento no Fedora 20, mas também aproveitamos para fazer uma longa caminhada batendo papo, onde o Marcelo me deu o caminho das pedras pra virar tradutor do Fedora, e encorajou eu e o Álisson a fazer caminhada e corrida todos os dias para cuidar da saúde física e mental. Eu já comecei hoje mesmo o "novo hábito", saí de casa para caminhar às 6h40 e voltei às 7h40, tendo dado algumas voltas no eco-parque. Já traduzi algumas coisas lá no transifex também. :)

Eu já vinha no ritmo das palestras e apresentações, pois tinha na semana passada conversado com alunos do SENAI e também da UCEFF, aqui em Chapecó. Tinha ficado um tempo sem realizar atividades relacionadas ao Fedora, mas agora retornei à ativa, hehehe. Na conversa da UCEFF eu acabei de vez com meus DVDs do Fedora 18, agora preciso arranjar mais, já do Fedora 20!

Costumes de quem usa Software Livre: "Hmm alguém já arrumou esse bug"

É engraçado como os sistemas que usamos vão aos poucos moldando nossos hábitos, até para as coisas mais simples. Agora de noite eu resolvi gravar um vídeo da Peppa Pig, no youtube, para a minha filha ver. Ela é fã da Peppa, então é bom ter uma reserva de vídeos guardados para quando não tem Peppa na TV. Achei um vídeo perfeito, de uma hora e pouco, então fui direto no youtube-dl pra gravar:

$ youtube-dl -o peppa-pig.webm 'http://www.youtube.com/watch?v=cgAVKlcs0dc'
[youtube] Setting language
[youtube] cgAVKlcs0dc: Downloading video webpage
[youtube] cgAVKlcs0dc: Downloading video info webpage
[youtube] cgAVKlcs0dc: Extracting video information
[youtube] cgAVKlcs0dc: Encrypted signatures detected.
ERROR: unable to download video

Deu esse erro ali, e eu pensei: "Hmm alguém já deve ter corrigido esse bug!". Mandei um yum update:

$ sudo yum update youtube-dl
...
...
 Updated:
  youtube-dl.noarch 0:2013.10.18.2-1.fc18

E chamei o youtube-dl de novo, confiando que ia funcionar:

$ youtube-dl -o peppa-pig.webm 'http://www.youtube.com/watch?v=cgAVKlcs0dc'
[youtube] Setting language
[youtube] cgAVKlcs0dc: Downloading video webpage
[youtube] cgAVKlcs0dc: Downloading video info webpage
[youtube] cgAVKlcs0dc: Extracting video information
[download] Destination: peppa-pig.webm
[download] 100% of 190.24MiB in 07:40

Não poderia ser mais simples, né? A rapidez e facilidade com que nossos sistemas operacionais livres são atualizados e corrigidos é fantástica! :)

OeSC-Livre e Hackerspaces na FACE 2013

MUITO OBRIGADO aos organizadores da FACE 2013 (Feira de Conhecimento, Cultura e Educação), e muito obrigado também ao Prof. Tiago Zonta, da UNOESC, que nos conseguiu um espaço fantástico para divulgar o OeSC-Livre e, mais importante, os Hackerspaces recém-nascidos de Chapecó e Concórdia. Nós passamos as últimas 3 ou 4 semanas numa correria daquelas para garantir que teríamos uma representação legal dos grupos (projetos, adesivos, panfletos, camisas pólo, e na verdade até o logo e domínios dos Hackerspaces na Internet), e deu certo. Foi um sucesso total!

No primeiro dia, quinta-feira dia 29, montamos nosso principal projeto pensado para a feira, o jogo Genius baseado em Arduino e Raspberry Pi. O Arduino fazia a lógica do jogo, controlando as teclas, som e luzes, e um programa rodando na Raspy mostrava um placar com os três melhores resultados da feira, e cuidava de mandar o Arduino iniciar o jogo e ler o resultado. Logo de início já deu muita gente interessada em brincar na caixa barulhenta. Alguns ficaram verdadeiramente viciados e não aceitavam ter seus resultados fora do ranking na tela.

Já neste primeiro dia rolou a primeira surpresa agradável e gratificante da feira: fui entrevistado pela RBS, em matéria que foi ao ar no Jornal do Almoço. Meus 30 segundos de fama! :-) Nesta curta entrevista demonstrei rapidamente um projetinho muito mais simples, um velho teclado de PC e um buzzer ligados em um Arduino, que rodava um pequeno programa lendo as teclas do teclado e tocando notas musicais correspondentes, representando uma oitava nas teclas QWERTYU (usando também as teclas numéricas acima destas para os sustenidos). Foi interessante ler sobre a Escala Temperada de Bach para este projetinho, e aprender que a frequência do som aumenta 5.94% a cada nota.

No segundo dia, sexta-feira dia 30, tivemos mais membros do grupo ajudando no nosso espaço, inclusive com uma gurizada muito boa que veio de Joaçaba (valeu Eliezer!). O Fábio Beckert e o Oruam Piazza também trouxeram seus projetos, o Fábio com um módulo de GPS fechado que ele está hackeando para criar programas próprios, e o Oruam com um projeto sensor de temperatura com escala em LED. Neste dia tivemos o acompanhamento mais próximo de uma jornalista do evento, que criou esta matéria. Ao final do dia os hackers de plantão Ernesto Albrecht e Ricardo Fachinello apareceram com uma baita estrutura de madeira onde estavam montando controles estilo arcade. Eles canibalizaram um velho controlador de teclado, e passamos algumas horas soldando fios para refazer a matriz de varredura desse controlador, ligando-a nos botões e joysticks do arcade. Acho que esse foi o ponto alto do estilo Hackerspace no evento. Ferro de solda, fios pra todo lado, e no final rodamos um emulador de arcade com jogos antigos usando um projetor de vídeo. Fantástico!

O último dia da feira, sábado dia 31, também trouxe muita diversão nerd. Fizemos um encontrão no shopping, na hora do almoço, onde se juntou a nós o pessoal de Concórdia, que também fazem muitos eventos do OeSC-Livre e estão montando um Hackerspace, o Concas Hackerspace. Com toda essa gurizada junta, nós tomamos conta do espaço na FACE e rolou muita descontração e conversas nerd, até o ponto em que achamos que estava tudo muito calmo e resolvemos trazer umas sucatas pra fuçar. O Gustavo Seitenfus trouxe um velho monitor de tubo que ele precisava arrumar, e o monitor quase pegou fogo umas três vezes. :-D

No sábado também tivemos a presença do João Ricardo, do Tarrafa Hacker Clube (Hackerspace de Floripa), que nos trouxe orientações, dicas e bom papo. Acho que ele gostou do que viu, pois conseguimos dar o pontapé inicial nos Hackerspaces do Oeste deixando claro que levamos isso muito a sério. O João trouxe a infame "Máquina Inútil" do Tarrafa, que deixou muitas pessoas da Feira bem curiosas. :-)

Enfim, foram algumas semanas de preparação, e três dias intensos de fuçadas épicas, conversas de alto nível, explicações, hacks e projetos divertidos. Pude até falar com alguns interessados sobre o Projeto Fedora, e entregar alguns DVDs Live para testarem em casa. Tenho certeza que estou esquecendo de muitos fatos e pessoas que poderia mencionar, que agora estão na confusa e misturada lembrança destes três dias de diversão intelectual. Obrigado a todos os que estiveram por lá, todos os que ajudaram a realizar esta ótima divulgação dos grupos e, novamente, muito muito obrigado ao Tiago Zonta e toda a organização da FACE 2013, por nos cederem este espaço e permitirem que celebrássemos a Cultura Hacker e o Software Livre no nosso cantinho da feira. Certamente estaremos muito interessados em participar novamente nos próximos anos, com mais e melhores projetos!

Mais FISL 14: Beyond the 4 Fs: What is Fedora effectively doing for Open Source?

[en_US version below]

Finalmente, depois da viagem de volta, do descanso e de retornar ao trabalho, consegui uns minutos para postar a segunda palestra que apresentei no FISL 14, ao lado do grande amigo e colega de trabalho Leonardo Vaz (obrigado Leo!). Agradeço também a presença e participação de outros Embaixadores Fedora do Brasil, como o Wolnei, Penasio, Marcelo e ainda outros que o cansaço não deixa lembrar (me desculpem!).

A idéia dessa palestra (aqui estão os slides, e aqui está o vídeo oficial) era demonstrar que, nos seus atuais 10 anos de existência, o Projeto Fedora sempre esteve focado na sua missão de avançar o estado da arte do Software Livre e Open Source. Começamos a palestra com uma rápida explicação de como e porque surgiu o projeto, e então fizemos uma recapitulação de todas as principais tecnologias e projetos que o Fedora integrou e ajudou a amadurecer, comentando ano a ano cada um dos releases lançados. O público se demonstrou bastante interessado, e acho que conseguimos demonstrar claramente que existe muito mais no Fedora do que aquilo que cabe no DVD de instalação, e que as pessoas devem não apenas instalar o Fedora, mas também esmiuçar detalhadamente todas as inúmeras funcionalidades que estão aguardando nos repositórios oficiais. Basta procurar o que se quer, tem um pouco-bastante de tudo!

[en_US] More FISL 14: Beyond the 4 Fs: What is Fedora effectively doing for Open Source?

Finally, after traveling back, getting some rest and then back to work, I could free up some minutes to post about the second talk I presented at FISL 14, beside my good friend and workmate Leonardo Vaz (thank you Leo!). I also thank the presence and participation of other brazilian Fedora Ambassadors, such as Wolnei, Penasio, Marcelo and still others that I'm too tired to remember (sorry!).

The idea on this talk (here are the slides, and here is the official video) was to demonstrate that, during its current 10 years of existance, the Fedora Project has always been focused on its mission of advancing the state-of-the-art in Free and Open Source Software. We started the talk with a quick explanation of how and why the project was created, and then we did a recollection of all the main technologies and projects that Fedora has integrated and helped mature, commenting each of the releases launched year after year. The public has shown great interest, and I believe we could demonstrate clearly that there is much more to Fedora than fits into the installation DVD, and that people should not just install Fedora, but also examine closely all the countless functionalities that are just waiting in the official repositories. You just need to search what you want, there's a little-lot of everything!