Cross-Compilar o QT5 para a Raspberry PI

Alguns meses depois… hora de voltar a ativa, muita coisa para se publicar, mas como sempre pouco tempo… durante este tempo fizemos a aquisição da Raspberry PI 512mb, para mais informações visite o site raspberrypi.

Eu não fiz este tutorial, apenas estou demonstrando aqui a minha experiência em cross-compilar o QT5 para a Raspberry PI, o tutorial que usei como base está no site qtonpi que contem muito mais informações.

A primeira ação é criar a pasta onde serão salvos todos os arquivos necessários para cross-compilar o QT5, então com os comandos abaixo no terminal do linux você cria e entra no diretório “opt” dentro da sua pasta “home”:
1. labsyn@labsynVM:~$ mkdir ~/opt
2. labsyn@labsynVM:~$ cd ~/opt

Agora é necessário fazer o download dos arquivos de imagem da Raspbian Wheezy em raspberrypi.org. Suponho que ja tenha gravado o sd card e testado sua Rasp, basta copiar a o arquivo que já baixou anteriormente para a pasta, mas se perdeu esses arquivos, baixe novamente, só não esquece de modificar o comando para a versão da Wheezy que está gravada no seu sd card:
1. labsyn@labsynVM:~/opt$ wget http://files.velocix.com/c1410/images/raspbian/2012-07-15-wheezy-raspbian/2012-12-16-wheezy-raspbian.zip
2. labsyn@labsynVM:~/opt$ unzip 2012-12-16-wheezy-raspbian.zip

Agora é necessário montar a imagem:
1. labsyn@labsynVM:~/opt$ sudo mkdir /mnt/rasp-pi-rootfs
2. labsyn@labsynVM:~/opt$ sudo mount -o loop,offset=62914560 2012-12-16-wheezy-raspbian.img /mnt/rasp-pi-rootfs
1. labsyn@labsynVM:~/opt$ wget http://swap.tsmt.eu/gcc-4.7-linaro-rpi-gnueabihf.tbz with sha1 f6255c6aca925239dc943d22a794f642daa17e65
2. labsyn@labsynVM:~/opt$ tar -xf gcc-4.7-linaro-rpi-gnueabihf.tbz

A Raspberry já possui um cross-compiler ideal, o que poupa muito tempo e muita dor de cabeça…. para mais informações acesse github.com/raspberrypi/tools. Mas se quiser ser mais específico, acesse sergioprado.org/

Obs: Se estiver trabalhando em uma máquina 64-bit, vai precisar instalar as bibliotecas de  32-bit “ia32-libs”, não foi o meu caso:
labsyn@labsynVM:~/opt$ sudo apt-get install ia32-libs

Obtendo o código do repositório do cross-compiler:
1. labsyn@labsynVM:~/opt$ git clone git://gitorious.org/cross-compile-tools/cross-compile-tools.git

Iniciando o repositório Qt5:
1. labsyn@labsynVM:~/opt$ git clone git://gitorious.org/qt/qt5.git
2. labsyn@labsynVM:~/opt$ cd qt5
3. labsyn@labsynVM:~/opt/qt5$ ./init-repository

Antes de aplicar os repositorios, se estiver atrás de um firewall, execute o comando para evitar problemas com “./init-repository”:
4. labsyn@labsynVM:~/opt/qt5$ sed -i 's/git:\/\//https:\/\/git./' .gitmodules

Em seguida:
5. labsyn@labsynVM:~/opt/qt5$ ./init-repository -f
6. labsyn@labsynVM:~/opt/qt5/$ cd ~/opt/qt5/qtjsbackend
7. labsyn@labsynVM:~/opt/qt5/$ git fetch https://codereview.qt-project.org/p/qt/qtjsbackend refs/changes/56/27256/4 && git cherry-pick FETCH_HEAD

Neste ponto, temos finalmente um ambiente necessário para compilar o QT5 para a Raspberry. Agora basta corrigir links e caminhos:
1. labsyn@labsynVM:~$ cd ~/opt/cross-compile-tools
2. labsyn@labsynVM:~$ sudo ./fixQualifiedLibraryPaths /mnt/rasp-pi-rootfs/ ~/opt/gcc-4.7-linaro-rpi-gnueabihf/bin/arm-linux-gnueabihf-gcc

Retornando para a pasta e finalmente iniciar:
1. labsyn@labsynVM:~$ cd ~/opt/qt5/qtbase
2. labsyn@labsynVM:~/opt/qt5/qtbase$ ./configure -opengl es2 -device linux-rasp-pi-g++ -device-option CROSS_COMPILE=~/opt/gcc-4.7-linaro-rpi-gnueabihf/bin/arm-linux-gnueabihf- -sysroot /mnt/rasp-pi-rootfs -opensource -confirm-license -optimized-qmake -reduce-relocations -reduce-exports -release -make libs -prefix /usr/local/qt5pi
3. labsyn@labsynVM:~/opt/qt5/qtbase$ make -j 4

Ela deve funcionar, mas depois de um bom tempo, eu tive a ingrata surpresa:
cc1: fatal error: .pch/release-shared/Qt5Gui: No such file or directory
compilation terminated.
make[2]: *** [.obj/release-shared/pixman-arm-neon-asm.o] Error 1
make[2]: *** Waiting for unfinished jobs....
make[2]: Leaving directory `/home/labsyn/opt/qt5/qtbase/src/gui'
make[1]: *** [sub-gui-make_first] Error 2
make[1]: Leaving directory `/home/labsyn/opt/qt5/qtbase/src'
make: *** [sub-src-make_first] Error 2

Estranho, mas a única solução que achei foi retirar esse erro inserindo “-no-pch” no ./configure. Então tive que executar os seguintes commandos, mas se não teve problema, pode pular direto para “make install”:
1. labsyn@labsynVM:~/opt/qt5/qtbase$ ./configure -opengl es2 -device linux-rasp-pi-g++ -device-option CROSS_COMPILE=~/opt/gcc-4.7-linaro-rpi-gnueabihf/bin/arm-linux-gnueabihf- -sysroot /mnt/rasp-pi-rootfs -opensource -confirm-license -optimized-qmake -reduce-relocations -reduce-exports -release -make libs -prefix /usr/local/qt5pi –no-pch
2. labsyn@labsynVM:~/opt/qt5/qtbase$ make -j 4


E agora:

3. labsyn@labsynVM:~/opt/qt5/qtbase$ sudo make install

Continua…

Tiny6410

Já estava com este kit faz tempo, mas só agora vou começar a desenvolver efetivamente, vejo nele o nosso controle central para o servidor. Após ler um pouco de chinês(rsrsrs), ele está testado e aprovado, funcionando muito bem.
Este é o kit FriendlyArm Tiny 6410, enquanto olhava e testava, já ia sonhando com a infinitas de possibilidades. Já fiz várias pesquisas e consegui muito material para iniciar o desenvolvimento, um local que encontrei muito conteúdo útil para o desenvolvimento foi o blog do Sergio Prado. Pretendo utilizar a IDE Eclipse juntamente com QT no Ubuntu para desenvolver uma interface gráfica, intuitiva e de tempo real. Inicialmente pretendo utilizar o display do kit, mas penso na saída VGA para o "produto final", já que não pretendo utilizar o touchscreen.














Testando o kit, vi duas aplicações que me interessaram e que tem muito em comum do que pretendo fazer. As dificuldades são muitas, mas a persistência vence todos os obstáculos e veremos o que acontecerá quando juntarmos as 3 placas, com certeza muita coisa boa vai aparecer e muitas idéias novas surgirão.

Simulação e Testes - USB 18f4550

Bom, entre uma obra e outra e depois de algumas especificações, consegui tempo para a simulação das placas de controle de entrada e saídas, mais rápido do que imaginado por usar como base uma simulação que achei na internet, não me lembro o site, mas com algum tempo dedicado a pesquisar é possível achar muita coisa sobre conexão usb utilizando pic, principalmente 18f4550 e 18f2550, além de uma infinidade de possibilidades.
Fiz uma modificação na simulação que utiliza o proteus para o hardware e o ccs para a programação do pic, como a intenção é utilizar todas os pinos possíveis como entradas e saídas digitais foram necessárias duas simulações independentes, uma só para as entradas utilizando chaves e outra só para as saídas utilizando leds, mas nada complicado.
Então fiz duas programações, para a comunicação usb utilizei a Human Interface Device - HID(http://en.wikipedia.org/wiki/Human_interface_device), dá trabalho para conseguir compilar a primeira vez e entender como tudo funciona, mas depois que consegue compilar a primeira, tudo fica mais fácil e funciona perfeitamente.
Código básico:

#include <18F4550.h>
//achei melhor configurar os fuses de forma individual
#FUSES HSPLL
#FUSES WDT//Habilita o Watchdog Timer(WDT) - Não tive problemas usando o WDT
#FUSES NOPROTECT
#FUSES NODEBUG
#FUSES NOLVP
#FUSES PLL5
#FUSES CPUDIV1
#FUSES USBDIV
#FUSES VREGEN
#FUSES WDT128 //Período do WDT

#use delay(clock=48000000) //valor do clock obrigatório

#define USB_HID_DEVICE TRUE //Utilizando a classe HID
#define USB_EP1_TX_ENABLE USB_ENABLE_BULK //Habilitando o(EndPoint1) para In bulk
#define USB_EP1_RX_ENABLE USB_ENABLE_BULK //Habilitando o(EndPoint1) para OUT bulk
#define USB_EP1_TX_SIZE 32 //tamanho reservado para a transferência
#define USB_EP1_RX_SIZE 32

//Declarações necessárias
#include
#include //Arquivo de configuração USB para o dispositivo deve conter o PID e o VID que identificam o dispositivo quando conectado
#include
//Função para conexão, serve para a numeração do dispositivo
void USB_debug() {
static int8 last_connected;
static int8 last_enumerated;
int8 new_connected;
int8 new_enumerated;

new_connected=usb_attached();
new_enumerated=usb_enumerated();
usb_wait_for_enumeration();

last_connected=new_connected;
last_enumerated=new_enumerated;
}

void main(void) // Função principal
{
//Declarando as variáveis e especificando seu tamanho
int8 envia[USB_EP1_TX_SIZE];
int8 recebe[USB_EP1_RX_SIZE];

usb_init(); // Inicializa a comunicação USB.

setup_wdt(wdt_ON); //Reinicia o WDT

while (TRUE) // while infinito.
{
//Funções de comunicações devem ser constantemente executadas para evitar a desconexão do dispositivo
usb_task();

USB_debug();

if(usb_enumerated()) //se o dispositivo está numerado, está conectado.
{
//Pronto, agora é só mandar ou receber informações e reiniciar o WDT
usb_put_packet(1, envia, 32, USB_DTS_TOGGLE); //enviando pacote de dados
if (usb_kbhit(1)) //testa se um pacote foi recebido
{
usb_get_packet(1, recebe, USB_CONFIG_HID_RX_SIZE); //as informações recebidas são colocadas na variável "recebe"
}
restart_wdt();//Reinicia o WDT
}
}









Pronto, depois foi apenas necessário programar como necessário e compilar, utilizei a IDE CCS 4.057.
E depois modifiquei o software, fiz com que identifica-se automaticamente o dispositivo e por meio de PictureBox e CheckBox identifiquei as chaves acionadas e acionei os leds... e funcionou perfeitamente como as imagens.















Então é isso, agora vamos para a parte mais complicada, o controle central e a IHM...

Placa de Desenvolvimento PIC USB

Estava com dificuldades para desenvolver e testar o software para as placas do projeto Servidor, então procurei por kits de desenvolvimento USB, achei algumas de baixo custo montada, mas como gosto de desafios, achei uma rápida de confeccionar e que já tinha todo material em mãos. Esta é uma placa de desenvolvimento PIC USB que encontrei no site PicTronics porém, fiz algumas alterações no lay-out e no Hardware utilizado:

- Substitui a barra de pinos de conexão com o gravador PicKit2 da Microchip por um RJ11 fêmea, utilizado no PicKit2 da PersonalPic e que também é um ótimo gravador(assunto para outro tópico);
- Utilizei apenas capacitores cerâmicos de disco;
- Substitui os diodos 1N5817 por 1N4148, mais lentos, mas que também funcionam.

Uma placa simples, fácil de montar e que permite fazer testes e simulações de forma prática e rápida. Tem como ponto positivo:

- Não precisa de fonte externa para simular e nem para gravar, mas recomendo utilizar fonte estabilizada esterna se estiver simulando em protoboard, este aliás é outro ponto forte;
- Pode conectar facilmente a placa com um protoboard e montar um circuito de desenvolvimento próprio;
- Como utiliza o PicKit2, não é necessário bootloader;
- O tamanho reduzido é outra praticidade, se mecher no lay-out mais um pouquinho ela cabe no bolso.

Para confecção utilizei o método térmico, rápido e prático
No site da PicTronics você consegue baixar o esquema eletrônico e o Lay-out da Placa, mas no link abaixo, segue o Esquema, o Lay-out original e o que eu adaptei.

Baixar Arquivos da Placa

CUSCOPIC

No mercado/internet é possível encontrar várias plataformas para o desenvolvimento de aplicações com microcontroladores, principalmente para quem está iniciando neste mundo e que além de desenvolver a parte de software pode implementar a parte de hardware, o que é fundamental para quem está pensando em criar aplicações no futuro, principalmente se forem comerciais...
Uma destas plataformas é a CUSCOPIC, um kit prático de desenvolvimento, ideal para quem pensa em iniciar neste mundo. Tem algum tempo que adquiri o kit e montei sem maiores dificuldades, principalmente por ser muito bem documentado e com muitos exemplos que podem ser encontrados no site do equipamento http://www.mecatronica.org.br/disciplinas/cuscopic/index.html.
A CUSCOPIC é uma plataforma bastante didática e simples, os desenhos da placa foram muito bem elaborados e o kit separado em partes, o que o torna prático para o transporte já que pode levar para onde quiser apenas o que for utilizar.

Os pontos fracos são a necessidade de gravação do bootloader pela porta paralela e a necessidade de porta serial (pode ser utilizada com um conversor USB-serial externo) para gravação da programação, ruim porque praticamente nenhum notebook tem essas portas hoje em dia. Outro ponto, não diria negativo, mas problemático, seria a dificuldade de se utilizar os programas de gravação nos novos sistemas operacionais, mas tudo pode ser resolvido com um gravador USB externo.
O idealizador do projeto é o professor Daniel Corteletti, Bacharel em Ciência da Computação pela Universidade de Caxias do Sul (UCS) – RS e Instrutor de Educação Profissional de Nível Técnico - Centro Tecnológico de Mecatrôncia do SENAI. Ele também mantém um fórum de discussão da plataforma no Yahoo e comunidade no Orkut.
Como a ultima atualização foi em 2009, nos resta saber quando estará disponível uma nova atualização, quem sabe USB, SD e RTC a vista. Se precisar de ajuda professor, estamos a disposição...
Uma ótima opção, apesar de ainda não ter utilizado todas as funcionalidades da plataforma, mas recomendo, depois abordarei alguns experimentos.