[ViKo 1]

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

Так PC и LR во время падения в HF сохраняются в стеке. Вот за них и потянуть. Можно просто выйти из HF и продолжить, как ни в чем не бывало.

Я не настаиваю. Предлагаю подумать.

Можно задачу удалить в РТОС, а потом снова создать.

А сбросить МК любой умеет.

[aaarrr 63]

Так PC и LR во время падения в HF сохраняются в стеке. Вот за них и потянуть.

А где сохраняется SP? :)

 

Можно просто выйти из HF и продолжить, как ни в чем не бывало.

Можно, но нужно или устранить причину fault'а, или привести ПО в безопасное состояние.

 

Вообще-то вероятность зависит...

Вообще-то я говорил о вероятности совпадения двух событий разной природы.

 

ФС нужна только если эту SD должны вынимать вставлять ещё куда-то (комп, etc.).

Если карту не предполагается вынимать, то и сама карта вроде бы ни к чему, нет?

 

Хранить удобнее бинарные записи (размер меньше, размер фиксированный)

Размер смущать в наше время не должен, а вот возможность непосредственного чтения человеком и гибкость формата являются преимуществом.

[Arlleex 131]

Если используется SD-карта, то логично использовать файловую систему и текстовые логи - скопировать текст из файла в письмо условная "баба Нюра" сможет, а вот всякие утилиты ей совершенно ни к чему. Дублировать ничего не нужно - вероятность совпадения двух аварийных событий ничтожна.

В этом, безусловно, огромный плюс... И это имеет смысл (в моем случае) для устройств, которые стоят на объектах и которые имеют возможность эту карту вытащить. Но есть и устройства, из которых SD-карта не вынимается, а стоит на плате жестко (припаяна или в слоте). В таком случае файлы .info выкачиваются по доступному интерфейсу и могут расшифровываться "налету". Сейчас же все-таки все равно сделано в текстовом виде и с файловой системой, гоню по Ethernet при выкачке на комп (кстати, вот как раз jcxz об этом и говорит как раз).

Кстати а можно ли каким-то образом сказать файловой системе (FatFS), что я часть карты использую для сырых данных (с такого-то по такой-то адрес), а остальную область она может использовать для себя? Грубо говоря, организовать ФС на карте и, одновременно, иметь возможность писать сырые данные в отведенную область (скажем, некая аналогия с разлиновкой памяти для МК)?

 

Вообще-то вероятность зависит от условий эксплуатации устройства автора. Вы откуда знаете какова у него вероятность?

Да вот конкретно сейчас бытовой пример - у меня устройство настольное, не серийное, а некий макет для людей. Им пользуются в течение дня и вечером выключат питание. И так каждый рабочий день. И хочу каждому юзеру обрубить его претензии, а то бывает не доказательное давление со стороны пользователей :laughing: А когда показываешь лог событий и говоришь - "вот все что ты делал" - сразу невинные глазки и ответ - "ну да, признаю"... :crying: В общем, перекладывание вины на других мне надоело и уже решил всегда все логгировать чтобы небезосновательно снять с разработчиков ответственность (или наоборот ее доказать).

 

ViKo, из Fault-обработчика то Вы выберетесь, элементарно ж. Но вот из функции, вызвавшей ошибку, находясь в прерывании, Вы не выйдете. Иначе надо знать размер каждой функции в памяти и состояние стека. Это не представляется возможным. Ваш подход насчет подумать "налету", не перезагружая процессор, был описан jcxz как некритическая ошибка, которую можно разрулить. Однако, если ПО довольно сложное и в нем крутится салат из многопоточных DMA, пересылок, обменов и т.д., выкрутиться из такой ситуации очень сложно (если не возможно вовсе) не затронув последствия такого разруливания. Ведь действительно, все может стать еще хуже: в реал-тайме полетит времянка из-за вовремя не остановленных процессов и т.д. Проще сбросить и начать сначала, с белого листа, указав разработчику на ошибку записью в какой-нибудь энергонезависимый накопитель :rolleyes: Со временем такие ошибки минимизируются к 0, останутся только некритические ошибки, которые, как раз, как и Вы предлагаете, исправляются "on fly".

[ViKo 1]

А где сохраняется SP? :)

А он (они) не портится. Нужно только определить, который из них использовался перед улетом, и далее из стека извлекается всё нужное и ненужное. Если, конечно, не напортачить с выделением стека изначально.

[aaarrr 63]

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

Если FatFS умеет работать с разделами, то почему бы и нет?

 

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

На макете можно и sync после каждой записи делать.

 

А он (они) не портится.

Да ну? То есть в произвольной точке функции Вы ожидаете увидеть то же значение SP, что и на входе?

[jcxz 184]

Размер смущать в наше время не должен, а вот возможность непосредственного чтения человеком и гибкость формата являются преимуществом.

Пока не изобрели МК с бесконечной памятью, он будет смущать.

Да и: скорость_записи=f(размер_записи).

[ViKo 1]

Да ну? То есть в произвольной точке функции Вы ожидаете увидеть то же значение SP, что и на входе?

Заваливаясь в HF, я всегда буду на вершине стека, относительно которой и находятся регистры PC, LR. То есть, я могу сохранить состояние ошибки, задать некий флаг ошибки и выйти из функции, используя сохраненный LR. Если внутри функции используется стек, тогда не знаю.

[aaarrr 63]

Пока не изобрела МК с бесконечной памятью, он будет смущать.

Да и: скорость_записи=f(размера_записи).

Размер типичной записи в лог - десятки байт-килобайты. Это явно не тот случай, когда экономия имеет смысл.

Вот если нужно в 24C04 лог писать - тогда другое дело :)

[jcxz 184]

В этом, безусловно, огромный плюс... И это имеет смысл (в моем случае) для устройств, которые стоят на объектах и которые имеют возможность эту карту вытащить.

Даже в этом случае имхо - надёжнее организовать журналы как я описывал. Просто дублировать их ещё и в ФС. Основное место хранения при этом - FIFO, а при старте ПО и при каждом обновлении FIFO-журнала ПО просто должно синхронизировать файлы по содержимому FIFO-журнала: удалять ненужные, или создавать отсутствующие (удалённые как сбойные при старте ПО и ремонте ФС).

 

Грубо говоря, организовать ФС на карте и, одновременно, иметь возможность писать сырые данные в отведенную область (скажем, некая аналогия с разлиновкой памяти для МК)?

Ну никто-ж Вам не мешает на этой SD ограничить размер раздела каким-то объёмом, а остальное место использовать для посекторного доступа. Фэйковые флешки с али, на которых написано 512 гиг, а по факту они - 8 гиг именно так и ремонтируются: раздел урезается до реальной ёмкости и всё. У меня несколько таких халявных флешек, работающих уже не один год :rolleyes:

[aaarrr 63]

Если внутри функции используется стек, тогда не знаю.

Так о том и речь.

[ViKo 1]

Так о том и речь.

По моему, регистры в стек заносятся непосредственно при улете в HF. То есть, определить PC и LR и еще кучу регистров можно точно.

[jcxz 184]

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

А какой толк-то? Вот у Вас произошло переполнение стека к примеру, в результате - разрушился счётчик цикла там хранившийся, потом по этому счётчику цикла производится цикл записи в память. В результате счётчик вместо скажем 10, стал равен 0xFFFFFFF и запись в память будет идти пока не дойдёт до границ региона, разрешённого для записи в MPU и не вызовется fault. И что - сохраните Вы ошибку и вернётесь куда - в полностью разрушенную программу (вся ОЗУ стёрта)? И что получите? Что устройство вылетит в следующий fault, и следующий и т.д.? И в результате потом даже неясно будет первоначальная точка fault-а? А может в очередной раз не вылетит в fault, а просто тупо повиснет - так лучше?

А в это время скажем какая-то нагрузка (которая в штатном режиме работы ПО устройства управляется ШИМ-ом) начинает поджариваться, так как силовой ключ остался во вкл. положении надолго, вместо перезапуска ПО и перевода всего и вся в безопасное положение. :smile3009:

[ViKo 1]

А какой толк-то? Вот у Вас произошло переполнение стека к примеру

...

вместо перезапуска ПО и перевода всего и вся в безопасное положение. :smile3009:

А вы контролируйте стек периодически, чтобы не переполнялся. :rolleyes:

А если у вас манипулятор переместился в крайнее положение и произошел сбой, то вам непременно нужно махнуть им в исходное положение в непредсказуемый момент времени (сброс), а не замереть?

[aaarrr 63]

По моему, регистры в стек заносятся непосредственно при улете в HF. То есть, определить PC и LR и еще кучу регистров можно точно.

Можно. Но восстановить историю использования SP в функции - нет. Соответственно, и выйти из функции не получится, только вернуться к точке сбоя.

 

А если у вас манипулятор переместился в крайнее положение и произошел сбой, то вам непременно нужно махнуть им в исходное положение в непредсказуемый момент времени (сброс), а не замереть?

А не нужно дергать манипуляторами по аварийному сбросу.

[ViKo 1]

Можно. Но восстановить историю использования SP в функции - нет. Соответственно, и выйти из функции не получится, только вернуться к точке сбоя.

И к выходу из функции. LR