ВходНаше всё Теги codebook 无线电组件 Поиск Опросы Закон Четверг
21 ноября
1152179 Топик полностью
Связанные сообщения
Важно
Нашел статью по отмывке плат фреоном. Сильно хвалят за качество и экономичность. Кто -нибудь использует? У нас стоит на складе м...2022-08-01
[OS]2021-12-08
Спасибо! Однако страшно стало. Если "newlib" каждый раз под новый MCU переписывать, пусть даже с 10го раза будет навык это делат...2021-12-06
я удивлен и сильно обрадован.... оказываеццо есть все таки надежда и свет в нашем стаде эмбеддед програмеров! Вы почти точно выр...2021-12-06
Evgeny_CD, Архитектор (06.12.2021 23:30, просмотров: 659) ответил klen на свежак KGP для мелко армов:
Так, возможно, возможно, я понял, о чем говорил Мастер Klen. И вообще смысл С++ в embedded. 

Пусть будет небольшой кусок кода. Объект, поля, методы. С++ компилятор переведет это в асм весьма эффективно. Я когда-то писал, что в 2002-2003 годах был у нас проект на ARM720 от Sharp с LCD 320 x 240. GUI был от создателя uCOS. GCC был 2.9х Вычитывание кода низкоуровневой части GUI и оптимизация особозачетных мест повысила скорость вывода на экран за 2 недели работы программистов порядка 15 раз (там был вывод большого количества мелких объектов на экране). Разгоряченные программисты решили натянуть компилятор на asm, и за 2 недели натянули....на 10% ускорения кода. Очевидно, что современный GCC имеет существенно выше эффективность кода.


Важно, что этот кусок не страшен, его можно понять.


Если правильно использовать фишки C++20, то компилер сможет из нашего кода сделать обобщенный объектный код (вот тут, если я правильно понял, начинаются фундаментальные отличия от С), который при сборке может быть оптимизирован до предела. Все что можно выкинуть, будет выкинуто. Все, что можно использовать повторно, будет использовано.


Строим сложную программу из кусочков.


Если мы хотим использовать абстрактную сущность B, она, почти наверняка, потянет использование абстрактной сущности А (и еще много чего, но не важно). И наш код может скачком вырасти. Пример https://caxapa.ru/1152046.html


Но если у нас использована сущность C, которая тоже зависит от A, и код A система сборки удачно переиспользовала, то прирост кода может оказаться небольшим.


Самое важное в embedded - построить правильный граф зависимостей сущностей друг от друга. Чтобы минимизировать количество сущностей и повторное использование кода.


Не стоит даже мечтать, что без рихтовки можно взять какую-то универсальную embedded либу, и она влезет в 32к FLASH при использовании "на всю катушку".


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


Добившись влезания кода с запасом на целевой код, мы начинаем писать целевой код.


Критически важна роль Мастера Klen'а. Он помогает построить граф сущностей, одновременно подрихтовывая базовую библиотеку. Целевой программист все это тестит и примеряет отобранные сущности на решаемую задачу. Критерии могут быть: чтобы влезло, скорость разработки, или использование внешнего кода, если это по каким-то причинам критически важно.


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


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


Продвинутые тулзы, которые очень важны.


1. Построитель графа сущностей. Чтобы он показывал не то, что вообще есть в библиотеке, а реальный использованную часть.

2. IDE, которая показывает одновременно C++ и asm. Не файл листинга, где наш код стоит рядом с асмом, а в удобном виде в окошках. Есть такие?

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


HAL живет и отлаживается отдельно. И он есть в двух вариантах - боевой и для симулятора.


Все, кроме HAL, пишется прикладным программистом, и им же отлаживается на симуляторе с силуяторным вариантом HAL.


Ситулятор такой надо делать по технологии статической компиляции. Всасываем elf файл проекта, и тупо каждую команду асма в C строку. Потом компилим. В отдельных потоках симуляция памяти (со статистикой), DMA, timers, контроллера прерываний. GDB stub. Если уйти от интерпретатора, и не гоняться за совсем уж cycle accurate, то на обычном многоядерном ПК сотни МГц реального MCU можно симулировать.


Блин!!! Я 15 лет шел к такому пониманию C++. И вот сегодня Мастер Klen дал мне и всем нам пинок под зада в нужную сторону, и картинка сложилась.