关于嵌入式工控电脑的一些问题

lololo

关于嵌入式工控电脑的一些问题 [复制链接]

        公司是生产自动化测试工控设备的，之前使用的是工控电脑+WinXP+VC的方式控制机器的运行，现在想转到嵌入式方面，初步确定采用WinCE+嵌入式单板电脑作为控制系统，但是在硬件选型方面碰到了不少困惑，希望有经验的高手能指点一二：
        1、ARM还是X86？个人来说是比较偏向ARM体系的，简洁快捷不像x86那样啰嗦复杂，但是采用ARM9的单板机经过测试其性能与期望相差太大，主要是一次IO读操作耗时近0.1ms，这样的性能远不够用来进行高速数字信号处理。而ARM10甚至ARM9E的工业电脑似乎国内在做的极少（目前发现的也只有阿尔泰一家而已），恐怕技术支持不够，是否意味着只能放弃ARM体系了？
        2、数字IO与运动控制方面。目前的设备需要有3轴的运动控制和200个左右的数字IO，之前工控机上是采用PCI插槽扩展相应的功能卡来实现的，所以现在也希望通过相似的方式采用PC104总线扩展IO卡和运动控制卡来实现这部分功能，但是这些产品国内在做的似乎也很少？是否有其它的选择呢？听说FPGA可以实现这样的要求，但就是不知其开发方式、开发周期与难度是怎样的。
        公司规模比较小，开发团队人数也非常有限，所以在开发周期与开发成本上能支持的也比较有限，高难度的开发方式（例如自己制作ARM板之类的）那是不可能的，谢谢。

linhuanhuan

好像用于工控的ARM9芯片很少吧，NXP好像有了，不过你不怕BUG的话可以试试，Intel的XScale的还不错。
X86的那种构架已经很稳定了，扩展板卡也非常多，貌似功耗太大。

wawj1819

做工控推荐Intel的XScale

三星等都不行的。

漂叶

可以选用I2C厂商的第三方提供的开发板，有些第三方的技术支持还不错。如果整体研发无法完成，也可以外包出去。工业级的用SHARP、ATMEL、TI、FREESCALE、NXP的都可以。

chenseawind

从02年开始用XScale的250，到现在的3xx，反而不建议在工控上选XScale，因为和你的需求不太一致。别的不说，用这个做成工控电脑的就没见过，可选资源就不丰富，支持也不会很好。

其实用ARM做工控的都很少见，因为ARM的架构本来的目标就不是工控那种实时性和精确性要求都高的领域的。当然，这里说的是ARM9及以上，因为你需要操作系统。如果不需要操作系统，可以考虑ARM7以及新的ARM-Cortex M3架构的CPU。（注：ARM7的CPU逐渐淡出市场，做ARM7强的ST/NXP都在往Cortex-M3转）

以前做的经验，其实工控机还是选X86的最合适，做的厂家多，性价比可选的多，资源丰富，扩展性强，支持也好。
再说，WINCE也是可以在X86上跑的，甚至连平台都不换，省的选型就要N久了。

至于FPGA，如果有现成的资源（人力、IP核），倒是可以选择，不然还是别随便介入。FPGA上手容易，想做的稳定能产品化，就不容易了。再说，一般FPGA也都是开发板，想要实际产品，一样是要投钱让人开发的。

peng_hui

要想转入嵌入式的，建议还是买块FPGA开发板做工控还是蛮不错的，从性价比看。FPGA主要是软件方面，开发起来相对容易些

min_sd

ARM+PC104 也有很多人用大多是winCE,ucos等....主要用于低功耗。。节点不是特别多拓展能力弱了点.
与IPC比起来，开发比较麻烦连用户界面GUI都要从头作起....
如果是经济许可建议还是用IPC吧....从PC诞生至今.....IAS,PCI等扩展槽...

xinbt

引用 6 楼 vc8fans 的回复:
ARM+PC104 也有很多人用大多是winCE,ucos等....主要用于低功耗。。节点不是特别多拓展能力弱了点.
与IPC比起来，开发比较麻烦连用户界面GUI都要从头作起....
如果是经济许可建议还是用IPC吧....从PC诞生至今.....IAS,PCI等扩展槽...

IPC就是工控PC吧, 之前的产品就是用的这个, 笨重占空间维护麻烦稳定性也不佳, 所以才想转到嵌入式的

lylhust

一个控制中心这么多点，是不是太过于集中了

能不能分化系统

在前端安排些小的控制内核来处理

这样，省了控制中心的接口

让其更专注于计算。。。

shenyesanbu

楼上的提意可以考虑

zjiulong

我是做通信的，对工控不熟，提点建议：

楼主说的IO读操作需要0.1ms是如何测出来的？
通常ARM芯片的IO操作的确比内部寄存器操作要慢很多，但我也没见过这么慢的芯片。假设楼主用的ARM芯片主时钟是100MHz（ARM9通常有这个速度），0.1ms已经是100000个时钟周期了……楼主测试的时候会不会忽略了操作系统的时延了……
我用过Xscale270，IO延时大概是0.x个us吧，具体记不清了。

至于FPGA方面，我建议如果逻辑不复杂的话，还是用CPLD吧。毕竟比FPGA简单，掉电后程序不会丢失。不像FPGA，上电时还得下载程序。

jjww

coldfire 5272 是用于工控的
FPGA也可以找一个CPU IP 做出一个软核来。

dengf

引用 10 楼 coderJames 的回复:
我是做通信的，对工控不熟，提点建议：

楼主说的IO读操作需要0.1ms是如何测出来的？
通常ARM芯片的IO操作的确比内部寄存器操作要慢很多，但我也没见过这么慢的芯片。假设楼主用的ARM芯片主时钟是100MHz（ARM9通常有这个速度），0.1ms已经是100000个时钟周期了……楼主测试的时候会不会忽略了操作系统的时延了……
我用过Xscale270，IO延时大概是0.x个us吧，具体记不清了。

至于FPGA方面，我建议如果逻辑不复杂的话，…

在CE5.0下面用QueryPormanceCounter这个函数计算出来的, 就是在DeviceIOControl函数前后调用QueryPormanceCounter, 对比两次的值就能大概算出DeviceIOControl所占的时间, QueryPormanceCounter函数本身的运行时间影响可以通过加大取样样本数来减少影响, 0.1ms只是个概数, 实际用时根据定制的CE分辨率不同而从0.06ms到0.1ms不等, 芯片是EP9315 200mHz
IO时延和这个不是同个概念来的, IO时延指的应该是发出IO命令到命令确实动作所花的时间来的吧

fanfanworm

引用 12 楼 drind 的回复:
引用 10 楼 coderJames 的回复:
在CE5.0下面用QueryPormanceCounter这个函数计算出来的, 就是在DeviceIOControl函数前后调用QueryPormanceCounter, 对比两次的值就能大概算出DeviceIOControl所占的时间, QueryPormanceCounter函数本身的运行时间影响可以通过加大取样样本数来减少影响, 0.1ms只是个概数, 实际用时根据定制的CE分辨率不同而从0.06ms到0.1ms不等, 芯片是EP9315 200mHz
IO时延和这个不是同个概念来的, IO时延指的应该是发出IO命令到命令确实动作所花的时间来的吧

楼主说的应该就是我想表达的意思了。就是0.1ms的时延应该主要是由WinCE操作系统造成的，芯片本身的IO执行速度是比较快的。由于WinCE是非实时操作系统，从调用驱动到程序返回，要经历用户态到内核态再到用户态的转换，耗费的时间是比较长而且不确定的。操作系统做了一大堆堆栈操作，最后对你来说有用的可能只有驱动程序里面对寄存器操作的那条语句。

如果不换一个实时操作系统（eg：ucos,vxworks）的话，这样的问题不好解决。

yu4821483

用GeodeLx800的板子试验, 同样环境下, 其调用占时只需1~2us, 足够了. 另外, WinCE至少是软实时操作系统的吧, 据说