Curiosity -- короткий огляд 10

На жаль, мушу визнати, що не маю належних ресурсів -- часу/сил/натхнення, щоб систематично писати тут про прогрес міжпланетних місій. Планую, щоправда, продовжувати (і відпрацювати борги -- Akatsuki, Juno, ExoMars Trace Gas Orbiter) по опису самих міжпланетних станцій -- воно корисно й мені особисто, щоб потім розібратися, що ж та місія робить, а без опису бракує терпцю ознайомлюватися достатньо детально.

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

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

908-го сола марсохід зробив чергову, шосту, свердловину (область Telegraph Peak, ближче до вершини Pahrump Hills, соли 903-923), після чого, нарешті, залишив цей регіон, прямуючи до "долини" Artist's Drive. На жаль, в процесі свердління сталося коротке замикання, десь в ударному (перкусійному) механізмі свердла, з яким довелося розбиратися, і повторення тепер є постійною загрозою. CheMin виявив у добутих зразках кристобаліт і кварц. 

Telegraph Peak, Sol 918, 7 березня 2015, Right Navcam. Взято тут.

Curiosity -- короткий огляд 9

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

Покинули ми Curiosty на початку 780-х солів. В процесі роботи в останній області, Confidence Hills, розпочалися проблеми із "рукою". Зокрема, не зразу змогли закрити кришку мікроскопа MAHLI. Це могло привести до запилення об'єктиву, тому використання маніпулятора обмежили, до вияснення причини проблем. Паралельно відбувалася підготовча робота до зустрічі із кометою Siding Spring. 780-го марсохід вирушив далі, до Pahrump Hills, проїхавши 22 метри:

Сол 780, місцевість Book Cliffs, NavCam.
(c) NASA / JPL / Emily Lakdawalla

Саме в місці, сфотографованому вище, марсохід і зустрічав комету.

Далекомір HC-SR04 -- зміст

Взято тут -- із тексту
якраз про змісти.

Якось так, слово за словом, постів про ультразвуковий далекомір  HC-SR04 написав багато -- робота із ним виявилася напрочуд хорошим педагогічним прикладом. При чому, пости ці сильно розкидані по часу. Тому вирішив створити окремий зміст.

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

Проекти із кодом, який використовується в постах, зазвичай можна скачати за посилання в кінці посту. Історично склалося так, що проекти для CoIDE. В принципі, зараз перейшов на System Workbench for STM32, але якщо б взявся всі пости переносити -- їх написання точно б ніколи не завершилося. Та й STM32VLDiscovery він не підтримує.

Використано мікроконтролери сімейства STM32, детальніше в тексті.

Код, в основному, написаний на С -- використання C++ додало б декілька зайвих рухів, майже не додавши "педагогічної цінності". Однак, в своїх реальних проектах використовую С++. Проекти в міру (сподіваюся -- в міру) неохайні, хоч і старався, щоб зовсім потворними вони не були. Якщо бачите помилки -- пишіть. 

Див. також зміст суміжної серії постів: "Таймери STM32".

Далекомір HC-SR04 -- зовнішні переривання EXTI/HAL

Подивимося, що в порівнянні із використанням CMSIS, надає нам STM32CubeMX разом із HAL для організації обробки переривань від зовнішніх джерел, традиційно -- реалізувавши приклад із попереднього CMSIS-поста.

Периферія сконфігурована як і раніше:

• Trig -- пін PA10,  вивід. Ми керуватимемо ним третім каналом таймера TIM1.
• Echo -- PA6, генеруємо переривання.

"Малюємо" відповідну конфігурацію:

Далекомір HC-SR04 -- зовнішні переривання EXTI/CMSIS

Взято тут: "STM32 External Interrupt"

Перекласти всю роботу із далекоміром на таймери (чи таймер) -- зручно, але, іноді, надміру складно -- якісь Capture-compare, захоплення ШІМ, інший "страх и ужас". Мікроконтролери мають ще один, простіший спосіб фіксувати тривалість імпульсу -- за допомогою "банального" зовнішнього переривання -- EXTI: фіксується момент зміни стану лінії ECHO з 0 в 1, потім -- назад, тривалість -- різниця часу між ними. Таймер, звичайно, використовується -- для вимірювання часу, але лише як лічильник. 

Спрощений варіант роботи за допомогою переривань було розглянуто в "методичному" пості: "Зовсім просто про далекомір HC-SR04 із GPIO/HAL", тут дотримуватимуся більш систематичного, але дещо заскладного для конкретної простої задачі підходу. 

Далекомір HC-SR04 -- один таймер/HAL

Повторимо зроблене в попередньому пості, із використанням HAL/SMT32CubeMX. Такі, трішки нестандартні, режими роботи, HAL безпосередньо не підтримує, але і не заважає сильно -- все ж, абстракція, надана цією бібліотекою, зовсім тоненька.

Нагадаємо апаратну конфігурацію:

• TRIG -- PA6 (TIM3_CH1)
• ECHO -- PB0 (TIM3_CH3)
• PC8 -- синій світлодіод
• PC9 -- зелений світлодіод 

За потреби, Cube вміє автоматично робити ремапінг. Тут в ньому потреби немає:

Далекомір HC-SR04 -- трасування, додаток

Взято тут.

Як вже згадувалося, використання дебагера для пошуку помилок можливе не завжди. Причин дві -- таймери, які не обов'язково зупиняються при зупинці головної програми та периферія, яка має свої часові характеристики, і часто не може вийти за їх межі. Якщо для таймерів мікроконтролер підтримує режим зневадження із їх зупинкою (при тому, не всі середовища розробки надають доступ до нього), то з периферією складніше. Наприклад, якщо шина I2C цілком терпима до доступних людині затримок, то  HC-SR04 не чекатиме -- через мілісекунди після запуску, видає результат, тривалістю до десятків мілісекунд і на тому завершує.

Один із способів пошуку помилок у таких програмах -- зберегти послідовність виконання програми в самому мікроконтролері, а потім передати її на комп'ютер -- так зване трасування. Воно використовувалося для створення програм, які працюють із далекоміром з використанням таймерів (чесно кажучи, однотаймерний варіант я б без трасування не зміг би до ладу довести, принаймні, це забрало б на порядок більше часу). Розглянемо використаний там підхід.

Увага: дана реалізація дуже примітивна і має багато недоліків! Створювалася нашвидкоруч і без якихось подальших перспектив. На С++ можна зробити багато краще та надійніше. Та й на чистому С є простір для покращення.

Крім того, навіть ідеально реалізований, цей метод придатний не всюди -- він не підійде, наприклад, для дуже чутливої до часів реакції апаратури, або коли пам'яті не вистачає. Однак, на загал, інструмент зручний.

Отож, поїхали.