我的一位同事从一个涉及串行通信的软件开发人员那里得到了一个报价,在他们的报价中,开发人员做了以下声明:
...Windows 7 操作系统,使用非实时串行通信设置。
Windows 7 是否真的不支持实时串行通信?为了澄清“实时”的含义,该项目涉及机器人自动化,任何通信延迟(例如缓冲)都可能导致产品损坏或停止生产线。我找不到任何证据来支持或否认这一说法。不过我不相信这是真的,而且我认为这可能与他们使用 VB.Net 进行开发有关。
我的一位同事从一个涉及串行通信的软件开发人员那里得到了一个报价,在他们的报价中,开发人员做了以下声明:
...Windows 7 操作系统,使用非实时串行通信设置。
Windows 7 是否真的不支持实时串行通信?为了澄清“实时”的含义,该项目涉及机器人自动化,任何通信延迟(例如缓冲)都可能导致产品损坏或停止生产线。我找不到任何证据来支持或否认这一说法。不过我不相信这是真的,而且我认为这可能与他们使用 VB.Net 进行开发有关。
此处使用的“实时”术语实际上并不指串行通信总线中的任何内容。
但是,这确实与 Windows 多任务调度程序的设计不支持具有硬期限的实时任务有关。
有关某些信息,请参阅此问题为什么认为 Windows 不适合实时系统/高性能服务器?
假设您的计算机连接了一个粒子加速器,并且您必须确保每 10 微秒磁力列车切换为下一组电池供电,但 Windows 决定是时候应用一些 Windows 更新补丁了。您的光子流将无法正确重定向,并可能对系统造成损坏。
这是一个相当荒谬的说法,Windows 本身并不是一个实时操作系统。它不能提供用户模式代码响应速度足够快的硬性保证。除了线程调度延迟之外,像将进程的页面交换到页面文件这样的简单事故就足以导致让它再次运行的任意延迟。任何按需分页虚拟内存操作系统的属性。因此,假设您不打算编写 ring 0 内核代码,“串行通信设置”当然也不能。没有人会。
这不是一个实际问题,使用串口的唯一一点是与机器人的控制器通信。这提供了实时保证。
只有当您命令机器人进行不受限制的移动并使用外部传感器使其停止时,您才会遇到麻烦。当您需要找到一个您不知道其位置的对象时,这种情况并不少见。一个体面的控制器知道如何做到这一点,避免在你的 Windows 代码中实现它。无论如何,机器人本身内置的固体超程保护触发急停是必要的,你也不能相信那个传感器。
不,Windows 7(实际上是所有主流 Windows 版本)都不是实时操作系统。澄清实时操作系统的含义:
实时操作系统 (RTOS) 是旨在为实时应用程序请求提供服务的操作系统 (OS)。它必须能够处理传入的数据,通常没有缓冲延迟。处理时间要求(包括任何操作系统延迟)以十分之一秒或更短的时间测量。
RTOS 的一个关键特性是它在接受和完成应用程序任务所需的时间量方面的一致性水平。可变性是抖动。 [1] 硬实时操作系统比软实时操作系统具有更少的抖动。主要设计目标不是高吞吐量,而是保证软或硬性能类别。通常可以或通常可以满足截止日期的 RTOS 是软实时 OS,但如果它可以确定地满足截止日期,则它是硬实时 OS。[2]
RTOS 具有用于调度的高级算法。调度程序的灵活性支持更广泛的计算机系统进程优先级编排,但实时操作系统更频繁地专用于一组狭窄的应用程序。实时操作系统的关键因素是最小的中断延迟和最小的线程切换延迟;实时操作系统的价值更多的是它可以响应的速度或可预测性,而不是它在给定时间段内可以执行的工作量。 [3]
请注意,大多数时候实时操作系统效率较低(即吞吐量较低),这就是为什么没有一个主流操作系统是实时的(例如,Linux 的实时版本使用完全不同的内核)——它唯一的在非常精确的时间绝对至关重要的情况下,这是值得的。
Windows CE是一个实时操作系统Real-Time Systems with Microsoft Windows CE 2.1