adnega

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%, то налоговая бы напрягалась на вашу Декларацию с таким кодом, но тут смысла нет - так мне объяснил бухгалтер.

А почему вы не хотите продавать лицензию на ПО? За прошивку и настройку много не возьмешь без подозрений.

А обычная функция чем не подходит? Если нужны полноценные задачи, то нужно применять RTOS. Флаг прерывания от периферии взводит связанный с ним pending-бит, а далее NVIC все делает сам.

Конечно, можно. Вопрос зачем?

Вместо default_isr в таблицу нужно вписать свой обработчик.

Что такое "ивент"? Можно пример. Прерывание можно спровоцировать программно, установив соответствующий pending-бит в регистре NVIC.

Как именно и зачем использовать асинхронное прерывание, когда есть синхронное исключение SVCall для подобных нужд?

Если подтверждение это ACK-бит, то все верно - должен слать сплошняком. Но если на шине есть хоть одно устройство, то оно выставит ACK-бит и ретрансмит остановится.

Значит кто-то другой с более высоким приоритетом начал передачу, а ваш узел потерял арбитраж. Это не страшно, т.к. тот узел успешно все передаст, а ваш должен повторить попытку в следующее освобождение шины. Большая беда возможна лишь когда два узла передают с одним и тем же ID.

У тини10, вроде, всего 32 байта ОЗУ.

Внешний резистор подтяжки может быть решением.

В свежих АТ-прошивках можно сделать, чтоб с +IPD вываливался только link_id и размер (passive mode), а вычитывать данные можно будет ручками. Вариант?

А можете описать это решение? По-моему, ОЗУ никак не поможет определить был это сброс по питанию, внешнему сигналу RESET или watchdog`у. Чем биты регистра RCC->CSR не угодили?

Из хороших новостей: - потери победил. пришлось включить аппаратное управление потоком; - стабильно работает на скорости UART 5 Мбит/с. Из плохого: - на ESP-01 пин 13 (U0_nRTS; он же MTDO, GPIO15) жестко сидит на земле; - простои на шине могут достигать тысяч мс; - максимальный поток примерно 2.5-3.0 Мбит/с (50 % от полосы UART и 18% от максимума, получаемого спецпрошивкой). Для информации: - пин nRTS взлетает на 8 мкс примерно каждые 100 байт; - максимальное значение активности nRTS не измерял; - максимальный размер пачки, который гарантировано не страгивал бы nRTS не выяснял.

У МК есть статусный регистр с указанием источника перезагрузки. Если у вас 10 перезагрузок от IWDT, то это можно программно определить. Есть флаги перезагрузки по пину RESET и подаче питания POR.