Рубрика «программирование микроконтроллеров» - 92

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

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

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

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

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

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

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

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

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

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

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

Процессоры Intel Xeon оснастили FPGA Altera - 1Intel начинает поставки двухчиповой платформы для разработки, состоящей из процессора Xeon E5-2600 v4 (Broadwell) и FPGA Altera Arria 10 — такую информацию озвучила вице-президент Intel Diane Bryant в своей речи на конференции IDF 2016 в Китае. Предполагается, что с помощью подобного гибрида удастся получить 70% прирост производительности при том же энергопотреблении и частоте. Плоды сотрудничества Intel и Altera, которое продолжается далеко не первый год, мы уже видели в лице прототипа платформы 5G — там скрещивались FPGA и Intel Core. И вот теперь — новый дуэт. В планах на будущее — полная интеграция обоих компонентов на одном кристалле. Первыми потребителями гибрида станут крупнейшие облачные сервисы и дата-центры. По прогнозам Intel, к 2020 году до 30% серверов в дата-центрах будут иметь процессоры с FPGA.
Тут уместно упомянуть, что в прошлом году стартовал совместный проект компаний Intel и eASIC по созданию платформы Xeon + ASIC для кастомизации процессоров под конкретные предварительно оговоренные нагрузки. Воистину, больше Xeon'ов, хороших и разных!
Под катом — немного информации о FPGA Altera Arria 10.
Читать полностью »

В процессе работы над ОС Фантом, которая вообще не Юникс никаким местом, мне, тем не менее, захотелось сделать в нём Unix-compatible подсистему. Не то, чтобы прямо POSIX, но что-то достаточно близкое. Отчасти из любопытства, отчасти для удобства, отчасти как ещё один migration path. (Ну и вообще было интересно, насколько трудно написать простенький Юникс «из головы».) В качестве цели номер 1 была поставлена задача запустить quake 1 for Unix, которая и была достигнута.

В процессе, естественно, появились open/close/r/w/ioctl, и появилось ощущение, что последний неприлично, постыдно устарел. В качестве упражнения для размятия мозга я реализовал (в дополнение к обычному ioctl) некоторый альтернативный API, который бы позволил управлять свойствами устройств более гибким и удобным с точки зрения пользователя способом. Этот API, конечно, имеет свои очевидны минусы, и, в целом, эта статья — RFC, aka request For Comments.

Итак, API на уровне пользователя:

// returns name of property with sequential number nProperty, or error
errno_t listproperties( int fd, int nProperty, char *buf, int buflen );

errno_t getproperty( int fd, const char *pName, char *buf, int buflen );
errno_t setproperty( int fd, const char *pName, const char *pValue );

Правила:

  1. Никаких дефайнов с номерами, только имена.
  2. Никаких бинарных данных, только строки

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

Интернет вещей на реальном примере — система поиска автомобиля - 1

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

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

См. две другие статьи этой группы — Делаем многозадачность и Преемптивность: как отнять процессор.

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

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

Как я уже говорил, шедулер — это просто функция, которая отвечает на вопрос: какую нить и на сколько времени поставить на процессор.

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

Говоря о шедулере нельзя не сказать о приоритетах.

Приоритет — свойство нити (или процесса) влияющее на конкуренцию этой нити с другими нитями за процессор.

Приоритет обычно описывается парой <класс приоритета, значение приоритета внутри класса>.
Читать полностью »

Arduino

Введение

В предыдущей статье я только начинал работать с Arduino, в результате чего закономерно получилась метеостанция. В этой статье пойдём дальше — будем делать аутентификацию с помощью RFID карт и Arduino в приложении InterSystems Caché.
Читать полностью »

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

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

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

Но, как обычно, есть нюансы. См. код для интела.

Сам «отъём» процессора делается как в рамках обычного хардверного прерывания, обычно — по таймеру, так и в рамках «софтверного» прерывания — которое, собственно, такое же прерывание, но вызванное специальной инструкцией процессора. Такой способ переключения контекста нужен, если мы (например, в рамках примитива синхронизации) явно останавливаем нить и не хотим ждать, пока прилетит таймерное прерывание.
Читать полностью »

Я стараюсь чередовать статьи про разработку ОС вообще и специфические для ОС Фантом статьи. Эта статья — общего плана. Хотя, конечно, я буду давать примеры именно из кода Фантома.

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

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

Шедулер — это функция, которая отвечает на вопрос «какой нити отдать процессор прямо сейчас». Всё. Простейший шедулер просто перебирает все нити (но, конечно, готовые к исполнению, не остановленные) по кругу (RR алгоритм). Реальный шедулер учитывает приоритеты, поведение нити (интерактивные получают больше, чем вычислительные), аффинити (на каком процессоре нить работала в прошлый раз) и т.п., при этом умеет сочетать несколько классов приоритетов. Типично это класс реального времени (если есть хотя бы одна нить этого класса — работает она), класс разделения времени и класс idle (получает процессор только если два предыдущих класса пустые, то есть в них нет нитей, готовых к исполнению).

На сём пока про шедулер закончим.

Перейдём к собственно подсистеме, которая умеет отнять процессор у одной нити и отдать его другой.
Читать полностью »

Введение

Беспроводные сети ZigBee. Часть 1 [Вводная] - 1Сейчас о концепции IoT («интернета вещей») говорят везде. Появляется «умная» бытовая техника, которая может подключиться к сети (Bluetooth/Wi-Fi) по беспроводному интерфейсу и начать рассылать уведомления о том, что задача по стирке/готовке еды/кипячению воды завершена и неплохо бы что-то с этим сделать. Большинство таких «умных» устройств получает питание непосредственно из электросети. Но как быть, если хочется получать информацию от беспроводного термометра и при этом не менять батарейку каждую неделю? Или иметь беспроводной выключатель с небольшим аккумулятором для которого не понадобится штробить стены? И хорошо бы объединить такие устройства в единую распределенную сеть, которой можно управлять удаленно и которая сама, основываясь на показаниях датчиков/извещателей/счетчиков, могла бы принимать какие-то решения.

Специально для решения таких задач была создана беспроводная технология ZigBee, о которой мы и начнем разговор.

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

Британская компания, две американские компании и 18 университетов (включая российские МИЭТ, ИТМО, СГАУ, ННТУ) сотрудничали, чтобы выпустить современный курс по микроконтроллерам c небольшой привязкой к интернету вещей. Об этом – сегодняшний пресс-релиз Imagination Technologies, Microchip Technology и Digilent (отделения National Instruments). Главный автор — профессор Александр Дин из университета Северной Каролины. В отличие от более легковестных курсов интернета вещей, новый курс подводит под предмет твердую инженерную базу – в нем подробно обсуждается использование RTOS-ов, архитектура микропроцессорного ядра микроконтроллера, протоколы периферии и даже оптимизация алгоритмов при программировании.

07_Communications

Скачать курс можно здесь:

https://community.imgtec.com/university/resources/connected-microcontroller-lab/

В пресс-релизе, помимо цитат из США, Великобритании, Германии, Китая, есть и цитата из России:

“MIET is part of Imagination’s MIPSfpga and Connected MCU Lab beta-testing programs. Our students have benefited from the MIPSfpga hands-on workshops and we are looking forward to implementing the Connected MCU Lab at our university because this course offers an up-to-date and well-structured curriculum for teaching embedded solutions to future engineers.”

– Alexey Pereverzev, Head of Computer Engineering, National Research University of Electronic Technology (MIET), Russia

Пару десятков слайдов из курса, чтобы вы почувствовали его вкус:

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


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