[tonyk_av 40]

Работаю с STM32F446.

Данные идут от человека, поэтому возможные деления на ноль, переполнения и тому подобные неприятности, по которым CPU улетает в Hard fault. Понятно, что попав в обработчик, можно посмотреть флаги FPU, чтобы понять причину попадания и выставить флаги ошибки в пользовательской программе.

Вопрос: как правильно восстановить состояние FPU? Как правильно вернуться к выполнению пользовательского кода?

Ткните пальцем в пример или где почитать.

P. S. Вспомнил, что где-то на форуме Миландра описывалась что-то подобное, поищу. Но, думаю, где-то должны быть описания и примеры обработки.

[_3m 7]

По моему доводить до цугундера Hard fault - плохая идея.
Ввод от двуногих прямоходящих совершенно необходимо проверять в явном виде на корректность, диапазоны и все что вообще можно вообразить (то что нельзя вообразить на всякий случай лучше тоже проверить).

[Obam 37]

Чёт, джентльмены, вы погорячились - сразу Hard Fault - у FPU есть своё законное прерывание, к примеру (на F446 доку поднимать лениво), в L451 за номером 81. И если я что-нибудь в чём-нибудь понимаю, то задаём нужный приоритет, разрешаем в NVIC прерывание от FPU и в обработчике обслуживаем признак(и)-причину прерывания.

[haker_fox 61]

9 hours ago, tonyk_av said:

Данные идут от человека, поэтому возможные деления на ноль

Этой информации недостаточно для полного понимания проблемы

 

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

 

Если же данные вводятся очень быстро, скажем, копированием огромного csv-файла на носитель прибора с последующим его чтением и вычислениями, когда времени на проверку как будто бы и не остаётся... наверное, Ваш вариант, который пытаетесь реализовать, будет уместен. Но тут моя опытность не даёт какого-либо ответа, т.к. не использовал прерывания от FPU.

[tonyk_av 40]

Можно теперь послушать тех, кто изучал математику ЭВМ, численные методы и знает, как обрабатывать ошибки вычислений FPU?

[haker_fox 61]

4 minutes ago, tonyk_av said:

Можно теперь послушать тех

Это в раздел "Предлагаю работу". Там за деньги Вы будете получать только желаемое. А здесь - общий форум. Вправе высказываться каждый.

[tonyk_av 40]

В общем, как обычно, всё оказалось проще и описано у самой СТМ в PM0214. Там же есть и список исключений, который может возбуждать каждая команда FPU.

Странно, что люди выполняют расчёты, но даже не знают, как проверить их достоверность, иначе сразу бы отослали меня к этому РМ.

[haker_fox 61]

1 hour ago, tonyk_av said:

Странно, что люди выполняют расчёты, но даже не знают, как проверить их достоверность

Какое у Вас безосновательное и неуважительное суждение к своим коллегам...

На самом деле непонятно превосходство проверки результатов вычислений посредсвом прерываний. Предположим, что FPU инициировал прерывание по результату, давшему "Деление на ноль". Как мне поможет эта информация именно в прерывании? В чём преимущество? Ведь ровно то же самое я могу сделать в основном потоке ПО. Я понимаю, что прерывание будет вызывать именно в случае какой-либо ошибки, и процессорное время будет меньше тратиться в этом случае на возникшие проблемы. Но ведь в прерывании Вы всё равно ничего не исправите. Данные уже пришли из какого-то канала поступления информации. Поэтому, всё равно придётся что-то предпринимать в основном потоке. Например, выдать на экран соответствующее сообщение.

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

[tonyk_av 40]

57 minutes ago, haker_fox said:

Как мне поможет эта информация именно в прерывании?

В прерывании- никак. Но в прерывании будет выставлен флаг, сигнализирующий пользователю о том, что в процессе вычислений была ошибка и результат вычислений недостоверен.

1 hour ago, haker_fox said:

Ведь ровно то же самое я могу сделать в основном потоке ПО

Готов поспорить, что в МК вы не проверяете статус FPU после вычислений.

1 hour ago, haker_fox said:

Но ведь в прерывании Вы всё равно ничего не исправите

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

 

1 hour ago, haker_fox said:

Поэтому, всё равно придётся что-то предпринимать в основном потоке

Ессно. Самое главное, что взведён флаг недостоверности, а там уж пользователь пусть сам решает, что делать.

[haker_fox 61]

2 minutes ago, tonyk_av said:

Готов поспорить, что в МК вы не проверяете статус FPU после вычислений.

Спорить нет нужды. Я его действительно не проверяю. Но зная Ваш опыт, ведь я же читаю соообщения на форуме, я всё же подумал, что не можете Вы из праздного любопытства спрашивать о прерываниях, и что что-то там в этих прерываниях действительно есть. Поэтому-то я попросил объяснений, чтобы повысить свой уровень знаний. Ибо знать всё невозможно, но пополнять опыт никто не запрещает. Спасибо!

[tonyk_av 40]

24 minutes ago, haker_fox said:

не можете Вы из праздного любопытства спрашивать о прерываниях, и что что-то там в этих прерываниях действительно есть

Практическая потребность.

Реализую рантайм ПЛК. В нём есть флаги, показывающие результат выполнения математических операций. Я ведь не знаю, какую формулу напишет пользователь и какие данные он будет по ней обсчитывать, поэтому для рантайма деление на ноль и корень из отрицательного числа это нормальные ситуации. А есть ведь ещё ситуации, когда в результате вычислений результат потеряет значимую часть или превысит разрядную сетку. Такие ситуации невозможно выявить проверками до начала вычислений, они выявятся только в процессе вычислений, поэтому для рантайма наличие ошибок вычислений в пользовательской программе не должно быть чем-то неожиданным.

Изменено 13 декабря, 2023 пользователем tonyk_av

[haker_fox 61]

4 minutes ago, tonyk_av said:

Реализую рантайм ПЛК.

Теперь всё встало на свои места. Но ПЛК - это довольно узкая и специфичная область. И без пояснений необходимости подхода мало, как я думаю, кто может дать адекватный совет. Лучше сразу подобные нюансы давать в исходном вопросе, либо по мере того, как становится очевидным, что пользователи форума не понимают о чём речь и дают советы невпопад)))))))

[tonyk_av 40]

8 minutes ago, haker_fox said:

Но ПЛК - это довольно узкая и специфичная область

Не такая уж и узкая и специфическая. Дело в другом. Если кто-то выполняет вычисления на FPU в задачах управления, то перед выдачей управляющих воздействий он должен проверить достоверность результата хотя бы с точки зрения математики, а то получит NaN и фиганёт его в виде 0xFFFFFFFF на ЦАП.

[haker_fox 61]

1 minute ago, tonyk_av said:

а то получит NaN и фиганёт его в виде 0xFFFFFFFF на ЦАП.

В принципе, у меня сейчас схожая задача. Только там не управление, а измерительный прибор. Он измеряет переходное сопротивление контактов высоковольтного выключателя (тех, что на электрических подстанциях) в цикле. Длительность цикла не более 200 мс. Данные с двух каналов АЦП (ток и напряжение) пересчитываются на лету, т.е. в реально времени,, и выдаются в ЦАП в виде сопротивления, приведённого к шкале напряжения. Возможно, Ваш опыт будет мне полезен для индикации возникшей ошибки, если такое имело место быть по какой-либо причине🙏

[tonyk_av 40]

54 minutes ago, haker_fox said:

Только там не управление, а измерительный прибор. Он измеряет переходное сопротивление контактов

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