打印

SPI问题

SPI问题

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

TOP

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

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

TOP

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

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

TOP

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

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

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

TOP

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

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

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

TOP

内核不是实时的,首先要考虑就是时间片反应的问题,好像非实时内核 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 了。

TOP

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

我自己就没买过开发板

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

TOP

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

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


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

TOP

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

TOP


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

TOP

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

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

TOP


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

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

TOP

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

TOP

TOP

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

TOP