Visual Studio Code and ev3dev

On a quest to promote ev3dev as an education tool several ev3dev users suggested that developing an ev3dev IDE could make ev3dev easier to use and more accessible for new users.

A great milestone has been achieved with ev3dev-browser, an ev3dev extension for Visual Studio Code:

You just need to install Visual Studio Code, press Ctrl+P and past “ext install ev3dev-browser”, install the ev3dev-browser (currently 0.1.0 by David Lechner) and reload the IDE window.

If you have also a python extension installed and you have something running an ev3dev stretch image (2017-07-25 or newer) it will appear on the left-bottom corner pane of the IDE (“EV3DEV-DEVICES”) and you can transfer your python script to it, run them, open an SSH session…

ev3dev based on Debian Stretch is still in development (so not stable yet) but I have great expectations that we all can use it soon.

Módulo MFL em Tomar

Os meus primeiros 3 módulos MFL (Módulo Ferrovia LEGO) junto dos restantes módulos da PLUG no Tomar BRInCKa 2015:

O  módulo ao centro tem dois desvios motorizados, bem como um «desengatador» no troço de recta entre as duas agulhas. Toda a electrónica está disfarçada por baixo das linhas.

O módulo da direita consiste numa plataforma rotativa motorizada e controlada por um LEGO Mindstorms EV3 correndo ev3dev (uma variante de Debian para o EV3). Sobre o carril um pequeno comboio controlado por SBrick (bluetooth).

O módulo da esquerda, quase 100% da minha marida, começou com uma pequena cascata no nosso presépio do Natal anterior.

A montagem no BRInCKa 2015 não ficou completa por isso todas as demonstrações são manuais, controladas por mim. Neste video gravado em casa é o computador (LEGO Mindstorms EV3) a fazer tudo sozinho:

O que faltou montar e que permite a automação plena? As componentes RFID – por baixo do pequeno comboio há um identificador RFID do tamanho de uma moeda que permite identificá-lo e em certa medida seguir-lhe a posição. Na montagem do video existem dois leitores RFID (USB) por baixo da linha (um no extremo direito e outro junto ao sistema de desengate). O EV3 utiliza esses sensores para perceber se o comboio está nos sítios certos antes de passar à acção seguinte.

ev3dev – backup e boot time

Nesta primeira semana de experiências com o ev3dev utilizei sempre o mesmo cartão microSD (um Kingston microSD 2GB penso que classe 4). Os tempos de arranque (desde o carregar no botão de power até ao primeiro ‘ping’) foram sempre de 60 segundos, não é muito mau comparado com o tempo de arranque do EV3 com o firmware LEGO por isso não me preocupei em experimentar outros cartões.

Mas hoje lembrei-me de ter visto alguma utilização de swap e já que as operações de update são longas (mais de 10 minutos só para actualizar o catálogo com ‘apt-get update’) podia ser que a coisa melhorasse com um cartão mais rápido.

Trocar de cartão é simples e faz-se em 5 minutos:

  1. colocar o cartão no meu portátil Ubuntu
  2. criar uma imagem do cartão e guardar como backup
  3. tirar o cartão e colocar outro qualquer
  4. repor a imagem anterior neste novo cartão

Como novo cartão utilizei um SanDisk Ultra de 4 GB (microSDHC classe UHS-I).

Os tempos de arranque desceram de 60 segundos para 50 segundos, nada mau. E a actualização do catálogo (‘apt-get update’) passou para ligeiramente menos de 8 minutos. Não é um ganho espantoso mas se estiver a trabalhar com pilhas ou baterias em vez de regulador DC já é qualquer coisa.

Como o novo cartão é de 4 GB em vez de 2 GB posso aproveitar o novo espaço extendendo o file system. Podia tê-lo feito de dentro do próprio ev3dev mas ainda não domino muito a linha de comando por isso fi-lo em 3 fases:

  1. Colocando o cartão no meu Ubuntu e utilizando o Gparted para criar uma nova partição do tipo ‘lvm2 pv’ com os 1906 MB livres no cartão
  2. Ainda no Ubuntu usando o system-config-lvm para adicionar a nova partição ao Volume Group já existente
  3. Voltando ao ev3dev e extendendo o Logical Volume ‘root’:
root@ev3dev:~# lvextend --extents +100%FREE /dev/ev3devVG/root
  Extending logical volume root to 3.59 GiB
  Logical volume root successfully resized

[editado posteriormente]

faltou indicar como expandir o file system:

resize2fs  /dev/ev3devVG/root

[se não der  no EV3 pode-se fazer no Ubuntu, precedendo o comando com ‘sudo’]

 

ev3dev – controlando motores

A utilização básica do LEGO Mindstorms EV3 com ev3dev fica completa com a utilização de motores.

Ligando um motor (45503 EV3 Medium Servo Motor) na ficha A, o sistema operativo acusa o evento:

root@ev3dev:~# dmesg
(...)
tacho-motor tacho-motor0: Tacho motor registered.
ev3-tacho-motor outA:motor: A Tacho Motor connected to port outA gpio 91 irq 192

Uma vez mais é necessário consultar a wiki do projecto ev3dev para entender como aceder aos motores. Estes também são mapeados pelo sistema operativo, desta vez em “/sys/bus/legoev3/devices/” e em ” /sys/class/tacho-motor/”:

root@ev3dev:~# ls /sys/bus/legoev3/devices/
in2  in3  in4  outA  outA:motor  outB  outC  outD
root@ev3dev:~# ls /sys/class/tacho-motor/
tacho-motor0
root@ev3dev:~# ls /sys/class/tacho-motor/tacho-motor0
device           port_name      pulses_per_second     reset        speed_regulation_K  subsystem
duty_cycle     position       pulses_per_second_sp  run            speed_regulation_P  time_sp
duty_cycle_sp  position_mode  ramp_down_sp        run_mode        state            type
estop           position_sp    ramp_up_sp        speed_regulation_D    stop_mode        uevent
polarity_mode  power          regulation_mode        speed_regulation_I    stop_modes

Muito informação para processar mas para começar podemos confirmar apenas o tipo de motor:

root@ev3dev:~# cat /sys/class/tacho-motor/tacho-motor0/type
minitacho

Os motores Mindstorms são inicializados no modo “run forever”, podemos também confirmar isso:

root@ev3dev:~# cat /sys/class/tacho-motor/tacho-motor0/run_mode
forever

Neste modo podemos controlar o motor controlando 2 parâmetros:

  • /sys/class/tacho-motor/tacho-motor0/duty_cycle_sp
  • /sys/class/tacho-motor/tacho-motor0/run

o shell script abaixo faz o motor rodar 5 segundos num sentido e 5 segundos no sentido inverso, com um duty factor de 50%:

 #!/bin/bash
 echo   0 > /sys/class/tacho-motor/tacho-motor0/duty_cycle_sp
 echo   1 > /sys/class/tacho-motor/tacho-motor0/run
 echo   50 > /sys/class/tacho-motor/tacho-motor0/duty_cycle_sp
 sleep 5s
 echo   0 > /sys/class/tacho-motor/tacho-motor0/duty_cycle_sp
 sleep 1s
 echo   -50 > /sys/class/tacho-motor/tacho-motor0/duty_cycle_sp
 sleep 5s
 echo   0 > /sys/class/tacho-motor/tacho-motor0/duty_cycle_sp
 echo   0 > /sys/class/tacho-motor/tacho-motor0/run

 

 

ev3dev – lendo sensores

Começar a trabalhar com sensores Mindstorms, mais concretamente Touch Sensores. Tenho duas versões: NXT e EV3.

Adicionei touch sensor (NXT) no porto #2. O sistema operativo detecta o acontecimento:

root@ev3dev:~# dmesg
...
msensor sensor0: Mindstorms sensor registered.
touch-sensor in2:nxt-analog-sensor: Touch sensor connected to port in2

Alguma informação útil na wiki do projecto ev3dev:

De acordo com a wiki, os sensores Mindstorms são mapeados em “/sys/class/msensor”:

root@ev3dev:~# ls /sys/class/msensor
 sensor0

Confirma-se a presença de um sensor “sensor0”. Que podemos saber acerca dele?

root@ev3dev:~# ls /sys/class/msensor/sensor0
 bin_data     dp    num_values  subsystem  units   value2  value5
 bin_data_format  mode    port_name   type_id    value0  value3  value6
 device         modes    power        uevent     value1  value4  value7

Muita informação, alguma apenas genérica. Fiquemos por “mode” e “value0”:

root@ev3dev:~# cat /sys/class/msensor/sensor0/mode
 TOUCH

Sim, é um Touch Sensor. E como saber o estado?

root@ev3dev:~# cat /sys/class/msensor/sensor0/value0
 0

O sensor estava em repouso. Vamos repetir enquanto premimos o sensor:

root@ev3dev:~# cat /sys/class/msensor/sensor0/value0
 1

Então e se trocarmos por um sensor EV3?

root@ev3dev:~# dmesg
 ...
 msensor sensor0: Mindstorms sensor unregistered.
 msensor sensor1: Mindstorms sensor registered.
 touch-sensor in2:ev3-analog-sensor: Touch sensor connected to port in2

E qual é o device?

root@ev3dev:~# ls /sys/class/msensor/
 sensor1

Agora é ‘sensor1’ em vez de ‘sensor0’. Talvez a troca tenha sido demasiado rápida ou talvez o sistema operativo nunca liberte os mapeamentos efectuados [até ao próximo boot].

A informação disponível é semelhante:

root@ev3dev:~# ls /sys/class/msensor/sensor1
 bin_data     dp    num_values  subsystem  units   value2  value5
 bin_data_format  mode    port_name   type_id    value0  value3  value6
 device         modes    power        uevent     value1  value4  value7
root@ev3dev:~# cat /sys/class/msensor/sensor1/mode
 TOUCH

E a leitura do estado do sensor funciona da mesma maneira através de ‘value0’.

Este forma do sistema operativo mapear todos os dispositivos no file system dá-nos uma enorme flexibilidade – todas as linguagens de programação permitem aceder a ficheiros… até a própria shell! Eis shell script que se limita a esperar que o sensor seja premido:

#!/bin/bash
 BOTAO=0
 while [ $BOTAO -ne "1" ]; do
 BOTAO=$(cat /sys/class/msensor/sensor0/value0)
 done
 echo "Ouch!" > /dev/tty0

se o ficheiro contendo este script se chamar ’touch.sh’ e tiver permissões de execução podemos invocá-lo directamente da linha de comando:

root@ev3dev:~# chmod +x touch.sh
root@ev3dev:~# ./touch.sh

ou de dentro de outros scripts.

Nota: usei aqui ‘sensor0’, assumo que há apenas um sensor e excepto na situação acima em que retirei um sensor e adicionei outro que por isso ficou ‘sensor1’, será sempre ‘sensor0’.

ev3dev – usando o LCD do EV3

Usando o ev3dev há duas formas de aceder ao LCD do LEGO Mindstorms EV3:

  • modo de texto: terminal via /dev/tty0
  • modo gráfico: framebuffer via /dev/fb0

Ambos os modos estão ainda a sofrer desenvolvimentos mas o segundo modo é seguramente o mais complexo pelo que fico-me por enquanto só pelo modo de texto.

Assim para escrever qualquer coisa basta por exemplo redireccionar o comando echo para /dev/tty0:

echo "Hello world!" > /dev/tty0

Já é qualquer coisa mas para limpar o ecran sem ter de enviar vários “echo” existem formas melhores. Sendo um terminal tty convencional, a maioria dos comandos para terminal devem funcionar (inclusive algumas sequencias de escape). Experimentei o tput:

Para limpar o ecran:

tput clear > /dev/tty0

Para posicionar o cursor:

tput cup linha coluna > /dev/tty0

(tput cup 0 0 envia para o canto superior esquerdo e já agora com tput cols ficamos a saber que o LCD tem 44 colunas)

Para escrever branco sobre negro:

tput smso > /dev/tty0

Para voltar ao negro sobre branco:

tput rmso > /dev/tty0

Muito bem, já escrevo o que quiser em qualquer lado do ecran… mas a fonte é tão pequena que só com uma lupa é que se lê. Como aumentar o texto?

A primeira hipótese que me ocorreu foi instalar o figlet que usa caracteres ASCII para fingir fontes maiores:

apt-get install figlet
figlet -f banner "Teste" > /dev/tty0
figlet -f big "Teste" > /dev/tty0

teste01mas é uma forma um bocado coxa. O melhor mesmo é poder trocar o tamanho dos caracteres e para isso existe o comando “setfont” que felizmente já existe no ev3dev e disponibiliza umas quantas fontes em “/usr/share/consolefonts/”, vejamos só quantas há na variante Lat15 (que serve à maioria das linguas ocidentais incluindo a nossa):

root@ev3dev:~# ls /usr/share/consolefonts/Lat15*
/usr/share/consolefonts/Lat15-Fixed13.psf.gz
/usr/share/consolefonts/Lat15-Fixed14.psf.gz
/usr/share/consolefonts/Lat15-Fixed15.psf.gz
/usr/share/consolefonts/Lat15-Fixed16.psf.gz
/usr/share/consolefonts/Lat15-Fixed18.psf.gz
/usr/share/consolefonts/Lat15-Terminus12x6.psf.gz
/usr/share/consolefonts/Lat15-Terminus14.psf.gz
/usr/share/consolefonts/Lat15-Terminus16.psf.gz
/usr/share/consolefonts/Lat15-Terminus20x10.psf.gz
/usr/share/consolefonts/Lat15-Terminus22x11.psf.gz
/usr/share/consolefonts/Lat15-Terminus24x12.psf.gz
/usr/share/consolefonts/Lat15-Terminus28x14.psf.gz
/usr/share/consolefonts/Lat15-Terminus32x16.psf.gz
/usr/share/consolefonts/Lat15-TerminusBold14.psf.gz
/usr/share/consolefonts/Lat15-TerminusBold16.psf.gz
/usr/share/consolefonts/Lat15-TerminusBold20x10.psf.gz
/usr/share/consolefonts/Lat15-TerminusBold22x11.psf.gz
/usr/share/consolefonts/Lat15-TerminusBold24x12.psf.gz
/usr/share/consolefonts/Lat15-TerminusBold28x14.psf.gz
/usr/share/consolefonts/Lat15-TerminusBold32x16.psf.gz
/usr/share/consolefonts/Lat15-TerminusBoldVGA14.psf.gz
/usr/share/consolefonts/Lat15-TerminusBoldVGA16.psf.gz
/usr/share/consolefonts/Lat15-TomThumb4x6.psf.gz
/usr/share/consolefonts/Lat15-VGA14.psf.gz
/usr/share/consolefonts/Lat15-VGA16.psf.gz
/usr/share/consolefonts/Lat15-VGA28x16.psf.gz
/usr/share/consolefonts/Lat15-VGA32x16.psf.gz
/usr/share/consolefonts/Lat15-VGA8.psf.gz

Bold e 32×16 parece-me bem por isso:

tput clear > /dev/tty0
setfont /usr/share/consolefonts/Lat7-TerminusBold32x16.psf.gz
echo "Hello World" > /dev/tty0

helloworldOs 11 caracteres de “Hello World” encheram uma linha (onde antes, com a fonte default, cabiam 44). Pelo menos já não é precisa a lupa.

ev3dev com USB Hub e USB Audio

Depois de ter Wi-Fi decidi testar mais alguns dispositivos USB que uso com o Raspberry Pi.

Para começar, uma vez que o EV3 apenas tem uma porta USB, imprescindível um hub, de preferência pequeno:

Hub KUNFT 4 Portas USB 2.0 H-088 (na Worten por €6,99)

Com o EV3 ainda desligado liguei-o e a ele o dongle Wi-Fi (ThePiHut).

Da primeira vez não obteve rede, não sei se não esperei tempo suficiente. Retirei o hub, liguei novamente (sem o dongle Wi-Fi) esperei um pouco e depois liguei o dongle e desta vez obtive rede. E a partir daqui cada boot/reboot com tudo ligado funcionou sempre bem.

root@ev3dev:~# lsusb
(...)
Bus 001 Device 002: ID 05e3:0608 Genesys Logic, Inc. USB-2.0 4-Port HUB

Agora o audio:

[Nota: o EV3 já tem uma placa de audio interna, suportada pelo ALSA, e um altifalante interno também. Mas tanto quanto percebi funciona de modo semelhante ao jack audio do Raspberry Pi, por PWM, consumindo CPU… além de ser mono e não permitir ligação externa a um amplificador]

DIY USB to Audio Module for Raspberry PI / Arduino / MAC / PC + More – Green (SKU 315287 na DX – DealExtreme, US$10.88)

root@ev3dev:~# dmesg
(...)
input: Burr-Brown from TI               USB Audio DAC    as /devices/platform/ohci.0/usb1/1-1/1-1.4/1-1.4:1.2/0003:08BB:2704.0001/input/input2
hid-generic 0003:08BB:2704.0001: input: USB HID v1.00 Device [Burr-Brown from TI USB Audio DAC   ] on usb-ohci.0-1.4/input2
(...)
root@ev3dev:~# lsusb
(...)
Bus 001 Device 004: ID 08bb:2704 Texas Instruments Audio Codec
(...)

O ALSA reconhece de imediato a nova placa de som:

root@ev3dev:~# aplay -l
**** List of PLAYBACK Hardware Devices ****
card 0: legoev3 [LEGO Mindstorms EV3 speaker], device 0: LEGO Mindstorms EV3 [LEGO Mindstorms EV3]
  Subdevices: 1/1
  Subdevice #0: subdevice #0
card 1: DAC [USB Audio DAC], device 0: USB Audio [USB Audio]
  Subdevices: 1/1
  Subdevice #0: subdevice #0
root@ev3dev:~# alsamixer
┌───────────────────────────── AlsaMixer v1.0.28 ──────────────────────────────┐
│ Card: LEGO Mindstorms EV3 speaker                    F1:  Help               │
│ Chip:                                                F2:  System information │
│ View: F3:[Playback] F4: Capture  F5: All             F6:  Select sound card  │
│ Item: Playback                                       Esc: Exit               │
│                                                                              │
│                                     ┌──┐                                     │
│                                     │  │                                     │
│                                     │  │                                     │
│                       ┌───────── Sound Card ─────────┐                       │
│                       │-  (default)                  │                       │
│                       │0  LEGO Mindstorms EV3 speaker│                       │
│                       │1  USB Audio DAC              │                       │
│                       │   enter device name...       │                       │
│                       └──────────────────────────────┘                       │
│                                     │▒▒│                                     │
│                                     │▒▒│                                     │
│                                     │▒▒│                                     │
│                                     │▒▒│                                     │
│                                     └──┘                                     │
│                                      75                                      │
│                                  <Playback>                                  │
│                                                                              │
└──────────────────────────────────────────────────────────────────────────────┘

E para tocar um ficheiro mp3 (previamente trasnferido por ssh):

root@ev3dev:~# apt-get install mpg321
root@ev3dev:~# mpg321 -a hw:1,0 Thunderstruck.mp3

Rock’n Roll!!!

Durante a execução o mpg321 consome entre 22 a 25% de CPU. É um bocado alto (quando se utiliza a rede em simultâneo, por exemplo um update, ocorrem soluços) e como dizem que o SoX consome menos CPU…

root@ev3dev:~# apt-get install sox libsox-fmt-all
root@ev3dev:~# export AUDIODEV=hw:1,0
root@ev3dev:~# play Thunderstruck.mp3

Durante a execução o play consome  20 a 22% de CPU, apenas marginalmente melhor.
Mas como SoX permite vários formatos (wav, ogg…) permite o redireccionamento (pipe) de outros comandos como o espeak:

root@ev3dev:~# espeak -v pt-pt “olá” –stdout | play -t wav –

E temos o nosso EV3 a falar português 🙂

EV3 wireless com ev3dev

Depois de instalar a última versão do ev3dev (ev3dev-jessie-2014-07-12) experimentei ligar 2 dos dongles Wi-FI que uso com o Raspberry Pi:

  • ThePiHut
  • Wi-Pi

Para o kernel são o mesmo dispositivo:

root@ev3dev:~#lsusb
ID 148f:5370 Ralink Technology, Corp. RT5370 Wireless Adapter

Mas não foram carregados nenhuns drivers por isso actualizei:

root@ev3dev:~#apt-get update
root@ev3dev:~#apt-get upgrade
root@ev3dev:~#apt-get dist-upgrade
root@ev3dev:~#reboot

Agora o Debian já tem os drivers:

root@ev3dev:~#dmesg
(...)
usbcore: registered new interface driver rt2800usb
(...

mas surge uma outra mensagem sobre não carregar o firmware por isso

root@ev3dev:~#dmesg
apt-get install firmware-ralink
ieee80211 phy1: rt2x00_set_rt: Info - RT chipset 5390, rev 0502 detected
ieee80211 phy1: rt2x00_set_rf: Info - RF chipset 5370 detected
ieee80211 phy1: Selected rate control algorithm 'minstrel_ht'
ieee80211 phy1: rt2x00lib_request_firmware: Info - Loading firmware file 'rt2870.bin'
ieee80211 phy1: rt2x00lib_request_firmware: Info - Firmware detected - version: 0.29

E para a ligação wireless, à semelhança do Raspbian no Pi, editei o ficheiro ‘interfaces’:

root@ev3dev:~#nano /etc/network/interfaces
# interfaces(5) file used by ifup(8) and ifdown(8)
# Include files from /etc/network/interfaces.d:
source-directory /etc/network/interfaces.d

### acrescentar as linhas abaixo ###
auto lo
iface lo inet loopback
allow-hotplug wlan0
iface wlan0 inet dhcp
   wpa-ssid "WI-Fi SID"
   wpa-psk "Wi-Fi Password"

iface default inet dhcp

Confirma-se:

root@ev3dev:~#ifconfig
wlan0     Link encap:Ethernet  HWaddr 00:0f:55:a8:ac:0a  
          inet addr:192.168.1.69  Bcast:192.168.1.255  Mask:255.255.255.0
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:11 errors:0 dropped:0 overruns:0 frame:0
          TX packets:5 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000
          RX bytes:1447 (1.4 KiB)  TX bytes:1074 (1.0 KiB)

Só não percebo porque motivo só funciona um dos dongles (o ThePiHut) quando aparentam ser iguais. Talvez o firmware não o seja completamente.

 

EV3MP3 – Um MP3 Player em LEGO

Encontrei quase por total acaso um projecto muito interessante: ev3dev.

Trata-se de uma versão de Debian para o LEGO Mindstorms EV3. Não há qualquer alteração ao firmware do EV3 – o bootloader do EV3 arranca a imagem do ev3dev instalada num cartão micro-SD.

Alguras horas depois de começar (a maior parte delas apenas a fazer actualizações de sistema já que o EV3 é cerca de 4x mais lento que um Raspberry Pi e como a versão do chipset USB é apenas 1.1 por a ligação Wi-Fi nunca fará mais que 11 mbps) descobri que o ev3dev se dá muito bem com muito do hardware que utilizo com o Raspberry Pi, nomeadamente:

  • Hub USB
  • ThePiHut Wi-Fi USB card
  • Audio USB card

Com meia duzia de linhas temos um shell script que nos saúda num português macarrónico e toca uma música em formato MP3 após ser premido um touch sensor:

#!/bin/bash

# play deve usar USB sound card
export AUDIODEV=hw:1,0

# saudar utilizador

tput clear > /dev/tty0
figlet -f small "Carregue" > /dev/tty0
figlet -f small "para" > /dev/tty0
figlet -f small "ouvir" > /dev/tty0
figlet -f small "musica" > /dev/tty0

espeak -v pt-pt "olá  queres ouvir uma música?" --stdout | play -t wav -

BOTAO=0
while [ $BOTAO -ne "1" ]; do
  BOTAO=$(cat /sys/class/msensor/sensor0/value0)
done

tput clear > /dev/tty0
figlet -f small "No ar:" > /dev/tty0
figlet -f mini "Highway To Hell" > /dev/tty0
figlet -f small "(AC/DC)" > /dev/tty0

mpg321 -a hw:1,0 HighwayToHell.mp3 -g 20

tput clear > /dev/tty0

Para quem tmabém possa estar interessado, após os updates de sistema a versão do kernel é a 3.14.7:

root@ev3dev:~# uname -a
Linux ev3dev 3.14.7-2-ev3dev-pre1 #2 PREEMPT Tue Jul 15 22:29:55 CDT 2014 armv5tejl GNU/Linux

e o htop diz que estou a usar 25 dos 57 MB de RAM disponíveis além de 7 dos 63 MB de swap.

O processador é reconhecido como um ARM926EJ-S rev 5 (v5l):

root@ev3dev:~# cat /proc/cpuinfo
processor    : 0
model name    : ARM926EJ-S rev 5 (v5l)
Features    : swp half thumb fastmult edsp java
CPU implementer    : 0x41
CPU architecture: 5TEJ
CPU variant    : 0x0
CPU part    : 0x926
CPU revision    : 5

Hardware    : LEGO MINDSTORMS EV3 Programmable Brick
Revision    : 0000
Serial        : 0000000000000000