原创 目前的进展、遇到的问题和解决的办法

从10月26日到12月23日，这两个月的时间都是投入在CPLD和驱动开发上的，当然重要的部分都是MR一手打造的。

12月初驱动和板卡都已经调通，在10号左右去现场测试打标效果的时候，发现板卡在单词打标的情况下，长期按下脚踏开关会出现打标软件自动退出的现象。本来就是新作的板卡，自然问题首先必须由我们内部进行检查。

这个问题首先我想到的是上位机读取数据的时候，数据采样是直接从外部wire型信号保存到寄存器中的，所以会不会是因为数据不稳定呢。针对这个猜想，我修改了CPLD程序，将板卡上的IO 信号的采样时间向前提前了，并从reg中读取数据，保证读数据的稳定。结果显示，发现仍然会有自动退出的现象。

接下来，我想到了在DLL中可以调用messagebox进行一些信息的现实，那么我可以看看到底是不是上位机没有正确读到数据。光是这个MessageBox就搞了我一个下午和半个晚上，还是不熟练啊，特别是Windows的一堆的别名类型之间的转换。我很想调用messagebox去显示上位机软件读到的值。于是最后还是MR写的程序可以用。

#include <comutil.h>

....

#pragma comment(lib,"CH365DLL.lib")

.....

static mPDA16_MEM_REG pMemBaseAddr = NULL;
mDA16_MEM_REG   MemBaseAddr;

......

BOOL DA16GetMemBaseAddr(mPDA16_MEM_REG *oMemBaseAddr) 
{  
 CH365GetMemBaseAddr( oMemBaseAddr );
  pMemBaseAddr = *oMemBaseAddr;
 return TRUE;
}

.........

BOOL DA16ReadMemByte(PVOID   iAddr,
      PUCHAR   oByte )
{

WCHAR data[9] = {0};
 LPCWSTR str;
data[0] = L'0'+(WCHAR)(((*oByte)&0x80));
  data[1] = L'0'+(WCHAR)(((*oByte)&0x40));
  data[2] = L'0'+(WCHAR)(((*oByte)&0x20));
  data[3] = L'0'+(WCHAR)(((*oByte)&0x10));
  data[4] = L'0'+(WCHAR)(((*oByte)&0x08));
  data[5] = L'0'+(WCHAR)(((*oByte)&0x04));
  data[6] = L'0'+(WCHAR)(((*oByte)&0x02));
  data[7] = L'0'+(WCHAR)(((*oByte)&0x01));
  data[8] = L'\0';
  str = data;

.................

MessageBox(NULL,str,L"DA16ReadMemByte",MB_OK);

..........

}

通过messagebox我发现可以看到下位机向上发送的数据，另外，我又发现确实按键按下以后上位机可以读到1的，那为什么以前的CH365的板卡长期按下脚踏开关不会出现异常退出呢，是不是可以将原来的读端口那部分直接在dll中硬性赋值为1，看上位机如何反应呢？

我于是开始下载CH365的lib 和 dll 以及.H，

在cpp中导入lib的方法是

#pragma comment(lib,"CH365DLL.lib")

然后发现即使是原来的板卡一样会出现异常退出，那么说明，为什么会异常退出只有一个原因，那就是按键的值按下后，如果是长时间的按下，接下来读到的值就会被设置成0，而不是1.

那这部分的工作有可能是在原来CHUNKIN写的驱动里面，也有可能是在通过CH365对8255进行读操作的时候由于是与写操作一起做的，就有可能使读到的数据线不是锁存上一次的数据。但是细想了一下，又在封装的时候，对弹出对话框进行了判断，只有读到1的时候才弹出对话框，但是实际测的时候发现，是1还是1，是0还是0，并没有什么长按的处理，于是我又发现，其实chunkin和ch365的接口函数名字都是一样的，为什么要做封装呢。会不会是自己做了一部分的去抖动呢？

于是我在封装的驱动中加入这段代码：

CH365ReadMemByte(iAddr,  &preByte);
  if(preByte==1)
  {
   if (agoByte==0)
   {
    counter = 0;
    *oByte = 0;
    agoByte = 1;
   }
   else if(agoByte == 1)
   {
    counter++;
    if (counter>=5 && counter <=40)
    {
     *oByte = 1;
    }
    else
    {     
     *oByte = 0;
    }
   }
  }
  else if (preByte == 0)
  {
   counter = 0;
   agoByte = 0;
   *oByte = 0;
  }
虽然参数5和40并没有什么依据，纯粹是测出来的结果，但是这样做了以后，上位机软件的确不再异常退出了。

虽然似乎找到了异常退出的问题，但是，MR强烈鄙视这种行为，他认为既然是板卡的驱动，板卡提供的接口那就应该将自己的功能完成，而去抖动这种功能不应该在驱动这层中出现，我也觉得有道理，下次见L老师的时候，会跟他讲清楚问题的原因。

虽然按按键异常中断的问题，找到了原因。可是从整个项目开发的角度上看，这是相当不合理的，因为你并不知道上位机软件如何调用下层的dll，而是刻意的写一些接口，使其迎合上位机软件的操作。这样做是徒劳的，也是没有什么实际价值的，虽然解决了总比留着问题好，但是我却花了两个晚上啊。觉得还是有点没有价值。

下面的问题又来了，因为上面的所有驱动都是基于Windriver提供的函数写的，在实际的客户机上运行的时候，还必须先将WinDriver打开关闭一次，应用软件才能正常工作，否则会弹出提示说你还剩多少时间可以用，这一点对于我们来说是之前并没有考虑到的，做了一个月，才发现有这个问题，网上查破解方案用了整整两个星期，都是宝贵的时间啊，用来做这些没价值的工作，唉，从这周开始就要转向用DDK开发了，唉，走了一个大圈的弯路啊。怎么用DDK开发PCI驱动，对于我来说还是一片空白。虽然已经看了几章张帆的《windows驱动开发技术详解》但是，真正写和理解驱动才刚刚起步，老板对我是很不满了，我自己也觉得不能太搓了，不然以后还怎么抬头做人啊，三个星期出一个ddk的设备驱动，包括上位机的API，我操，又要通几次宵啊，不过在怎么说，至少也比花时间去琢磨怎么破解Windriver要光明正大，和有实际价值。

学习驱动的路漫漫啊。