[原创] GNU（GNU_ARM_Toolchain为主）编程 记录

这算是前面 那个 Contiki系列的续编。不过，相对来说，我觉得它比较独立。 一直以来，用GCC编程是我的习惯，只不过，那也仅限于PC上的程序。而一旦到了单片机上我就整不开了。 随着前阵子越来越觉得，必须跳出微软这盆大温水，我觉得，单片机开发GNU化是必需的，但这个过程对我来说比较痛苦。毕竟以前我用GCC，所会的几个命令和选项也仅限于编译程序，我甚至连GDB都不熟悉。 而现在，到了单片机上，事情却变得非常凌乱，琐碎，困难重重，没迈开一步都特别困难。 ——然而，有时候，一旦走通了某一步，突然之间，能看到的范围（自己能感知到的范围）也随之变得很清晰，简单。 比如说，在Windows上，为什么经常没办法执行那些开源项目里的make去重新编译? 其实是因为你没意识到Windows的cmd和linux的shell完全是两回事，你没有shell里那些标准的make find这些命令，而为了获得这些，其实你并不需要安装什么Ubuntu,你仅仅需要一个 小巧可爱的 MSYS。 上周末，我几乎什么事情都没干（除了周日一天都在加班）。 周六一天我一直都在倒腾 GNU_ARM工具链，虽然事情还没完，但好歹我总算用它点亮了STM32F3的一颗LED。 后来经过各种折腾，我发现我编译出来的程序比正常用IAR编译的程序少了一截代码。于是我想，终于还是绕不开，我必须找一种方法学习或者理解 makefile ld这两部分里那些我只能看懂一小部分的命令和选项。 而渐渐的我终于意识到 GCC熟悉起来确实需要相当长的时间。而且这方面的内容，除了看一堆英文（有时还因为不明所以，抓不住重点，看到头晕眼花还不知道关键在哪）。而所谓中文，呵呵，还是算了吧，大家都知道国人什么情况。 于是我想，不妨自己努力一把。把这个过程中的一些东西写下来。不敢说什么教程，也不敢说对什么人有用。只希望，我走过的弯路，我曾经百思不得其解的东西，进来看到的人不需要再百思不得其解。也希望有一同爱好的人有个集中的地方一起聊聊，互相帮帮忙什么的。 曾经也想过建Q群——上周末我就脑残一样加入N个标榜着GNU的群，结果到现在我还没听到一句正经话。 Q群是非常不靠谱的讨论技术的地方，所以现在我更喜欢帖子的方式进行。 就说到这吧，下面渐渐来一些如何开始的，个人使用的方法，算是一点经验，不学那些乱七八糟开口闭口开源的论坛，口号太多了，标题党太多了，烦。 本帖最后由 辛昕 于 2014-12-4 00:04 编辑

简单说一下 编程开发需要的工具（链）

我就不扯那些什么乱七八糟的广告，宣言，那些破玩意你爱看尽可以百度，多的是。 对于工具链这个词，我相信，其实......对于用开 VC/VS的你，你很可能从来没有听说过 toolchain这个词。我想对你说的就是。这些IDE（嗯，这里我至少希望你能分清楚 GCC和VC不是一回事，因为前者是编译器，后者是IDE），它们通过GUI界面，把一系列的程序开发所需要的工具都集成到了一起，使用过程简单到就和你平时点点鼠标就能上网一样简单。因此你完全没有意识到在背后到底发生了什么。 ——也许你已经迫不及待的想反驳我为什么要这么麻烦？ 嗯，我懒得解释理由，这确实非常复杂。然而我这么折腾并非因为我和那些喜欢用Linux显示自己很屌很拽的优越感的 人生赢家 一样。我折腾它，如果你非要问，我只想说： 自由。 另一些更深层的技术原因，现在说也是多的，因为我还没能熟悉使用它。所以，不要问为什么，假如你不喜欢折腾，尽可以关掉这个帖子。 在最简单的情况下（对于我们中大多数人，包括我），绝大多数时候，我们需要的仅仅只是一个 GCC编译器，偶尔的，也许你还想学一下GDB。 ——回想一下你在VC/VS下是怎么调试程序的，除了不断的穿插printf，你经常debug么？或者说，你有debug,设断点么——说实话，我还真没。 我之所以debug,那是在单片机下，为什么我debug呢？因为在很长一段时间里，我不懂用串口重定向标准输出流，除了debug，难道你让我看led？（嗯，51时代，那样的事情我确实没少干） 关于GDB——大多数时候大多数人喜欢直接命令行来调试程序，这对于我们中的很多人是非常难以想象的——包括我，我还没怎么用过gdb。 不管如何，我想告诉你的是，其实只要你对这些工具足够的熟悉，最后，其实不管是 以黑乎乎的命令行示人的GNU工具链，还是VC VS看起来非常友好的傻瓜图形界面，其实，它们能做的事情是一样的。当然它们各有千秋，所以，并不是因为谁好谁坏我们才去选择另一个放弃另一个 ——当然，假如你是一个认为 等待盗版是一件很受制于人的事情，假如你认为应该支持正版，但是微软或者其他工具制造厂商实在太贵了，假如你认为有一天你很想知道编译器的编译细节这些很重要的话 ——那么，你和我一样，所以我们当然会认为 GCC比起任何我们所知的傻瓜图形化IDE都要好得多得多，于是我们不辞辛苦地去选择折腾。 本帖最后由 辛昕 于 2014-12-2 22:53 编辑

顶一个

怎么开始

说了这么多，动点真格。
——大多数时候，我是一个喜欢让自己（甚至是强迫自己）试着去体验一些不一样东西的人。
而我相信了解一个东西最好的办法就是 参与其中，熟悉一个东西最好的办法就是让它成为你最常用的工具，动作，熟悉到你每天吃饭上班一样。

Windows还是Linux
坦白说，虽然我早就萌生了逃离微软的心，但我不得不承认，很长时间内，我是难以逃离微软（至少上班时间我是难以逃离的。）
但反过来说，现在很多开源软件，都提供了对操作系统用户的足够尊重。
和其他著名开源软件一样，你当然可以在WINDOWS下使用GNU GCC工具链。

反之，你就没办法在Linux上使用 VC/VS，这就是区别。

命令行 / IDE
是的，你没有听错，使用GCC，同样可以是IDE方式。
在Windows下，你至少有两个选择
1.Dev Cpp;
2.Codeblocks;

特别的，Codeblocks在Linux下也可以使用。（当然，Codeblocks严格来说，其实是一个 开源跨操作系统的 IDE。）

MinGW / CygWin
在Windows下，有两个非常著名的，几乎齐名的GCC工具链，一个是MinGW,一个是Cygwin,我个人使用的是前者，后者我有过一小会的使用经验，然而体验不是太好，也就一直没用。
我只是后来折腾的时候，大致知道了这两者的一个区别。
MinGW,只是一组GNU GCC工具链，被视为Windows下的原生GCC工具链；
而Cygwin则是在GNU基础上，还集成了一些UNIX环境（大致是这么说）。但因为我没怎么用，所以不清楚。

另外值得一提的是。
MinGW似乎更受欢迎。
举个例子，大名鼎鼎的Qt,它的Windows版本中，除了一个针对VS的版本以外，它的GCC版本选择的就是MinGW,
而我们前面提及的 Codeblocks，它提供的bin版本中，唯一带编译器的也是MinGW.


但直到一个星期之前左右的时间，我才理解到这个UNIX环境是多么重要，所幸，在MinGW的工具链中，有一个MSYS,有了它，那些让人头疼的 "make不是可执行命令...."变得不是问题。

现在，摆在你面前的选择，其实是非常多的，你已经看到了。
你可以选择命令行，或者选择IDE；
你可以选择MinGW,或者Cygwin.

最后提一句，为什么我会特别强调Codeblocks，在Linux下也可以使用。
这其实是很重要的。

如果我们特别熟悉的某个工具到了另一个环境下也可以使用，那我们可以节省大量的重新熟悉时间，此外，这种熟悉的东西可以作为我们在另一个陌生环境中的良好起点。
而在这些之外，使用一套完全一致的工具链，对于跨平台目标很重要的开发，其实是至关重要的。

明晚继续......
包括发一些我个人在使用的软件.......

软件最新版并不总是最重要的。
有时候我看到一个软件链接，而不是一个下载链接，我其实经常是很担心的——我就试过，连官网或者官方github页面，我都试过无法下载的情形。

明晚继续等着楼主更新，顺便学学，文中提到了DevC++，我电脑上也装了一个，平常都是写单片机程序，但有时要验证某个算法对不对时会先在电脑上试试，为了避免安装VS这样的“大”软件，就用了DEVC++这个软件，带的就是GCC编译器，一直搞不明白相关的东西，都是当VS的功能用，这下可以跟版主学习了

没看到说什么东西啊。 没太多关系的多说一句吧：不要用codeblock，即使要用也应该只考虑eclipse 本帖最后由 freebsder 于 2014-12-3 03:26 编辑

codeblocks很好啊，eclipse太臃肿了

写的很不错，期待续集。

eclipse确实臃肿，用过一两次，卡的跟什么似的。
对我来说，我对编辑器的 所谓强大功能 要求不大。
可能跟我没写什么大程序有关系。

我最在乎的还是反应快，最不能容忍的就是 卡的一B

最近有点小蛋疼的是编辑器的界面最好漂亮点，为了这个，最近已经甩了 糟糠之妻 npp,换了新情人 sublite text
啥的，妈的，名字都忘了，，，，果然不是糟糠之妻

不过这玩意不是开源免费版本，所以我当然找的破解版
最新的3没啥破解好的，用着不对，直接官网搞了个2的，随便百度个号码就破解了。

哦，需要的话，我今晚一并传上来

嗯嗯，还没传东西.......

写程序时IDE最重要是功能而不是臃肿与否，人工成本比机器贵的太多。 说到臃肿，gcc都不应该考虑，要小，可以用pelles c, lcc，watcom等（我都用过，各有千秋）。 为什么应该要eclipse，两个根本原因：强大的代码处理，比souceinsigte不差的代码解析，工程管理自由，兼容绝大多数开发平台，比如一个产品的单片机端，后太服务端，数据库管理和移动安卓端 ，涉及不同语言不同平台的集成，很方便工程管理和集成调试，不要小看这个功能，现在稍微有点噱头的硬件产品，怎么都会把移动端考虑进去，自然也涉及后台。然后对嵌入式最重要的是eclipse可以支持iar，keil编译器官方插件，gcc不用说有多支持，同时很方便支持jlink，openocd等仿真器插件。仿真器插件跨平台（硬件驱动当然是厂家的事，作为ide只需要考虑自己怎么用好这些功能），支持原生linux，macos下使用。对于编译器，可以很方便的做工程切换，对应仿真器，做嵌入式开发的能拒绝吗？ 另外，freescale的codewarrier，kds基于eclipse，prosessor expert代码生成器也是基于eclipe（能跨平台），ti的ccs全部在eclipse上，nxp的lpcxpresso也是eclipse。 本帖最后由 freebsder 于 2014-12-3 11:02 编辑

多说一点，不要觉得用原始的东西自己就很蓝翔，尤其是所谓命令行，放着更好的东西不用那是傻。呵呵。

怎么说捏？额......
首先是我真的没有去过蓝翔，也没去过山东，虽然我很想试试那里的山东烧饼～～

前面其实说了，使用命令行或者原始的东东，并非是显示自己很屌，或者很蓝翔。

怎么说捏？
简单的说，我觉得这是一种理念的问题。
比如说，我喜欢简单的工具，简单到什么鸟样呢？
简单到我觉得我不在乎它没有所谓的扩展性。

不要说eclipse,说回 VC/VS,它们也是灰常强大，包罗万象。
可问题是，亲，有时候我只是要编译一个小程序呀，我甚至连debug都不用呀......
可是为了这80%我用不到的功能，我却要容忍一个G的下载，编译出来大概是4个G，我的电脑不算配置低了，可是他奶奶的跑起来还是卡巴斯基.......

功能强悍，齐全，兼容性是有代价的。

当然话说回来，这种工具之争木有啥好纠结的。

只能说这是一种理念的不同。
就好比 有人喜欢 富客户端，有人喜欢 瘦客户端。

另外，我个人确实很喜欢黑乎乎的命令行，因为它绝对不会冒出什么让我非常讨厌的多余信息。

OK，就说到这。。。。。。。
晚上我就发软件了，其实现在也特么想继续，但是算了，还是乖乖上班吧，这绝对是要加班的节奏悲剧的年底啊～～

呵呵，随便吧，我也就说说。看你一个人倒腾的挺辛苦（甚至包括很多单片机出身的人），想给大家说说个人认为的便宜的路，看来做单片机的人确实看法不同，我图样图森破啦。你们继续折腾呵呵，我围观就行。

首先上一个 Dev Cpp 这个我记得没有什么独立的官网。但是在大名鼎鼎的 SourceForge有官方页面，你可以在哪里找到最新版本下载。 老规矩，为了避免你打不开无法下载——这个网站在开源代码下载和开源软件下载方面确实极富盛名，但是经常打不开也是常事。 我上一个我自己在用的版本。 本帖最后由 辛昕 于 2014-12-3 21:47 编辑

楼上这个，用的MinGW和GDB
一路next的安装非常方便，用吧。
你用的时候和你用VC6没啥差别，你基本上就不知道你在用gcc

我觉得用这个找点感觉是最好的。

除此之外，我个人觉得这是个非常轻量化的C/C++ ide，也是个人目前最喜欢的在windows下的小程序编译开发工具。

是的——我有过一段时间直接写简单bat脚本，那段时光大概持续了半年左右，后来我无意找到这个软件，发现也挺好，简单，纯粹，体积小。大概是二三十M的安装文件。
安装出来也没多大。

燃后再传一个 codeblocks，这个是带mingw的版本，就不用你自己去设置了，省得还得着疼一阵子。 相对前面的dev来说，codeblocks比较大一点，这是一个号称能满足所有需求的ide, 个人虽然觉得这属于广告不足以取信。而且因为还没展开来用，所以也不太清楚具体怎么回事。 不过鉴于它在Linux也能用，我觉得还是应该一并发上来。 本帖最后由 辛昕 于 2014-12-3 23:01 编辑

差点忘了一个非常重要的东西 MSYS 没有它，在windows下，很多开源库，软件因为可能没有bin文件，只有源码。 而它们大多数采用Linux下的“标准” make编译。 一般的cmd是没办法执行这些命令的。 这也是我很长一段时间无法使用一些开源库而不得其法的地方。 在MinGW官方版本的mingw安装文件里，可以选择安装这个东西的最新版，但是我却无法下完全里面的MSYS文件，因此也无法使用。 所以我搜索了一下，找到一个老版本，一体的安装包，这个版本上可能久一点，但绝对可用。 ——也就是因为它，我才终于有办法编译 ARM官方维护的 GNU_ARM_Toolchain 里的例程，终于用它把LED点亮了。（虽然只是点亮了。。。。。听起来有点奇怪是么，看下文吧。） 见鬼，居然忘了丢哪了。等我找到了再传上来吧～～～ 本帖最后由 辛昕 于 2014-12-4 08:50 编辑

接下来，进入正题。 我们都是搞单片机的。 关于 单片机的GNU方案。有很多 比如搜索百度更容易见到的 Code Sourcery,或者windows下已经做成IDE的 TrueStudio等。 坦白说，这两者我都尝试过。 其中，TrueStudio,我刚学会怎么运行它，跑了一下例程，然而我的主要目的是要从中找一个能用的ld文件而已。 而Code Sourcery一度是我曾经想搞来用的主要工具。 可是它太让人伤心了，我只想要一个 gcc工具链，而非一个完整工具链，因为那是有限制的。 可是最近 CodeSourcery Lite版本，不管是Linux版还是Windows版都已经不能直接下载了，需要发一个什么狗屁邮件，太麻烦了，发了肯定得让你填一堆东西。 后来，我写了一篇博客，一个朋友给我推荐了 ARM官方维护的工具链 GNU_ARM_Toolchain. 它也是一个Lite性质的，只有工具链，没有ide。 但好歹它是ARM官方，我想它应该会比什么CodeSourcery靠谱的多。 于是我下了一个版本，windows下安装都比较简单——当然，现在在Linux下都提供 sh.bin文件，安装起来也要比直接从代码重新编译简单了许多许多。 官方的网页我懒得打开，我先发这个附件，回头慢慢添加。 这两天忙的稀里糊涂，晚上也没怎么做正经事。 我决定剩下的个把小时，继续就着 LibOpenCm3这个 开源库，看看能不能把这套工具链完全打通用起来。 先这样，先传exe. 本帖最后由 辛昕 于 2014-12-4 00:05 编辑