1.问题阐述
在ITE的SDK上编译，选择了CPU write-back cache enable (CPU_WB)，之后，显示画面总是出现有错乱。通过设置断点，发现当停在解析的数据后，在运行就不会出现错乱现象，问了大神才知道，只是cache没同步的问题。
2.解决方法
memcpy(data2, data, VARMSIZE);
ithFlushDCacheRange(data2, VARMSIZE);
ithFlushMemBuffer();
在完成数据的搬运之后，需要加上了清理缓存，将数据彻底地进行copy,这样数据就没问题了。
3.Write Through和Write back比较
当SDK不选择WB，则是Write Through模式，那么这两种有什么不一样的地方呢。
write through：CPU向cache写入数据时，同时向memory也写一份，使cache和memory的数据保持一致。优点是简单，缺点是每次都要访问memory，速度比较慢。
write back：CPU更新cache时，只是把更新的cache区标记一下，并不同步更新memory。只是在cache区要被新进入的数据取代时，才更新memory。这样做的原因是考虑到很多时候cache存入的是中间结果，没有必要同步更新memory。优点是CPU执行的效率提高，缺点是实现起来技术比较复杂。
一般来说，都是选择效率高的WB模式。
3.cache 和 buffer比较
一.A从B取一个1000M的文件结果需要2s，本来需要1s就可以完成的工作，却还需要额外等待1s,B设备把剩余的500M找出来，这等待B取出剩下500M的空闲时间内(1s)其他的事务还干不了
二.A给B一个1000M的文件结果也需要2s，本来需要也就1s就可以完成的工作，却由于B，1s内只能拿500M，剩下的500M还得等下一个1sB来取，这等待下1s的时间还做不了其他事务。
第一种情况A要B(cache)：当A从B取一个1000M的文件，他把需求告诉了ab，接下来ab通过b和B进行文件传送，由于B本身的速率，传送第一次ab并没有什么卵用，对A来说不仅浪费了时间还浪费了感情，ab这家伙很快感受到了A的不满，所以在第二次传送的时候，ab背着B偷偷缓存了一个一模一样的文件，而且只要从B取东西，ab都会缓存一个拷贝下来放在自己的大本营，如果下次A或者其他C来取B的东西，ab直接就给A或C一个货真价实的赝品，然后把它通过a接口给了A或C，由于a的速率相对接近A的接口速率，所以A觉得不错为他省了时间，最终和ab的a成了好基友，说白了此时的ab提供的就是一种缓存能力，即cache，绝对的走私！因为C取的是A执行的结果。所以在这种工作模式下，怎么取得的东西是最新的也是我们需要考虑的，一般就是清cache。例如cpu读取内存数据，硬盘一般都提供一个内存作为缓存来增加系统的读取性能
第二种情况A给B(buffer)：当A发给B一个1000M的文件，因为A知道通过ab的a接口就可以转交给B，而且通过a接口要比通过B接口传送文件需要等待的时间更短，所以1000M通过a接口给了ab ，站在A视图上他认为已经把1000M的文件给了B，但对于ab并不立即交给B，而是先缓存下来，除非B执行sync命令，即使B马上要，但由于b的接口速率最少大于B接口速率，所以也不会存在漏洞时间，但最终的结果是A节约了时间就可以干其他的事务，说白了就是推卸责任，哈哈而ab此时提供的就是一种缓冲的能力，即buffer，它存在的目的适用于当速度快的往速度慢的输出东西。例如内存的数据要写到磁盘，cpu寄存器里的数据写到内存。
