在研究嵌入式系统时，我发现了适用于Linux的libmraa库。但我不能确定它是否是适合我的工具
我想做的是实现一个包含步进电机、加热器和风扇等的嵌入式系统。如果我能用Linux做这件事，那就太好了，但我认为这不实用，也不可能。
libmraa是否提供调度保证，以确保确定性行为和及时响应事件和中断？因为我总是确保步行者总是工作不受任何干扰。
libmraa只是一个爱好者的工具，还是一个真正的嵌入式系统的好工具？
警告：我没有使用mraa的经验。不过，除了查看它的内容外，我所做的是克隆repo并grep"sched"、"nice"等的源代码。
我唯一找到的是这个mraa_set_priority() API：
https://github.com/intel-iot-devkit/mraa/blob/master/api/mraa/common.h#L153
请注意，它适用于SCHED_RR，但对于更具攻击性和确定性的SCHED_FIFO和现代细化SCHED_DEADLINE，都没有API。
因此：
libmraa是否提供调度保证以确保确定性行为和及时响应事件和中断？
否（除了本SCHED_RR API相对较小的例外）。
它这样做是正确的，因为"Libmraa是一个C/C++库[…]，用于与Galileo、Edison和其他平台上的IO接口"，而调度策略与此无关：调度策略是一个特定于应用程序和/或系统集成范围（考虑其他过程）的设计决策和设置在大多数情况下（存在一些例外），将特定的sched方案硬编码到应用程序中，而不考虑其他正在运行的进程，也不考虑内核中内置的sched策略机制（内核配置选择），这不是一个明智的选择。
这是的工作
-
对系统进行基准测试（内核+应用程序+其他进程），
-
通过构建或运行时配置选项）和/或将内核配置为提供新的时间表选项，
-
再次进行基准测试，冲洗，重复。
这方面的标准工具是：
- 很好
- chrt
- 任务集
以及他们使用的标准API，如sched_set/getaffinity、sched_set/getscheduler等（查看util-linux包中的shchedutils/源目录）。
至于内核调度选项，请查看scheduler/子目录中的文档。您还可以查看CPU cgroup控制器，查看cgroup-v2.txt或cgroup-v1/子目录，具体取决于您的内核版本。
我使用这些替代方案为嵌入式产品做了一些基准测试/测试，最终决定使用CPU cgroup控制器的CPU共享，因为它们是我的案例中"最聪明的自适应"和灵活的负载平衡机制（实时与非实时的混合，但对产品功能很重要，与日志等低优先级任务相比）。我没有考虑/测试cgroups-cpuset，这对双核嵌入式系统和周期/配额设置都没有多大意义。
当然，可以使用上述技术的组合。
libmraa只是一个爱好者的工具，还是一个真正嵌入式的好工具系统
再说一遍，没有任何经验。不过，有一些英特尔开源的经验（来自他们的e10000以太网驱动程序），对我来说，英特尔是认真的，不会在野外丢弃一些源代码，然后忘记它。即使是对于一个非常"原型风格"的项目。对于mraa，看看github，有一个最小的wiki，一个问题跟踪显示一些问题确实得到了修复。
因此，我倾向于相信它是"真正的嵌入式系统"。不过，社区可能很小，这是一个不容忽视的因素。
PS:
其中最重要的是：基准，基准，基准。。。
编辑：
至于"真正的RTOS"与Linux：
我在这方面也有一些经验，尽管从技术上讲，这是你所描述的应用程序的合理选择，但前提是你有时间（=金钱）和/或错过最后期限可能会导致灾难性事件，如伤害/杀死某人或摧毁某物（包括你自己的硬件，前无人机坠落），或根本无法完成关键任务。想想国防、航空航天、卫生/医疗设备。
Linux（代码->构建->闪存/安装->调试，重复）与实时操作系统相比，Linux的开发周期将更快（你可以在没有任何硬件的情况下在电脑上制作很多东西的原型），libs/应用程序的生态系统将更丰富，社区将更广泛，所需的特殊技术培训更少，所有东西都需要大量的文档等=更快的上市时间和丰富的功能。
如果考虑到"没有灾难性事件"的情况，那么使用真正的嵌入式RT OS更多的是BOM（材料清单：更少的闪存/RAM/CPU功率）的问题，或者有时与产品可靠性有关的法律责任。
正如@LP的回答所指出的那样，Linux的硬实时性是可能的（不一定在用户区）。
lib无法授予实时行为。这是一个核心问题。
您应该使用实时Linux内核：例如RTI或PREEMPT RT Patch。