SPI问题

zz_6_3

DM368的芯片，CPU主频432MHz，Linux系统，用SPI作从设备（不使用DMA，而是使用中断），SPI主设备给过来的时钟是3MHz，在应用程序中每次发送1字节，主端收到的数据每个字节中间隔着3个0，这是啥回事？难道Linux进程调度需要耗这么长时间？

jiangtao9999

3个0+1字节=4*8bit=32bit……
你这是不是代码写的有问题？传过来的不是一个字节，而是 4 字节。
因为 4 字节正好是 32 位的 arm9 的指令长度，而 arm 是 RISC ，数据应该是需要对齐的。一次只能扔出 32bit 的数据？

瞎蒙的。错了勿喷，对了就送我个 cortex-A5x 的开发板做奖励吧。

zz_6_3

应用程序每次发送一个0~255的递增数，中间的0就会达到12个的样子，递增数还是连续的。还真不知道什么原因导致前面会有那么多0，一两个0的话还算正常，那么多就不正常了

话说，有些开发板不是可以申请么？免费的。我问问我同事看看有没有这块开发板申请

jiangtao9999

我根本就不打算出东西，申请一般都是需要有产出的，我可受不了。
所以我宁愿选择花钱买，或者谁不要了扔给我一个。

如果数量递增，而不是结构一致，那就应该是发送的数据不同步。发送这边还没开始发数据，但是接收端就已经“收到”了空数据。这样的话，如果你的 0 真的是 0x00 ，而不是 0x30 ，那么其实应该是 NULL 。也就是其实没有数据发送，但是你的程序自己创造了空数据。之后又把这个空数据当作了真实数据。

我不知道你这个东西是怎么进行数据传输时钟同步的。我想弄不好真的是程序延迟导致的输出时间不准，你的 Linux 是实时系统么？好像实时系统也不能精确到兆赫兹的速度水平吧？你这可是三百万分之一秒啊，光速在这个时间里，也才走了 100 米不到。
这样的话，或许你需要前缀和结尾关键字节，来让自己的程序可以识别出数据包了。如果你需要准确的时间发送，这我就没见过怎么搞的相关资料了。财会人员的无延迟工作，也都是人肉工作，不存在微妙级的时间要求。

zz_6_3

不是实时的。我作从设备，不需要产生时钟，我只用发就行了，在我的程序跑起来之前就对方就给时钟和片选信号了，一直不间断地给，所以只要我发慢一点中间就会多出一些0了。按道理来说进入下一次循环的间隔是很短的，再慢也最多出现一两个0，绝对不会出现那么多 0。从代码来看，只有将数据从用户空间拷入内核空间和设置硬件这两个最耗时间了，但432MHz也不至于慢成那样子啊

我昨天问了，没有那个开发板

[ 本帖最后由 zz_6_3 于 2015-3-27 12:40 编辑 ]

jiangtao9999

内核不是实时的，首先要考虑就是时间片反应的问题，好像非实时内核 Linux 的时间片调度最高是 1kHz ，这个时间反应就已经低于 3Mhz 了。你打补丁，我想也不可能跑出 3Mhz 的调度速度吧？
另外，ARM CPU 也是有流水线的，而且 IO 各方面都需要有延迟，你的程序从运行到输出，就算是 432Mhz ，我想也很难保证效率。你要在 432/3=144 个时钟里处理完全部。
而内存存取寻址，都是需要有延迟的。而且还是随机存储，位置不固定，导致寻址等待的时间肯定也不一致，更何况还要等你的程序时间片到了才能进行处理。另外硬件传输我记得也有阻塞延迟的问题……要在这么高的频率里解决不确定的事情，我觉得太难。
你找找看，有没有保持数据在 CPU 缓存中保留并且直接调用的指令吧。我查到个资料 i5 的 L1 延迟是 4 ，L2 是11 ，L3 是 25 。我想 ARM 的缓存性能肯定不如这个吧？

我觉得你还是考虑实时系统。至少不要等待多任务的分时间片到了才能运行，最好可以独占的系统。抢占式内核似乎也要等调度器装入程序进程，也有不小的延迟。我觉得你还不如用单片机那种直接操作硬件的方式快呢……

A5X 系列刚出，你们有的概率太小了。
就算有，肯定不能给我的。
不过你们要是有不用的 A8/A9/A7/A15 的这种 armv7 系列的主板，内存 1G 或者更高的主板，可以联系sejishikong，给他，这样 magic linux 就可以弄 arm 版了。不过最好多核心，交叉编译一个系统不靠谱，我这都是本地编译。龙芯 2f 的性能，哈哈哈……
不过目前来看，估计精力不够做，我弄 mips64el 版已经快被折腾疯了。这种开发板其实没多少钱，主要还是 ml 没人弄啊。要不弄到开发板你也别给 sejishikong 了。你直接承包 arm 版的就 OK 了。

zz_6_3

呵呵，我刚开始也是想着系统调度需要时间，不过上面的人说肯定还有其它原因，我怎么说都没用，郁闷着呢。系统是不可能换的，因为有些视频和图片相关的处理，只能尽量优化加速了。这个SPI驱动真是闹心啊，最底层异步做的，不过中间用一个完成量转换成了同步发送了。DMA实现方式又有BUG，用不了。现在这个虽然能发送数据，但第一个字节总是发送出错，后面字节的都正常。

我自己就没买过开发板

[ 本帖最后由 zz_6_3 于 2015-3-27 22:55 编辑 ]

jiangtao9999

你能不能缩减你的程序功能，去掉一部分运算试试。尽量用汇编来写。这样一点一点的试每部分功能的延迟。
不是完全实时的系统，对于速度真的是没办法把握。

就烦这种上面说肯定行，但是又不说出到底是什么地方有问题。一副我有这能耐，但我就不告诉你的嘴脸。


你是干这行的，开发板对于你来说拿来有用，我这要他其实根本就没用的人，自然只能是花钱买了。

zz_6_3

呵呵，单位鸟规定，C不能与汇编混用

jiangtao9999

其实这样规定挺好的。汇编对于硬件的关联性太强，如果你用混合编写，这个代码别人会以为是 C 的通用语言，结果实际上是汇编，会让以后的维护出现问题。
不过你这很大的问题是 C 要看编译器的输出情况了。要是输出的代码比较糟糕，很费时间的。

zz_6_3

把源码看了一下，系统提供的驱动是尽量写成通用的，效率实在咋的不起来

现在又出现一个新问题：只启用一个ADC通道，采样前电压为1.2V，采样时电压被拉高到2V，采集完成后又变回1.2V，好诡异的问题

jiangtao9999

你们公司挑战硬件性能的手法很奇妙。

这电压是不是有地方写错了，还是这东西本来就工作不稳定，只要一工作，电压就提高？

zz_6_3

鬼知道呢，估计得检查检查电路了，目前我还没看到最新版的原理图啥的

jiangtao9999

zz_6_3

ADC的问题找到了，其它通道的电压过高，漏过来的