Мне нравится vscode. Но в основном из-за его легкости, расширяемости и универсальности (один редактор для всего), удобством настроек в текстовом файле, а не монструозном ui
К тому же для vscode легко пишутся собственные расширения, что сильно подкупает.
Передавать прошивки (бинарники) можно разными способами, хоть на листочке хексы печатать.
Для таких организаций, где нет систем контроля версий проще в ide, или в редакторе кода настроить форматирование по хоткеям. Или в принципе не заниматься этим. Так как скорее программист единственный и о командной работе над одной кодовой базой тут речи и быть не может. Либо это будет сущим адом.
Очень интересный жизненный процесс: сначала пишем, потом понимаем как работает.
Кажется что должно быть иначе: анализ проблемы, поиск вариантов решения, реализация
Если коротко по тексту:
Были проблемы..
Wiren Board молодцы, дали железяки
Wiren Board молодцы, есть дока
Интегрировали
Wiren Board молодцы
Так о чем собственно статья, где расследование, выводы, приняти решений?
С 485 дешевле и проще наклепать кучу датчиков и устройств, CAN не у всех дешевых контроллеров есть.
Был рефакторинг... Или у вас до сих пор ещё есть жабры и хвост?
Если уж на то пошло, то с таким шаблоном форматирования можно справится регулярками, благо у вас си, а не плюсы.
Заодно можно и легко отсеять все статические функции.
Умеет:
https://clang.llvm.org/docs/ClangFormatStyleOptions.html#allowallparametersofdeclarationonnextline
В чем необходимость компоновки аргументов функций именно таким образом?
Для этого можно использовать clang-format, он может генерировать отчет о несоответствии шаблону. И им же можно форматировать.
Принимайте мои соболезнования
Кодстайл и статический анализ это две разные задачи и не должны смешиваться
Зависит от стандарта языка, который вы используете. Для си >= с2х это не нужно
К слову, typedef не переопределяет тип и не создает тип, а лишь определяет псевдоним.
Да делайте, что хотите, изобретайте кучу странных скриптов и практик. Я вам показал путь без извращений, дальше сами.
Проблема с отображением затененных кусков кода это чисто проблема эклипса, в нем и нужно её решать.
Мне нравится vscode. Но в основном из-за его легкости, расширяемости и универсальности (один редактор для всего), удобством настроек в текстовом файле, а не монструозном ui
К тому же для vscode легко пишутся собственные расширения, что сильно подкупает.
Не призываю использовать, просто делюсь мнением.
Открываете настройки проекта и настраиваете провайдеры для препроцессора.
Отметил только тот который реализует функционал вашей статьи. Остальное тоже посмотрите, думаю пригодится.
Все это делается одной простой настройкой и все ваши самописные мэйкфайлы и константы из них подтягиваются и нормально отображаются а редакторе.
Под капотом эклипс делает тихую пустую сборку и уже на основе этого отображает верно.
Не нужно изобретать, нужно уметь пользоваться инструментом который выбрал.
Но, на мой взгляд, эклипс сейчас наихудший выбор для писанины кода.
Наврядли там чистый js и HTML, скорее куча плохопонимаемого кода, который если написать руками будет сильно меньше.
Передавать прошивки (бинарники) можно разными способами, хоть на листочке хексы печатать.
Для таких организаций, где нет систем контроля версий проще в ide, или в редакторе кода настроить форматирование по хоткеям. Или в принципе не заниматься этим. Так как скорее программист единственный и о командной работе над одной кодовой базой тут речи и быть не может. Либо это будет сущим адом.
Ему место в прекомит хуках, как писали выше или в чем-то подобном.
Какой толк от него в системе сборки?
Вы по одному автору статьи не судите о всей индустрии. Стиль и задачи описанные автором, это чисто его проблемы.
Согласен, что высосано из пальца и всё решается куда проще. Но такой уж стиль автора
*.lst весьма полезен при отладке просто в консоли и без исходников, а вот бин и хекс легко вытаскиваются из элфа