spa*_*e78 29 embedded rtos firmware
首先是我的问题的背景,具体细节如下:
我在平台上工作的公司目前是使用MPLAB IDE作为开发环境的Microchip PIC32系列.此前,我们还为同一应用编写了Microchip dsPIC和TI MSP系列的固件.固件非常简单,因为代码分为三个主要模块:设备控制,数据采样和用户通信(通常是用户PC).器件控制是通过GPIO总线和至少一部分需要SPI或I2C控制的部分组合实现的.使用定时器模块中断数据采样以保持采样频率,使用更多SPI/I2C和GPIO总线来控制采样硬件(即ADC).用户通信目前通过USB使用Microchip App Framework实现.
那么现在的问题是:鉴于我上面所描述的内容,我会考虑在什么时候为我的项目使用RTOS？目前我正在考虑将这些可能的触发点作为使用RTOS的理由:
您认为我应该考虑哪些其他方面？根据您的经验,您认为(或强迫)您考虑使用RTOS而不是仅仅在基本运行时运行代码？关于为RTOS设计/编程的其他资源的指针也非常受欢迎.
Dan*_*Dan 33
您可能希望使用RTOS的原因有很多.它们的多样性以及它们适用于您的情况的程度很难说.(注意:我倾向于这样思考:RTOS 意味着硬实时,这意味着抢占内核...)
速率单调分析(RMA) - 如果您想使用速率单调分析来确保您的时间期限得到满足,您必须使用先发制人的调度程序
通过基于优先级的抢先RTOS,即使不使用RMA,也可以满足实时截止日期,您的调度程序可以帮助确保满足最后期限.矛盾的是,RTOS通常会增加中断延迟,因为内核中的关键部分通常会屏蔽中断
管理复杂性 - 当然,RTOS(或大多数OS风格)可以帮助解决这个问题.通过允许将项目分解为独立的线程或进程,并使用OS服务(如消息队列,互斥,信号量,事件标志等)进行通信和同步,您的项目(根据我的经验和意见)变得更易于管理.我倾向于从事大型项目,大多数人都了解保护共享资源的概念,所以很多新手的错误都不会发生.但要注意,一旦你采用多线程方法,在你解决问题之前,事情会变得更加复杂.
使用第三方软件包 - 许多RTOS提供其他软件组件,例如协议栈,文件系统,设备驱动程序,GUI软件包,引导加载程序和其他中间件,它们可以帮助您更快地构建应用程序,而不仅仅是"集成器".一个DIY商店.
测试 - 是的,当然,您可以将每个控制线程视为具有定义良好的接口的可测试组件,尤其是在使用一致方法时(例如始终在消息队列中的单个位置阻塞).当然,这不能替代单元,集成,系统等测试.
稳健性/容错性 - RTOS也可以为处理器的MMU提供支持(在您的PIC情况下,我认为不适用).这允许每个线程(或进程)在其自己的受保护空间中运行; 线程/进程不能"浸入"彼此的内存并踩踏它.甚至设备区域(MMIO)也可能不受某些(或所有)线程的限制.严格地说,您不需要RTOS来利用处理器的MMU(或MPU),但是2可以很好地协同工作.
通常,当我可以使用RTOS(或某种类型的抢占式多任务程序)进行开发时,结果往往更清晰,更模块化,更良好,更易于维护.当我有选择时,我会使用一个.
请注意,多线程开发有一点学习曲线.如果你是新来的RTOS /多线程开发,你可能有兴趣在一些文章选择一个RTOS,抢占的危险,并以抢占式多任务的介绍.
最后,即使您没有提出建议......除了众多商业RTOS之外,还有免费产品(FreeRTOS是最受欢迎的产品之一),而Quantum平台是一个基于事件驱动的框架.包含抢占式内核的活动对象的概念.有很多选择,但我发现拥有源代码(即使RTOS不是免费的)也是有利的,尤其是.调试时
小智 6
RTOS首先允许您将并行流组织到一组任务中,并在它们之间进行明确定义的同步.
IMO,非RTOS设计仅适用于单流架构,其中所有程序都是一个无限循环.如果您需要多流程 - 许多任务,并行运行 - 您最好使用RTOS.如果没有RTOS,您将被迫在内部实施此功能,重新发明轮子.