В предыдущих статьях мы обсуждали функциональность ядра с точки зрения выполняемых задач и взаимодействия между ними. В этой статье мы рассмотрим, что еще может делать ядро, что в значительной степени проявляется в ряде других доступных вызовов API. Мы также ответим на вопрос, что превращает ядро в операционную систему?

Вся правда об ОСРВ. Статья #1.

Операционные системы реального времени: введение

Эта серия статей посвящена тщательному изучению всех аспектов операционных систем реального времени (ОСРВ). Статьи ориентированы на разработчиков, которым любопытно узнать, как работают ОСРВ и как ими пользоваться. Отправной точкой станет рассуждение о системах реального времени в общем, далее речь пойдет о том, как ОСРВ могут упростить их реализацию и сделать полученный код более надежным.

Заглянув во внутрь ОСРВ, мы посмотрим, как работает планировщик задач. Благодаря многопоточности создается впечатление, что ЦП выполняет несколько операций одновременно. Это не магия, понимание принципов работы планировщика задач доступно даже неопытному инженеру-программисту. Мы поговорим и о других объектах ОСРВ: о взаимодействии между задачами и синхронизации, о режиме реального времени, об управлении памятью и т. д., все будет точно описано и подкреплено примерами кода.

Информацию о состоянии окружающей среды или, например, некоторого объекта управления можно получать, измеряя текущие значения параметров, характеризующих те или иные свойства среды или объекта. Для получения, обработки и передачи такой информации техническими средствами, значение измеряемого параметра необходимо преобразовать автоматическими измерительными устройствами в сигнал измерительной информации. Для этого реализуют информационно-измерительный канал (ИИК), как совокупность технических средств, каждое из которых будет выполнять свою определённую функцию, начиная от восприятия измеряемой величины и заканчивая получением измерительной информации в форме, удобной для восприятия человеком или для дальнейшей её обработки. И всё бы хорошо, да вот по пути следования информации на полезный сигнал y(t) измерительной информации накладывается помеха e(t) – случайная функция времени, которая может моделировать и случайную погрешность измерительного преобразователя, и электрические наводки в соединительных проводах, и случайные пульсации измеряемого параметра, и другие факторы.

В Интернете найдется масса информации по ревью кода:

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

Да, конечно же, есть и книги на эту тему. Словом, в этой статье изложено, как ревью кода организован в компании Palantir. В тех организациях, чья культура не приемлет подобной коллегиальной оценки, возможно, полезно будет сначала ознакомиться с блестящим эссе Карла Уиджерса  (Karl E. Wiegers) «Ревью кода с человеческим лицом», а затем попытаться следовать этому руководству.

Этот текст взят из рекомендаций по повышению качества,  составленным на основе работы с Baseline, нашим инструментом для контроля качества кода на Java. В нем рассмотрены следующие темы:

•         Зачем, что и когда мы пытаемся достичь при ревью кода
  
•         Подготовка кода к ревью
  
•         Выполнение ревью кода
  
•         Примеры ревью кода
  

Переведено в Alconost

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

Мир, трассировка печатной платы, май. Потому что трассировка печатной платы — это труд. И эта статья открывает целый блок, цель которого дать правильные инструменты для этой задачи. В ней обосновывается важность контроля траектории возвратного тока и минимизации индуктивности контура тока критических сигнальных линий, а также даются рекомендации по их оптимальной трассировке.

Давайте возьмём пару от двух типов <YourType, bool> — что вы можете сделать с композицией подобного рода?

В этой статье я расскажу вам про std::optional — новый вспомогательный тип, добавленный в C++17. Это обёртка для вашего типа и флаг показывает, инициализировано ваше значение или нет. Давайте посмотрим, где это может быть полезно.

Вступление

Добавлением логических флагов к другим типам вы можете достичь то, что называется "Nullable типы". Как было сказано ранее, флаг используется для обозначения того, доступно значение или нет. Такая обёртка выразительно представляет объект, который может быть пустым (не через комментарии :).

Фраза звучит несколько странно? Спасибо техническому прогрессу — не так давно «сфотографировать на телефон» звучало не менее странно.


В конце прошлого года я купил паяльную станцию, уже успевшую получить ярлык «народная». Её достоинства: удобные жала-картриджи T12, приличная мощность (до 72W в теории), быстрый нагрев (единицы секунд), невысокая цена. (Подробнее ознакомиться со станцией можно в этом шикарном обзоре)

Купил я самую последнюю версию hardware 2.1s, и немного расстроился, увидев что прошивка старая. Разумеется руки зачесались обновить. Зная что «сердцем» паяльной станции является STM32F103C8 (популярный микропроцессор ARM Cortex-M3 производства STMicroelectronics) — тем интереснее было покопаться, т.к. я когда-то уже моргал светодиодом на STM32F4Discovery.

Тут же были припаяны 4 провода SWD интерфейса, подключен программатор, залита прошивка.
И… Станция потребовала активацию!

Стиль описания конечного автомата как образ мышления

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

Например, очень популярной является работа: Clifford E. Cummings, The Fundamentals of Efficient Synthesizable Finite State Machine Design using NC-Verilog and BuildGates. Всякий раз, когда специалисты решают обсудить, как правильно писать конечные автоматы, кто-то обязательно достает эту публикацию.

Статья стала настолько авторитетной, что многие даже не стараются анализировать аргументы автора. В частности, бытует мнение, что профессионалы всегда используют двухчастный способ описания конечных автоматов, имеется ввиду, описание конечных автоматов в 2 always блока. Это утверждение продолжает вызывать жаркие споры, и я хочу пояснить различия в описаниях конечного автомата с разным количество always блоков.

В беседах с коллегами я понял, что споры о том, как надо писать конечные автоматы в 1 или 2, 3 always блока, связаны с разным представлением (осознанием) реализуемого алгоритма, разным типом мышления. Попробую показать это на примере.

Я полагаю, что эта статья не первая статья о FSM и Verilog в вашей жизни, поэтому я не буду объяснять ни что такое конечный автомат, ни как он описывается на Verilog, а перейду сразу к делу.

Введение

Когда на IT-форумах задают вопрос «Быстрее ли язык программирования X языка Y», это обычно вызывает потоки эмоций и считается некорректным. Сродни вопросу про религию или предпочтение той или иной политической партии. Действительно, язык — это способ выражения мысли, идеи. В данном случае идеи программной системы. Он не быстр и не медлен. Он может быть более или менее лаконичным, более или менее точным. А скорость определяется не столько языком, сколько конечным кодом, который генерирует компилятор этого языка. Или скоростью интерпретатора в случае интерпретируемого языка.

Но это всё философия. А на практике обычно есть практическая задача разработки ПО. И, действительно, реализовать это ПО можно на десятке разных языков программирования. Поэтому, хоть это и «религиозный вопрос» в случае публичного обсуждения, вопрос этот часто возникает в голове IT-специалиста, стоящего перед конкретной задачей. «Сколько времени мне потребуется для реализации задачи на языке X и какие у полученного ПО будут характеристики, в том числе скоростные, по сравнению с реализацией этой задачи на языке Y». Понятное дело, точного ответа на этот вопрос нет, специалист опирается на свой личный опыт и отвечает как-то типа «с вероятностью 95%, написанная на ассемблере, эта задача будет работать быстрее, чем на php». Но, положа руку на сердце, опыт этот редко базируется на точных цифрах реальных задач, которые сам этот специалист реализовал. Нет, ну кто в здравом уме будет писать сложное ПО сначала на php, а потом его же переписывать на ассемблере, только чтобы измерить характеристики? В основном ограничиваются синтетическими тестами типа сортировки массива, построения и обхода бинарного дерева и тому подобных.

Всем привет! Зовут меня Дмитрий Григоров. Работаю фронтедером в Райффайзенбанке в команде RBO PRO. Я расскажу и покажу вам, как можно творчески применять данные возможности CSS. В статье мы рассмотрим следующие темы:

• Фоны и рамки;
• Фигуры;
• Визуальные эффекты.

В Playrix приходит много новых сотрудников и большинство из них не работали с Git. Особенно это касается гейм-дизайнеров и художников. Хотя и для программистов это не редкость – опыт работы с другими системами контроля версий не слишком помогает. Например, часто встречается опыт работы с SVN. Но Git заметно отличается по идеологии. Заучить, какие кнопки нажимать, в большинстве случаев не сложно, но шаг в сторону – и уже трудно понять, что происходит.



Поэтому мы решили написать ознакомительный материал. Мы поговорим о системе контроля версий и логике её работы, с самых азов. С Git можно работать с помощью  разных клиентов, потому в статье не пойдет речь об интерфейсе пользователя. Это может показаться непривычным, но это сделано намеренно. Вместо этого мы сфокусируемся на рабочем каталоге, коммитах, ветках, командах pull, push и прочих. Когда вы разберетесь в этих понятиях, вам останется выбрать один из Git-клиентов и освоить его интерфейс.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Код

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

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

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

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

Задача

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

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

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

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

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

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

Несколько недель назад я, развлечения ради, собрал простенькую роботизированную руку (а-ля манипулятор) и решил прикрутить к ней управление со смартфона через Bluetooth. Опыта в разработке нативных мобильных приложений у меня пока нет, с Apache Cordova я уже знаком, а вот задействовать Web Bluetooth API было бы интересно, приправив фишками Progressive Web Apps.


Картинка Для Привлечения Внимания, ведущая под кат

На первый взгляд может показаться, что статей по ключевым словам достаточно: есть спецификация Web Bluetooth, подробная статья в блоге Google Developers с примерами, есть подробный разбор Bluetooth Low Energy, примеры реверс-инжиниринга протоколов различных BLE устройств и даже моргания «умными» лампочками и получения данных от фитнес-браслетов прямо из браузера — что может пойти не так?

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

Назвал я её MakiseGui.