dimka76 42 14 сентября, 2018 Опубликовано 14 сентября, 2018 · Жалоба Здравствуйте. Возник такой вопрос. Можно ли из обработчиков исключительных ситуаций вызывать функции ? Не возникнет ли проблем со стеком ? И еще. Насколько я понимаю, обработчики исключительных ситуаций не могут прерваться прерываниями от периферии ? Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
Forger 17 14 сентября, 2018 Опубликовано 14 сентября, 2018 · Жалоба Можно ли из обработчиков исключительных ситуаций вызывать функции ? Не возникнет ли проблем со стеком ? В целом, такое прерывание не сильно то и отличается от всех других прерываний, поэтому вызов функций в них не запрещен, ведь для ядра нет понятия функция или т.п., но есть НО: Если такое исключение возникло именно из-за проблем со стеком, то логично предположить, что сразу пользоваться стеком не стоит (точнее, таким указателем стека). Также нужно учесть, что для прерываний обычно используют другой стек (точнее, указатель стека), особенно если применяется RTOS. Более подробную информацию лучше см. в документации на выбранное ядро. Насколько я понимаю, обработчики исключительных ситуаций не могут прерваться прерываниями от периферии ? Да, не могут, поскольку приоритет обработчиков исключительных ситуаций имеют наивысший приоритет. Ведь в этом весь смысл таких прерываний )) зы Дабы не изобретать велосипед, посмотрите в сторону уже существует готовых вариантов обслуживания исключений, в т.ч. на этом форуме. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
dimka76 42 14 сентября, 2018 Опубликовано 14 сентября, 2018 · Жалоба но есть НО: Если такое исключение возникло именно из-за проблем со стеком, то логично предположить, что сразу пользоваться стеком не стоит (точнее, таким указателем стека). Вот этот вариант и навел на вопрос. Спасибо, что подтвердили мои опасения. У меня план такой. При попадании в исключительную ситуацию перевести некоторые ноги МК в определенное состояние. И после этого зависнуть в этом прерывании навсегда. А вот для управления нужными ногами у меня есть свои функции. Можно конечно прямо в прерывании через регистры переключить ноги. Но мне кажется, что с точки зрения архитектуры программы это не правильно. Думаю перед вызовом функции заново проинициализировать указатель стека значением из нулевого адреса. Также нужно учесть, что для прерываний обычно используют другой стек (точнее, указатель стека), особенно если применяется RTOS. RTOS не используется и режим работы не меняется. Поэтому указатель один, если я не ошибаюсь конечно ))) Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
Forger 17 14 сентября, 2018 Опубликовано 14 сентября, 2018 · Жалоба Вот этот вариант и навел на вопрос. Спасибо, что подтвердили мои опасения. У меня план такой. При попадании в исключительную ситуацию перевести некоторые ноги МК в определенное состояние. И после этого зависнуть в этом прерывании навсегда. Не забывайте, что ноги могут управляться аппаратно соотв. периферией. Поэтому такие ноги сначала стоит отключить от соотв. периферии, а уже потом переводить в некие состояния. Ну и зависать в исключении навсегда, имхо, не есть хорошее решение. А вот для управления нужными ногами у меня есть свои функции. Можно конечно прямо в прерывании через регистры переключить ноги. Но мне кажется, что с точки зрения архитектуры программы это не правильно. С "точки зрения архитектуры" в обработчике прерывания нужно сделать все, чтобы сделать девайс безопасным. Как можно быстрее! Как именно это будет сделано - вопрос второстепенный. Самое простое - тупо вызвать принудительный сброс всего проца. Вообще, тема исключений - давно избитая, поэтому есть смысл по-смотреть в сторону уже готовых решений. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
scifi 1 14 сентября, 2018 Опубликовано 14 сентября, 2018 · Жалоба У меня план такой. При попадании в исключительную ситуацию перевести некоторые ноги МК в определенное состояние. И после этого зависнуть в этом прерывании навсегда. А вот для управления нужными ногами у меня есть свои функции. Можно конечно прямо в прерывании через регистры переключить ноги. Но мне кажется, что с точки зрения архитектуры программы это не правильно. Думаю перед вызовом функции заново проинициализировать указатель стека значением из нулевого адреса. Предлагаю другой план. Устанавливаем некий флаг "перевести ноги и зависнуть", вызываем программный сброс. Программа при старте проверяет условие "сброс == программный && флаг == установлен". Ну и при выполнении условия делает что надо. Так проще. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
Forger 17 14 сентября, 2018 Опубликовано 14 сентября, 2018 · Жалоба Предлагаю другой план. Устанавливаем некий флаг "перевести ноги и зависнуть", вызываем программный сброс. Увы, на некоторых процах программный сброс != аппаратному сбросу. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
scifi 1 14 сентября, 2018 Опубликовано 14 сентября, 2018 · Жалоба Увы, на некоторых процах программный сброс != аппаратному сбросу. Это уж пусть ТС разбирается. Во всяком случае, на STM32 команда программного сброса физически дёргает ногу RST. И даже не сбросится, если ногу подтянуть так, что дёргание не осилит. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
Forger 17 14 сентября, 2018 Опубликовано 14 сентября, 2018 · Жалоба Это уж пусть ТС разбирается. Да вся эта тема - по сути баян, но раз уж подняли муть со дна, то не грех и чуток погундеть, благо пятница :rolleyes: Во всяком случае, на STM32 команда программного сброса физически дёргает ногу RST. Не совсем - содержимое ОЗУ все же сохраняется. Но это даже к лучшему )) Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
aaarrr 68 14 сентября, 2018 Опубликовано 14 сентября, 2018 · Жалоба Не совсем - содержимое ОЗУ все же сохраняется. Но это даже к лучшему )) А что, POR сбрасывает ОЗУ? Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
Forger 17 14 сентября, 2018 Опубликовано 14 сентября, 2018 · Жалоба А что, POR сбрасывает ОЗУ? У STM32 - не сбрасывает, просто в этом случае там будет "каша". Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
aaarrr 68 14 сентября, 2018 Опубликовано 14 сентября, 2018 · Жалоба У STM32 - не сбрасывает, просто в этом случае там "каша". Честно говоря, не знаю семейств, где бы сброс обнулял содержимое ОЗУ. Хотя вполне допускаю, что и такое встречается. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
scifi 1 14 сентября, 2018 Опубликовано 14 сентября, 2018 · Жалоба Не совсем - содержимое ОЗУ все же сохраняется. Но это даже к лучшему )) Ага, лишь бы возразить. У ОЗУ не бывает сигнала сброса. Ну или это какое-то чудесатое ОЗУ. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
Forger 17 14 сентября, 2018 Опубликовано 14 сентября, 2018 · Жалоба Честно говоря, не знаю семейств, где бы сброс обнулял содержимое ОЗУ. Хотя вполне допускаю, что и такое встречается. Честно говоря тоже, но в свете новых событий обнуление ОЗУ при сбросе становится уже необходимостью :laughing: У ОЗУ не бывает сигнала сброса. ОЗУ бывают разные, в том числе внешние Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
scifi 1 14 сентября, 2018 Опубликовано 14 сентября, 2018 · Жалоба Честно говоря тоже, но в свете новых событий обнуление ОЗУ при сбросе становится уже необходимостью :laughing: Сенсация. Обнаружен способ стащить деньги из кошелька. Для этого нужен физический доступ к кошельку. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
Forger 17 14 сентября, 2018 Опубликовано 14 сентября, 2018 · Жалоба Сенсация. Обнаружен способ стащить деньги из кошелька. Для этого нужен физический доступ к кошельку. Ага, лишь бы возразить. :rolleyes: Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться