Обычно я пишу циклы статей по двум причинам. Либо я участвую в какой-то разработке и, с одной стороны, хочу рассказать о ней, но с другой – описать что-то интересное про применённые там технологии, так как овладел ими в достаточной мере. Самый большой цикл был про комплекс Redd, который перерос в разработку USB-анализатора на его базе. Другая причина засесть за клавиатуру – я нашёл какую-то интересную поделку

В сегодняшней статье (которая, надеюсь, разрастётся до цикла) всё несколько иначе. Поделка сама нашла меня. Её разрабатывают в другом отделе нашей же компании. Но именно в соседнем отделе, не в моём. Как она устроена внутри, мне знать не положено. Зато я могу, вдобавок к чтению документации, не просто расспрашивать авторов про пользовательский интерфейс, а ещё и давать им советы, как его изменить.

Речь пойдёт про чип, который по задумке разработчиков должен помочь Embedded-программистам начать работу с Искусственным Интеллектом, не погружаясь в его недра, а оперируя только привычными им сущностями. Давайте разбираться более детально.

Я очень люблю видеоуроки. Почему-то информацию с текста лично я воспринимаю весьма и весьма плохо. А есть вещи, в которых информации на бумаге не так много. Возьмём, к примеру, уроки игры на балалайке: на YouTube есть замечательные разборы, как играть ту или иную мелодию (кому интересно, ищем по имени «Сергей Воронцов»), но повторить и заучить последовательность с потокового видео сложно. Надо или записывать на бумагу (судя по комментариям под уроками, некоторые так и делают), или докупать дополнительные материалы (но я не жадный, а домовитый).



В общем, в моём балалаечном случае, да и при многих других, надо идти так: посмотрел фрагмент, поставил на паузу, повторил несколько раз за автором, продолжил просмотр. Если что-то непонятно — отмотал назад, посмотрел повнимательнее. Но как это всё мотать, если руки заняты? Тем более, в моём случае они заняты пусть не огромным баяном, но всё-таки какой-никакой, а балалайкой. Значит, работать надо при помощи ног.

Нам предстоит сделать предпоследний шаг в практическом освоении работы с UDB. Сегодня мы будем вести разработку не при помощи автоматизированного UDB Editor, а в полуручном режиме, с использованием Datapath Config Tool. Очень хорошим подспорьем в освоении этого инструмента является документ AN82156 — PSoC 3, PSoC 4, and PSoC 5LP – Designing PSoC Creator Components with UDB Datapaths. Собственно, я сам учился по нему.

В статье, несмотря на то, что она, безусловно, чистый PR и рассказывает о нашем новом крутом (мнение автора) продукте, я постарался описать наш полезный опыт.

С какими проблемами сталкивались мы и наши клиенты при организации удаленной разработки ПО для устройств, как их решали, и откуда «растут ноги» у Redd, программно-аппаратного комплекса удаленной разработки ПО для встроенных систем. Почему появилась эта «коробка», и как изменится жизнь (опять же, мнение автора) миллионов разработчиков embedded-систем, устройств интернета вещей, оборудования для авто, самолётов, связи.

Reddit.com – это американская социальная сеть, которая может стать отличным источником трафика из США. Для того чтобы понять, каким образом это можно осуществить, стоит разобраться в особенностях платформы.

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

Представьте, программист без особых последствий может поиграться со своим локальным кодом, придумать любую архитектуру и переписать ее несколько раз, запустить на компиляцию непроверенный код и получить много ахтунгов от компилятора. То ли дело руководитель, который работает с людьми и не имеет права на ошибку. Он не может экспериментировать: попробовать один подход, забекапиться и откатиться в отношении с человеком обратно. Хотя некоторые менеджеры такие эксперименты постоянно выкидывают.

Последнее время ко мне часто обращаются начинающие тимлиды и руководители продуктов с вопросами: а что почитать на тему управления? что почитать на тему планирования? что почитать про управление рисками?

Я читал и читаю довольно много книг. Хорошие книги, которые мне понравилось, записываю, чтобы потом порекомендовать. Я решил сделать небольшую подборку must have книг, которые должен прочитать каждый начинающий руководитель. Одно из требований, чтобы эти книги были не только полезными, но и интересными. Книги должны заинтересовать человека развиваться в управлении, ни в коем случае не демотивировать.

В этой публикации попробуем разобраться, как живут foundry-компании не топ уровня. Так же попытаемся выяснить, могут ли российские компании попасть в это бизнес?

Немного истории: начало специализации

Первоначально компании, занимающиеся изготовлением полупроводников, были созданы в соответствие с моделью IDM (integrated device manufacture, на русском ближе по смыслу «комплексный производитель»). Это значит, что компания сама занимается разработкой, производством и продажей готовых изделий. Наиболее ярким примером успешной реализации IDM модели является компания Intel, основанная еще на заре становления микроэлектроники как отрасли.

Новость о подписанном 24 мая 2018 года в рамках Петербургского международного экономического форума мега-контракте всколыхнула волны моей памяти.
Даже на сайте компании «Ангстрем-Т» появилась эта новость.

И я решился написать все наболевшее и о проекте, и вообще…

Публикую последнюю статью из первого тома «Книги знаний» ОСРВ МАКС. Надеюсь, это неформальное руководство поможет вам, коллеги, в случае, если придется работать с этой RTOS.

Предыдущие статьи:
Часть 1. Общие сведения
Часть 2. Ядро ОСРВ МАКС
Часть 3. Структура простейшей программы
Часть 4. Полезная теория
Часть 5. Первое приложение
Часть 6. Средства синхронизации потоков
Часть 7. Средства обмена данными между задачами
Часть 8. Работа с прерываниями (настоящая статья)

Почему прерывания жизненно необходимы

Преподаватели информатики очень любят рассказывать о том, что существует работа по опросу, а также — по прерыванию, после чего обычно приводят небольшой примерчик обработки прерываний и забывают о теме. Дальше, при реальном программировании, приходится постигать основы этого дела не собственной шкуре.

При программировании в однозадачных системах, очень часто удаётся «выкрутиться» за счёт работы с оборудованием по опросу. В многозадачных системах это становится всё труднее.

Рассмотрим простейший пример. Пусть идёт приём из последовательного порта с ужасно низкой скоростью 9600 БОД. Реальные скорости давно находятся в районе 250 КБОД, но чтобы не возникало желания просто снизить скорость для решения проблемы, давайте рассмотрим именно сверхмедленный вариант.

К сожалению, при разработке реальных многопоточных приложений, невозможно просто написать код всех задач, подключить их к планировщику и просто запустить на исполнение.

Начнём с банальности — если задач много, то они начнут впустую тратить процессорное время на исполнение в холостых циклах. Как уже отмечалось в предыдущих публикациях, все задачи, которым в настоящий момент нечего делать (не пришли данные от аппаратуры или по прочим организационным причинам) должны быть заблокированы. На исполнение следует ставить только те задачи, которым сейчас есть что делать, так как процессорных тактов микроконтроллерам вечно не хватает.

Далее, задачи могут конфликтовать друг с другом за те или иные ресурсы (в частности, за оборудование). При рассмотрении типов многозадачности, мы уже рассматривали типовые случаи конфликтов за порт SPI (частично решаемое переходом на кооперативную многозадачность, но на неё перейти можно не всегда).

И самый страшный случай — зависимость задач. Часто результат работы одной задачи используется в другой. Из очевидных примеров, можно упомянуть следующие: бесполезно пересчитывать данные для выхода PID регулятора температуры, пока не получено и не усреднено достаточно данных с термодатчика, нет смысла менять воздействие на скорость двигателя, пока не получены сведения о текущем периоде его вращения, незачем обрабатывать строку символов с терминала, пока не получено терминирующего символа (признака конца строки). А кроме очевидных, есть масса неочевидных случаев зависимостей и порождаемых ими гонок. Иногда у начинающего разработчика больше времени уходит именно на борьбу с гонками, чем непосредственно на реализацию алгоритмов работы программы.

Во всех этих случаях, на помощь разработчику приходят синхронизирующие объекты. Давайте в текущей публикации рассмотрим, какие синхронизирующие объекты и функции имеются в ОСРВ МАКС.

Готова очередная публикация обзора особенностей ОСРВ МАКС. В предыдущей статье мы разбирались с теорией, а сегодня наступило время практики.

Часть 1. Общие сведения
Часть 2. Ядро ОСРВ МАКС
Часть 3. Структура простейшей программы
Часть 4. Полезная теория
Часть 5. Первое приложение (настоящая статья)
Часть 6. Средства синхронизации потоков
Часть 7. Средства обмена данными между задачами
Часть 8. Работа с прерываниями

При начале работы с контроллерами, принято мигать светодиодами. Я нарушу эту традицию.

Во-первых, это банально надоело. Во-вторых, светодиоды потребляют слишком большой ток. Не спешите думать, что я экономлю каждый милливатт, просто по ходу работ, нам эта экономия будет крайне важна. Опять же, то, что мы увидим ниже — на светодиодах увидеть практически невозможно.

Итак, пока нет генератора проектов, берём проект по-умолчанию для своей макетной платы и своего любимого компилятора (я взял

О чем?

В этой статье я расскажу о том, что предлагает нам компания Microsoft в своем Lync SDK для создания «красивых» интерфейсов и новых возможностей для Lync-клиента. Так же подробно остановлюсь на взаимодействии с Lync клиентом в UI Suppression mode, с которым нам очень плотно пришлось иметь дело в процессе разработки собственного корпоративного мессенджера на базе Skype for Business. И, самое главное, постараюсь подробно описать, с какими ограничениями нам пришлось столкнуться.

Мы продолжаем делать продукты на базе (и для) Skype for Business. Дело это непростое — приходится сталкиваться со множеством препятствий, которые нужно творчески преодолевать. Сегодня я расскажу о том, как шла разработка одного из наших самых последних приложений, откуда взялась идея и какие технологические задачи мы решили.

Идея

В нашей компании для коммуникации сотрудников в качестве корпоративной связи используется Lync сервер и Skype for Business клиенты. Они имеют свои достоинства и недостатки (например, проблемы с сохранением истории переписки), но сегодня не об этом.

У нас уже была идея создания собственного клиента на основе Lync SDK, который полностью бы заменил клиент Skype for Business. Мы потратили много времени и сил, создали свой мессенджер, который покрывает все неудобства и дополняет функционал Lync, но несколько «ШоуСтопперов» так и не смогли побороть. Также оптимизма не добавляло и немалое количество багов в самом Lync SDK.

У разработчиков прикладного ПО очень часто возникает потребность встроить в свой продукт некий скриптовый язык, который бы решал часть задач, не описанных детально на момент проектирования системы. Действительно удобно: и возможность расширения функциональности есть, и трудоёмкость создания такого решения, на первый взгляд, невелика.

Эту давнюю мечту можно было бы назвать «мечтой лентяя», если бы имеющиеся общедоступные встраиваемые скриптовые средства были бы просты. Готовые средства существовали давно, например на платформе Windows, ещё в прошлом веке можно было использовать интерфейсы VBScript и Jscript через COM-интерфейс IActiveScriptSite. В настоящее время существует большое количество и других решений, например на базе Lua, но все они имеют одну неприятную особенность, сильно ограничивающую желание их применять.

Скрипты прекрасно работают и сами по себе, на них можно выполнять и логику, и арифметику, но пользы от них ровным счётом никакой, если сложно или нет возможности:

• добавлять функции и объекты для доступа к объектам разрабатываемой системы,
• проводить синтаксический контроль исходного скрипта и генерировать сообщения о синтаксических ошибках,
• выполнять скрипт в пошаговом режиме, подобно отладчику, с нотификацией точки исполнения и статусом.

И ещё, хотелось бы, чтобы делалось всё это просто и интуитивно понятно и не приходилось бы проводить бессонные ночи за чтением многочисленной документации по новому API. Увы, это удаётся далеко не всегда и весьма нечасто.

Прикладное ПО сейчас очень часто пишется на C#, и хотелось бы иметь что-то знакомое, но гибкое, и позволяющее писать скрипты. Такое решение есть, и оно заслуживает пристального внимания. Это пространство имён

Мы уже рассмотрели способ создания встраиваемого скриптового движка на основе CodeDom.Compiler и класса CSharpCodeProvider. Поставим теперь более амбициозную задачу, где не будем полагаться на готовый компилятор. Будем писать свой собственный генератор, который строит MSIL-код «на лету» и исполняет его.

Для начала, попробуем сложить два числа и распечатать результат как бы на C#, но не пользуясь его языковыми конструкциями:

Раньше всё было лучше: компьютеры были большими, а буквы на экране — зелёными. Тогда они ещё назывались ЭВМ, а инженеры ходили по машинному залу в белых халатах. В те благословенные времена никто не заморачивался на тему user friendly-интерфейсов, а просто требовали от пользователя подготовить колоду перфокарт в соответствии с определённым форматом. Подготовил неверно — сам виноват. Это кажется не очень удобным и вовсе не «интуитивно понятным», но данный спартанский подход позволял обсчитывать весьма серьёзные задачи вроде моделирования ядерных реакций или расчёт полётного задания для космических ракет. И всё это при ресурсах, на два-три порядка меньших, чем почти любой современный смартфон.

Шло время, и перфокарты с магнитными барабанами канули в лету, в угоду пользователю стали доминировать программы с развитым GUI. Это стало подаваться как технический прогресс и забота об удобстве пользователе. А всегда ли это хорошо? А всегда ли это удобнее обычного текстового конфигурационного файла? Что-нибудь такое удобно воспринимать?

Здравствуйте!

Мной подготовлена серия статей, посвященных конкретной российской ОСРВ, одним из создателей которой я являюсь. Получилась своеобразная «Книга знаний», неформальное руководство для программиста, которое, надеюсь, поможет тем, кто эту ОСРВ использует.

Я расскажу об особенностях работы этой ОСРВ. Если о чём-то другом, то только потому, что без этого будут непонятны особенности.

Ниже я расскажу об особенностях ОСРВ вообще, и об особенностях ОСРВ МАКС в частности. Представлю ее архитектуру.

В дальнейшем я буду регулярно размещать новые публикации: вторая будет посвящена ядру системы, в последующих я представлю структуру простейшей программы, работающей под управлением ОСРВ МАКС с элементами кода, расскажу, как настроить ОСРВ МАКС для работы, затрону вопросы строгой типизации и драйверов.

Я продолжаю выкладывать главы «Книги знаний» ОСРВ МАКС. Первая часть была общей. Сегодня вторая часть, посвященная ядру и приоритету задач.

Содержание (опубликованные и неопубликованные статьи):

Часть 1. Общие сведения
Часть 2. Ядро ОСРВ МАКС (настоящая статья)
Часть 3. Структура простейшей программы
Часть 4. Полезная теория
Часть 5. Первое приложение
Часть 6. Средства синхронизации потоков
Часть 7. Средства обмена данными между задачами
Часть 8. Работа с прерываниями

Задача

Как уже упоминалось, задача в ОСРВ МАКС является аналогом потока в ОС общего назначения. Одновременно в системе может исполняться произвольное число задач (в рамках доступных ресурсов, разумеется). В ОС общего назначения на этом можно было бы прекратить теоретизировать и переходить к практике, но в случае с ОС реального времени программист должен быть уверен, что он сделал всё верно и задачи будут гарантированно получать столько процессорного времени, сколько им требуется. А чтобы всё сделать верно, необходимо знать кое-какую теорию. Поэтому рассмотрим работу задач более подробно.

Здравствуйте, коллеги! Готова очередная публикация из неформальной «Книги знаний» ОСРВ МАКС.

Просьба к постоянным читателям отнестись ко мне лояльно и не минусить за небольшое повторение части материала из предыдущей статьи (про защиту стека) — здесь оно оказалось логичней. А там я уже удалил.

Общее содержание (опубликованные и пока неопубликованные статьи):

Часть 1. Общие сведения
Часть 2. Ядро ОСРВ МАКС
Часть 3. Структура простейшей программы
Часть 4. Полезная теория (настоящая статья)
Часть 5. Первое приложение
Часть 6. Средства синхронизации потоков
Часть 7. Средства обмена данными между задачами
Часть 8. Работа с прерываниями

Некоторые неочевидные сведения о данных

Несколько фактов о куче

Многие программисты почему-то считают, что операции new и delete достаточно легковесны и просты. Поэтому код часто изобилует выделением и освобождением динамической памяти. Это более-менее приемлемо на мощных системах (гигабайты ОЗУ и гигагерцы тактовой частоты), но при ограниченных ресурсах может создавать некоторые проблемы, особенно для программ, работающих в режиме 24/7.

• Самая очевидная проблема —