关于工业控制领域DSP、ARM和操作系统的探讨

      本人从事工业控制嵌入式14年有余，一直以DSP为看家本领，从ADI到TI，从定点到浮点，甚至最初直接玩汇编语言。就目前工业控制领域而言，以TI的C2000为主，其次是C6000。可能是我个人眼光所限，我一直排斥在工业控制领域加操作系统，也排斥使用BGA封装的CPU。但近期我发现似乎越来越多的人把目光转移到高端ARM，动辄七八百M，不少人喜欢玩Linux。不知道是我落后了，还是其他人盲目高端奢侈？
      关于此，我有几个核心问题，希望大牛们指点交流：
1  Linux适合不适合对实时性要求高的工业控制？比如，定时采样，甚至IGBT的实时保护等。我一直感觉这是消费电子领域才玩的东西。
2  如果Linux做不到，Uc如何？
3  有没有哪位大侠能推荐一款贴片封装的、带DSP核的高端ARM芯片？

谢谢。

没人回？我一向都认为工业控制简单粗暴最佳，所以都是裸机跑程序。落后了吗？

团队里有几个兄弟对linux跃跃欲试，我本来一直尊重个人的研发习惯，但这次我很想阻止，linux玩的溜的大侠们给点指点呗。

各有各的好，

习惯就好，算法是关键

强实时LINUX还是不行吧?一般的处理用linux写起来方便嘛,关键是稳定性如何.代码大了,问题就多啊.

RTOS在实时性上比前后台是更好的.前后台要不放在中断里,以得到最快的响应,不然就要最坏等一个循环的最长时间才能处理.

z_no1 发表于 2018-5-18 09:12
RTOS在实时性上比前后台是更好的.前后台要不放在中断里,以得到最快的响应,不然就要最坏等一个循环的最长时 ...

谢谢。
网上说有linux有个实时补丁，不知道效果如何？打这个补丁，会不会把系统变得很复杂？

用脚趾想也知道啊,本来就复杂的再改,难道会简单点?

据说是把正常的linux当作是一个任务,和其他要求实时的放一起.反正不怕闪退,死机就用吧.

我们做项目，安全级别要求较高的项目，从来不用操作系统。linux和ucos都达不到安全级别的要求。还是裸跑程序更安全。

linux显然不适合你说的场合。
个人觉得，一个完整的系统，通常不会一块CPU就能搞定，一般根据功能分为好几个部分，设计成好几个板卡的型式，各负其责。

不同场合用各自适合的东西，譬如我上家机械臂公司，手臂各关节是 DSP 控制无刷电机，然后底部使用的主机为 x86 平台，跑 RT-PREEMPT 补丁的 Linux 内核负责整个的路径规划、逆解、插补等，同时负责 UI 界面显示、网络通讯等事务，主机和各电机之间通过增强版的 RS485 通讯（支持广播、并发读写操作）。

以上，非常小粒度的实时控制使用 DSP/MCU 裸跑实现，稍微大些粒度的用 Linux 可以更加高效。（更小粒度的用 FPGA 实现。）
有的时候使用小系统，加了文件系统、网络、UI 之后，实时性不见得比 Linux 好，而且要造很多轮子，开发也不方便，用 Linux, 应用程序就可以跑实时任务，方便快捷。（譬如，让小系统支持 IPv6 会很麻烦。）
楼上说复杂的，我想说的是，系统的出现是为了简化编程的，譬如小系统自动帮我们调度任务，那么同样的原理，大的系统则是更大的简化（前提是在合适的场合）。

很多人不愿意用 Linux 主要是不熟悉该系统，其实，如果你也像我这样，日常生活、工作都使用 Linux 桌面系统的话，无需额外花时间学习，即可积累足够多的 Linux 经验。然而可惜的是，大多数人只图眼前方便，或是随大流，或是不愿意改变，顶多把 Linux 当一个开发工具（E.g. 那些用 Windows 调试 Linux 的朋友），错失宝贵财富。

dukedz 发表于 2018-5-20 18:13
不同场合用各自适合的东西，譬如我上家机械臂公司，手臂各关节是 DSP 控制无刷电机，然后底部使用的主机为  ...

兄台所言甚是。我原本之所以排斥操作系统，主要是考虑实时性，不是因为懒惰或不敢改变。
如果从控制程序的可读性而言，加上Linux之后，可读性是增强了还是变弱了？会不会导致离职的研发人员工作交接时把交接过程变得复杂？

小研究 发表于 2018-5-20 22:18
兄台所言甚是。我原本之所以排斥操作系统，主要是考虑实时性，不是因为懒惰或不敢改变。
如果从控制程序的 ...

在合适的情况下，使用 Linux, 会简便很多，可读性自然是增强很多。

还有很多工业控制，譬如，要处理工业视觉，MCU 级别的芯片会很麻烦，性能也差很多，几乎只能选用 Linux 系统。

然而，虽然 Linux 系统本身几乎所以东西都是现成的，但对外通讯的硬件的实时性也需要考虑，譬如，RS485 通讯，如果使用 USB 转串口的方案，实时性得不到保障，即使是用 PCIe 的卡，很多也是工作在传统的中断线共享的模式，实时性也得不到保障，而且现成的 RS485 卡不支持 CDBUS 增强型的通讯协议（传统轮询的延时会放大很多倍，至少是节点数的倍数，而且命令之间因软件等待而浪费的时间也很多；增强型：主机可以连续下发命令或广播单个命令，然后连续接收回覆，延时合并缩小到接近单个设备的系统，原理是硬件自动避让冲突，同时支持多主机系统），所以要用 FPGA 自己做 PCIe 通讯板卡（CDBUS 有开源的 IP 核），且驱动部分也不能走串口框架，防止增大延时。
如果是 ARM 跑 Linux, 由于 ARM 本身有 SPI 接口可以直接连接现有的增强型 485 的控制器，倒是简单很多。

除了接口部分，功能完成之后还要进行测试，防止因为内核的不正确配置或个别驱动问题导致实时性不达标。万一出现不达标的情况要有能力去找出问题，要非常熟悉内核才行。

以上，如果你们公司已经有员工可以胜任，你要考虑的是如何让他留下来为公司服务（升职位、给股份、给分红），因为这样的人不多，再好的可读性，交接也要能力对等的人。
如果暂时没有人可以胜任，建议顶多用在项目预演，而非直接上真实的项目（除非对实时性要求不高、出点 bug 没所谓的场合）。

吴国生 发表于 2018-5-20 11:00
我们做项目，安全级别要求较高的项目，从来不用操作系统。linux和ucos都达不到安全级别的要求。还是裸跑程 ...

如果源代码开放的RTOS,安全性还是可以的.功能简单情况下,裸跑是可靠点,功能复杂了,要求响应时间更严格了,RTOS还是有优势的.因为这么复杂的功能,用裸跑实现出问题的概率其实比用RTOS可能更大.

mark