Марсіанські справи -- 1

Увага, це старий текст, написаний на початку 2015-го! З того часу не мав можливості до нього повертатися, але викидати шкода, тому трішки відредагував і викладаю. 

Не маючи можливості охопити неосяжне, пишу (upd кінця 2016: на жаль, ймовірно -- писав) лише про нові місії, зокрема із марсіанських -- MSL Curiosity, MAVEN та MOM. Однак, над тим же Марсом працює багато інших (на загал -- потужніших, якщо говорити про орбітальні) станцій та, що важливіше, наукових колективів. Раніше всілякі цікавинки про них я поміщав під заголовком "Додаток до огляду Curiosity", але на додаток воно мало схоже :-) То завів окрему серію, "Марсіанські справи".

Користуючись наземними телескопами, група дослідників розрахувала ймовірну кількість води на Марсі в епоху Ноя, яка закінчилася 3.7 млрд років тому, коли Марс ще був вологим.  За їх оцінками, об'єм води складав мінімум 20 мільйонів кубічних кілометрів --- достатній, щоб  вкрити всю його поверхню шаром товщиною 140 м. Ймовірно, вона, в основному, містилася в океані, що займав помітну частину теперішньої північної півкулі (орієнтація Марсу в просторі помітно змінюється з часом!), де зараз низини. Його площа могла складати 19% поверхні планети, а глибина досягати 1.6 км.

Так міг виглядати Марс 4 млрд років тому.
(c) ESO/M. Kornmesser/N. Risinger

Огляд (CPU) performance counters API

Схема процесора M68000. Взято тут.

Сучасні процесори надають доступ до різноманітної інформації, пов'язаної із їх роботою -- кількість кеш-промахів та кеш-попадань, кількість виконаних переходів та кількість не вгаданих branch-предиктором переходів, кількість виконаних команд різних видів і т.д. і т.п.

Звичайно, до цієї інформації можна доступатися безпосередньо -- якщо ОС надає відповідні права працювати із моделе-специфічними регістрами процесора (MSR) або є можливість завантажити відповідний драйвер. Однак, це складно -- набір регістрів прив'язаний не тільки до архітектури процесора (x86 чи ARM), але й виробника (Intel vs AMD) і конкретної моделі процесора. Код виходить дуже непортабельним, або дуже громіздким. Зате все під контролем. Детальніше про такий підхід -- див., наприклад, сайт славнозвісного Агнера Фога: "Test programs for measuring clock cycles and performance monitoring". 

Однак, розвинені ОС надають і звичайним програмам доступ до цих інструментів. Про відповідні API MS Windows трішки говорилося в попередньому пості. Для повноти коротко (дуже коротко!) розглянемо спеціалізоване API для POSIX систем -- PAPI та кросплатформову бібліотеку від Intel Processor Counter Monitor (PCM).

Як бачимо, повної кросплатформовості немає -- або тільки POSIX (з обмовками), або тільки процесори Intel, при тому -- достатньо сучасні (конкретніше -- див. далі).

Огляд інструментів трасування та профілювання багатопоточних програм

Взято тут.

Для вирішення описаних раніше задач (та багато яких інших!) існує ряд хороших готових інструментів. З тих чи інших причин вони для задачі, згаданої в попередньому пості, не підходять, зокрема -- через складність автоматизації і не завжди присутню можливість фіксувати фрагменти коду, що досліджуються. Але знати про них слід -- вони дозволяють детально, іноді -- майже інтерактивно, подивитися, як паралельна програма функціонує. Та й автоматизація, в принципі, можлива.

MS Windows - Concurrency Visualizer

Інструмент, власне, візуалізації роботи багатопоточної програми. Може використовуватися як додаток до Visual Studio або самостійно.

• Інсталяція: "Concurrency Visualizer для Visual Studio 2015".
• Використання консольних утиліт: "Concurrency Visualizer Command-Line Utility (CVCollectionCmd)".
• Використання GUI Visual Studio 2015: "Profiling an application with Visual Studio – Concurrency"

Вимірювання часу роботи коду

Взято тут.

Для одного дослідження виникла потреба заміряти час виконання шматків програми. При чому -- різних програм, включаючи багатопоточні, які виконуватимуться на різних архітектурах, із різними процесорами.

Задача ця виявилася далеко не тривіальною. Сучасний процесор -- дуже складний пристрій. Який працює із складно організованою пам'яттю -- кеші, NUMA, інші жахіття. А на ньому виконується жахливо складна операційна система.

Однак, задачу таки треба вирішувати. Що важливо -- профайлери, на жаль, не дуже підходять, через необхідність дослідити час виконання певного шматка коду -- достатньо великого, але не цілої програми. Точніше -- десятків програм на різних мовах. Добування потрібної інформації із профілів -- чи не складніша задача, за самостійне вимірювання.

Спробую тут дати короткий огляд підходів. Він не претендує на вичерпність -- це надміру складна та велика сфера, хоча принаймні згадати - де дивитися для глибшого ознайомлення, старатимуся.

Отож, задача: є багатопоточна програма, слід виміряти час виконання її фрагменту, тривалість роботи якого складатиме між секундами і хвилинами.

Проста бібліотека для роботи з гігрометрами DHT11 і DHT22

Приклад виміру.

В попередньому пості ми розглянули трішки нетипові для цього блогу пристрої -- гігрометри. Наведу також приклад коду для роботи із ними. На жаль, код доволі примітивний -- зроблений на явних затримках. Значно елегантнішим було б зробити скінчений автомат на перериваннях. Однак, як завжди, часу жахливо забракло, усвідомив -- якщо буду чекати, поки допишу, то опублікую добре якщо в цьому році. То викладаю, як є -- в ролі "технологічної демонстрації", хай і неелегантної. 

Цей пост цілком може швидко застаріти -- майте на увазі.

Огляд  та використання

Бібліотека:

• Дозволяє під'єднувати довільну кількість гігрометрів -- поки вистачить пінів.
• Як і попередня бібліотечка для LCD5110, ця -- повністю динамічна, єдиний необхідний пристрою пін задається при ініціалізації. (Зі всіма плюсами і мінусами такого підходу. Обговорення див. у пості за посиланням вище, у розділі "Технічні подробиці").
• Потребує мікросекундні таймери та можливість вимірювати мікросекундні інтервали. Вона користується кодом, запропонованим тут: "Мікросекундні затримки та відлік мікросекунд для STM32".
• Сама бібліотека складається із двох файлів, dhtxx.h і dhtxx.c.
• Поки -- чисто С-на бібліотека.

Скачати бібліотеку можна тут. Архів включає бібліотечку для роботи із мікросекундними інтервалами, але вважає, що в проекті є файл gpio.h, згенерований STM32CubeMX.

Гігрометри DHT11 і DHT22

DHT11 та DHT22.
Фото взято тут.

Згадані в назві сенсори користуються певною популярністю поміж любителів. Вони мають терпимі параметри, прості в роботі та зовсім дешеві (на ebay -- менше долара перший, 2.7$ -- другий). Правда, відносно повільні та, іноді, капризні.

При тому, хоча вся інформація про них в мережі є, але вона розсіяна по купі різних місць, а більшість даташітів взагалі китайською, іноді із перекладом у вигляді "підстрочника".  Так що, вирішив і я приєднатися до цього інформаційного хаосу. :-)

Скачати згадані даташіти, накопані на просторах Інтернету, можна тут.

Отож,  DHT11 і DHT22 міряють відносну вологість та температуру. Загальні характеристики:

Дисплей Nokia 5110 на контролері PCD8544 - бібліотека для STM32

За мотивами попереднього поста, написав бібліотечку для роботи із ним за допомогою STM32. Бібліотека ще зовсім сира, але нею вже можна користуватися. В подальшому її код знаходитиметься на Github, але поки прикріпляю архівом. Опис нижче орієнтується на System Workbench for STM32 та STM32F3Discovery, хоча ні те ні те не є принциповим.

Увага! Так як бібліотека мала б розвиватися, дана стаття може доволі швидко застаріти. Але гарантій не дам. :-)

Огляд 

В списку нижче, цифрами вказано номери виносок, розшифрованих в технічних подробицях. Отож, бібліотека:

• Дозволяє під'єднувати довільну кількість дисплеїв (1).
• Підтримує вивід тексту: окремих літер, С-стрічок,  чисел, та стрічок, форматованих у стилі printf() (2).
• Підтримує вивід довільних прямих. (5)
• Вміє виводити прямокутники, зокрема -- заповнені. (5)
• Вивід може відбуватися як "білими", так і чорними пікселями.
• Надає доступ до всіх режимів дисплею та безпосереднього керування його параметрами.
• На кожному дисплеї може використовуватися декілька незалежних вікон. Із кожним вікном пов'язаний свій "графічний" курсор, який задає лівий верхній кут виводу наступної літери (3).
• Для кожного дисплея підтримує свій "відео"-буфер, котрий при оновленнях передається на пристрій для відображення.
• Шрифт вкомільовується в код, моноширинний, але розмір символу не фіксується бібліотекою (4). 
• У шрифті по замовчуванню підтримується кирилиця -- українська та російська. Кодування -- ASCII + CP1251.
• На жаль, автоматично генерованої документації в коді ще немає. Планується. Поки дивіться код та користуйтеся цим постом.