在基于ARM7的C上编程的嵌入式应用程序(具有可移植性要求)中,当前使用基于商业优先级的抢占式RTOS,我们需要根据客户要求删除该RTOS和任何RTOS依赖关系.我们有8个任务使用许多HW接口,睡眠语句,I2C通信.实际上,SW很好地利用了RTOS功能来简化代码,尽管在没有RTOS的情况下可以管理时序要求.
几个函数,包括在许多地方调用的例程,当前实现阻塞(对于该线程)调用I2c驱动程序函数,睡眠语句等的序列.基于对客户不接受对I2C调用/休眠进行轮询的前提,此类调用必须然后是非阻塞并返回.问题当然是"返回"到"声明",当I2C完成或睡眠时间已经过去时,可能从顶层任务进入4次调用.
我正在为每项任务收集分层状态机设计,并在顶部安装一个简单的调度程序.但是处理几个例程,用于制作当时阻塞调用的序列,现在变成每个状态机,可以在几个地方和不同的函数调用深度调用,似乎需要为每个任务提供显式的堆栈功能,以便每次我启动子状态机时,我都可以为该进程分配状态并将它们推送到该任务的"状态堆栈",以便下一个调度程序对该任务的调用将能够完成所有分层状态继续处理它"停止"的地方.
您是否可以看到适用于该问题的其他设计架构,将代码快速移植到非抢占式范例的注意事项,或者指向富含思想的资源以及有关"RTOS移除"技术和设计的讨论？
这三个答案共同描绘了基于状态机的开发相关性和相关工具的良好画面,以避免重新发明轮子.我们的客户不会获得任何形式的许可,包括GPL.从答案中可以看出,如果想要使用没有RTOS的分层状态机并且禁止轮询呼叫,则无法绕过缓存状态.由于分层SM通过保留其结构(对例程的函数调用变为子状态机的调用)来帮助移植现有代码,所以我将使用提供的工具作为好例子.- 谢谢.
我希望能够为高端MSP430提供基本操作系统和基本文件系统,可能是MSP430F5438.我知道我可以使用像FreeRTOS,IAR PowerPac或Micrium这样的东西来命名操作系统和文件系统的一些选项.但是我希望能够在后期加载小applet或线程,理想情况下从文件系统中获取这些额外的代码.我的目标是不必重新刷新整个设备以更改或实现嵌入式设备上的功能.不确定在哪里开始实现此功能,或者我是否需要切换到另一个处理器,如ARM.
我想开发一些HAL(硬件抽象层)以在PIC32和一些ARM中使用.
基本上我想制作一些通常在操作系统上可用的代码,如通用引脚访问,通信库,设备I/O等.
你能用好书/网站告诉我吗？
我将从几周前发现的那个开始:http://www.kalinskyassociates.com/OnLineLearning.html
谢谢
我目前正在开发一个使用ARM Cortex M3微控制器和FreeRTOS作为系统操作系统的嵌入式项目.代码是由一位前同事编写的,遗憾的是该项目有一些奇怪的错误,我必须尽快找到并修复.
简短说明:该设备集成到车辆中,并使用集成调制解调器向远程服务器发送一些"特殊"数据.
主要问题:由于设备集成在车辆中,设备的电源可能随时丢失.因此,设备将"特殊"数据的某些部分存储到两个保留的闪存页面.此代码模块在两个闪存页面上作为eeprom仿真进行布局(用于从一个闪存页面到另一个闪存页面的耗损均衡和数据传输).eeprom仿真与所谓的"虚拟地址"一起使用,您可以在其中将任意大小的数据块写入当前活动/有效的闪存页面,并使用这些虚拟地址将其读回.前同事将eeprom仿真实现为多任务模块,您可以从应用程序中的每个任务读取/写入闪存页面.乍一看,一切似乎都很好.
但是我的项目经理告诉我,设备总是会丢失一些"特殊"数据,车辆中的电源电压下降到几伏,设备会尝试将数据保存到闪存中.通常电源大约为10-18伏,但如果电压降至7伏以下,则设备会收到一个被调用的中断powerwarn,并触发一个叫做的任务powerfail task.它powerfail task具有所有任务的最高优先级,并执行一些回调,例如调制解调器关闭,以及"特殊"数据存储在闪存页面中.我试着理解代码并调试了几天/几周,现在我很确定我发现了问题:
在powerfail任务执行的那些回调(称为powerfail回调)中,有RTOS调用,其他任务被暂停.但不幸的是,那些被填充的任务也可能EEPROM_WriteBlock()在接收到电源警告中断之前有一个未完成的呼叫.因此,powerfail任务执行回调,并且在其中一个回调中有一个EE_WriteBlock()调用,其中任务无法接受互斥锁,EE_WriteBlock()因为另一个任务(已暂停)已经采取了 - >死锁!
这是将数据写入闪存的例程:
uint16_t
EE_WriteBlock (EE_TypeDef *EE, uint16_t VirtAddress, const void *Data, uint16_t Size)
{
.
.
xSemaphoreTakeRecursive(EE->rw_mutex, portMAX_DELAY);
/* Write the variable virtual address and value in the EEPROM */
.
.
.
xSemaphoreGiveRecursive(EE->rw_mutex);
return Status;
}
当调用'xSemaphoreTakeRecursive()'时,这是RTOS特定的代码:
portBASE_TYPE xQueueTakeMutexRecursive( xQueueHandle pxMutex, portTickType xBlockTime )
{
portBASE_TYPE xReturn;
/* Comments regarding mutual exclusion as per those …我正在准备在Linux之上构建RTOS解决方案,这将在嵌入式设备上运行.我自己做了一些调查,但我仍然有点困惑.这些是我的标准:
易于在三星s3c2440 ARM9机器上运行
开源
与Linux一起使用
良好的社区支持
我见过RTLinux和Xenomai.Xenomai看起来更适合我,但我仍然感到困惑.
任何好的建议,专业和缺点？
我正在为不同的硬件(avr,arm7,tms55xx ......)和不同的rtoses(freeRTOS,rtx,dsp/bios)编写嵌入式应用程序.而且他们每一秒都需要与PC或其他数字设备进行通信.有时,交互逻辑非常先进.所以我对常用的方法(如状态机编程风格),协议规范或库感兴趣,可以简化开发这样的事情.
我目前正在开发我公司正在开发的消费电子产品的操作系统.我已经决定将freeRTOS作为我们操作系统的主干,并且正努力在操作系统中实现硬件功能.但是,我遇到了一个关于在freeRTOS中运行第三方应用程序的问题.
最初我认为任务是一个应用程序,基本上你有"myapplication.c"和"myapplication.h"包含所有应用程序必需的函数,代码将驻留在任务中的for(;;)循环中(作为一个主要的while循环).然后,当用户决定运行该应用程序时,会将一个函数指针传递给队列,然后我的app_launcher任务会使用第三方任务或应用程序创建新任务.
然而,这种方法的问题是操作系统已经被编译并驻留在微控制器上,并且可以根据用户的需要安装和删除应用程序......显然,应用程序需要从操作系统进行编译和执行.在标准的unix机器上,我会使用fork之类的东西来选择可执行文件并给它自己的进程.但是我在freeRTOS中找不到类似的功能..我的另一个想法是接近应用程序开发的脚本语言,但我不知道如何启动这些应用程序......
所以问题是,如何让freeRTOS从尚未加入操作系统的第三方开发人员那里运行应用程序？
我有一个为freeRTOS编写的简单程序（实现一个计时器）。
我想在一个空的虚拟机（VirtualBox或QEMU或其他）中运行该程序。
我需要制作一个可以在空VM中运行的二进制文件。
任何建议或指导我该怎么做？
我在freeRTOS主页上检查了很多东西，但找不到有用的东西。
我想通过使用 RTOS 更具体地了解硬实时系统背后的概念。根据 RTOS 的定义，它保证实时任务永远不会超过其最后期限。
void RT_task1(void *params)
{
do_inits();
while (true)
{
... // Do the job whatever it is in realtime.
Delay(20); // Wait for 20 ms.
}
}
这是 RTOS 中基于任务的实时系统的简单结构。在这一点上，我想知道这些问题；
1）此代码块中 RTOS 定义中提到的“DEADLINE”是什么。是“Delay”时间20 ms还是“Do Job”部分确定的其他时间？
2) 如果超过期限会怎样？我知道它是由 RTOS 保证的，但在“假设情况”下：我们是否定义了灾难性错误过程？
3）RTOS如何保证工期？我的意思是，我可以运行大量 RT 任务，因此 CPU 资源可能不够，或者编程错误的任务比其他 RT 任务消耗了太多时间？“保证”部分在哪里？
我知道 RTOS 和传统操作系统之间的主要区别在于调度程序。RTOS采用确定性的方式为用户提供调度保证。然而，这些信息并不能完全满足我对整个系统的理解。
谢谢。
PendSV和SVCall都是由软件调用的——SVCall是通过调用svc指令来调用的，PendSV是通过设置Cortex-M的特定寄存器来调用的。PendSV 用于上下文切换，SVCall 用于访问操作系统内核功能和设备驱动程序。
我想知道的不仅仅是“PendSV 用于上下文切换，SVCall 用于启用调度程序”。我找不到更多信息。
干杯