标签: program

Albert Einstein once said , "Everything should be as simple as possible, but not simpler." I would never claim to have his level of insight -- or such an awesome head of hair -- but as an engineer, I wholeheartedly agree with this statement.   It definitely applies when it comes to computer-controlled vision systems for parts inspection. When designing a system, it can be tempting to try and include every inspection that could possibly be done. If, for instance, the machine is already being designed to check whether a bearing is missing a roller or ball, why not also inspect for the roundness of the bearing's housing or even check for surface defects? These extra steps should be simple, because the camera's already there, right?   Wrong. You rarely get anything extra for free. Engineers who work on vision systems know what I am talking about. But sometimes other people erroneously believe that just putting a camera on it constitutes an effective inspection setup.   When adding tasks for a vision system, a major challenge is lighting and camera position. Just because the light is properly set up for one inspection doesn't mean it will be correct for anything else. The result is inevitably some sort of compromise, which is never ideal. Of course, one could add a robot or other device to position all the parts for inspection, but it would add significant complexity and cost.   Another drawback of piggbacking features on to a vision system is that troubleshooting becomes harder with each additional inspection. It's incredibly frustrating to tweak a machine to pass one inspection, only to find that it often causes a malfunction elsewhere in the program.   On my first job, the inspection machinery that I oversaw was set up primarily to check for a missing pin or roller in a bearing. But it was also set up to check several other things that technically were not required or even necessary.   I was eventually able to program all these machines to look only for a missing pin -- with no loss in parts quality, interestly enough.   Later, an outside contractor was called in to update the machinery. He offered to expand its inspection capabilities. I wanted that code to remain as simple as possible. Some of these machines used a PlayStation-like controller for adjustment, so I seriously didn't want to have to do more than was absolutely necessary.   As for making things as simple as possible, but not simpler, an inspection camera shouldn't physically be more adjustable than necessary. To that end, I wish vision companies would start making holes for dowel pins standard on all their products. This feature would simplify the setup, allowing one to determine the precise camera position within a thousandth of an inch or so.   Jeremy Cook is a manufacturing engineer with 10 years of experience and has a BSME from Clemson University.

Albert Einstein has been quoted as saying , "Everything should be as simple as possible, but not simpler." I would never claim to have his level of insight -- or such an awesome head of hair -- but as an engineer, I wholeheartedly agree with this statement.   It definitely applies when it comes to computer-controlled vision systems for parts inspection. When designing a system, it can be tempting to try and include every inspection that could possibly be done. If, for instance, the machine is already being designed to check whether a bearing is missing a roller or ball, why not also inspect for the roundness of the bearing's housing or even check for surface defects? These extra steps should be simple, because the camera's already there, right?   Wrong. You rarely get anything extra for free. Engineers who work on vision systems know what I am talking about. But sometimes other people erroneously believe that just putting a camera on it constitutes an effective inspection setup.   When adding tasks for a vision system, a major challenge is lighting and camera position. Just because the light is properly set up for one inspection doesn't mean it will be correct for anything else. The result is inevitably some sort of compromise, which is never ideal. Of course, one could add a robot or other device to position all the parts for inspection, but it would add significant complexity and cost.   Another drawback of piggbacking features on to a vision system is that troubleshooting becomes harder with each additional inspection. It's incredibly frustrating to tweak a machine to pass one inspection, only to find that it often causes a malfunction elsewhere in the program.   On my first job, the inspection machinery that I oversaw was set up primarily to check for a missing pin or roller in a bearing. But it was also set up to check several other things that technically were not required or even necessary.   I was eventually able to program all these machines to look only for a missing pin -- with no loss in parts quality, interestly enough.   Later, an outside contractor was called in to update the machinery. He offered to expand its inspection capabilities. I wanted that code to remain as simple as possible. Some of these machines used a PlayStation-like controller for adjustment, so I seriously didn't want to have to do more than was absolutely necessary.   As for making things as simple as possible, but not simpler, an inspection camera shouldn't physically be more adjustable than necessary. To that end, I wish vision companies would start making holes for dowel pins standard on all their products. This feature would simplify the setup, allowing one to determine the precise camera position within a thousandth of an inch or so.   Jeremy Cook is a manufacturing engineer with 10 years of experience and has a BSME from Clemson University.

  需要的一些： 对于单片机程序，首先要对于要使用的单片机比较了解，对于硬件设计比较了解，对C编程比较熟悉； 了解单片机是因为当需要设置某些寄存器的时候，会知道相应的设置方式，避免出现因为寄存器设置造成的不必要的调试时间。 对硬件比较了解，因为硬件电路是程序运行的前提，如果硬件电路出现了问题，软件无论如何也跑不起来； 对C比较熟悉，因为过了初始化以后主要工作就是由C来承担了； 对于需要操作模块的了解与设置，知道相应的设置或操作引发的结果。 遗忘的死角：   最近在查看一段代码的时候，发现里边有一个潜在的递归操作，而且没有限制递归的次数。   对于在PC上运行的程序，很多时候是不用担心的，毕竟内存还是够用的。当然对于数据量比较大的时候，还是需要注意。   但是对于在单片机上运行的只有512字节栈空间的uC/OS系统的一个任务而言，如果发生了，很容易造成内存溢出。   确实，有时候使用递归会使问题更容易解决，但是它所带来的资源消耗也是很可观的。由于不知道何时终止，对于内存受限的系统而言，更像是一个定时**。   对于递归的使用，在很多时候还是不建议使用的。   虽然，它是我们C基础教材上经常出现的一种方法，但是它确实在很多时候都不适合使用。   关于Flash初始化及Fatfs初始化： 如果遇到FR_NOT_ENABLED，则是没有正常挂载需要f_mount，挂载成功Flash； 如果遇到FR_NO_FILESYSTEM，则需要f_mkfs初始化文件系统，创建Fat文件系统； 但是如果遇到了f_mkfs成功了，这时调用f_open时，又出现了FR_NO_FILESYSTEM，该如何是好呢？f_mkfs的哪一点漏洞，会造成没有正确的返回？ 关于(3)的疑问，找到了是硬件焊接不牢固的问题。 虽然（3）的问题解决了，但是在f_open的时候，却依旧返回FR_NO_FILE，即使创建文件，也返回同样的错误，为何？ （5）的问题在代码上定位到ff.c的1029行，发现注释是Initialize the SFN entry失败。 分析发现既然Flash可创建文件系统，即可写入，这一步通不过应该不是硬件的原因，可能是软件上的某个操作，导致了不正常的文件，于是重新初始化了文件系统，发现可以。应该是因为初始化完成后，没有关闭文件，导致再一次操作时，一直失败。这个时候需要先关闭文件，再次打开。当然，重新f_mkfs也是可以的。  

  参考《代码大全》及自己编程（C）中的一些错误记录，总结编程中产生错误的一些原因 1．拼写错误 a)        变量名，宏名，函数名等拼写错误，在编译阶段直接报错； b)       变量名，宏名，函数名等拼写为相近的变量名，宏名，函数名等，在运行时出错； 2．逻辑错误 a)        if语句的真值逻辑判断，没有包括全部的条件，或者包含了不需要的条件； b)       选择计算方式时，采用了错误的计算方法； 3．边界值问题（Off-one） a)        if语句判断的边界值问题； b)       while/for等语句的边界判断问题； 4．调用错误的近似函数 a)        函数名相近的函数，调用错误；（过去一段时间常调用错的memset/memcpy） 5．变量初始化问题 a)        局部变量初始化； b)       函数入参的初始化； c)       函数返回值的初始化； d)       释放内存的初始化； 6．编译时的警告问题 a)        参照以前的常见警告列表； 7．版本管理 a)        很重要，需要做好版本管理； 8．可读性 a)        很重要，减轻以后的维护压力；   相应错误导致程序运行时出现的一些问题： 1．拼写错误； a)        内存溢出； b)       出现意外的结果； 2．逻辑错误； a)        对于特定的值计算出现错误； b)       对于某些条件，执行出错； c)       数组越界； d)       内存溢出； 3．边界值问题 a)        部分可归于逻辑错误； b)       数组越界； c)       内存溢出； d)       循环结束时，出现多操作或者少操作一个元素； 4．调用错误的近似函数 a)        内存溢出； b)       计算错误； c)       结果在意料之外； 5．变量初始化问题 a)        大部分时候运行正确，偶尔运行错误； b)       大部分时候运行错误，偶尔运行正确； c)       在有些地方运行正确，在其他地方运行失败；（在某些函数之前，之后，之中） 6．编译器警告问题 a)        影响很严重； b)       影响很小； c)       没有影响；   找到原因的难易 1．拼写错误 a)        在编译时出现的错误，好找； b)       在运行时出现的错误，有些好找，有些不好找； 2．逻辑错误 a)        错误没有出现，不好找，需要特定的条件，因为大部分时候运行正确，只有在特定值或者特定条件出现错误； b)       错误如果出现了，比较好重现，这个时候变得好找； 3．边界值问题 a)        同（2） 4．调用错误的近似函数 a)        一般会导致运行出错，比较好找； 5．变量初始化问题 a)        如果想到了初始化问题，比较好找； b)       如果没有想到初始化问题，十分难找；（因为现象出现随机，比较灵异。一般如果程序出现了比较灵异的运行现象，需要考虑初始化问题） 7．编译器警告问题 c)       重视警告，分析警告问题。   其他一些错误原因： 1．不同类型指针间的强制类型转换；造成数据截断或者错误 2．不同类型变量间的强制转换；造成数据截断 3．调用一些不安全的函数，如strcat等，没有长度限制的字符操作函数；   暂列如上。

One advantage of punched cards over paper tapes was that the textual equivalent of the patterns of holes could be printed along the top of the card (one character above each column). Another advantage was that it was easy to replace any cards containing errors. However, the major disadvantage of working off-line (with both punched cards and paper tapes) was that the turn-around time to actually locate and correct any errors was horrendous. Generally speaking, if you make a programming error on one of today's interactive systems, the system quickly informs you of your mistake and you can fix it almost immediately. By comparison, in the days of the batch mode, you might slave for hours at a teleprinter with a card puncher attachment, march miles through wind and rain to the computer building carrying a one-foot high stack of cards, only to hear: "We're a bit busy at the moment, can you come back next Monday?" So you left your cards with the operator and spent the weekend in delightful anticipation, but on returning the following week to collect your results, you'd probably receive a few inches of computer printout carrying the words: "Syntax error on card 2: missing comma". Arrgggh – if the computer knew enough to tell that there was a missing comma, why didn't the callous beast know enough to stick one in for you? The result was that debugging even a trivial program could take weeks and weeks. In fact, by the time you eventually got a program to work, you were often hard-pushed to recall what had prompted you to write it in the first place! Although punched cards are rarely used now, we endure their legacies to this day. For example, the first computer monitors were constructed so as to display 80 characters across the screen. This number was chosen on the basis that you certainly wouldn't want to display fewer characters than were on an IBM punched card, and there didn't appear to be any obvious advantage to being able to display more characters than were on a card. Similarly, long after interactive terminals became commonly available, the formatting of certain computer languages continued to follow the rules laid down in the era of punched cards. To this day, many assembly languages have unnecessarily restrictive rules along the lines of "Labels can only occupy columns 1 through 8." Even the first high-level languages such as FORTRAN (an abbreviation of "Formula Translation") had comparable rules. As a final example, consider the case of the program called SPICE (Simulation Program with Integrated Circuit Emphasis) , which is used by engineers for evaluating analogue circuits. The first generation of this program appeared commercially around the beginning of the 1970s and its descendants are used to this day. The point is that it is still common practice to refer to the data used by this program as a "SPICE deck", which is a hangover from those times when such data was stored using punched cards ("deck of cards" – get it?). Perforated paper products never die... Finally, a word of caution. Perforated paper products never die, they simply fade away. Although the halcyon days for paper tapes and punched cards were certainly the 1960s and 1970s, do not be misled into believing that these media have completely exited the stage. In those days of yore, it was easy to spot anyone who had anything to do with computers, because their offices, briefcases, jacket pockets, and hands were usually overflowing with reels of paper tape and decks of punched cards ( "Holy paper products, Batman" ). However, although paper tapes and punched cards may seem delightfully antiquated, many institutions, including universities, continued to use these forms of data storage well into the 1980s, and both techniques are still to be found in the odd technological backwater to this day. Indeed, paper tapes continue to find a role to play in certain hostile environments. For example, in some manufacturing and heavy engineering facilities, computer-controlled machine tools may be located close to strong magnetic fields and electromagnetic noise. Many of today's storage technologies (such as floppy disks) tend to be corrupted in these conditions, but, much like the Energizer Bunny in the television commercials, paper tape products (especially modern varieties formed from materials such as Mylar) keep on going, and going, and going, and...