И ведь они совершенно правы

не так давно в России кто-то запатентовал "бутылку стеклянную" ... и был бы "прав" до сих пор, если бы автора не занесло потребовать от пивных компаний отчислений за использование его изобретения. Тут его патент и кансельнули...

Сообщение отредактировал kikos - May 25 2011, 07:15

Вы об этом ?
http://electronix.ru/forum/index.php?showtopic=69735

только я не понял какое отношение патенты имеют к типу обработки прерываний в ОС

Несколько замечаний из собственного опытов:
1) На Cortex-M3 (Luminary) я использовал Keil-овскую RTOS "RTL"; 2) на DSP TMS320VC5509a - техасовскую DSP/BIOS.

В первом случае: a)keil декларирирует, что RTL не запрещает прерываний, что хотите, то и делайте. б) RTL предоставляет ряд механизмов: семафоров, "сигналы" (ихнее собственное понятие), с помощью которых ISR может взаимодействовать с шедьюлером RTOS.
Можно использовать как UIA так и SIA - архитектуры. Я пользовался как тем так и другим. Но официально KEIL рекомендует пользоваться SIA-подходом. Они говорят, что "у нас есть замечательный механизм сигналов; вы пишете ISR, который просто выставляет сигнал, а какая-то высокоприоритетная задача его ожидает и отрабатывает действие, в этом случае не необходимости иметь высокоприоритетные/низкоприоритетные прерывания - так как ISR выполняют только установку бита сигнала, который ловится "фактическим обработчиком прерывания" - задачей, которая ожидает этот сигнал. И этот фактический обработчик прерывания - он уже имеет приоритет". Это - они говорят - наиболее правильный подход. Т.е. SIA в чистом виде. Этим способом я пользовался. Т.е. ISR-обрабочик SPI у меня просто устанавливал сигнал, и дальше высокприоритетная легковесная задача "делала своё дело". Передача сигнала операционкой RTL делается очень быстро. (Можно посмотреть спецификации этой RTOS - они есть в документации - я на вскидку здесь их не приведу). Второй вариант: ISR обработки SPI при приёме данных может формировать небольшой массив из байт (например 32 байта) и по готовности массива отправить сигнал в высокоприоритетную задачу-обработчик, которая берёт этот массив и кдадёт его в почтовый ящик для следующей по ходу задачи. То есть ISR уже не тупая, а более "интеллектуальная". Т.е. возможны гибкие решения. И главное, что всё работает быстро.

Во втором случае DSP/BIOS - мощная RTOS, (кейловская RTL - это малютка по сравнению с ней). а) DSP/BIOS может по своему усмотрению запрещать прервания.
б)даёт ряд механизмов, из которых ISR может взаимодействовать с операционкой - в частности: семафоры (которые могут ожидаться задачами с определёнными приоритетами); вызовы программных прерываний SWI - software interrupts; выделение памяти из специальных memory pool-ов и отправка их в "очереди" или "почтовые ящики" (это стандартные "системные" объекты RTOS) - тут обилие всяческих вариантов. Т.е. можно с легкостью построить как SIA так и UIA - модель. в)Есть также изумительная абстракция драйвера. Кто-то со стороны может написать определённым образом "оформленный" модуль - "драйвер", и вы можете его подключить к своей программе и общаться с устройством на уровне "пакетов". Послал пакет/получил пакет. И всё. Но по сути тут вот что: вы из контекста задачи кладёте в некую "скрытую", организованную на memory pool-е, очередь и из контекста вашей задачи запускаете устройство в работу (например SPI или McBSP). Прерывание (ISR) этого устройства из контекста прерывания разгребает эту очередь (т.е., например отправляет все её пакеты). Если очередь переполнена (вы пытаетесь положить больше пакетов, чем позволяет её максим. длина), то ваша задача "засыпает", и проснётся только после того, когда такая возможность появится. Это порисходит всё внутри RTOS, а вы пользуетесь примитивным стандартным вызовом функции драйвера - "отправить очередной пакет".

Мой лично вывод - RTOS должна позволять и то и это (и SIA и UIA). А если нет, то что-то тут не так. (Но те RTOS, что я юзал - коммерческие, и очень толково сделаны).

Может быть "RTX" имелся ввиду?
Когда они пишут что не запрещают прерывания - то лукавят, конкретно в порту для CM3 используется исключение SVC. Ессно, при вызове обработчика инструкцией SVC приоритет прерываний снижается до фактического запрета. Да, очереди событий они сделали прикольные, но - жрут память, и беспомощны перед переполнением. Я точно не помню, но там кажется только один единственный сервис может быть вызван из ISR - "положить событие в очередь".


Нет, насколько я понял RTX не поддерживает SIA в понимании данного топика.


Это стандартная практика, я много лет пользуюсь ей в TNKernel, но к SIA это не имеет никакого отношения, ИМХО.


Это все есть (кроме SWI который есть не на всякой архитектуре и вообще особо не нужен, и даже вреден если Вы пишете мультиплатформенный софт) и в TNKernel, которая ни разу не SIA.


И это есть в TNKernel


Ага, TNKernel тоже... ну - Вы поняли , за исключением того что она свободная, и даже свободней чем, скажем, софт под GPL

Да, точное название RL-RTX.

Я режим SVC отключал сразу еще до запуска RTX, так как у меня сразу выбрасывалось исключение (не помню точно что, но что-то типа "в режиме пользователя что-то где-то запрещено"). Сейчас я уже не вспомню, почему отказался от преимуществ использования SVC, тогда он меня сильно напрягал.

Я так понял, что SIA (по статье http://www.rtos.com/articles/18835) - это возможность обработки критических секций вне ISR. Так это как раз то о чём я и говорю: прерывание только генерирует сигнал ( isr_evt_set(...) ), задача-обработчик (типа "ISR2" в контексте упомянутой статьи) - получает управление, обрабатывает данные в критических секциях - используя mutex-ы или замки на ресурсы - и вот вам и решение - никакие прерывания запрещать в теле самой ISR не надо - она только генерирует сигнал. И никакие прирывания в задаче-обработчике запрещать не надо - она пользуется mutex-ами, замками и прочей стандартной байдой для защиты критических секций данных. Чем не SIA? Или я что-то не догоняю?

SWI - в DSP/BIOS - крайне удобная вещь. Это нечто промежуточное между стандартным "аппаратным прерыванием" и "задачей". Очень выгодно использовать, чтобы сделать аппаратное прерывание - действительно лёгким. Аппаратное прерывание выполняет своё элементарное действие и перед возвратом вызывает SWI - программное прерывание, которое, в свою очередь, запустится, как только все аппаратные прерывания отработаются. Этот как раз именно то самое "ISR2" в вышеупомянутой статье.

В RL-RTX нет очереди событий - это битовая маска. Событие - это установить бит - как семафор, только быстрее.
Кроме этого из прерываний можно:отправлять и получать данные в почтовый ящик (это то, что Вы, наверное, имели в виду), устанавливать семафор, и определить идентификатор задачи, которую это прерывание прервало.

Я думаю вы не поняли. ISR2 по идеологии сегментированных прерываний не может быть обычной задачей.
Т.е. должна иметь отличную от задач управляющую структуру. Чтобы ISR2 не могла быть идентифицирована как задача, и чтобы ее не могли приостановить, прервать, удалить, понизить приоритет другие обычные задачи.
В Keil-е нет настоящей модели SIA, там есть только задачи и обычные ISR.

Как фича ISR2 появляется только в сравнении с Keil-oм толстых осях. Где реально крутятся многие десятки задач. О некоторых из которых вы даже не подозреваете ибо они не вами написаны. И вам нужен надежный механизм разруливания проблем ограниченного процессорного времени.

Думаю в DSP/BIOS подобия ISR2 также нет, (поправьте если ошибаюсь), поскольку DSP от TI не выполняют роль процессоров приложений с кучей функциональности им там для этого всегда ARM в подмогу дают

Извините, это была опечатка, я имел ввиду обработчик исключения SuperVisorCall - вызывается инструкцией SWI. Когда эта инструкция обрабатывается, то прерывания с более низким приоритетом чем у нее - запрещаются. То есть - явного запрета прерываний нет, а вот неявный - есть.


Это не SIA в терминах данного топика. Вот если бы там был аналог DPC для Windows или BottomHalf для Линукса, и для них был выделен особый уровень приоритета (DISPATCH_LEVEL) - НАД всеми задачами, и подобие очереди - вот это точно SIA.


Она может быть очень удобной и приятной, более того - иногда без нее не обойтись - это единственный способ красиво выйти из непривилегированного режима, например. Но если вдруг понадобится портануться на процессор без SWI - чего тогда делать?


Мне кажется что там очередь есть, посмотрите что isr_evt_set делает и как. Более того - очерель/циклический буфер - это одна из немногих (если вообще не единственная) структур которая позволяет обмениваться данными без взаимной блокировки. Иначе Кейл не смог бы рассказывать нам как он не запрещает прерывания.

Покажите пожалуйста пример такой очереди.

http://www.research.ibm.com/people/m/michael/podc-1996.pdf

Хе-хе, в Keil-е показать не получится. Там используются специальные инструкции эксклюзивного доступа, которые есть у Cortex-M3.
А так Keil для других архитектур использует все те же запрещения прерываний для своих кольцевых буферов.

Присмотрелся, однако, к этой фишке Keil-а с командами эксклюзивного доступа и вижу, что это решение довольно рискованное.
В инструкции на ARMv7-M много связанного с поведением эксклюзивного доступа оставлено на имплементацию, а скажем в доке на тот же STM32 полная тишина про нюансы имплементации эксклюзивного доступа.

Спасибо

Псевдокод из статьи

dequeue(Q: pointer to queue t, pvalue: pointer to data type): boolean
D1: loop # Keep trying until Dequeue is done
D2: head = Q–>Head # Read Head
D3: tail = Q–>Tail # Read Tail
D4: next = head–>next # Read Head.ptr–>next
D5: if head == Q–>Head # Are head, tail, and next consistent?
D6: if head.ptr == tail.ptr # Is queue empty or Tail falling behind?
D7: if next.ptr == NULL # Is queue empty?
D8: return FALSE # Queue is empty, couldn’t dequeue
D9: endif
D10: CAS(&Q–>Tail, tail, <next.ptr, tail.count+1>) # Tail is falling behind. Try to advance it
D11: else # No need to deal with Tail
# Read value before CAS, otherwise another dequeue might free the next node
D12: *pvalue = next.ptr–>value
D13: if CAS(&Q–>Head, head, <next.ptr, head.count+1>) # Try to swing Head to the next node
D14: break # Dequeue is done. Exit loop
D15: endif
D16: endif
D17: endif
D18: endloop
D19: free(head.ptr) # It is safe now to free the old dummy node
D20: return TRUE # Queue was not empty, dequeue succeeded

------------------------
А ну как перед
D19: free(head.ptr) # It is safe now to free the old dummy node
управление передадут какому-нибудь злодею, который сделает head.ptr не валидным( вычистит, а потом положит по этому адресу совсем не то что ожидалось) , а потом обратно ?






Сообщение отредактировал kikos - May 30 2011, 08:49

Я понимаю, что я немного не в тему, но всё равно, раз уж влез, то продолжаю:

Я не вижу, зачем нужны такие навороты для CM3. Это слабый процессор и, я считаю, совсем не предназначен для таких наворотов. А что качается самой идеи сегментированного прерывания - то она легко организуется как указано выше - на высоко-приоритетной задаче. Программист сам всегда знает, для чего какая задача у него предназначена. Он выделяет задачу, назначает ей высокий приоритет, и сам организует "механизм" сегментированного прерывания - то что keil'овцы и рекомендуют делать в своих офиц. дпокументах.
А что касается Cortex A8 - там как бы тоже всегда был выбор: Linux - open source - пожалуйста, Linux Montavista (softreal-time) - пожалуйтса, RTLinux (hard realtime) - пожалуйста, MentorGraphics Nucleus ( QNX-архитектура "микроядра" но для армов) - пожалуйста. В этих условиях новой операционке со "спец фичей" не очень-то легко отвоевать себе позиции.

Механизма, чтобы отправить изменения системных данные в очередь и отложить их изменение в како-то специфичном системном потоке - такого точно нет.
В DSP/BIOS есть три вида контекстов: контекст аппаратного прерывания, контекст программного прерывания и контекст задачи. Программное прерывание - то же что и аппаратное, но не привязано ни к какой аппаратуре и их вектора расположены в таблице векторов после всех векторов аппаратуры, и приоритет, соответственно ниже всех аппаратных. Вызываются ассемблерной инструкцией. Программных прерываний может быть много. То есть спец. контекста "ISR2" - нет. Но по сути - "ISR2" - этим может стать именно программное прерывание. Оно может (при желании) быть непрерываемым, неизменяемым в плане приоритета и.т.д. Я тут вижу полную аналогию со статьёй. Вот только у меня законный вопрос: что будет, если низкоприоритетная задача захватит "замком" критические данные, а ISR2 как раз захочет их изменить? Зависать-то она не имеет права. Т.е. ISR2 должна быть всё-таки приоритетной задачей или нужно предусмотреть стандартную "борьбу" с "инверсией приоритетов", которой в DSP/BIOS нет (по крайней мере раньше не было). В данном случае - это мож. быть - повысить приоритет "замка", и автоматически - задачи, которая его захватила.

Масса процессоров типа 6424, 6477 (трёхядерник), 6618 (4 ядра - базовая станция GSM/или полноценная радиорелейка на одном кристалле) - предназначены для работы с громадным числом задач обработки радио/видео/голоса причём с жесточайшими требованиями по реал-тайму. Там ВСЕГДА присудстуют как задачи с низкими, так и задачи с высокими приоритетами. И работают они с большим объёмом периферии (большое число стандартных многоканальных и специфических интерфейсов, есть даже SATA, 64 DMA-канала). Да и уменя в одном из проектов в DSP/BIOS крутилось около 70 задач. Если ж брать OMAP/DaVINCI, то ARM там нужен только для одной цели - прикрутить дисплей с оконной оболочкой KDE или WinCE - т.е. дать пользователю (который держит в руках наладонник, видеокамеру или прибор УЗИ - привычный интерфейс. Для этого DSP- совершенно не приспособлены.

К сож. нет keil-а под боком, чтобы посмотреть. Но на 99.9% уверен, что очереди нет. У каждой задачи есть специальное "системное" слово на 16 бит, и каждой задаче можно передать 16 событий (по биту на каждое событие). isr_evt_set() - по-просту устанавливает соответствующий бит в этом слове задачи и специальным механизмом программирует вызов "шедьюлера" сразу по выходу из прерывания. "Шедьюлер", по вызове тот-час же передаёт этой задаче управление.

Организовать SIA на примитивах UIA не получится хотя бы потому что на UIA-системах прерывания запрещены во время исполнения обработчика что исключает возможность вложенных прерываний, а вот наоборот - эмулировать UIA на SIA можно без особых проблем, только это не нужно. Например в ранних версиях Linux можно было регистрировать обработчик который вызывается с отключенными прерываниями, сейчас этот флаг тоже формально существует но не рекомендуется

Это неверно, CM3 пришел на смену вариантам ARM9 без MMU. А это очень сильные приложения включая бортовые компы.




Про нуклеус вы я вижу не в курсе. Можем обсудить в другой ветке если интересует.




6618 - довольно примитивный проц с точки зрения богатства приложений. Один UART, один SPI, отсутствие чего либо относящегося к HMI, нет MMU.
Это масштабируемый коммуникационный шлюз и не более. Конечно он может поддержать и 100 и больше задач. Но это однотипные задачи, ну может разделенные на несколько функциональных доменов. Сюда SIA точно не нужно, все делается простым клонированием задач.
Т.е. пример явно не в тему.