Massimo Banzi zaprezentował kolejną wersję platformy Arduino, nazwaną potocznie Yún (z języka chińskiego: chmura), będącą kombinacją Arduino Leonardo z Linuksem. Całość oparto o mikro-kontroler Atmega32U4 oraz układ SoC Atheros AR9331 z wbudowanym kontrolerem sieci bezprzewodowej, przewodowej oraz USB. Taki sam układ stosowany jest niektórych modelach routerów firmy TP-Link - np.: WR703N.

Pośrednikiem pomiędzy Arduino a SoC został układ Carambola 2. SoC pracuje pod kontrolą dystrybucji Linino (MIPS GNU/Linux), będącą modyfikacją znanego OpenWrt.

Podobnie jak Leonardo, Yún oferuje 14 pinów cyfrowych, z których 7 może być wykorzystane w trybie PWM, a 12 pinów jako wejścia analogowe. Dodatkowo posiada czytnik kart microSD oraz micro-USB potrafiący pracować w trybie hosta.

Po włączeniu, Yún domyślnie widoczny jest jako punkt dostępowy tworząc sieć Wi-Fi o nazwie "Arduino". Logując się poprzez przeglądarkę internetową można zmienić parametry sieci oraz ustawić hasło dostępowe.  Ciekawostką jest możliwość zaprogramowania Atmegi poprzez Wi-Fi bezpośrednio z IDE (widoczny na liście jako adres IP/port - zamiast portu szeregowego).

Sugerowana cena to około 69 dolarów. Arduino Yún ma być dostępny już pod koniec czerwca tego roku.

Jakiś czas temu zaprezentowałem Wam mój pomysł na monitorowanie zasobów Linuksa za pomocą Arduino UNO. Dziś przyszedł czas, na przedstawienie bardziej praktycznej wersji 1.2.

Zasadniczym problemem było dla mnie upychanie całego Arduino wewnątrz komputera wraz z plątaniną kabelków - co nie jest do końca dobrym rozwiązaniem - nie tylko pod względem zajmowanej przestrzeni, ale z dostępem do samego Arduino, które przyda mi się do szybkiego testowania kolejnych projektów. Postanowiłem więc przenieść całą zabawkę na pojedynczą płytkę PCB z wyprowadzeniem podstawowych złączy takich jak: zasilania z zasilacza komputera, diod RGB, czujnika temperatury i wilgotności DHT11 oraz przycisków RESET i IDLE do zmiany trybu pracy

Zmiany w schemacie i prototyp

Kiedy mamy pod ręką Molexa +12/+5V grzech z niego nie skorzystać. Zamiast zasilania ze złącza USB wybrałem właśnie ten wariant, stabilizując sobie obie linie na kolejno +5V i +3.3V, gwarantując sobie pewne poziomy napięć niż w przypadku napięcia USB, które potrafi sobie pływać pomiędzy 4.8V - 4.9V. Różnica może niewielka, ale ma zasadniczy wpływ na odczyt z czujników analogowych, powodując spore różnice np.: w odczycie temperatury nawet do 2-4 °C.

Zamiast całego Arduino UNO, sercem została naturalnie ATMEGA328P-PU uprzednio zaprogramowana. Do komunikacji z komputerem skorzystałem z gotowego modułu FTDI Basic, który pozwoli mi nie tylko przesyłać dane o stanie systemu, ale również na wgranie nowego softu do mikro-kontrolera.

Oprócz dodatkowego przycisku RESET (głównie do przygotowania układu do wgrywania softu) reszta pozostała praktycznie bez zmian.

Schemat połączeń

Uruchomienie prototypu

Projekt płytki drukowanej

Kolejnym krokiem było zaprojektowanie płytki drukowanej - do tego celu doskonale nadał się opisywany przeze mnie program Eagle. Autorouter ścieżek nie spisał się koncertowo, jednak z małą pomocą i korektami udało się to jakoś w miarę sensownie poukładać.

Montaż elementów

Uruchomienie

Po końcowych testach, można już bez wstydu zamontować całość w obudowie. Ostatnim krokiem jaki mnie czeka, jest przygotowanie sobie panelu do zatoki 5,25" z miejscem na wyświetlacz TFT oraz przyciski Reset oraz Idle.

Strona projektu: Monitino UNO.

Jono Bacon zaprezentował  film przedstawiający wczesną wersję rozwojowego środowiska Unity-Next (Unity 8.x) działającego pod kontrolą kontrowersyjnego serwera wyświetlania Mir. Platformę sprzętową stanowi MacBook Pro z ekranem Retina, wyposażony w układ graficzny Intel HD.

Biorąc pod uwagę rozdzielczość 2880x1800 pikseli, trzeba przyznać, że całość działa zaskakująco szybko. Jono dodatkowo zwrócił uwagę na fakt, że całość nie została jeszcze poddana procesowi optymalizacji, która będzie miała jeszcze większy wpływ na jakość i wydajność rozwiązania jakie zaserwuje nam w przyszłości Canoncial.

Jeśli wszystko pójdzie zgodnie z planem, Mir wraz z Unity-Next zawita w Ubuntu 14.04 LTS.

Konfiguracja testowa

Do testów posłuży nam konwencjolany dysk twardy Western Digital Caviar Black oraz Samsung SSD 830. Platformę testową stanowi Intel i5-2500 wraz z 16GB pamięci RAM.

Przygotowanie dysku SSD

Jedna z cech tego mechanizmu cache z wykorzystaniem dysku SSD jest rozdzielenie jego powierzchni pomiędzy obszarem przechowywania metadanych, a obszarem cache, który będzie gromadził nasze najczęściej wykorzystywane dane. Naturalnie rozmiar cache powinien być jak największy i nie ma większego kłopotu z wyborem jego rozmiaru. Kłopotliwy może być jednak obszar metadanych, którego rozmiar powinniśmy wyliczyć z poniższego wzoru:

4 MiB + (16 B * liczba_bloków)

Rozmiar partycji przyjmiemy 55 GiB, a jako rozmiar bloków 256 KiB - czyli 512 sektorów po 512 B. A więc:

Liczba bloków = 55 GiB / 256 KiB = 225280 bloków
Metadane = 4 MiB + (16 B * 225280) = 7798784 B = 7616 KiB

Przeliczmy jeszcze nasze wartości na 512 B sektory:

Partycja Cache = 55 GiB / 512 = 115343360 sektorów
Partycja Metadanych = 7616 KiB / 512 = 15232 sektory

Za pomocą programu fdisk przygotujemy teraz dysk SSD na podstawie powyższych wartości:

Konfiguracja devmappera

Kiedy mamy już przygotowany dysk SSD, musimy skonfigurować nasz cache. Dla testów ograniczyłem się jednynie do partycji /dev/sda1, do której to będziemy potrzebowli rozmiar w sektorach:

Jako rozmiar bloków przyjęliśmy na początku 256 KiB, a więc 512 sektorów.

Pozostaje nam już tylko zamontować naszą "hybrydę" poniższym poleceniem:

Testy: Kopiowanie pliku (2,5 GiB)

4802704+0 przeczytanych recordów
4802704+0 zapisanych recordów
skopiowane 2458984448 bajtów (2,5 GB), 25,2681 s, 97,3 MB/s

4802704+0 przeczytanych recordów
4802704+0 zapisanych recordów
skopiowane 2458984448 bajtów (2,5 GB), 20,3597 s, 121 MB/s

Testy: Kopiowanie źródeł jądra 3.9.0 (1,2 GiB)

real    0m48.583s
user    0m0.243s
sys     0m2.513s

real    0m38.133s
user    0m0.253s
sys     0m2.344s

Testy: Kompilacja jądra 3.9.0

real    6m3.854s
user    19m51.270s
sys     1m29.049s

real    6m8.074s
user    19m56.077s
sys     1m29.865s

Podsumowanie

Zauważalnych różnic praktycznie nie ma. Jest odrobinę szybciej, jednak należy zastanowić się, czy nie lepszym rozwiązaniem jest postawienie systemu na dysku SSD zamiast stosować cache. Dotyczy się to również testów uruchomieniowych, gdzie programy uruchamiały się praktycznie w tym samym czasie. Przyjrzyjmy się jeszcze na koniec statystykom:

ssdcache: 0 125788887 cache 676/4544 4595 448904 8957 209538 0 607 627 579 0 2 migration_threshold 204800 4 random_threshold 4 sequential_threshold 512

Podczas krótkiej pracy z tym rozwiązaniem można zauważyć, że procent trafień podczas odczytu to zaledwie 1% (4595 trafień i 448904 chybień). Zapis wyszedł trochę lepiej bo, aż porywające 4% (8957 trafień i 209538 chybień).

Czy warto? Moim zdaniem nie - jednak na to pytanie musicie sobie odpowiedzieć sami.