adnega

Есть мнение: - что 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.

Проверил TCP2UART (v0.6.4). Потери ~44% для потока 128 кБ/с, причем снизил скорость UART до 2.5 Мбит/с. Современные китайские AT-прошивки хоть и теряют байты, но не половину потока.

Проще некоторый (или весь) функционал перенести в ESP. Была бы полная документация по ESP32, я бы выбрал их.

Прозрачный режим очень удобен, т.к. не требуется дорабатывать прошивку изделия, которое уже общается по UART. Обычно по такому каналу я гоняю текстовую консоль. Там трафик просто никудышный и никаких потерь не заметил. В крайнем случае, команды вернет "error" и можно переповторить. Нет такого смайлика, чтоб передать всю печаль по данной теме. Самое интересное, что кишки ESP без проблем гоняют трафик 16.7 Мбит/с (~2000 пакетов/с по 1024 байт в каждом) уже на протяжении 10 часов. Причем, и UDP, и TCP примерно одно и тоже, т.е. WiFi точно не является узким местом. Я думаю, проблема в UART и криворукости писателей AT-прошивки. Либо она не предназначена для передачи значительного потока без потерь. Из альтернативных пробовал только TCP2UART с форума esp8266.ru По сравнению с v0.25 она в свое время была значительно лучше, но тоже не без приколов - не мог задать свои SSID и пароль.