RTOS

很多初学者都是从裸机开始学起,不能明白裸机和操作系统的区别。甚至有不少人认为用中断就能代替多任务处理,你认同吗?

裸机系统    

裸机系统通常分成轮询系统和前后台系统。

1 轮询系统

轮询系统即是在裸机编程的时候,先初始化好相关的硬件,然后让主程序在一个死循环里面不断循环,顺序地做各种事情,大概的伪代码具体如代码清单所示:

int main(void)
{  
    /* 硬件相关初始化 */  
    HardWareInit();
    
  /* 无限循环 */  
  for (;;) 
  {    
      /* 处理事情 1 */    
      DoSomething1();
      
    /* 处理事情 2 */    
    DoSomethingg2();
    
    /* 处理事情 3 */    
    DoSomethingg3();  
  }
}

轮询系统是一种非常简单的软件结构,通常只适用于那些只需要顺序执行代码且不需要外部事件来驱动的就能完成的事情。在代码清单 1-1 中,如果只是实现 LED 翻转,串口输出,液晶显示等这些操作,那么使用轮询系统将会非常完美。但是,如果加入了按键操作等需要检测外部信号的事件,用来模拟紧急报警,那么整个系统的实时响应能力就不会那么好了。

假设DoSomethingg3 是按键扫描,当外部按键被按下,相当于一个警报,这个时候,需要立马响 应 , 并 做 紧 急 处 理 , 而 这 个 时 候 程 序 刚 好 执 行 到 DoSomethingg1 , 要 命 的 是DoSomethingg1 需要执行的时间比较久,久到按键释放之后都没有执行完毕,那么当执行到 DoSomethingg3 的时候就会丢失掉一次事件。足见,轮询系统只适合顺序执行的功能代码,当有外部事件驱动时,实时性就会降低。

2 前后台系统    

相比轮询系统,前后台系统是在轮询系统的基础上加入了中断。外部事件的响应在中断里面完成,事件的处理还是回到轮询系统中完成,中断在这里我们称为前台, main 函数里面的无限循环我们称为后台,大概的伪代码见代码清单所示:

int flag1 = 0;
int flag2 = 0;
int flag3 = 0;

int main(void)
{  
    /* 硬件相关初始化 */  
    HardWareInit();
  
    /* 无限循环 */  
    for (;;) 
    {    
        if (flag1) 
        {      
            /* 处理事情 1 */      
            DoSomething1();    
        }
        
        if (flag2) 
        {      
            /* 处理事情 2 */      
            DoSomethingg2();    
        }
    
        if (flag3) 
        {      
            /* 处理事情 3 */      
            DoSomethingg3();    
        }  
    }
}

void ISR1(void)
{ 
     /* 置位标志位 */  
     flag1 = 1;  
     
     /* 如果事件处理时间很短,则在中断里面处理  
     如果事件处理时间比较长,在回到后台处理 */  
     DoSomething1();
}

void ISR2(void)
{  
    /* 置位标志位 */  
    flag2 = 2;
  
    /* 如果事件处理时间很短,则在中断里面处理  
    如果事件处理时间比较长,在回到后台处理 */  
    DoSomething2();
}

void ISR3(void)
{  
    /* 置位标志位 */  
    flag3 = 1; 
    
    /* 如果事件处理时间很短,则在中断里面处理  
    如果事件处理时间比较长,在回到后台处理 */  
    DoSomething3();
}

在顺序执行后台程序的时候,如果有中断来临,那么中断会打断后台程序的正常执行流,转而去执行中断服务程序,在中断服务程序里面标记事件,如果事件要处理的事情很简短,则可在中断服务程序里面处理,如果事件要处理的事情比较多,则返回到后台程序里面处理。

虽然事件的响应和处理是分开了,但是事件的处理还是在后台里面顺序执行的,但相比轮询系统,前后台系统确保了事件不会丢失,再加上中断具有可嵌套的功能,这可以大大的提高程序的实时响应能力。在大多数的中小型项目中,前后台系统运用的好,堪称有操作系统的效果。

RTOS多线程    

相比前后台系统,多线程系统的事件响应也是在中断中完成的,但是事件的处理是在线程中完成的。在多线程系统中,线程跟中断一样,也具有优先级,优先级高的线程会被优先执行。    当一个紧急的事件在中断被标记之后,如果事件对应的线程的优先级足够高,就会立马得到响应。相比前后台系统,多线程系统的实时性又被提高了。    

多线程系统大概的伪代码具体见代码清单所示:

int flag1 = 0;
int flag2 = 0;
int flag3 = 0;

int main(void)
{  
    /* 硬件相关初始化 */  
    HardWareInit();
    
    /* OS 初始化 */  
    RTOSInit();
   
    /* OS 启动,开始多线程调度,不再返回 */  
    RTOSStart();
}

void ISR1(void)
{  
    /* 置位标志位 */  
    flag1 = 1;
}

void ISR2(void)
{  
    /* 置位标志位 */  
    flag2 = 2;
}

void ISR3(void)
{  
    /* 置位标志位 */  
    flag3 = 1;
}

void DoSomething1(void)
{  
    /* 无限循环,不能返回 */  
    for (;;) 
    {    
        /* 线程实体 */    
        if (flag1) {
        }  
    }
}

void DoSomething2(void)
{ 
     /* 无限循环,不能返回 */  
     for (;;) {    
         /* 线程实体 */    
         if (flag2) {
         }  
     }
}

void DoSomething3(void)
{  
    /* 无限循环,不能返回 */  
    for (;;) {    
        /* 线程实体 */    
        if (flag3) {
        }  
    }
}

相比前后台系统中后台顺序执行的程序主体,在多线程系统中,根据程序的功能,我们把这个程序主体分割成一个个独立的,无限循环且不能返回的小程序,这个小程序我们称之为线程。

每个线程都是独立的,互不干扰的,且具备自身的优先级,它由操作系统调度管理。加入操作系统后,我们在编程的时候不需要精心地去设计程序的执行流,不用担心每个功能模块之间是否存在干扰。

加入了操作系统,我们的编程反而变得简单了。整个系统随之带来的额外开销就是操作系统占据的那一丁点的 FLASH 和 RAM。现如今,单片机的 FLASH 和 RAM 是越来越大,完全足以抵挡 RTOS 那点开销。

轮询、前后台和多线程系统软件模型区别:

1.jpg

来源:单片机与嵌入式

免责声明:本文为转载文章,转载此文目的在于传递更多信息,版权归原作者所有。本文所用视频、图片、文字如涉及作品版权问题,请联系小编进行处理(联系邮箱:cathy@eetrend.com)。

围观 11

对于搞单片机的特别用8051系列工程师来说,谈到单片机的RTOS,很多时候会问一句:“为什么要用RTOS?单片机就这一点资源,使用RTOS能保证效率吗?”

对于这个问题,我会反问:“你用单片机的目的是什么?是为了用单片机的C编程,单片机的汇编编程甚至于用单片机的二进制指令编程?”上个世纪80年代,工程师用二进制指令给Z80编程,现在还有谁在用?现在还有人死抱着汇编不放,但越来越多的人工程师使用C编程(我起初也是使用汇编的),为什么?

因为我们的目的是在有限的时间甚至是不充足的时间内把项目保质保量的完成!使用什么工具和方法是次要的(如果你的项目以成本放在第一位,则另当别论,这时,也是要考虑开发时间的)。时间就是金钱啊,一个产品在单片机上增加些许成本是可以接受的。

况且,使用8051系列单片机时,单片机资源也常有富余,CPU一般情况也只是空转,这就为它使用RTOS创造了条件。那么,使用RTOS的好处呢?

我举一个例子吧。假设我们编一个串行通讯程序,通讯协议如下:数据包长度为NBYTE,起始字节为STARTBYTE1,STARTBYTE2,最后一个字节为检验和,中间字节不可能出现连续出现STARTBYTE1,STARTBYTE2。

第一种方法,在中断中处理协议:

unsigned char Buf[NBYTE-2];
bit GetRight = 0;
void comm(void) interrupt 4//"串行口中断"
{    
    static unsigned char Sum,Flag = 0,i;    
    unsigned char temp;    if(RI == 1)    
    {        
        RI = 0;        
        temp = SBUF;        
        switch(Flag)        
        {        
        case 0:            
            if(temp == STARTBYTE1)            
            {               
                 Flag = 1;            
             }            
             break;        
         case 1:             
             if(temp == STARTBYTE2)            
             {                
                 Sum = STARTBYTE1 + STARTBYTE2;                
                 i = 0;                
                 Flag = 2;                
                 break;            
             }            
             if(temp == STARTBYTE1) break;            
             Flag = 0;            
             break;        
         case 2:            
         if(temp == STARTBYTE1)           
         {                
             Flag = 3;                
             break;            
         }            
         Sum += temp;            
         if((i >= (NBYTE-3)) && Sum == 0)            
         {                
             GetRight = 1;                
             Flag = 0;                
             break;            
         }            
         Buf[i++] = temp;            
         break;        
         case 3:            
         if(temp == STARTBYTE2)            
         {                
             Sum = STARTBYTE1 + STARTBYTE2;                
             Flag = 2;                
             i = 0;                
             break;            
         }           
         Sum += STARTBYTE1;            
         if((i >= (NBYTE - 3))&&Sum == 0)            
         {                
             GetRight = 1;                
             Flag = 0;                
             break;            
         }            
         Buf[i++] = STARTBYTE1;            
         if(temp == STARTBYTE1)            
         {                
             break;             
         }            
         Sum += temp;            
         if((i >= (NBYTE-3))&&Sum == 0)            
         {                
             GetRight = 1;                
             Flag = 0;                
             break;            
         }            
         Buf[i++] = temp;            
         Flag = 2;            
         break;        
     }    
  }
}
第二种方法,使用队列中断函数:
void comm(void) interrupt 4//"串行口中断"
{    
    if(RI == 1)    
    {
          RI=0;        
          SBUF 入队;    
     }
}
主程序不断调用的函数:
unsigned char Buf[NBYTE-2];unsigned char ReadSerial(unsigned char *cp)
{    
    unsigned char i;    
    unsigned char temp,Sum;    
    temp = 队列中数据个数;    
    if(temp < (NBYTE)) return 0;
    
    出队 temp;    
    if(temp != STARTBYTE1) return 0;
    
    temp=队列首字节;     
    if(temp != STARTBYTE2) return 0;
    
    出队 temp;    
    sum = STARTBYTE1 + STARTBYTE2;    
    for(i = 0;i < NBYTE-3;i++)    
    {
        temp = 队列首字节;        
        if(temp == STARTBYTE1)        
        {            
            temp = 队列次首字节;            
            if(temp == STARTBYTE2) return 0;        
        }        
        出队 temp;        
        *cp++ = temp;        
        Sum += temp;    
    }    
    temp = 队列首字节;    
    Sum += temp;    
    if(Sum != 0) return 0;    
    出队 temp;    
    return 1;
}
第三种方法,使用RTOS中断函数:
void comm(void) interrupt 4//"串行口中断" 
 {     
     OS_INT_ENTER();     
     if(RI == 1)     
     {        
         RI = 0;        
         OSIntSendSignal(RECIVE_TASK_ID);     
     }    
     OSIntExit();
}
ID为RECIVE_TASK_ID的任务.
void Recive(void) 
{     
    unsigned char temp,temp1,Sum,i;      
    OSWait(K_SIG,0);     
    temp = SBUF;     
    while(1)     
    {         
        while(1)         
        {             
            OSWait(K_SIG,0);             
            temp1 = SBUF;             
            if((temp == STARTBYTE1)&&(temp1 == STARTBYTE2)) break;             
            temp = temp1;         
        }         
        Sum = STARTBYTE1 + STARTBYTE2;         
        OSWait(K_SIG,0);         
        temp = SBUF;         
        for(i = 0;i < NBYTE-3;i++)         
        {             
            OSWait(K_SIG,0);             
            temp1 = SBUF;             
            if((temp == STARTBYTE1)&&(temp1 == STARTBYTE2))             
            {                 
                OSWait(K_SIG,0);                 
                temp=SBUF;                 
                i = -1;                 
                Sum = STARTBYTE1 + STARTBYTE2;                 
                continue;             
            }             
            Buf[i] = temp;             
            Sum += temp;             
            temp = temp1;         
        }         
        Sum += temp1;         
        if(Sum == 0) OSSendSignal(命令解释任务 ID);     
    }
}

以下为这几种方法的比较可读性和编程容易性方面

第三钟方法最好(如果允许使用goto语句,程序更加简单易读)

第二种次之(因为要编队列程序)

第一种相对较差,如果协议更加复杂,这方面更加明显。

程序简单易读,自然出错机会小了。

RAM占用方面,第三种方法较少,第二种最多(因为队列占用大量空间),第一种最少。

中断执行时间方面,第三种方法最长,第二种最短,第一种较长。

从功能方面,第三种方法最强,它还可以进行超时处理(虽然例子程序没有),其它方法均不行。

如果数据来的太快,命令处理程序来不及处理,三种方法处理方式不太一样,第一种和第三种方法类似:丢弃以前数据,第二种则是丢弃后到的数据。而且,第二种方法必须等命令处理程序完成后才处理下一个数据包,而第一种和第三种方只需命令处理程序将数据收取后就可处理下一个数据包。也就是说,第一种和第三种与命令处理程序并行处理,第二种方法为串行处理。

现在,一般情况下,开发的效率第一,执行的效率(包括执行时间和资源占用)第二。在这种情况下,降低些许效率换取开发的效率的较大提高,何乐而不为?

何况,单个模块的执行的效率高不等于整个程序执行效率高。例如,如果程序需要等待一段时间,一般用程序延时或定时器延时。无论何种方法,CPU不再处理其它工作,效率很低。而用RTOS,等待的时候CPU可以处理其它工作,效率得到提高。

以下摘自《uC/OS-II--源码公开的实时嵌入式操作系统》:

“实时内核也称为实时操作系统或RTOS。使用它使得实时应用程序的设计和扩展变得容易。不需要大的改动就可以增加新的功能。通过应用程序分割为若干独立的任务,RTOS使得应用程序的设计过程大为简化。使用可剥夺性的内核时,所有时间要求苛刻的事件都得到了尽可能快捷、有效的处理。通过有效的服务;如信号量、邮箱、队列、延时、超时等;RTOS使得资源得到更好的利用。“如果应用项目对额外的需求可以承受,应该考虑使用实时内核。这些额外的需求是:内核的价格,额外ROM/RAM开销,2至4百分点的CPU额外负担。“还有没提到的一个因素是使用实时内核增加的价格成本。在一些应用中,价格就是一切,以至于对使用RTOS连想都不敢想。”

总而言之,适用的就是最好的,不要拒绝RTOS,在它适用的情况下,它工作得很好。

来源:STM32嵌入式开发

免责声明:本文为转载文章,转载此文目的在于传递更多信息,版权归原作者所有。本文所用视频、图片、文字如涉及作品版权问题,请联系小编进行处理(联系邮箱:cathy@eetrend.com)。

围观 20

如果CPU没有中断,你能想象是什么情况吗?

就是一个while循环,且不能中断处理及时的任务,更别说有现在的RTOS了(RTOS也是需要中断才能实现)。

下面就来说说关于Cortex-M中断在RTOS应用及注意事项。

关于Cortex-M处理器

这里先介绍一点Cortex-M处理器相关的内容,本文结合内核为Cortex-M3的STM32来讲述。

STM32属于ARM中Cortex-M系列处理器,比如:STM32F1数据Cortex-M3,STM32F7数据Cortex-M7。

1.jpg

可以参看我之前分享文章《从Cortex-M到Cortex-A认识ARM处理器》,了解一下关于ARM处理器的种类。

本文主要结合Cortex-M3下面STM32F1系列处理器为例来讲述中断控制相关内容。而Cortex-M其它系列,或者说STM32其它系列关于中断的内容类似。

Cortex-M3只是STM32F1的一个内核。反过来说STM32F1是在Cortex-M3基础上增加了一些外设(如:USART、AD等)的芯片。

Cortex-M中断控制

NVIC:Nested Vectored Interrupt Controller,即嵌套向量中断控制器。

STM32中NVIC我们比较熟悉,编程的时候使用中断都会对NVIC进行配置。

而STM32F1中的NVIC是属于Cortex-M3中的一部分,而不是STM32增加的外设。

NVIC向量中断控制器是Cortex‐M3不可分离的一部分,它与 CM3 内核的逻辑紧密耦合,有一部分甚至水乳交融在一起。

所以,NVIC相关的寄存器位于Cortex-M手册中。讲述STM32的中断控制,还得从Cortex-M3的NVIC讲起,

1.中断输入向量表

Cortex-M3的NVIC支持1至240个中断输入,比如STM32中xxxIRQs,也就是中断向量表,具体的数值由芯片厂商在设计芯片时决定。

比如STM32F1的中断和异常向量表:

2.jpg

3.jpg

2.中断和异常区别很多初学的朋友不知道什么是中断?什么是异常?甚至有人直接把中断和异常笼统称为“中断”。

中断和异常其实有差异,也有关联,我们常说的中断其实是包含了异常。异常可以理解为MCU,或者程序处于了某种异常状态。

这么区分吧,看上面向量表,上部分有灰色背景的为异常,下部分白色的为中断。

异常属于Cortex‐M3内核的一部分,而中断属于MCU(STM32)的一部分(由厂家决定)。

所以:1.站在Cortex‐M3内核角度,像STM32中USART这类中断,属于外部中断。

2.站在STM32角度,EXTI外部引脚中断才属于中断。

3.优先级对于Cortex-M3来说,每个外部中断都有一个对应的优先级寄存器。

每个寄存器占用8位,但是允许最少只使用最高3位,在STM32F1中使用了高4位。(也就是我们可以分16个优先级)

优先级可以被分为高低两个位段,分别是抢占优先级和亚(响应)优先级。

4.jpg

提示:

1.STM32中断优先级数值越小,优先级越大。

2.优先级分组:Cortex-M3,M4具有分组功能,即存在抢占优先级和响应优先级,如下图:

5.jpg

而有的内核就没有,如Cortex-M0就没有。

3.参考资料

可以参看《Cortex-M3权威指南》

STM32的内核编程手册:http://www.st.com/stonline/products/literature/pm/15491.pdf

RTOS中断优先级配置

本节内容讲述一下FreeRTOS最大中断优先级配置问题,也就是FreeRTOSConfig.h配置文件中的:

configMAX_SYSCALL_INTERRUPT_PRIORITY

6.jpg


你们知道配置数值的含义吗?这里就需要结合NVIC相关的内容来理解。

上面说了,在STM32中,使用了NVIC优先级的高4位,而我们配置时需要对高4位进行配置(低4位未使用)。

7.jpg

看上图,明白了吗,上面这个数值就是95,但代表的优先级为5。

这个配置数值的含义,大概意思是:你代码中使用的中断(比如USART1_IRQn)优先级需要大于5才可行。

如下面配置,优先级为2就不行(当然,有分组的还牵涉到分组问题)。

8.jpg

关于FreeRTOS最大优先级配置的内容可以参考:https://www.freertos.org/RTOS-Cortex-M3-M4.html

最后再次提示:FreeRTOS任务优先级是数值越大,优先级越高,需要和CM3中断优先级区分开来。

来源:strongerHuang

免责声明:本文为转载文章,转载此文目的在于传递更多信息,版权归原作者所有。本文所用视频、图片、文字如涉及作品版权问题,请联系小编进行处理(联系邮箱:cathy@eetrend.com)。

围观 22

手机、电脑多核的CPU你可能经常看见,但多核的单片机相对来说就不那么常见了。随着需求的增加、技术的进步,单片机已不再局限于单核了,因此,近几年陆续出现了双核的单片机了。

你可能会好奇,双核单片机之间怎么通信?其实,通信的方式和方法有很多种。本文就给大家描述一下:使用FreeRTOS消息缓冲区,实现简单的非对称多处理(AMP)核心到核心通信,结合STM32H7(M4和M7) 双核处理器为例。

概述

实现STM32H7双核之间通信是FreeRTOS官方提供的一个方案,是基于FreeRTOS消息缓冲区,该消息缓冲区是无锁循环缓冲区,可以将大小不同的数据包从单个发送方传递到单个接收方。

说明,该消息缓冲区仅提供数据的传输,不提供通信相关协议处理。

基本原理

实现双核之间通信基本原理:发送和接收任务位于非对称多处理器(AMP)配置中的多核微控制器(MCU)的不同内核上,这意味着每个内核都运行自己的FreeRTOS程序。

同时,一个内核在另一个内核中具有生成中断的能力,以及两个内核都有访问的内存区域(共享内存)。消息缓冲区以每个内核上运行在应用程序已知的地址置在共享内存中,如下图:

1.png

理想情况下,还将有一个内存保护单元(MPU),以确保只能通过内核的消息缓冲区API来访问消息缓冲区,并最好将共享内存标记为不可被其他程序占用。

单消息代码描述

这里官方提供了实现该方案的基础代码(仅供参考)。

将数据发送到流缓冲区的代码:

xMessageBufferSend()
{    
    /* If a time out is specified and there isn't enough    
    space in the message buffer to send the data, then    
    enter the blocked state to wait for more space. */    
    if( time out != 0 )    
    {        
        while( there is insufficient space in the buffer &&            
            not timed out waiting )        
        {            
            Enter the blocked state to wait for space in the buffer        
        }    
    }
    
    if( there is enough space in the buffer )    
    {        
       write data to buffer        
       sbSEND_COMPLETED()    
    }
}

从流缓冲区读取数据的代码:

xMessageBufferReceive()
{    
    /* If a time out is specified and the buffer doesn't    
    contain any data that can be read, then enter the    
    blocked state to wait for the buffer to contain data. */    
    if( time out != 0 )    
    {        
        while( there is no data in the buffer &&               
            not timed out waiting )        
        {            
            Enter the blocked state to wait for data        
        }    
    }
    
   if( there is data in the buffer )    
    {        
       read data from buffer        
       sbRECEIVE_COMPLETED()    
    }
}

如果任务在xMessageBufferReceive()中进入阻塞状态以等待缓冲区包含数据,则将数据发送到缓冲区必须取消阻塞该任务,以便它可以完成其操作。

当xMessageBufferSend()调用sbSEND_COMPLETED()时,任务将不受阻碍。

2.png

ISR通过将消息缓冲区的句柄作为参数传递给xMessageBufferSendCompletedFromISR()函数来解除对任务的阻塞。

如图箭头所示,其中发送和接收任务位于不同的MCU内核上:

1.接收任务尝试从空的消息缓冲区中读取数据,并进入阻止状态以等待数据到达。

2.发送任务将数据写入消息缓冲区。

3.sbSEND_COMPLETED()在正在执行接收任务的内核中触发一个中断。

4.中断服务例程调用xMessageBufferSendCompletedFromISR()来解除阻止接收任务,该任务现在可以从缓冲区读取,因为缓冲区不再为空。

多消息代码描述

当只有一个消息缓冲区时,很容易将消息缓冲区的句柄传递到xMessageBufferSendCompletedFromISR()中。

但是要考虑有两个或更多消息缓冲区的情况,ISR必须首先确定哪个消息缓冲区包含数据。如果消息缓冲区的数量很少,则有几种方法可以实现:

  • 如果硬件允许,则每个消息缓冲区可以使用不同的中断线,从而使中断服务程序和消息缓冲区之间保持一对一的映射。

  • 中断服务例程可以简单地查询每个消息缓冲区以查看其是否包含数据。

  • 可以通过传递元数据(消息是什么,消息的预期接收者是什么等等)以及实际数据的单个消息缓冲区来代替多个消息缓冲区。

但是,如果存在大量或未知的消息缓冲区,则这些技术效率不高。

在这种情况下,可伸缩的解决方案是引入单独的控制消息缓冲区。如下面的代码所示,sbSEND_COMPLETED()使用控制消息缓冲区将包含数据的消息缓冲区的句柄传递到中断服务例程中。
使用sbSEND_COMPLETED()的实现:

/* Added to FreeRTOSConfig.h to override the default implementation. */
#define sbSEND_COMPLETED( pxStreamBuffer ) vGenerateCoreToCoreInterrupt( pxStreamBuffer )
/* Implemented in a C file. */
void vGenerateCoreToCoreInterrupt( MessageBufferHandle_t xUpdatedBuffer )
{
  size_t BytesWritten.
  /* Called by the implementation of sbSEND_COMPLETED() in FreeRTOSConfig.h.    
  If this function was called because data was written to any message buffer    
  other than the control message buffer then write the handle of the message    
  buffer that contains data to the control message buffer, then raise an    
  interrupt in the other core.  If this function was called because data was    
  written to the control message buffer then do nothing. */    
  if( xUpdatedBuffer != xControlMessageBuffer )    
  {        
     BytesWritten = xMessageBufferSend(  xControlMessageBuffer,                                            
                         &xUpdatedBuffer,                                            
                         sizeof( xUpdatedBuffer ),                                            
                         0 );
     /* If the bytes could not be written then the control message buffer        
     is too small! */        
      configASSERT( BytesWritten == sizeof( xUpdatedBuffer );
      
     /* Generate interrupt in the other core (pseudocode). */        
     GenerateInterrupt();    
    }
}

然后,ISR读取控制消息缓冲区以获得句柄,将句柄作为参数传递到xMessageBufferSendCompletedFromISR()中:

void InterruptServiceRoutine( void )
{
  MessageBufferHandle_t xUpdatedMessageBuffer;
  BaseType_t xHigherPriorityTaskWoken = pdFALSE;
   
  /* Receive the handle of the message buffer that contains data from the    
  control message buffer.  Ensure to drain the buffer before returning. */    
  while( xMessageBufferReceiveFromISR( xControlMessageBuffer,                                         
                      &xUpdatedMessageBuffer,                                         
                      sizeof( xUpdatedMessageBuffer ),                                         
                      &xHigherPriorityTaskWoken )                                           
                      == sizeof( xUpdatedMessageBuffer ) )    
    {        
      /* Call the API function that sends a notification to any task that is        
      blocked on the xUpdatedMessageBuffer message buffer waiting for data to        
      arrive. */        
      xMessageBufferSendCompletedFromISR( xUpdatedMessageBuffer,                                            
                         &xHigherPriorityTaskWoken );    
    }
   
  /* Normal FreeRTOS "yield from interrupt" semantics, where    
  xHigherPriorityTaskWoken is initialised to pdFALSE and will then get set to    
  pdTRUE if the interrupt unblocks a task that has a priority above that of    
  the currently executing task. */    
  portYIELD_FROM_ISR( xHigherPriorityTaskWoken );
}

3.png

如图,使用控制消息缓冲区时的顺序:

1.接收任务尝试从空的消息缓冲区中读取数据,并进入阻止状态以等待数据到达。

2.发送任务将数据写入消息缓冲区。

3.sbSEND_COMPLETED()将现在包含数据的消息缓冲区的句柄发送到控制消息缓冲区。

4.sbSEND_COMPLETED()在正在执行接收任务的内核中触发一个中断。

5.中断服务例程从控制消息缓冲区中读取包含数据的消息缓冲区的句柄,然后将该句柄传递给xMessageBufferSendCompletedFromISR()API函数以取消阻止接收任务,该任务现在可以从缓冲区读取,因为缓冲区不再存在空的。

当然,以上仅提供基础原理和方法,具体实现需结合项目实际情况。更多相关内容,请参看官方相关资料。

来源:strongerHuang

免责声明:本文为转载文章,转载此文目的在于传递更多信息,版权归原作者所有。本文所用视频、图片、文字如涉及作品版权问题,请联系小编进行处理(联系邮箱:cathy@eetrend.com)。

围观 91

1、FreeRTOS

由于RTOS需占用一定的系统资源(尤其是RAM资源),只有μC/OS-II、embOS、salvo、FreeRTOS等少数实时操作系统能在小RAM单片机上运行。

相对于C/OS-II、 embOS等商业操作系统,FreeRTOS操作系统是完全免费的操作系统,具有源码公开、可移植、可裁减、调度策略灵活的特点,可以方便地移植到各种单片机上运行,其最新版本为6.0版。

作为一个轻量级的操作系统,FreeRTOS提供的功能包括:任务管理、时间管理、信号量、消息队列、内存管理、记录功能等,可基本满足较小系统的需要。

FreeRTOS内核支持优先级调度算法,每个任务可根据重要程度的不同被赋予一定的优先级,CPU总是让处于就绪态的、优先级最高的任务先运行。

FreeRT0S内核同时支持轮换调度算法,系统允许不同的任务使用相同的优先级,在没有更高优先级任务就绪的情况下,同一优先级的任务共享CPU的使用时间。

FreeRTOS的不足:相对于常见的μC/OS—II操作系统,FreeRTOS操作系统既有优点也存在不足。其不足之处, 一方面体现在系统的服务功能上,如FreeRTOS只提供了消息队列和信号量的实现,无法以后进先出的顺序向消息队列发送消息;另一方 面,FreeRTOS只是一个操作系统内核,需外扩第三方的GUI(图形用户界面)、TCP/IP协议栈、FS(文件系统)等才能实现一个较复杂的系统, 不像μC/OS-II可以和μC/GUI、μC/FS、μC/TCP-IP等无缝结合。

“STM32嵌入式开发中的RTOS,你用过哪些?"

在STM32CubeIDE中直接可以配置FreeRTOS,如上图。STM32使用FreeRTOS的相关文章,请移步此处:使用STM32CubeMx工具,写FreeRTOS的demo程序。

FreeRTOS资料多、生态活跃,在Cube中通过配置界面,三两下上手这款操作系统,推荐拿来入门。

基于不同的需求,下文再介绍下其他RTOS。

2、μClinux

μClinux是一种优秀的嵌入式Linux版本,其全称为micro-control Linux,从字面意思看是指微控制Linux。

同标准的Linux相比,μClinux的内核非常小,但是它仍然继承了Linux操作系统的主要特性,包括良好的稳定性和移植性、强大的网络功能、出色的文件系统支持、标准丰富的API,以及TCP/IP网络协议等。因为没有MMU内存管理单元,所以其多任务的实现需要一定技巧。

μClinux在结构上继承了标准Linux的多任务实现方式,分为实时进程和普通进程,分别采用先来先服务和时间片轮转调度,仅针对中低档嵌入式CPU特点进行改良,且不支持内核抢占,实时性一般。

综上可知,μClinux最大特点在于针对无MMU处理器设计,这对于没有MMU功能的STM32F103来说是合适的,但移植此系统需要至少512KB的RAM空间,1MB的ROM/FLASH空间,而STM32F103拥有256K的FLASH,需要外接存储器,这就增加了硬件设计的成本。

μClinux结构复杂,移植相对困难,内核也较大,其实时性也差一些,若开发的嵌入式产品注重文件系统和与网络应用则μClinux是一个不错的选择。

“STM32嵌入式开发中的RTOS,你用过哪些?"

3、μC/OS-II

μC/OS-II是在μC/OS的基础上发展起来的,是用C语言编写的一个结构小巧、抢占式的多任务实时内核。μC/OS-II能管理64个任务,并提供任务调度与管理、内存管理、任务间同步与通信、时间管理和中断服务等功能,具有执行效率高、占用空间小、实时性能优良和扩展性强等特点。

在文件系统的支持方面,由于μC/OS-II是面向中小型嵌入式系统的,即使包含全部功能,编译后内核也不到10 KB,所以系统本身并没有提供对文件系统的支持。但是μC/OS-II具有良好的扩展性能,如果需要也可自行加入文件系统的内容。

在对硬件的支持上,μC/OS-II能够支持当前流行的大部分CPU,μC/OS-II由于本身内核就很小,经过裁剪后的代码最小可以为2KB,所需的最小数据RAM空间为4 KB,μC/OS-II的移植相对比较简单,只需要修改与处理器相关的代码就可以。

综上可知,μC/OS-II是一个结构简单、功能完备和实时性很强的嵌入式操作系统内核,针对于没有MMU功能的CPU,它是非常合适的。它需要很少的内核代码空间和数据存储空间,拥有良好的实时性,良好的可扩展性能,并且是开源的,网上拥有很多的资料和实例,所以很适合向STM32F103这款CPU上移植。

“STM32嵌入式开发中的RTOS,你用过哪些?"

4、eCos

eCos(embedded Configurable operating system),即嵌入式可配置操作系统。它是一个源代码开放的可配置、可移植、面向深度嵌入式应用的实时操作系统。

最大特点是配置灵活,采用模块化设计,核心部分由小同的组件构成,包括内核、C语言库和底层运行包等。

每个组件可提供大量的配置选项(实时内核也可作为可选配置),使用eCos提供的配置工具可以很方便地配置,并通过不同的配置使得eCos能够满足不同的嵌入式应用要求。

eCos操作系统的可配置性非常强大,用户可以自己加入所需的文件系统。eCos操作系统同样支持当前流行的大部分嵌入式CPU,eCos操作系统可以在16位、32位和64位等不同体系结构之间移植。

“STM32嵌入式开发中的RTOS,你用过哪些?"

eCos由于本身内核就很小,经过裁剪后的代码最小可以为10 KB,所需的最小数据RAM空间为10 KB。

在系统移植方面 eCos操作系统的可移植性很好,要比μC/OS-II和μClinux容易。

综上所述,eCos最大特点是配置灵活,并且支持无MMU的CPU的移植,开源且具有很好的移植性,也比较合适于移植到STM32平台的CPU上。但eCOS的应用还不是太广泛,还没有像μC/OS-II那样普遍,并且资料也没有μC/OS-II多。eCos适合用于一些商业级或工业级对成本敏感的嵌入式系统,例如消费电子领域中的一些应用。

5、mbed OS

开源嵌入式操作系统,ARM公司将mbed OS免费提供给所有厂商使用,mbed提供了一个相对更加系统和更加全面的智能硬件开发环境。

主要功能:

提供用于开发物联网设备的通用操作系统基础,以解决嵌入式设计的碎片化问题。支持所有重要的连接性与设备管理开放标准,以实现面向未来的设计。使安全可升级的边缘设备支持新增处理能力与功能。通过自动电源管理解决复杂的能耗问题。

主要特点:

开发速度快,功能强大,安全性高,为了量产化而设计,可离线开发,也可以在网页上编辑。

“STM32嵌入式开发中的RTOS,你用过哪些?"

6、RTX

是ARM公司的一款嵌入式实时操作系统,使用标准的C结构编写,运用RealView编译器进行编译。不仅仅是一个实时内核,还具备丰富的中间层组件,不但免费,而且代码也是开放的。

主要功能:

开始和停止任务(进程),除此之外还支持进程通信,例如任务的同步、共享资源(外设或内存)的管理、任务之间消息的传递。开发者可以使用基本函数去开启实时运行器,去开始和终结任务,以及去传递任务间的控制(轮转调度)。开发者可以赋予任务优先级。

主要特点:

支持时间片,抢占式和合作式调度。不限制数量的任务,每个任务都具有254的优先级。不限制数量的信号量,互斥信号量,消息邮箱和软定时器。支持多线程和线程安全操作。使用MDK基于对话框的配置向导,可以很方便的完成MDK的配置。

7、都江堰

都江堰操作系统,简称djyos,得名于一个伟大的水利工程:都江堰。

与传统操作系统不同,djyos不是以线程而是以事件为调度核心,这种调度算法使程序员摆脱模拟计算机执行过程编写程序的思维方式,而是按人类认知世界的方式编写应用程序,就如同在嵌入式编程中引入了VC似的。

djyos的调度算法使程序员可以摆脱线程和进程的束缚,djyos没有有关线程的api,一个完全不懂线程知识的程序员也可以顺利地在djyos下编写应用程序。

djyos 操作系统是以事件为核心进行调度的,这种调度策略使程序员可以按人类认知事物的习惯而不是计算机的习惯来编程。

“STM32嵌入式开发中的RTOS,你用过哪些?"

8、RT-Thread

嵌入式操作系统RTOS介绍,RT-Thread是一个集实时操作系统(RTOS)内核、中间件组件和开发者社区于一体的技术平台,由熊谱翔先生带领并集合开源社区力量开发而成,RT-Thread也是一个组件完整丰富、高度可伸缩、简易开发、超低功耗、高安全性的物联网操作系统。

RT-Thread具备一个IoT OS平台所需的所有关键组件,例如GUI、网络协议栈、安全传输、低功耗组件等等。经过11年的累积发展,RT-Thread已经拥有一个国内最大的嵌入式开源社区,同时被广泛应用于能源、车载、医疗、消费电子等多个行业,累积装机量超过两千万台,成为国人自主开发、国内最成熟稳定和装机量最大的开源RTOS。

国内最有可能成为Top 1,优势在于丰富的组件,中立立场!赶上了时机,得到诸多芯片厂商的支持,也挺受开发者喜欢的。缺点在于本身的教程文档和freertos等之类的比还是很弱。

来源:http://www.sylixos.com/

直接来源:STM32嵌入式开发
免责声明:本文为转载文章,转载此文目的在于传递更多信息,版权归原作者所有。本文所用视频、图片、文字如涉及作品版权问题,请联系小编进行处理(联系邮箱:cathy@eetrend.com)。

围观 791

概述

嵌入式物联网开发平台是一个系统,是微控制器+物+联+网+开发平台的系统组合。

“MCU,RTOS,物联网之间的关系"
  • 微控制器:是嵌入式控制的核心
  • 物:智能化的电子产品
  • 联:电子产品通讯或对话的通道
  • 网:互联网、移动互联网
  • 开发平台:产品、技术和开发工具的组合

随着微控制器的工艺和技术的发展,成本越来越低,更多的产品用上了微控制器,使得“物(电子产品)”越来越智能化,并在ICT(信息通讯技术)的推动下,电子智能化的“物(电子产品)”越来越多地连接到网络上,物连网络的发展让人与“物”的联系越来越紧密了。

微控制器(MCU)

MCU(Microcontroller,即微控制器)根据数据处理能力不同,分为4位、8位、16位、32位微控制器,如下图:

“MCU,RTOS,物联网之间的关系"

目前,在物联网产品应用中,一般对MCU的需求是:

“MCU,RTOS,物联网之间的关系"

面对物联网市场的需求,众多的MCU厂家都在计划着推出新产品。如在一些小家电和家电市场、一些MCU厂商配合用户做一些定制化的产品;有的51厂商开始考虑集成蓝牙功能的产品;ARM公司收购了两家美国公司Wicentric和Sunrise,将以Cordio品牌推出低功耗蓝牙产品。

实时操作系统(RTOS)

微控制器性能的提升让一些实时操作系统RTOS有了“容身之地”,在32位 的ARM Cortex-M系列产品中,越来越多的产品用上了RTOS。

也为一些中间件/协议栈或一些高级的应用提供了一个平台基础。产品的系统化设计成为了可能,为物联网大规模开发部署提供了发展机会。

操作系统好多是开源的。开源机制使更多的人参与其中,发现问题改正问题,使平台能在众人的推动下不断优化发展。也能使一些优秀的组件或中间件/协议栈开源出来与更多的人分享设计。

常见的一些实时操作系统(RTOS)有如下:

“MCU,RTOS,物联网之间的关系"

常见的一些协议栈有如下:

“MCU,RTOS,物联网之间的关系"

常用的一些中间件:

“MCU,RTOS,物联网之间的关系"

开发平台选择

开发平台不是一个产品,是系统的组合。如何在做或计划一个项目时选择一个合适的开发平台,需要多方面综合考虑。

1.微控制器

做一个“跟随者”,参考同行中的产品选型。不做“第一个吃螃蟹”的,这样可以避免走一些不必要的弯路,不会有产品开发风险。但新机会往往会都是会眷顾那些“敢为天下先”的人。新的产品层出不穷,也为开发者提供了更多的选择空间。

对于遥控、小家电/家电、智能卡、玩具等市场应用而言,4位/8位/16位仍然有很大的选择空间。毕竟一些应用的数据处理要求并不高,在原有产品基础上开发,开发成本低。

新的产品总是会在一些新的项目上开始,近些年流行的ARM Cortex-M是比较理想的选择。毕竟ARM Cortex-M是32位机市场的主流,厂家多、应用广、资源多。

2.嵌入式实时操作系统(RTOS)

32位MCU的流行,开发者越来越爱使用RTOS了。有的甚至在8位MCU上跑RTOS。

RTOS提供了开发的便捷性,但在资源紧张的8位微控制器上运行还是有一些局限性的。建议还是在资源丰富的产品上运行RTOS。

选择活跃度比较高的开源的RTOS会得到后续更好的升级维护,学习成本低,社区众多人的支持和参与会使得RTOS不断改进不断完善。

国内的RTOS操作系统近几年也多了起来,如:RT-Thread、 MiCo、DJYOS、μTenux等等。开发者可以根据项目需求选择适合的RTOS。

开源的推动下,RTOS的发展会衍生出一些新的商务模式出来,如下图:

“MCU,RTOS,物联网之间的关系"

在使用RTOS带来方便的同时,也需要注意一些问题:

  • RTOS稳定性
  • RTOS安全性
  • RTOS授权方式/版权
  • 中间件或协议栈的支持

4.网络

物联网就是将电子设备连接到网络,基于网络来控制或使用一些服务。目前,连接到网络的方式有:有线连接和无线连接。近些年来,无线技术的发展非常迅速。

“MCU,RTOS,物联网之间的关系"

5.产品原型设计

从目前业内来看,mbed.org提供了比较齐全的功能设计,无论从底层、RTOS、中间件或协议栈、组件、服务器端等应用都提供了比较全的选择。这为开发者或者有意于物联网开发者来说,是一个不错的参考。

6.物联网的发展

物联网的发展的特点是:智能化、网络化、信息化。

“MCU,RTOS,物联网之间的关系"

来源: 小麦大叔
免责声明:本文为转载文章,转载此文目的在于传递更多信息,版权归原作者所有。本文所用视频、图片、文字如涉及作品版权问题,请联系小编进行处理(联系邮箱:cathy@eetrend.com)。

围观 176

满足实时控制要求的嵌入式操作系统(RTOS)

以下介绍14种主流的RTOS,分别为μClinux、μC/OS-II、eCos、FreeRTOS、mbed OS、RTX、Vxworks、QNX、NuttX,而国产的嵌入式操作系统包括都江堰操作系统(djyos)、Alios Things、Huawei LiteOS、RT-Thread、SylixOS。

下面分别介绍这14种嵌入式操作系统的特点。

1、μClinux

μClinux是一种优秀的嵌入式Linux版本,其全称为micro-control Linux,从字面意思看是指微控制Linux。同标准的Linux相比,μClinux的内核非常小,但是它仍然继承了Linux操作系统的主要特性,包括良好的稳定性和移植性、强大的网络功能、出色的文件系统支持、标准丰富的API,以及TCP/IP网络协议等。因为没有MMU内存管理单元,所以其多任务的实现需要一定技巧。

μClinux在结构上继承了标准Linux的多任务实现方式,分为实时进程和普通进程,分别采用先来先服务和时间片轮转调度,仅针对中低档嵌入式CPU特点进行改良,且不支持内核抢占,实时性一般。

综上可知,μClinux最大特点在于针对无MMU处理器设计,这对于没有MMU功能的stm32f103来说是合适的,但移植此系统需要至少512KB的RAM空间,1MB的ROM/FLASH空间,而stmf103拥有256K的FLASH,需要外接存储器,这就增加了硬件设计的成本。

μClinux结构复杂,移植相对困难,内核也较大,其实时性也差一些,若开发的嵌入式产品注重文件系统和与网络应用则μClinux是一个不错的选择。

“14种主流RTOS,你认识几种?”

2、μC/OS-II

μC/OS-II是在μC/OS的基础上发展起来的,是用C语言编写的一个结构小巧、抢占式的多任务实时内核。μC/OS-II能管理64个任务,并提供任务调度与管理、内存管理、任务间同步与通信、时间管理和中断服务等功能,具有执行效率高、占用空间小、实时性能优良和扩展性强等特点。

在文件系统的支持方面,由于μC/OS-II是面向中小型嵌入式系统的,即使包含全部功能,编译后内核也不到10 KB,所以系统本身并没有提供对文件系统的支持。但是μC/OS-II具有良好的扩展性能,如果需要也可自行加入文件系统的内容。

在对硬件的支持上,μC/OS-II能够支持当前流行的大部分CPU,μC/OS-II由于本身内核就很小,经过裁剪后的代码最小可以为2KB,所需的最小数据RAM空间为4 KB,μC/OS-II的移植相对比较简单,只需要修改与处理器相关的代码就可以。

综上可知,μC/OS-II是一个结构简单、功能完备和实时性很强的嵌入式操作系统内核,针对于没有MMU功能的CPU,它是非常合适的。它需要很少的内核代码空间和数据存储空间,拥有良好的实时性,良好的可扩展性能,并且是开源的,网上拥有很多的资料和实例,所以很适合向stm32f103这款CPU上移植。

“14种主流RTOS,你认识几种?”

3、eCos

“14种主流RTOS,你认识几种?”

eCos(embedded Configurable operating system),即嵌入式可配置操作系统。

它是一个源代码开放的可配置、可移植、面向深度嵌入式应用的实时操作系统。

最大特点是配置灵活,采用模块化设计,核心部分由小同的组件构成,包括内核、C语言库和底层运行包等。

每个组件可提供大量的配置选项(实时内核也可作为可选配置),使用eCos提供的配置工具可以很方便地配置,并通过不同的配置使得eCos能够满足不同的嵌入式应用要求。

eCos操作系统的可配置性非常强大,用户可以自己加入所需的文件系统。eCos操作系统同样支持当前流行的大部分嵌入式CPU,eCos操作系统可以在16位、32位和64位等不同体系结构之间移植。

eCos由于本身内核就很小,经过裁剪后的代码最小可以为10 KB,所需的最小数据RAM空间为10 KB。

在系统移植方面 eCos操作系统的可移植性很好,要比μC/OS-II和μClinux容易。

综上所述,eCos最大特点是配置灵活,并且支持无MMU的CPU的移植,开源且具有很好的移植性,也比较合适于移植到stm32平台的CPU上。但eCOS的应用还不是太广泛,还没有像μC/OS-II那样普遍,并且资料也没有μC/OS-II多。eCos适合用于一些商业级或工业级对成本敏感的嵌入式系统,例如消费电子领域中的一些应用。

4、FreeRTOS

“14种主流RTOS,你认识几种?”

由于RTOS需占用一定的系统资源(尤其是RAM资源),只有μC/OS-II、embOS、salvo、FreeRTOS等少数实时操作系统能在小RAM单片机上运行。

相对于C/OS-II、 embOS等商业操作系统,FreeRTOS操作系统是完全免费的操作系统,具有源码公开、可移植、可裁减、调度策略灵活的特点,可以方便地移植到各种单片机上运行,其最新版本为6.0版。

作为一个轻量级的操作系统,FreeRTOS提供的功能包括:任务管理、时间管理、信号量、消息队列、内存管理、记录功能等,可基本满足较小系统的需要。

FreeRTOS内核支持优先级调度算法,每个任务可根据重要程度的不同被赋予一定的优先级,CPU总是让处于就绪态的、优先级最高的任务先运行。

FreeRT0S内核同时支持轮换调度算法,系统允许不同的任务使用相同的优先级,在没有更高优先级任务就绪的情况下,同一优先级的任务共享CPU的使用时间。

FreeRTOS的不足:

相对于常见的μC/OS—II操作系统,FreeRTOS操作系统既有优点也存在不足。

其不足之处, 一方面体现在系统的服务功能上,如FreeRTOS只提供了消息队列和信号量的实现,无法以后进先出的顺序向消息队列发送消息;另一方 面,FreeRTOS只是一个操作系统内核,需外扩第三方的GUI(图形用户界面)、TCP/IP协议栈、FS(文件系统)等才能实现一个较复杂的系统, 不像μC/OS-II可以和μC/GUI、μC/FS、μC/TCP-IP等无缝结合。

5、mbed OS

开源嵌入式操作系统,ARM公司将mbed OS免费提供给所有厂商使用,mbed提供了一个相对更加系统和更加全面的智能硬件开发环境。

主要功能:

提供用于开发物联网设备的通用操作系统基础,以解决嵌入式设计的碎片化问题。支持所有重要的连接性与设备管理开放标准,以实现面向未来的设计。使安全可升级的边缘设备支持新增处理能力与功能。通过自动电源管理解决复杂的能耗问题。

主要特点:

开发速度快,功能强大,安全性高,为了量产化而设计,可离线开发,也可以在网页上编辑。

“14种主流RTOS,你认识几种?”

6、RTX

是ARM公司的一款嵌入式实时操作系统,使用标准的C结构编写,运用RealView编译器进行编译。不仅仅是一个实时内核,还具备丰富的中间层组件,不但免费,而且代码也是开放的。

主要功能:

开始和停止任务(进程),除此之外还支持进程通信,例如任务的同步、共享资源(外设或内存)的管理、任务之间消息的传递。开发者可以使用基本函数去开启实时运行器,去开始和终结任务,以及去传递任务间的控制(轮转调度)。开发者可以赋予任务优先级。

主要特点:

支持时间片,抢占式和合作式调度。不限制数量的任务,每个任务都具有254的优先级。不限制数量的信号量,互斥信号量,消息邮箱和软定时器。支持多线程和线程安全操作。使用MDK基于对话框的配置向导,可以很方便的完成MDK的配置。

7、VxWorks

“”

美国WindRiver公司于1983年设计开发的一种嵌入式实时操作系(RTOS),具有硬实时、确定性与稳定性,也具备航空与国防、工业、医疗、汽车、消费电子产品、网络及其他行业要求的可伸缩性与安全性。

主要功能:

支持可预测的任务同步机制、支持多任务间的通信、存储器优化管理、操作系统的(中断延迟、任务切换、驱动程序延迟等)行为是可知的和可预测的。实时时钟服务+中断管理服务。

主要特点:

具有一个高性能的操作系统内核Wind(实时性好、可裁减)友好的开发调试环境、较好的兼容性、支持多种开发和运行环境

8、QNX

诞生于1980年,是一种商用的遵从POSIX规范的类Unix嵌入式实时操作系统。
主要功能:

支持在同一台计算机上同时调度执行多个任务;也可以让多个用户共享一台计算机,这些用户可以通过多个终端向系统提交任务,与QNX进行交互操作。
主要特点:

核心仅提供4种服务:进程调度、进程间通信、底层网络通信和中断处理,其进程在独立的地址空间运行。所有其它OS服务,都实现为协作的用户进程,因此QNX核心非常小巧(QNX4.x大约为12Kb)而且运行速度极快。

“14种主流RTOS,你认识几种?”

9、NuttX

NuttX是一个实时嵌入式操作系统(Embedded RTOS),第一个版本由 Gregory Nutt 于 2007 年在宽松的 BSD 许可证下发布。

主要功能:

可以构建为开放的、平面的嵌入式 RTOS,或单独构建为具有系统调用接口的微内核。容易扩展到新的处理器架构、 SoC 架构或板级架构。实时的、确定性的、支持优先级继承。BSD 套接字接口。优先级管理的扩展。可选的具有地址环境的任务(进程)。

主要特点:

配置灵活,采用模块化设计,核心部分由小同的组件构成,包括内核、C语言库和底层运行包等。每个组件可提供大量的配置选项(实时内核也可作为可选配置),使用eCos提供的配置工具可以很方便地配置,并通过不同的配置使得eCos能够满足不同的嵌入式应用要求。

10、都江堰操作系统(djyos)

(注意:网友提示都江堰操作系统官网提示,stm32的f4和f7没调通)

都江堰操作系统,简称djyos,得名于一个伟大的水利工程:都江堰。

与传统操作系统不同,djyos不是以线程而是以事件为调度核心,这种调度算法使程序员摆脱模拟计算机执行过程编写程序的思维方式,而是按人类认知世界的方式编写应用程序,就如同在嵌入式编程中引入了VC似的。

djyos的调度算法使程序员可以摆脱线程和进程的束缚,djyos没有有关线程的api,一个完全不懂线程知识的程序员也可以顺利地在djyos下编写应用程序。

djyos 操作系统是以事件为核心进行调度的,这种调度策略使程序员可以按人类认知事物的习惯而不是计算机的习惯来编程。

“14种主流RTOS,你认识几种?"

11、Alios Things

据著名媒体嵌入式操作系统RTOS介绍,AliOS Things 是 AliOS 家族旗下、面向 IoT 领域的、高可伸缩的物联网操作系统。AliOS Things将致力于搭建云端一体化IoT基础设施,具备极致性能、极简开发、云端一体、丰富组件、安全防护等关键能力,并支持终端设备连接到阿里云Link,可广泛应用在智能家居、智慧城市、新出行等领域。

点评:阿里系,背靠阿里资源来势汹汹杀入物联网市场,芯片+模组厂商合作,是非常有力的一个玩家,但这也是其最大的劣势!

“14种主流RTOS,你认识几种?"

12、Huawei LiteOS

嵌入式操作系统RTOS介绍,Huawei LiteOS 是华为面向IoT领域,构建的轻量级物联网操作系统,以轻量级低功耗、快速启动、互联互通、安全等关键能力,为开发者提供 “一站式” 完整软件平台,有效降低开发门槛、缩短开发周期。

点评:华为系,不过其开源程度比较低,其主要用于华为自己的产品,有大树罩着。

“14种主流RTOS,你认识几种?"

13、RT-Thread

嵌入式操作系统RTOS介绍,RT-Thread是一个集实时操作系统(RTOS)内核、中间件组件和开发者社区于一体的技术平台,由熊谱翔先生带领并集合开源社区力量开发而成,RT-Thread也是一个组件完整丰富、高度可伸缩、简易开发、超低功耗、高安全性的物联网操作系统。RT-Thread具备一个IoT OS平台所需的所有关键组件,例如GUI、网络协议栈、安全传输、低功耗组件等等。经过11年的累积发展,RT-Thread已经拥有一个国内最大的嵌入式开源社区,同时被广泛应用于能源、车载、医疗、消费电子等多个行业,累积装机量超过两千万台,成为国人自主开发、国内最成熟稳定和装机量最大的开源RTOS。

点评:国内最有可能成为Top 1,优势在于丰富的组件,中立立场!赶上了时机,得到诸多芯片厂商的支持,也挺受开发者喜欢的。缺点在于本身的教程文档和freertos等之类的比还是很弱。

嵌入式操作系统RTOS推荐的学习资源:

① 文档:
https://www.rt-thread.org/document/site/

② 书籍:
《 嵌入式实时操作系统:RT-Thread设计与实现 》
《 RT-Thread内核实现与应用开发实战指南 基于STM32 》

“14种主流RTOS,你认识几种?"

14、SylixOS

嵌入式操作系统RTOS介绍,SylixOS 是一个开源的跨平台的大型实时操作系统(RTOS),SylixOS诞生于2006年,经过十多年的持续开发,SylixOS 已成为功能最为全面的国产操作系统之一。目前已有众多产品和项目应用案例,行业涉及航空航天、军事防务、轨道交通、智能电网、工业自动化等诸多领域。SylixOS 完全符合 POSIX 规范,开源社区丰富的自由软件移植非常方便。

点评:这家也是挺有意思的,2006年就开始了,吃军工饭,最近一两年才露头角。其实力不容小觑!

参考网站:http://www.sylixos.com/

当然,RTOS并不仅上面这些,欢迎补充

直接来源:最后一个bug
转载此文目的在于传递更多信息,版权归原作者所有。
素材来源:嵌入式ARM
【1】嵌入式操作系统RTOS . 《国产嵌入式操作系统行不行就看这5家了!》
【2】国讯芯微 . 《盘点那些实时高效的物联网操作系统》
【3】百度百科

围观 568

一、区别

两则的分流造成的主要原因是数字信号处理的简便性,考虑一个数字信号处理的实例,比如有限冲击响应滤波器(FIR)。用数学语言来说,FIR滤波器是做一系列的点积。取一个输入量和一个序数向量,在系数和输入样本的滑动窗口间作乘法,然后将所有的乘积加起来,形成一个输出样本。

类似的运算在数字信号处理过程中大量的重复发生,使得为此设计的器件必须提供专门的支持,促进了DSP器件与通用处理器(GPP)的分流:

1. 对密集乘法的支持


2. 存储器结构


此外,DSP处理器几乎都不具备数据的高速缓存。这是因为DSP的典型数据是数据流。也就是说,DSP处理器对每个数据样本做计算后,就丢弃,几乎不再重复使用。

3. 零开销循环

DSP算法的一个共同的特点,即大多数处理时间都花在执行较小的循环上,也就容易理解,为什么大多数的DSP都有专门的硬件,用于零开销循环。所谓的零开销循环是指处理器在执行循环时,不用花时间去检查循环计数器的值,条件转移到循环大额顶部,将循环计数器减1.

与此相反,GPP的循环使用软件来实现。某些高性能的GPP使用转移预报硬件,几乎达到与硬件支持零开销循环同样地效果。

二、联系

按照传统方式,嵌入式应用中的数字信号处理器(dsp)相对于主微控制器起到从属的作用。在这些应用中,MCU用作系统控制器,而大量的数据处理留给DSP。例如,在音频或视频处理器应用中有可能需要人机界面管理,或则是整个系统的控制。

为完成这些任务,有几种系统设计方案选择。

第一种方案是将DSP和MCU芯片组合在印制电路板上。这种方案成本高并且占用面积大,但是可适当地调整每个芯片的尺寸以最大限度的满足系统需要。

第二种方案是将DSP功能合并到一个MCU中。这种方案只适合于直接的信号处理应用。MCU的时钟频率和计算体系结构根本上不太适合大量的数字处理。有些MCU试图通过增加一个乘法和累加器(MAC)(dsp的一个特点)来补偿上述不足。但是这种方案任然缺乏高级应用所需要的基本的“由上至下”的体系结构设计。

第三种方案是一种将dsp和mcu组合在单个封装内的多芯片模块(mcm).这种方案的局限性是,设计工程师必须按“50/50”的时间比例分配给控制和DSP功能;例如,一旦DSP超出时间,MCU不能完成计算任务。像第一种方案选择一样,当DSP和MCU内核独立存在的时候,需要两套开发工具。

已经出现第四种方案它是将MCU的功能合并到一个DSP中。这类方案的一个例子是美国模拟器件公司(Anolog Device Inc.,简称ADI)的Blackfin 处理器系列。这些新型处理器具有统一的经过优化的体系结构,不仅适于数据计算,而且也适于有关的控制任务。通过平衡执行控制任务与复杂计算的要求,这种方案可以根据系统实时处理的需要,完成100%的控制或者100%的计算任务。完成所有这一切任务不需要在DSP模式和MCU模式之间的模式转换。

DSP & MCU

首先让我们回顾一下DSP和MCU的典型功能。DSP主要是在一单个时钟周期内尽可能完成多个MAC(乘法和累加)操作。为了这一点,指令的操作代码通常是可变的超长的指令字(VLIW)。DSP也适于工作在紧密、高效的环路中。另外,为了达到性能指标通常需要编写优化的汇编代码。由于DSP的算法程序一般装在小容量、短等待时间的内置存储器中,所以代码密度通常不是大问题。像DSP主要用于完成计算一样,MCU主要用于完成控制功能。同样地,典型的MCU应用包括许多条件操作,在程序流程中频繁地跳转。通常使用C或者C++语言编写程序。代码密度极为重要,并且根据编译代码的长度来评估算法。存储器系统是基于高速缓存从而允许该系统设计工程师用较长等待时间从较大的存储器中调用较大程序。利用基于高速缓存系统,程序员不需要考虑如何以及何时将指令输入到内核去执行。

统一的DSP和MCU兼备两者的优点。它的指令集由16 bit,32 bit和64 bit操作码组成,但是由于最常用的指令采用16 bit编码,所以编译代码密度大小与那些流行的MCU相同。另外,它包括一个存储器保护功能以及指令高速缓存和数据高速缓存,作为整个存储器管理单元(MMU)的一部分。此外,容易提供一套完整的C/C++开发工具,提供可选汇编语言或者全部汇编语言适合算法优化的编程。

RTOS

系统控制的一个重要方面是任务管理。实时操作系统(RTOS)逐渐地用于控制复杂系统中多种正在进行的和同时发生的任务。通过提供对任务调度与管理的支持,RTOS简化了编程模式,这通常是由MCU控制的,由于普通的DSP不具备支持RTOS需要的所有功能以便有效地控制。

然而,统一的DSP和MCU促进了RTOS几个重要功能的发展。第一个是限制访问功能以保护或者保留存储单元。第二个是配备单独的堆栈和帧指针以减少操作系统(OS)请求以及中断和异常处理所需的等待时间。第三个是具备单独的用户操作模式和管理员操作模式。过去,DSP按照等效于管理员操作模式工作,从而允许在任何时间完全访问所有的系统资源。然而MCU提供类似的在用户操作模式,它允许在OS的顶层运行应用软件。现在,在一个统一的体系结构下提供两种操作模式,因为增强的DSP系统能够限制用户应用软件仅通过OS访问系统资源。

MCU的一个优点是包含使用灵活和种类齐全的外围设备。作为通用的嵌入式控制器,它们通常具备可编程输入输出(I/O)标志、定时器、串行接口和日益增加越来越复杂的标准接口。MCU外围设备的主要作用是嵌入式控制,而不是大量计算。例如,一个实时时钟信号可以唤醒一只温度传感器用以采集环境温度并且将一个延迟的信息通过I/O引脚反馈到MCU。然后,一个定时器的脉冲宽度调制(PWM)输出相应地能够增加或者减小风扇电机的转速。像MCU一样,统一的DSP和MCU具备一套系统控制外围设备(例如,实时时钟、多功能定时器、监视定时器、双向标志位引脚)。然而,它还包括一些高速接口(例如,PCI、异步或者同步存储器控制器、USB、并行视频接口)以便通过这些接口,与许多DMA通道配合快速搬移数据,从而有助于有效利用高速DSP内核的信号处理能力。

功耗控制一直是嵌入式控制器的一项功能。但是,当系统要求DSP具有优良的性能时,对其电源的选择就不太理想。如果将独立的MCU和DSP芯片应用于电源敏感的场合,通常必须为每个芯片提供一个单独的开关稳压器,因为这两个器件的内核电压经常不一致。这会导致降低电源变换效率和增加设计器件的引脚数目,最终增加布线的复杂程度和解决方案的成本。此外,当MCU和DSP的内核集成到一个芯片上时,电源解决方案本质上不是最佳的,因为它必须满足2个完全独立并具有不同负载特性处理器的需求。将这种情况与统一的DSP和MCU相比较,它包含一个集成动态电源管理(DPM)控制器。由于它是只有一个处理器的体系结构,所以该控制器能够完全适合给定应用的需求。它提供几种固有的电源模式以支持多种系统性能等级。另外,对于未使用的时钟和L2存储器可选择性地禁止。该PLL的频率可在一个宽范围(通常1倍~31倍)进行调节,以满足在DSP和MCU内部多层次的处理需求。最后能够调节电压(外部或者通过一个集成的开关控制器)以提供指数式的节省功耗。由于系统成本、开发容易、器件采购和升级能力的原因,设计工程师正趋向采用一种单芯片解决方案用于嵌入式信号处理解决方案。这种单芯片解决方案必须能够同样好地完成DSP和MCU的功能,所以有必要提出一种统一的处理器体系结构。面对MCU的挑战,比较简单的解决方案是将MCU的功能合并到一个高性能的DSP内核,而不是与此相反。当今一个统一的DSP和MCU平台(由BlackfinDSP系列产品说明)已经投放市场,它将在MCU和DSP目前应用领域提供许多应用。

本文转自网络,版权归原作者,如果您觉得不好,请联系我们删除!

围观 363

对于搞单片机的特别用8051系列工程师来说,谈到单片机的RTOS,很多时候会问一句:“为什么要用RTOS?单片机就这一点资源,使用RTOS能保证效率吗?”

对于这个问题,我会反问:“你用单片机的目的是什么?是为了用单片机的C编程,单片机的汇编编程甚至于用单片机的二进制指令编程?”上个世纪80年代,工程师用二进制指令给Z80编程,现在还有谁在用?现在还有人死抱着汇编不放,但越来越多的人工程师使用C编程(我起初也是使用汇编的),为什么?因为我们的目的是在有限的时间甚至是不充足的时间内把项目保质保量的完成!使用什么工具和方法是次要的(如果你的项目以成本放在第一位,则另当别论,这时,也是要考虑开发时间的)。时间就是金钱啊,一个产品在单片机上增加些许成本是可以接受的。况且,使用8051系列单片机时,单片机资源也常有富余,CPU一般情况也只是空转,这就为它使用RTOS创造了条件。

那么,使用RTOS的好处呢?我举一个例子吧。假设我们编一个串行通讯程序,通讯协议如下:

数据包长度为NBYTE,起始字节为STARTBYTE1,STARTBYTE2,最后一个字节为检验和,中间字节不可能出现连续出现STARTBYTE1,STARTBYTE2。

第一种方法,在中断中处理协议:

unsigned char Buf[NBYTE-2];bit GetRight=0;
void comm(void) interrupt 4//"串行口中断"{
static unsigned char Sum,Flag=0,i;
unsigned char temp;
if(RI==1)
{
RI=0;
temp=SBUF;
switch(Flag)
{
case 0:
if(temp==STARTBYTE1)
{
Flag=1;
}
break;
case 1:
if(temp==STARTBYTE2)
{
Sum=STARTBYTE1+STARTBYTE2;
i=0;
Flag=2;
break;
}
if(temp==STARTBYTE1) break;
Flag=0;
break;
case 2:
if(temp==STARTBYTE1)
{
Flag=3;
break;
}
Sum+=temp;
if((i>=(NBYTE-3))&&Sum==0)
{
GetRight=1;
Flag=0;
break;
}
Buf[i++]=temp;
break;
case 3:
if(temp==STARTBYTE2)
{
Sum=STARTBYTE1+STARTBYTE2;
Flag=2;
i=0;
break;
}
Sum+=STARTBYTE1;
if((i>=(NBYTE-3))&&Sum==0)
{
GetRight=1;
Flag=0;
break;
}
Buf[i++]=STARTBYTE1;
if(temp==STARTBYTE1)
{
break;
}
Sum+=temp;
if((i>=(NBYTE-3))&&Sum==0)
{
GetRight=1;
Flag=0;
break;
}
Buf[i++]=temp;
Flag=2;
break;
}
}}

第二种方法,使用队列中断函数:

void comm(void) interrupt 4//"串行口中断"{
if(RI==1)
{
RI=0;
SBUF 入队;
}}

主程序不断调用的函数:

unsigned char Buf[NBYTE-2];
unsigned char ReadSerial(unsigned char *cp){
unsigned char i;
unsigned char temp,Sum;
temp=队列中数据个数;
if(temp<(NBYTE)) return 0;
出队 temp;
if(temp!=STARTBYTE1) return 0;
temp=队列首字节;
if(temp!=STARTBYTE2) return 0;
出队 temp;
sum=STARTBYTE1+STARTBYTE2;
for(i=0;i
{
temp=队列首字节;
if(temp==STARTBYTE1)
{
temp=队列次首字节;
if(temp==STARTBYTE2) return 0;
}
出队 temp;
*cp++=temp;
Sum+=temp;
}
temp=队列首字节;
Sum+=temp;
if(Sum!=0) return 0;
出队 temp;
return 1;}

第三种方法,使用RTOS中断函数:

void comm(void) interrupt 4//"串行口中断"{
OS_INT_ENTER();
if(RI==1)
{
RI=0;
OSIntSendSignal(RECIVE_TASK_ID);
}
OSIntExit();}
ID为RECIVE_TASK_ID的任务
void Recuve(void){
unsigned char temp,temp1,Sum,i;
OSWait(K_SIG,0);
temp=SBUF;
while(1)
{
while(1)
{
OSWait(K_SIG,0);
temp1=SBUF;
if((temp==STARTBYTE1)&&(temp1==STARTBYTE2)) break;
temp=temp1;
}
Sum=STARTBYTE1+STARTBYTE2;
OSWait(K_SIG,0);
temp=SBUF;
for(i=0;i
{
OSWait(K_SIG,0);
temp1=SBUF;
if((temp==STARTBYTE1)&&(temp1==STARTBYTE2))
{
OSWait(K_SIG,0);
temp=SBUF;
i=-1;
Sum=STARTBYTE1+STARTBYTE2;
continue;
}
Buf[i]=temp;
Sum+=temp;
temp=temp1;
}
Sum+=temp1;
if(Sum==0) OSSendSignal(命令解释任务 ID);
}}

以下为这几种方法的比较:

可读性和编程容易性方面,第三钟方法最好(如果允许使用goto语句,程序更加简单易读),第二种次之(因为要编队列程序),第一种最差。如果协议更加复杂,这方面更加明显。程序简单易读,自然出错机会小了。

RAM占用方面,第三种方法较少,第二种最多(因为队列占用大量空间),第一种最少。

中断执行时间方面,第三种方法最长,第二种最短,第一种较长。

从功能方面,第三种方法最强,它还可以进行超时处理(虽然例子程序没有),其它方法均不行。

如果数据来的太快,命令处理程序来不及处理,三种方法处理方式不太一样,第一种和第三种方法类似:丢弃以前数据,第二种则是丢弃后到的数据。而且,第二种方法必须等命令处理程序完成后才处理下一个数据包,而第一种和第三种方只需命令处理程序将数据收取后就可处理下一个数据包。也就是说,第一种和第三种与命令处理程序并行处理,第二种方法为串行处理。

现在,一般情况下,开发的效率第一,执行的效率(包括执行时间和资源占用)第二。在这种情况下,降低些许效率换取开发的效率的较大提高,何乐而不为?何况,单个模块的执行的效率高不等于整个程序执行效率高。例如,如果程序需要等待一段时间,一般用程序延时或定时器延时。无论何种方法,CPU不再处理其它工作,效率很低。而用RTOS,等待的时候CPU可以处理其它工作,效率得到提高。

以下摘自《uC/OS-II--源码公开的实时嵌入式操作系统》

“实时内核也称为实时操作系统或RTOS。使用它使得实时应用程序的设计和扩展变得容易。不需要大的改动就可以增加新的功能。通过应用程序分割为若干独立的任务,RTOS使得应用程序的设计过程大为简化。使用可剥夺性的内核时,所有时间要求苛刻的事件都得到了尽可能快捷、有效的处理。通过有效的服务;如信号量、邮箱、队列、延时、超时等;RTOS使得资源得到更好的利用。

“如果应用项目对额外的需求可以承受,应该考虑使用实时内核。这些额外的需求是:内核的价格,额外ROM/RAM开销,2至4百分点的CPU额外负担。

“还有没提到的一个因素是使用实时内核增加的价格成本。在一些应用中,价格就是一切,以至于对使用RTOS连想都不敢想。”

总而言之,适用的就是最好的,不要拒绝RTOS,在它适用的情况下,它工作得很好

本文转自:单片机与嵌入式

围观 22

一、区别

两则的分流造成的主要原因是数字信号处理的简便性,考虑一个数字信号处理的实例,比如有限冲击响应滤波器(FIR)。用数学语言来说,FIR滤波器是做一系列的点积。取一个输入量和一个序数向量,在系数和输入样本的滑动窗口间作乘法,然后将所有的乘积加起来,形成一个输出样本。

类似的运算在数字信号处理过程中大量的重复发生,使得为此设计的器件必须提供专门的支持,促进了DSP器件与通用处理器(GPP)的分流:

1. 对密集乘法的支持


2. 存储器结构


此外,DSP处理器几乎都不具备数据的高速缓存。这是因为DSP的典型数据是数据流。也就是说,DSP处理器对每个数据样本做计算后,就丢弃,几乎不再重复使用。

3. 零开销循环

DSP算法的一个共同的特点,即大多数处理时间都花在执行较小的循环上,也就容易理解,为什么大多数的DSP都有专门的硬件,用于零开销循环。所谓的零开销循环是指处理器在执行循环时,不用花时间去检查循环计数器的值,条件转移到循环大额顶部,将循环计数器减1.

与此相反,GPP的循环使用软件来实现。某些高性能的GPP使用转移预报硬件,几乎达到与硬件支持零开销循环同样地效果。

二、联系

按照传统方式,嵌入式应用中的数字信号处理器(dsp)相对于主微控制器起到从属的作用。在这些应用中,MCU用作系统控制器,而大量的数据处理留给DSP。例如,在音频或视频处理器应用中有可能需要人机界面管理,或则是整个系统的控制。

为完成这些任务,有几种系统设计方案选择

第一种方案是将DSP和MCU芯片组合在印制电路板上。这种方案成本高并且占用面积大,但是可适当地调整每个芯片的尺寸以最大限度的满足系统需要。

第二种方案是将DSP功能合并到一个MCU中。这种方案只适合于直接的信号处理应用。MCU的时钟频率和计算体系结构根本上不太适合大量的数字处理。有些MCU试图通过增加一个乘法和累加器(MAC)(dsp的一个特点)来补偿上述不足。但是这种方案任然缺乏高级应用所需要的基本的“由上至下”的体系结构设计。

第三种方案是一种将dsp和mcu组合在单个封装内的多芯片模块(mcm).这种方案的局限性是,设计工程师必须按“50/50”的时间比例分配给控制和DSP功能;例如,一旦DSP超出时间,MCU不能完成计算任务。像第一种方案选择一样,当DSP和MCU内核独立存在的时候,需要两套开发工具。

已经出现第四种方案它是将MCU的功能合并到一个DSP中。这类方案的一个例子是美国模拟器件公司(Anolog Device Inc.,简称ADI)的Blackfin 处理器系列。这些新型处理器具有统一的经过优化的体系结构,不仅适于数据计算,而且也适于有关的控制任务。通过平衡执行控制任务与复杂计算的要求,这种方案可以根据系统实时处理的需要,完成100%的控制或者100%的计算任务。完成所有这一切任务不需要在DSP模式和MCU模式之间的模式转换。

DSP MCU

首先让我们回顾一下DSP和MCU的典型功能。DSP主要是在一单个时钟周期内尽可能完成多个MAC(乘法和累加)操作。为了这一点,指令的操作代码通常是可变的超长的指令字(VLIW)。DSP也适于工作在紧密、高效的环路中。另外,为了达到性能指标通常需要编写优化的汇编代码。由于DSP的算法程序一般装在小容量、短等待时间的内置存储器中,所以代码密度通常不是大问题。像DSP主要用于完成计算一样,MCU主要用于完成控制功能。同样地,典型的MCU应用包括许多条件操作,在程序流程中频繁地跳转。通常使用C或者C++语言编写程序。代码密度极为重要,并且根据编译代码的长度来评估算法。存储器系统是基于高速缓存从而允许该系统设计工程师用较长等待时间从较大的存储器中调用较大程序。利用基于高速缓存系统,程序员不需要考虑如何以及何时将指令输入到内核去执行。

统一的DSP和MCU兼备两者的优点。它的指令集由16 bit,32 bit和64 bit操作码组成,但是由于最常用的指令采用16 bit编码,所以编译代码密度大小与那些流行的MCU相同。另外,它包括一个存储器保护功能以及指令高速缓存和数据高速缓存,作为整个存储器管理单元(MMU)的一部分。此外,容易提供一套完整的C/C++开发工具,提供可选汇编语言或者全部汇编语言适合算法优化的编程。

RTOS

系统控制的一个重要方面是任务管理。实时操作系统(RTOS)逐渐地用于控制复杂系统中多种正在进行的和同时发生的任务。通过提供对任务调度与管理的支持,RTOS简化了编程模式,这通常是由MCU控制的,由于普通的DSP不具备支持RTOS需要的所有功能以便有效地控制。

然而,统一的DSP和MCU促进了RTOS几个重要功能的发展。第一个是限制访问功能以保护或者保留存储单元。第二个是配备单独的堆栈和帧指针以减少操作系统(OS)请求以及中断和异常处理所需的等待时间。第三个是具备单独的用户操作模式和管理员操作模式。过去,DSP按照等效于管理员操作模式工作,从而允许在任何时间完全访问所有的系统资源。然而MCU提供类似的在用户操作模式,它允许在OS的顶层运行应用软件。现在,在一个统一的体系结构下提供两种操作模式,因为增强的DSP系统能够限制用户应用软件仅通过OS访问系统资源。

MCU的一个优点是包含使用灵活和种类齐全的外围设备。作为通用的嵌入式控制器,它们通常具备可编程输入输出(I/O)标志、定时器、串行接口和日益增加越来越复杂的标准接口。MCU外围设备的主要作用是嵌入式控制,而不是大量计算。例如,一个实时时钟信号可以唤醒一只温度传感器用以采集环境温度并且将一个延迟的信息通过I/O引脚反馈到MCU。然后,一个定时器的脉冲宽度调制(PWM)输出相应地能够增加或者减小风扇电机的转速。像MCU一样,统一的DSP和MCU具备一套系统控制外围设备(例如,实时时钟、多功能定时器、监视定时器、双向标志位引脚)。然而,它还包括一些高速接口(例如,PCI、异步或者同步存储器控制器、USB、并行视频接口)以便通过这些接口,与许多DMA通道配合快速搬移数据,从而有助于有效利用高速DSP内核的信号处理能力。

功耗控制一直是嵌入式控制器的一项功能。但是,当系统要求DSP具有优良的性能时,对其电源的选择就不太理想。如果将独立的MCU和DSP芯片应用于电源敏感的场合,通常必须为每个芯片提供一个单独的开关稳压器,因为这两个器件的内核电压经常不一致。这会导致降低电源变换效率和增加设计器件的引脚数目,最终增加布线的复杂程度和解决方案的成本。此外,当MCU和DSP的内核集成到一个芯片上时,电源解决方案本质上不是最佳的,因为它必须满足2个完全独立并具有不同负载特性处理器的需求。将这种情况与统一的DSP和MCU相比较,它包含一个集成动态电源管理(DPM)控制器。由于它是只有一个处理器的体系结构,所以该控制器能够完全适合给定应用的需求。它提供几种固有的电源模式以支持多种系统性能等级。另外,对于未使用的时钟和L2存储器可选择性地禁止。该PLL的频率可在一个宽范围(通常1倍~31倍)进行调节,以满足在DSP和MCU内部多层次的处理需求。最后能够调节电压(外部或者通过一个集成的开关控制器)以提供指数式的节省功耗。由于系统成本、开发容易、器件采购和升级能力的原因,设计工程师正趋向采用一种单芯片解决方案用于嵌入式信号处理解决方案。这种单芯片解决方案必须能够同样好地完成DSP和MCU的功能,所以有必要提出一种统一的处理器体系结构。面对MCU的挑战,比较简单的解决方案是将MCU的功能合并到一个高性能的DSP内核,而不是与此相反。当今一个统一的DSP和MCU平台(由BlackfinDSP系列产品说明)已经投放市场,它将在MCU和DSP目前应用领域提供许多应用。

本文转自:单片机与嵌入式,转载此文目的在于传递更多信息,版权归原作者所有。

围观 98

页面

订阅 RSS - RTOS