adnega

Могу сделать минимальный проект под STM32. У вас есть какая-нибудь discovery?

dw0 = SCB->SHCSR; fm0 = get_faultmask(); asm("cpsid f"); __ISB(); __DSB(); fm1 = get_faultmask(); __ISB(); __DSB(); SCB->SHCSR = (1 << 15); __ISB(); __DSB(); dw1 = SCB->SHCSR; __ISB(); __DSB(); asm("cpsie f"); __ISB(); __DSB(); fm2 = get_faultmask(); dw2 = SCB->SHCSR; Результат: Но самое главное, что обработчик SVCall вызывается, т.к. он пишет послание в буфер консоли, и ничего не зависает.

Попробуйте сделать пустой обработчик SVCall (или светодиодиком мигнуть). Скорее всего, у вас обработчик SVCall не готов к асинхронному вызову, т.к. в стеке будет будет далеко не контекст инструкции svc (swi).

asm("cpsid f"); 800030e: b671 cpsid f __ASM volatile ("isb"); 8000310: f3bf 8f6f isb sy __ASM volatile ("dsb"); 8000314: f3bf 8f4f dsb sy SCB->SHCSR = (1 << 15); 8000318: f44f 4300 mov.w r3, #32768 ; 0x8000 800031c: 626b str r3, [r5, #36] ; 0x24 __ASM volatile ("isb"); 800031e: f3bf 8f6f isb sy __ASM volatile ("dsb"); 8000322: f3bf 8f4f dsb sy asm("cpsie f"); 8000326: b661 cpsie f У меня не зависает. Что я делаю не так?

Обычно 12 обработчик используют для DebugMonitor. После повышения уровня до -1, он тоже должен перестать работать. У меня все работает )) Что насчет такого обрубка: static int DteZZ1(char const *str, uint, uint) { u32 i; asm("cpsid f"); NVIC.SHCSR = B15; asm("nop"); asm("cpsie f"); return DteRes_OK; }

Если там что-то связанное с прерываниями, то разумеется работать не должно. Если там цикл на nop`ах или на регистрах таймера, то все Ок. Cortex-M4. Значит сейчас вы замените DelayMcs на asm("nop") и ему также будет плохо?

Соглашаетесь уже, что при запрещенных fault`ах от попытки вызова обработчика SVCаll (через SVCALLPENDED) никому не плохеет. Разумеется, выполнение инструкции svc (swi) в приоритете -1 (и любом выше или равном приоритету SVCall) невозможно.

;) Что в DelayMcs ? asm("cpsid f"); for(volatile int i = 0; i < 100000000; i++) asm("nop"); SCB->SHCSR = (1 << 15); asm("cpsie f"); У меня такой код морозит систему на ~7 секунд, а затем все оживает - но именно это поведение в коде и описано. Да, после оживления приходит сообщение от обработчика SVCall.

Это не приведет к блокировке, а после окончания текущего прерывания вызовется обработчик SVCall. Разумеется, до окончания данного прерывания обработчик SVCall вызван не будет, т.к. у него приоритет ниже -1 (HF). Происходит асинхронный вызов SVCall когда-то в будущем. Лог посмотрите и увидите, что SVCall срабатывает.

asm("cpsid f"); SCB->SHCSR = (1 << 15);

Я вас понял. void func_scall(void *p) { asm("svc #0"); } void func_acall(void *p) { SCB->SHCSR = (1 << 15); } if(fcall) { fcall = 0; asm("cpsid f"); SCB->SHCSR = (1 << 15); } if(xcall) { xcall = 0; asm("cpsid f"); asm("svc #0"); } Исход такой: Мое представление архитектуры по этому вопросу оказывается полностью соответствует поведению железа.

Нет - разговор был про SVCall-исключение. Про асинхронность SVCall вы не знали - рад, что вы для себя сегодня открыли что-то новое.

Проверил - прекрасно возбуждается. void SVCHandler(void) { con_str("{SVCall}\n\r"); con_start(); } void func_scall(void *p) { asm("svc #0"); } void func_acall(void *p) { SCB->SHCSR = (1 << 15); } Имею лог:

Использовать SVC в асинхронном виде - смысла, конечно же, лишено, но. Есть такой регистр System handler control and state register (SCB_SHCSR). У этого регистра есть rw-бит с номером 15: Bit 15 SVCALLPENDED: SVC call pending bit, reads as 1 if exception is pending. Описание бита имеет такую сноску: Pending bits, read as 1 if the exception is pending, or as 0 if it is not pending. You can write to these bits to change the pending status of the exceptions. Осмелюсь предположить, что запись в 1 бита 15 регистра SCB_SHCSR должно спровоцировать исключение с обработчиком SVCall. Повторюсь, практического смысла в этом ноль, проверять - не проверял, но истина дороже.

SVCHandler: tst lr, #4 ite eq mrseq r3, msp mrsne r3, psp ldr r1, [r3, #24] ldrb r0, [r1, #-2] cmp r0, #2 it hi bxhi lr tbb [pc, r0] svc_func_table: .byte ((svc_func_timer_set - svc_func_table) / 2) .byte ((svc_func_timer_tick - svc_func_table) / 2) svc_func_timer_set: ldr r0, [r3, #0] ldr r1, [r3, #4] str r1, [r0] str r1, [r3, #0] bx lr svc_func_timer_tick: ldr r0, [r3, #0] ldr r1, [r0] add r1, #10 str r1, [r0] str r1, [r3, #0] bx lr .global svc_timer_set svc_timer_set: svc 0 bx lr .global svc_timer_tick svc_timer_tick: svc 1 bx lr Вместо тысячи слов...

Да. Но вы знаете текущий стек и его указатель. Идете туда, вычитываете стандартный кадр, а уже в нем вся подноготная. В стековом кадре будет значение PC. Пошаманив со смещением найдете адрес инструкции swс, а уже в ее теле будет номер.

Спора никакого нет. Я изначально сказал, что SVCall - это исключение, и для него справедливы все правила исключений. Вы же начали обсуждать частные случаи. Вот их и обсуждаем. Насколько вам известно, исключение SVCall можно возбудить двумя способами: соответствующей инструкцией (синхронный) и через pending-бит NVIC (асинхронный). Я утверждаю, что асинхронный вызов SVCall не должен никак повредить системе даже с "запрещенными" fault`ами. А вы? Помню-помню... вы такое уже заявляли. Утверждение уровня "2х2=5", т.к. я 4 переопределил. Замаскировать NMI-обработчик невозможно. Отключить все возбудители NMI - даже обсуждать не стоит в силу очевидности. Я по аналогии скажу, что вывел тумблер запрета NMI на крышку прибора и подписываю его вместо старого "Питание" пафосным "Запрет NMI".

Есть мнение: - что NMI не маскируется, а HF не запрещается; - некоторые fault`ы по-умолчанию запрещены и улетают в HF; - можно включить отдельные обработчики fault`ов; - FAULTMASK используется не для запрета fault`ов, а для повышения текущего приоритета до -1 (уровня HF). В результате чего до выхода из обработчика никакие другие прерывания/исключения вас не потревожат.

Есть какие-то действия, которые в обработчике SVCall при вызове SVCall не приведут к блокировке? В студию! Какой fault нужно запретить (кроме, разумеется, SVCall), чтобы вызов SVCall (без соответствующей исключительной ситуации внутри SVCall) привел к блокировке? Дык, и я ровно про тоже. Если исключение не может быть выполнено (причины вы указали), то будет блокировка. Я fault`ы могу заблокировать в любом месте и там же их справоцировать - будет блокировка и SVCall тут ни при чем. Я с вами не спорю, и не измеряю, чьи познания в архитектуре больше - я лишь объясняю ТС, что "свои прерывания" ему не помогут: нужно использовать либо RTOS, либо любое периодическое прерывание.

Можно ли вызвать SVCall из SVCall ? Иначе: можно ли вызвать исключение из исключения? Конечно нет - ядро блокируется. Запрещение fault`ов тут ни при чем. Или я вас не понял.

Зависит от среды. Но по сути это исключение, в которое можно передать некое число и, при необходимости, параметры как в обычную функцию. Если у вас нет ОС и разделения на уровни привилегий, то обычную функцию использовать будет лучше во всех отношениях. Если же вы находитесь в непривилегированном режиме исполнения (который многое ограничивает), но вам нужно получить привилегированный синхронный доступ, то только SVCall. Вам, насколько я понял, нужен функционал RTOS. Я RTOS не пользуюсь, т.к. все что мне нужно можно сделать на машинах состояний.

Алиэкспресс, ЕвроМобайл, Терра, Компэл..

Я тоже с кем ни общаюсь, все как-то не волнуются. От налоговой многое зависит, но у нашей имею пару наблюдений: - на одном из мероприятий начальник нашей ФНС сказала, мол, поднимите руку кого из вас мы наказали/оштрафовали и т.п. - никто не признался. Я так понял, что все вопросы сначала попробуют решить полюбовно, а наглецов уже накажут; - однажды пригласили на беседу в ФНС. По итогу пришли к тому, что я напишу объяснительную, чтоб их вышестоящее руководство не наказало. Т.е. у них собственной инициативы ноль, но если спорный вопрос возникает, то если вы им прикроете одно место, то и к вам претензий не будет. - было явное нарушение при применении ККТ с моей стороны, позвонил и спросил как мне это нарушение разрешить, мол, как о нем заявить и т.п. Мне сказали, что не стоит на себя навлекать лишние проблемы, и предложили путь как все разрешить мирно. Кста, так до конца еще не довел это вопрос, но уровень кровожадности у нашей ФНС, по-моему, минимальный. Итого: если вы не портите жизнь рядовым инспекторам (которые ответственны перед вышестоящим руководством), то и вас никто мучить не будет.

Я пришел тому, что если сумма исчисляемого налога не ниже той, которую считает ФНС, то никаких проблем нет, даже если вы все насчитали неправильно и переплатили. Но вот если вы хотите уменьшить сумму налога, то нужно все вести аккуратно.

А где этот ОКВЭД вообще фигурирует? У меня только в ежегодной декларации по УСН указан основной ОКВЭД 62.01. Договор позразумевает различные виды деятельности, и по ОКВЭДам я их не разделяю - все в итоге попадут в 62.01. Как-то это можно разделить по кодам на уровне Договора? Ставка налога УСН для 62.01 обычная 6%. Если бы она была 0%, то налоговая бы напрягалась на вашу Декларацию с таким кодом, но тут смысла нет - так мне объяснил бухгалтер.