Рубрика «прерывание»

Идентификаторы задач (Task Identifiers)


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

Вся правда об ОСРВ от Колина Уоллса. Статья #4. Задачи, переключение контекста и прерывания - 1

Разработчики ОСРВ используют разные подходы к идентификации задач, но можно выделить четыре общие стратегии:

  • Задача идентифицируется с помощью указателя (pointer) на свой «блок управления» (“control block”). Указатели всегда уникальны, а также удобны в использовании, поскольку доступ к блоку управления требуется при многих вызовах API. Это подразумевает, что все данные о задаче хранятся в оперативной памяти (RAM), что может быть неэффективно. Указатель обычно занимает около 32 бит памяти.
  • Задача может быть определена с помощью произвольного «порядкового числа» (index number). Это значение может пригодиться при предоставлении доступа к записям в определенных таблицах. Такой идентификатор может занимать восемь или меньше бит памяти, в зависимости от ограничений по количеству задач, которые поддерживаются ОСРВ.
  • Некоторые ОСРВ разрешают только одну задачу на каждый уровень приоритета и, следовательно, используют приоритет для уникальной идентификации задачи. Это означает, что приоритет задачи не может быть изменен. Этот подход является разновидностью предыдущего подхода.
  • Задачи могут иметь имена, которые являются символьными строками (character string). Это может быть полезно для отладки, но вряд ли будет эффективным средством уникальной идентификации задачи. ОСРВ, которые поддерживают именование задач, как правило, имеют дополнительный идентификатор (например, указатель), который используется вызовами API и т. д. Для большинства встраиваемых систем текстовые имена — это накладные расходы; хороший отладчик позволяет называть их локально на хосте.

Читать полностью »

Продолжаем цикл про основы работы STM32MXCube и программированию микроконтроллеров STM32.
Часть 1.
Часть 2.
Начинаем работать в STM32CubeMX. Часть 3 - 1
В прошлых частях мы освоили базовые настройки микроконтроллера, работу с GPIO, таймером, DMA и DAC. В этой части мы познакомимся с ADC и USB.

Читать полностью »

В прошлый раз мы научились создавать в STM32CubeMX новый проект, настраивать тактовый генератор, таймер и порт ввода-вывода, и немного помигали светодиодом. Сегодня мы освоим цифро-аналоговый преобразователь и научимся работать с ним через DMA. В результате у нас должен получиться простой генератор прямого синтеза (Direct digital synthesizer, DDS).
Начинаем работать в STM32CubeMX. Часть 2 - 1
Читать полностью »

Приветствую аудиторию хабра, и хочу предложить вашему вниманию первый пост, посвященный использованию среды разработки STM32CubeMX, написанный для тех, кто хочет начать изучение STM32 «с нуля».

Начинаем работать в STM32CubeMX. Часть 1 - 1

Я планировал написать несколько постов, рассмотрев несколько периферийных устройств микроконтроллера и их конфигурирование в STM32CubeMX. Но эти посты не заменяют фирменной документации и не претендуют на полноту. В них будут рассмотрены только некоторые, наиболее, на мой взгляд, типичные, примеры использования периферии STM32.
Надеюсь, кому-то этот материал будет полезен.
Читать полностью »

Умное мигание светодиодом в Ардуино - 1

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

Бывает при программирование какого-нибудь устройства не хватает портов ввода-вывода микроконтроллера. Или из экономических соображений, а может нехватки места в корпусе, не хочется устанавливать дисплей, а как то сигнализировать о режимах работы устройства очень хотелось бы. Часто достаточно сигнализировать о этих режимах горением или миганием светодиода. А если режимов много?
Читать полностью »

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

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

Если когда-нибудь вы задумывались над тем, что значат слова «the processor supports precise aborts» в даташите, прошу под кат.
Читать полностью »

Пишу игрушечную ОС (доступнее о планировщике)
Отсутствие комментариев к двум моим предыдущим постам, несмотря на большое число лайков, привели меня к выводу, что подавляющее большинство ничего не поняли. Просто, будучи давно погружённым в тему, я проявил невнимательность к своему читателю. Моя вина, буду исправляться. Итак, поговорим о планировании доступным языком.

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

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

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

Пишу игрушечную ОС (о планировщике)
Продолжаю вести блог о разработке игрушечной ОС.

В прошлом посте я писал о том, как добиться возможности реализовывать на C обработчики прерываний. Теперь, пользуясь написанными ранее макросами, можно реализовать простой SMP-планировщик. Он будет предоставлять минимально возможный функционал, на базе которого в будущем нужно будет возводить различные надстройки, в частности, примитивы синхронизации (например, мьютекс). Опять же, красивая модульная структура не способствует высокой производительности, но красота, как известно, спасёт мир, так что отдадим ей предпочтение.

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

Кроме того, было бы здорово, если бы планировщик не занимался выделением памяти, а мог принимать и возвращать память, выделенную под поток кем-то другим. С одной стороны, это бы обеспечило гибкость произвольного кеширования памяти потоков. С другой – дало бы уникальную возможность сохранять поток во внешней памяти (например, на жёстком диске) с последующей его загрузкой и запуском с прерванного места.
Читать полностью »