Эндрю Шульман - Неофициальная Windows 95

Трапилася мені книжечка із далекого минулого, "Неофициальная Windows 95", проглядав її останні місяці, на пару із Таненбаумом, про якого пізніше. Такої "ніжності" та "ностальгії" як до FCB та DOS я до неї аж ніяк не відчуваю, тому детальної рецензії, як до "Extending DOS" by Ray Duncan et. al  не писатиму. Однак, дечим із неї поділитися хотілося б.

Мікро-реалізація стандартної бібліотеки C++ -- uClibc++

Саморобна амфібія. (c) wiki

Якщо libcxxrt підміняє собою libsupc++, то uClibc++ намагається бути всім решта із libstdc++, що не входить в libsupc++. Тобто, для свого функціонування вона потребує libsupc++ (або libcxxrt) -- бібліотеку низькорівневої підтримки.

Подивимося, що це за звір. Скачати її можна на офіційному сайті. В архіві є файл INSTALL, в якому описана процедура інсталяції. На жаль, вона доволі нетривіальна і сильно зав'язана на Linux (хоча, перенесення під Windows видається можливим). Перший етап -- "make menuconfig", генерує конфігурацію бібліотеки -- можливості, які слід включити. Результатом його буде файл system_configuration.h, із купою макросів виду "#define __UCLIBCXX_STL_BUFFER_SIZE__ 32". Після чого слід виконати хитрі магічні процедури, в результаті яких буде отримано незалежний lib-файл.

Для економії часу, я схитрував --- критично важливий system_configuration.h згенерував на доступній мені Linux-машині, а решту операцій уник, додавши файли бібліотеки до проекту. Для ясності, це може виглядати так -- в директорії проекту створюється директорія uclibcxx, до неї копіюється вміст директорій src та include із архіву текстів бібліотеки, крім Makefile-ів та піддиректорії src/abi -- вона буде зайвою. В include кладемо і system_configuration.h. В середовищі створюємо відповідні групи, додаємо до них файли із цих директорій. (Готовий демонстраційний проект CoIDE, як завжди, можна скачати тут).

Додаємо libsupc++ до списку бібліотек (як це робити, не раз згадувалося в попередніх постах) -- uClibc++ покладається на неї. (libstdc++, навпаки, повністю самодостатня, фактично є "два-в-одному"). Також, вважаємо, що С-ний runtime, про який говорили раніше, присутній. "Свій" С++-ний runtime не додаємо --- цим займається libsupc++.

Пробуємо компілювати. Халяви немає -- купа помилок.

libcxxrt в ролі libsupc++ -- бібліотеки підтримки мовних засобів часу виконання

Клікабельно. :-)

Розглядаючи підтримку С++ на "голому залізі", в попередньому пості, ми орієнтувалися на штатні засоби --- мінімальний набір із libsupc++, яка підтримує синтаксичні засоби мови (зокрема, виключення та RTTI) та повну libstdc++, що дозволяє, принаймні -- в теорії, користуватися всіма засобами стандартної бібліотеки мови. Однак, і одна і друга страждають певною громіздкістю, тому іноді хотілося б мати більш компактну альтернативу, навіть якщо її можливості будуть дещо урізаними. В ролі альтернативи до libsupc++ часто пропонують libcxxrt, для повної бібліотеки можна подивитися на uClibc++.

Почнемо із розгляду libcxxrt. Вона прийшла із світу FreeBSD/x86, потім модифікувалася і для інших платформ. Потребує окрему бібліотеку розкрутки стеку, в ролі якої підходять як libgcc_s так і libunwind (якщо просто --- одна із них мала б бути з GCC, детальніше -- див. попередні пости або тут чи тут). Крім того, вона, все ж, розрахована на великі системи, де не потрібно економити кожен кілобайт, що проявляється в коді.

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

При тому, завдяки своїй простоті (відносній), бібліотека виявилася неоціненим джерелом подробиць про роботу C++ runtime, допомігши розібратися в нюансах для попереднього поста. У свою чергу, цінні підказки по перенесенню libcxxrt знайдено тут: "C++ Exception Support".

Попередивши, можна починати. Розгляд проводиться на прикладі все тієї ж STM32VLDiscovery, але для інших мікроконтролерів сімейства особливих відмінностей (крім доступного розміру RAM) бути не мало б.

C++ із ARM GCC + STM32 (+ CoIDE)

Автор С++, Б'ярн Страуструп
Фото взято тут.

Програми практично на будь-якій (*) мові програмування потребує підтримки так-званого коду часу виконання --- runtime. Для С цей код відносно простий, С++ вимагає складнішого --- всілякі там ініціалізації статичних змінних, підтримка роботи із виключеннями, тощо. Зазвичай програмісти не повинні про це турбуватися --- компілятор, разом із операційною системою все забезпечує. Однак, програмуючи мікроконтролери, дуже часто доводиться обходитися без операційних систем (про RTOS всілякі поговоримо іншим разом), а відповідно, без підтримки стандартних бібліотек, які змушені звертатися до ОС для виконання своїх функцій. При тому,  якщо необхідний мінімум підтримки мовних конструкцій С присутній майже завжди, із С++ типова ситуація гірша. Це нікуди не годиться, насправді.

(*) З традиційною обмовкою, що всезагальні твердження про об'єкти реального світу, завжди помилкові -- включаючи це твердження. :-)

Давайте подивимося, яка runtime-підтримка потрібна C++, а потім -- що потрібно "допилювати" вручну, щоб добитися її, працюючи із наступним комплектом інструментів: ARM GCC 4.8 та 4.9 + STM32 CMSIS + CoIDE. Для інших компіляторів -- будуть суттєві відмінності, навіть для інших версій GCC певні відмінності можуть бути. Для інших контролерів -- будуть відмінності. Із середовищем -- як повезе. [Можливо, про Keil поговоримо окремо.]

Розгляд нижче -- достатньо мінімалістичний. І так пост непомірно великий. Про підтримку локалей мова не йде, для контролерів вони просто не вартують затрат. Взагалі, про ціну за використання окремих можливостей С++ буде окремий пост -- сюди воно просто не влазить. Хіба скажу -- зазвичай ця ціна нульова або незначна. Основні винятки описані нижче -- виключення і RTTI.

Вважатимемо, що вже обговорена підтримка стандартної бібліотеки у нас є. Працюватимемо все із тією ж STM32VLDiscovery, обладнаною мікроконтролером STM32F100RB. Сама по собі модель мікроконтролера не є аж такою важливою, але для ясності, орієнтуватимемося на його ресурси -- 128 Кб пам'яті програм, 8Кб оперативної пам'яті.

Так як пост вийшов достатньо великим і трохи плутаним, почну  із короткого огляду:

• C++ runtime. Огляд задач, які стоять перед кодом часу підтримки, зокрема -- перед його реалізаціями, libstdc++ і libsupc++.
• Ініціалізація. З чого починає роботу контролер, і як добитися, щоб стандартна для С++ процедура підготовки програми перед входом в main(), зокрема -- виклик конструкторів глобальних об'єктів відбувалася, як очікується. Розглядається процедура ініціалізації контролера, підхід GCC  до ініціалізації програми (зокрема, всілякі там crt0.o) та обробник переривання Reset. Також, для повноти, зачіпається тема "деініціалізації" -- виклику деструкторів по завершенню main(), хоча для контролерів можливість не є особливо цінною.
• Оператори new, new[], delete, delete[]. Особливості реалізації, вимоги до них, опис цілого зоопарку цих операторів.
• Виключення. Дуже корисна можливість сучасних мов програмування, яка, на жаль, вимагає складної підтримки часу виконання і помітних ресурсів для своєї роботи (помітних -- в масштабах доступних контролеру ресурсів). Самопальною тут не обійдешся. Тому рекомендується їх просто не використовувати. Якщо ж таки є потреба у них, (чи є просто бажання спробувати), розповідається, як підключити їх підтримку засобами libsupc++, і чого це коштуватиме. Звертається увага на відмінності обробки виключень в GCC  для ARM та його ж для інших архітектур. Є посилання для подальшого заглиблення. Згадується альтернативна реалізація C++ runtime -- libcxxrt, про яку буде окремий пост.
• RTTI -- RunTime Type Information. Так само, як із виключенням, краще без цієї можливості обійтися, якщо ж таки дуже треба (не вдається прожити без dynamic_cast<> :-), розповідається, як її підключити -- крім компонування із libsupc++ слід додати декілька функцій: __cxa_bad_cast(), __cxa_bad_typeid(), що задають реакцію на відповідні події.
• Реакція на виклик чисто віртуальних чи видалених функцій. Власне -- воно, пара функцій, що викликатимуться у таких нещасливих випадках. Компілятор вставляє їх виклик в патологічних місцях коду, без надання їх реалізації будуть помилки компонування.
• Локальні статичні змінні. Для захисту від одночасного доступу, race condition, під час ініціалізації статичних змінних в багатопоточному середовищі, компілятор вставляє спеціальні захисні виклики (таке собі блокування-розблокування мютекса). Написати ці функції коректно відносно складно, тому тут, для початку, описано мінімальні заглушки, які, насправді, не захищають, але дозволяють коду скомпілюватися. (За більш  повною реалізацією див. ту ж libcxxrt).
• C++11. Більшість мовних засобів мали б працювати зразу, без додаткової підтримки.
• Стандартна бібліотека С++. Включаючи STL. Огляд того, що вдасться використовувати зразу, що потребує певної підтримки часу виконання, а для чого доведеться тягнути цілу libstdc++. Якщо коротко -- послідовні контейнери (vector<>, deque<>, list<>, array<>, і т.д.) та більшість алгоритмів можна використовувати майже зразу. Асоціативні вимагають компонуватися із libstdc++. Паралельно розглянуті деякі брудні трюки, що дозволяють справитися із дещо непомірними її апетитами щодо RAM. Ілюстрація затрат ресурсів на це все.
• Керування та відстеження динамічного виділення пам'яті.
• Опис демонстраційного проекту.
• Додаток містить прокоментований скрипт лінкера.

Для лінивих, демонстраційний проект тут.

На жаль, якорі HTML в цьому блозі чомусь дуже капризно поводяться, тому, щоб не витрачати додаткового часу (даний пост його спожив неміряно!), не використовую їх для посилання на розділи нижче (може потім додам, під настрій).

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

Retargetable printf з CoIDE та порівняння розмірів ROM/RAM для різних способів виводу

Ілюстрація з Вікі до
теми саморобок (DIY)

В попередньому пості було розглянуто, як забезпечити мінімалістичну підтримку стандартної бібліотеки С для мікроконтролерів сімейства STM32F1, (для контролерів інших сімейств, крім, власне, особливостей SemiHosting, відмінності будуть мінімальними, якщо взагалі будуть), працюючи з-під CoIDE. Однак, повноцінна підтримка цієї бібліотеки не завжди потрібна, а витрати пам'яті програм та RAM її printf(), в деяких ситуаціях можуть бути неприйнятними. На такий випадок CoIDE пропонує ще один варіант -- скористатися урізаною, мініатюрною реалізацією, яку воно називає Retargetable printf (Retarget_printf). (Взагалі, всі такі бібліотеки, де реалізувавши пару-другу функцій, можна "перенацілити" на роботу із іншим залізом, називають retargetable.)

Подивимося, що вона вміє, для чого може бути і як її подружити із SemiHosting --- виведенням повідомлень із використанням дебаггера.

Стандартна бібліотека C та SemiHosting (на прикладі STM32 і CoIDE)

Роль LibC в Linux. Зауважте, що
glibc надає значно більше інструментів,
ніж стандартна бібліотека С -- зокрема,
засоби POSIX. Нижче мови про них не буде.
(c) wiki

В попередньому пості було показано, як викристовувати CoIDE, програмуючи мікроконтролери (на прикладі плати STM32VLDiscovery). Розглянемо тепер, деякі загальні практичні питання програмування із використанням С. (В порівнянні із давнішими попередніми (1, 2) постами, тут більше подробиць, виправлено деякі помилки, і т.д.)

Увага (як часто буває в  embedded!), багато що із написаного нижче дуже сильно прив'язано до особливостей конкретного компілятора, GCC та конкретних його версій! Про Keil, можливо, колись напишу окремо. З іншого боку, особливої прив'язки до IDE немає, CoIDE згадується лише як конкретний приклад, котру галочку в котрому меню слід поставити для досягнення якогось результату. Розгляд ведеться для ARM-GCC 4.8 та 4.9, для новіших чи старіших версій можуть бути відмінності.

Стандартна бібліотека C

CoIDE 2

Давненько я про CoIDE не писав. Воно потроху розвивався, виходили нові версії, фіксилися старі баги, вносилися нові. З'явилася підтримка STM32F3 -- тих, що в STM32F3Discovery, з'явилася, в значній мірі -- формальна (див. наступні пости) підтримка C++. Остання доступна версія - 1.7.8. Однак, попередні рік-два, не зважаючи на вихід згаданої 1.7.8, основні зусилля були зосереджені на новій версії, CoIDE-2. Перші його випуски видалися мені претензійним, але мало-юзабельним. Однак, минав час, випала нагода з ним знову попрацювати, і виявилося, що версія 2.0.3, все ще бета, але вже цілком придатна для повсякденної роботи. 

Так як і в самому CoIDE, і в CMSIS (*) з часу попередніх постів ("CooCox CoIDE [1.5.1]", "CoIDE 1.7.1"), багато що змінилося, вирішив написати знову. Спочатку планувався один пост, потім він переріс у цілу серію, але, як би там не було, серія ця запланована як незалежна від попередніх матеріалів, але абсолютної гарантії не дам -- у них може бути щось важливе, що я забув згадати тут. Буду вдячний за bug-report-и. :-)

(*) CMSIS -- "стандартна бібліотека" для ARM-івських контролерів, основу якої, для спільного у всіх них ядра, випускає ARM Inc, а кожен розробник конкретних мікроконтролерів доповнює підтримкою своїх "фіч" --- реалізованих ними периферійних засобів та можливостей, див [1], [2].

Новини з Плутона (оновлюється)

Отож, новини із системи Плутона. 

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

Останні навігаційні фото Плутона та Харона, 12 липня 2015, 08:45 і 08:50 UTC, відповідно, віддаль -- 2.5 млн км.
(c) NASA / JHUAPL / SwRI

На прес-конференції від наземної команди, разом із цією фото було опубліковано попередні наукові результати:

Місія New Horizons

"New Horizons". (c) NASA

Плутон давно приваблює дослідників, особливо після того, як в 1989 Voyager-2 відвідав Нептун і Плутон залишився останньою планетою, де не бували земні роботи. Звичайно, первинним тут було не "колекціонування", а науковий (і трішки -- технічний) інтерес. Детальніше про останній -- див. "Плутон, до "New Horizons"", розділ "Фото".

Однак, дорога до нього була тернистою --- місії багато раз відміняли, навіть переможця, "наш" New Horizons, довелося відстоювати не раз. Детальніше на цій сторінці історії не зупинятимуся, за подробицями див. там же, посилання у виносці "(**)", а також вступ та історію на Вікі.

Тут зосередимося на тому, що це за Автоматична міжпланетна станція (АМС), що вона може і на які результати можна очікувати.

Спочатку --- про віддалі.  Станцію запущено в 2006 році, при запуску вона стала найшвидшим запущеним землянами об'єктом, по дорозі отримала "копняка" від Юпітера, тому змогла досягнути Плутона всього лиш за дев'ять з половиною років. А Плутон знаходиться всього лиш на внутрішній межі поясу Койпера. 

Тепер детальніше:

Ще один таємничий світ -- Плутон

Кращі, на момент публікації, фото. Подробиці - нижче.
(c) NASA / JHUAPL / SwRI

Є, все таки, щось магічне у тому, як нова земля вперше проявляється на горизонті. Вчетверте пишу про це в цьому блозі. Раніше була Веста, Церера, комета Чурюмова-Герасименко. А тепер -- Плутон. Як відомо, повз нього, через лічені десятки годин, 14 липня 2015 р, пролетить АМС New Horizons, вперше показавши його нам зблизька. Але вже зараз вона достатньо близько, щоб кожного дня постачати все більш якісні фото. І поки -- все більш загадкові.

Плутон, до "New Horizons"

Пара фотографій, з допомогою яких було відкрито Плутон.
Взято із Wiki

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

Про саму станцію, New Horizons, напишу трішки пізніше -- на жаль, недостача часу та втома і так відтягнули написання цього тексту до самого "далі нікуди". А зараз -- трішки про те, що ж ми знаємо про Плутон станом на першу половину 2015 року. 

Отож, Плутон, до-"Ново-Горизонтна" ера.

Мікро-оптимізація

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

Код, варіант 1:

double hamiltonian(const FK_GA_c::Individual & _indi)
{
    double sum = 0;
    for (unsigned i = 0; i < _indi.size(); i=i+2) {
        //i -- n_f,
        //i+1 -- n_d
        double n_f_i = _indi[i];
        double n_d_i = _indi[i+1];
        sum-=defparams.mu_f*n_f_i;
        sum-=defparams.mu_d*n_d_i;
        sum+=defparams.U*n_f_i*n_d_i;
        // 
        auto i_plus_1 = i+2; //i+1 в математичному сенсі --- наступний вузол
        // Циклічні граничні умови
        if(i_plus_1>=_indi.size()-1)
            i_plus_1=0;
        double n_f_i_1 = _indi[i_plus_1];
        double n_d_i_1 = _indi[i_plus_1+1];

        double base_hopping = (1-n_d_i)*n_d_i_1;
        double hopping=defparams.t1;
        hopping+=defparams.t2*(n_f_i+n_f_i_1);
        hopping+=defparams.t3*(n_f_i*n_f_i_1);

        hopping*=base_hopping;
        sum+=hopping;
    }
    return -sum;
} 

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

Марсіанська армада та комета Siding Spring - 2014

В жовтні 2014 відбулася подія із класу феноменального везіння. 19 жовтня 2014 поруч із Марсом пролітала комета Siding Spring (C/2013 A1) з хмари Оорта. В чому везіння? -- ту ж "Розетту" згадуючи? Комети, такі як Чурюмова-Герасименко -- короткоперіодичні, вони "тусуються" біля Сонця давно, вже ґрунтовно "просмажені" ним. Зате планувати місії до них відносно просто -- вони постійно тут. А комета Siding Spring (C/2013 A1) прилетіла до нас здалеку, навряд чи раніше бувала так близько до Сонця і повернеться не скоро -- після проходження перигелію період буде порядку мільйона років. Трагедія із такими, майже міжзоряними, гостями, в тому, що  спланувати до них спеціалізовану експедицію майже неможливо -- від моменту виявлення залишається замало часу. Наприклад, дану відкрили  3 січня 2013 року, менше ніж за рік до прольоту попри Марс.

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

Хмара Оорта та пояс Койпера. Взято тут.

Індієць MOM - 2015 - 1

Подивимося, чим там індійська марсіанська місія займається. Залишили ми її на початку жовтня 2014, коли було опубліковано перші фото.

7 жовтня станція виконала маневр, який дозволив їй заховатися за  Марсом під час зустрічі із кометою Siding Spring, використавши 1.9 кг палива (із ~40 кг запасу).

Поміж те все продовжували фотографувати.

Ліворуч -- вулкан Олімп, найбільший в сонячній системі. Праворуч -- долина Марінера. По центру -- Tharsis Montes, три великих щитових вулкани, Ascraeus Mons, Pavonis Mons і Arsia Mons.
4 жовтня 2014 р, висота 76680 км, MOM. Видно, що калібрування камери явно уточнюється -- якість зображення росте. Клікабельно!
(c) ISRO

Що ж розповів Dawn про Весту

Кратер Cornelia. Опис - нижче.

Колись вже описував, як виглядала для нас Веста до прильоту Dawn, та як вона почала проявлятися перед очима: "Перші результати Dawn з Вести. Остання фото -- 25 км на піксель!", "Наближаючись до Вести". Але самі фото --це ще навіть не початок. Користуючись даними від приладів, науковці проводять дослідження будови, геології, історії небесного тіла. 


Про попередні дослідження колись давно вже теж писав: "Новини з Вести, кінець 2011". Як там згадується, мені бракує і компетенції і зацікавленості безатмосферними тілами, щоб самому писати про те, що ж вдалося вияснити з того часу. Але недавно [ну, недавно -- на момент написання цього поста] Emily Lakdawalla з The Planetary Society зробила це за мене: "What did Dawn learn at Vesta?". Для тих, хто володіє англійською хоча б базово -- краще читайте оригінальну статтю! А для решти спробую коротко переказати.

Церера -- наближаємося [update 2]

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

Церера. 19 лютого 2015, 46 000 км, 4 км на піксель. Зображення збільшено вдвічі відносно оригінального.
(c) NASA / JPL / UCLA / MPS / DLR / IDA

Емілі пробує проаналізувати побачене: "At last, Ceres is a geological world", зокрема, проводить чисельні порівняння із іншими схожими тілами, на загал - дуже рекомендую! Мені бракує кваліфікації, щоб якось оцінювати чи коментувати самостійно, однак на кілька речей увагу звернути хочу.

Rosetta -- 2015, попередні результати 2014-го

Джети. Підпис та це ж фото у
великому розмірі, див. нижче!

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

Нижче -- всілякі вимірювання комети,  співвідношення ізотопів, пилюка на поверхні і в космосі, двометрові пилинки, тендітна атмосфера (екзосфера), з її CO2 та H2O, джети, геоморфологічні області, обриви і т.д. 

Rosetta -- 2015, працює та чекає на Philae

"Мале небесне тіло"...
Підпис та це ж фото у кращій
роздільній здатності див. нижче.

Так виглядає, 2015-й -- рік малих небесних тіл. Комета Чурюмова-Герасименко, Церера, Плутон.

Нагадаємо, 27 листопада 2014 ми знайомилися з підсумками активної роботи Philae. (Сподіваюся, лише першої її частини, хоч і не вірю в реалістичність цих сподівань). Про власну роботу "Розетти" взагалі не згадували з 11 листопада.

Зразу після цьго, 28 листопада 2014, опубліковано нові дані, з ROMAP, (Rosetta Lander Magnetometer and Plasma Monitor) на борту Philae. Його виміри використовувалися для спостереження за станом спускного апарату. Зокрема, магнітометр фіксував зміну орієнтації апарату в навколишньому магнітному полі. Згідно його показів:

Плани Dawn щодо Церери

Церера і "Dawn" (малюнок)
(с) NASA / JPL-Caltech

Станція "Світанок", "Dawn", перша із сучасних АМС, про яку я писав у цьому блозі, наближається до Церери -- найбільшого (і першого відкритого) астероїда із поясу астероїдів.

У цієї станціє є характерна особливість -- іонні двигуни. З їх допомогою вона може набути значно більшої зміни швидкості (delta v), ніж з використанням аналогічної маси палива хімічним двигуном, однак через малу силу, що розвивають згадані іонні двигуни, процес цей повільний. Тому, як і до Вести, наближення відбувається, за космічними масштабами, повільно (станом на минулий тиждень, яких 400 км/год), і Церера постає перед нашими очима поступово, ніби випливаючи із туману. 

Однак, вже зараз її видно краще, ніж її бачить "Хаббл". 

Користуючись нагодою, коротко розглянемо план польоту та дослідження. 

Перші фото Церери від Dawn

Церера потроху проявляється перед "очима"-камерами "Dawn" -- швидкість наближення порядку 400 км/год, (явно нетипова для космічних експедицій).

Є якась магія в такому плавному проявленні іншого світу, який з туманної плямки перетворюється на конкретне місце.

Перше фото Церери, зроблене Dawn під час калібрування камери. 20 липня 2010 р. Давно це було!
(c) NASA / JPL-Caltech / MPS / DLR / IDA

Церера. 1 грудня 2014, 1.2 млн км. (Не так вже й багато, як зауважила Емілі -- Титан знаходиться на такій же віддалі від Сатурна).
(c) NASA / JPL / UCLA / MPS / DLR / IDA

Церера. 13 січня 2015 р. 20 кадрів, зроблених із віддалі ~ 383 000 км. Диск поки займає 27 пікселів, вже майже дотягнулися до роздільної здатності "Хаббла".
(c) NASA / JPL / UCLA / MPS / DLR / IDA

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

Церера

Анімація обертання Церери за даними "Хаббла"
(c) STSci

Останній (вже майже впущений -- нові дані почали поступати) шанс подивитися, що ж ми знаємо про Цереру, на момент прибуття до неї "Dawn", аналогічно до того, що ми робили із Вестою.

• Церера -- перший із відкритих та найбільший астероїд поясу астероїдів. Карликова планета. 32% маси поясу астероїдів!

Chang'e-3 i Yutu -- все ще!

Зовсім коротеньке оновлення.

1. Yutu все ще функціонує! (Станом на 4 лютого 2015) -- див. тут (2 лютого) та тут (4 лютого).

2. Опубліковано фото галактики М101 в ультрафіолеті, з телескопу базової станції, Chang'e-3:

M101, ультафіолетовий телескоп Chang'e 3, 2 грудня 2014 р. (c) Chinese Academy of Sciences

3. Опубліковано багато нових фото у хорошій якості.

Chang'e 5-T1

Chang'e 5-T1
(c) CCTV

Поки ми слідкували за кометними перипетіями, китайці потроху просували власну програму дослідження космосу. В рамках підготовки до доставки ґрунту з Місця (Chang'e-5, запуск якого заплановано на 2017 рік), запущено та успішно проведено тестову місію  Chang'e 5-T1. Її призначенням було випробування капсули, (зокрема -- її теплового екрану), котра повертатиме зразки на Землю.

Українською її назву прийнято вимовляти Чан'є -- із твердим "н".