my504 (13.10.2025 11:41, просмотров: 14229)-
- Терминологическая непонятка: что вы имеете в виду под софтверными
прерываниями? Есть, как минимум, три расшифровки: инструкция SVC,
прерывание PendSV, программный вызов аппаратного прерывания путем
манипуляций с регистрами NVIC. - LightElf(13.10.2025 12:39)
- То которое не конфликтует с RTOS. Видимо последнее из вашего списка. - 3m(13.10.2025 13:15)
- Смотря какой ARM. Есть специальные регистры, записью единицы в бит
которых, принудительно взводится любое прерывание. И я использовал
вектора прерываний неиспользуемой, выключенной периферии. - Nikolay_Po(13.10.2025 11:57)
- Кортекс 4. AT32F435. В системе команд есть инструкция софтверного
прерывания. Вот про нее и вопрос. Как вызвать и кто будет
обработчиком. Как пользоваться EXTINT-ом (там есть софтверный
триггер), а так же через свободную периферию, я знаю. Хотелось бы
узнать про внутриядерный механизм через упомянутую инструкцию. - my504(13.10.2025 12:04)
- LightElf ответил. Именно так. - Nikolay_Po(13.10.2025 13:44)
- инструкция SVC (раньше называлась SWI) вызывает исключение SVCall,
вектор 11. Дальше делаете что хотите. - LightElf(13.10.2025 12:42, +1)
- Спасибо. А как она выглядит в Си? - my504(13.10.2025 14:09)
- От компилятора зависит, это нестандартная вещь. - LightElf(13.10.2025 21:24)
- Что интересно, в хедерах CMSIS есть много макросов-обёрток для
специальных инструкций (как бы для всех компиляторов), но именно
SVC отсутствует. - SciFi(13.10.2025 21:29)
- Можно посмотреть в examples. Например: Tahoe06(355 знак., 02.01.2026 21:03,
) - И это не просто так :-) - LightElf(13.10.2025 21:30)
- Можно посмотреть в examples. Например: Tahoe06(355 знак., 02.01.2026 21:03,
- Что интересно, в хедерах CMSIS есть много макросов-обёрток для
специальных инструкций (как бы для всех компиляторов), но именно
SVC отсутствует. - SciFi(13.10.2025 21:29)
- Наверное так (для GCC): Nikolay_Po(166 знак., 13.10.2025 14:24, ссылка, ссылка)
- Вопрос в догон. Обработчик SVC один - SVC_Handler. Что определяет
параметр этой инструкции? Как понимать 11 вектор? - my504(13.10.2025 14:31)
- Насчет вектора - непонятен вопрос. Номера векторов перечислены в хедере на конкретный проц. LightElf(359 знак., 13.10.2025 21:11)
- Там два параметра. Первый, код, определяет условие, по которому срабатывает исключение (можно, например, сравнивать значение с допуском и по выходу за пределы - исключаться). Второе значение - типа блокнотика, куда можно записать свою цифру, 8 бит, для передачи обработчику - чтобы в обработчике прерывания прочитать и принять к сведению. Nikolay_Po(91 знак., 13.10.2025 16:49)
- Тут почитать можно. Andrew_Q(2 знак., 13.10.2025 15:22, ссылка, картинка)
- Вопрос в догон. Обработчик SVC один - SVC_Handler. Что определяет
параметр этой инструкции? Как понимать 11 вектор? - my504(13.10.2025 14:31)
- От компилятора зависит, это нестандартная вещь. - LightElf(13.10.2025 21:24)
- Спасибо. А как она выглядит в Си? - my504(13.10.2025 14:09)
- Не про это? Из FREERTOS. Andrew_Q(1 знак., 13.10.2025 12:11, картинка)
- Кортекс 4. AT32F435. В системе команд есть инструкция софтверного
прерывания. Вот про нее и вопрос. Как вызвать и кто будет
обработчиком. Как пользоваться EXTINT-ом (там есть софтверный
триггер), а так же через свободную периферию, я знаю. Хотелось бы
узнать про внутриядерный механизм через упомянутую инструкцию. - my504(13.10.2025 12:04)
- Дикпик что-то вещает на эту тему. - POV(13.10.2025 11:51)
- В вопросе должно содержаться половина ответа, а тут даже на
половину вопроса не тянет... :-) - il-2(13.10.2025 11:49)
- ++ Eddy_Em(30 знак., 13.10.2025 14:05)
- Есть такие случаи, когда нужно сгенерировать прерывание из
основного кода. Это прерывание называется софтверным. О нем и речь.
Часто для этого используют незадействованную периферию. Например
внешние прерывания, которые вызываются не с ноги МК (нога никуда не
подключена и подтянута в пассивное состояние), а с помощью
соответствующего бита регистра SWTr. Заслал туда единицу -
сгенерировалось внешнее прерывание. Однако есть специальная
инструкция и вектор, чтобы не my504(32 знак., 13.10.2025 16:12)
- Вот тут можно посмотреть - LightElf(1 знак., 13.10.2025 21:09, ссылка)
- Все-таки остается вопрос, зачем вам непременно это надо делать в
виде прерывания? То-же самое можно получить, сделав вызов
подпрограммы. il-2(205 знак., 13.10.2025 17:10)
- См. в моём ответе Эдуарду: - Nikolay_Po(1 знак., 13.10.2025 18:09, ссылка)
- Что-то я читал, читал... понял наконец в чем тонкость. Но это все
можно сделать и в подпрограмме - типа программного семафора, и
заменить таки программное прерывание на вызов подпрограммы. Код
подпрограммы должен быть реентрантный (по крайней мере до момента
проверки семафора). С программным прерыванием конечно будет проще.
Но если его нет, то можно при желании обойтись. Я с такими задачами
не сталкивался. - il-2(14.10.2025 06:51)
- Там ниже еще LightElf пример привел, связанный с приоритетами. Все,
теперь врубился до конца. Но текущий приоритет можно снизить
(наверное) в NVIC. Если так, то можно обойтись без программных
прерываний (подпрограммами). Можно, но сложно :-) - il-2(14.10.2025 07:01)
- Нет, текущий приоритет (приоритет обрабатываемого в данный момент
прерывания) снизить нельзя. Тиритицки (не проверял) можно изменить
значение приоритета в NVIC и программно взвести (через NVIC) то же
прерывание еще раз. Тогда по выходу из текущего обработчика мы
снова перезайдем в тот же обработчик, но уже на новом (более
низком) уровне приоритета. Но тогда при наступлении нового события
мы не смодем его гарантированно быстро обработать, потому что
приоритет уже понижен и LightElf(308 знак., 14.10.2025 18:14)
- Тут: Nikolay_Po(978 знак., 14.10.2025 20:45, ссылка)
- BASEPRI, насколько я помню, маскирует прерывания с приоритетом ниже
указанного. На уже активное прерывание он не влияет. ARM пишет про
него такое: LightElf(591 знак., 14.10.2025 22:58, +1)
- Хмм... Сейчас вернулся к развитию проекта на Cortex-M3. Смотрю - у меня вовсю меняется BASEPRI и часто, даже большую часть случаев - из кода прерывания, во время нахождения в прерывании. Таким образом, решаю задачу временного поднятия приоритета для обеспечения атомарности обращения к общим ресурсам. Но всегда меняется только в сторону повышения приоритета, в сторону маскирования более приоритетных прерываний. И работает. - Nikolay_Po(02.01.2026 19:56)
- Спасибо! Особенно за вторую цитату. Получается, оно может работать, но при разработке ядра и контроллера прерываний, эту ситуацию не прорабатывали и никто ничего не гарантирует. - Nikolay_Po(15.10.2025 16:06)
- BASEPRI, насколько я помню, маскирует прерывания с приоритетом ниже
указанного. На уже активное прерывание он не влияет. ARM пишет про
него такое: LightElf(591 знак., 14.10.2025 22:58, +1)
- Тут: Nikolay_Po(978 знак., 14.10.2025 20:45, ссылка)
- Возможно, существуют задачи, где без "программных прерываний" не
обойтись, но я сходу таковых придумать не смог. - Eddy_Em(14.10.2025 09:48)
- Отлично! Значит, тебе удаётся так продумать структуру программы и
разделить её на куски, что защищать секции выполнения поднятием
приоритета не приходится. - Nikolay_Po(14.10.2025 11:19)
- Ну так у меня в случаях, где нужна реакция в пределах миллисекунды,
обычно один прогон суперлупа длится куда меньше. Eddy_Em(363 знак., 14.10.2025 11:57)
- А у меня требуется реакция не дольше чем за 20мкс по паре
интерфейсов сразу. Обработка блока данных - намного дольше и должна
быть приоритетнее кода пользовательского режима. В принципе, как
предположил товарищ il-2, можно не выходя из текущего высокоприоритетного прерывания, после
снятия флага запроса прерывания, понизить текущий приоритет
выполнения кода, изменив значение BASEPRI и вызвать подпрограмму
обработки. Nikolay_Po(69 знак., 14.10.2025 13:02)
- Сильно сомневаюсь что это сработает, но это на уровне ощущений.
Прерывание обрабатывается в Handler Mode, а BASEPRI (насколько я
понимаю) влияет только на Thread Mode. - LightElf(14.10.2025 18:37)
- Хмм... Жаль, меня пока не интересует ARM, на данный момент работаю
с RISC-V QingKe4F от WCH. Nikolay_Po(211 знак., 14.10.2025 20:58)
- Про RISC-V ничего сказать не могу. У ARM регистр BASEPRI позволяет запретить более приоритетные прерывания, но не позволяет разрешить менее приоритетные. Выше писал, что, по отзывам, вроде бы можно понизить приоритет текущему прерыванию, но в доке ARM это отдельным пунктом не рекомендуется делать. - LightElf(15.10.2025 00:40, +1)
- Хмм... Жаль, меня пока не интересует ARM, на данный момент работаю
с RISC-V QingKe4F от WCH. Nikolay_Po(211 знак., 14.10.2025 20:58)
- Сильно сомневаюсь что это сработает, но это на уровне ощущений.
Прерывание обрабатывается в Handler Mode, а BASEPRI (насколько я
понимаю) влияет только на Thread Mode. - LightElf(14.10.2025 18:37)
- А у меня требуется реакция не дольше чем за 20мкс по паре
интерфейсов сразу. Обработка блока данных - намного дольше и должна
быть приоритетнее кода пользовательского режима. В принципе, как
предположил товарищ il-2, можно не выходя из текущего высокоприоритетного прерывания, после
снятия флага запроса прерывания, понизить текущий приоритет
выполнения кода, изменив значение BASEPRI и вызвать подпрограмму
обработки. Nikolay_Po(69 знак., 14.10.2025 13:02)
- Ну так у меня в случаях, где нужна реакция в пределах миллисекунды,
обычно один прогон суперлупа длится куда меньше. Eddy_Em(363 знак., 14.10.2025 11:57)
- Отлично! Значит, тебе удаётся так продумать структуру программы и
разделить её на куски, что защищать секции выполнения поднятием
приоритета не приходится. - Nikolay_Po(14.10.2025 11:19)
- Нет, текущий приоритет (приоритет обрабатываемого в данный момент
прерывания) снизить нельзя. Тиритицки (не проверял) можно изменить
значение приоритета в NVIC и программно взвести (через NVIC) то же
прерывание еще раз. Тогда по выходу из текущего обработчика мы
снова перезайдем в тот же обработчик, но уже на новом (более
низком) уровне приоритета. Но тогда при наступлении нового события
мы не смодем его гарантированно быстро обработать, потому что
приоритет уже понижен и LightElf(308 знак., 14.10.2025 18:14)
- Там ниже еще LightElf пример привел, связанный с приоритетами. Все,
теперь врубился до конца. Но текущий приоритет можно снизить
(наверное) в NVIC. Если так, то можно обойтись без программных
прерываний (подпрограммами). Можно, но сложно :-) - il-2(14.10.2025 07:01)
- Что-то я читал, читал... понял наконец в чем тонкость. Но это все
можно сделать и в подпрограмме - типа программного семафора, и
заменить таки программное прерывание на вызов подпрограммы. Код
подпрограммы должен быть реентрантный (по крайней мере до момента
проверки семафора). С программным прерыванием конечно будет проще.
Но если его нет, то можно при желании обойтись. Я с такими задачами
не сталкивался. - il-2(14.10.2025 06:51)
- я могу ответить зачем это понадобилось мне. В пике есть 2
компаратора от которых я собственно получал прерывания и
обрабатывал их. в артери нет компараторов, пришлось использовать
АЦП. И вот чтобы не переделывать механизм работы обработчик ацп
генерил софтварные прерывания, которые обрабатывались, словно они
пришли от компаратора. - abivan(13.10.2025 17:55, +1)
- ИМХО, в СТМах у АЦП есть прерывание по превышению/снижэнию. - mse homjak(13.10.2025 18:00)
- Была жесткая синхронизация работы двух устройств через скоростной УАРТ (2мбит/с). Этот УАРТ работал через хаф-дуплекс 485, что позволяло синхронизировать работу - мастер и слейв получали сообщения одновременно. Теперь я отказался от слейва и хочу для минимизации правок кода просто перенести тело обработчика приемника УАРТа в обработчик софтового прерывания, более ничего не меняя. Тогда ставить 485 трансивер или перемычку Rx-Tx не требуется. - my504(13.10.2025 17:50)
- См. в моём ответе Эдуарду: - Nikolay_Po(1 знак., 13.10.2025 18:09, ссылка)
- Опять ничего не понял. Зачем? - Eddy_Em(13.10.2025 16:26)
- "CMSIS-RTOS: Implements supervisor calls (SVCs) as a fundamental
mechanism for invoking privileged system services such as hardware
access and kernel functions." - SciFi(13.10.2025 16:55)
- Ну и на кой оно вне RTOS? - Eddy_Em(13.10.2025 17:43)
- А кто мешает применять механизмы RTOS вне её? Эдик, ты слишком категоричен во всем. Это выглядит как клоунада. - my504(13.10.2025 17:55)
- Ну и на кой оно вне RTOS? - Eddy_Em(13.10.2025 17:43)
- Для выполнения более приоритетного кода в программном прерывании -
по сути, использование прерывания для аппаратного переключения
выполнения текущего кода на код программного прерывания. - Nikolay_Po(13.10.2025 16:51)
- Достаточно такие критические секции просто обложить disable_irq /
enable_irq. - Eddy_Em(13.10.2025 17:42)
- Эдуард, выглядит так, будто ты умнее всех и нас учишь. А если представить себе, что выполняется секция высокоприоритетного прерывания интерфейса. И нужно вызвать другую, более приоритетную, чем main() задачу, долгую, длинную функцию, но менее приоритетную чем прерывания железа. Nikolay_Po(791 знак., 13.10.2025 18:12)
- Это стремный костыль. - my504(13.10.2025 17:53)
- Достаточно такие критические секции просто обложить disable_irq /
enable_irq. - Eddy_Em(13.10.2025 17:42)
- "CMSIS-RTOS: Implements supervisor calls (SVCs) as a fundamental
mechanism for invoking privileged system services such as hardware
access and kernel functions." - SciFi(13.10.2025 16:55)
- Есть такие случаи, когда нужно сгенерировать прерывание из
основного кода. Это прерывание называется софтверным. О нем и речь.
Часто для этого используют незадействованную периферию. Например
внешние прерывания, которые вызываются не с ноги МК (нога никуда не
подключена и подтянута в пассивное состояние), а с помощью
соответствующего бита регистра SWTr. Заслал туда единицу -
сгенерировалось внешнее прерывание. Однако есть специальная
инструкция и вектор, чтобы не my504(32 знак., 13.10.2025 16:12)
- ++ Eddy_Em(30 знак., 13.10.2025 14:05)
- Терминологическая непонятка: что вы имеете в виду под софтверными
прерываниями? Есть, как минимум, три расшифровки: инструкция SVC,
прерывание PendSV, программный вызов аппаратного прерывания путем
манипуляций с регистрами NVIC. - LightElf(13.10.2025 12:39)
