[Arlleex 160]

34 минуты назад, jenya7 сказал:

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

Ну вот определитесь, что Вам нужно. А то до setjmp/longjmp так дойдем.

[haker_fox 61]

@jenya7, а чем вам стандартное решение не подходит? SVC же есть?!

[jenya7 0]

On 6/14/2019 at 5:29 AM, haker_fox said:

@jenya7, а чем вам стандартное решение не подходит? SVC же есть?!

а как им пользоваться?

[adnega 11]

7 минут назад, jenya7 сказал:

а как им пользоваться?

Зависит от среды. Но по сути это исключение, в которое можно передать некое число и, при необходимости, параметры как в обычную функцию.

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

Если же вы находитесь в непривилегированном режиме исполнения (который многое ограничивает),

но вам нужно получить привилегированный синхронный доступ, то только SVCall.

Вам, насколько я понял, нужен функционал RTOS.

Я RTOS не пользуюсь, т.к. все что мне нужно можно сделать на машинах состояний.

[haker_fox 61]

1 hour ago, jenya7 said:

а как им пользоваться?

Пример кода я вам не приведу, т.к. не использую. Но в своё время эсперименты проводил. Если кратко, то на асме вы пишете (я думаю, что можно и на си/си++ это сделать)

svc #1
...
...
svc #7
...
...
svc #255

т.е. вызыван будет обработчик по адресу SVC. Аргументы при этом через регистры не передаются!!! Вы должны сами, используя адрес возврата из прерывания, считать значение аргумента, которое находится "рядом" с кодом команды. Я делал это на асме. Как сделать на си/си++ нужно смотреть в доке на компилятор, наверняка там есть соответствующие "функции".

[jcxz 218]

10 минут назад, haker_fox сказал:

т.е. вызыван будет обработчик по адресу SVC. Аргументы при этом через регистры не передаются!!!

Неправда! Давно уже использую функции, оформленные через SVC. В IAR даже синтаксис для таких функций специальный существует. Аргументы туда можно передавать так же как в обычные функции - через регистры. И здесь на форуме уже вроде был тред на эту тему.

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

Не передаётся только номер после SVC. Так а кто заставляет его использовать?

[jcxz 218]

1 час назад, adnega сказал:

Зависит от среды. Но по сути это исключение, в которое можно передать некое число и, при необходимости, параметры как в обычную функцию.

Есть ограничение вызова SVC от обычных функций: обычные можно вызывать при запрещённых fault-ах, но если так попытаться сделать с SVC, то очень поплохеет.  

Возбуждение прерывания через  NVIC_ISPRx тоже возможно при запрещённых interrupt/faults.

[adnega 11]

2 минуты назад, jcxz сказал:

Есть ограничение вызова SVC от обычных функций: обычные можно вызывать при запрещённых fault-ах, но если так попытаться сделать с SVC, то очень поплохеет.  

Можно ли вызвать SVCall из SVCall ? Иначе: можно ли вызвать исключение из исключения?

Конечно нет - ядро блокируется. Запрещение fault`ов тут ни при чем. Или я вас не понял.

[jcxz 218]

13 минут назад, adnega сказал:

Можно ли вызвать SVCall из SVCall ?

Нет. Без некоторых доп.действий.

Цитата

Иначе: можно ли вызвать исключение из исключения?

В общем случае - да. Если приоритет нового исключения выше чем действующего.

Цитата

Конечно нет - ядро блокируется. Запрещение fault`ов тут ни при чем. Или я вас не понял.

Запрещение fault-ов тут при чём. SVC - это синхронное прерывание. В отличие от асинхронных (коими являются все прерывания от аппаратуры), синхронное прерывание, если не может быть выполнено по каким-то причинам, приводит к блокировке CPU. Такие причины невыполнения:

1) маскирование в соответствующем регистре FAULTMASK (о чём я и писал);

2) текущий уровень приоритета прерывания выше или равен уровеню приоритета SVC.

[adnega 11]

2 минуты назад, jcxz сказал:

Нет. Без некоторых доп.действий.

Есть какие-то действия, которые в обработчике SVCall при вызове SVCall не приведут к блокировке? В студию!

2 минуты назад, jcxz сказал:

В общем случае - да. Если приоритет нового исключения выше чем действующего.

Какой fault нужно запретить (кроме, разумеется, SVCall), чтобы вызов SVCall (без соответствующей исключительной ситуации внутри SVCall) привел к блокировке?

2 минуты назад, jcxz сказал:

Запрещение fault-ов тут при чём. SVC - это синхронное прерывание. В отличие от асинхронных (коими являются все прерывания от аппаратуры), синхронное прерывание, если не может быть выполнено по каким-то причинам, приводит к блокировке CPU. Такие причины невыполнения:

1) маскирование в соответствующем регистре FAULTMASK (о чём я и писал);

2) текущий уровень приоритета прерывания выше чем уровень приоритета SVC.

Дык, и я ровно про тоже. Если исключение не может быть выполнено (причины вы указали), то будет блокировка.

Я fault`ы могу заблокировать в любом месте и там же их справоцировать - будет блокировка и SVCall тут ни при чем.

Я с вами не спорю, и не измеряю, чьи познания в архитектуре больше - я лишь объясняю ТС, что "свои прерывания" ему не помогут: нужно использовать либо RTOS, либо любое периодическое прерывание.

[jcxz 218]

5 минут назад, adnega сказал:

Есть какие-то действия, которые в обработчике SVCall при вызове SVCall не приведут к блокировке? В студию!

Понизить уровень приоритета текущего fault-а. Или повысить уровень приоритета SVC (в регистрах конфигурации NVIC) для следующего SVC. Если его конечно можно изменить не изменяя уровня текущего SVC.

 

5 минут назад, adnega сказал:

Какой fault нужно запретить (кроме, разумеется, SVCall), чтобы вызов SVCall (без соответствующей исключительной ситуации внутри SVCall) привел к блокировке?

Бит запрета fault-ов он всего один: в регистре FAULTMASK. Я уже писал.

 

5 минут назад, adnega сказал:

Я fault`ы могу заблокировать в любом месте и там же их справоцировать - будет блокировка и SVCall тут ни при чем.

Вообще непонятно с чем Вы спорите?   Сперва пишете что:

43 минуты назад, adnega сказал:

Конечно нет - ядро блокируется. Запрещение fault`ов тут ни при чем. Или я вас не понял.

не знаете о FAULTMASK? Или о чём Вы вообще???  

[adnega 11]

43 минуты назад, jcxz сказал:

Бит запрета fault-ов он всего один: в регистре FAULTMASK. Я уже писал.

Есть мнение:

- что NMI не маскируется, а HF не запрещается;

- некоторые fault`ы по-умолчанию запрещены и улетают в HF;

- можно включить отдельные обработчики fault`ов;

- FAULTMASK используется не для запрета fault`ов, а для повышения текущего приоритета до -1 (уровня HF).

В результате чего до выхода из обработчика никакие другие прерывания/исключения вас не потревожат.

[jcxz 218]

3 минуты назад, adnega сказал:

- FAULTMASK используется не для запрета fault`ов, а для повышения текущего приоритета до -1 (уровня HF).

....что является идентичным запрету. Вам просто поспорить охота?    И маскирование/немаскирование NMI и HF никак не относится к SVC.

PS: Если что, то NMI во многих МК маскируется. Но не через регистры NVIC.

[haker_fox 61]

2 hours ago, jcxz said:

Неправда!

Ну так я то про ассемблер. Я не использвал вызов и обработку SVC из СИ. Так вот, при вызове прерывания из ассемблерного кода, мы попадаем в вектор SVC, но в регистрах нет информации об аргументе.

2 hours ago, jcxz said:

В IAR даже синтаксис для таких функций специальный существует.

Повторюсь, на си не использовал.

[adnega 11]

6 минут назад, jcxz сказал:

....что является идентичным запрету. Вам просто поспорить охота? 

Спора никакого нет. Я изначально сказал, что SVCall - это исключение, и для него справедливы все правила исключений.

Вы же начали обсуждать частные случаи. Вот их и обсуждаем.

Насколько вам известно, исключение SVCall можно возбудить двумя способами: соответствующей инструкцией (синхронный) и через pending-бит NVIC (асинхронный).

Я утверждаю, что асинхронный вызов SVCall не должен никак повредить системе даже с "запрещенными" fault`ами. А вы?

6 минут назад, jcxz сказал:

PS: Если что, то NMI во многих МК маскируется. Но не через регистры NVIC.

Помню-помню... вы такое уже заявляли. Утверждение уровня "2х2=5", т.к. я 4 переопределил.

Замаскировать NMI-обработчик невозможно. Отключить все возбудители NMI - даже обсуждать не стоит в силу очевидности.

Я по аналогии скажу, что вывел тумблер запрета NMI на крышку прибора и подписываю его вместо старого "Питание" пафосным "Запрет NMI".