Опыт роста каждого осадного льва всегда одинаков.
Когда я только начинал изучать эту технологию, я надеялся, что смогу самостоятельно делать различные умные изделия.
С этой способностью вы будете более конкурентоспособны и заработаете больше денег, и вы не будете брошены во все более интеллектуальную эпоху.
К сожалению, не все могут дойти до финиша.
Многие люди учатся учиться, но не могут учиться и в конце концов с сожалением сдаются.
Хотя некоторые люди шли разными путями, они выживали с удивительным упорством.
На пути слишком много узких мест, чтобы прорваться, каждое из которых может решить, являетесь ли вы избранным или уничтоженным.
Для инженеров, только что вошедших в отрасль, есть узкое место, которое очень сложно пробить.
Вот как сделать программы, которые вы пишете, более профессиональными.
Долгое время, хотя я и мог сам писать функции, я всегда чувствовал, что мои программы написаны в беспорядке.
На картинке выше написана программа, которую я только что занимался разработкой однокристального микрокомпьютера в течение года, не знаю, видите ли вы какие-то проблемы.
Позвольте мне проанализировать это для вас:
1. Вся программа проекта написана в функции main
2. Слишком много глобальных переменных
3. Отсутствие модульного мышления
Это программная логика этого проекта, и я вот-вот рухну, когда ее переведут.
На самом деле изделие не сложное, это пульт управления солнечным водонагревателем.
Однако, как только они будут объединены, функции будут сильно конфликтовать друг с другом, вызывая изменение проблем тут и там.
При возникновении проблемы необходимо повторно проверить все функции.
Если вы не сталкивались с такой проблемой, вы не поймете важность архитектуры программы.
Качество архитектуры программы повлияет на все аспекты всей программы.
Например, глобальные переменные, эту проблему я тоже понял позже.
То есть глобальных переменных слишком много, и программа выйдет из-под контроля, когда она станет слишком большой.
Во-первых, чтобы избежать дублирования имен глобальных переменных, а во-вторых, если какая-либо переменная не закомментирована, она будет чистой через месяц.
Особенно когда вы определяете глобальные переменные всей функции проекта вместе, это катастрофа.
Однако без глобальных переменных это точно невозможно .
Просто чтобы использовать его разумно , на этот раз проверим опыт инженеров.
как мне это сделать
Возьмем в качестве примера курсовой проект нашего шлюза IoT по программированию микроконтроллеров Wuji.
Я принял концепцию модульного программирования и отделил аппаратный уровень и прикладной уровень от общей архитектуры.
Вообще говоря, есть промежуточный слой, типа парсинг некоторых протоколов, кода в среднем слое проекта не так много, что я упрощаю.
Глобальные переменные каждого функционального модуля определены в своих собственных файлах .c.
По сравнению с программой платы управления солнечным водонагревателем, которую я сделал, хотя количество глобальных переменных, возможно, не изменилось, очевидно, что модульный метод записи более понятен.
Конечно, это не так просто, как сделать код более чистым, но также имеет преимущества сильной функциональной масштабируемости и сильной переносимости.
Сильная масштабируемость звучит как технический термин, и многие новички могут не понимать, что он означает.
Только представьте, функциональный код продукта наконец-то завершен, тестирование прошло без проблем, и оно передано заказчику для тестирования.
После теста заказчик сказал, что хочет поменять функцию, и менял туда-сюда раз 7 или 8. Вы их все порвали?
Это нормально, заказчик — новичок в технологиях, и он не знает, сколько нужно платить за его слова.
Опытные инженеры начинают с того, что учатся быть ленивыми, независимо от того, насколько срочным является проект, это здорово, если у вас еще остается свободное время после завершения проекта.
Здесь важна расширяемость кода.
Теперь поговорим о переносимости.
Портативность относительно MCU (аппаратной платформы).
Например, раньше я делал этот проект на однокристальном микрокомпьютере STM32.Сейчас, когда цена на чип выросла, начальник попросил заменить его на GD32.
На этот раз проверим переносимость вашей программы.
В программах, написанных опытными инженерами, обычно требуется только изменить периферийные интерфейсы аппаратного уровня, а коды функций логики продукта прикладного уровня в основном не нужно изменять.
И Кайдзи, возможно, придется переписать весь код...
Проблема глобальной переменной кажется простой, но если вы хотите ее решить, вам все равно придется думать с точки зрения всей архитектуры программы.
Если вам еще далеко до этого этапа, есть более удобный способ.
Просто используйте структуру .
Используйте объектно-ориентированное мышление для единообразного определения переменных того же типа, что и структуры.
Например, время делится на год, месяц, день, неделю, час, минуту и секунду.
Если вы используете форму отдельной глобальной переменной, она более фрагментирована и сложнее в управлении.
В этом случае удобнее использовать структуру, потому что это все параметры объекта «время».
Подобных много.Например GPIO тоже объект.Параметры включают номер порта,номер вывода,режим ввода,режим вывода,частота и т.д.
Вы можете взглянуть на библиотеку прошивки STM32, которая представляет собой типичное объектно-ориентированное программирование.