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

Ну вот это уже более развернутый ответ касающийся только printf
а то сразу

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

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

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

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

Да ладно, это вы Явы не видели Вот там оверинжиниринг в полный рост.

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

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

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



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

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

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

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

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

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

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

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

Все это перешло в глубокий офф, ибо холивар - "C vs C++" - пожалуй самый бессмысленный и беспощадный холивар у программеров.
Одно время был "ASM vs C", я чуток застал те дремучие времена такого холивара (я про контроллеры, т.е. эмбеддерство, НЕ ПК), тоже самое ))
Придет время, C# или что-то подобное сменит C++....

Короче, вот простое сравнение:
Детишки носятся на велосипедах, подрастают и пересаживаются на мопеды/моциклеты, потом личное авто, а у более успешных личный самолет
Чистый С - это велосипед: для здоровья полезен, укрепляет мышцы, прост как 5копеек - починит даже безрукий. Но далеко на нем не уедешь и тем более не увезешь.
Но другое дело - моциклет и т.д .....

Понимаете о чем?

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

То же ООП вполне себе работает и в сях, просто местами оно похоже на закат солнца вручную

Чистый Си как-то практически остановился в развитии. Особенно это хорошо видно, если сравнить его с плюсами. Плюсы заморозились в промежутке 1998-2011. Однако стандарт 2011 дал уже много вкусностей, сейчас есть стандарт 14, в котором часть вкусностей углубили. Дальше речь идет о стандарте 17, в котором это движение продолжается.

В Си же за последние годы было добавлено крайне мало - навскидку атомики, bcd, может еще что по мелочи.

Ой не надо, я тока что пообедал


Это точно!

На самом деле не так сложно. Правда если использовать более базовые функции из библотеки.
Я делал принты через TCP и UDP -- познакомился.



Нет не понимаю. На Javа предлагаете писать или ХML, а может на Rational Rose?



Да нет никакого холивара. Тот же компилятор для С++ написан на С. Только если писать апликации, то конечно С++ кроет С, а вот с системным программированием пока все с точностью до наоборот. У часового мастера и у кузнеца разные инструменты.



От вас подвигов никто и не ждет. Есть же мы для этого

Однажды у меня был один сотрудник, который писал на Вижуал С. Он к эмбеддед программистам приставал, чтобы признали, что на РС тоже реал-тайм можно писать. С ним соглашались, чтобы отстал. И с вами согласимся.