1. 怎样学单片机编程
要仔细阅读单片机的教材；硬件的基本组成必须要熟悉要理解，基本概念要清楚，单片机基本指令的寻址方式要弄懂，基本指令要掌握。
要购买自己的仿真器和烧写器，也可以自己动手做。
要自己设计开发试验电路板，学单片机必须要学会使用CAD电路设计。
只要坚持，是能学会的。也不是很难。
2. 我要学单片机编程，怎么样学最好啊，或哪里有单片机培训啊
学单片机最有效的方式是“买一块50左右开发板（C51, AVR, PIC, ARM），板上要有LED，RS232串口”+“C编译器（Keil, GNU C）”+“一台有串口电脑（586以上都可以）”+“自已有兴趣玩IC芯片，动手实践”+“英文芯片数据手册阅读能力”。
其中“兴趣”最关键，没事可以想想交通灯怎么控制的，电子广告牌的工作原理等。
3. 单片机C语言培训 应注意哪些学习方法
学习单片机C语言的话，注重多实践，不要好高骛远。
把学习到的程序一个字符回一个字符的敲出来，用来答加深编写代码的印象。用仿真软件看现象，再下载到实际电路板看运行状态。初期编写简单的程序进行仿真，逐渐增加代码量，增加难度。再去网上找一些好玩的程序去学。
建议先看看51单片机的程序，进行模拟。然后直接用STM32系列单片机进行单片机C语言学习及实践。
4. 谁帮我规划一个学习单片机的方案
两种学习思路；
我刚学完单片机，我就说说我导师教我我们的思路吧，首先用AT89S52上手，这是最简单，也是新手最容易上手的。价格便宜，我们学校批量购买就七八块钱一片，零售估计也贵不到哪去。首先搞清以它构成的小系统板的原理图，这是学习的一切前提（你要可以告诉我邮箱，我发给你，还有编程软件，下载软件，LED流水灯，8LED字数码管程序实例等一些程序）编程软件我用的keil3，下载用的Progisp，等到你能用LED8字数码管编出一个时钟程序时，单片机你就入门了。再接着用STC12C5410AD继续深一步学习，现在多说无益，等你入门后自己自然就找到感觉了，而且STC有自己专用的STC下载软件。
另一个学习思路就是：买一本配有光盘的单片机书，郭天祥的《51单片机C语言教程》是个不错的选择，里面有教学视屏，有软件，当然你就可以买他教学的配套系统版学习了，三百多，我有几个同学是这样学的，效果不错。
我觉得已经说得够实际够具体了，希望能帮到。
5. 单片机 学习计划
你好，我是学软件开发的，把我的学习经验和你分享一下吧！其实无论是学什么，只要你学好了深入了都是有前途的，如果只是浮于表面那么学什么都是没前途的！现在来说一下单片机吧，现在学习单片机还是有前途的，虽然说新的mcu层出不穷，但是单片机还是以它低廉的价格，占据着很大的市场！如果你想学习单片机那么你应该有一些基础，例如：c语言、数电、模电，兴趣也是很重要的一点！如果你对mcu从前一点也没接触过建议你刚开始不要从汇编语言和单片机的内部结构开始，而是从c语言来开始，用c语言来编一些简单的程序来控制单片机开发板上的流水灯数码管，这样可以使你对单片机有一个感性的认识，也可以给你一点成就感，但是这只是开始！当你感觉自己已经对单片机有一定了那么，就么就要开始深入学习汇编语言和单片机的内部结构了，郭天祥的 十天学会单片机和c语言视频 挺好的，他讲的是51单片机，你可以跟着这个视频来入门！以后要做的就是不断用单片机来做东西，积累经验，没有最好只有更好，也可以学习其他的机型，呵呵，如果你把51学好了那学其他的就很简单了，最后的忠告：一定要深入学习，要坚持，吃苦！！============================================================================希望采纳！o(∩_∩)o 哈哈，希望共同进步！！%D%A
6. 单片机培训
最好是自己买几本书，再从网上学习，这样花钱少，又会有很大的进步，现在很多的培训班都是骗人的。
7. 快速学习单片机编程的方法
单片机汇编语言编程规范
软件设计更多地是一种工程，而不是一种个人艺术。如果不统一编程规范，最终写出的程序，其可读性将较差，这
不仅给代码的理解带来障碍，增加维护阶段的工作量，同时不规范的代码隐含错误的可能性也比较大。分析表明，编码
阶段产生的错误当中，语法错误大概占20%左右，而由于未严格检查软件逻辑导致的错误、函数（模块）之间接口错误
及由于代码可理解度低导致优化维护阶段对代码的错误修改引起的错误则占了一半以上。可见，提高软件质量必须降低
编码阶段的错误率。如何有效降低编码阶段的错误呢？这需要制定详细的软件编程规范，并培训每一位程序员，最终的
结果可以把编码阶段的错误降至10%左右，同时也降低了程序的测试费用，效果相当显著。
本文从代码的可维护性（可读性、可理解性、可修改性）、代码逻辑与效率、函数（模块）接口、可测试性四个方
面阐述了软件编程规范，规范分成规则和建议两种，其中规则部分为强制执行项目，而建议部分则不作强制，可根据习
惯取舍。
1．排版
规则 1
程序块使用缩进方式，函数和标号使用空格缩进，程序段混合使用TAB 和空格缩进。缩进的目的是使程序结构清晰，便
于阅读和理解。
<TAB>默认宽度应为8 个空格，由于Word 中<TAB>为4 个空格，为示范清晰，此处用2 个<TAB>代替(下同)。
例如：
MOV R1, #00H
MOV R2, #00H
MOV PMR, #PMRNORMAL
MOV DPS, #FLAGDPTR
MOV DPTR, #ADDREEPROM
read1kloop:
read1kpage:
INC R1
MOVX A, @DPTR
MOV SBUF, A
JNB TI, $
CLR TI
INC DPTR
CJNE R1, #20H, read1kpage
INC R2
MOV R1, #00H
CPL WDI
CJNE R2, #20H, read1kloop ;END OF EEPROM
规则2
在指令的操作数之间的，使用空格进行间隔，采用这种松散方式编写代码的目的是使代码更加清晰。
例如：
CJNE R2, #20H, read1kloop ;END OF EEPROM
规则 3
一行最多写一条语句。
规则 4
变量定义时，保持对齐。便于阅读和检查内存的使用情况。
例如：
RegLEDLOSS EQU 30H ; VARIABLE ;
TESTLED==RegLEDLOSS.0
RegLEDRA EQU 31H ; VARIABLE
RUNLED_Flag EQU 32H ; VARIABLE ;
256ms 改变一次RUNLED 状态
RUNLED_Def EQU 10H ; STATIC ;
16*32ms=500ms 改变一次LED 状态
2．注释
注释的原则是有助于对程序的阅读理解，注释不宜太多也不能太少，太少不利于代码理解，太多则会对阅读产生干扰，
因此只在必要的地方才加注释，而且注释要准确、易懂、尽可能简洁。注释量一般控制在30%到50%之间。
规则 1
程序在必要的地方必须有注释，注释要准确、易懂、简洁。
例如如下注释意义不大：
MOV DXCE1COUNTER, #00H ; 将DXCE1COUNTER 赋值为0
而如下的注释则给出了额外有用的信息：
JNZ PcComm_Err ; 假如校验出错
规则 2
注释应与其描述的代码相近，对代码的注释应放在其上方或右方（对单条语句的注释）相邻位置，不可放在下面，如放
于上方则需与其上面的代码用空行隔开。
规则 3
头文件、源文件的头部，应进行注释。注释必须列出：文件名、作者、目的、功能、修改日志等。
规则 4
函数头部应进行注释，列出：函数的目的、功能、输入参数、输出参数、涉及到的通用变量和寄存器、调用的其他函数
和模块、修改日志等。对一些复杂的函数，在注释中最好提供典型用法。
规则 5
对重要代码段的功能、意图进行注释，提供有用的、额外的信息。并在该代码段的结束处加一行注释表示该段代码结束。
规则 6
对于所有的常量，变量，数据结构声明(包括数组、结构、类、枚举等)，如果其命名不是充分自注释的，在声明时都必
须加以注释，说明其含义。
规则 7
维护代码时，要更新相应的注释，删除不再有用的注释。保持代码、注释的一致性，避免产生误解。
3．命名
规则 1
标识符缩写
形成缩写的几种技术：
1) 去掉所有的不在词头的元音字母。如screen 写成scrn, primtive 写成prmv。
2) 使用每个单词的头一个或几个字母。如Channel Activation 写成ChanActiv，ReleaseIndication 写成RelInd。
3) 使用变量名中每个有典型意义的单词。如Count of Failure 写成FailCnt。
4) 去掉无用的单词后缀 ing, ed 等。如Paging Request 写成PagReq。
5) 使用标准的或惯用的缩写形式（包括协议文件中出现的缩写形式）。
如 BSIC(Base Station Identification Code)、MAP(Mobile Application Part)。
关于缩写的准则：
1) 缩写应该保持一致性。如Channel 不要有时缩写成Chan，有时缩写成C
h。Length 有时缩写成Len，有时缩写成len。
2) 在源代码头部加入注解来说明协议相关的、非通用缩写。
3) 标识符的长度不超过12 个字符。
规则 2
变量命名约定：<前缀> + 主体 ; 注释
变量命名要考虑简单、直观、不易混淆。
前缀是可选项，表示变量类型，由于汇编中变量多是单字节变量，所以单字节变量可以不加前缀，对于 bit 和双字节型
变量，使用小写的b 和d 作为前缀表示。
主体是必选项，可多个单词(或缩写)合在一起，每个单词首字母大写，其余部分小写。
规则 3
常量的命名
常量的命名规则：单词的字母全部大写，各单词之间用下划线隔开。
规则 4
函数的命名
单词首字母为大写，其余均为小写。函数名应以一个动词开头，即函数名应类似一个动词断语或祈使句。
例如：Test_Protect， Check_EEPROM， Init_Para
4．可维护性
规则 1
函数和过程中关系较为紧密的代码尽可能相邻。
规则 2
每个函数的源程序行数原则上应该少于200 行。对于消息分流处理函数，完成的功能统一，但由于消息的种类多，可能
超过200 行的限制，不属于违反规定。
规则 3
语句嵌套层次不得超过5 层。嵌套层次太多，增加了代码的复杂度及测试的难度，容易出错，增加代码维护的难度。
规则 4
避免相同的代码段在多个地方出现。当某段代码需在不同的地方重复使用时，应根据代码段的规模大小使用函数调用或
宏调用的方式代替。这样，对该代码段的修改就可在一处完成，增强代码的可维护性。
规则 5
每个函数完成单一的功能，不设计多用途面面俱到的函数。多功能集于一身的函数，很可能使函数的理解、测试、维护
等变得困难。使函数功能明确化，增加程序可读性，亦可方便维护、测试。
规则 6
在函数的项目维护文档中，应该指出软件适用的硬件平台及版本。
建议 1
使用专门的初始化函数对所有的公共变量进行初始化。
5．程序正确性、效率
规则 1
严禁使用未经初始化的变量。引用未经初始化的变量可能会产生不可预知的后果，特别是引用未经初始化的指针经常会
导致系统崩溃，需特别注意。
规则 2
防止内存操作越界。
说明：内存操作越界是软件系统主要错误之一，后果往往非常严重。
规则 3
注意变量的有效取值范围，防止表达式出现上溢或下溢。
规则 4
防止易混淆的指令和操作数拼写错误。
规则 5
避免函数中不必要语句，防止程序中的垃圾代码，预留代码应以注释的方式出现。程序中的垃圾代码不仅占用额外的空
间，而且还常常影响程序的功能与性能，很可能给程序的测试、维护等造成不必要的麻烦。
规则 6
通过对系统数据结构的划分与组织的改进，以及对程序算法的优化来提高空间效率。这种方式是解决软件空间效率的根
本办法。
规则 7
循环体内工作量最小化。应仔细考虑循环体内的语句是否可以放在循环体之外，使循环体内工作量最小，从而提高程序
的时间效率。
规则 8
在多重循环中，应将最忙的循环放在最内层。
规则 9
避免循环体内含判断语句，将与循环变量无关的判断语句移到循环体外。目的是减少判断次数。循环体中的判断语句是
否可以移到循环体外，要视程序的具体情况而言，一般情况，与循环变量无关的判断语句可以移到循环体外，而有关的
则不可以。
规则 10
中断和恢复
中断程序应该尽量短，应该在中断中进行标记，在主程序中处理。但实时性很高的程序段例外。
中断时应该保存所有涉及到的通用变量和寄存器，如 A, PSW, DPTR 等。
规则 11
堆栈设置
堆栈对于程序非常重要，对于堆栈的设置要合理。堆栈太小，在嵌套调用和容易溢出，造成系统故障；堆栈太大，浪费
RAM 资源。为了节约堆栈资源，中断时要求不要保存太多资源，中断嵌套和程序嵌套层数不要太多，尽量不要超过5
层。这就要求合理的划分功能模块。
规则 12
看门狗
看门狗电路用于在单片机死机时自动复位。单片机需要定时向看门狗发送脉冲，俗称”喂狗”。喂狗不可太勤，这样看门
狗没有起到作用；也不可太慢，这样容易造成单片机复位。正确的喂狗应该在主循环中进行，最好是建立一个独立的系
统监控进程。不可以在定时中断中喂狗，应为单片机有时可能会在主循环中死掉。
6．接口
规则 1
去掉没有必要的公共变量，编程时应尽量少用公共变量。公共变量是增大模块间耦合的原因之一，故应减少没必要的公
共变量以降低模块间的耦合度。应该构造仅有一个模块或函数可以修改、创建，而其余有关模块或函数只访问的公共变
量，防止多个不同模块或函数都可以修改、创建同一公共变量的现象。
规则 2
当向公共变量传递数据时，要防止越界现象发生。对公共变量赋值时，若有必要应进行合法性检查，以提高代码的可靠
性、稳定性。
规则 3
尽量不设计多参数函数，将不使用的参数从接口中去掉，降低接口复杂度，减少函数间接口的复杂度。
规则 4
对所调用函数的返回码要仔细、全面地处理。防止把错误传递到后面的处理流程。如有意不检查其返回码，应明确指明。
规则5
检查接口函数所有输入参数的有效性。
规则 6
检查函数的所有非参数输入，如外部数据、公共变量等。
7．代码可测性
规则 1
模块编写应该有完善的测试方面的考虑。
规则 2
源代码中应该设计了代码测试的内容。
在编写代码之前，应预先设计好程序调试与测试的方法和手段，并设计好各种调测开关及相应测试代码。程序的调试与
测试是软件生存周期中很重要的一个阶段，如何对软件进行较全面、高率的测试并尽可能地找出软件中的错误就成为很
关键的问题。因此在编写源代码之前，除了要有一套比较完善的测试计划外，还应设计出一系列代码测试手段，为单元
测试、集成测试及系统联调提供方便。
规则 3
在同一项目组或产品组内，要有一套统一的为集成测试与系统联调准备的调测开关及相应函数，并且要有详细的说明。
本规则是针对项目组或产品组的。
规则 4
在同一项目组或产品组内，调测打印出的信息串的格式要有统一的形式。信息串中至少要有所在模块名（或源文件名）
及行号。统一的调测信息格式便于集成测试。
规则 5
正式软件产品中应把调测代码去掉（即把有关的调测开关关掉）。
规则 6
用调测开关来切换软件的DEBUG 版和正式版，而不要同时存在正式版本和DEBUG 版本的不同源文件，以减少维护的
难度。
规则 7
在软件系统中设置与取消有关测试手段，不能对软件实现的功能等产生影响。即有测试代码的软件和关掉测试代码的软
件，在功能行为上应一致。
规则 8
发现错误应该立即修改，并且若有必要记录下来。
规则 9
开发人员应坚持对代码进行彻底的测试（单元测试），而不依靠他人或测试组来发现问题。
规则 10
清理、整理或优化后的代码要经过审查及测试。
规则 11
代码版本升级要经过严格测试。
8．代码编译
规则 1
打开编译器的所有告警开关对程序进行编译。防止隐藏可能是错误的告警。
规则 2
某些语句经编译后产生告警，但如果你认为它是正确的，那么应通过某种手段去掉告警信息。照着规范系统的学习，不久的将来你也是个高手了。