Тоже пришел к подобной связке, только вместо CMake->Make, один раз написал файл и он сам ищет все .c .cpp .h .hpp в желаемых папках. И расширение для отладки Native Debug, оно более общее.
Мне нравятся подобные решения, так как имея минимальный набор инструментов можно собирать проекты для любых чипов, любой конфигурации на бесплатных обновляемых инструментах (Для меня это критично, так как использую некоторые фичи С++20, для чистого С обновляемость компилятора не так важна).
Я полностью поддерживаю вашу точку зрения. Как видите, статья была написана 2 года назад и сейчас я считаю такой подход ошибочным. Честно говоря, я думаю, что это был дерьмовый код со всех сторон.
Спасибо за разъяснение!
Я одно время вообще кучу не использовал в проектах под embedded, сейчас сталкиваюсь с большими проектами, где куча используется.
Вообще, я для себя рассудил так. У меня прошивка без использования кучи под домашние проекты занимает не более 10-20 кБайт. На всех используемых мною камнях памяти от 128 до 512 кБайт. Почему не пожертвовать ей, если это улучшит переносимость и гибкость кода.
Это лишь моё мнение касательно моих проектов, оно может измениться. Повторюсь, ещё совсем недавно я был противником использование кучи в МК для несложных проектов.
С вами мне спорить трудно, знаю по вашим публикациям что вы очень давно в IAR работаете.
Я лишь описал то, что выдал мне отладчик при беглом просмотре, возможно я не так понял и вы правы.
Хотелось контролировать питание флэш-памяти.
Рвал землю, потому что так в протеусе были внятные результаты, в обратном случае — нет.
SCK нужно подтянуть, так как команды SPI flash начинают читаться по первому спадающему фронту, что и обеспечивается подтяжкой.(из документации)
НА счёт CS, забыл. В прототипе подтянут был.
Полная аргументация — это тема для отдельной статьи. Если коротко, то люблю копаться в контроллере, а также код получается много быстрее и компактнее. В проект не переносятся ошибки из стандартной библиотеки. Хотя, можно сказать, что они заменяются собственными.
Со стороны бизнеса пока претензий не было.
Куча — не очень хочется тащить системные библиотеки в маленькие проекты.
Динамическое выделение памяти — не очень безопасно.
USB разъём делал по спецификации. Сделал два разъёма на плате, один основной, а другой отрывной по 1мм толщиной. Далее отрывной разъём отделяется, и прикладывается сверху на основной, затем припаиваются к друг другу. Таким образом достигается нужная толщина в 2мм.
Но в продакшене, увы. Когда просят «эзернет за 2 дня», то уже нет времени вдумчиво сидеть и работать с регистрами
Это называется херовая культура разработки, когда лишь-бы сделать быстро, не важно как. К сожалению, во мноких конторках практикуется, но это не значит, что это норма.
Ссылка хоть и на форум, но кидаю именно книжную полку, что важно, с небольшими рецензиями и практически все книги не заезжены, по крайней мере для меня почти все наименования были новы. В основном это книги от среднего уровня и выше. Книжная полка
Вообще, если стоит цель именно продвинуться в области схемотехники, программирования и т.п., могу порекомендовать обращаться именно к книгам, сам всегда учился по книгам, уровень материала там заметно выше, что в общем-то и не удивительно.
И с учётом этого делать акцент в статье на «побочную», в общем-то, фичу — экономию нескольких байт — не упомянув основную… ну как-то странно.
С этой точки зрения вы правы конечно, тут мне и возразить то нечего, а в статью я этот момент добавил уже ранее. Для себя учел на будущее, если взялся тему раскрывать, то описать следует все важные особенности.
Тоже пришел к подобной связке, только вместо CMake->Make, один раз написал файл и он сам ищет все .c .cpp .h .hpp в желаемых папках.
И расширение для отладки Native Debug, оно более общее.
Мне нравятся подобные решения, так как имея минимальный набор инструментов можно собирать проекты для любых чипов, любой конфигурации на бесплатных обновляемых инструментах (Для меня это критично, так как использую некоторые фичи С++20, для чистого С обновляемость компилятора не так важна).
Так как?
Добрый день, cпасибо за комментарий!
Я полностью поддерживаю вашу точку зрения. Как видите, статья была написана 2 года назад и сейчас я считаю такой подход ошибочным. Честно говоря, я думаю, что это был дерьмовый код со всех сторон.
Теперь я перешел на что-то вроде этого: https://github.com/isobchuk/cpp_register (просто пример).
Однако я не согласен с замедлением в 10 раз с виртуальными функциями. Мой опыт разбора дизамблера и некоторые статьи говорят о другом.
И все же сейчас, я предпочитаю статический полиморфизм динамическому при написании универсальных кода.
Я одно время вообще кучу не использовал в проектах под embedded, сейчас сталкиваюсь с большими проектами, где куча используется.
Вообще, я для себя рассудил так. У меня прошивка без использования кучи под домашние проекты занимает не более 10-20 кБайт. На всех используемых мною камнях памяти от 128 до 512 кБайт. Почему не пожертвовать ей, если это улучшит переносимость и гибкость кода.
Это лишь моё мнение касательно моих проектов, оно может измениться. Повторюсь, ещё совсем недавно я был противником использование кучи в МК для несложных проектов.
Я лишь описал то, что выдал мне отладчик при беглом просмотре, возможно я не так понял и вы правы.
Рвал землю, потому что так в протеусе были внятные результаты, в обратном случае — нет.
SCK нужно подтянуть, так как команды SPI flash начинают читаться по первому спадающему фронту, что и обеспечивается подтяжкой.(из документации)
НА счёт CS, забыл. В прототипе подтянут был.
Со стороны бизнеса пока претензий не было.
Куча — не очень хочется тащить системные библиотеки в маленькие проекты.
Динамическое выделение памяти — не очень безопасно.
Это называется херовая культура разработки, когда лишь-бы сделать быстро, не важно как. К сожалению, во мноких конторках практикуется, но это не значит, что это норма.
Книжная полка
Вообще, если стоит цель именно продвинуться в области схемотехники, программирования и т.п., могу порекомендовать обращаться именно к книгам, сам всегда учился по книгам, уровень материала там заметно выше, что в общем-то и не удивительно.
С этой точки зрения вы правы конечно, тут мне и возразить то нечего, а в статью я этот момент добавил уже ранее. Для себя учел на будущее, если взялся тему раскрывать, то описать следует все важные особенности.