Открыть список
Как стать автором
Обновить

Комментарии 8

Тут я напоролся на особенность IAR ARM, а именно то, что он инициализирует статические переменные два раза, в начале программы и непосредственно при входе в main

Быть такого не может. Статические переменные инициализируются один раз. Там на задворках создается флажок в ОЗУ, при следующей инициализации этот флажоки проверяется и повторной инициализации не происходит. Синглтон Майерса инициализируется при первом обращении, по месту. С мейном это вообще не связано. Где вызвали, там и проинициализировалось. А вот глобальные статические переменные инициализируются до main. Если все сделать по умолчанию в IAR вызывается его функция инициализации глобальных переменных. Можно эту инициализацию пропустить, например, если переопределить функцию _low_level_init и вернуть из нее 0, инициализация глобальных переменных пропускается.

С вами мне спорить трудно, знаю по вашим публикациям что вы очень давно в IAR работаете.
Я лишь описал то, что выдал мне отладчик при беглом просмотре, возможно я не так понял и вы правы.
Ладно virtual, но зачем же тащить в микроконтроллер std::map из стандартной бибилотеки, тем более, что номера портов нумеруются числами? Можно обойтись простым массивом, ну или списком наконец.
Просто пробую, эксперементирую, сравниваю результирующий код. А почему нет?
Я вижу две причины не использовать STL.
1. STL занимает много памяти
2. STL везде, где возможно, использует динамическую память.
По моим наблюдениям на основе компилятора IAR
Использование хотя бы одного «new» сильно увеличивает проект, сильнее чем использование хотя бы одного malloc.

Динамическая память имеет обыкновение заканчиваться, что приводит либо к exception, либо к возврату null. Включение exceptions в ембедед — это еще большее разбухание кода. Отключение exceptions — будь добр, отрабатывать все неудачные попытки выделения памяти, причем выделения часто бывают неявными, например, при использовании лямбд.

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

Так как обычно куча является односвязным списком (зависит от компилятора и настроек), то выделение динамической памяти не детерминировано по времени. Это может иметь значение в жестком рилтайме. Т.е. первый байт выделится за 1 наносекунду, а 10001 байт может выделиться за 1 микросекунду.
Спасибо за разъяснение!
Я одно время вообще кучу не использовал в проектах под embedded, сейчас сталкиваюсь с большими проектами, где куча используется.

Вообще, я для себя рассудил так. У меня прошивка без использования кучи под домашние проекты занимает не более 10-20 кБайт. На всех используемых мною камнях памяти от 128 до 512 кБайт. Почему не пожертвовать ей, если это улучшит переносимость и гибкость кода.

Это лишь моё мнение касательно моих проектов, оно может измениться. Повторюсь, ещё совсем недавно я был противником использование кучи в МК для несложных проектов.

Сильное кунг-фу, однако ничего необычного не увидел.
Зачем в hw процедурах приёма/отправки bool res, если он всегда false?

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