为什么 MPC5554 板不需要 RTOS?它是否带有内置 OS?
Why doesn't MPC5554 board requires a RTOS? Does it come with a built-in OS?
我在看 MPC5554 板的参考手册,没有提到使用的任何操作系统(内核)。应用程序可以 运行 无需使用此板上的任何外部 OS。
我理解RTOS有内存管理,任务调度功能,请问这些功能是MPC5554内置固件完成的吗?
这些板有 RTOS 的供应商,所以我想知道在什么应用中需要它们?
RTOS 是否只是板级实现之上的另一种抽象?
如果我们在上面放一个 RTOS,那不会与内置 OS 冲突吗?
没有内置 OS - 您为什么会这样认为?
许多嵌入式应用程序 运行 没有 OS 的裸机(RTOS 或其他),但无论如何 RTOS 的选择是开发人员决定不是电路板制造商的决定。
RTOS从根本上提供调度、同步、进程间通信和定时服务。可以为具有 MMU 的设备提供内存管理,但这不是给定的。裸机应用程序可以建立 C 运行 时间环境并引导至 main()
,无需调度或 IPC 等。在最简单的 RTOS 中,系统引导至 main()
初始化和启动 RTOS 的地方,而不是像 GPOS.
中那样启动 `main() 的 OS
电路板制造商可以为一个或多个特定的 RTOS 提供 电路板支持包 ,但 BSP(或 HAL 或驱动程序库)同样可以包含仅限裸机或 RTOS 独立设备驱动程序。通常是供开发人员集成 RTOS、设备驱动程序和中间件(例如文件系统和网络)等,这些可能来自单个或多个供应商。您必须了解,许多(或者可能是大多数)开发人员将围绕微控制器而不是使用 COTS 硬件来设计自己的电路板,因此没有通用的解决方案,嵌入式开发往往是一种更多部件套件方法。
Clifford 已经一语中的了。根据您希望完成的任务的复杂性,您可能需要重新考虑您到底需要什么。如果您对 RTOS 的唯一兴趣是基于 "real-time" 部分,那么创建您自己的小型 interrupt-driven 裸机应用程序可能更容易(也更便宜)。一般来说,我发现如果性能约束是您主要关心的问题,那么抽象越少越好。
根据您表述问题的方式,我假设您正在查看以 MPC5554 作为微型的评估板或开发套件,在这种情况下,您可能已经有了一些基本的启动代码做一些事情,比如设置内存控制器和一些外围设备(大多数开发工具包或 IDE 都带有一些您可以重复使用的示例代码)。
一个简单的应用程序可能会执行以下操作:
- 初始化运行时间环境(MMU、INTC、FMPLL)
- 初始化您要使用的外围设备,例如。 ADC、GPIO、SPI 等(如果您有任何需要 EBI 的外围设备,这可能会变得非常复杂)
- 初始化eMIOS以生成高优先级的定时中断(即您的主要处理任务循环)
我看到这通常工作的方式是,一旦上述所有初始化完成,您的主应用程序线程 运行 进入无限循环,您可以将其用作后台任务来处理垃圾收集或一些 non-time-critical 故障检测。然后,在您创建的定时中断的 ISR 中,您实现一个基本调度程序来执行您的 driver-level 处理(例如 trigger/read ADC、read/write GPIO、启动任何 IPC 事务等) .一个极其基本的概念可能如下所示:
void fastTaskISR()
{
static uint8 frameCount = 1;
...
switch(frameCount)
{
case 1:
//Task 1
break;
case 2:
//Task 2
break;
case 3:
//Task 3
break;
case 4:
//Task 4
break;
case 5:
//Task 5
break;
default:
//Default case for robustness. Error.
break;
}
frameCount++;
if(frameCount > 5)
{
frameCount = 1;
}
...
}
您可以选择使用其中一项计划任务生成软件中断,然后可以将其用于 运行 一些较慢的任务或更复杂的控制逻辑。在我工作的地方,这是一个久经考验的真实公式:eMIOS 驱动 "fast task"(通常在 100us 和 1ms 周期之间)+ 软件中断驱动 "normal task" 其中 运行 是 higher-level控制逻辑,通常从 Simulink 模型生成。不用说,我们对 BSP 和驱动程序级代码做了很多重用。
我在看 MPC5554 板的参考手册,没有提到使用的任何操作系统(内核)。应用程序可以 运行 无需使用此板上的任何外部 OS。
我理解RTOS有内存管理,任务调度功能,请问这些功能是MPC5554内置固件完成的吗?
这些板有 RTOS 的供应商,所以我想知道在什么应用中需要它们?
RTOS 是否只是板级实现之上的另一种抽象?
如果我们在上面放一个 RTOS,那不会与内置 OS 冲突吗?
没有内置 OS - 您为什么会这样认为?
许多嵌入式应用程序 运行 没有 OS 的裸机(RTOS 或其他),但无论如何 RTOS 的选择是开发人员决定不是电路板制造商的决定。
RTOS从根本上提供调度、同步、进程间通信和定时服务。可以为具有 MMU 的设备提供内存管理,但这不是给定的。裸机应用程序可以建立 C 运行 时间环境并引导至 main()
,无需调度或 IPC 等。在最简单的 RTOS 中,系统引导至 main()
初始化和启动 RTOS 的地方,而不是像 GPOS.
电路板制造商可以为一个或多个特定的 RTOS 提供 电路板支持包 ,但 BSP(或 HAL 或驱动程序库)同样可以包含仅限裸机或 RTOS 独立设备驱动程序。通常是供开发人员集成 RTOS、设备驱动程序和中间件(例如文件系统和网络)等,这些可能来自单个或多个供应商。您必须了解,许多(或者可能是大多数)开发人员将围绕微控制器而不是使用 COTS 硬件来设计自己的电路板,因此没有通用的解决方案,嵌入式开发往往是一种更多部件套件方法。
Clifford 已经一语中的了。根据您希望完成的任务的复杂性,您可能需要重新考虑您到底需要什么。如果您对 RTOS 的唯一兴趣是基于 "real-time" 部分,那么创建您自己的小型 interrupt-driven 裸机应用程序可能更容易(也更便宜)。一般来说,我发现如果性能约束是您主要关心的问题,那么抽象越少越好。
根据您表述问题的方式,我假设您正在查看以 MPC5554 作为微型的评估板或开发套件,在这种情况下,您可能已经有了一些基本的启动代码做一些事情,比如设置内存控制器和一些外围设备(大多数开发工具包或 IDE 都带有一些您可以重复使用的示例代码)。
一个简单的应用程序可能会执行以下操作:
- 初始化运行时间环境(MMU、INTC、FMPLL)
- 初始化您要使用的外围设备,例如。 ADC、GPIO、SPI 等(如果您有任何需要 EBI 的外围设备,这可能会变得非常复杂)
- 初始化eMIOS以生成高优先级的定时中断(即您的主要处理任务循环)
我看到这通常工作的方式是,一旦上述所有初始化完成,您的主应用程序线程 运行 进入无限循环,您可以将其用作后台任务来处理垃圾收集或一些 non-time-critical 故障检测。然后,在您创建的定时中断的 ISR 中,您实现一个基本调度程序来执行您的 driver-level 处理(例如 trigger/read ADC、read/write GPIO、启动任何 IPC 事务等) .一个极其基本的概念可能如下所示:
void fastTaskISR()
{
static uint8 frameCount = 1;
...
switch(frameCount)
{
case 1:
//Task 1
break;
case 2:
//Task 2
break;
case 3:
//Task 3
break;
case 4:
//Task 4
break;
case 5:
//Task 5
break;
default:
//Default case for robustness. Error.
break;
}
frameCount++;
if(frameCount > 5)
{
frameCount = 1;
}
...
}
您可以选择使用其中一项计划任务生成软件中断,然后可以将其用于 运行 一些较慢的任务或更复杂的控制逻辑。在我工作的地方,这是一个久经考验的真实公式:eMIOS 驱动 "fast task"(通常在 100us 和 1ms 周期之间)+ 软件中断驱动 "normal task" 其中 运行 是 higher-level控制逻辑,通常从 Simulink 模型生成。不用说,我们对 BSP 和驱动程序级代码做了很多重用。