OSDev

После некоторой работы с этой архитектурой появились вопросы, ответы на которые что-то я не смог отыскать (если плохо искал - ткните носом )
Особенно сейчас интересует следующее: насколько я понял, запросы внешних прерываний (с номером больше 15) приходят в NVIC и уже там разруливаются их приоритеты, остальные запросы приходят непосредственно в ядро процессора. Так вот вопрос в том, кто решает окончательно, обработчик какого из прерываний будет запущен первым (при одновременном их возникновении конечно) - ядро или NVIC?
Например, есть запрос прерывания от SysTick с некоторым приоритетом и запрос внешнего прерывания с приоритетом выше чем у SysTick. Как работает подсистема прерываний процессора при одновременном их возникновении?

Всё описано в документации на архитектуру. Правда, написана она быдлоиндусами на быдлоиндусском варианте английского языка, т.е. откровенно погано; некоторые вещи невозможно понять, не анализируя тамошний быдлопсевдокод, разбросанный по всему документу. Конкретно обработку прерываний для М-профиля (как и для А/Р) я описал на Вике.

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

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

Согласен на 99%, просто в их же документации NVIC настолько связан с ядром, что иногда не до конца понятно, что делает NVIC, а что - ядро.

Он связан лишь в том смысле, что любое ядро серии Cortex-M имеет в комплекте и NVIC, и (вроде бы) SysTick. Однако логически процессорное ядро и контроллер прерываний -- разные вещи. Здесь их "связанность" противопоставляется ситуации, имевшей место с предыдущими версиями архитектуры, когда каждый производитель пихал в комплекте с процессором такой контроллер прерываний, какой сочтёт нужным. Иногда даже у одного и того же производителя в разных семействах использовались разные контроллеры (например, у NXP в сериях LPC22xx и LPC24xx контроллеры прерываний называются VIC, но между собой они не совместимы программно). То же касается и таймеров: иногда фирмы-производители предусматривали специальный таймер именно для нужд ОС (PIT в МК фирмы Atmel), но в большинстве случаев его не было, и для отсчёта времени в системе использовалось прерывание от какого-либо из обычных "внешних" таймеров (так, например, у всех МК NXP, с которыми хоть как-то сталкивался). Вот ARM и решила при выпуске 7-й версии архитектуры стандартизировать это дело.

Да, для меня было приятной новостью узнать, что есть стандартный таймер, который можно найти в любом МК семейства Cortex-M3, а не выяснять каждый раз, что да как. с LPC24xx начал работать, но потом было принято решение перейти на новую их серию LPC178x, тем более они pin-to-pin. Чувствую, я теперь с этой архитектурой связан надолго вот и хочу разобраться в неё хорошенько!

У меня по работе тоже LPC1788 (начинал на 2478). Ось, соответственно, поддерживается именно под него (ну и под 24хх на пару -- код самой системы почти полностью совпадает, драйверов -- тоже в приличной степени), хотя может работать на любом арме с подходящими ресурсами -- надо лишь несколько макросов написать и нужные дрова.

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

Ось я разрабатываю для удовольствия Решить стоящие передо мной задачи я мог бы и вообще без системы, но если у меня есть нечто относительно рабочее, то почему бы не использовать, совместив приятное с полезным?

Ну а кроме удовольствия, разрабатываю ещё и потому, что вокруг имеются либо недосистемы вроде FreeRTOS, RTX и т.д. (я бы постыдился такое назвать осью), либо монстры -- Windows CE, Linux (в т.ч. её кастрированный вариант ucLinux) и т.д. Я фактически стараюсь сделать систему (точней, её ядро + некий минимум других компонентов, поскольку всё в одиночку не охватишь), которая сочетала бы компактность и высокую скорость с одной стороны с развитым эффективным API, поддержкой всяких там Plug&Play и прочего с другой. Т.е. моя система в идеале (до коего примерно как до луны) -- это не тупая переключалка потоков с минимальным набором сервисов синхронизации и обмена сообщениями, каковой, по сути, является та же FreeRTOS, а полноценная система с нормальной драйверной моделью, поддержкой многозадачности, квотирования ресурсов, многопользовательской защитой и т.д. и т.п. Естественно, в конкретный вариант системы включаются не все её возможности, а необходимые (и только те, которые могут поддерживаться на данной аппаратуре: для процессоров М-профиля, например, виртуальная память исключена, поскольку они не имеют MMU).

Да, вменяемая ось под МК - это было бы здорово! Я когда начал работать с LPC1788, начинал с платки от starterkit: http://www.starterkit.ru/html/index.php ... view&id=66. В конце концов мне удалось собрать под неё u-boot и ucLinux (хотелось посмотреть взлетит или нет). Но время загрузки линуха - это ужас. Да и память жрет. короче попробовал и понял что если и ставить линух то только на что-то помощнее, навроде ARM11 с MMU (чтобы полноценная ось была) или Cortex из серии -R или -A.

Вот это слово "относительно" и пугает (сам как-то пытался сваять что-то свое, правда не под ARM). Что вы скажете вообще по части надежности систем с ОСью по сравнению с построенными просто на прерываниях? Если рассматривать добавление ОСи как еще одной компоненты системы, усложняющей её, то по идее надежность будет падать (понятно, что и без оси можно такого понаписать...). В системах с MMU с этим чуток полегче наверное - можно процессы изолировать.

Аналогично. Сначала была на 2478 -- просто пощупать, потом на 1788 -- чтоб быстро начать практическую разработку. Затем уже свою плату сделали, поскольку у Стартеркита совершенно безбашенная разводка по разъёмам (например, сигналы SPI раскиданы по трём разъёмам, а общение с АЦП сенсорного экрана идёт путём программного ногодрыга, поскольку развести на него обычный SPI им религия не позволила).



Даже не пытался. Более того, Linux не рассматривался в принципе: система с откровенно ущербным API мне не нужна абсолютно. Если уж ставить унихоподобное, то QNX (и надёжная, и ОСРВ) -- да только она требует MMU, не говоря о том, что для коммерческого использования надо платить.



Ошибок, как известно, не содержит лишь абсолютно бесполезная программа

На самом деле, "относительная работоспособность" означает лишь то, что сама система находится в процессе разработки, а значит, во-первых, реализован далеко не весь функционал, который будет когда-нибудь (надеюсь) реализован, а во-вторых, всякие прибавки требуют отладки, а значит, нельзя дать гарантию полной работоспособности для любого случая. Естественно, если выползает какой-либо глюк, я его исправляю, а не откладываю на потом и не объявляю фичей



Ошибок где угодно и сколько угодно можно понаделать. У меня ошибки в основном были в "прикладном" по своей сути коде (даже если это драйвер режима ядра, обслуживающий специфичное для моей задачи железо), а не в самой системе.

Сейчас вот спихну очередной кусок работы, чтоб освободилось времени более-менее достаточно, в очередной раз доработаю драйверную модель и перенесу систему на многоядерный Cortex-A: надо ж отлаживать поддержку многопроцессорности, и чем раньше, тем лучше (поскольку там полно тонких моментов, связанных с внутриядерной синхронизацией). Естественно, поддержка 1788 никуда не денется: просто под него система будет собираться в однопроцессорном варианте.

Если интересно, документацию веду на http://wiki.armada-os.org. Она пишется урывками, но всё уже реализованное в части пользовательского API задокументировано. Частично документация написана "вперёд", отчасти отстаёт от реальной разработки (это касается главным образом описания внутренней реализации тех или иных механизмов: поскольку пишу один, вся "внутренняя" документация у меня есть в виде записок сумасшедшего на бумаге, ну а в Вику переношу лишь то, что более-менее устоялось).