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

Otrzymałem do testów od ITEAD Studio rozwojową próbkę nowego mini komputera IBOX opartego o dwurdzeniowy układ SOC Allwinner A20 wyposażony układem graficznym Mali 400MP.  IBOX ma do dyspozycji 1GB pamięci DDR3 oraz wbudowaną pamięć NAND o pojemności 4GB. Na łamach Bloga opisywałem już Iteaduino Plus A10, będący nieco słabszą wersją IBOX-a. Pomimo tego, że  dostępna jest również wersja Iteaduino Plus A20, który wykorzystuje ten sam procesor, to IBOX przeznaczony jest dla nieco innego odbiorcy. Zanim zaczniesz czytać ten wpis, musisz przyjąć do wiadomości, że nie jest to produkt końcowy, a jedynie rozwojowy sample.

IBOX jest bardzo podobny do swoich poprzedników, z tą różnicą, że został on umieszczony w aluminiowej obudowie, którą bez obaw możemy postawić obok telewizora. Na frontowym panelu znalazł się slot pamięci kart mikroSD, odbiornik podczerwieni oraz dioda sygnalizująca działanie. Pomimo tego, że konstrukcja wydaje się być solidna, to brakuje w zestawie pilota, czy tak oczywistego elementu jak włącznik zasilania.

Z tyłu obudowy znajdziemy cztery gniazda USB 2.0 (jeden pracujący w trybie OTG), gniazdo HDMI, S/PDIF oraz port Ethernet. Z lewej strony został umieszczony przycisk uruchamiający Uboot, który okaże się przydatny podczas wgrywania nowszych wersji systemu do wbudowanej pamięci NAND.

Z boku został umieszczony 32-pinowy port rozszerzeń, do którego docelowo będziemy mogli podłączyć różne dodatki, takie jak adapter dysków SATA i inne. Umożliwia on również bezpośredni dostęp do szyn USB, 4x UART, 1x SPI, 1x I2C, LCD, wyjścia TV-OUT, LINE IN oraz linii zasilania 5V i 3.3V.

Po odkręceniu czterech śrubek od spodu obudowy z łatwoscią dostaniemy się do jego wnętrza, gdzie znajduje się standardowy moduł A20 umieszczony na płytce PCB. Oznacza to, że taki moduł można swobodnie wyjąć i wykorzystać w Iteaduino. Aby jednak wyjąć płytkę PCB z obudowy wymagana jest spora ostrożność, ponieważ została ona umieszczona na tyle ciasno, że można ją uszkodzić podczas wkładania lub wyjmowania. Jest to jednak wersja rozwojowa i stan rzeczy ma się poprawić w finalnym produkcie.

Pierwsze uruchomienie

Po podłączeniu zasilania zostaje uruchomiony preinstalowany w pamięci NAND system Android w wersji 4.2.2. Na chwilę obecną dostępne są dwie jego wersje: przystosowany do działania pod telewizorem Android TV A20 (przygotowany przez ITEAD) oraz standardowy Android 4.2 od CubieTech. Oznacza to, że z powodzeniem powinno udać nam się uruchomić systemy operacyjne przeznaczone dla Cubieboard2.

Niestety jest i smutna wiadomość - bardzo duża część aplikacji z Google Play nie jest kompatybilna z IBOX-em, przez co nie udało mi się zainstalować takich programów jak Antutu czy 3D Mark w celu sprawdzenia wydajności urządzenia. Preinstalowana wersja Androida TV również nie zachwyca pod kątem stabilności, ale poczekajmy z werdyktem do finalnej wersji. Ciekawym za to elementem tego systemu jest obsługa dysków SATA oraz możliwość wyboru rozdzielczości, do której skalowany jest interfejs wykorzystujący grafikę w rozdzielczości 720p.

 

Dystrybucje Lubuntu, Debian, Cubian, Arch ARM

Na start możliwe jest zainstalowanie jednej z czterech dostępnych dystrybucji Linuksa, z której jedna (Lubuntu) przeznaczona jest wyłącznie dla pamięci NAND, a pozostałe możemy zainstalować na karcie mikroSD. Najbardziej zainteresowała mnie dystrybuacja Debian przygotowana przez  ITEAD (nazwa obrazu sugeruje, że jest to taka sama wersja jak dla Iteaduino Plus A20). Obraz systemu należy pobrać i wypalić na karcie mikroSD:

  1. # wget http://iteadstudio.dbankcloud.com/IteaduinoPlus-A20-debian-xfce-0.1-2014-02-26.img.bz2
  2. # tar xvf IteaduinoPlus-A20-debian-xfce-0.1-2014-02-26.img.bz2
  3. # dd if=IteaduinoPlus-A20-debian-xfce-0.1-2014-02-26.img of=/dev/sdX
  4. # sync

Teraz wystarczy włożyć ją do slotu i ponownie uruchomić IBOX-a. Po uruchomieniu logujemy sie na konto "root" za pomocą hasła "root". Podobnie jak Iteaduino Plus system nie posiada akceleracji sprzętowej OpenGL ES 2, a repozytoria Debiana nie posiadają tak podstawowych programów jak przeglądarki Firefox czy Chrome.

Na obecnym etapie rozwoju IBOX-a można stwierdzić, że nie jest on przeznaczony dla końcowego odbiorcy, który chciałby podłączyć pudełeczko pod TV i cieszyć się Androidem i Linuksem. Drobnym rozczarowaniem może okazać się tutaj brak SATA w zestawie i konieczność dołączenia specjalnego modułu. 

IBOX jest produktem niewątpliwie ciekawym i sensownie przemyślanym - jednak z oceną końcową trzeba się jeszcze wstrzymać.

Więcej informacji na temat IBOX-a znajdziecie na Indiegogo. Pełną listę obsługiwanych systemów operacyjnych znajdziecie natomiast tutaj.

Reklama

MarsBoard RK3066 oprócz współpracy z systemem operacyjnym Android, może działać również pod kontrolą Linuksa. Producent tego urządzenia przygotował swoją odmianę dystrybucji PicUntu oznaczonej numerem 0.9 RC2.2 (bazującej Ubuntu Qantal 12.10). Na stronie domowej MarsBoard możemy wybrać jedną z trzech jego odmian:

  • uruchamianą z pamięci NAND Flash z obsługą ekranu dotykowego HY070CTP-A
  • urcuhamianą z pamięci NAND Flash z obsługą HDMI
  • oraz uruchamianą z karty microSD z obsługą HDMI

Instalacja w pamięci NAND Flash z obsługą HDMI

Do wgrania PicUntu w wersji HDMI do pamięci NAND Flash będziemy potrzebować specjalnego narzędzia o nazwie upgrade_tool (do pobrania z tego miejsca)

  1. # mkdir marsboard
  2. # cd marsboard/
  3. # wget http://www.haoyuelectronics.com/service/RK3066/tools/linux/Linux_Upgrade_Tool_v1.16.zip
  4. # unzip Linux_Upgrade_Tool_v1.16.zip
  5. # chmod +x upgrade_tool

Rzecz jasna, będziemy również potrzebowali obrazu systemu w wersji HDMI:

  1. # wget http://bit.ly/1fRx81u -O picuntu-0.9-RC2.2-HDMI-NAND.img.7z
  2. # 7z x picuntu-0.9-RC2.2-HDMI-NAND.img.7z

Aby mieć możliwość wgrania obrazu do pamięci NAND Flash, musimy uruchomić płytkę w trybie Recovery. W tym celu podczas podłączania do portu USB OTG należy przytrzymać przycisk "SW1". Po tym zabiegu powinniśmy zobaczyć w naszym systemie urządzenie, wydając polecenie lsusb:

  1. # lsusb
  2. Bus 003 Device 012: ID 2207:300a

Kiedy wszystko jest gotowe, możemy przystąpić do "wypalenia" obrazu:

  1. # sudo ./upgrade_tool uf nazwa_naszego_obrazu.img

I gotowe! Po chwil powita nas pulpit GNOME, do którego logujemy się za pomocą hasła: marsboard.

Jak widzimy, rozmiar pamięci NAND nie pozwala nam na wiele manewrów - 2GB to odrobinę krucho jak na PicUntu. Ale o tym dalej. Na początek zajmiemy się konfiguracją połączenia sieciowego.

Konfiguracja Wi-Fi

MarsBoard RK3066 jest dostarczane razem z kartą sieciową USB Wi-Fi Mercury (RTL8188EU) w komplecie. Karta ta (co się komu trafi) może być wykryta jako interfejsy wlan0 - wlan3. Wypadałoby się więc dowiedzieć, pod jakim interfejsem jest dostępna nasza karta sieciowa wydając polecenie: sudo iwconfig. Mając już tą świadomość, możemy przystąpić do konfiguracji połączenia w programie wicd.

W polu "Wireless interface" wpisujemy nasz interfejs i zatwierdzamy przyciskiem OK. Wybierając zakładkę Refresh powinniśmy już widzieć otaczające nas punkty dostępowe sieci bezprzewodowych.

 

Instalacja na karcie pamięci uSD z obsługą HDMI

Jak wspomniałem wcześniej, 2GB pamięć NAND jest pewną przeszkodą, a bootloader dla układu RK3066  jest niestety oprogramowaniem zamkniętym, dlatego uruchomienie systemu musi odbywać się wyłącznie z pamięci NAND Flash. Można jednak odpowiednio skonfigurować start jądra systemu ze wskazaniem karty pamięci SD jako nośnika systemu plików rootfs. Będziemy potrzebowali tym razem dwóch obrazów. Jeden do "wypalenia" w pamięci NAND Flash oraz drugi, przeznaczony dla karty SD. Ponownie korzystamy z narzędzia upgrade_tool w trybie recovery.

  1. # wget http://bit.ly/1j04XCQ -O MarsBoard_RK3066_HDMI_boot_from_sdcard_rootfs_v1.1.img
  2. # wget http://bit.ly/NQ3Jho -O  MarsBoard_RK3066_PicUntu_sd_rootfs.img.tar.gz
  3. # tar -zxvf MarsBoard_RK3066_PicUntu_sd_rootfs.img.tar.gz

Wypalamy pamięć NAND Flash:

  1. # sudo ./upgrade_tool uf MarsBoard_RK3066_HDMI_boot_from_sdcard_rootfs_v1.1.img

a następnie kartę SD:

Uwaga! Należy zwrócić szczególną uwagę na urządzenie docelowe /dev/sdX, abyśmy przypadkiem nie wykasowali sobie ważnego dysku. Karta pamięci musi mieć minimum 4GB.

  1. # sudo dd if=marsboard-picuntu-linuxroot-0.9-RC2.2-lubuntu-desktop-rfs.img of=/dev/sdX

Kiedy wszystko przebiegnie sprawnie, wkładamy kartę microSD do slotu pamięci i odpalamy MarsBoarda.

Domyślnie partycja rootfs posiada rozmiar 3GB, jeśli mamy kartę pamięci o większej pojemności, w prosty sposób możemy zwiększyć jej powierzchnię wydając jedno polecenie:

  1. # sudo resize2fs /dev/mmcblk0

Jeśli mamy na to ochotę, możemy również zaktualizować nasz system:

  1. # sudo apt-get update
  2. # sudo apt-get upgrade

Nie zalecam jednak proponowanej aktualizacji systemu do wersji Ubuntu 13.10 Saucy Salamander.

Problemy z połączeniem Ethernet

W obecnej wersji PicUntu dla MarsBoard RK3066 występuje problem z działaniem portu Ethernet. Nie jest to wina ani systemu, ani jądra systemu. Obecny obraz zawiera bootloader w wersji 1.22, który ma kłopoty z jego inicjalizacją. Problem ten nie występuje podobno w bootloaderze w wersji 2.07. Jak sobie z tym poradzić? Jeszcze nie wiem :) Ale próby i rozmowy trwają.

Wgrywanie nie powiodło się?

Może zdarzyć się sytuacja, że wgrywanie nowego systemu do pamięci NAND Flash zakończy się niepowodzeniem, wyświetlając komunikat "Download Firmware Fail".

Najczęściej może się to przytrafić, gdy zapisujemy system po raz kolejny. Nie należy panikować - wystarczy uprzednio sformatować NAND-a wydając polecenie:

  1. # sudo ./upgrade_tool lf

Co dalej?

Jak to zwykle bywa z działaniem Linuksów z układem graficznym Mali 400 nie ma zaskoczenia. Akceleracja sprzętowa 3D OpenGL ES i dekodowanie materiałów filmowych nie jest jego mocną stroną. Co wcale nie czyni go produktem słabym, czy przeciętnym. Dwa rdzenie Cortex A9 1.6 GHz doskonale sprawdzą się w rozwiązaniach mini-serwera domowego do szerokiej gamy zastosowań (o czym będziecie mogli poczytać w kolejnych częściach). Dotykowy wyświetlacz pojemnościowy LCD za rozsądną cenę to także spory atut otwierający przed Marsem wiele drzwi do zastosowań bardziej wygustowanych. A wszystko to kosztem maksymalnie 5W. Podczas powyższych testów MarsBoard RK3066 przez zdecydowaną większość czasu zadowalał się poborem energii na poziomie jedynie 2.5W.

Oczywiście nie byłbym sobą, gdybym nie przygotował własnej dystrybucji, uzupełniającej obecne niedociągnięcia. Macie jakieś pomysły na nazwę kodową? :)

Kontakt z producentem na forum oceniam jako dobry. Zaangażowanie jest również OK - wiki jest ciągle aktualizowane o nowe poradniki, takie jak: kompilacja, konfiguracja czy wykorzystanie GPIO. Pamiętajmy, że przygotowane obrazy systemów są pierwszymi wersjam, więc należy dać im kredyt zaufania w oczekiwaniu na kolejne wydania.


Sprzęt do testu dostarczył sklep
ArduinoSolutions.

Tak jak obiecałem, przedstawiam Wam pierwszą betę własnego systemu Sunflower Linux 1.0 dla Iteaduino Plus A10. W odróżnieniu od IteadOS przedstawia się następująco:

  • Podstawka Linaro 12.11 Precise Pangolin,
  • Jądro Linux 3.4.67+,
  • Sterownik FBTURBO z akceleracją srzętową G2D dla X11 / 2D,
  • Sprzętowa akceleracja OpenGL ES. 2.0,
  • Obsługa Cedar / CedarX,
  • XBMC 12.2 z obsługą OpenGL ES 2.0 + Librhybris,
  • Możliwy wybór rozdzielczości 720p / 1080p za pomocą pliku boot.scr,
  • Rezerwacja 128MB dla Mali400 oraz 128MB dla G2D,
  • HDMI Audio Output,
  • Optymalizacja systemu plików,
  • Optymalizacja biblioteki libiteadIO - maksymalna prędkość 1.1MHz

Instalacja

Instalacja przebiega identycznie jak w przypadku IteadOS. Należy pobrać, rozpakować i wypalić obraz systemu na karcie microSD:

Uwaga! Należy zwrócić szczególną uwagę na urządzenie docelowe /dev/sdX, abyśmy przypadkiem nie wykasowali sobie ważnego dysku. Karta pamięci musi mieć minimum 4GB.

  1. # wget https://dl.dropboxusercontent.com/s/gz3a9s6bgskp6wk/sunflower-1.0-beta1.img.7z
  2. # 7z e sunflower-1.0-beta1.img.7z
  3. # dd if=sunflower-1.0-beta1.img of=/dev/sdX

Tak przygotowaną kartę microSD wkładamy do slotu kart pamięci i uruchamiamy. Jeśli system wykryje większy kartę niż 4GB, system plików zostanie automatycznie rozszerzony do jej maksymalnego rozmiaru.

Akceleracja 2D w X11 za pomocą G2D / FBTURBO

Sunflower Linux posiada sterownik FBTURBO, który wykorzystuje silnik akceleracji G2D dla X11. Na jego potrzeby zostało zarezerwowane 128MB pamięci.

  1. [    13.274] (II) FBTURBO: driver for framebuffer: fbturbo
  2. [    13.330] (II) FBTURBO(0): using /dev/fb0
  3. [    13.330] (II) FBTURBO(0): Creating default Display subsection in Screen section
  4. [    13.330] (==) FBTURBO(0): Depth 24, (==) framebuffer bpp 32
  5. [    13.330] (==) FBTURBO(0): RGB weight 888
  6. [    13.330] (==) FBTURBO(0): Default visual is TrueColor
  7. [    13.330] (==) FBTURBO(0): Using gamma correction (1.0, 1.0, 1.0)
  8. [    13.330] (II) FBTURBO(0): hardware:  (video memory: 10800kB)
  9. [    13.331] (**) FBTURBO(0): Option "fbdev" "/dev/fb0"
  10. [    13.331] (**) FBTURBO(0): Option "SwapbuffersWait" "true"
  11. [    13.331] (II) FBTURBO(0): processor: Late ARM Cortex-A8 (NEON can bypass L1 cache)
  12. [    13.331] (II) FBTURBO(0): checking modes against framebuffer device...
  13. [    13.331] (II) FBTURBO(0): checking modes against monitor...
  14. [    13.331] (--) FBTURBO(0): Virtual size is 1280x720 (pitch 1280)
  15. [    13.331] (**) FBTURBO(0):  Built-in mode "current": 74.2 MHz, 37.5 kHz, 50.0 Hz
  16. [    13.332] (==) FBTURBO(0): DPI set to (96, 96)
  17. [    13.355] (II) FBTURBO(0): using backing store heuristics
  18. [    13.430] (II) FBTURBO(0): enabled G2D acceleration
  19. [    13.430] (==) FBTURBO(0): Backing store disabled
  20. [    13.431] (==) FBTURBO(0): DPMS enabled
  21. [    13.431] (II) FBTURBO(0): using sunxi disp layers for X video extension
  22. [    13.431] (II) FBTURBO(0): using hardware cursor
  23. [    13.481] (II) FBTURBO(0): enabled display controller hardware overlays for DRI2
  24. [    13.481] (II) FBTURBO(0): Wait on SwapBuffers? enabled
  25. [    13.481] (II) FBTURBO(0): [DRI2] Setup complete
  26. [    13.481] (II) FBTURBO(0): [DRI2]   DRI driver: lima
  27. [    13.482] (II) FBTURBO(0): using DRI2 integration for Mali GPU (UMP buffers)
  28. [    13.482] (II) FBTURBO(0): Mali binary drivers can only accelerate EGL/GLES
  29. [    13.482] (II) FBTURBO(0): so AIGLX/GLX is expected to fail or fallback to softwar

Akceleracja 3D - OpenGL ES 2.0

Uzyskany wynik w glmark2-es2 to 45 punktów.

  1. # glmark2-es2
  1. [build] use-vbo=false: FPS: 50 FrameTime: 20.000 ms
  2. [build] use-vbo=true: FPS: 50 FrameTime: 20.000 ms
  3. [texture] texture-filter=nearest: FPS: 50 FrameTime: 20.000 ms
  4. [texture] texture-filter=linear: FPS: 50 FrameTime: 20.000 ms
  5. [texture] texture-filter=mipmap: FPS: 50 FrameTime: 20.000 ms
  6. [shading] shading=gouraud: FPS: 50 FrameTime: 20.000 ms
  7. [shading] shading=blinn-phong-inf: FPS: 50 FrameTime: 20.000 ms
  8. [shading] shading=phong: FPS: 50 FrameTime: 20.000 ms
  9. [bump] bump-render=high-poly: FPS: 50 FrameTime: 20.000 ms
  10. [bump] bump-render=normals: FPS: 50 FrameTime: 20.000 ms
  11. [bump] bump-render=height: FPS: 50 FrameTime: 20.000 ms
  12. [effect2d] kernel=0,1,0;1,-4,1;0,1,0;: FPS: 25 FrameTime: 40.000 ms
  13. [effect2d] kernel=1,1,1,1,1;1,1,1,1,1;1,1,1,1,1;: FPS: 16 FrameTime: 62.500 ms
  14. [pulsar] light=false:quads=5:texture=false: FPS: 49 FrameTime: 20.408 ms
  15. [desktop] blur-radius=5:effect=blur:passes=1:separable=true:windows=4: FPS: 16 FrameTime: 62.500 ms
  16. [desktop] effect=shadow:windows=4: FPS: 50 FrameTime: 20.000 ms
  17. [buffer] columns=200:interleave=false:update-dispersion=0.9:update-fraction=0.5:update-method=map: Unsupported
  18. [buffer] columns=200:interleave=false:update-dispersion=0.9:update-fraction=0.5:update-method=subdata: FPS: 26 FrameTime: 38.462 ms
  19. [buffer] columns=200:interleave=true:update-dispersion=0.9:update-fraction=0.5:update-method=map: Unsupported
  20. [ideas] speed=duration: FPS: 50 FrameTime: 20.000 ms
  21. [jellyfish] <default>: FPS: 50 FrameTime: 20.000 ms
  22. [conditionals] fragment-steps=0:vertex-steps=0: FPS: 50 FrameTime: 20.000 ms
  23. [conditionals] fragment-steps=5:vertex-steps=0: FPS: 50 FrameTime: 20.000 ms
  24. [conditionals] fragment-steps=0:vertex-steps=5: FPS: 58 FrameTime: 17.241 ms
  25. [function] fragment-complexity=low:fragment-steps=5: FPS: 50 FrameTime: 20.000 ms
  26. [function] fragment-complexity=medium:fragment-steps=5: FPS: 50 FrameTime: 20.000 ms
  27. [loop] fragment-loop=false:fragment-steps=5:vertex-steps=5: FPS: 50 FrameTime: 20.000 ms
  28. [loop] fragment-steps=5:fragment-uniform=false:vertex-steps=5: FPS: 50 FrameTime: 20.000 ms
  29. [loop] fragment-steps=5:fragment-uniform=true:vertex-steps=5: FPS: 50 FrameTime: 20.000 ms

XBMC 12.2 z akceleracją sprzętową za pomocą CedarX / Libhybris

Na pokładzie znajdziecie również XBMC 12.2 działające pod OpenGL ES 2.0, które wykorzystuje biblioteki CedarX oraz Libhybris do sprzętowego dekodowania materiałów video 720p / 1080p. Jak sobie z tym radzi? Zobaczycie również na filmie, który znajdziecie na dole tego wpisu. Demonstrację przeprowadzono w dwóch rozdzielczościach: 1280x720 oraz 1920x1080.

Ponieważ XBMC 12.2 korzysta z framebuffera, można go uruchomić zarówno spod X11 jak i bez niego (można zrobić sobie fajne HTPC). Obecnie występuje problem z przechwyceniem myszki i klawiatury, gdy uruchomimy XBMC pod X11 jako zwykły użytkownik. Dopóki nie rozwiążę tego problemu, zalecam uruchomić XBMC za pomocą polecenia sudo. Kiedy nie korzystamy z X11, problem ten nie występuje.

  1. # sudo /allwinner/xbmc-pvr-binhf/bin/xbmc

Zmiana rozdzielczość. 1280x720 / 1920x1080

Zmiana rozdzielczości jest możliwa za pomocą pliku boot.scr znajdującego się na pierwszej partycji.

Wybór rozdzielczości 1280x720

  1. # sudo su
  2. # mount /dev/mmcblk0p1 /mnt/
  3. # cd /mnt
  4. # cp boot-720.scr boot.scr
  5. # reboot

Wybór rozdzielczości 1920x1080

  1. # sudo su
  2. # mount /dev/mmcblk0p1 /mnt/
  3. # cd /mnt
  4. # cp boot-1080.scr boot.scr
  5. # reboot

Inne optymalizacje

Sunflower Linux 1.0 beta 1 posiada jeszcze szereg innych optymalizacji, które mają wpływ na szybsze działanie GPIO oraz systemu plików.  Nie jest to jeszcze to co chciałem osiągnąć, ale to jeszcze nie jest moje ostatnie słowo. Bardzo zależy mi na znacznym przyśpieszeniu GPIO poprzez optymalizację biblioteki libiteadIO.

Demonstracja


Sprzęt do testu dostarczył sklep
ArduinoSolutions.

W dzisiejszym odcinku na temat Iteaduino Plus zajmiemy się interfejsem GPIO, który udostępnia 123 piny I/O. Większość pinów jest wielofunkcyjnych, oferując między innymi: I2C, SPI, UART, RGB/LVDS oraz CSI/TS. Na spodzie znajdziemy również 4 gniazda Grove oraz w pełni zgodny z Raspberry Pi interfejs.

Mapa pinów GPIO

Mapa pinów Grove oraz RaspberryPI

Jestem Arduino

System IteadOS pozwala na pisanie  programów w języku C /  C++, udostępniając dobrze znane funkcje z Arduino, takie jak: digitalRead, digitalWrite, analogWrite, delay itp. SDK umożliwia również z korzystania z szyn danych 8- i 16 bitowych.

Pełną listę funkcji można znaleźć w dokumentacji SDK 0.1b 20130823. My zaczniemy jednak klasycznie - od mrugania diodą LED, którą podłączyłem do pinu 59. Tworzymy sobie w edytorze plik o nazwie blink.c, do którego wpisujemy taki oto programik:

  1. #include <itead.h>
  2.  
  3. int main()
  4. {
  5.     pinMode(59,OUTPUT);
  6.  
  7.     while(1)
  8.     {
  9.         digitalWrite(59, HIGH);
  10.         delay(250);
  11.         digitalWrite(59, LOW);
  12.         delay(250);
  13.     }
  14. }

Kiedy mamy już nasz program, musimy go skompilować za pomocą polecenia iteadcompile:

# sudo iteadcompile blink blink.c

[/bash]

Jeśli wszystko przebiegnie prawidłowo, możemy przystąpić do uruchomienia programu wynikowego blink, a dioda powinna radośnie mrugać w odstępach 250ms.

  1. # sudo blink

Pojawia się pytanie - jak szybkie jest GPIO w Iteaduino Plus. Możemy zmierzyć czas, jaki jest potrzebny na wystawienie na wyjściu dwóch milionów przełączeń, pomiędzy stanem wysokim, a stanem niskim. Po krótkim teście można stwierdzić, że prędkość GPIO sięga jedynie do 967 kHZ, podczas gdy Raspberry Pi potrafi rozpędzić się do 4.7 MHz. Zakładam, że jest to problem optymalizacji biblioteki libiteadIO, która nie do końca została dopracowana w wersji beta systemu.

GPIO via Python

Do GPIO również mamy dostęp z poziomu Pythona, który również korzysta z biblioteki libiteadIO. Dzięki Pythonowi możliwe jest tworzenie aplikacji graficznych, które mają dostęp do interfejsu GPIO. Tutaj sprawdzimy działanie funkcji analogWrite, która posłuży nam jako PWM dla diody RGB.

  1. from ctypes import *
  2. from Tkinter import *
  3.  
  4. def pwm(ev=None):
  5.     clib.analogWrite(c_int(59), c_int(scale.get()))
  6.  
  7. clib = cdll.LoadLibrary("/usr/local/lib/libiteadIO.so")
  8.  
  9. root=Tk()
  10. scale = Scale(root, from_ = 0, to = 255, resolution = 1, orient = HORIZONTAL, command = pwm)
  11. scale.pack()
  12.  
  13. root.mainloop()

Po uruchmieniu otrzymujemy suwak, którym regulujemy wypełnienie PWM.

Tutaj pojawia się przeszkoda. PWM realizowane jest w sposób symulacji, poprzez dodanie wątka thread przez bibliotekę libiteadIO. Problem polega na tym, że biblioteka nie radzi sobie z więcej niż jednym pinem w trybie PWM, ponieważ wątki są nadpisywane :) Ale, że jest to wersja beta - wybaczam. Na szczęście, źródła biblioteki libiteadIO są ogólnie dostępne i z chęcią wcisnę z tego więcej możliwości. Póki co, aby wysterować np.: diodę RGB, musimy przygotować trzy skrypty :) każdy z własnym wątkiem symulacji PWM.

Jest to o tyle pocieszające, że nie jest to problem sprzętowy, a jedynie programowy, który można poprawić w przyszłości.


Sprzęt do testu dostarczył sklep
ArduinoSolutions.

W trzeciej części artykułów na temat platformy Iteaduino Plus postanowiłem przyjrzeć się z bliska działaniu Linuksa, a konkretnie dedykowanej dystrybucji IteadOS opartej na Linaro 12.11 Precise Pangolin. Obraz systemu możemy znaleźć na dostarczonej z zestawem płycie CD, który należy wypalić na karcie microSD. Obraz płyty możemy pobrać również z Internetu.

  1. # wget http://ubuntuone.com/2nztO9D8NXed3o4EQYoA96

Uwaga! Należy zwrócić szczególną uwagę na urządzenie docelowe /dev/sdX, abyśmy przypadkiem nie wykasowali sobie ważnego dysku. Karta pamięci musi mieć minimum 2GB.

  1. # 7z e iteadOS_beta_1.0_130909.7z
  2. # dd if=iteadOS-beta-1.0-130909.img of=/dev/sdX

Tak przygotowaną kartę microSD wkładamy do slotu kart pamięci i uruchamiamy. Pierwsze uruchomienie systemu rozszerza partycję systemową z rozmiaru 2GB do rozmiaru karty, także dopiero drugie uruchomienie wprowadza nas od do pulpitu.

IteadOS Linux

Domyślnym środowiskiem IteadOS jext LXDE. System działa zaskakująco dobrze jak na tego typu sprzęt, zdecydowanie lepiej niż w przypadku Raspberry Pi. Film demonstracyjny znajdziecie na końcu wpisu. Jądro systemu stanowi Linux 3.4.29+, więc całkiem nieźle. Niestety jest drobny szkopuł - jest to albo jądro monolityczne, albo zapomniano dostarczyć wraz z nim dodatkowych modułów jądra, przez co możecie mieć kłopoty z działaniem urządzeń Logitech z wykorzystaniem technologii Unifying lub takich, które nie zostały dołączone bezpośrednio do jądra.

SATA - duże możlwiości

Jeśli chodzi o szybkość odczytu danych z karty microSD to oczywiście szału nie ma, transfer mieści się w zakresie 11MB/s i zależy od zastosowanej klasy karty SD. Wersja Iteaduino Plus A20 posiada natomiast wbudowaną pamięć NAND o rozmiarze 4GB, która na pewno jest w stanie poprawić ten wynik.

Jednak to na co czekałem najbardziej to kontroler SATA do którego możemy podłączyć dysk twardy. Tutaj jest już pole do popisu. Średni transfer to 70MB/s, minimalny natomiast 48MB/s. Tak więc bardziej doświadczeniu użytkownicy będą mogli tak przygotować kartę pamięci, aby system uruchamiał się dysku twardego. Obecność portu SATA otwiera przed nami zupełnie nowe możliwości, ponieważ większe transfery pozwolą nam na rozwinięcie skrzydeł.

Akceleracja 3D/2D

Bardzo byłem ciekaw akceleracji sprzętowej 3D. O ile pulpit odpowiada na nasze poczynania całkiem nieźle, to wciąż za obsługę OpenGL/X11 dla Mali400 odpowiada programowa akceleracja (software rasterizer). Co ciekawe dostępne są sterowniki fbturbo, które wykorzystują silnik akceleracji G2D, ale niestety nie znalazły się one w tym systemie. Tak więc na pewno wrócę do tego tematu podczas prezentacji własnej dystrybucji dla Iteaduino Plus A10, którą obecnie przygotowuję.

Multimedia

Jak już się domyślacie, odtwarzanie filmów pod IteadOS nie będzie cudowne - przyzwoitą płynność obrazu można uzyskać na materiałach do rozdzielczości 480p. Dodatkowo IteadOS nie przesyła dźwięku do HDMI (!). Support na forum Itead twierdzi, że nie jest on wspierany - ale chyba mieli na myśli IteadOS - ponieważ mnie się udało :) Ale o tym wkrótce.

Wróćmy jednak do filmów. Na procesorach A10/20 jest możliwe uzyskanie sprzętowej akceleracji video dzięki CedarX / libvecore, który jest obsługiwany przez odtwarzacze VLC i XMBC, jednak biblioteki te również nie znalazły się w obecnej IteadOS. Tej kwestii również zamierzam przyjrzeć się bliżej.

Podsumowanie

IteadOS nie wydaje się być zatem dystrybucją do multimediów. ponieważ znajdziemy w nim dodatkowe oprogramowanie i biblioteki SDK do obsługi GPIO/I2C/SPI, które są bardzo podobne składnią do Arduino. O tym jednak w napiszę w kolejnej części, a tym czasem przedstawiam film z działania IteadOS.


Sprzęt do testu dostarczył sklep
ArduinoSolutions.