| 标题 | 阅读 | 评论 | 转发 | 发布日期 | |
|---|---|---|---|---|---|
| Google app engine Go语言开发环境搭建 | 5752 | 0 | 0 | 2012-05-25 | |
| X86 之MTRR | 1904 | 0 | 0 | 2015-02-26 | |
| 网络数据包收发流程(一)：从驱动到协议栈 | 1871 | 0 | 0 | 2014-10-31 | |
| 网络数据包收发流程(二)：不配置NAPI的情况 | 1561 | 0 | 0 | 2014-10-31 | |
| 网络数据包收发流程(四)：协议栈之packet_type | 1824 | 0 | 0 | 2014-10-31 | |
| 网络数据包收发流程(三)：e1000网卡和DMA | 1406 | 0 | 0 | 2014-10-31 | |
| 截获linux系统调用 | 1663 | 0 | 0 | 2013-08-12 | |
| golang web编程：简单的会话（使用sessions包) | 5227 | 0 | 0 | 2013-03-29 | |
| 简单vim插件一枚，好多人说中国用vim的人不会写插件 | 1703 | 0 | 0 | 2013-03-14 | |
| 博客已升级，请注意变更地址 | 1259 | 0 | 0 | 2011-07-29 | |
| 以前做做的Linux内核移植过程： | 1631 | 0 | 0 | 2009-12-29 | |
| 自己做mini2440下视频播放器图形化界面 | 2194 | 0 | 0 | 2009-12-27 | |
| 自己做的mini2440下的音乐播放器图形化界面 | 1999 | 0 | 0 | 2009-12-27 | |
| i2c驱动第三步-写入再续 | 1784 | 0 | 3 | 2009-12-27 | |
| i2c驱动第三步-写入续 | 2544 | 0 | 3 | 2009-12-27 | |
| i2c驱动第三步-写入 | 1915 | 0 | 4 | 2009-12-27 | |
| i2c驱动第二步-打开 | 2099 | 0 | 3 | 2009-12-26 | |
| i2c驱动第一步-加载 | 2180 | 0 | 3 | 2009-12-26 | |
| 上层应用mini2440上的移植之QTpia4.2.4的移植 | 1749 | 0 | 1 | 2009-12-16 | |
| Linux2.6.30在mini2440上移植Boa服务器 | 1989 | 0 | 0 | 2009-12-09 |
config20102010-01-15 01:25
FPGA有2个PIN与2440中断相连。1s都可以产生1333次中断（750us）。 中断服务子程序：产生中断后将fpga寄存器的数据读出放入内存（链表的一个元素），并由2440写FPGA寄存器清除中断，通知驱动中的读函数数据已处理完毕（这一块是用等待队列，来唤醒驱动中的读函数）。从示波器上看，完成这些用了50us. 我想让每次中断产生的数据在下次中断来前执行完毕，也就是说还有700us的时间处理。但是现在两个中断同时出现不能完成，一个中断可以完成。若将中断周期换为1ms，刚两个可以同时完成。（完成思路：读取链到的一个元素（128位）到用户层，在链表中删除这个元素，再由socket送入PC）。任意时刻链表的长度为1或者0。 出现问题的现象：链表的长度瞬时变的很长，上万。我猜就是下次中断来之前数据没读走，就造成了恶性循环，再也读不完。或者两个中断突然就剩下一个，还有个没有了（1，我估计是执行的过程中，没有清楚中断就退出，恢复不了了，可能是没有保护好，不知？？？） 2，从时间是看，剩下的700us怎么可能处理不完这件事情呢？ 3，同时处理两个难道cpu到极限的吗？ 4，cpu中断返回后，是不是没有立即去等到队列等待处去执行，过了会才过去？有没有对策。 5，我估计cpu每次从中断返回到驱动中的读函数数据这个切换过程可能耗时很多（猜），所以我尝试的方法：10次中断的数据存在一起后，再唤醒驱动中的读函数的等待队列去读。结果是一样的，还是来不及？很想不通。 6, 有没有延时中断子函数的方法？local_irq_save()?
