суббота, 16 апреля 2016 г.
Хакер рассказал о компрометации Hacking Team
По утверждению Phineas Fisher взлом был мотивирован тем фактом, что услуги Hacking Team использовались спецслужбами для нарушения прав человека. Напомним, что спецслужбы различных стран были основными клиентами HT. Во взломе участвовал один человек и это заняло у него сто часов работы.
That’s the beauty and asymmetry of hacking: with just 100 hours of work, one person can undo years of a multimillion dollar company’s work. Hacking gives the underdog a chance to fight and win.
Хакер пишет, что утекшие документы кибергруппы показывают, что они злоупотребляли термином «этический хакинг», продавая свои услуги тем, кто, по его мнению, был сам достоен компрометации.
I see [Hacking Team’s CEO David] Vincenzetti, his company, and his friends in the police, military and governments, as part of a long tradition of Italian fascists.
Хакер утверждает, что на начальном этапе компрометации внутренней сети HT, использовался 0day эксплойт в embedded-устройстве, детали которого не раскрываются.
Hacking Team tenía muy poco expuesto al internet. Por ejemplo, diferente a Gamma Group, su sitio de atención al cliente necesita un certificado del cliente para conectar. Lo que tenía era su sitio web principal (un blog Joomla en que Joomscan no revela ningún fallo grave), un servidor de correos, un par de routers, dos dispositivos VPN, y un dispositivo para filtrar spam. Entonces tuve tres opciones: buscar un 0day en Joomla, buscar un 0day en postfix, o buscar un 0day en uno de los sistemas embebidos. Un 0day en un sistema embebido me pareció la opción más alcanzable, y después de dos semanas de trabajo de ingeniería inversa, logré un exploit remoto de root. Dado que las vulnerabilidades aún no han sido parcheadas, no voy a dar más detalles. Para más información sobre como buscar este tipo de vulnerabilidades, véase y.
У меня имелось мало возможностей для компрометации Hacking Teeam через Интернет. Например, в отличие от организации Gamma Group, HT использовали идентификацию клиента на основе цифрового сертификата. Компрометация могла быть выполнена через веб-сайт HT (управляемый Joomla, причем сканер Joomscan не нашел в нем существенных уязвимостей), почтовый сервер, через пару роутеров, два устройства VPN, и устройство фильтрации спама. Таким образом, у меня имелось три варианта: найти 0day уязвимость в Joomla, postfix, или в embedded-устройстве. Обнаружение уязвимости в embedded-устройстве мне показалось вполне выполнимой задачей и потратив на это две недели мне удалось написать эксплойт с функцией предоставления прав root. Так как уязвимости до сих пор не закрыты, я не буду раскрывать их детали.
Я потратил много времени на разработку и тестирование эксплойта перед его использованием против HT. Был написан специальный firmware-бэкдор, а также были подготовлены ряд инструментов для работы на embedded-устройстве после получения доступа к нему. Firmware-бэкдор использовался для защиты используемого эксплойта. Использование эксплойта один раз с возвратом управления бэкдору усложняет работу по обнаружению использованных уязвимостей и последующего их исправления.
Модификации следующих известных инструментов для embedded-устройства использовались для работы и выполнении необходимых действий:
- Набор инструментов busybox для работы на ОС устройства.
- Инструмент nmap для сканирования внутренней сети HT.
- Скрипт Responder.py, который предназначен для осуществления атак на локальную сеть под управлением Windows, когда у атакующего есть доступ к внутренней сети, но отсутствуют учетные данные для входа в домен.
- Пакет ПО Python для исполнения предыдущего скрипта.
- Инструмент tcpdump для получения передаваемого трафика.
- Инструмент dsniff для отслеживания небезопасной передачи паролей для таких сервисов как ftp, а также для выполнения атаки типа ARP spoofing.
- Инструмент ретрансляции socat.
- Инструмент screen для выполнения расширенного спектра действий в системе.
- SOCKS прокси-сервер.
- Сетевой инструмент tgcd.
Как видно из рассказа автора, после получения доступа к внутренней сети организации, он использовал различные эксплойты Windows для получения прав администратора в системе. Кроме 1day эксплойтов, для этого использовались атаки типа Pass-the-Hash, а также инструмент удаленного доступа (RAT). В целом, упоминаемые шаги мало чем отличаются от шагов злоумышленников, используемых в аналогичных комплексных кибератак, которые уже неоднократно раскрывались security-фирмами…
Прочую информацию о кибератаке можно получить на pastebin.
Конкурс на лучшую публикацию про разработку, дизайн или тестирование мобильного приложения
Мы, Appodeal, вместе с Хабрахабром решили провести творческий (в понятии сообщества) конкурс для всех тех пользователей, читателей и, конечно же, специалистов в области мобильной разработки, на лучшую публикацию по теме с тегом "#Appodeal".
Зачем? Всё просто — хороший контент требует усилий. А ещё хороший контент требует качественного опыта — иначе что описывать? С этим всё понятно — прописные истины.
Поэтому мы решили наградить 30, 20 и 10 тысячами рублей авторов трёх лучших публикаций на Хабрахабре в тематике мобильной разработки. Всё то, что подходит тематически под следующие хабы:
- Разработка мобильных приложений
- Разработка под Android
- Разработка под iOS
- Тестирование мобильных приложений
- Дизайн мобильных приложений
Как видите, мы постарались заинтересовать не только Objective C, Swift и Java-специалистов, но и тестировщиков и, конечно же, талантливых дизайнеров. Потому что мир не замыкается на одних разработчиках и, как мы знаем, в создании качественных и популярных мобильных приложений всегда принимает участие достаточно большое количество самых разнообразных профессионалов.
Естественно, места распределяются привычным хабрапользователю голосованием за публикации — мы не стали менять привычную схему. Но, вдобавок к этому, конкурсное жюри, состоящие из сотрудников компании, будет следить за отсутствием накруток и полнотой раскрытия темы автором.
Что мы добавили, так это «Специальную номинацию». В которой призом станет… iPad Pro 128 Гб! Заинтересовались? Получить его будет не так-то просто, хотя, с одной стороны, легче — для участия в номинации не нужно иметь прокачанный аккаунт на Хабрахабре (необходимый для успешных публикаций), достаточно лишь доступа к сети и желания детально протестировать продукт.
Для участия в спец. номинации необходимо:
- Скачать SDK Appodeal;
- Интегрировать в ваше мобильное приложение с общим количеством скачиваний в любой из платформ не менее 10000;
- Поделиться собственными впечатлениями и аргументированной критикой;
- Наконец, бороться за iPad Pro с другими участниками!
Пишите публикации и описывайте собственный опыт создания и поддержки или отрисовки и тестирования мобильного приложения, в разработке которого вы принимали непосредственное участие. А мы наградим авторов лучших постов по итогам голосования призами от спонсора (то есть нас).
Это, конечно же, помимо славы и успеха, которые вас настигнут в любом случае! Главное — не забудьте добавить тэг вида "#Appodeal" к своим публикациям по теме.
Комментарии (0)
Устройство NVRAM в UEFI-совместимых прошивках, часть третья
Если вам интересно, что умудрились напридумывать на замену VSS разработчики из Phoenix — добро пожаловать под кат, только предупреждаю сразу, статья получилась достаточно длинной.
Отказ от ответственности №3
Даже не знаю, что сюда писать после первых двух «отказов», кроме того, что автор в очередной раз снимает с себя любую и всякую ответственность за потерю работоспособности вашей NVRAM, прошивки, системы и всего остального. Используйте сведения на свой страх и риск, ведите себя хорошо, и все будет хорошо.
Если вы случайно наткнулись на эту статью и вам не ясно, что тут происходит, почему автор ныряет в какие-то форматы с головой, ничего не поясняя, и да как он посмел вообще — первая и вторая части ждут вас. Остальные — за мной!
Phoenix Flash Map
Впервые открыв содержимое основного тома NVRAM из прошивки имеющегося у меня старенького Dell Vostro 3360 на Ivy Bridge, я был сильно удивлен. Чего там только не найти — сначала целый набор интеловских микрокодов, после него какой-то блок с строками, добрую половину которых составляют копии строки NoLongerUsed, затем смутно знакомые блоки с RSA-сигнатурами, штук пять хранилищ EVSA, и под занавес — структура с говорящей сигнатурой _FLASH_MAP. Короче говоря, ребята из Phoenix умудрились свалить в том NVRAM такую кучу всего, что без карты стало не разобраться. Вот с нее и начнем.
Заголовок карты занимает 16 байт и выглядит вот так:
struct PHOENIX_FLASH_MAP_HEADER {
UINT8 Signature[10]; // Сигнатура _FLASH_MAP
UINT16 NumEntries; // Количество записей
UINT32 : 32; // Зарезервированное поле
};
Сразу за заголовком без дополнительного выравнивания вплотную друг к другу следуют записи вот такого вида:
struct PHOENIX_FLASH_MAP_ENTRY {
EFI_GUID Guid; // GUID записи, помогает определить тип данных, на который эта запись указывает
UINT16 DataType; // Тип данных, я видел два - том (0) и данные в томе (1)
UINT16 EntryType; // Тип записи, могут быть различными, точно назначение мне пока не известно
UINT64 PhysicalAddress; // Физический адрес данных, на которые указывает запись
UINT32 Size; // Размер данных, на которые указывает запись
UINT32 Offset; // Смещение данных, на которые указывает запись, относительно данных, на которые указывает первая запись
};
Максимальный размер карты определяется её положением, а т.к. располагается она за 0x1000 байт от конца основного тома NVRAM, максимально в ней может быть ровно 113 записей, чего достаточно с огромным запасом.
На скриншоте карта выглядит вот так:
Сразу виден заголовок с сигнатурой и количеством записей, сразу за ним идет запись с нулевым GUID'ом, типом данных 0 (т.е. это том), типом записи 6, физическим адресом 0xFF980000, размером данных 0x20000 и с нулевым смещением (еще бы, относительно самого себя первый том никуда не смещен, иначе что-то сильно не так или с файлом, или с метрикой пространства).
Можно было еще привести все значения GUIDов, которые мне удалось найти в разных образах и сопоставить с типом данных, но это можно сделать буквально одним скриншотом из UEFITool NE, вот он:
Кроме GUIDов, также виднеется пара спойлеров: смутно знакомые блоки с RSA оказались публичным ключом и маркером для таблицы SLIC, а блок со строками назвался почему-то CMDB. Ко всем этим вещам мы еще вернемся, а вот с картой все понятно, осталось научиться разбирать форматы всех этих перечисленных блоков, и можно считать, что структуру NVRAM в прошивке на базе Phoenix SCT мы более или менее понимаем. Поехали!
Intel Microcode
Первым по списку у нас блок с микрокодами. У меня, к сожалению, нет образа с микрокодами AMD в NVRAM, поэтому рассматривать будем только интеловские. Несмотря на то, что в заголовке микрокода целых 12 свободных байт, места даже под какую-нибудь захудалую сигнатуру не нашлось, и потому поиск такого блока данных среди содержимого тома NVRAM — та еще задача. Будете разрабатывать свой процессор — задумайтесь о сигнатуре для его микрокода, пожалуйста! В любом случае, основной заголовок интеловского микрокода документирован и не менялся, на моей памяти, вообще никогда. Вот он:
struct INTEL_MICROCODE_HEADER {
UINT32 Version; // Версия структуры (1)
UINT32 Revision; // Ревизия микрокода
UINT32 Date; // Дата релиза
UINT32 CpuSignature; // Тип процессора
UINT32 Checksum; // Контрольная сумма, корректный микрокод вместе с заголовком и данными должен суммироваться в 0
UINT32 LoaderRevision; // Ревизия загрузчика микрокодов, для который предназначен микрокод
UINT32 CpuFlags; // Флаги процессора
UINT32 DataSize; // Размер данных без заголовка
UINT32 TotalSize; // Размер данных вместе с заголовком
UINT8 Reserved[12]; // Двенадцать нулевых байт
};
По идее, там есть еще расширенный заголовок, но самое главную для дальнейшего разбора информацию, общий размер, мы уже получили. Посмотрим на заголовок первого микрокода в томе:
Версия действительно 1, ревизия — 0x28, дата релиза — 24.04.2012, тип процессора — 0x206A7, контрольная сумма — 0xF3E9935D, ревизия загрузчика — 1, флаги процессора — 0x12, размер данных — 0x23D0, общий размер — 0x2400.
Тот же самый микрокод в UEFITool NE, видно что таких блоков с микродом оказалось 5 штук:
CMDB
Следующий блок, на который ссылается карта — CMDB. Назначение его мне не очень понятно, скорее всего он использовался для выбора подходящей конфигурации в прошивках, подходящих сразу к нескольким платам, либо для заполнения таблиц SMBIOS, но на данный момент он уже не используется. Блок этот имеет формат, который иначе как «наркоманским» я назвать не могу, что думали его разработчики — тайна сия великая есть. Смотрите сами:
struct PHOENIX_CMDB_HEADER {
UINT32 Signature; // Сигнатура CMDB
UINT32 HeaderSize; // Размер заголовка
UINT32 TotalSize; // Размер заголовка вместе с чанками
};
Заголовок не выглядит каким-то уж очень странным, ну нет общего размера, ну и ладно, конец блока можно найти при разборе, веселье начинается с чанков, которые проще показать на скриншоте сразу:
После заголовка с сигнатурой CMDB, размером 0x0C и общим размером 0x23 идет нулевой чанк из трех байт: стартовый байт 0x42 (до сих пор борюсь с желанием назвать его TheAnswer), смещение первой строки после заголовка (которое всегда 0) и смещение начала блока со строками (которое всегда TotalSize — HeaderSize). Итого — три поля из трех не используются вообще, зачем нужен этот чанк — решительно непонятно. За нулевым чанком следуют остальные, эти состоят уже из пяти байт: знакомого нам стартового 0x42, смещения строки-ключа, непонятного двухбайтового поля, которое всегда 0x205 и смещения строки-значения. Длины обеих строк при этом нигде не хранятся, и, видимо, даже не вычисляются. В блоке со строками отдельно хранится строка-заголовок BiosInfo, на которую ссылается нулевой чанк, а затем все оставшиеся строки, на которые ссылаются остальные чанки. Общий размер блока — всегда 0x100, поэтому он нигде и не хранится. Хочется спросить, что курил человек, который это придумал?
Т.к. структура давно уже не используется, и при этом глазами разбирается мгновенно, добавлять поддержку ее разбора в UEFITool NE я не стал. Если вдруг вам это нужно — напишите мне в комментариях или вот сюда.
SLIC Pubkey и Marker
Сразу за CMDB друг за другом следуют нужные для OEM-активации Windows Vista/7/2008 блоки Pubkey и Marker, которые потом специальным драйвером переносятся в ACPI-таблицу SLIC. Формат этих блоков я описывать не буду, дабы предотвратить возможный DMCA takedown этой статьи, но разобран он достаточно давно, описание всех полей показывает утилита RW Everything, плюс UEFITool NE их поддерживает, так что если форматы этих блоков вам все-таки необходимы, подсмотрите их в nvram.h.
EVSA
Последний формат в нашей карте, который (наконец-то!) используется для хранения переменных NVRAM. По сравнению с VSS формат использует место в NVRAM чуть более эффективно за счет дедупликации имен переменных и их GUID'ов, но и испортить хранилище EVSA намного проще, и практически все мои случаи восстановления данных из NVRAM вручную приходятся именно на него, несмотря на массированное использование этим форматом контрольных сумм. Данные (в том числе и заголовок самого хранилища) хранятся в виде записей с общим заголовком и отличающимися дополнительными полями, вот так:
struct EVSA_ENTRY_HEADER {
UINT8 Type; // Тип записи
UINT8 Checksum; // Контрольная сумма
UINT16 Size; // Размер записи, если не используется расширенный заголовок
};
struct EVSA_STORE_ENTRY {
EVSA_ENTRY_HEADER Header; // Заголовок записи
UINT32 Signature; // Сигнатура EVSA
UINT32 Attributes; // Атрибуты хранилища
UINT32 StoreSize; // Размер хранилища вместе с заголовком
UINT32 : 32; // Зарезервированное поле
};
struct EVSA_GUID_ENTRY {
EVSA_ENTRY_HEADER Header; // Заголовок записи
UINT16 GuidId; // Идентификатор GUIDа
// EFI_GUID Guid // Сам GUID можно включать в заголовок, а можно считать данными
};
Скриншотом:
Тут у нас заголовок хранилища с типом 0xEC («заголовок хранилища»), однобайтовой контрольной суммой 0x2C, размером 0x14 правильной сигнатурой EVSA, атрибутами 0x01 («тут лежат значения по умолчанию») и размером хранилища 0x2B65. Сразу после заголовка без какого-либо выравнивания идут две записи типа 0xED («GUID»), с контрольными суммами 0x35 и 0xB3 соответственно, размером 0x16, идентификаторами 0 и 1, и GUIDами 4FEE3D67-18F4-4217-BA7B-BC538148382A и 1E1F1797-2CCE-49D6-A6CE-4012F338A76E соответственно.
В UEFITool NE то же хранилище выглядит вот так:
Кроме уже рассмотренных типов 0xEC («хранилище») и 0xEC (иногда 0xE1, «GUID»), рассмотренных выше, существуют еще три — 0xEE (иногда 0xE2, «имя переменной»), 0xEF (иногда 0xE3, «данные») и 0x83 («удаленные данные»). Насколько я понял, удаление записей типа «GUID» и «имя переменной» возможно только при полной пересборке хранилища драйвером, выполняющем в нем сборку мусора.
Запись с типом «имя» выглядит так:
struct EVSA_NAME_ENTRY {
EVSA_ENTRY_HEADER Header; // Заголовок записи
UINT16 VarId; // Идентификатор имени переменной
//CHAR16 Name[]; // Имя переменной в кодировке UCS2
};
Картинкой:
Запись типа 0xEE, с контрольной суммой 0x39, длиной 0x20 и идентификатором 0, в которой лежит строка DellVariable в UCS2. Показывать в UEFITool NE смысла нет — и так все понятно.
Осталось рассмотреть последний тип записи — данные. На самом деле, форматов там два, вот такие:
struct EVSA_DATA_ENTRY {
EVSA_ENTRY_HEADER Header; // Заголовок записи
UINT16 GuidId; // Идентификатор GUIDа
UINT16 VarId; // Идентификатор имени
UINT32 Attributes; // Атрибуты
// UINT8 Data[]; // Данные
} EVSA_DATA_ENTRY;
struct EVSA_DATA_ENTRY_EXTENDED {
EVSA_ENTRY_HEADER Header; // Заголовок записи
UINT16 GuidId; // Идентификатор GUIDа
UINT16 VarId; // Идентификатор имени
UINT32 Attributes; // Атрибуты, специальный атрибут 0x10000000 указывает на наличие дополнительного поля
UINT32 DataSize; // Настоящий размер данных, вместо того, что в заголовке
// UINT8 Data[]; // Данные
};
Покажу на скриншоте только первый, ибо второй достаточно редко встречается, и там просто еще одно дополнительное поле:
Тут у нас две записи типа 0xEF, первая из которых имеет контрольную сумму 0x84, размер 0x5F, идентификатор GUIDа 0, идентификатор имени 0 и атрибуты 0x03 (NV+BS), а вторая — 0xEA, 0x11, 1, 1 и 0x03 соответственно. В первой, получается, как раз и хранятся данные той самой вышеупомянутой переменной DellVariable с GUIDом 4FEE3D67-18F4-4217-BA7B-BC538148382A.
В UEFITool NE:
Заключение
Ну вот, теперь формат данных, которые прошивки на кодовой базе Phoenix SCT могут хранить в томах NVRAM, стал немного яснее. Осталось поговорить о формате NVAR, который используется в AMI Aptio, о котором я расскажу в следующей, заключительной части этой статьи.
Большое спасибо за внимание, высылайте в Л/С замеченные очепятки, и пусть рандом избавит вас от восстановления NVRAM хоть вручную, хоть еще как.
Комментарии (0)
пятница, 15 апреля 2016 г.
Конференция Ladies Code: Девушки в IT 26 апреля в Москве
Зачем это все? Мы полагаем, что все должно быть сбалансировано — и девушки своим талантом, страстью и другими подходами к решению проблем могут значительно ускорить и улучшить развитие технологий. В России уже ощущается большая нехватка разработчиков, системных администраторов, людей большинства IT-специальностей. И дальше ситуация очевидно будет только ухудшаться. C другой стороны девушки просто не хотят идти в компьютерные науки, отчасти из-за снобизма мужской части, отчасти не находя в этом ничего интересного. Мы хотим этой конференцией увлечь девушек информационными технологиями, показать что это не страшно и задать направления для развития и карьеры.
Как это сделать? Очень просто — спикеры у нас в подавляющем большинстве тоже прекрасные женщины и они на своих примерах расскажут о том, как это интересно и увлекательно. Выступают представительницы Artec3D, Стрим, Нетология, ФРИИ, Yota Devices, TimePad, Pure, Pixonic, 101XP, NVIDIA, Lingualeo, Opera, ZeptoLab, Mail.Ru Group, Intel, WEBORAMA, LPgenerator, PayQR, Bookinna и многих других. Среди тем — Разработка ПО, Разработка Игр, Карьера, Создание стартапов, Железные проекты, Аналитика, Дизайн.
В мире ведущие корпорации возглавляются женщинами — Yahoo, Oracle, Intel, DARPA (когда то, правда), даже автономные автомобили в General Motors делает женщина. Мы хотим, чтобы и в России все было столь же красиво и прекрасно.
Приходите, вход открыт для всех, самая красивая конференция весны 26 апреля в Люмьер-Холле: http://ift.tt/1VuEIb7.
Комментарии (0)
Программирование и отладка микроконтроллеров ARM Cortex-M4 фирмы Atmel в среде операционной системы Linux. Часть 1
В статье описан процесс развертывания экосистемы разработки приложений для микроконтроллеров Atmel серии SAM4S в среде операционной системы Linux. Читатель познакомится также с оценочной платой SAM4S-EK и семейством ARM Cortex-M4 микроконтроллеров фирмы Atmel. Приведены рекомендации по работе с адаптером отладки SAM-ICE (он же J-LINK) и программой OpenOCD.
Введение
Выбор операционной системы Linux в качестве среды для программирования микроконтроллеров ARM Cortex-M4 фирмы Atmel сложно назвать общепринятой практикой. Напротив, для разработки под свои микроконтроллеры Atmel свободно распространяет среду Atmel Studio 7, предназначенную исключительно для операционных систем Windows. Не будет секретом и тот факт, что разворачивание и настройка среды Atmel Studio 7 для новичка окажется куда проще, чем выбранный автором путь.
Автор предлагает использовать среду разработки Qt Creator в связке с инструментарием для кросс-компиляции GCC и с пакетом OpenOCD для отладки. В качестве операционной системы автор выбрал Linux Lubuntu 14.04 LTS (выполняющуюся на виртуальной машине, но это не существенно). Такой подход позволяет с легкостью переходить на другие ARM (и не только) микроконтроллеры, не меняя при этом привычный комплект инструментов. Например, в [1] приводится пример разработки для микроконтроллеров STM32F4 фирмы ST microelectronics с применением такого же комплекта инструментов.
Несколько слов об используемой терминологии. Аппаратное устройство, которое подключается к целевому микроконтроллеру и к рабочей станции, далее называется отладочным адаптером. Отладчиком же будет называться компьютерная программа, служащая для пошагового выполнения программы, просмотра значений ячеек памяти и т.д.
Аппаратная платформа
Рис. 1. Внешний вид платы SAM4S-EK с подключенным отладочным адаптером.
В основе оценочной платы лежит микроконтроллер SAM4S16C фирмы Atmel, ключевые особенности которого приведены ниже:
- Ядро ARM Cortex-M4, максимальная тактовая частота 120МГц
- Объемы памяти на кристалле: 1 Мбайт flash-памяти и 128 кбайт ОЗУ
- Среди периферийных устройств можно выделить: USB контроллер (работа только в режиме Device), контроллер внешней NAND flash-памяти, контроллер SD карт памяти
- Контроллеры интерфейсов UART, I2C, SPI и др.
- 100-выводный корпус
Среди особенностей оценочной платы SAM4S-EK можно выделить следующие:
- Микросхема NAND flash-памяти Micron MT29F2G08ABAEA объемом 2 Гбит
- Цветной дисплейный модуль FTM280C34D разрешением 320x240 точек, с диагональю 2,8 дюйма и с резистивной сенсорной панелью. Дисплей содержит встроенный контроллер Ilitek ILI9320, подключенный к микроконтроллеру по параллельному интерфейсу.
- Контроллер резистивной сенсорной панели Texas Instruments ADS7843E
- Распаяны два DB9 разъема для двух портов RS-232 (один из них — с сигналами RTS, CTS), выведен также интерфейс RS-485
- Элементы сенсорного управления по технологии Atmel QTouch, расположены прямо на печатной плате (сенсорные кнопки 5 шт. и слайдер)
- Электретный микрофон и операционный усилитель TS922 для него
- Усилитель звуковой частоты для подключения наушников TPA022, а также 3,5мм гнездо типа «джек».
- Два коаксиальных BNC разъема, которые подключены к встроенным АЦП и ЦАП блокам микроконтроллера.
- Держатель micro-SD карты памяти
- 63 вывода общего назначения (GPIO) выведены на IDC разъемы с шагом 2,54 мм
Более подробно как о плате SAM4S-EK, так и о микроконтроллере SAM4S16C можно ознакомиться на сайте Atmel [12].
Комплект инструментов
Когда аппаратная (плата SAM4S-EK) и программная (операционная система Linux Lubuntu) платформы определены, можно построить систему аппаратных и программных инструментов для программирования и отладки целевого микроконтроллера (рис. 2)
Рис. 2. Структурная схема процесса отладки микроконтроллера
Микроконтроллер по интерфейсу JTAG подключен к отладочному адаптеру SAM-ICE, который в свою очередь подключен к рабочей станции по интерфейсу USB. Питание отладочного адаптера подается также по интерфейсу USB, а питание платы разработчика вместе с микроконтроллером должно осуществляться отдельно (на рис. 2 не показано).
На рабочей станции должна выполняться некая программа, которая будет взаимодействовать с адаптером отладки SAM-ICE с одной стороны и отладчиком GDB, входящим в инструментарий GCC, с другой. На эту роль идеально подходит свободно распространяемая программа OpenOCD [4-6], которая помимо отладки может использоваться для загрузки прошивки во flash-память микроконтроллера и для внутрисхемного тестирования.
Программа OpenOCD поддерживает как адаптер отладки SAM-ICE (в действительности это аналог популярного J-LINK), так и оценочную плату SAM4S-EK (соответственно и микроконтроллеры Atmel SAM4). Кроме этого OpenOCD доступна в виде исходных кодов и может быть собрана для операционной системы Linux.
Интегрированная среда разработки Qt Creator (рис. 2) получает отладочную информацию через отладчик GDB и предоставляет в удобном для разработчика виде (точки останова, значения переменных, пошаговое выполнение программы и др.)
Программа OpenOCD работает в режиме сервера и допускает подключение других клиентов-программ, например, telnet-клиента (рис. 2). Это может быть удобно для серийного программирования микроконтроллеров на производстве.
Установка OpenOCD
Установить OpenOCD можно наименее трудоемким способом — из репозиториев Ubuntu, для чего следует выполнить команду:
sudo apt-get install openocd
Однако в этом случае будет установлена устаревшая версия 0.7.0 (проверить версию установленной программы OpenOCD можно выполнив команду openocd --version).
Для получения актуальной версии (на момент написания статьи — 0.9.0), необходимо собрать OpenOCD из исходных кодов. Для этого надо выполнить следующие действия:
1. Загрузить исходные коды OpenOCD с сайта [2], выполнив команду:
cd ~
wget http://ift.tt/1SjnAFZ.
В результате в домашнем каталоге должен появиться файл-архив openocd-0.9.0.tar.bz2.
2. Далее следует разархивировать OpenOCD, выполнив команду:
tar xvf openocd-0.9.0.tar.bz2
В результате, в домашнем каталоге должен появиться каталог с исходным кодом openocd-0.9.0
3. Проверить, установлена ли библиотека libusb-dev, которая необходима для взаимодействия рабочей станции и адаптера SAM-ICE по USB интерфейсу. Чтобы проверить наличие библиотеки libusb-dev, следует выполнить команду:
sudo dpkg --get-selections | grep libusb
Если библиотека установлена, то вывод должен быть примерно такой:
libusb-0.1-4:i386 install
libusb-1.0-0:i386 install
libusb-1.0-0-dbg:i386 install
libusb-1.0-0-dev:i386 install
libusb-1.0-doc install
libusbmuxd2 install
Если библиотека не установлена, то ее установить ее можно, выполнив команду:
sudo apt-get install libusb-dev
4. Для сборки OpenOCD также потребуются следующие пакеты:
- make,
- libtool,
- pkg-config версии 0.23 и выше,
- autoconf версии 2.64 и выше,
- automake версии 1.9 и выше,
- texinfo
Проверить их наличие можно тем же способом, что и библиотеки libusb-dev, как описано выше.
5. Теперь можно собрать пакет OpenOCD с поддержкой адаптера SAM-ICE, для чего следует последовательно выполнить следующие команды:
cd ~/openocd-0.9.0
./configure --enable-jlink
make
sudo make install
Ключ --enable-jlink предписывает включить поддержку адаптера J-LINK. Дело в том, что адаптер SAM-ICE представляет собой модифицированный J-LINK BASE от фирмы Segger так, что он может работать только с микроконтроллерами фирмы Atmel. Однако программный интерфейс для работы с J-LINK полностью совместим с адаптером SAM-ICE.
Подключение адаптера SAM-ICE
Далее следует подключить адаптер SAM-ICE к рабочей станции и проверить список подключенных по USB устройств командой:
lsusb
Если адаптер SAM-ICE подключен, то вывод команды должен содержать следующую строку:
Bus 002 Device 003: ID 1366:0101 SEGGER J-Link ARM
Где 1366 — VID-номер (код производителя USB-устройства), 0101 — PID-номер (код изделия). Эти номера потребуются в дальнейшем для настройки менеджера устройств udev.
Чтобы обеспечить взаимодействие сервера отладки OpenOCD с адаптером SAM-ICE по интерфейсу USB необходимо создать файл-правило для менеджера устройств udev, например, так:
sudo nano /etc/udev/rules.d/45-jlink.rules
В окне редактора Nano ввести следующий текст:
SUBSYSTEMS=="usb", ATTRS{idVendor}=="1366", ATTRS{idProduct}=="0101", \
MODE:="0666", \
SYMLINK+="jlink_%n"
Где поля idVendor и idProduct соответствуют полученным ранее номерам VID и PID.
Далее следует перезагрузить рабочую станцию.
Если же сконфигурировать udev, как описано в [3], то запуск сервера отладки OpenOCD будет возможен только с правами суперпользователя, что в дальнейшем создаст проблемы с отладкой из среды QtCreator.
Совместная работа адаптера SAM-ICE и сервера отладки OpenOCD
Необходимо в каталоге проекта (автор использовал каталог ~/sam/) создать файл конфигурации openocd.cfg со следующим содержимым:
telnet_port 4444
gdb_port 3333
source [find interface/jlink.cfg]
source [find board/atmel_sam4s_ek.cfg]
gdb_flash_program enable
Файл openocd.cfg содержит предписания для сервера OpenOCD, а именно:
- разрешить подключение к серверу по протоколу telnet через порт 4444,
- установить порт 3333 для подключения отладчика GDB,
- соединяться с адаптером J-LINK (SAM-ICE),
- целевая платформа — оценочная плата Atmel SAM4S_EK,
- разрешить программирование flash-памяти.
Теперь, когда необходимое программное обеспечение установлено, а отладчик подключен к рабочей станции и целевому микроконтроллеру, можно проверить работоспособность системы. Для этого следует, находясь в каталоге проекта (~/sam/), запустить сервер OpenOCD командой
openocd
Если все сделано правильно, в терминал будет выведено:
Open On-Chip Debugger 0.9.0 (2015-12-29-14:45)
Licensed under GNU GPL v2
For bug reports, read
http://ift.tt/1Ob5uAr
Info : auto-selecting first available session transport "jtag". To override use 'transport select <transport>'.
adapter speed: 500 kHz
adapter_nsrst_delay: 100
jtag_ntrst_delay: 100
cortex_m reset_config sysresetreq
Info : J-Link ARM V8 compiled Nov 25 2013 19:20:08
Info : J-Link caps 0xb9ff7bbf
Info : J-Link hw version 80000
Info : J-Link hw type J-Link
Info : J-Link max mem block 9296
Info : J-Link configuration
Info : USB-Address: 0x0
Info : Kickstart power on JTAG-pin 19: 0xffffffff
Info : Vref = 3.313 TCK = 1 TDI = 0 TDO = 0 TMS = 0 SRST = 1 TRST = 1
Info : J-Link JTAG Interface ready
Info : clock speed 500 kHz
Info : JTAG tap: sam4.cpu tap/device found: 0x4ba00477 (mfg: 0x23b, part: 0xba00, ver: 0x4)
Info : sam4.cpu: hardware has 6 breakpoints, 4 watchpoints
При этом приглашение командной строки выведено не будет, что свидетельствует о том, что сервер успешно запущен и установлено соединение с целевым микроконтроллером через отладочный адаптер SAM-ICE.
Теперь можно подключиться к серверу отладки по протоколу telnet, для чего надо открыть второй терминал и выполнить команду:
telnet localhost 4444
Где 4444 – номер порта, заданный ранее в конфигурационном файле openocd.cfg. В результате будет установлено соединение с сервером отладки и появится приглашение для ввода команд:
Trying 127.0.0.1...
Connected to localhost.
Escape character is '^]'.
Open On-Chip Debugger
>
Когда соединение с сервером установлено, можно выполнить любую из команд OpenOCD (полный список — в [7]), например, просмотреть содержимое регистров ядра микроконтроллера. Для этого следует остановить выполнение программы в микроконтроллере командой halt:
> halt
target state: halted
target halted due to debug-request, current mode: Thread
xPSR: 0x81000000 pc: 0x004003e6 msp: 0x20003488
Затем просмотреть непосредственно содержимое регистров командой reg:
> reg
===== arm v7m registers
(0) r0 (/32): 0x00000013
(1) r1 (/32): 0x00000800
(2) r2 (/32): 0x004023D8
(3) r3 (/32): 0x00000000
(4) r4 (/32): 0x81CBF6AB
(5) r5 (/32): 0x788E2033
(6) r6 (/32): 0x5C2195CC
(7) r7 (/32): 0x20003488
…
…
…
Завершить работу сервера OpenOCD можно командой shutdown, при этом автоматически закроется и telnet соединение:
> shutdown
shutdown command invoked
Connection closed by foreign host.
andy@andy-vm:~$
Связку «адаптер SAM-ICE – программа OpenOCD» можно использовать для серийного производства для загрузки готовой прошивки во flash-память микроконтроллера. Например, чтобы очистить всю flash-память микроконтроллера Atmel SAM4S16C, необходимо выполнить команду:
openocd -f interface/jlink.cfg -f board/atmel_sam4s_ek.cfg -c init -c halt -c "flash erase_address 0x00400000 0x100000" -c reset -c
shutdown
Где 0x00400000 — адрес начала flash-памяти в адресном пространстве, 0x100000 — размер flash-памяти в шестнадцатеричной системе счисления, для микроконтроллера SAM4S16C составляет 1 Мбайт = 2^20 байт = 0x100000(16) байт. Адрес начала flash-памяти и ее размер получен из документации на данный микроконтроллер [12].
В случае успешного стирания вывод программы OpenOCD должен содержать строку:
erased address 0x00400000 (length 1048576) in 4.685278s (218.557 KiB/s)
Для непосредственно записи прошивки во flash-память надо выполнить команду:
openocd -f interface/jlink.cfg -f board/atmel_sam4s_ek.cfg -c init -c halt -c "flash write_image erase sam.hex" -c reset -c shutdown
Где sam.hex — имя файла с прошивкой в формате Intel HEX. OpenOCD принимает также другие форматы файлов с прошивкой, например binary и ELF.
В случае успешной загрузки прошивки во flash-память вывод должен содержать строки:
Info : sam4 does not auto-erase while programming (Erasing relevant sectors)
Info : sam4 First: 0x00000000 Last: 0x00000000
Info : Erasing sector: 0x00000000
wrote 8192 bytes from file sam.hex in 2.979438s (2.685 KiB/s)
То есть в данном случае очищается лишь те сектора flash-памяти, в которые будет размещена прошивка.
Создание комплекта в Qt Creator
Теперь, когда связка «адаптер отладки — сервер отладки» настроена и готова к работе, можно приступать к настройке интегрированной среды разработки, в нашем случае — Qt Creator.
При этом предполагается, что на рабочую станцию уже установлен инструментарий GCC для сборки для микроконтроллеров ARM, а также установлена и настроена сама среда Qt Creator, процесс установки и настройки которых подробно описан в [1].
Прежде всего, необходимо добавить сервер отладки, для этого в Qt Creator следует вызвать настройки (пункт главного меню «Инструменты –> Параметры…»), выбрать вкладку «BareMetal» («Голое устройство»), нажать «Добавить» и выбрать пункт «OpenOCD». Появится окно, где можно указать параметры запуска сервера (рис. 3). Следует отметить, что поддержка OpenOCD добавляется в среду Qt Creator при включении модуля «BareMetal», как это сделать — описано в [1].
Рис. 3. Добавление сервера отладки OpenOCD в Qt Creator.
Имя сервера отладки можно задать «OpenOCD + SAM-ICE» (рис. 3), «Режим запуска» следует установить в «Запуск в режиме TCP/IP», так как сервер OpenOCD будет выполняться на рабочей станции, то поле «Хост» должно содержать имя компьютера «localhost» и порт 3333, указанный ранее в конфигурационном файле openocd.cfg.
В поле «Исполняемый файл» следует вписать имя исполняемого файла openocd (или полный путь к нему, если необходимо). Поле «Файл конфигурации» должно содержать путь к файлу конфигурации OpenOCD, созданному ранее, в данном случае это ~sam/openocd.cfg. Поля «Команды инициализации» и «Команды сброса» по умолчанию содержат команды управления сервером, менять их содержимое не требуется.
Далее можно добавить новое устройство, для которого будет производиться сборка и отладка — микроконтроллер семейства Atmel SAM4S. Для этого в настройках Qt Creator следует выбрать вкладку «Устройства» и нажать «Добавить…».
После чего ввести имя устройства, например «Atmel SAM» и выбрать настроенный ранее сервер отладки «OpenOCD + SAM-ICE».
Когда устройство добавлено, можно окончательно настроить комплект для сборки так, как показано на рис. 4.
Рис. 4. Добавление комплекта для микроконтроллеров Atmel SAM4S в Qt Creator.
Компилятор GCC и отладчик GDB заданы из состава инструментария GCC для микроконтроллеров ARM так, как описано в [1].
Продолжение статьи будет оформлено в виде отдельной публикации, чтобы не раздувать объем.
Литература
- Курниц А. Разработка для микроконтроллеров STM32 в среде операционной системы Linux // Компоненты и технологии. 2015. № 10.
- http://ift.tt/1SjnAG1
- http://ift.tt/1SeFrL4
- http://ift.tt/1SjnAG3
- http://ift.tt/1SeFrL6
- http://ift.tt/1SjnAWh
- http://ift.tt/1SeFrL8
- http://ift.tt/1Sjnz4U
- http://ift.tt/1MpL1aN
- http://ift.tt/1SjnAWj
- www.e-kit.ru
- http://ift.tt/1SeFs1m
Комментарии (0)
[Из песочницы] Вертикальные отступы или ещё раз про margin
margin, и что такое Margin collapsing.
Помощь родителю
Отступы необходимо формировать за счёт самого элемента, а не его содержания, т.е. не стоит обеспечивать отступ между соседними блоками за счёт отступов их дочерних элементов.
Margin для padding
Как следствие предыдущего пункта,
margin первого и последнего элементов вертикального списка должны быть нулевыми, ибо зачем? Если нужен отступ от внешних границ родителя, используем padding для родителя.
Mixin для вертикального списка
Для реализации всего вышеописанного вам понадобиться хелпер для расстановки
margin с использованием нативного not(), например такой.
// Scss
@mixin ritm($valueTop, $valueBottom:$valueTop) {
@if $valueTop != 0 {
@include not(':first-child') {
margin-top: $valueTop;
}
}
@if $valueBottom != 0 {
@include not(':last-child') {
margin-bottom: $valueBottom;
}
}
}
Подробнее.
Пользовательский контент
В пользовательский контент, в классическом понимании, состоит из параграфов, списков, изображений и т.п. Всё это образует условный вертикальный список (практически однородных) элементов. Все вышеперечисленные правила применяйте и для компонентов UGC.
Более того, явное указание вертикальных margin для элементов UGC, позволяет производить перестановки элементов контента без вреда для конечного результата.
// Scss
.ui-h3 {
@include ritm(1.5*$v, 1*$v);
}
.ui-img {
@include ritm(1*$v, 1.5*$v);
.ui-h3 + & {
margin-top: 1.5*$v;
}
}
Margin и Box-model
Стоит сделать оговорку, что margin является неотъемлемой частью блока, хоть и воспринимается как нечто попутное. Важно понимать, размеры блока, а конкретно его ширина, не всегда одно и тоже, что значение свойства width. Width — это ширина части бокса от border до border, либо размер контентной области в зависимости от боксовой модели. При смене боксовой модели (border-box / content-box), width может меняться, а размеры блока при этом остаются неизменные.
Each box has four edges: the margin edge, border edge, padding edge, and content edge.
developer.mozilla.org — Introduction_to_the_CSS_box_model
В ней у каждого бокса есть 4 области: margin (внешние отступы), border (рамка), padding (внутренние поля), и content (контент или содержимое).
developer.mozilla.org — box_model
Each box has a content area (e.g., text, an image, etc.) and optional surrounding padding, border, and margin areas;
www.w3.org — box-dimensions
Тонкости перевода, холивара ради:
— граница блока ≠ border блока, бордер — это border согласно спецификации, а граница блока — это граница/край блока
— block area = область блока (читай размеры блока), но
— block area ≠ область ограниченная border'ом.
Честно говоря, наука-наукой, а ежедневная работа вносит свои правки в лексикон разработчиков.
PS. Данные дополнения мной были предложены в комментариях к вышеупомянутой статье, но строгий НЛО вырезал все теги по причине ограниченных прав.
Комментарии (0)
Кодь кто живой: Livecoding.tv запустил онлайн-хакатон по созданию своего приложения
Т.к. это сервис онлайн-трансляций кодинга, то и конкурс объявлен онлайновый — т.е. разработка должна вестись в прямом эфире. Тогда, если даже не получится сделать лучше других, хотя бы можно выиграть приз за самую интересную трансляцию.
Если вы всё же не слышали про Livecoding.tv, то, вкратце, это Twitch (ну про «Твитч»-то вы знаете?) для программистов. Да, кодить в прямом эфире сейчас модно.
Чтобы проникнуться идеей было проще, можем посоетовать кое-кого из русскоязычных кодеров:
- indiecamp — разработка игр, участник флешмоба «100игрзанеделю»
- Voley6969 — разработка игр Unity3D
- c0deum — разработка мильтичата C++
- MomWillBeProud — разработка на Ruby, Coffeescript, AngularJS
- DAloGG — разработка на Swift
- есть и девушки: tetianna — ведение стримов как способ изучения программирования
В принципе, конкурс — тот же хакатон, но для экстравертов. По условиям, трансляцию можно делать на своём языке, но, думаю, шансы выиграть в этом случае будут ниже, т.к. большинство аудитории сервиса всё равно англоязычное — соответственно, русскоязычную трансляцию они посмотреть и оценить не смогут. С другой стороны, и среднего английского должно хватить, чтобы вести стрим.
Приложению не требуется повторять все функции сайта — главное, чтобы работало самое основное: страница пользователя, список стримов, страница видео, расписание, поиск и прочее.
Участники могут начинать стримить с сегодняшнего дня. Конкурс продлится месяц, и завершится 15 мая. Победителя выберёт коммьюнити голосованием в блоге Livecoding.tv в трёх номинациях:
- лучшее iOS-приложение под iOS 8.0 и выше,
- лучшее Android-приложение под Android 4.0 и выше,
- лучший (самый интересный и познавательный) стрим
Приложение должно быть создано с использованием Livecoding API.
Лучше бы, конечно, призы поменяли местами. Зачем iOS-разработчику ещё один айпад, а андроидщику ещё один дроид?
Весь процесс разработки приложения должен транслироваться на Livecoding.tv. В этом поможет инструкция для стримера.
В результате должны присутствовать основные элемента сервиса:
- Домашняя страница;
- Страница пользователя с логином и выводом сообщений об ошибках;
- Список трансляций с фильтрами по категориям, языку и сложности;
- Список видеозаписей с теми же фильтрами по категориям, языку и сложности, а также дате и популярности;
- Страница канала с видеоплеером, чатом и инфо;
- Страница видео с плеером и инфо;
- Страница расписания с напоминалками;
- Поиск по стримам, расписанию, видео, плейлистам, стримерам и зрителям.
Результат нужен будет в виде установочного бинарника (ipa или apk), самостоятельно выложенного в Playstore или Appstore. Для эмуляции Android будут использоваться GenyMotion и Manymo, для iOS — Xcode.
Все дополнительные вопросы можно задать на ящик streamers@livecoding.tv
Вот вроде и всё. Кто решится участвовать — присылайте ссылки в комменты, посмотрим.
Комментарии (0)
четверг, 14 апреля 2016 г.
Storydesk — мой несуществующий чудо-проектировщик
Позавчера, на второй неделе возни с инструментами для проектирования и анимации прототипов, у меня накипело: мои изначальные пожелания к инструментам синтезировались с тем, что я увидел и пощупал, образовав экспериментальную модель проектировщика, с которой я спешу поделиться с вами.
***
Ключевой постулат модели, по залёту которого и началось рождение инструмента, состоит в другом подходе к организации цифрового рабочего пространства: я привык работать не с экранами приложения, а с его полотном в разных состояниях.
Экраны и полотно в разных состояниях
Это не вопрос привычки, сформированной инструментом и временем: с самого детства я с удовольствием смотрел на работу мультипликатора у какой-то волшебной доски, на которой листались кальки с персонажами, запечатляя различные сцены мультфильма, потому что такой подход не только очаровывал детское воображение, но и казался логичным для самого процесса. Волшебная доска мультипликатора, как оказалось, называется световым (просветным) столом или стеклофоном.
Просветный стол
Да, в процессе над созданием мультфильма используется раскадровка (storyboard), чтобы запечатлеть основной ход событий, но основная проработка ведётся на стеклофоне.
Сюжетная доска «Пиноккио»
Таким образом, есть два подхода к созданию взаимосвязанной истории: линейный (storyboard) и совмещённый (стеклофон). Второй подход позже закрепится мной под понятием «линия истории» (storyline), а «storydesk» станет кодовом словом концепции моего несуществующего проектировщика.
***
Первым делом я обратил внимание на то, что схожую реализацию я периодически кое-где когда-то да использовал:
Layer Comps
Когда я разобрал на детали механизм Layer Comps, то увидел в нём зачаток будущего функционала – объект обладает поведением на определённом экране (состоянии полотна):
Поведение объекта на определённом экране
Но мне захотелось не только наделять объект более разнообразными движениями, чем простое появление и исчезновение в разных местах полотна …
Вариация появления-исчезновения объекта
… но и наделять объект отзывчивостью на мои действия, жесты:
Объект начинает реагировать на мои действия
Реакция объекта в такой модели состоит из причины (моего действия, жеста) и следствия (что должно произойти или куда я должен попасть, если объект обладает свойствами обычной ссылки):
Составляющие реакции объекта: я указываю объекту на что (нажатие) и как надо реагировать (переключаем экран)
Как и движения объекта, я бы хотел не только задавать разнообразную реакцию, но и делать это не единожды, т.е. наделять объект мультиреакцией:
Разнообразная и комплексная реакция объекта
Наделение объекта поведением в программной парадигме Фотошопа становится похожим на придание эффекта для слоя:
Меню добавления поведения и результат на слое в Фотошопе
Таким образом, в моём инструменте я хотел бы видеть обогащённый функционал Layer Comps, задавая объекту (актёру) не только различные движения появления-исчезновения, но и реакцию на мои действия в определённых экранах (сценах) моего монументального полотна:
Работа с объектом в Layer Comps и в Storydesk
Обратите внимание, как начинают мутироваться понятия: слой становится объектом, экран – сценой.
***
Весь процесс начинает базироваться на управлении сюжетной линией истории моего приложения, которая, как и любая линия произведения, состоит из сцен, схожих или отличных друг от друга:
Со сценами на такой линии я смогу выполнять стандартные режиссёрско-монтажёрские операции:
Сцены будут проигрываться и записываться в чистовик поочерёдно или произвольно:
Помимо списка сцен, кликабельно и само полотно с объектами:
Репетировать и транслировать свою историю я смогу не только на экране проектировщика, но и на других проигрывателях:
Постепенно подбираясь к функционалу трансляции, я увидел сходство макросценария Storydesk с вышедшим в марте Adobe Expirience Design, где в режиме Design я работаю с объектами, в Prototype – с сюжетом, на Share – транслирую свою историю в разных форматах.
Макросценарии Adobe XD и Storyline
Единственное и большое дополнение – наличие контроля обратной связи от моей истории. Таким образом, рабочий процесс моего проектировщика-небылицы складывается следующим образом:
Objects и Story можно объединить под одну вкладку, обозначающую созидательный аспект, чтобы вычленить базовые операции с любой историей: создавать, распространять, получать обратную связь.
В идеале, создавая универсальный продукт, я бы добавил возможность обзора сцен (экранов) стандартным линейным (storyboard), добавив этот режим на вкладке Story, чтобы можно было переключаться между режимами board и line, но пока решил оставить всё как есть.
И пока моя губа катится да раскатывается, помимо добавления объектов с подгружаемым реальным контентом, я бы хотел распространять свою историю всеми возможными способами: выгружать и отправлять в разных видах и форматах, обсуждать с аудиторией и тестировать на ней.
***
Мечты должны сбываться! И если для кого-то вышеизложенная концепция проектирования – мечта, которую можно воплотить в реальность: буду рад услышать, как и где это может произойти ;)
И напоследок, пока я перевожу эту статью на мой интермедияте-английский для Medium, можете пощёлкать прототип общей модели Storydesk – несуществующего проектировщика историй ваших продуктов.
Прототип Storydesk
Комментарии (0)