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

image

Никогда не сдавайтесь

Действительно ли Билл Гейтс произнёс фразу «640 КБ должно хватить всем»? Её история довольно туманна, однако чаще всего её приписывают Биллу, так что, возможно, он действительно такое говорил.

Его довольно часто за это высмеивали. Мысль о общем пространстве памяти размером всего 640 КБ по современным стандартам смехотворна. В этот размер не уместится даже исполняемые файлы большинства программ-установщиков.

Для сравнения: калькулятор в Windows 10 занимает в состоянии простоя 16,2 МБ оперативной памяти — почти в 26 раз больше, чем объём доступной DOS-программам памяти в 1980-х.

Странные дела

Поверите ли вы мне, если я скажу, что до сих пор существует активное сообщество, использующее эту устаревшую платформу и разрабатывающее для неё ПО?

Наверно, вашим первым вопросом будет «Но зачем?» И я хорошо вас понимаю. Давайте рассмотрим некоторые группы, которые до сих пор заинтересованы во вложениях усилий в DOS.
Читать полностью »

Опять вернёмся в традиционную область разработки операционных систем (и приложений для микроконтроллеров) — написание драйверов.

Я попробую выделить некоторые общие правила и каноны в этой области. Как всегда — на примере Фантома.

Драйвер — функциональная компонента ОС, ответственная за отношения с определённым подмножеством аппаратуры компьютера.

С лёгкой руки того же Юникса драйвера делятся на блочные и байт-ориентированные. В былые времена классическими примерами были драйвер диска (операции — записать и прочитать сектор диска) и драйвер дисплея (прочитать и записать символ).

В современной реальности, конечно, всё сложнее. Драйвер — типичный инстанс-объект класса, и классов этих до фига и больше. В принципе, интерфейс драйверов пытаются как-то ужать в прокрустово ложе модели read/write, но это самообман. У драйвера сетевой карты есть метод «прочитать MAC-адрес карты» (который, конечно, можно реализовать через properties), а у драйвера USB — целая пачка USB-специфичных операций. Ещё веселее у графических драйверов — какой-нибудь bitblt( startx, starty, destx, desty, xsize, ysize, operation ) — обычное дело.

Цикл жизни драйвера, в целом, может быть описан так:

  • Инициализация: драйвер получает ресурсы (но не доступ к своей аппаратуре)
  • Поиск аппаратуры: драйвер получает от ядра или находит сам свои аппаратные ресурсы
  • Активация — драйвер начинает работу
  • Появление/пропадание устройств, если это уместно. См. тот же USB.
  • Засыпание/просыпание аппаратуры, если это уместно. В контроллерах часто неиспользуемая аппаратура выключается для экономии.
  • Деактивация драйвера — обслуживание запросов прекращается
  • Выгрузка драйвера — освобождаются все ресурсы ядра, драйвер не существует.

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

Мне известны три модели построения драйвера:

  • Поллинг
  • Прерывания
  • Нити (threads)

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

Сегодня мы поговорим о прерываниях процессоров семейства x86 (-64). Подробнее под катом.Читать полностью »

Сегодня я расскажу, как можно динамически подменять обработчики прерываний в процессорах ARM на примере микроконтроллеров STM32. Описанный мною способ работает в процессорах ARM Cortex M3 и выше.

Когда и где это может понадобиться? Во-первых, подменять обработчики прерываний можно если перед вами стоит задача написания программы, совместимой с разными аппаратными платформами. В процессорах ARM есть несколько прерываний ядра, которые обязательны для любой реализации архитектуры. Но оставшиеся прерывания предназначены для периферии, и производители процессоров вольны устанавливать эти векторы для любых периферийных устройств, имеющихся в процессоре. Это требует динамически подставлять нужные обработчики прерываний для каждой реализации архитектуры. Во-вторых, если к вашему продукту предъявляются повышенные требования к скорости реакции на внешние события, иногда выбор нужного действия внутри обработчика прерывания оказывается неэффективным, и будет выгоднее изменять вектор прерывания динамически.
Читать полностью »

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

ATtiny85: прототип беспроводного сенсора - 1

Цель — создать сенсор работающий, условно говоря, в коробке с искусственным освещением и передающий температуру и статус освещения с немедленной реакцией на изменение освещения: включилось, отключилось, мигнуло. Сенсор решено было сделать мобильным и питать от элемента CR2032, иначе говоря, при разряде до 2.7V (предел для датчика TMP36), можно рассчитывать на 200mAh.

Микроконтроллер ATtiny85 имеет всего 5 портов ввода/вывода и возможность отключить RESET в пользу дополнительного порта. Данный бюджет был распределён следующим образом:

  • 3 порта — радиомодуль NRF24L01+, спецификация требует пять портов, но в данном случае это не приемлемо и будет использована 3-х пиновая конфигурация;
  • 1 порт — датчик освещения на базе фототранзистора BPW17N;
  • 2 порта — температурный датчик на базе TMP36, второй порт нужен для подачи питания, чтобы иметь возможность отключать датчик при необходимости.

Элементная база определена, можно приступать к проектированию.

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

ARM ы для самых маленьких: компоновка 2, прерывания и hello world!

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

  • рассматриваем «сложный» сценарий компоновки GNU ld;
  • учимся использовать прерывания;
  • наконец добираемся до hello world!

Предыдущие статьи цикла:

Примеры кода из статьи: https://github.com/farcaller/arm-demos

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

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

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

Общая задумка (пока весьма далёкая от реализации) следующая: единое 64-битное адресное пространство с вечно живущими нитями (как у Phantom OS); виртуальная машина, обеспечивающая безопасность исполнения кода. На данный момент реализованы:

1. загрузка ядра при помощи multiboot-загрузчика (GRUB);
2. текстовый VGA-режим (16-цветов, kprintf);
3. простой интерфейс настройки отображения страниц;
4. возможность обработки прерываний на C;
5. идентификация топологии процессоров (сокеты, ядра, потоки) и их запуск;
6. работающий прототип SMP-планировщика с поддержкой приоритетов;

Пропустим описание multiboot-загрузки и работы с VGA-режимом (об этом не писал, разве что, ленивый). Про отображение страниц тоже не хочу писать, боюсь это будет скучно (может, в другой раз). Давайте лучше поговорим об обработке прерываний.
Читать полностью »

Как это было?

Когда у меня возникло желание вести разработку под Arduino, я столкнулся с несколькими проблемами:

  • Выбор модели из списка доступных
  • Попытки понять, чего мне понадобится кроме самой платформы
  • Установка и настройка среды разработки
  • Поиск и разбор тестовых примеров
  • «Разборки» с экраном
  • «Разборки» с процессором

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

Выбор платформы

Перед началом программирования под железяку требуется в начале ее купить. И тут я столкнулся с первой проблемой: оказалось, что разных *дуин довольно много. Тут есть и широкая линейка Arduino и примерно такая же широкая Freeduino и другие аналоги. Как оказалось, большой разницы, что именно брать, нет. То есть одни из этих устройств чуть быстрее, другие чуть медленнее, одни дешевле, другие — дороже, но основные принципы работы практически не отличаются. Отличия появляются практически только при работе с регистрами процессора и то я далее объясню, как по возможности избежать проблем.
Читать полностью »