HummingBoard i2eX oraz CuBox-i 4x4 od SolidRun
Dzięki uprzejmości sklepu internetowego Kamami miałem okazję przyjrzeć się HummingBoard i2eX będącą najbardziej rozbudowaną wersją z rodziny HummingBoard oraz multimedialnej kostce Cubox-i 4x4 produkcji SolidRun.
HummingBoard i2eX - RPi na bogato
Hummingboard został wyposażony w dwurdzeniowy procesor Freescale i.MX6 (ARM A9) taktowany zegarem 1GHz z jednostką graficzną Vivante GC2000 wspierająca standardy OpenGL ES1.1/2.0 oraz Open CL 1.1. Do naszej dyspozycji dostajemy również 1GB pamięci RAM DDR3 o przepustowości 1066Mbps.
Za sprzęt przyjdzie nam zapłacić prawie 700 złotych, jednak w tej cenie dostajemy całkiem niezłe wyposażenie, którego trudno szukać w innych zestawach: złącze LVDS, MIPI CSI 2.0, gigabitowy port Ethernet, złącze PCI-Express Gen2 oraz mSATA II. Oprócz tego dwa porty USB 2.0, złącze microSD UHS-1, zegar RTC, wyjście audio SPDIF Coax, a także wyście stereofoniczne i mikrofonowe. Nie zapomniano o odbiorniku podczerwieni oraz GPIO udostępniający UART, I/O, SPI oraz I2c.
Cubox-i 4x4 pod TV
384 to kolejny produkt od SoldRun, tym razem wyposażony w czterdzeniowy Freescale i.MX6 (ARM A9) taktowany zegarem od 1GHz do 1.2GHz. Niespotykana jest ilość również pamięci RAM, której zdecydowano się włożyć 4GB. Podobnie jak w prezentowanym dziś HummingBoard za grafikę odpowiada Vivante GC2000. W środku kostki znajduje się również moduł WiFi, BlueTooth, a także odbiornik i nadajnik podczerwieni. System uruchamiany jest z karty microSD i jest w pełni zgodny z systemami dla HummingBoard. Znajdziemy również dwa gniazda USB 2.0, złącze eSATA II (3Gbps) oraz optyczne wyjście S/PDIF. Wymiary kostki to 55 x 55 x 42 mm.
Szeroki wybór oprogramowania
Producent oficjalnie wspiera szeroką gamę oprogramowania, udostępniając w tym celu pomysłowy obraz o rozmiarze 40MB z instalatorem o nazwie Ignition. Wystarczy, że wgramy go na kartę microSD, aby po chwili mieć dostęp sporej ilości obrazów z gotowymi systemami operacyjnymi, które docelowo możemy zainstalować poprzez Internet.
A jest w czym wybierać - dostępne są między innymi: Android 4.4.4, Arch Linux, Debian Jessie, Debian Whezzy, Fedora, GeexBox, OpenELEC, OpenSUSE 13.2, RedSieeve, Slackware, Snappy, Volumio oraz XBian.
Kultura pracy
Procesor chłodzony jest pasywnie za pomocą sporego radiatora. Podczas normalnego obciążenia potrafił się on rozgrzać do temperatury ponad 50°C, a przy większych obciążeniach rozgrzać się jeszcze bardziej. Jednak podczas kilkugodzinnych testów, nie wpłynęło to na stabilność pracy urządzenia.
Dobrym pomysłem okazał się montaż 25mm wentylatorka o przepływie powietrza zaledwie 5.44m3/h. Ponieważ napięcie zasilania wentylatora to 5V, a pobór prądu wynosi około 100mA, bez problemu mogłem podłączyć go do dodatkowego złącza portu USB. Nawet tak niska moc wentylatorka, pozwoliła zbić gorączkę pod obciążeniem do temperatury 35°C.
Pomiar temperatury bez wentylatora
Pomiar temperatury z wentylatorem 5.44m3/h
Pobór energii wygląda następująco:
HummingBoard i2eX | Cubox-i 4x4 | |
Idle | 3.3 W | 3.0 W |
1-core | 3.6 W | 4.3 W |
2-core | 4.8 W | 4.6 W |
3-core | - | 5.9 W |
4-core | - | 6.2 W |
glmar2-es2 | 5. 7 W | 5.9 W |
Dytsrybucje Linuksa
Wszystkie oficjalnie wspierane dystrybucje Linuksa sprawowały się dobrze, obsługując dostępne komponenty. W większości przypadków za poprawną pracę odpowiada jądro z serii 3.14.x. Dużym dla mnie zaskoczeniem jest poprawnie działająca akceleracja sprzętowa, zarówno dla środowisk graficznych jak i dekodowania materiałów wideo. W testowanych dystrybucjach OpenSuse oraz Debian Jessie wszystko działało bez najmniejszych problemów, a repozytoria pakietów nie stawiały żadnych przeszkód.
Dla osób niewymagających środowiska graficznego, którzy chcieliby wykorzystać HummingBoarda do innych celów, dostępne są również minimalistyczne obrazy systemów Debian Jessie/Whezzy oraz Ubuntu Trusty. Posiadają one usprawnione jądra 3.14 oraz 4.1 z obsługą dodatkowych elementów takich jak wyświetlaczy ze sterownikiem ILI9341. Społeczność zgromadzona wokół HummingBoard również nie wydaje się próżnować - na forum znajdziemy dobrze udokumentowane rozwiązania, czy "wypasioną" dystrybucję Ubuntu (Lubuntu, X-ubuntu, Lxde, KDE).
OpenELEC 6 z Kodi Isengard
OpenELEC 6 @ HummingBoard i2eX
Testy porównawcze
Zobacz również porównanie z pozostałymi platformami na https://www.jarzebski.pl/soc-benchmark.html
Obserwacje dodatkowe
- Pomimo wyposażenia w 1Gbps złącza Ethernet, maksymalna przepustowość to 470Mbps, wynika to z ograniczeń jednostki SoC
- HummingBoard obsługuje karty microSD UHS I, co powinno zwiększyć prędkość operacji na kartach microSD w tym standardzie. Obsługa UHS-I została celowo wyłączona ze względu problemów jądra z przełączaniem napięcia regulatora z 3.3V na 1.8V. Możliwe jest zastosowanie odpowiednich łatek na jądra mainline >=3.15, jednak tracimy wtedy akcelerację grafiki.
- System bez problemu możemy uruchomić z nośnika mSATA. Podczas testów z dyskiem SSD A-Data XPG SX300 64GB prędkość zapisu sięgała 130MB/s, a odczytu 137MB/s. Po przeniesieniu rootfs korzystanie z HummingBoard i2eX nabiera zupełnie nowego wymiaru.
Wnioski
Zarówno HummingBoard i2eX jak i Cubox-i 4x4 są niewątpliwie bardzo ciekawymi produktami. Pierwsza z nich wyróżnia się złączami mPCIE oraz mSATA, co czyni ją wyjątkową propozycją do zadań specjalnych. Cubox-i posiada z kolei 4GB pamięci RAM, gniazdo eSATA oraz zgrabne wymiary, które idealnie wpasują się w styl naszego salonu. Dobre wsparcie producenta, a także szeroka gama systemów operacyjnych sprawia, że ta już bądź co bądz leciwa konstrukcja, wciąż okazuje się interesująca.
Reklama
Natrafiłem dziś na bardzo interesującą płytkę o nazwie NanoPi z układem ARM Samsung S3C2451 taktowany zegarem 400MHz oraz wyposażoną w 64MB pamięci RAM DDR2 133Mhz. Wymiary tego maleństwa to zaledwie 75mm x 30mm.
W cenie 16$ dostajemy również:
- zintegrowany moduł WiFi oraz Bluetooth (układ AP6210)
- port USB Host 1.1 (Typ A)
- port microUSB, który może posłużyć do zasilania jak i do transmisji danych (również jako Ethernet)
- port Serial Debug
- slot kart pamięci microSD
- złącze interfejsu LCD o rastrze 0.5mm z obsługą RGB 8-8-8
- złącze kamer DVP o rastrze 0.5mm z obsługą ITU-R BT 601/656 8-bit, I2C, I/O
- 40-pinowe złącze GPIO o rastrze 2.54mm zgodne z Raspberry Pi (UART, SPI, I2c, I/O)
- dodatkowe 12-pinowe złącze GPIO (I2S, I2c, UART)
Płytka obsługuje u-Boot, a także posiada wsparcie dla dystrybucji Debian oraz Linux-4.1+Qt.
Zastanawia mnie jedynie w jaki sposób rozwiązano obsługę kamer, ponieważ zastosowany tutaj układ Samsunga, który akurat nie wspiera kompresji wideo. Tak czy inaczej pozycja ta wydaje się bardzo ciekawa i może znaleźć sporą ilość zastosowań.
Więcej informacji znajdziecie na stronie producenta: http://nanopi.org
Wgrywamy firmware do NodeMCU v2 - krok po kroku
W poprzednim tygodniu opisywałem świetną płytkę NodeMCU v2 opartą na układzie ESP8266. Oprócz podstawowych zagadnień, pokazywałem również jak wgrać nowy firmware w postaci binarnej jaki przygotowali twórcy. Najnowsza dostępna wersja w dniu tego wpisu to NodeMCU 0.9.6 datowana na 2015/02/16. Możemy jednak wgrać nowszy build, a nawet skorzystać z rozwojowego drzewa dev120.
Wszystko czego będziemy potrzebowali to Linuksa, trochę czasu i odrobinę miejsca na dysku twardym (około 4GB)
ESP Open SDK
W pierwszej kolejności sklonujmy repozytorium ESP Open SDK i przygotujmy zestaw odpowiednich narzędzi:
- cd ~
- mkdir nodemcu
- cd nodemcu/
- git clone https://github.com/pfalcon/esp-open-sdk.git
- cd esp-open-sdk/
- make STANDALONE=y
W zależności od posiadanego sprzętu i prędkości sieci, proces ten może zając od kilku do kilkunastu minut. Po tym czasie powinien wyświetlić się komunikat o pomyślnym wykonaniu zadania z prośbą o modyfikację zmiennej środowiskowej PATH. W moim przypadku będzie to:
- export PATH=/home/korneliusz/nodemcu/esp-open-sdk/xtensa-lx106-elf/bin:$PATH
Sprawdźmy jeszcze, czy wszystko jest poprawnie, wydając poniższe polecenie:
- xtensa-lx106-elf-gcc -v
Using built-in specs.
COLLECT_GCC=xtensa-lx106-elf-gcc
COLLECT_LTO_WRAPPER=/home/korneliusz/nodemcu/esp-open-sdk/xtensa-lx106-elf/libexec/gcc/xtensa-lx106-elf/4.8.2/lto-wrapper
Target: xtensa-lx106-elf
Configured with: /home/korneliusz/nodemcu/esp-open-sdk/crosstool-NG/.build/src/gcc-4.8.2/configure --build=x86_64-build_unknown-linux-gnu --host=x86_64-build_unknown-linux-gnu --target=xtensa-lx106-elf --prefix=/home/korneliusz/nodemcu/esp-open-sdk/xtensa-lx106-elf --with-local-prefix=/home/korneliusz/nodemcu/esp-open-sdk/xtensa-lx106-elf/xtensa-lx106-elf/sysroot --disable-libmudflap --with-sysroot=/home/korneliusz/nodemcu/esp-open-sdk/xtensa-lx106-elf/xtensa-lx106-elf/sysroot --with-newlib --enable-threads=no --disable-shared --with-pkgversion='crosstool-NG 1.20.0' --disable-__cxa_atexit --with-gmp=/home/korneliusz/nodemcu/esp-open-sdk/crosstool-NG/.build/xtensa-lx106-elf/buildtools --with-mpfr=/home/korneliusz/nodemcu/esp-open-sdk/crosstool-NG/.build/xtensa-lx106-elf/buildtools --with-mpc=/home/korneliusz/nodemcu/esp-open-sdk/crosstool-NG/.build/xtensa-lx106-elf/buildtools --with-isl=/home/korneliusz/nodemcu/esp-open-sdk/crosstool-NG/.build/xtensa-lx106-elf/buildtools --with-cloog=/home/korneliusz/nodemcu/esp-open-sdk/crosstool-NG/.build/xtensa-lx106-elf/buildtools --with-libelf=/home/korneliusz/nodemcu/esp-open-sdk/crosstool-NG/.build/xtensa-lx106-elf/buildtools --enable-lto --enable-target-optspace --disable-libgomp --disable-libmudflap --disable-nls --disable-multilib --enable-languages=c,c++
Thread model: single
gcc version 4.8.2 (crosstool-NG 1.20.0):
Możemy przystąpić do budowania firmware
Ponownie klonujemy repozytorium - tym razem zawierające firmware:
- cd ~/nodemcu/
- git clone https://github.com/nodemcu/nodemcu-firmware.git
- cd nodemcu-firmware.git/
Na tym etapie musimy zdecydować, czy interesuje nas gałąź master (obecnie z wersją 0.9.6), czy może chcemy spróbować deweloperskiej wersji 1.2.0. Jeśli tak, wybieramy gałąź dev120. Jeśli nie, pomijamy poniższe polecenie:
- git checkout dev120
Na koniec nie pozostaje nam już nic innego, jak wydanie polecenia kompilacji:
- make
Kiedy kompilacja dobiegnie końca, możemy przygotować nasz firmware i wgrać go NodeMCU v2 (oczywiście podłączająć go do USB):
- tools/esptool.py elf2image app/.output/eagle/debug/image/eagle.app.v6.out
- tools/esptool.py write_flash -fm dio -fs 32m -ff 40m 0x00000 app/.output/eagle/debug/image/eagle.app.v6.out-0x00000.bin 0x10000 app/.output/eagle/debug/image/eagle.app.v6.out-0x10000.bin
I praktycznie tyle. Sprawdźmy jeszcze za pomocą minicoma, czy rezultat jest zgodny z oczekiwaniami:
- minicom -D /dev/ttyUSB0 -b 9600
Po restarcie powinniśmy ujrzeć świeży firmware:
Custom firmware
Przed kompilacją i wgraniem, możemy zmodyfikować konfigurację naszego firmwareu edytując plik app/include/user_modules.h.
Właśnie tutaj zdecydujemy o dostępności poszczególnych modułów, oszczędzając tym samym cenne kilobajty.
Hardkernel ostatnio nie zasypia gruszek w popiele i uchylił rąbka tajemnicy o poprawionej wersji płytki ODROID-C1+, którą obecną wersję miałem już okazję testować jakiś czas temu. W moim osobistym przekonaniu, ta kosztująca zaledwie 35$ płytka wykorzystująca czterordzeniowy układ SoC Amlogic S805 stała się realnym konkurentem dla Raspberry Pi 2.
Argumentem koronnym obozu przeciwnego wyższości "maliny" nad konkurentem były problemy obsługi CEC przez ODROIDa. Tym razem, będzie trzeba będzie znaleźć inne przeszkody, ponieważ poprawiona rewizja C+ już tego problemu nie posiada.
W dalszym ciągu wykorzystuje ona ten sam układ SoC i poasiada identyczną ilość pamięci RAM (1GB). Jednak poprawna obsługa CEC to nie wszystkie usprawnienia. Wymieniono złącze HDMI, zastępując micro HDMI standardowym gniazdem Typu A. Poprawiono równiez kompatybilność z kartami SD oraz umożliwiono zasilanie płytki z gniazda USB OTG.
Czy tym razem ODROID-C1+ zaskarbi sobie serca "malinowców"? Nie wiadomo. Za społecznością Raspberry Pi stoi wielka społeczność i ogromne zasoby finansowe, które Hardkernel stara się nadgonić z co raz lepszym rezultatem. Trzymam kciuki!.
Wyświetlacze TFT Riverdi ze sterowniiem FT800 i FT801
Jeśli interesujecie się wyświetlaczami TFT wykorzystującymi kontrolery FTDI Chip FT800/FT801, to bez wątpienia powinniście zwrócić uwagę na propozycję firmy Riverdi. Dzięki ogromnej uprzejmości firmy UNISYSTEM z Gdańska, otrzymałem do testów kilka wyświetlaczy wykorzystujące kontrolery FT800 jak i FT801. Oba układy należą do grupy kontrolerów określanych mianem EVE (Embedded Video Engine), czyli z wbudowanym silnikiem wideo, znacząco przyśpieszającym działanie standardowych wyświetlaczy TFT z mniej wydajnymi MCU.