Criar um mostrador para o Pebble Time

Pebble Time Face Poupar Melhor

Pebble Time Face Poupar Melhor

O Pebble Time oferece uma ferramenta de apoio ao desenvolvimento para utilizadores (Software Development Kit – Pebble SDK). Essa ferramenta facilita e bastante a compilação e teste com um conjunto de instruções prontas e um emulador para o computador onde estão a trabalhar.

Vou poupar-vos aos detalhes da criação do ambiente de trabalho para o SDK. Depois de criado, o SDK do Pebble tem um conjunto de comandos para compilar o código e enviar o resultado para o emulador.

Ao contrário do ambiente de desenvolvimento online, no próprio computador a compilação e teste são mesmo muito rápidos. Se querem mesmo começar a desenvolver para o Pebble Time, o melhor que têm a fazer é poupar muito tempo instalando o SDK no vosso computador e aprendendo os comandos para o usar.

Podem espreitar o resultado final na app-store Pebble.

Mais bugs graves no Android!

Há uns dias voltou a surgir mais um problema grave no sistema operativo Linux. Mas, enquanto na maioria dos PCs é possível actualizar o Linux de forma fácil, o mesmo não se verifica no Android. Segundo os investigadores que descobriram o problema, 66% dos Androids estarão vulneráveis, embora tal seja discutido.

O problema de muitos de nós não podermos actualizar os nossos equipamentos electrónicos começa a tornar-se demasiado grave. Já o havíamos referido neste artigo do Stagefright. Agora volta a acontecer, e não admira que as pessoas a mudar para os iPhones seja cada vez maior!

Um site que acompanha a evolução destas falhas no Android é o AndroidVulnerabilities.org. Eles produzem um gráfico muito interessante, visível abaixo, que permite ver qual a percentagem de dispositivos seguros, e os inseguros, ao longo dos últimos anos. Como podem observar, a grande  maioria permanece insegura:

Evolução vulnerabilidades em Android

Evolução vulnerabilidades em Android

170º bug: o da falha de segurança nos Android e da programação para o Pebble Time

Podcast do Poupar Melhor

Esta semana falamos sobre um defeito importante que afetou 66% dos equipamentos com sistema operativo Android. Terminamos a falar sobre aquilo que vamos passar a contar acerca da programação para o Pebble Time.

Podem aceder aqui à lista completa de episódios do Podcast. O Podcast do PouparMelhor está também no iTunes.

Play

Menos Velocidade, mais Poluição?

A ideia que todos temos interiorizada é que o consumo de combustível de um automóvel aumenta, com o aumento da velocidade. E com o aumento do consumo de combustível, aumenta naturalmente a poluição. Na proposta da Câmara para a Segunda Circular, é por isso assumido que a redução do limite de velocidade máxima de circulação contribuiria para uma redução dos impactes ambientais.

Por outro lado, é nos dito que para minimizar o consumo, é necessário engrenar a velocidade mais elevada, e conduzir nessa engrenagem sem deixar o carro ir abaixo. Acontece que na maioria dos carros, não se consegue fazer isso com um limite de 60 Km/h. Eu no meu não consigo…

A verdade é que a eficiência de um motor vai melhorando à medida que vamos inicialmente subindo a velocidade. Tal é verdade no arranque inicial, e tal mantém-se até determinada velocidade. Mas, a partir dessa velocidade, a potência necessária para o veículo se mover a uma velocidade superior aumenta mais que a melhoria de eficiência no motor, pelo que o consumo voltará a subir.

O ponto em que se verifica a inflexão de consumos é dependente das várias marcas/modelos, mas também de um conjunto diverso de factores variáveis, conforme temos referido em múltiplos artigos do Poupar Melhor. A melhor compilação que conheço no domínio desta área é a dada pelo documento “Transportation Energy Data Book”, que na sua página 126 tem o seguinte gráfico:

Consumo vs. velocidade, ao longo das últimas décadas

Consumo vs. velocidade, ao longo das últimas décadas (atenção às medidas imperiais)

Os dados deste gráfico evidenciam que actualmente os automóveis estarão próximos do seu melhor consumo quando circularem a quase 100 Km/h. E isto para os automóveis americanos, que sabemos não são tão eficientes como os europeus, que tipicamente utilizamos em Portugal. Esse valor está também de acordo os melhores consumos que consigo no meu automóvel. Notem ainda como as velocidades onde os automóveis têm os seus melhores consumos, tem vindo a subir nas últimas décadas. Tal não é obviamente surpreendente dadas as melhorias em termos de motorizações, mas também de aerodinâmica.

Os valores que a literatura consagra como óptimos, na zona dos 80 Km/h, não são válidos para todos os automóveis. Os mais recentes de uma forma geral ficam acima, mas com a notável excepção dos carros híbridos e eléctricos. Nestes, a velocidade óptima é genericamente bastante inferior, mas também não contam significativamente para o aumento das emissões de gases poluentes.

Assim sendo, o que a proposta da Câmara vai conseguir, ao reduzir a velocidade máxima da Segunda Circular, de 80 Km/h para 60 Km/h, é aumentar a poluição, o contrário obviamente do que é desejável!

Raspberry e diferentes cartões micro SD

Temos vindo aqui a analisar diferentes aspectos relacionados com o desempenho dos Raspberry, nomeadamente entre as versões Raspberry Pi model B e a Raspberry Pi model B versão 2.

Quando configurei o mais recente Raspberry Pi model B versão 2 cá em casa, a velocidade era bastante sofrível. Na verdade, o OSMC arrastava-se e ficava mesmo bloqueado. Foi então que me lembrei que não havia sido boa ideia utilizar o único cartão micro SD que então tinha à mão.

Na verdade, nem todos os cartões SD nasceram iguais! Muitas vezes podemos interrogar-nos porque custam uns bastante mais que outros? Na verdade, um dos factores que distingue vários tipos de cartões SD é a sua velocidade de escrita e de leitura. Há várias boas referências na Internet, sendo que destaco particularmente esta página.

Acabei por substituir o cartão micro SD por outro, com características diferentes. E realmente a mudança foi brutal! Olhando para os dois abaixo, podem parecer iguais, mas há um dourado, que por acaso (?) é o que se porta melhor:

O dourado é o melhor!

O dourado é o melhor, e não é por ter 16GB!

Para averiguar as diferenças entre os dois, resolvi fazer alguns testes. Utilizei o comando hdparm (é preciso instalá-lo, pois não vem por defeito com o OSMC), bem como o dd. Ambos são comandos problemáticos, especialmente o dd, pelo que tenham sempre a certeza do que estão a fazer!

No cartão micro SD inicial, o hdparm deu valores de leitura com cache, ligeiramente superiores a 430 MB/segundo. A ler directamente do cartão, a velocidade ficou próxima dos 18 MB/segundo. O comando dd permite-nos averiguar a velocidade de escrita, e essa foi ainda inferior, entre os 8 e 9 MB/segundo. A velocidade de leitura com o dd foi ainda superior ao do hdparm:

osmc@osmc:~$ uname -a
Linux osmc 4.3.0-10-osmc #1 SMP PREEMPT Sun Nov 29 14:06:50 UTC 2015 armv7l GNU/Linux
osmc@osmc:~$ sudo hdparm -tT /dev/mmcblk0p2
/dev/mmcblk0p2:
Timing cached reads: 878 MB in 2.00 seconds = 438.80 MB/sec
Timing buffered disk reads: 54 MB in 3.06 seconds = 17.64 MB/sec
osmc@osmc:~$ sudo hdparm -tT /dev/mmcblk0p2
/dev/mmcblk0p2:
Timing cached reads: 864 MB in 2.00 seconds = 431.84 MB/sec
Timing buffered disk reads: 56 MB in 3.11 seconds = 18.01 MB/sec
osmc@osmc:~$ dd if=/dev/zero of=test bs=1048576 count=200
200+0 records in
200+0 records out
209715200 bytes (210 MB) copied, 23.2975 s, 9.0 MB/s
osmc@osmc:~$ dd if=test of=/dev/null bs=1048576
200+0 records in
200+0 records out
209715200 bytes (210 MB) copied, 0.437839 s, 479 MB/s
osmc@osmc:~$ rm test
osmc@osmc:~$ dd if=/dev/zero of=test bs=1048576 count=200
200+0 records in
200+0 records out
209715200 bytes (210 MB) copied, 26.4668 s, 7.9 MB/s
osmc@osmc:~$ dd if=test of=/dev/null bs=1048576
200+0 records in
200+0 records out
209715200 bytes (210 MB) copied, 0.420012 s, 499 MB/s

No segundo cartão micro SD, o hdparm deu valores de leitura com cache de cerca de 380 MB/segundo. A ler directamente do cartão, a velocidade ficou ligeiramente acima dos 18 MB/segundo. Com o comando dd, a velocidade de escrita ficou entre os 45 e 50 MB/segundo, com a velocidade de leitura do dd a ser também superior à do hdparm:

osmc@osmc:~$ uname -a
Linux osmc 4.3.0-10-osmc #1 SMP PREEMPT Sun Nov 29 14:06:50 UTC 2015 armv7l GNU/Linux
osmc@osmc:~$ sudo hdparm -tT /dev/mmcblk0p2
/dev/mmcblk0p2:
Timing cached reads: 762 MB in 2.00 seconds = 380.58 MB/sec
Timing buffered disk reads: 56 MB in 3.02 seconds = 18.54 MB/sec
osmc@osmc:~$ sudo hdparm -tT /dev/mmcblk0p2
/dev/mmcblk0p2:
Timing cached reads: 756 MB in 2.00 seconds = 377.79 MB/sec
Timing buffered disk reads: 56 MB in 3.01 seconds = 18.57 MB/sec
osmc@osmc:~$ dd if=/dev/zero of=test bs=1048576 count=200
200+0 records in
200+0 records out
209715200 bytes (210 MB) copied, 4.57351 s, 45.9 MB/s
osmc@osmc:~$ dd if=test of=/dev/null bs=1048576
200+0 records in
200+0 records out
209715200 bytes (210 MB) copied, 0.476132 s, 440 MB/s
osmc@osmc:~$ rm test
osmc@osmc:~$ dd if=/dev/zero of=test bs=1048576 count=200
200+0 records in
200+0 records out
209715200 bytes (210 MB) copied, 4.04712 s, 51.8 MB/s
osmc@osmc:~$ dd if=test of=/dev/null bs=1048576
200+0 records in
200+0 records out
209715200 bytes (210 MB) copied, 0.489697 s, 428 MB/s

Resumindo, a velocidade de escrita do segundo cartão micro SD parece ser a determinante na perceção de desempenho do OSMC. É aqui que entra a classe dos cartões, e se repararam o segundo cartão é da classe 10, enquanto o primeiro é de classe 4. As classes dos cartões estão relacionados com a sua capacidade de escrita, essencial na fotografia/vídeo. Notem até que a velocidade de leitura do primeiro é melhor!

Para que o OSMC tenha este comportamento, é em princípio porque está a escrever muita informação no cartão micro SD. Presumo que quando está a fazer streaming, que esteja a guardar informação temporariamente no cartão micro SD. Ainda assim, é uma dúvida que vou tentar esclarecer posteriormente…

Raspberry Pi model B versus Raspberry Pi model B versão 2

Se fizeram scroll até ao final dos posts sobre as medições com o NBench do Raspberry Pi model B (RPi B) e do Raspberry Pi model B versão 2 (RPi 2) já sabem o que aqui vou resumir. O RPi 2 é realmente mais rápido, o que podem observar pelo vídeo acima.

O vídeo acima mostra primeiro o RPi B a mudar entre opções no ecrã inicial até chegar à previsão meteorológica e depois a mesma operação no RPi 2. O que é visível é o tempo de resposta entre ambos os equipamentos. O primeiro apresenta inclusivamente paragens para iniciar a apresentação da previsão meteorológica.

O RPi 2 é muito mais rápido que o seu antecessor RPi B. Os resultados dos testes abaixo exprimem essa diferença. O RPi B só tem um core. Um core é um componente de computação que, quando existam mais de um, permite processar instruções em simultâneo.

Sistema testado Número de Testes paralelos Resultado global
RPi B 1 76.0
RPi 2 1 173.7
RPi 2 4 402.5