SantyagoSantyago
YouTube RSS Google+ Facebook GitHub

Kategorie wpisów

Geolokalizacja adresów IP

Reklama na Blogu

Na szybko

Ostatnio na Board

Ostatnie komentarze

Software Monitor

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.

Jetson TK1 posiada dwa zegary czasu rzeczywistego - pierwszy z nich znajduje się w kompaktowym układzie PMU AS3722, natomiast drugi obecny jest w układzie SoC Tegra TK1. W podstawowej dystrybucji Linux 4 Tegra, domyślnym zegarem jest ten pierwszy. W przypadku Jetsona jest taki problem, że nie posiada on podtrzymania bateryjnego dla zegarów - w praktyce oznacza to utratę ustawionej daty i czasu po zaniku zasilania. Oczywiście, kiedy zostaniemy połączeni z siecią, czas jest synchronizowany z serwerów NTP, ale kłopot pojawia się, gdy nie jesteśmy połączeni z Internetem.

Na pomoc przyjdzie nam opisywany już wcześniej układ DS3231 oraz magistrala I2C oraz moja kompilacja jądra The Grinch  w wersji minimum 19.3.4. O samym jądrze i dodatkowych możliwościach jakie przynosi przeczytacie na forum NVIDIA Developer Zone.

Do dyspozycji dostajemy cztery magistrale I2C, dwie w logice 1.8V i dwie w logice 3.3V:

  • GEN1_I2C (1.8V) na 50-pinowym złączu J3A1 i 75-pinowym złączu J3A2 (i2c-0)
  • GEN2_I2C (3.3V) na 50-pinowym złączu J3A1 (i2c-1)
  • PWR_I2C (1.8V) na 75-pinowym złączu J3A2 (i2c-4)
  • CAM_I2C (3.3V) na 75-pinowym złączu J3A2 (i2c-2)

Ponieważ DS3231 doskonale radzi sobie również przy napięciu zasilania 3.3V, skorzystamy z GEN2_I2C (i2c-1)

Linie sygnałowe podciągnięte są już do napięć zasilania poprzez rezystory 1kΩ, więc wystarczy praktycznie podłączyć nasz układ:

Jeśli podłączyliśmy wszystko poprawnie, powinniśmy zobaczyć nasz zegar RTC na magistrali i2c-1 pod adresem 0x68.

  1. # sudo i2cdetect -y -r 1
  1.      0  1  2  3  4  5  6  7  8  9  a  b  c  d  e  f
  2. 00:          -- -- -- -- -- -- -- -- -- -- -- -- --
  3. 10: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
  4. 20: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
  5. 30: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
  6. 40: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
  7. 50: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
  8. 60: -- -- -- -- -- -- -- -- 68 -- -- -- -- -- -- --
  9. 70: -- -- -- -- -- -- -- --

Następnie możemy dołączyć DS3231 do magistrali:

  1. # echo ds3231 0x68 | sudo tee /sys/class/i2c-dev/i2c-1/device/new_device

Po tym zabiegu, powinien załadować się nam moduł rtc_ds1307. Możemy to sprawdzić za pomocą polecenia lsmod.

  1. Module                  Size  Used by
  2. rtc_ds1307             10881  0

Dodatkowo powinniśmy mieć już dostęp do naszego zegara poprzez nowo utworzone urządzenie /dev/rtc1 i uzyskać możliwość zapisania do niego aktualnego czasu:

  1. # sudo hwclock -w -f /dev/rtc1

Sprawdźmy, czy czas został zapisany i możemy go odczytać:

  1. # sudo hwclock -r -f /dev/rtc1
  2. Thu 21 Aug 2014 11:01:38 PM UTC  -0.434869 seconds

Na zakończenie, możemy dodać dwie linie do naszego skryptu rc.local w celu automatyzacji procesu przy starcie systemu:

  1. echo ds3231 0x68 | sudo tee /sys/class/i2c-dev/i2c-1/device/new_device
  2. sudo hwclock -s -f /dev/rtc1

Gdybyśmy chcieli, aby nasz DS3231 był domyślnym zegarem rtc0, musimy zablokować moduł rtc_as3722 w pliku /etc/modprobe.d/blacklist.conf dodając linię:

  1. blacklist rtc_as3722

Należy przy tym pamiętać, aby zmienić w pliku rc.local poprzedni wpis, aby odczyt odbywał się z rtc0 zamiast rtc1, ponieważ po tym zabiegu nasz układ będzie urządzeniem rtc0.

Już jakiś czas rozglądałem się za kamerą do mojego nowego projektu z wykorzystaniem platformy Jetson TK1 i potencjału jaki daje USB 3.0. Poszukiwania zakończyły się przekonaniem, że asortyment kamer pod port USB 3.0 jest obecnie bardzo ubogi. W trakcie moich poszukiwań natrafiłem na kamery firmy Point Grey, ale za najsłabszy model z obsługiwaną rozdzielczością 1288x964 liczą sobie prawie 400$, natomiast z rozdzielczością 2080x1552 cena rośnie do kwoty 600$ wzwyż.

Błąkając się po wyszukiwarce, natrafiłem na produkty indyjskiej firmy e-con Systems. Firma ta  ma w swojej ofercie kilka ciekawych i stosunkowo niedrogich kamer z możliwością podpięcia do portu USB 3.0 (ale i nie tylko). Jedną z takich kamer jest model oznaczony See3CAM_80 z sensorem CMOS OV8825 firmy OmniVision. Co prawda, nie jest to klasa sprzętu jaką reprezentuje Point Grey i kompletnie nie ma czego porównywać, ale można dostać namiastkę rozdzielczości Full HD z przyzwoitą ilośćią klatek za przyzwoitą cenę.

Decydując się na ten konkretny model z portem USB zależało mi na uzyskaniu możliwie dużej elastyczności, gdzie mógłbym ją w przyszłości wykorzystać również w innych celach. Wybierając wersję z interfejsem MIPI, ograniczyłbym się do węższego grona sprzętu, a wydatek trzeba jakoś zrekompensować. Jednak głównym kryterium jaki postawiłem poszukiwanej kamerze to zgodność ze standardem UVC, dzięki któremu nie są wymagane jakieś specjalnie sterowniki. Kamera praktycznie powinna zadowolić się standardowym modułem jądra Linuksa.

See3CAM_80 potrafi przechywić materiał zarówno HD (720p) jak i Full HD (1080p) z prędkością 30 klatek na sekundę - był to drugi warunek, jaki kamera musiała spełnić. Kamera obsługuje także automatyczną ekspozycję, ręczny lub automatyczny balans bieli, autofocus (automatyczny, ręczny lub pojedynczy). Do zadań specjalnych jest dostępna również pełna rozdzielczość 3264x2448 pikseli (ale tylko do 11 klatek na seknudę). Minimalna, deklarowana odległość do przedmiotu to 10 cm.

Format kodowania strumienia wideo stanowi jedynie nieskompresowany YUV2 - kamera nie obsługuje zatem formatu MJPEG. Trochę szkoda, ponieważ pozwoliłoby to osiągnąć spokojnie ponad 60 klatek na sekundę, kosztem pogorszenia jakośc i przerzucenia dekodowania strumienia na procesor. Kodowanie MJPEG posiada za to inny model See3CAMCU50, ale niestety w rozdzielczości Full HD i formacie YUV2 przetwarza tylko 15 klatek na seknduę i nie posiada funkcji autofocusu.

Jeśli chodzi o programowe możliwości, to kamera udostępnia funkcje takie jak: wybór ilości klatek na sukndę, odbicie lustrzane, odbicie, przycinanie i skalowanie. Jednak to co jest najważniejsze, to dostępne źródła zmodyfikowanego programu GUVCView do pełnej obsługi tej kamery.

Z przydatnych rzeczy kamera posiada jeszcze 10 pinowe gniazdo GPIO. Do naszej dyspozycji pozostają dwa piny ustawione jako wejście i dwa piny ustawione jako wyjście. Pozostałe 4 piny są kontrolowane przez rozszerzenie sterownika UVC do kontrolowania pracy kamery. czyl ręczny wyzwalacz autofocusa, przechwycenia obrazu czy opcjonalnej lampy błyskowej,

Jesteście ciekawi jak kamera sprawuje się z platformą Jetson TK1? Poniżej krótka demonstracja:

Jeśli twierdzisz, że Raspberry Pi nie ma sobie równych wśród klonów, to po prostu sie mylisz! Koreański Hardkernel zaprezentował swój nowy komputerek nazwany ODROID-W, który może być mocnym uderzeniem w społeczność "maliny". W porównaniu do pierwowzoru, posiada ponad dwukrotnie mniejszą powierzchnię wynoszącą 60x36mm, ważąc przy tym zaledwie 8 gramów.

Tak samo jak w przypadku RaspberryPi, został wyposażony w układ Broadcom BCM2835 taktowany zegarem 700MHz oraz 512MB pamięci RAM. Oferowana liczba złącz też jest przyzwoita. Dostajemy gniazdo micro HDMI, pojedynczy port USB 2.0 oraz w pełni zgodne 26 pinowe złącze rozszerzeń I/O. Bardzo ciekawym rozwiązaniem jest dostępność tego złącza z obu stron płytki. Na dokładkę, otrzymujemy również dodatkowe 20+6 pinowe złącze zawierające ekstra porty GPIO, 12-bitowy przetwornik ADC, wyprowadzenie zasilania oraz drugi port USB pracujący w trybie hosta (tu również możemy sami zdecydować, z której strony płytki będzie on dostępny).

To jeszcze nie koniec ciekawostek. ODROID-W zawiera wbudowany zegar czasu rzeczywistego RTC, a całą płytkę można zasilić z akumulatora Li-Pol. Jeśli pytacie jak to możliwe przy konieczności zasilania portu USB i HDMI, to odpowiedzią jest tu wydajny przetwornik DC/DC, podwyższający napięcie 3.7V do wymaganych 5V.

Nie jest niestety nigdzie powiedziane, czy widoczny od spodu slot modułów eMMC pozwala na stosownie tej pamięci, ale gdyby jednak okazało się, że nie - wciąż pozostaje nieśmiertelne microSD.

Natomiast jeśli okaże się, że potrzebujecie gniazdo UART lub Ethernet, podłączyć wyświetlacz LCD lub większej ilości portów USB, możecie zaopatrzyć się w specjalną płytkę dokującą:

Sugerowana cena to 30$ za płytkę bazową oraz 20$ za płytkę dokującą. Jeśli będziemy mieli ochotę na "docka" z wyświetlaczem TFT LCD 320x240, to musimy jeszcze wyciągnąć ze skarbonki kolejne 10$.

Więcej informacji znajdziecie na stronie Hardkernel.com

HAOYU Electronics wypuściła na rynek kolejną płytkę, opartą o dwurdzeniowy procesor Allwinner A20 ARM Cortex-A7 Dual-Core taktowany zegarem 1GHz - mowa tutaj o New MarsBoard A20, któremu przyjrzymy się bliżej dzięki uprzejmości sklepu ArduinoSolutions. Tak jak w innych konstrukcjach tego typu, za grafikę odpowiada układ graficzny Mali400MP2 obsługujący standard OpenGL ES 2.0.

New MarsBoard A20 został wyposażony w 1GB pamięci DRAM taktowanej zegarem 480MHz oraz 8GB pamięci Flash. Cechą szczególną  jest wbudowana karta WiFi RTL8188EU oraz port SATA. Do płytki możemy również przylutować odbiornik podczerwieni IR (nie ma go w zestawie).  Jeśli chodzi o dostępne złącza, to do dyspozycji dostajemy: 4x USB 2.0, 1x USB 2.0 OTG, 1x DEBUG, 10/100 Mbps port Ethernet z układem LAN8710A, slot kart pamięci microSD, wyjście audio oraz wejście mikrofonowe.

Płytkę możemy podłączyć za pomocą pełnowymiarowego złącza HDMI lub standardowego złącza VGA. Jeśli istnieje taka potrzeba, możemy skorzystać również z 7" dotykowego panelu TFT LCD HU070CTP-HD obsługującego rozdzielczość 1024x600. Jakość obrazu oraz działanie 10 punktowego dotyku jest tutaj o niebo lepsze, niż w przypadku opisywanego już modelu HY070CTP-A z rozdzielczością 800x480.

Ciekawym dodatkiem są gniazda TV In oraz TV Out, pozwalające na podłączenie zewnętrznego źródła obrazu CVBS oraz dedykowana aplikacja pod system Android umożliwiająca jego wyświetlenie. Niestety nie udało mi się zmusić tego elementu do działania, ponieważ program miał wyraźny problem z odbiorem sygnału, wyświetlając jedynie niebieski obraz.

New MarsBoard A20 udostępnia również dwa porty rozszerzeń, gdzie jeden z nich jest przeznaczony do obsługi kamer CIF, natomiast drugi stanowi port rozszerzeń I/O.

Ogromnym rozczarowaniem jest jednak port SATA - pomimo tego, że jest, podłączenie dysku twardego wymaga zewnętrznego źródła zasilania. Na osłodę dostajemy jednak owtorzy montażowe, których w RK3066 nie doświadczyliśmy :)

 New MarsBoard A20 / MarsBoard RK3066

Najsłabsze ogniwo - system operacyjny

Jeśli chodzi o dostępne oprogramowanie, to stanowi one obecnie najsłabszą stronę nowego Marsa. Należy jednak zwrócić szczególną uwagę na to, że jest to platforma nowa, która premierę miała w czerwcu i wiele może się  jeszcze zmienić. Zresztą podobna sytuacja była w przypadku MarsBoard RK3066 kiedy opisywałem ją po raz pierwszy. Dziś jest dostępna już pełna dystrybucja Ubuntu Trusty 14.04 LTS ze środwiskiem LXDE, ze sprzętową akceleracją graficzną układu Mali oraz obsługą ekranów LCD HY070CTP-A/HD z dotykiem. Ale wróćmy do tematu.

Na chwilę obecną dostępne są trzy dystrybucje Linuksa: Debian Wheezy 7.1 (LXDE), Ubuntu 12.10  (Lubuntu) oraz Raspbian Debian Wheezy (LXDE). Wielką zaletą w nowym MarsBoard jest Dual-Boot, dzięki któremu mamy możliwość wypalenia ich na karcie SD pozostawiając system w pamięci NAND nietkniętym. Ubuntu jako jedyne obsługuje panel dotykowy (Debian również działa z ekranem LCD, ale bez dotyku), ale repozytorium jest w całkowitej rozsypce, co dyskwalifikuje go do sensownego użytku. Debian wygląda już dużo lepiej, bowiem można doinstalować wymagane oprogramowanie. Natomiast żadna dystrybucja nie obsługuje wspomnianego wejścia/wyjścia video oraz nie wspiera akceleracji OpenGL ES.

Debian Wheezy 7.1 / Rasbian Debian Wheezy

O Androidzie 4.2.2, można powiedzieć tylko, że jest. Nie udało mi się zainstalować na nim Google Play i oferowanego przez niego oprogramowania.

Testy porównawcze

NewMars Board A20 to sprzęt zbliżony możliwościami do CubieTruck i trudno oczekiwać czegoś innego. Obie platformy oparte są o ten sam procesor. Za Marsem przemawia jednak prawie dwukrotna niższa cena i genialny dotykowy wyświetlacz, co pozwala na wykorzystanie go w mniejszych, niskobudżetowych projektach. Jeśli tylko producent dopracuje oprogramowanie, będzie to bardzo interesująca platforma w przyzwoitej cenie.

Porównanie parametrów

  CubierTruck Iteaduino Plus A10 MarsBoard RK3066 New MarsBoard A20
   
Procesor Allwinner A20 Allwinner A10 Rockchip RK3066 Allwinner A20
Rodzina ARM Cortex A7  ARM Cortex A8 ARM Cortex A9  ARM Cortex A7
Zegar procesora  1,0 GHz  1,0 GHz 1,6 GHz  1,0 GHz
Liczba rdzeni 2  1  2 2
Układ graficzny  ARM Mali-400  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 2048 MB  1024 MB    1024 MB 1024 MB
 USB 2.0  Tak (2x) Tak (2x)  Tak (4x) Tak (4x)  
USB 2.0 OTG Tak (1x) Tak (1x) Nie Tak (1x)
Serial NIe Tak (1x) Nie Tak (1x)
 HDMI Tak Tak Tak Tak
VGA Tak Nie Nie Tak
eMMC / NAND Tak
(wbudowana 8GB)
Nie
(możliwość dokupienia)
Tak
(wbudowana 4GB)
Tak
(wbudowana 8GB)
microSD Tak Tak Tak Tak
SATA Tak Tak Nie Tak
10/100 Ethernet Tak  Tak Tak Tak
10/100/1000 Ethernet Tak Nie Nie Nie
IR Tak Nie Tak / Dodatkowo Tak / Dodatkowo
TV In / Out Nie / Nie Nie / Nie Nie / Nie Tak / Tak
Akcesoria
w komplecie
Kabel SATA
Kabel zasilający USB
Obudwa
Kabel USB
Kabel SATA
Zasilacz
Obudowa
Kabel USB
Zasilacz
Kabel USB
Podstawka LCD
Karta Wi-Fi USB
Nie
Wymiary   110 x 80 mm  109 x 76 mm 105 x 76 mm   115 x 90 mm
Cena ~ 480 zł ~ 235 zł ~ 245 zł ~ 260 zł


Sprzęt do testu dostarczył sklep
ArduinoSolutions.

Pomimo tego, że Jetson TK1 posiada 16GB szybkiej pamięci eMMC 4.51, to z biegiem czasu zaczniemy rozglądać się za możliwością zwiększenia wolnej przestrzeni. Pomogą nam w tym porty USB 2.0, USB 3.0, złącze kart SD oraz interfejs SATA.

W szranki stanęły:

  • wbudowana pamięć eMMC 4.51,
  • dysk twardy 2.5" Seagate Momentus XT ST500LM000 (SATA, USB 2.0, USB 3.0),
  • pendrive ADATA S102 (USB 2.0, USB 3.0),
  • karta Kingston microSD HC Class 10, UHS-I (SD)

Nie będzie żadną rewelacją, że najszybszy okazał się dysk twardy podłączony do portu SATA, oferując prędkość odczytu na poziomie 107 MB/s oraz zapisu na poziomie 87 MB/s. Jeśli uwzględnimy synchronizację dysku po zapisie, otrzymamy wartość 75 MB/s.

Dla objaśnienia podaję regułę, w jaki sposób została ona określona:

  1. time sh -c "dd if=/dev/zero of=/media/ubuntu/c2a13d2f-65b5-4df6-b480-4639a6e7c038/test bs=4k count=200000 && sync"
  2.  
  3. 200000+0 records in
  4. 200000+0 records out
  5. 819200000 bytes (819 MB) copied, 9.3416 s, 87.7 MB/s
  6.  
  7. real    0m10.383s
  8. user    0m0.122s
  9. sys    0m4.733s

Czas zapisu bez synchronizacji wyniósł 9,34 sekundy. Z synchronizacją dysku po zapisie, czas ten zwiększył się do 10,38 sekundy, a więc rzeczywista prędkość to (819200000/1024/1024) / 10.383 = 75,2 MB/s.

Na drugim miejscu znalazł się ten sam dysk podłączony do portu USB 3.0, ale jest tutaj drobna pułapka. Domyślnie dostarczony system Linux 4 Tegra 19.2 i 19.3 mają ustawiony ten interfejs do pracy jako USB 2.0. Wynik polecenia lsusb:

  1. Bus 002 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
  2. Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
  3. Bus 003 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub

Aby uzyskać pełnowartościowe USB 3.0, musimy ponownie wgrać firmware, zmieniając w pliku jetson-tk1.conf ustawioną zmienną ODMDATA=0x6009C000 na ODMDATA=0x6209C000. Wiąże się to z wyczyszczeniem systemu, ale po takim zabiegu,  port USB 3.0 będzie już widoczny:

  1. Bus 003 Device 001: ID 1d6b:0003 Linux Foundation 3.0 root hub
  2. Bus 002 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
  3. Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub

Ile jest wart gigabiotwy port Ethernet?

Skoro mamy możliwość podłączenia szybkiego dysku twardego pod SATA, to czy gigabitowy port Ethernet RTL8111GS pozwoli nam osiągnąć odpowiednio duże transfery? Sprawdziłem to na podstawie zamontowanych,  trzech katalogów NFS z różnymi parametrami:

Z parametrami rsize=8192 kB i wsize=8192 kB udało się "wycisnąć" 85MB/s (680 Mbps)

Jetson TK1 jako HTPC?

Ostatnim razem (również na filmie) pokazywałem, że platforma dobrze sobie radzi z wszelkim materiałem w rozdzielczości 1080p - zarówno w odtwarzaczu Totem jak i XBMC. Podczas testów z różnymi materiałami wideo, nie doświadczyłem żadnych kłopotów. Dopiero jeden z czytelników zapytał mnie, jak radzi sobie Jetson TK1 z materiałami o dużym bitrate. Dodatkowo podniosłem poprzeczkę, testując to z podmontowanej lokalizacji sieciowej NFS.

Okazuje się, że zarówno Totem jak i XBMC dekoduje materiał, nie wykorzystując akceleracji sprzętowej, a jedynie mocy obliczeniowej procesora. Na dodatek dostępny w repozytorium XBMC 12.3 wykorzystuje do tego celu tylko jeden rdzeń, co pozwala mu na płynne odtworzeniu materiału z maksymalnym stałym bitrate do 20 Mbps. Dużo lepiej radzi sobie Totem, ponieważ wykorzystuje już wszystkie 4 rdzenie, radząc sobie już z materiałem do 120 Mbps przy obciążeniu rdzeni na poziome 60-80%.

Sytuacja nieco się poprawia, kiedy film odtworzymy drugi raz, a materiał wideo znajduje się pamięci buforowanej:

Sytuacja ta powinna się jednak bardzo szybko zmienić, ponieważ NVIDIA udostępniła źródła programów nvgstplayer i nvgscapture, które wykorzystują OpenMAX (Open Media Acceleration) dla gstreamera 0.10 i 1.0 z akceleracją sprzętową TK1. Dla próbki 120Mbps wygląda to następująco:

Za drugim razem, kiedy materiał znajdował się w pamięci buforowanej:

Jest więc kwestią czasu, aż ktoś przygotuje odpowiednią łatkę do XBMC.