SantyagoSantyago
YouTube RSS Google+ Facebook GitHub

Kategorie wpisów

Reklama na Blogu

Najnowsze poradniki

Ostatnie komentarze

Popularne wpisy

Facebook

Google+

Ostatnie fotografie

polskie-gorypolskie-gorypolskie-gorypolskie-gorypolskie-gorypolskie-gorypolskie-gorypolskie-gorypolskie-gorywieliczka-szyb-danilowicza

Geolokalizacja

Nie odnaleziono Twojego adresu IP w bazie danych TrackIP. Jeśli chcesz pomóc w rozwoju projektu - zarejestruj swój adres.

Na forum xdadevelopers pojawił się obraz systemu Ubuntu dla NVIDIA Shield TV z układem Tegra X1. Wyniki testów, przeprowadzone przez właściciela strony phoronix.com z modelem NVIDIA Shield TV wyposażonym w dysk 500GB są bardzo imponujące. Bez problemu osiąga lepsze wyniki niż pozostałe platformy ARM, ale dogania procesory z rodziny Core i3 (wersje oszczędne):

Obraz systemu waży około ~2.5GB i poprawnie obsługuje porty USB, gniazdo Ethernet, WiFi oraz framebuffer. Wystepują jednak problemy z bluetooth i serwerm Xorg, który uruchamia się na "chybił, trafił". Oczywiście system nie posiada jeszcze akceleracji sprzętowej dla grafiki, ponieważ NVIDIA nie opublikowała jeszcze zamkniętych sterowników.

Wciąż niestety nie wiadomo, czy NVIDIA zdecyduje się na wydanie wersji deweloperskiej, jak to było w przypadku platformy Jetson TK1.

Więcej informacji: NVIDIA's Tegra X1 Delivers Stunning Performance On Ubuntu Linux

Reklama

Na stronie domowej Hardkernel pojawił się nowy produkt CloudShell przeznaczony dla ODROID-XU4. Jest to nic innego jak obudowa NAS dla projektów DIY, przeznaczona dla 2.5" dysku twardego, dodatkowo wyposażona w wyświetlacz LCD o rozdzielczości 320x240 punktów oraz odbiornik podczerwieni.

Jak wiadomo, rodzina ODROIDów nie posiada póki co złącz SATA/mSATA, dlatego zdecydowano się  na zastosowanie mostka SATA↔USB3.0 opartego o układ Genesis GL3321G.

CloudShell


Obudowy dostępne są dwóch kolorach - szarym i niebieskim, natomiast wymiary po złożeniu to 47 x 25 x 21mm. Producent podaje, że prędkość odczytu wynosi 80MB/s, co jest dość dobrym wynikiem. Małe rozmiary i dodatkowy wyświetlacz LCD są oczywiście na "plus", ale pojawia się pytanie: "Czy warto?"

Jeśli nam się poszczęści, za komplet ODROID-XU4 oraz CloudShell przyjdzie nam zapłacić 430 złotych (nie licząc podatku i opłaty celnej). Znając polskie realia czuję, że będzie to ponad 600-700 złotych.

Skoro mówimy o zastosowaniu NAS, to wypadałoby się zaopatrzyć w dysk twardy. W tym momencie zderzymy się z kolejnym problemem. Co prawda dyski 2.5" sięgają już pojemnością 2TB, ale są znacznie droższe niż odpowiedniki 3.5". Na chwilę obecną koszt 2TB to kwota około kolejnych ~500 złotych, a 1TB dysku ~300 złotych.

Jak by nie liczyć, za kompletne rozwiązanie NAS o pojemności 2TB przyjdzie nam zapłacić co najmniej 1100 złotych. Co możemy mieć w tej kwocie?

  • QNAP TS-112P (SATA 3G) + dysk twardy 3TB za ~850 zł
  • QNAP TS-112P (SATA 3G) + dysk twardy 4TB za ~1100 zł

W rozwiązaniu dwu kieszeniowym, a więc z możlwiością stosowania RAID 1, RAID 0, JBOD:

  • QNAP TS-212P (SATA 3G) + 2x 2TB za ~1200 zł
  • QNAP TS-231 (SATA 6G) + 2x 1TB za ~1100 zł

QNAP TS-231

Zastosowanie dedykowanej obudowy NAS niesie za sobą dodatkowe i niewymierne korzyści. Nie będę przyklejał specyfikacji, ale warto zajrzeć na kartę produktową QNAP TS-231 i odpowiedzieć sobie na pytanie czy warto?

Owszem pojawia się pewna myśl, że CloudShell z ODROIDem można wykorzystać jeszcze do innych zadań niż NAS. Nie jest nigdzie powiedziane, że akurat do tego celu musi nam służyć. Może być również wykorzystany jako "komputerek" z funkcją udostępniania plików "po sieci" lub jako zgrabna obudowa jeśli chcemy mieć podpięty dysk twardy bez zbędnej plątaniny kabli, gdzie dodatkowo pojemność karty eMMC nie jest dla nas wystarczająca.

Ale jeśli myślisz wyłącznie o NAS, to chyba nie warto - no chyba, że masz "smykałkę" do DIY - wtedy nic i nikt nie powstrzyma :)

Bardzo jestem ciekaw Waszego zdania, czy pomysł jest trafny, czy może chybiony?

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.

HummingBoard i2eX 

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.

HummingBoard i2eX 

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.

Cubox-i 4x4

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.

Instalator Ignition

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.

OpenSUSE 13.2

Debian Jessie

Dekodowanie materiału wideo

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

OpenELEC 6 / Cubox-i 4x4

Testy porównawcze

Zobacz również porównanie z pozostałymi platformami na http://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.

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

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:

  1. cd ~
  2. mkdir nodemcu
  3. cd nodemcu/
  4. git clone https://github.com/pfalcon/esp-open-sdk.git
  5. cd esp-open-sdk/
  6. 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:

  1. 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:

  1. 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:

  1. cd ~/nodemcu/
  2. git clone https://github.com/nodemcu/nodemcu-firmware.git
  3. 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:

  1. git checkout dev120

Na koniec nie pozostaje nam już nic innego, jak wydanie polecenia kompilacji:

  1. make

Kiedy kompilacja dobiegnie końca, możemy przygotować nasz firmware i wgrać go NodeMCU v2 (oczywiście podłączająć go do USB):

  1. tools/esptool.py elf2image app/.output/eagle/debug/image/eagle.app.v6.out
  1. 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:

  1. 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.