数码小叶

要说MSP430编程方式选择，实际上估计没有多少人用库，个人觉得这个就和TI有关了，库的通用性太弱，不是支持所有器件，参数太复杂，和ST没法比，也可能和TI的库出现不久有关吧。所以花时间去适应库觉得意思也不是很大，所以430一般更倾向于寄存器操作，一是没那么复杂，二是，每个模块都有例程，上手也不难。
另外，TI的Grace本来是个很不错的开发工具，可惜貌似被放弃了，然而ST却推出了类似的CUBE，让开发大大简化

zgf004494

没有用过函数库，一般都是参考列程+ PDF ， 调完程序，再也不回头看，  希望 有更多函数库这样参考性更多，通用性强

rowen800

寄存器开发缺点：程序可读性差、开发速度慢，但执行效率高点。库函数开发是 趋势，代码易读，移植性好。

xunke

用库比较方便，然后再优化。

DavidZH

底层+库，必须的，搞起

huaiqiao

1、针对楼主提出的问题，以前我也有此疑问？
为什么430要像51一样，如此麻烦的操作寄存器，没有更加简单的方式？ 后来接触到32我才发现，其实库函数的本质还是在操作寄存器。这个只是相当于“站的高”一些而已；
以前刚开始接触430的时候是f149，属于比较经典的老款单片机了。写代码的时候，要一遍看用户手册，一遍在iar中敲代码。
其实如果是经常用430的工程师，可以将一些常用的寄存器的操作封装成函数。这样直接引用函数就好。这个思路其实我在最近学习2530的时候想到的，可能我自己比较笨，也许有更好的办法。

上次我跟一个网友交流说，现在比较新的430的片子有库函数了，不过我听了以后没有去深究。

2、既然提到IDE，那么ti在430 这块的话，开发环境据我了解还是以ccs和iar为主。说实话，ccs我没有碰。原因是因为它很大，动不动就几个G。。。。听说它很强大，但是对于我来说，我不想浪费电脑空间。所以就选择了iar。。。。

3、当然从开发的方便的程度来说，库函数开发可能会更加容易上手一些，或者说更加方便一些，这也就是我身边的几个同事都偏向于使用32，而非TI的430或者飞思卡尔，以及小日本的额瑞萨。如果ti能把这块做的像32一样漂亮(说实话，新的库我没有接触过哦)，从低功耗的角度来讲的话，会更加的受欢迎。
寄存器，这个最底层的东西。因为debug的时候，一看就知道，语句操作寄存器操作的对不对？

我是奔着插线板来的，评不到的话，其他奖品留给其他网友。哈哈，就这么“无耻”。O(∩_∩)O哈哈~

ketose

       用库函数，还是使用寄存器，这个话题经常看到在很多论坛都有讨论。喜欢用寄存器的说：库函数效率低，不能了解低层。喜欢用库函数的说：寄存器开发代码看起来晦涩，开发效率低，开发复杂。总之是公说公有理，婆说婆有理。
        在我看来不能一概而论，首先任务事物的发展都要经历从低级到高级，从简单到复杂的这么一个过程。单片机软件开发也不例外。从最初的只能用汇编写，到现在可以使用C来写代码，再到可以使用C++来写代码，再发展到现在可以使用脚本(Python)来写.无不是多少软件硬件工程师努力的结果，其目的只有一个：就是希望简化单片机开发难度，提高单片机开发效率。
        我们再来看单片机的发展，从最初的4位机，到8位机，到16位机，再到现在普遍使用的32位机，单片机的硬件也是超来超复杂，寄存器也从原来的十几个到二十几，三十机到现在的近百个。刚开始编程可以使用寄存器，我们能记住那么区区几个寄存器，可是越到后面寄存器越来越多，我们已经无法记住所有寄存器的使用方法。但是我们人类是聪明的动物，我们会总结过去的经验，把一些比较模式化的寄存器操作封装成一个一个的函数，而且起一个比较直观的名字。以后使用的时候，我们只需要调用一下以前总结的函数，不用一句一句的写寄存器了。库函数就这样诞生了。哇，人类又向前迈进了一步。。。
        接下来我们再来看看软件的发展，现在比较流行的Arduino,为什么能火起来？ARM为会么要致力推广Mbed？为什么单片机也要跑操作系统？回答这个问题我们先得了解下Arduion和Mbed,使用过这两个系统的人都会为它们的简单而折服，我不需要有很深的单片机知识，我一样能让我的四轴飞行器飞上天，一样能让两轮平衡车站起来，我只需要有数学知识和一点点电路知道就够了。这就是Arduion和Mbed努力的目标。就是因为软件工程越来越复杂，一个人的能力是有限的，所以我们要分工合作，熟悉低层的人可以来写低层驱动。熟悉算法，但对低层不熟悉的人可以来写上层业务算法，术业有专攻这样岂不更好。库函数是对寄存器操作的封装，而Arduion和Mbed在库函数的基础上更进一步抽象，使得单片机也面向对象，更符合人们认识事物的逻辑。哦还忘了说一个最重要的使用Arduion和Mbed写出来的程序，移植性更好。虽然现在MSP430还只是发展到库函数，但是总有一天也会像Arduion和Mbed看齐，我希望看到那一天的到来。
        总结在单片机硬件越来越复杂，性能越来越强的情况下，我们会优先选择开发更为简单点的方式，在能满足要求的前提下，我们应该优先选择Arduion和Mbed，然后是库函数，最后才是寄存器。当然使用Arduion和Mbed的同时我会穿插使用库函数，使用库函数的同时我也会穿插使用寄存器，也并不是那么绝对。既然人类已经进入了信息化工业时代，我们为什么非要回到石器时代呢？

jishuaihu

个人其实更喜欢用寄存器来操作各类MCU，430当然也不例外，好处嘛，当然就是能够更清晰的了解内部寄存器的结构，理解每一个制定的具体意义，这样基本上可以确保不会有多余的操作步骤，对于一些有严格操作顺序的寄存器，在学习寄存器的定义的时候肯定也就注意到了，避免了误操作之后再去找原因。同时，使用寄存器操作的代码文本量一般回小一些，执行效率一般也会高一些。不过呢，使用寄存器操作的缺点就更多了，首先就是意义不明确，时间稍微一长就记不清到底表示说明意思了，为了解决这个问题，不得不去写一大堆注释，或者弄一大堆宏定义来表示寄存器的意义。其次，使用寄存器操作在跨平台移植的时候也很麻烦，上述的工作又得重新来一遍，在更好新平台之前需要重新了解一遍寄存器，并且都更改了。
  话说回来，喜欢归喜欢，但我现在大多时候也在用库函数，意义明确，使用方便，移植也方便，稳定性也比较好。至于效率低的问题，对于现在性能不断提升的MCU来说已经不算说明问题了。谁也不会把芯片的性能用到极致，否则升级的时候可能就麻烦了。
  最终观点，实际使用的话更推荐使用库函数的方式，但喜欢以学习为主的童鞋们多了解一下寄存器的知识，这样对理解芯片的核心部分有好处。

yaoyuanytu

个人感觉还是库函数比较方便些 理由1.库函数比较直观，方便简单集成度高  初学时候比较容易掌握各个需要的功能直接调用，省去了编写大量基础操作指令 理由2：库函数比较整齐简化，方便移植和交叉使用 理由3：寄存器指令虽然是最底层最核心的东西，但是需要的时候需要大量的基础操作，势必会增加工作量。

mark86739851

如果要求实时性比较严苛的地方直接操作寄存器是比较节省时间的，如果这时候用一大堆库函数就不太合适了，但如果实时性要求不高的地方，大可放心的用库函数，一来能减少工作量，而来能避免出错，可移植性也大大增强了

wudianjun2001

个人还是比较喜欢寄存器的，占用的存储空间少，但用库的话会省很多事情，阅读起来也方便，两者结合使用，效果更佳

woody_chen

个人觉得MSP430没必要用库编程。
1）430没有什么复杂外设（如USB、Ethernet），寄存器配置起来还是比较简单的。
2）由于430存储空间小，不可能像M3一样寄存器都统一编址。这导致库不能统一。
我都是参考TI的示例寄存器代码稍微修改一下。
麻子照镜子，个人观点。

飞翔荷兰人号

需要自己精确把控的一些内部资源，寄存器用起来还是比较顺手，但是一些复杂外设，像UART、USB这些，直接用库函数也很好

LeoMe

初学的时候从寄存器+技术手册开始会让你受益匪浅，430是这样，stm也是这样，这些简单的微控制器其实寄存器布局和外设控制方式都很相似的（不信你去对比各厂商的timer的寄存器），这对你以后接触学习其他处理器和找硬件bug是很有帮助的

那么到了实际应用中，对于简单控制应用，寄存器+库函数结合起来效率更高，也可以尝试模仿官方库函数自己去写一些外设驱动（学习如何标准化接口和传递数据），如上面的兄弟所说，纯寄存器编程有利于压缩代码体积和压缩430唤醒后运行的时间，而遇到高级外设比如USB，函数库帮你跑赢deadline。

说到这个话题，从我接触16位MCU开始发现大家都会去纠结这个问题，特别是刚入门甚至还没入门的兄弟。其实这就跟论坛里问“现在是学stm32前景好还是学DSP好还是学FPGA前景好”这种问题差不多，有时间你都学都接触一下，自己找最适合自己的，或者找你所在地最好就业的，去智联搜一下相关职位描述的关键词试试，会帮你找到自己的答案。

库函数和寄存器各自的有点恐怕是一言难以盖全的，恐怕具体到某一行代码具体讨论都不为过。大方向是你要权衡1执行效率 2编程效率 3可移植性 这三点。我也经常鼓励刚入坑的兄弟们多动手动脑，在过程中自己找答案，而不是遇到问题就开始求助，重要的是解决问题的思路而不是解决问题的结果，前者才是你将来涨工资的基石。

笑鸟007

还是，比较支持库函数，库函数容易上手。易读性、移植性等会更高。另外现在单片机的运行速度，flash等都比以前有了很大的提高，所有利用库函数开发也不要太担心执行效率的问题（当然特殊的要求还是利用寄存器）。当然再利用库函数的时候，一定要对寄存器有所了解，才能高效的开发应用。

辛昕

昨天看到这个题目的时候，我的第一反应是，这玩意跟MSP430无关。
毕竟STM32开始，首开此风，从那以后，其实各种单片机，尤其是后来新出的，基本都走这条路线，因为不走这条路线就没法好好活。
大家都喜欢快，不喜欢自己研究，学习。仿佛一夜之间，大家都进入了深圳模式：
买来一个芯片，其实我们动都不想动，就想直接贴近我们自己的板卡上，然后加上自己的代码（我突然发现了什么，感觉这是一个好套路）
然后就可以卖钱。

但是我后来忘记了，其实直到现在为止,TI的芯片，例程是有，还相当丰富，可是，类似ST这样的库，实际上并没有。

对于库开发还是原始的寄存器开发这个问题。
其实早在STM库横行的时代，就有了两拨人。

一拨人是坚决反对库开发，我其实可以理解他们的心情——说实话，这个库的质量如何我们不评论，但是用起来真的比较痛苦。
这也是下面我重点讨论的：
你觉得层次清晰，封装明白，似乎很多宏用着很方便
那真的只是你觉得而已。

另一拨人，坚决拥护使用库，讨厌寄存器。
这也不难理解，君不见，51之后，再无一款单片机的寄存器是你可以把握的了——当年，我真的背过8051的寄存器和指令集，我真的背了下来。
你现在别说让我去背，你让我去看STM32的寄存器我都没心情。

所以实际上，我相信我和更大的一群人是一样的。
我们坚固两者，而我个人是以库为主，遇到问题或者实在有瓶颈需要休整的时候，再去参考寄存器。

donydong

库函数更加稳定和规范，虽然开始用msp430的时候直接用的寄存器形式，但是现在mcu编程已经逐步往库函数方法发展，这个趋势是不可改变的，做技术也要紧跟潮流！

辛昕

现在是一个比较 见仁见智的问题了。

前面说了，STM首开外设库，说实话，真的是一大好事。
别的不说，区区在下的编程风格和习惯，最初就来源于它的教育和启发。

而其他家，其实也有类似的东西，只是像它这样封装成一个完整的独立的库的并且坚持到底的，实在不多。
或者可能只有他一家。

TI其实例程相当丰富，但其实和其它许多家一样，它们都只是一套很分散的底层内存映射机制而已。
和ATMEGA 也就是 大家熟知的 Arduino，其实基本是一个套路。

它们的做法和ST的内存映射机制是不一样的。
从我个人的角度来说，我更倾向于ST库的机制，因为它符合了我对封装和构建数据结构的一种基本原则：

利用语法本身的特征去模拟事物的物理特征。

这里不展开，因为这里的讨论重点不在于谁家做的好，谁家做的不好——我现在真的非常厌恶这种讨论。
何况，好与不好，各有各的看法，不便强求。

我只说一点：
那就是，ST也好，Arduino.TI也好。
当然也包括像Cypress这种，直接提供一个图形配置工具。

后来其实ST也出了类似的 CUBE配置工具。

说实话，这种 图形配置工具真的大大简化了我们很多工作。从方便实用角度来说可以说很完美。

但是，对于单片机来说，底层配置的方式，其实决定了很多东西。时序是否精准，软件的一些IO速度，负荷瓶颈、
好吧，或者我不得不承认，这些其实都不是重点，性能越来越不成为纠结的地方了。

但是单片机的移植和编程涉及了大量的这种底层的打交道。
所以，一个好理解的底层真的非常重要。

前面说了，各家，不管是ST这样一个完整的库，还是TI这种以例程来提供。
他们的做法大相径庭，我前些年看ST看得多，我已经习惯了他的套路，等到我切到CC2540的时候，我不得不重新熟悉一套新的思路。
然后我又切到nordic的nrf51822，于是又一套思路，更惨的是，这货居然提供了两种不一样的封装，而你如果直接把这些例程拼接在一起，往往会出现各类问题。
编译的冲突，运行起来外设的冲突.......
结果最后你往往宁可自己重新从最基本的外设寄存器做起。

说起来，我到现在才真正明白以前的自己有多令人讨厌——
我总是试图推行自己觉得好的方式，好的编码方法，以为自己可以造福大家。
实际上，就是因为我这样的人多了，才今天我推出这种方法，明天他推出那个框架，最后大家无所适从。根本没时间做正事，只能疲于学习新架构新框架，这貌似也是现在PC WEB上常有的苦逼事情。

而ST TI这些厂商推出的例程，库也类似、
他们都太有个性了，太坚持自我了。
每个人都不愿意使用最直接地方式。
总是喜欢标新立异，我很认真的说，我希望有FAE或者原厂工程师看到我的这段话。
真正站在我们的角度替我们考虑问题、
不要卖弄你们的外包团队的代码技巧或者其实很繁琐不实用只是看起来很方便的封装方式。

对于这个话题，我没有认真梳理，所以说的有点乱，但我相信我想表达的意思一定已经足够表达出来了、
我直接摘抄我昨天回答朋友这个问题的回答。

来直接结束这个话题吧。

辛昕

cube 以前上一版的st库，然后这还只是stm系列地芯片，好了，换一个厂家的，甚至换一个系列地，每一家地做法都不一样，而且还特别有个性，最后就苦了我们这些开发者……
相信我，身为一个曾经也试图发明一套良好封装去应付所有单片机，所谓的通用单片机驱动架构的我，最后发现，再没有什么比直接简单粗暴一层bsp到寄存器更加简单了。
虽然不代表这是最好的方案，但是我现在坚信，直截了当，少封装所谓中间层，hal层是最好的，比如我眼下就不时切一个mcu，每次我看到又是一种不一样的底层封装方式，然后我一个一个函数一个一个宏地解开之后，赫然发现只是一个寄存器操作而已的时候……
移位就1>>3就可以了，不用专程来个 #define bv(n) 1>>n
然后千万不要做各种套路的宏，大量使用#
这种复杂转来转去的宏包裹，我都能看懂，我也觉得很精彩，我以前也很喜欢这么玩……但是我现在真的就觉得累，写个寄存器而已，直接一个函数包起来不行吗？
换一个板子而已，一个项目下来能有几次？直接换一个bsp会死啊？
真正该花心思想的是地方都不在这里。
所以你们就不要再折腾我们了……

anqi90

新上手还是用库会方便一些，但是想深入研究的话最好还是利用库的代码（如果有的话）研究一下具体的实现方式
不光是如何操作寄存器实现功能，很多编程的方法和技巧都是值得借鉴的

其实所有能接触到的别人发布出来的代码都有可能会给你提供一些学习的机会，最简单的就像用if(a==0)还是if(0==a)，后者就能避免浪费了半天时间去找为什么a的值始终是0结果发现只是手抖少写一个等号...