原因1——了解应用程序的基础
许多微控制器供应商在创建客户可以用来开发嵌入式产品的开发平台方面做得非常出色。毕竟，如果他们做所有产品通常做的工作，如编写链接器脚本、启动代码、链接标准库和初始化微控制器，他们的客户会受益。客户可以忽略这些标准代码，专注于更快地编写他们的应用程序，这将使他们更快地进入市场，并在总体上销售更多的微控制器。
问题是，开发人员忽略了底层代码，看不到他们的构建环境是如何工作的，甚至看不到与项目有什么联系!也许更糟的是，供应商编写的代码被开发为通用代码，是一种适合所有解决方案的通用代码。这可能不适用于任何一个特定的应用程序。
创建你的构建环境，在其中编写你的链接器、启动代码、设置C/C++运行时并创建makefiles，确保你了解你的应用程序和环境的基础。你知道有哪些部分和为什么。你知道你用什么汇编和C/C++标志来构建你的应用程序，为什么。事实上，你甚至将了解C/C++运行时环境，以及它如何影响代码大小和执行效率。如果你只是使用提供给你的东西或者回顾那里的东西，你会错过重要的细节。
原因2——代码优化
默认情况下，许多提供给开发人员的构建环境可能是为嵌入式开发而配置的，但它们通常被配置为通用解决方案。该解决方案旨在满足普通开发人员或公司的需求。不幸的是，结果往往是代码中充斥着不必要的库函数，甚至代码阅读起来很复杂。比如看很多厂商提供的代码。它们将包括来自C库的标准系统调用，如printf、_exit、_kill、_read、_write等。使用这些系统调用的最小实现可以很容易地增加10千字节以上的代码空间。对于许多使用大型32位处理器的尖端团队来说，这可能不是什么大事，但是对于嵌入式行业的其他人来说，这可能决定一个应用程序的成败!(从闪烁LED的平台代码创建一个基线项目，并发现它编译了超过60千字节的代码，这并不罕见!)。
原因3——更容易与敏捷和开发运维流程集成
使用敏捷和DevOps是一个必要的过程，在许多嵌入式团队中越来越流行。在嵌入式社区中逐渐流行的敏捷方法包括测试驱动开发(TDD)。DevOps包含的不仅仅是持续集成和持续部署(CI/CD )，但这也是大多数团队关注的焦点。
使用微控制器供应商提供的环境，利用TDD和CI/CD可能会更加麻烦和复杂。这是因为他们没有考虑你交付产品需要遵循的流程，只考虑你需要让他们的处理器启动并运行。结果可能是一个与你的其他过程和需求不太协调的构建环境。很多嵌入式开发团队努力通过变通方法，有时甚至是双重环境来使所有这些过程和工具很好地结合在一起。
原因4——灵活性
有时候，构建系统中有太多的小钩子，以至于定制它要花两倍于从头开始的时间。例如，你可能想禁用一个库，却发现这样做会导致几十个编译错误，迫使你花费数小时来解决这些错误。
一个有用的灵活性方法是IDE灵活性。不同的开发人员对于他们想要使用的ide和文本编辑器有不同的偏好。例如，人们可能喜欢Sublime文本、另一个Visual Studio代码或另一个供应商提供的IDE。开发人员经常争论，试图让他们喜欢的工具成为团队的选择。如果你构建你的环境，每个人都可以使用他们喜欢的工具，这有助于提高嵌入式开发人员的效率。
原因5——构建系统定制
我认为构建自己的C/C++环境的最大原因是能够定制它。没有两个项目是相同的。存在一些共性，但是你可以通过定制构建系统来极大地提高代码大小和性能。有时候直到你从零开始，你才明白需要什么样的定制。有许多定制需要考虑，例如:
使用Docker容器设置的环境
程序集级别标志
C/C++标志
库集成
如何处理启动代码
向量表集成
TDD集成
CI/CD集成
代码分析
等等
定制C/C++环境和构建系统的能力会极大地影响项目的成功。
结论
为你的嵌入式应用程序创建一个定制的构建系统有很多好处。起初，进行这样的努力似乎很复杂，充满了潜在的问题。幸运的是，这个过程远没有你想象的那么复杂。几乎可以在不到一周的时间内为任何嵌入式处理器研究和实现定制构建系统。此外，构建系统是一个经过高度调整和优化系统，它可以帮助嵌入式开发人员为应用程序和构建过程奠定基础，从而为产品提供多年的支持。
