原来68013做数据采集的时候不需要外置fifo.docVIP

/BLOG_ARTICLE_1972869.HTM 很久很久以前做过一个68013的图像采集卡 当时发现，虽然68013内部有一个slave fifo，但是这个fifo貌似没法当作真正意义上的fifo用-- 每当pc读光ep2 fifo的数据之后，无论是进行网络转发，还是文件存储的操作 都会导致fifo满掉，此时如果不对发过来的数据加以处理，就会丢数据 于是当时的做法是加了一个外置的fifo，并通过fpga控制 68013的fifo满了之后，把数据暂存在外置fifo里，关闭哪个fifo的rd 68013的fifo空了在继续通过rd写入数据。 那时候用了一个idt的fifo，要500多一片。。。 今天才知道，原来有更好的办法 在pc读取数据的时候，开两个线程 一个负责不断的从68013读，一个负责对读到的数据进行处理。。。 具体怎么做就是上位机的事情了。。。 公司原来做这个项目的人据说是改写驱动实现的这一点 对了，68013 的datasheet，关于slave fifo部分有一个波形图，相当的坑爹。。。里面的slwr是一上一下的，搞的每4个clk才能发送一组data 当时完全按照波形图设计的fpga。。。后来仔细读了68013，才发现slwr只是写使能而已。。一直拉低就好了当然更坑爹的是那个状态机的描述。。状态图里4个状态，整个波形图却只用2个clk就完成了一次转换昨天发现68013的slwr，不管内部firmwre怎么写，只要把slwr拉低就肯定死机，pc完全检测不到usb设备，查了一圈发现是reserve忘了接地了，明明DS里提到了的。。 明明1年前犯过同样的错误的。。不过当年是连i2c上拉都没接，现在好歹记得了。。 看来调试记录太重要了！ 想起来当年做68013的时候用fpga做fifomaster，外接一个idt的dc fifo做缓冲，也是一波三折了。。当时是需要大量数据采集+少量控制信号接收，但是不会根据需要切换fifo address，也不会通过ep0再bulk传输的时候收发指令，于是用了2片68013分别完成这两个工作。负责指令发送的68013，用了好久才发现必须工作在autoout 0的方式下，也就是manual out 不然每次都等512byte才发一个bulk，延时太大了 指令长度又不统一，不好通过调整length的方式来解决。 数据采集部分，最开始用fpga产生了累加数据送给fifo作为测试手段，通过这个手段发现，68013接收到的数据有时候会重复第512bytge，有时候则会丢掉某些数据。 检查发现是控制idt的fifo的oe与68013的slwr的时序有问题。 那时候写状态机写的还是相当混乱的。。。最后把某个寄存器操作延时了一个clk把问题解决了。 说到这个延时clk还有另外一个事情 前几天做一个fpga直接控制phy片输出udp包的板，fpga采集到的数据先送到了一个megacore生成的dcram里，dcram in的时钟是fpga主时钟分频，dcram out的时钟则是来自phy片的txc。 但是出来的数据死活不对。。 比如给ram写出来的则是座机电话号码 反复分析过2进制的每一位，没有任何问题。。。 之后发现是metacore的dc ram的output，我选择了clk register，使发送出来的数据延时了一位 于是第address位的data变成了address-1的。。。 1，说FIFO满了就自动上传给电脑——这话是错的。USB2.0及1.1设备不能中断主机，只能是主机主动去访问设备。就是说，即便FIFO满了，如果主机不取，数据依然在设备的RAM里，RAM写满之后固件就不应该再写了。2，端点0，1比较简单，缓冲区长度固定，64字节，没有多重缓冲。端点2468比较灵活，4和8可以配置成512字节的双缓冲，2和6可以配置成512字节、1024字节的2、3、4倍缓冲。3，多重缓冲的目的是，主机（USB数据）可以和端点外部逻辑（如DSP，FPGA）直接交换信息，数据不用从CPU导进导出，从而提高了性能。4，缓冲是指对于端点有效的内存区块数。比如，双重缓冲，在USB数据进出一个端点的同时，外部逻辑的信息也可以进出同一端点。这是手册说的。5，假定端点2缓冲区设置为512字节，4倍缓冲，尽管这一端点占有了2048字节RAM，但CPU只认识“激活的”512字节缓冲区。这可以从寄存器长度看得出来，比如，EP2BCH是11位，可对1024字节的最大缓冲区长度进行计数，EP4BCH是10位，可对512自己的最大缓冲区长度进行计数。6，从第5点可以看出，FIFO读写数据是自动完成的，至于乒乓方式也是隐式实现的，CPU不了解也无需了解如何乒乓。CPU可以对FIFO进行少量的控