弄清楚了！非常感谢 孤獨の快樂的指教！具体如下：

  1. 孤獨の快樂 的程序是对的，我上面说错了，他的程序与程序2的读写流程不同，与程序3的循环移位不同。

        我在上面轻易断定他的程序无用，是大错特错， 孤獨の快樂，不好意思了，

 

  2. 程序3的错误如孤獨の快樂所说，移位丢失了一位。

      程序2不仅循环移位错了，而且读写时序也错了。但为什么下载到板子上现象正常呢？请往下看

      为方便说明，挂了张图如下，画得很丑，见谅！

    

    先说读写时序错误 

     正常的读数据时机应该是I/O线上的后面的那8个六边形，如图中“1、2、。。8”

     程序2读数据的时机在SCLK的高电平期间，并且比正常的时机提前大约半个SCLK脉冲周期，

     如图中SCLK后8个高电平上的长方形所示。

 

     在图中可以看到，第1个长方形出现时，SCLK还没有下降沿，故I/O上也还没有正常输出，此时读取的数据无效，用“？”表示。

     在第2个长方形到第8个长方形间，如果I/O的输出数据在两个下降沿间均有效，那么这期间就能读到数据，

     但是，读到的数据是前一个下降沿触发输出的。

 

     这样，第1个长方形被浪费，后面7个依次读取数据“1、2、3、。。。7”，第8位数据没有长方形来读，被丢弃。

     在这种时序下，“87654321”会被读成“7654321？”。（？表示无效数据）

   

     由于程序2又犯了移位错误，“7654321？”又变成了“07654321”   

    

     这就是个很大的漏洞了。如果正确的数据最高位为0，那么将会一切正常；否则，才会出现错误！

     比如：设定09年04月15日，读出来显示的是正常的；

                设定99年04月15日，读出来显示的是19年04月15日，此时错误才显现。    

 

  3.  我用程序2下载，现象正常，原因即如上所述。同时也反证了上面红 {MOD}字体的假设是成立的，

         那么，datasheet上的I/O数据六边形应该拉长，即图中比特1的维持长度应是所画两条直竖线之间。