只为uC而生，uS成长历程 7

辛昕

只为uC而生，uS成长历程 7 [复制链接]

新的一周开始了。
随着我们的 uS v0.1释出，接下来，我们要实现的是 我计划中的 通信控制台 部件。
这里简单解释一下。

控制台，这个名字 模仿 电脑上的 终端，也就是windows下的cmd，linux下的 bash shell.
如果接触过linux，那么，你最先敲的一定是命令行，那个黑乎乎或者白花花的窗口也许让你恐惧（还好，在ubuntu 10以后的版本里，它变成了让我陶醉的深紫色。）

不管你诅咒它还是盲目热情地崇拜它，我只想说，这个控制台实际上简化了我们入门linux——对于新手而言，在linux下安装软件可不是一件容易的事情，当然那是在以前，现在这种情况得到一定改善。
至于windows，它以图形化操作界面著称，然而一些早期接触电脑的人来说，一定不会忘记在黑乎乎的cmd下，一步一步敲入地址，打开软件的经历——我刚开始学习pascal的时候，老师在黑板上写的第一块内容就是打开 turbo pascal的地址。

这个简单，乃至让人恐惧生厌的 界面（我们也叫他 控制台，英文是 cosole）为何如此重要？
因为它是你的机器在刚开始什么交互软件都没有的情况下，通过一些非常原始的通信口（比如串口）对机器下达指令，并查看输出结果的 媒介。
它的意义在于：
它简单，容易实现，而且一般是给这台机器赋予其他进一步功能，软件，包括让人心旷神怡的点鼠标就可以轻松穿行于不同的文件夹，不同的软件，网页之间的 基础。

[ 本帖最后由 辛昕 于 2013-8-5 20:36 编辑 ]

辛昕

而到了我们这个简单的uS框架，你也许会很惊讶。
神马神马！你说神马，就这么一丁点单片机，黑乎乎的东西你要实现一个console!!
你没听错。
然后你开始想象一个屏幕，额，不，对于单片机来说，能驱动一个一两寸的液晶条就很不错了，那也不错啊。然后你想象你要输入各种复杂的命令

打住打住。
不错，我是要实现这样一个console，但是，console指的是一种通信管道，并不是非要黑乎乎的命令行终端盒巨大的液晶屏。

同时如你所担忧的一样。
单片机的资源极其有限，不能这么浪费。
否则就是买珠还椟。

那么，在我们这个uS框架里，这样一个console，它应该是怎样子呢？
我来为你描述一下
我们采用的通信管道是几乎所有单片机都不会少的 串口。通过它和电脑232通信。
我们将在电脑上采用到处可见的 串口助手 来作为我们的（临时）终端。
说临时，是因为它有许多不足，同时不满足我们的特殊定制要求。因此，最终，我将在命令行下通过windows的API写一个 真正的 串口通信终端（目前，我已经掌握了这些API最基本的串口收发功能，只是不够完善。另外，如果有一天我能得到一些帮助或者我自己有时间，我将把这个工具做成简单的 图形化软件。）

而这样一个console它又有什么作用呢？
首先，以往，我们写单片机程序，因为不同于PC，可以使用printf的方法向屏幕输出调试信息，我们只能用 断点和查看 内存上的内容 去 做调试，通过仅仅查看程序运行效果来判断是否通过验收。

实际上这种测试是非常脆弱的，这种调试方法也是很不足的。

诚然，在某种情况下，直接断点查看内存值，的确是一件非常简单和省事的事情，然而当我们试图实现测试自动化和daily化的时候，这种方式就会非常困难和痛苦。
另外，某些测试，是这种断点查看绝对无法完成的。
比如说你要密集地去用一组数据轰炸一个通信口的性能（吞吐量测试或者成为压力测试亦可），或者你要定时地记录一个重要标志在什么时候异常......

我相信你会想到很多种方法，比如构造缓冲去存储。这事我常干。
然而一次一次地实现，你难道不辛苦吗？
难道你不得仍然通过断点停下来去查看内存值么？
那么，测试期间你如何继续频繁地 修改程序和测试？

所以，为了实现自动化测试以及更全面的测试，我们需要一个通信管道，使程序在正常运行时能向外输出我们需要的调试信息和测试结果。

此外，它的存在也是类似于C语言里的 标准错误信息流 stderr。我们永远无法预测我们什么时候需要它向外输出什么异常信息，或者直接在运行时，通过输出某些信息来追踪它当前的运行状态，是否出错，错在什么地方......
在现场，你是绝对没有机会重新烧写程序，进入debug模式下查看内存值的。

所以，这个console管道应运而生，非常重要，以至于需要位列 uSCore。

[ 本帖最后由 辛昕 于 2013-8-5 20:39 编辑 ]

辛昕

今天白天开始我就在回想，昨天那个整理帖子的过程里，没能解决那个“最有技术性的问题”
——不要让Apper来实现把 从 uS带出来的，比如说那个 TimrTaskLisk函数 向 定时器中断里 丢的事情。

当时我思考再三，认为“这近乎是个不可能任务”：
因为，这些从uS中带出来的函数，本来就是要在Apper中由开发者决定具体放在什么地方调用的。

然而我忽略了一个很重要的细节。
虽说如此，但我总是通过一个本地的函数指针承载这个 来自uS的函数地址。
因此，实际上，不管我的Apper将在何处调用，我总是可以在一个地方完成这个向 本地函数指针的转移。

当然为了实现更自动化的过程。
我决定通过函数指针的方式向uS提供，使得这个 指针转移也在 uS内部完成。

大家会注意到，这个时候，过去的uSPoster真的已经没有意义了。
当然，它会在uS里面有意义，只是他已经不能再取这个名字了........


但是，今晚不再花时间去做这个改动，我们把它押后，我们首先继续思考和开始着手实现我们的 console部件。

虽然我总是不断的引用编程大师的话：
一个好的设计总是往复循环的，但所谓事有急缓之分。
我也怕再反复下去，一而再，再而衰，那就可惜了。

因此，只在这里做一个说明和记录 就此划过。

[ 本帖最后由 辛昕 于 2013-8-5 20:40 编辑 ]

辛昕

这个console，它的预期功能，首先最直观的就是可以接受简单的命令，并执行然后返回结果——
它可以是 英语式的——如果有字库，我甚至可以使用汉字，但这个不太实际，暂且忘记他，能看到英文我已经很满足了。

于是乎，我们了解到，这样一个console它至少包含两个要求：
1.它能连续接收一串数据；
2.要设置一组简单的命令解释功能；

-------------------
除此以外，我们也要保留最简单的纯数据通信，也就是 原始字节通信，或称RAW通信。

不过我们很快就发现了一点。
实质上第二点功能可以归入第一个功能的一个子集。

于是实质上，我们只有一个大的功能。
而经过上面的分析，我们也已经完成了大概的任务设计。

1.首先我们要完成 基本的串口数据串收发（单片机和PC之间）；
   而在那以前，当然我们首先要完成基本的 单字节收发（因为绝大多数裸机单片机，串口不存在一个缓冲区域，其缓冲一般都是一个SBUF。）
2.命令解释和返回结果功能；

辛昕

作为一个基本的串口收发，对于任何一个单片机，这往往是极其简单的一件事情，而且一般成为熟悉这个单片机的一个入门例程，因此，在此我们首先不去关心它。

我们要从更高的层次上去首先实现这个东西的框架。
但我们要选择一个合适的切入点。

在连基本的数据串收发完成以前，去谈论和设计命令行是没有意义的。
因此，我们的切入点就是 数据串 收发。

注意到这同样是一个实现在uS内部的功能。

第一步，当然是串口的初始化（基本的收发，一般而然，接收都需要或者说必须中断，因为接收是一件突发事件。当然，有的时候，发送也需要中断，以减少CPU的枷锁。）
第二步，如同前面所说，我们的发送函数和接收函数实质上都是通过特定寄存器完成的，然而，这些功能在uS内部也需要。因此这两个都是需要嵌入内部的 注册函数。

一般而言，我们都会通过读写缓冲来实现 通信本身和对信息的处理机制，而在这个地方这个方法不仅要沿用，还变得非此不可。

最后一点我们要特别注意。
对于任何通信过程，都会有 接收 和 发送，因此，这个console并不是非得串口实现不可——这也是为什么我没给它取名 串口console的原因。
因此，我们必须时刻想到，我们也许会用 以太网口来实现，也许会用无线通信来实现。

关键在于我们的 初始化函数，在我们的收发注册函数。
因此实现的时候一定不能做任何先验性的假设。

辛昕

我们进一步往下考虑问题：
现在我们假设我们已经实现了基本的单个字节的收发功能——因为这实质上真的很简单。

那么，我们如何把这个实现扩展到 字符串的收发呢？

我们知道 发送这个过程对于MCU来说是主动的，因此，它想发什么就发什么，发多少就发多少，想什么时候发就什么时候发。
对于MCU它是已知确定的行为，因此我们不需要操心。

但是接受就不一样。
首先我们不能假设我们接收数据的长度——我见过一种蹩脚的做法就是 愣是选择一个字符串最大长度。结果明明有效数据只有三个字节，他愣是填充了无意义的27个字节——另外，为了区分他的有效信息和无用信息，他还不得不设置一套属于他自己私有的字头——从而加重了它的处理函数的负担。

这么做只是为了一个目的：
因为它必须以接受的长度作为接收完毕的判断。你已经可以很明显地看到它的缺陷。

然而必须考虑到，我们确实缺乏一个判断结束的方法。
除非我们设计了一套蹩脚的私有协议（实质上就是一串字头而已。）

前面我们已经分析过了这是一件非常愚蠢非常蹩脚的实现方式。
不要为了一种错误的想法去勉为其难接收一种其实很愚蠢的实现方案。

我经常这样告诫自己。

实质上，我自己已经有了一个解决方案，当然这不是我自创的。
这是我前不久解决一个公司项目时，从同事那学习，并且对比网上类似的想法以后得到的结果。

它就是 超时判断机制。
别被名字忽悠，其实这是一个非常简单而切合实际的思想。
下面将解释。

辛昕

闂傚倸鍊风粈渚€骞栭銈嗗仏妞ゆ劧绠戠壕鍧楁煕閹邦垼鍤嬮柤鏉挎健閺屾稑鈽夊▎鎰▏闁诲孩鑹鹃ˇ浼村Φ閸曨垰绠抽柛鈩冦仦婢规洜绱撻崒娆戝妽妞ゃ劌妫濋弫鍐閻樺灚娈惧┑掳鍊曢幊搴㈠劔闂備礁鐤囧銊х矆娴ｈ鍙忛柕鍫濐槹閻撶喖鏌ｅ鈧禍璺侯瀶閻戣姤鐓曢柡鍌濇硶缁犵粯銇勯姀锛勬噰妤犵偛顑夐弫鍌炴嚍閵夛妇褰ㄩ梺璇查閸樻粓宕戦幘缁樼厱闁归偊鍘奸崝銈嗙箾閸剚瀚�闂傚倸鍊峰ù鍥儍椤愶箑骞㈤柍杞扮劍椤斿嫮绱撻崒姘偓鍝ョ矙閸曨垰绠柨鐕傛嫹闂傚倸鍊烽懗鍫曞箠閹剧粯鍋ら柕濞炬櫆閸嬪鏌ｉ幇顒佹儓闁绘帒鐏氶妵鍕箳閹搭垱鏁鹃柣搴㈢啲閹凤拷婵犵數濮烽弫鎼佸磻濞戔懞鍥敇閵忕姷顦悗鍏夊亾闁告洦鍋夐崺鐐烘⒑鐠恒劌娅愰柟鍑ゆ嫹

辛昕

闂傚倸鍊风粈渚€骞栭銈嗗仏妞ゆ劧绠戠壕鍧楁煕閹邦垼鍤嬮柤鏉挎健閺屾稑鈽夊▎鎰▏闁诲孩鑹鹃ˇ浼村Φ閸曨垰绠抽柛鈩冦仦婢规洜绱撻崒娆戝妽妞ゃ劌妫濋弫鍐閻樺灚娈惧┑掳鍊曢幊搴㈠劔闂備礁鐤囧銊х矆娴ｈ鍙忛柕鍫濐槹閻撶喖鏌ｅ鈧禍璺侯瀶閻戣姤鐓曢柡鍌濇硶缁犵粯銇勯姀锛勬噰妤犵偛顑夐弫鍌炴嚍閵夛妇褰ㄩ梺璇查閸樻粓宕戦幘缁樼厱闁归偊鍘奸崝銈嗙箾閸剚瀚�闂傚倸鍊峰ù鍥儍椤愶箑骞㈤柍杞扮劍椤斿嫮绱撻崒姘偓鍝ョ矙閸曨垰绠柨鐕傛嫹闂傚倸鍊烽懗鍫曞箠閹剧粯鍋ら柕濞炬櫆閸嬪鏌ｉ幇顒佹儓闁绘帒鐏氶妵鍕箳閹搭垱鏁鹃柣搴㈢啲閹凤拷婵犵數濮烽弫鎼佸磻濞戔懞鍥敇閵忕姷顦悗鍏夊亾闁告洦鍋夐崺鐐烘⒑鐠恒劌娅愰柟鍑ゆ嫹

辛昕

闂傚倸鍊风粈渚€骞栭銈嗗仏妞ゆ劧绠戠壕鍧楁煕閹邦垼鍤嬮柤鏉挎健閺屾稑鈽夊▎鎰▏闁诲孩鑹鹃ˇ浼村Φ閸曨垰绠抽柛鈩冦仦婢规洜绱撻崒娆戝妽妞ゃ劌妫濋弫鍐閻樺灚娈惧┑掳鍊曢幊搴㈠劔闂備礁鐤囧銊х矆娴ｈ鍙忛柕鍫濐槹閻撶喖鏌ｅ鈧禍璺侯瀶閻戣姤鐓曢柡鍌濇硶缁犵粯銇勯姀锛勬噰妤犵偛顑夐弫鍌炴嚍閵夛妇褰ㄩ梺璇查閸樻粓宕戦幘缁樼厱闁归偊鍘奸崝銈嗙箾閸剚瀚�闂傚倸鍊峰ù鍥儍椤愶箑骞㈤柍杞扮劍椤斿嫮绱撻崒姘偓鍝ョ矙閸曨垰绠柨鐕傛嫹闂傚倸鍊烽懗鍫曞箠閹剧粯鍋ら柕濞炬櫆閸嬪鏌ｉ幇顒佹儓闁绘帒鐏氶妵鍕箳閹搭垱鏁鹃柣搴㈢啲閹凤拷婵犵數濮烽弫鎼佸磻濞戔懞鍥敇閵忕姷顦悗鍏夊亾闁告洦鍋夐崺鐐烘⒑鐠恒劌娅愰柟鍑ゆ嫹

辛昕

闂傚倸鍊风粈渚€骞栭銈嗗仏妞ゆ劧绠戠壕鍧楁煕閹邦垼鍤嬮柤鏉挎健閺屾稑鈽夊▎鎰▏闁诲孩鑹鹃ˇ浼村Φ閸曨垰绠抽柛鈩冦仦婢规洜绱撻崒娆戝妽妞ゃ劌妫濋弫鍐閻樺灚娈惧┑掳鍊曢幊搴㈠劔闂備礁鐤囧銊х矆娴ｈ鍙忛柕鍫濐槹閻撶喖鏌ｅ鈧禍璺侯瀶閻戣姤鐓曢柡鍌濇硶缁犵粯銇勯姀锛勬噰妤犵偛顑夐弫鍌炴嚍閵夛妇褰ㄩ梺璇查閸樻粓宕戦幘缁樼厱闁归偊鍘奸崝銈嗙箾閸剚瀚�闂傚倸鍊峰ù鍥儍椤愶箑骞㈤柍杞扮劍椤斿嫮绱撻崒姘偓鍝ョ矙閸曨垰绠柨鐕傛嫹闂傚倸鍊烽懗鍫曞箠閹剧粯鍋ら柕濞炬櫆閸嬪鏌ｉ幇顒佹儓闁绘帒鐏氶妵鍕箳閹搭垱鏁鹃柣搴㈢啲閹凤拷婵犵數濮烽弫鎼佸磻濞戔懞鍥敇閵忕姷顦悗鍏夊亾闁告洦鍋夐崺鐐烘⒑鐠恒劌娅愰柟鍑ゆ嫹

soso

闂傚倸鍊风粈渚€骞栭銈嗗仏妞ゆ劧绠戠壕鍧楁煕閹邦垼鍤嬮柤鏉挎健閺屾稑鈽夊▎鎰▏闁诲孩鑹鹃ˇ浼村Φ閸曨垰绠抽柛鈩冦仦婢规洜绱撻崒娆戝妽妞ゃ劌妫濋弫鍐閻樺灚娈惧┑掳鍊曢幊搴㈠劔闂備礁鐤囧銊х矆娴ｈ鍙忛柕鍫濐槹閻撶喖鏌ｅ鈧禍璺侯瀶閻戣姤鐓曢柡鍌濇硶缁犵粯銇勯姀锛勬噰妤犵偛顑夐弫鍌炴嚍閵夛妇褰ㄩ梺璇查閸樻粓宕戦幘缁樼厱闁归偊鍘奸崝銈嗙箾閸剚瀚�闂傚倸鍊峰ù鍥儍椤愶箑骞㈤柍杞扮劍椤斿嫮绱撻崒姘偓鍝ョ矙閸曨垰绠柨鐕傛嫹闂傚倸鍊烽懗鍫曞箠閹剧粯鍋ら柕濞炬櫆閸嬪鏌ｉ幇顒佹儓闁绘帒鐏氶妵鍕箳閹搭垱鏁鹃柣搴㈢啲閹凤拷婵犵數濮烽弫鎼佸磻濞戔懞鍥敇閵忕姷顦悗鍏夊亾闁告洦鍋夐崺鐐烘⒑鐠恒劌娅愰柟鍑ゆ嫹

辛昕

闂傚倸鍊风粈渚€骞栭銈嗗仏妞ゆ劧绠戠壕鍧楁煕閹邦垼鍤嬮柤鏉挎健閺屾稑鈽夊▎鎰▏闁诲孩鑹鹃ˇ浼村Φ閸曨垰绠抽柛鈩冦仦婢规洜绱撻崒娆戝妽妞ゃ劌妫濋弫鍐閻樺灚娈惧┑掳鍊曢幊搴㈠劔闂備礁鐤囧銊х矆娴ｈ鍙忛柕鍫濐槹閻撶喖鏌ｅ鈧禍璺侯瀶閻戣姤鐓曢柡鍌濇硶缁犵粯銇勯姀锛勬噰妤犵偛顑夐弫鍌炴嚍閵夛妇褰ㄩ梺璇查閸樻粓宕戦幘缁樼厱闁归偊鍘奸崝銈嗙箾閸剚瀚�闂傚倸鍊峰ù鍥儍椤愶箑骞㈤柍杞扮劍椤斿嫮绱撻崒姘偓鍝ョ矙閸曨垰绠柨鐕傛嫹闂傚倸鍊烽懗鍫曞箠閹剧粯鍋ら柕濞炬櫆閸嬪鏌ｉ幇顒佹儓闁绘帒鐏氶妵鍕箳閹搭垱鏁鹃柣搴㈢啲閹凤拷婵犵數濮烽弫鎼佸磻濞戔懞鍥敇閵忕姷顦悗鍏夊亾闁告洦鍋夐崺鐐烘⒑鐠恒劌娅愰柟鍑ゆ嫹