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

Утраченный потенциал подсистемы Windows для Linux (WSL) - 1

Если вы несколько лет вообще не следили за Windows 10 и не знаете, что происходит, то пропустили одну вещь — очень горячей темой для разработчиков стала подсистема Windows для Linux, она же WSL. Среди программистов очень часто её обсуждают. Действительно, потрясающе интересная штука.

Наконец-то у нас появилась возможность запустить свой инструментарий Linux на Windows наравне с виндовыми программами. А это значит, что больше не нужно изучать странный PowerShell или пользоваться архаичной консолью CMD.EXE.

К сожалению, не всё так радужно. WSL по-прежнему является неким инородным элементом, который отделён от родной среды Windows. В частности, не может взаимодействовать с «родными» инструментами Windows.
Читать полностью »

Отлаживаем сетевые задержки в Kubernetes - 1

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

По сути, в приложениях происходит будто случайная сетевая задержка до 100 мс и более, что приводит к тайм-аутам или повторным попыткам. Ожидалось, что службы смогут отвечать на запросы гораздо быстрее 100 мс. Но это невозможно, если само соединение отнимает столько времени. Отдельно мы наблюдали очень быстрые запросы MySQL, которые должны были занимать миллисекунды, и MySQL действительно справлялась за миллисекунды, но с точки зрения запрашивающего приложения ответ занимал 100 мс или больше.
Читать полностью »

Современные микроконтроллеры имеют достаточно большую производительность и это дает многим программистом возможность думать в примерно следующем ключе: — «Ничего страшного, если 1-5% производительности уйдут на обслуживание операционной системы. Зато мой код будет легко отлаживаемый и явный!». Эти мысли подкрепляются большим количеством энергонезависимой (flash) памяти для хранения кода операционной системы и оперативной (RAM/SRAM) памяти для выделения под каждую задачу своего стека. Однако в большинстве случаев эта мысль ошибочна. И в данной статье я расскажу, почему.Читать полностью »

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


https://ajax.googleapis.com/ajax/libs/jquery/3.4.1/jquery.min.js