stm32 Hard fault Опции

[juvf]

часто валиться hf. иногда указывает LR и PC на одно и тоже место.... но иногда на 0х0. Как отловить HF с LR и PC равным нулю?

Код

[Hard fault handler]
R0 = 0x20003d28
R1 = 0x20003db8
R2 = 0x20006230
R3 = 0x20006230
R12 = 0xa5a5a5a5
LR = 0x0
PC = 0x0
PSR = 0x4000000e

[sigmaN]

на вскидку-как можно реже пользуйтесь кейловскими(иаровскими) библиотечными функциями..как максимум-только malloc/free,все остальное заменяйте собственными реализациями

это действительно обоснованный практикой совет или просто по-пугать?
Честно интересуюсь, без стёба.

[SasaVitebsk]

это действительно обоснованный практикой совет или просто по-пугать?
Честно интересуюсь, без стёба.

Да нет особого стёба. Я написал свой printf. Точнее просто сделал п/п вывода чисел различных. В том числе с плавучкой.
Вы же должны понимать как стандартный работает. Там через список передаются параметры и шаблон вывода. Получается, что при обработке тратится значительное количество памяти на стеке.
Но проблема, если честно, не в самом объёме а в том, что это достаточно сильно меняющееся число. Ну и когда у вас несколько задач используют printf, то при анализе размеров стека понимаешь, что его надо увеличивать. В зависимости от сложности выводимой информации, народ указывает размеры до 2к. Вот и получается, что использование printf в трёх задачах - 6к озу.
Применение своих п/п вывода экономит эту память. В моём случае скорости особой не требовалось, так как это происходило при выводе на дисплей, принтер, ну и в HTTP задаче.

Никто не призывает отказываться от стандартных п/п. Просто надо знать инструмент, который применяешь. В случае с printf, надо автоматически увеличивать объём стека ну и убедится что вы выделили его достаточно. В частности FreeRTOS это позволяет делать.

[jcxz]

Но проблема, если честно, не в самом объёме а в том, что это достаточно сильно меняющееся число. Ну и когда у вас несколько задач используют printf, то при анализе размеров стека понимаешь, что его надо увеличивать. В зависимости от сложности выводимой информации, народ указывает размеры до 2к. Вот и получается, что использование printf в трёх задачах - 6к озу.
Применение своих п/п вывода экономит эту память. В моём случае скорости особой не требовалось, так как это происходило при выводе на дисплей, принтер, ну и в HTTP задаче.
Никто не призывает отказываться от стандартных п/п. Просто надо знать инструмент, который применяешь. В случае с printf, надо автоматически увеличивать объём стека ну и убедится что вы выделили его достаточно.

В многозадачной среде можно сделать переключение стека при вызове printf, естественно заблокировав его семафором.
Тогда не нужно закладывать дополнительный объём стека для printf для каждой задачи.

[Forger]

В многозадачной среде можно сделать переключение стека при вызове printf, естественно заблокировав его семафором.
Тогда не нужно закладывать дополнительный объём стека для printf для каждой задачи.

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

Сорри за офф ))

[juvf]

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

Оверинженеринг в вакууме.

[Forger]

Оверинженеринг в вакууме.

Когда ушел в C++ на ARMах, в голый С не вернусь даже под дулом пистолета )))
Разница по размеру кода щас никого не волнует, да и нету там особой разныцы, зато читаемость и переносимость на порядки выше!
Скорость работы тоже не страдает. Я не использую исключения и работу с ними (пока что).
В обязательном порядке стоит ось, причем сделана обертка вокруг нее, чтобы она стала C++, ну, там классы потоков, программных таймеров, семафором и т.п.
Поменяю ось, поменяю обертку под нее, а весь остальной код во всех проектах вообще не изменится.
Так читаемость и переносимость кода возрастает в разы. Нет глубокой привязки ни к ядру, ни к процу, ни к компилятору, ни к оси.
Экономия времени на новых проектах просто чумовая!
Лень-матушка вынуждает так поступать - категорически ненавижу переделывать свою же работу, лучше сразу сделать нормально

[scifi]

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

Это и старый добрый Си умеет.
Вам нравится Си++ - почему бы и нет? Может быть, у меня просто такие проекты, но ни разу не ощущал потребности перейти на Си++. А просто так без причины как-то не хочется.

[Forger]

Это и старый добрый Си умеет.

Это даже можно на асме сделать ))
Тока переход в плюсы - это переход на новый уровень структурного, а не функционального программирования.
Чистый С хоть и позволяет это делать, но с такими ацкими костылями, что боже упаси это недобровольный "секас"

Вам нравится Си++ - почему бы и нет? Может быть, у меня просто такие проекты, но ни разу не ощущал потребности перейти на Си++. А просто так без причины как-то не хочется.

Дело тут вовсе не том что нравится или нет, а в том, что этот инструмент обладает гораздо бОльшей функциональностью и значительно упрощает создание самодокументируемого и легкосопровождаемого кода.
Мне важнее последнее. Ведь в конечном итоге любой код превращается компилятором в т.н. машинные коды.
Поэтому если когда-то появится возможность писать на ARM под С#, я буду это делать, предварительно отключив "тяжелые" вещи, свойственные этим мощным языкам.

Я не буду ручной дрелью ковырять сотню дырок, особенно когда под рукой есть электрическая дрель

[Непомнящий Евген...]

Поэтому если когда-то появится возможность писать на ARM под С#, я буду это делать, предварительно отключив "тяжелые" вещи, свойственные этим мощным языкам.

Шарп без тяжелых вещей будет хуже плюсов банально потому, что в плюсах значительно больше инструментов времени компиляции. Те же шаблоны, лямбды (сахарок над шаблонами), итераторы в for, да хоть старые добрые макросы.

А вот в шарпе приоритет отдается динамике. Опять же очень многие вещи завязаны на GC.

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

Хотя конечно процессоры развиваются и постепенно это будет волновать все меньшее количество людей

[Forger]

Хотя конечно процессоры развиваются и постепенно это будет волновать все меньшее количество людей

Именно! Тут главное - не отставать от поезда, иначе быстро спишут в утиль

[scifi]

Именно! Тут главное - не отставать от поезда, иначе быстро спишут в утиль

Всё-таки чистое программирование и ковыряние в железе - сильно отличающиеся области деятельности. ИМХО, Си - достаточно простой и обозримый язык, чтобы железячник мог им достойно овладеть и строить сложные системы. Си++ уже выползает за пределы этой зоны, такие железячники - уже редкий зверь (вроде Вас). Там, где железо и софт делает один человек, Си никуда не денется.