本文目录一览：

人有多大力就办多大事”，STM32的功能远比51、AVR之类的单片机要强大得多，相对来说开发的产品功能比较大，代码也会比较复杂。

首先有完整的框架是非常必须的，我个人认为这里的框架有两层，一个是在STM32上移植现有的操作系统或者一些稳定的代码框架，另外一个是自己的编程风格。

你想很方便的开发相对复杂的东西，建议你首先在STM32上移植一个小型操作系统或一种框架，然后在操作系统之上编写你自己的应用去开发产品。在没有操作系统或框架的情况下开发是非常麻烦的事情。要做到条理清晰的话，那就应该去迎合操作系统或框架的风格去编写代码，这答案并不唯一。 举个简单例子，现在比较热门的STM32F103或STM32F407开发产品，一般会移植一个ucosii或rt-thread操作系统（当然也有移植linux或android的，但我个人很少见），ucosii我没实际开发过我就不说了，像rt-thread这样的实时操作系统，它具有多任务编程，那么我们就需要迎合它的特点，比如我串口作为一个线程，LCD、LED扫描作为一个线程，数据采集作为一个线程，键盘扫描作为一个线程等等，在他们的线程中只各自做自己的事情，然后在增加一个顶层的线程专门来负责处理其他线程所产生的消息事件（或者给其他各线程发送消息事件），顶层的线程是作为一个中心处理线程来合理安排和处理其他各个线程的消息事件。

至于在这方面的提升，只能是通过实践来达到效果，这里的“实践”不是说要完全自己去摸索，你需要有东西来借鉴，因为现在一些操作系统、或框架、或编程风格都是比较成熟，你直接拿来看，看看别人是怎么写的代码，然后自己再去仿照着能不能写的出来，再分析里面的优缺点。你要是还在学校且资源有限，建议你可以花个几百块钱上淘宝买一个开发板，一般的开发板都有各个外设的实验，以及综合实验，或许还会有操作系统或框架的移植和使用

这个问题太笼统，这个需要具体问题具体分析。多的就不说，以我的经验和一般情况说下面几点。

1、中断问题。

中断函数要写得尽量短，而且要保证是顺序执行，一定不能在中断中有等待的语句，比如在中断函数中要等待某个标识位置位while(Flag == 0);之类的语句是不可取的，因为会在中断中执行的时间过长导致长时间不能进入别的中断，程序会跑飞现象。

2、敏感代码问题。

可能某些代码的地方，我们不希望执行某部分代码过程被中断给打断，那么我们会在执行该部分代码时禁止中断，执行完毕后再开启中断。那么必须要保证该部分代码执行的时间要尽可能的短，保证短到什么程度由CPU特性决定。

3、阻塞问题。

如果应用比较大，要实现的功能和执行的任务很多，那么程序中尽量避免使用等待阻塞之类的语句，如while()判断标识位的语句，最好是用if()语句判断，如果if()条件不成立会接着往后执行，看有没有别的事情做，如果没有则再返回接着进行if判断。

4、中断优先级问题。

有些CPU支持中断嵌套，而有些CPU不支持中断嵌套，不管CPU支不支持中断嵌套，要合理安排中断优先级关系，比如51单片机中使用定时器中断刷新LED(或LCD)显示，同时串口中断接收数据，默认状态下定时器比串口中断优先级更高，那么最好把串口中断优先级设置得比定时器更高更保险一些，相比之下漏掉一个串口数据比少刷新一次LED(或LCD)后果更严重。

5、代码框架结构问题。

其实这才是最核心的问题，如果你的CPU要实现很庞大的功能，如CPU要完成串口收发、I2C数据存储、LCD显示、Flash读写、USB接口通讯、按键识别、IO口电平监测等等等等的功能，那么自己直接裸机写程序那是不太现实的，必须要选择移植一个成熟的代码架构或操作系统，如选择状态机代码架构，操作系统如uCos、eCos、RT-thread等等。这种方法对CPU的处理速度、Flash空间、RAM空间的需求是挺高的，如果是51、52之类的单片机那就不要考虑算了。51、52之类的单片机那就根据自己的需要自己设计一个简单的代码架构即可。

rt-thread是中国人自己开发的实时操作系统，和ucos类似，rt-thread可以移植到STM32上跑这个系统，rt-thread在发展阶段花费了大量精力和时间让这个系统更好的在stm32系列芯片上运行。

两者的关系有点像 安卓和手机，一个是操作系统，一个是硬件。