MarsBoard RK3066. Część 1: Unboxing i Android
MarsBoard RK3066 to kolejna, niskobudżetowa platforma deweloperska oparta o układ SoC Rockchip RK3066, będący kolejną kombinacją dwurdzeniowego procesora ARM Cortex-A9 taktowanego zegarem 1.6GHz z układem graficznym Mali400. Dzięki ponownej uprzejmości sklepu ArduinoSolutions mam okazję porównania jej z innymi dostępnymi urządzeniami tego typu na naszym rynku.
MarsBoard RK3066
Nowy MarsBoard w budowie przypomina Iteaduduino Plus - składa się z płytki głównej i wymiennego moduł z układem SoC Rockchip RK3066, pamięcią 1GB DDR3 oraz pamięcią NAND Flash o rozmiarze 4GB, na której możemy zainstalować system operacyjny Android lub Linux. Układ graficzny Mali400 taktowany jest zegarem 533MHz oraz obsługuje standard OpenGL ES 2.0.
Na płycie głównej znajdziemy gniazdo HDMI 1.4a, port Ethernet (LAN8720A), cztery gniazda USB 2.0 oraz jedno microUSB pełniące funkcję OTG. Ciekawym rozwiązaniem jest dostępność dodatkowego gniazda microUSB, pełniącego funkcję portu szeregowego (za tą część odpowiada układ CP2102).
W przypadku, gdy rozmiar pamięci NAND Flash jest dla nas nie wystarczający, możemy skorzytać ze slotu kart pamięci Micro-SD SDXC, z którego również możemy uruchomić system operacyjny. Na płytce znalazły się również cztery przyciski sterujące: VOL+ (Recover Key), VOL-, ESC oraz Power KEY.
Na odwrocie znajdziemy złącze interfejsu LCD do którego możemy podłączyć dedykowany, pojemnościowy ekran dotykowy HY070CTP.
7" ekran TFT HY070CTP (800x480)
Akcesoria
Wraz z MarsBoard RK3066 otrzymamy bezprzewodową kartę sieciową Wi-FI USB Mercury (RTL8188EU), kabelek microUSB oraz zasilacz 5V/4A. W pudełku znalazłem również gustowną, różową podstawkę pod ekran LCD :]
Porównanie parametrów
Raspberry Pi B | Iteaduino Plus A10 | MarsBoard RK3066 | ODROID-X2 | |
Procesor | Broadcom BCM2835 | Allwinner A10 | Rockwell RK3066 | Exynos 4412 |
Rodzina | ARM v6 | ARM Cortex A8 | ARM Cortex A9 | ARM Cortex A9 |
Zegar procesora | 700 MHz | 1,0 GHz | 1,6 GHz | 1,7 GHz |
Liczba rdzeni | 1 | 1 | 2 | 4 |
Układ graficzny | VideoCore 4 | ARM Mali-400 | ARM Mali-400 | ARM Mali-400 |
Zegar grafiki | 400 MHz | 400 MHz | 533 MHz | 533 MHz |
OpenGL ES | 2.0 | 2.0 | 2.0 | 2.0 |
Pamięć RAM | 512 MB | 1024 MB | 1024 MB | 2048 MB |
USB 2.0 | Tak (6x) | Tak (2x) | Tak (4x) | Tak (6x) |
USB 2.0 OTG | Nie | Tak (1x) | Nie | Nie |
Serial | NIe | Tak (1x) | Nie | Nie |
HDMI | Tak | Tak | Tak | Tak |
eMMC / NAND | Nie | Nie | Tak (wbudowana 4GB) |
Tak |
microSD | Nie | Tak | Tak | Nie |
SD | Tak | Nie | Nie | Tak |
SATA | Nie | Tak | Nie | Nie |
10/100 Ethernet | Tak | Tak | Tak | Tak |
Akcesoria w komplecie |
Nie | Kabel SATA Zasilacz Obudowa Kabel USB |
Zasilacz Kabel USB Podstawka LCD Karta Wi-Fi USB |
Nie |
Wymiary | 86 x 54 mm | 109 x 76 mm | 105 x 76 mm | 90 x 94 mm |
Cena | ~ 165 zł | ~ 235 zł | ~ 245 zł | ~ 445 zł |
Android 4.1.1
Domyślnie w pamięci NAND FLASH zainstalowany jest Android w wersji 4.1.1 w wersji do współpracy z pojemnościowym ekranem dotykowym LCD HY070CTP. Ekran ten obsługuje rozdzielczość 800x480 pikseli oraz 5 punktów dotykowych Jak na ustaloną cenę 175 zł to całkiem nieźle!
Wydajność w programie Antutu
MarsBoard RK3066 w teście Antutu otrzymuje wynik 11.847 punktów. Przypomnę, że Iteaduino Plus A10 uzyskał wynik 3.962 punktów, natomiast ODROID-X2 zdobywa w tym teście 19.574 punktów.
Wydajność w programie 3D Mark
Do testu w programie 3D Mark konieczna była instalacja systemu Android w wersji 4.2.2 opartego o oprogramowanie R-BOX. Niestety system ten nie posiada roota i nie mogłem wykonać tradycyjnego zrzutu ekranu. Dlatego proszę o wybaczenie za popełnione zdjęcie :) Tak, czy inaczej MarsBoard RK3066 uzyskuje dobry wynik 2534 punktów vs. ODROID-X2 2612 punktów.
Podsumowanie
Nowy MarsBoard RK3066 to bardzo ciekawa pozycja, oferująca bardzo dobry wynik stosunku wydajności do ceny.
Dwurdzeniowy, szybki procesor, wbudowana pamięć NAND Flash oraz wydajny układ graficzny Mali 400 czyni go liderem w tym przedziale cenowym. Producent zadbał również o komplet obrazów NAND oraz SD systemów operacyjnych Android 4.1, Android 4.2 oraz PicUntu 0.9 RC2.2 (Ubuntu Qantal 12.10 + Lubuntu). Na stronie domowej znajdziemy także narzędzia do flashowania pamięci NAND dla systemów operacyjnych Linux i Windows oraz dokumentację.
Nie zapomniano również o poradnikach na temat instalacji, kompilacji oraz konfiguracji na specjalnie przygotowanym wiki Jeśli chodzi o samego Androida to działa płynnie, bez problemu odtwarza materiały filmowe w rozdzielczości 1080p. Obsługa taniego, dotykowego wyświetlacza LCD czyni go smakowitym kąskiem do zastosowań w automatyce.
Sprzęt do testu dostarczył sklep ArduinoSolutions.
Reklama
Dotarła do mnie w końcu nowa wersja ODROIDA oznaczona symbolem XU (Extreme + Ultimate), będąca następcą modelu X2. Jednostka wyposażona jest w ośmiordzeniowy układ SoC Exynos 5410 z technologią big.LITTLE (Cortex A15 + Cortex A7), gdzie poszczególne rdzenie są aktywne w zależności od obciążenia systemu.
Odroid-XU wyposażony jest w 2GB LPDDR3 pamięci RAM, złącze HDMI, cztery porty USB 2.0 oraz dwa USB 3.0 (w tym jeden pracujący w trybie OTG). Na płytce znajdziemy również czytnik katy Micro-SD oraz slot pamięci eMMC w wersji 4.5.
W odróżnieniu od innych układów z serii Exynos 4xxx, znajdziemy tutaj układ graficzny PowerVR SGX 544MP. Co ciekawe, XU został wyposażony również w uniwersalny port DisplayPort, co powinno ucieszyć właścicieli monitorów z tym wejściem. Jestem tutaj zaskoczony, ponieważ w oryginalnych zdjęciach tego portu brak.
Rozmiarowo XU jest krótszy od swojego poprzednika aż o 3 cm, a także niższy dzięki nisko profilowemu chłodzeniu, które jest wyjątkowo ciche. W wersji X2 wentylator jest podłączony do portu USB, co przekłada się na większy hałas, ponieważ wentylator pracuję z maksymalną prędkością obrotową. XU z kolei inteligentnie steruje prędkością obrotową nawet do zera, gdy temperatura układu jest odpowiedni niska.
W ODROID-XU bardziej przemyślano rozmieszczenie wszystkich gniazd, wykorzystując jedynie przeciwległe sobie krawędzie płytki. Z jednej strony znajdziemy gniazdo zasilania, porty USB 3.0, slot kart pamięci microSD, gniazdo HDMI oraz wyjście Audio. Z drugiej natomiast strony gniazdo Ethernet, porty USB 2.0 oraz DisplayPort. Bardzo dobrym pomysłem okazuje się również umieszczenie gniazda pamięci eMMC na górnej warstwie płytki PCB zamiast na dolnej, jak ma to miejsce w wersji X2.
Akcesoria
Oczywiście również do wersji XU dostępne są dodatkowe akcesoria. Nie mogło zabraknąć konwertera UART, dongla Wi-Fi oraz karty pamięci eMMC. Tutaj jest również zmiana - XU obsługuje pamięci eMMC w wersji 4.5 (X2 obsługuje wersję 4.21), co powinno przełożyć się na prędkość operacji I/O.
Bardzo cieszy zastosowanie zasilacza z "normalnym" wtykiem 2.1/5.5 mm. Do dziś pamiętam gorączkowe bieganie w poszukiwaniu 5V zasilacza z wtykiem 0.8/2.5mm dla X2.
Należy tutaj pochwalić producenta za standardowy zestaw, gdzie w podstawowej cenie znajduje się również odpowiedni zasilacz 5V/4A oraz zamykana obudowa. Koniec ze zbieraniem nadmiernej ilości kurzu :)
Porównanie parametrów
System operacyjny
Na chwilę obecną dostępny jest system operacyjny Android 4.2.2 z jądrem w wersji 3.4.5. Jak wygląda sprawa z dystrybucjami Linuksa zamierzam sprawdzić dopiero na dniach, przeprowadzając bardziej szczegółowe testy wydajności.
Antutu Benchmark
W programie Antutu ODROID-XU zdobywa 30.054 punktów, wyprzedzając tym samym Samsung Galaxy S4. ODROID-X2 uzyskuje wynik o 35% słabszy, otrzymując 19.574 punktów.
3D Mark Ice Storm
Bardzo interesujące są wyniki 3D Mark Ice Strom. Wersja X2 otrzymała w tym teście ogólny wynik 2612 punktów (Graphics test 1 - 6.9 FPS, Graphics test 2 - 14.2 FPS, Physics test - 35.1 FPS). Wersja XU nie otrzymała wyników, ponieważ pierwszy test był ograniczony częstotliwością odświeżania obrazu 60Hz (Graphics test 1 - 56.9 FPS, Graphics test 2 - 44.4 FPS, Physics test - 46.5 FPS).
Dopiero test Ice Strom Extreme oszacował liczbę punktów. Wersja X2 otrzymała w tym teście ogólny wynik 1947 punktów (Graphics test 1 - 5.8 FPS, Graphics test 2 - 8.4 FPS, Physics test - 34.5 FPS). Wersja XU zdobywa natomiast 7363 punktów (Graphics test 1 - 37.3 FPS, Graphics test 2 - 23.1 FPS, Physics test - 40.8 FPS).
Podsumowanie
Całość zapowiada się bardzo interesująco. ODROID-XU oferuje bardzo wysoką wydajność w systemie Android, pozwalając na uruchomienie bardzo wymagających aplikacji oraz gier. Specyfikacja techniczna jest również bardzo mocna. Co prawda, nie wiem jak sprawa wygląda pod kątem działania systemu operacyjnego Linuks, ale wszystkie powyższe cechy i tak wypływają na wielki plus. ODROID-XU cierpi oczywiście na problemy wieku młodzieńczego, takie jak współpraca z niektórymi modelami monitorów z wejściem HDMI, gdzie obsługa realizowana jest przez wewnętrzny konwerter DVI » HDMI (zamiast typowego sterownika HDMI) - ale nie są to problemy, nie do przeskoczenia.
W moim przypadku automatyczne wykrywanie sygnału pomiędzy gniazdami DVI, a HDMI jest trochę "kulawe", ponieważ mój monitor Iiyama ProLite E2271HDS stara się wykryć sygnał HDMI przez zbyt krótki czas, przełączając się automatycznie na DVI. Moim rozwiązaniem jest odłączenie DVI lub wybór na stałe wejścia HDMI, zamiast trybu automatycznego.
Pod telewizorem Samsung wykrycie sygnału HDMI jest niemal natychmiastowe. Ogoromą zaletą jest tutaj również spora społeczność skupiająca wokół platformy, a forum tętni życiem, wraz z aktywnym uczestnictwem producenta.Ten element jest tutaj szalenie ważny i kluczowy.
Tak jak w przypadku ODROID-X2, jestem przekonany, że wykryte problemy zostaną z czasem rozwiązane, a całość pokaże jeszcze większe pazury.
Wszystko co chciałbyś wiedzieć o RFID / NFC MIFARE
Zapraszam do wyczerpującego artykułu na temat wykorzystania technologii NFC oraz RFID w projektach Arduino. Znajdziecie w nim między innymi porównanie technologii oraz sposoby dostępu do pamięci EEPROM w kartach standardu MIFARE. Dowiecie się również w jaki sposób zmienić klucze dostępowe oraz jak ustawić bardziej zaawansowane reguły dostępu do bloków pamięci.
Artykuł:
https://www.jarzebski.pl/arduino/komponenty/czytnik-rfid-nfc-nxp-pn532.html
Kalkulator Access Bits:
https://www.jarzebski.pl/arduino/narzedzia/bity-dostepu-do-pamieci-kart-mifare.html
Iteaduino Plus. Część 5: Sunflower Linux 1.0 Beta 1
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.
- # wget https://dl.dropboxusercontent.com/s/gz3a9s6bgskp6wk/sunflower-1.0-beta1.img.7z
- # 7z e sunflower-1.0-beta1.img.7z
- # 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.
- [ 13.274] (II) FBTURBO: driver for framebuffer: fbturbo
- [ 13.330] (II) FBTURBO(0): using /dev/fb0
- [ 13.330] (II) FBTURBO(0): Creating default Display subsection in Screen section
- [ 13.330] (==) FBTURBO(0): Depth 24, (==) framebuffer bpp 32
- [ 13.330] (==) FBTURBO(0): RGB weight 888
- [ 13.330] (==) FBTURBO(0): Default visual is TrueColor
- [ 13.330] (==) FBTURBO(0): Using gamma correction (1.0, 1.0, 1.0)
- [ 13.330] (II) FBTURBO(0): hardware: (video memory: 10800kB)
- [ 13.331] (**) FBTURBO(0): Option "fbdev" "/dev/fb0"
- [ 13.331] (**) FBTURBO(0): Option "SwapbuffersWait" "true"
- [ 13.331] (II) FBTURBO(0): processor: Late ARM Cortex-A8 (NEON can bypass L1 cache)
- [ 13.331] (II) FBTURBO(0): checking modes against framebuffer device...
- [ 13.331] (II) FBTURBO(0): checking modes against monitor...
- [ 13.331] (--) FBTURBO(0): Virtual size is 1280x720 (pitch 1280)
- [ 13.331] (**) FBTURBO(0): Built-in mode "current": 74.2 MHz, 37.5 kHz, 50.0 Hz
- [ 13.332] (==) FBTURBO(0): DPI set to (96, 96)
- [ 13.355] (II) FBTURBO(0): using backing store heuristics
- [ 13.430] (II) FBTURBO(0): enabled G2D acceleration
- [ 13.430] (==) FBTURBO(0): Backing store disabled
- [ 13.431] (==) FBTURBO(0): DPMS enabled
- [ 13.431] (II) FBTURBO(0): using sunxi disp layers for X video extension
- [ 13.431] (II) FBTURBO(0): using hardware cursor
- [ 13.481] (II) FBTURBO(0): enabled display controller hardware overlays for DRI2
- [ 13.481] (II) FBTURBO(0): Wait on SwapBuffers? enabled
- [ 13.481] (II) FBTURBO(0): [DRI2] Setup complete
- [ 13.481] (II) FBTURBO(0): [DRI2] DRI driver: lima
- [ 13.482] (II) FBTURBO(0): using DRI2 integration for Mali GPU (UMP buffers)
- [ 13.482] (II) FBTURBO(0): Mali binary drivers can only accelerate EGL/GLES
- [ 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.
- # glmark2-es2
- [build] use-vbo=false: FPS: 50 FrameTime: 20.000 ms
- [build] use-vbo=true: FPS: 50 FrameTime: 20.000 ms
- [texture] texture-filter=nearest: FPS: 50 FrameTime: 20.000 ms
- [texture] texture-filter=linear: FPS: 50 FrameTime: 20.000 ms
- [texture] texture-filter=mipmap: FPS: 50 FrameTime: 20.000 ms
- [shading] shading=gouraud: FPS: 50 FrameTime: 20.000 ms
- [shading] shading=blinn-phong-inf: FPS: 50 FrameTime: 20.000 ms
- [shading] shading=phong: FPS: 50 FrameTime: 20.000 ms
- [bump] bump-render=high-poly: FPS: 50 FrameTime: 20.000 ms
- [bump] bump-render=normals: FPS: 50 FrameTime: 20.000 ms
- [bump] bump-render=height: FPS: 50 FrameTime: 20.000 ms
- [effect2d] kernel=0,1,0;1,-4,1;0,1,0;: FPS: 25 FrameTime: 40.000 ms
- [effect2d] kernel=1,1,1,1,1;1,1,1,1,1;1,1,1,1,1;: FPS: 16 FrameTime: 62.500 ms
- [pulsar] light=false:quads=5:texture=false: FPS: 49 FrameTime: 20.408 ms
- [desktop] blur-radius=5:effect=blur:passes=1:separable=true:windows=4: FPS: 16 FrameTime: 62.500 ms
- [desktop] effect=shadow:windows=4: FPS: 50 FrameTime: 20.000 ms
- [buffer] columns=200:interleave=false:update-dispersion=0.9:update-fraction=0.5:update-method=map: Unsupported
- [buffer] columns=200:interleave=false:update-dispersion=0.9:update-fraction=0.5:update-method=subdata: FPS: 26 FrameTime: 38.462 ms
- [buffer] columns=200:interleave=true:update-dispersion=0.9:update-fraction=0.5:update-method=map: Unsupported
- [ideas] speed=duration: FPS: 50 FrameTime: 20.000 ms
- [jellyfish] <default>: FPS: 50 FrameTime: 20.000 ms
- [conditionals] fragment-steps=0:vertex-steps=0: FPS: 50 FrameTime: 20.000 ms
- [conditionals] fragment-steps=5:vertex-steps=0: FPS: 50 FrameTime: 20.000 ms
- [conditionals] fragment-steps=0:vertex-steps=5: FPS: 58 FrameTime: 17.241 ms
- [function] fragment-complexity=low:fragment-steps=5: FPS: 50 FrameTime: 20.000 ms
- [function] fragment-complexity=medium:fragment-steps=5: FPS: 50 FrameTime: 20.000 ms
- [loop] fragment-loop=false:fragment-steps=5:vertex-steps=5: FPS: 50 FrameTime: 20.000 ms
- [loop] fragment-steps=5:fragment-uniform=false:vertex-steps=5: FPS: 50 FrameTime: 20.000 ms
- [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.
- # 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
- # sudo su
- # mount /dev/mmcblk0p1 /mnt/
- # cd /mnt
- # cp boot-720.scr boot.scr
- # reboot
Wybór rozdzielczości 1920x1080
- # sudo su
- # mount /dev/mmcblk0p1 /mnt/
- # cd /mnt
- # cp boot-1080.scr boot.scr
- # 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.
Iteaduino Plus. Część 4: Jestem Arduino
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:
- #include <itead.h>
- int main()
- {
- pinMode(59,OUTPUT);
- while(1)
- {
- digitalWrite(59, HIGH);
- delay(250);
- digitalWrite(59, LOW);
- delay(250);
- }
- }
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.
- # 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.
- from ctypes import *
- from Tkinter import *
- def pwm(ev=None):
- clib.analogWrite(c_int(59), c_int(scale.get()))
- clib = cdll.LoadLibrary("/usr/local/lib/libiteadIO.so")
- root=Tk()
- scale = Scale(root, from_ = 0, to = 255, resolution = 1, orient = HORIZONTAL, command = pwm)
- scale.pack()
- 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.