Надеюсь, неокрепшие умы из статьи запомнять, что перенос глобальных переменных в main высвободит заметную часть ROM.
Вы уверены, что это верный посыл?!
Я не вижу смысла продолжать разговор с человеком, который не понимает, чем чревато использование большого количества локальных переменных, это еще раз говорит о Вашей низкой профпригодности, как разработчика встраиваемых систем. Я все больше склоняюсь, что Вы не далеко ушли от «ардуинщиков». И Ваша статья из раздела: «Смотрите как могут „ардунщики“, который освоили FSM».
Статья Ваша. В целом написана не плохо, но некоторый моменты вводят в заблуждения неокрепшие умы, которые не до конца понимают устройство и принципы работы микроконтроллера (большинство «ардуинщиков»). И эти неокрепшие умы поверят Вам на слово про ~50Байт на каждую глобальную переменную и будут все пихать в стек, пока не получат переполнение стека. Или Вам все равно на таких, что принижает Ваши профессиональные навыки, как программиста микроконтроллеров, или Вы не до конца разобрались и не хотите принять правильную точку зрения.
По процессорам — примерно такая же история с STM32H7, мы начали с ним работать, когда для него ещё в STM32CUBE багов было порядочно.
А без куба никак? И Вы после этого считаете себя хорошим разработчиком?!
Как бы вам так объяснить поближе к вашей области… Видели errata на процессор? Ну не такой уж маленький документ. А теперь представьте, что вся errata пишется на основе того, что мы нашли
Вы себе льстите. Вы прям как ВДВ-шники: «Никто кроме нас».
Ну и сколько фирменных запчастей вы могли купить в любой день в 1993 году? Мое решение продержалось, пока не нашлись деньги на новую клавиатуру.
Не надо мне рассказывать мне о 90-х. Многие сами ремонтировали, исправляя не исправность, а не костыляли, как Вы. Костыляние говорит об низком уровне инженерной подготовки.
Поехали дальше. 1994 год, Pentium FDIV bug. С ужасом обнаруживаете, что тот баг вашего кода касается.
Ваши действия? Напишите в документации, что на пнях с багом программа не работает? Или обойдете баг костылем?
или используете компилятор с опцией Pentium Safe FDIV?
С чего Вы решили, что баг в аппаратной части (как делают большинство недоразработчиков программного обеспечения), а не в Вашем ПО и не все предусмотрели в коде.
Выясню причину и выпушу полноценный патч. А не закрою костылем баг в ПО, чтобы костыль потом стал боком.
Что вы делаете, увидев errata на SoC? Ждете 5 лет, пока производитель исправит? Или обходите чужие баги своими костылями?
Не обхожу костылями, а разрабатываю код с учетом ошибок в аппаратной части. И код разрабатывается так, чтобы при устранении аппаратной ошибки, он не приводил к падению ее и был легко поддерживаемым и модифицированным.
Поехали дальше. Вот есть у вас массив записей измерений за 10 лет. Используется для регресссионного тестирования и многих других вещей. Вы его выкинете? Или будете использовать, несмотря на то, что для его дешифровки нужны костыли?
Эх знаю таких недоархитекторов систем, которые не знают и не умеют создавать системы хранения большого количества данных.
И если нужен костыль — это говорит об уровне квалификации разработчика, который ниже плинтуса.
Эта практика называется совместимость. Вы будете утверждать, что совместимость это плохо?
Это несовместимость. Это закрывание дыр. И это снова говорит об очень низкой квалификации разработчика.
Костыль — весьма не плох.
Костыль — всегда плохо. Костылять могут только оооочень низкого уровня разрабы.
Применения костыля возможно только для проверки гипотезы неработоспособности программы самим разработчиком. А дальше выпускается полноценный патч или новая версия ПО.
Ваше отношение к Git for Windows?
Я использую Git for Linux. Использование Git for Windows, не говорит о хорошем уровне разработчика.
Считаете ли вы, что он «не имеет ничего общего с хорошей работой инженера-разработчика»
И объясните мне, как использования Git может говорить о хорошем уроне разработчика?!
А использование других систем управления версиями говорит о невысоком уровне разработчика?!
Вы, видимо, кроме Git ничего не знаете и не использовали. И это снова говорит о низкой квалификации.
Уберите из статью это фразу: "каждая глобальная переменная в С — примерно +50 байт требуемого ROM."
Так как она в корне не верна.
Поясните почему происходит увеличение прошивки при использовании переменных с различными областями видимости, в результате работы конкретного компилятора и конкретных его настроек, и конкретного скрипта компоновщика. Почему нельзя злоупотреблять локальными переменными, чем это вредит.
А так это выглядит: «я тут ткнул пальцем в небо и решил».
Автор, ответьте на вопрос: «Почему АСУ ТП строят на ПЛК?» В АСУ ТП количество переключений на порядок больше, чем количество переключений лампочек в доме.
Просто Вам внутренняя жаба не позволила потратить много денег. И не надо вводить в заблуждение.
Хороший разработчик предусмотрит замену тем блокам, выход которых вероятен раньше всего по той или иной причине. И, следовательно, в комплект поставки заложит ЗИП.
Хороший разработчик предусмотрит регламентные работы, которые выявит блоки, выход из строя которых наступит в ближайшее время.
Хороший разработчик не будет предлагать делать костыли, этим занимаются плохие разработчики.
Вы путаетесь в своих показаниях.
Диагноз: «Ардуино головного мозга.»
Вы уверены, что именно ПЛК Вы делали?!
Вы все равно не согласитесь с моим мнением, если Вы не уяснили информацию про стек.
Как Вы сильно заблуждаетесь! С таким подходом Вам не стоит заниматься программированием для микроконтроллеров и не писать об этом статьи.
Вы уверены, что это верный посыл?!
Я не вижу смысла продолжать разговор с человеком, который не понимает, чем чревато использование большого количества локальных переменных, это еще раз говорит о Вашей низкой профпригодности, как разработчика встраиваемых систем. Я все больше склоняюсь, что Вы не далеко ушли от «ардуинщиков». И Ваша статья из раздела: «Смотрите как могут „ардунщики“, который освоили FSM».
Не во все ядра Cortex-M входит TPI.
TPI есть во всех семействах Cortex-M?!
Помимо ЕСПД, хорошие программисты используют и другие ГОСТы и стандарты.
А без куба никак? И Вы после этого считаете себя хорошим разработчиком?!
Вы себе льстите. Вы прям как ВДВ-шники: «Никто кроме нас».
Не надо мне рассказывать мне о 90-х. Многие сами ремонтировали, исправляя не исправность, а не костыляли, как Вы. Костыляние говорит об низком уровне инженерной подготовки.
С чего Вы решили, что баг в аппаратной части (как делают большинство недоразработчиков программного обеспечения), а не в Вашем ПО и не все предусмотрели в коде.
Выясню причину и выпушу полноценный патч. А не закрою костылем баг в ПО, чтобы костыль потом стал боком.
Не обхожу костылями, а разрабатываю код с учетом ошибок в аппаратной части. И код разрабатывается так, чтобы при устранении аппаратной ошибки, он не приводил к падению ее и был легко поддерживаемым и модифицированным.
Эх знаю таких недоархитекторов систем, которые не знают и не умеют создавать системы хранения большого количества данных.
И если нужен костыль — это говорит об уровне квалификации разработчика, который ниже плинтуса.
Это несовместимость. Это закрывание дыр. И это снова говорит об очень низкой квалификации разработчика.
Костыль — всегда плохо. Костылять могут только оооочень низкого уровня разрабы.
Применения костыля возможно только для проверки гипотезы неработоспособности программы самим разработчиком. А дальше выпускается полноценный патч или новая версия ПО.
Я использую Git for Linux. Использование Git for Windows, не говорит о хорошем уровне разработчика.
И объясните мне, как использования Git может говорить о хорошем уроне разработчика?!
А использование других систем управления версиями говорит о невысоком уровне разработчика?!
Вы, видимо, кроме Git ничего не знаете и не использовали. И это снова говорит о низкой квалификации.
Так как она в корне не верна.
Поясните почему происходит увеличение прошивки при использовании переменных с различными областями видимости, в результате работы конкретного компилятора и конкретных его настроек, и конкретного скрипта компоновщика. Почему нельзя злоупотреблять локальными переменными, чем это вредит.
А так это выглядит: «я тут ткнул пальцем в небо и решил».
И какой напрашивается вывод?
Просто Вам внутренняя жаба не позволила потратить много денег. И не надо вводить в заблуждение.
Хороший разработчик предусмотрит регламентные работы, которые выявит блоки, выход из строя которых наступит в ближайшее время.
Хороший разработчик не будет предлагать делать костыли, этим занимаются плохие разработчики.