我做程序员的手记
我做程序员的手记
做为学过自动化的我来说，能够搞一些与自动化相关的东西，我感觉很高兴。做为研发人员，能够有机会最近距离接触一个公司的核心技术，我也感觉到很高兴。做为一个程序员，能够让程序代码按照自己的意愿在一个产品的功能上全方位表现出来，我感觉到更高兴。
现在很多人在搞嵌入式系统，我也在这个行列，这一点以前从来没有想到过。我虽然喜欢编程（比如做PLC），但对单片机懂得很少，因为读书的时候一直都是想：反正这辈子不想搞单片机与DSP什么的。对于以前根本不懂嵌入式系统的我，花了几个月做一个项目，感觉还是能学习到一些东西的。写下我第一个项目的一些相关数据，用来以后做个纪念和给自己向新的目标奋斗的鼓励：头文件14个（不包括公共的头文件，1400多行），3900多行；程序8个模块，14300多行；液晶显示界面250多个。做编程也有好几个月了，说一下自己做编程的体会：
如果你以前写的程序最多从来没有超过一百行，那么当你某天写的程序超过一百行时，你一定会感觉：哇，这个程序挺长的啊，原来我可以写出这么长的程序。一旦你的程序突破了一百，那么一百行与九百行给你的感觉差不多是一样的，你此时很想的是要突破一千行。当你的程序突破一千行时，你会有不同的感觉。因为那是站在一个不同层次，量变从而质变。如果你的程序突破了一千行，那么一千行与九千行给你的感觉差不多也是一样的，你此时很想的就会是突破一万行。当你的程序突破一万行时，你又会有不同的感觉，下一步目标就是突破十万行。如果你有十万行以上的编程能力，那么看几万行的程序你会毫不费劲。可能有时你回过头看自己的程序，都不相信自己可以编那么长的程序。因为要你一下子说出里面所有的逻辑，估计你不一定可以做到。但再长的程序也是一行一行编出来的。
一万行的程序，就是你自己写的，看着也感觉累的。然而它的大小只不过是170KB左右，而一张普通的BMP图可能都1MB-2MB，甚至更大。你可计算一下一个电脑系统的程序大概多少行了。一个普通的电脑系统，就算它700MB吧，700*1024/170*10000=42164705，大概四千多万行，虽然那是很多人一起完成的，但也够恐怖吧？如果电脑的CPU的运行能力不在一秒钟能够运行几亿次的层次上，这个系统是根本运行不了。这就是为什么现在电脑的CPU总是在不地追求提升主频的一个重要原因了。下面想提一下我编程时遇到过的一些问题，用以提醒自己以后少犯错误。如果刚好有朋友也搞一行，刚好我的某些话可以给你一些启示，那就最好不过了。
关于看门狗的问题
除非你很自信，认为自己的程序没有任何问题，不会出现跑飞现象，你就可以不用它。但如果你做不到，你就要用到它。看门狗很听话，前提是你管得很好，也就是你能够正确的喂狗，否则它就会找你麻烦。它会复位你的系统，让产品不能正常干活。俗话说：你不复位它，它就复位你。它就这么牛！当你发现狗复位你的系统时，表明你的程序肯定是有问题的。但
要找到问题所在，有时往往很难，特别是程序比较大时。你得通过仿真器，首先试探性的放断点初步判断出在哪个模块，比如：键盘模块，保护模块，通讯模块，采样模块等等里看门狗复位了系统。当判断出在哪个模块时，范围就缩小了很多。接着你得判断在哪个函数时，，再接着判断在哪一行的前后。然而，就算你精确到了哪一行看门狗进行了复位，并不代表你就解决了问题。因为往往那一行的语句很可能是没有任何问题的，很有可能是在别的地方，比如头文件里某个参数的设置上引起的。我曾经被看门狗烦过好几次。我认为一个好的程序，一个喂狗程序就够了，也就是在一个地方喂狗就够了。
关于差1的问题
这是一个刚开始编程的都很容易犯错的问题，不管你细心还是粗心。这个问题的后果可能有时并不重要无关紧要，但有时是崩溃性的灾难性的。就因为某个地方差了1，会让你几万行程序几乎完全作废。我就犯过这种错误。就因为有一个地方应该是>的我写成了≥，这就是典型的差了1的情况，结果导致通讯失败。通讯一失败，每台机只能单机使用，对于不能停机的生产线来说，这台机就是作废的，没有任何作用。做为编程的，我一直认为差1问题多数时候都是一个非常严重的问题。
关于第三状态的问题
我以前一直认为一个开关只有两种状态：要么是合闸，要么是分闸。就是当听到高手说开关还有第三个状态：未知状态时我都感觉很奇怪。什么是未知状态？一个开关难道能处于不分不合的状态？可是，一个开关真的有第三个状态。如果没有，就会出错！我在这方面也得过教训。假设开头处于合闸是1，处于分闸是0，那么这个开头就会有一段时间内不是1也不是0的。原因就是你不可能让CPU一直处理开关的状态，CPU的时间总是要进行切割的，一段时间内处理这件事，一段时间内处理另一件事。所以在不处理开关状态的时间内，开关状态就是处于第三种状态：未知状态。
关于地址操作与口操作的问题
地址操作与口操作差别是很大的，但往往也会出问题。有些管脚是既可以做为地址操作与口操作的。并且你用的硬件很可能都在某些引脚既要地址操作也要口操作的。这其实算是一种某种形式上的冲突，处理不好很容易出问题。假设你的显示程序需要到某些引脚做I/O口，但另一方面你的采样程序又需要到这些引脚做为地址，这时你是需要释放这些引脚的地址的。否则采样程序不能通过地址的方式访问到需要访问的空间，于是你的采样程序就不起作用。如果你能意识到是因为这个原因造成的，恭喜你，省了不少麻烦。但是，我就没那么好，在
这方面就栽过跟头。当时又是怀疑程序，又是怀疑硬件，吃喝都不香郁闷了好久才最终找到原因。
关于EEPROM的问题
EEPROM就像电脑的硬盘，可以存储一些数据，特别是一些需要掉电保存的数据。然而，它用起来可比用硬盘复杂得多多了。电脑的硬盘你格式化过后，你就可以往里面放东西，想拷东西出来也很方面。EEPROM你得规划好哪些空间放什么东西，也就是什么地址开始到什么地址结束。如果你划的空间比你要存储的小，那么你肯定有些数据是不能保存的，这时也许不仅仅是数据是不能保存的这么简单了，很可能看门狗就会复位你的系统，特别是你定义的结构体中夹杂些不需要保存的数据，看门狗是绝对会这样做的。
关于堆栈的问题
其实堆栈不是一个整体，堆是堆，栈是栈，这个概念估计就是学计算机的也有部分没搞清楚的。堆区一般由程序员分配释放，栈区由编译器自动分配释放。但通俗些讲，堆栈就像一个仓库，只是临时放数据的一个地方。所以，这个堆栈能大些还是有好处的。这就好比你卸货，先放到仓库，再搬到别的地方。就像如果仓库都装不下了，这时肯定有些货就得放在外面被雨淋风吹日晒一样，如果堆栈太小，就会有些数据在规定时间内进不去，或者能进去但速度太慢，这时你的系统就受到影响了。堆栈曾经给我上过一课。曾经在一段时间内，应该有一个月左右，遇上一个莫名其妙的问题，百思不得其解：液晶显示的不是乱码，就是乱七八糟的数据，完全不是我想要的。最后知道原因，仅仅是因为堆栈设得太小了。
关于if与else的问题
用好一个if与else不是问题，但要用好很多的if与else这就是一个问题。程序一庞大了，if、else if与else相互嵌套，嵌套一多，你就会很容易模糊每个成立的条件。最容易模糊的是else，因为else成立的条件是除了if以外的所有条件。如果这些所有的条件中，有一个不属于esle的范围，那一定会出问题。当你幸运时，问题不大，但更多时候你可能不幸运。我在这方面交过学费。举个例子，假如从A去B有两条路线，路线1与路线2。问你从A去B 有几种可能性。你如果用if判断是路线1或者路线2后，再用else去执行另外一条路线，你感觉这种判断没有任何问题，但这是错的，因为还有一种可能性是：可以不去。可能这个例子不是很恰当，但你用else的时候一定要小心。如果不能算清else里面究竟包含多少种情况，那么，解决这方面问题最好办法就是只用if，只有让条件恒成立时才执行。通过这一点，都可以看出编程永远要有非常清醒的头脑与非常严密的逻辑能力。
关于BUG的问题
BUG是程序的一个漏洞。程序有BUG很正常的，没有BUG才感觉非常可疑。任何人编程，都仅仅是尽量做到没有BUG而已，能不能做到又是两回事。再牛的程序也可能有BUG，只不过是很难发现而已，也就是说那个BUG成立的条件的概率非常之小，所以就算你反复测试，都不一定能发现到。只有很了解程序的人，才更可能找到BUG。黑客就是那样的人。往往一个匪夷所思的现象就是因为一个BUG引起的。程序有BUG我经历多了。BUG同样有些时候是无所谓的，但有时候就是摧毁性的。避免BUG，唯一的方法就是在编程时做到非常清晰程序每一行的成立条件是什么，这一步是做什么的，又是怎么实现的，等程序做好后，再经过大量的测试，特别是边缘测试。
我记得部门经理曾经说过一句话：“单片机不会骗人，你叫它怎么做它就做。如果有问题，一定是你的程序有问题。”真是这样。经常你盯着程序半天没有找到毛病，然后说：“我的程序没有问题啊！”可是，你错了，因为别人一过来就发现了程序的毛病。证明自己检查自己的程序时，大脑里往往有一种潜在思想：这行是检查过的，没有问题，直接往下一行。所以检查程序问题时最好不要有惯性思维。
做嵌入式系统才刚刚开始，真不知道自己以后能走到什么地步。但真的希望自己能够可以做到熟悉地用DSP与ARM来做嵌入式系统，最好还能有机会接触到FPGA与CPLD。所有刚开始做嵌入式系统都与我共勉吧！