RTOS

一、区别

两则的分流造成的主要原因是数字信号处理的简便性,考虑一个数字信号处理的实例,比如有限冲击响应滤波器(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目前应用领域提供许多应用。

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

围观 4

对于搞单片机的特别用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,在它适用的情况下,它工作得很好

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

围观 13

一、区别

两则的分流造成的主要原因是数字信号处理的简便性,考虑一个数字信号处理的实例,比如有限冲击响应滤波器(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目前应用领域提供许多应用。

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

围观 23

微控制器(MCU)广泛应用在各行各业,如各式家电、工业自动化,即时控制、资料采集等领域,为因应工控所需的即时(Realtime)控制、快速回应等需求,因此MCU大多搭载RTOS(即时作业系统)运作。随着物联网的兴起,软体业也为RTOS加入物联网的成分,以提早卡位物联网的核心软体市场…

各种处理器专用之OS

在一般功能(General-purpose)的处理器市场分类中,若以功能与执行速度来说,大致分为CPU > MPU > MCU。CPU的功能最强,主要应用在电脑产品;MPU功能次之,其应用多元,主要应用在嵌入式系统与精简型电脑等多种;而MCU则是以单一应用为主,应用在各式家电、电子产品、嵌入式产品、可穿戴设备、物联网(IoT)应用产品等控制应用。

MCU内部整合了KHz~MHz级的CPU、KB~MB级的记忆体单元(RAM与ROM/EEPROM/Flash)、时脉产生器(Oscillator;Clock Generator)、与I/O扩充单元等,可视为一种速度较慢的系统单芯片(SoC)。

技术干货:MCU专用RTOS种类盘点

由于内部存储容量小,因此大型作业系统如Windows、Linux等是不可能塞入MCU去执行的,且MCU大多被应用在即时控制的环境,因此许多容量小的RTOS(Real-Time Operating System;即时作业系统),便成为开发MCU软体的主要平台。

主打嵌入式应用的中高阶RTOS
  
RTOS的种类繁多,主要设计给基于MPU或MCU的嵌入式系统所使用。例如MPU等级专用的有Integrity、QNX、VxWorks等功能强大之 RTOS;至于体积较小巧,主要支援MCU等级为主的RTOS,则有Nucleus、ThreadX、Unison OS、ucOS II/III等等。
  
以Green Hills Software推出的Integrity OS为例,就是一种支援MPU (甚至CPU等级)为主的RTOS。其强项在于Integrity-178版本已通过EAL 6+(资讯安全)认证与DO-178B(飞安环境) A级认证,被应用在极度重视安全和可靠性的市场,例如战斗机(如B-2、F-16、F-22、F-35)与民航机(如Airbus A380)等领域。该RTOS支援ARM、XScale、Blackfin、Freescale (已并入NXP) ColdFire、MIPS、PowerPC、AMD x86(嵌入式APU)等CPU/MPU平台。
  
另一个知名的QNX RTOS,采用微核心架构,是唯一成功打入商用市场的OS,其强项是多媒体的即时处理能力,适用于车(机)上娱乐设备与手机等嵌入式市场。QNX于 2010年被BlackBerry购并,并开发出BB 10作业系统。QNX支援IA32、MIPS、PowerPC、SH-4、ARM、StrongARM、XScale等CPU/MPU平台。
  
至于像是IntervalZero的RTX、RTX64,则是设计来与微软Windows共存共容的RTOS,搭配EtherCAT协定来做为工厂自动化的应用。其中,Windows主要负责GUI、储存、运算,RTX则负责即时工控与资料采集,让工控软体开发更容易。以上的RTOS都是MB至GB等级的 MPU等级OS,不适用于MCU的环境。
  
主打MCU应用的商用RTOS
  
中低阶RTOS部分,主要是把软体功能极尽精简到MB甚至KB等级,使整个OS与主要应用程式,均可以塞入MCU里的ROM/EEPROM/Flash。由于MCU应用的领域更加广泛,其软体必须力求更加精简,因此MCU专用的RTOS大多具备非常高度模组化的架构,从核心、驱动程式、档案系统、周边 I/O、网路支援等,都可以量身订作,以利产品快速上市。
  
商用的RTOS有些会提供原始码给授权客户,而开源的RTOS则更能自由使用,让开发人员可以编译出程式码最小、最佳化的执行环境。
  
由于各芯片厂所推出的MCU产品/开发板,都会有其对应的OS与IDE(整合软体开发环境),但这些OS与软体开发环境可能只适用于该厂的MCU产品,因此第三方软体厂商,就开发出跨芯片/跨硬体平台的OS与IDE,让开发人员不须因为换了硬体平台,软体就必须全部改写。
  
目前MCU OS/IDE市场占有率最高的,大多是软体公司所推出商用RTOS(搭配各厂商的MCU产品),然随着ARM推出Cortex-M、Cortex-R等指令集架构,进军可穿戴与物联网应用市场,使得ARM架构(采开源码)的RTOS开始有提升的趋势。
  
Mentor Graphics旗下Accelerated Technology公司所推出的Nucleus,采Microkernel设计,号称有30亿个设备导入,优势是核心长度可以小至2KB,且开发人员不需要撰写嵌入式设备专用BSP(开发板支援套装软体),因此被广泛应用到消费性电子、移动设备、车用电子、智能能源、医疗仪器、工业/工控等领域。
  
早期采用联发科MT6217芯片的大陆山寨、白牌、双卡2G手机,就是执行Nucleus RTOS。该RTOS支援ARM、MicroBlaze、MIPS、Nios II、Power、SuperH、XScale等嵌入式MCU架构。
  
Express Logic推出的ThreadX,则是一套免收权利金的RTOS,其优点是具备超快速的开机时间、反应时间,其Picokernel核心长度低于2KB,并通过安全规范,号称有21亿个设备导入使用。例如HP的旗下印表机和事务机便采用该RTOS。可广泛支援各式32位MCU,包含ARM、Atmel、 BlackFin、CoreFire/68K、EFM32、Freescale (NXP)、FM3、H8、XMC、M-Core、MicroBlaze、MIPS、Nios II、Power、STM32、StrongARM、Synopsys ARC、TI、Win32、x86/x386、XScale等等。
  
Wind River公司所推出的VxWorks,主要针对嵌入式系统设计,采Monolithic (单体式)核心,优势是具备先占式多工处理核心、循环执行、岔断快速反应等特性,原生支援64位处理器架构(x64)、可进行平行(SMP)/非平行 (AMP)处理,累积至今有超过15亿个设备导入。
  
新版VxWorks 7则瞄准IoT所需要的可扩充性、安全性、连接性、绘图能力、虚拟化等做强化,而全功能的VxWorks微核心长度只要20KB。VxWorks广受科技业界的采用,登陆火星的Curiosity(好奇号)便采用VxWorks。该RTOS支援Intel x86(包含Quark SoC与x86-64)、MIPS、PowerPC、SH-4、ARM等CPU/MPU架构。
  
RoweBots公司的Unison OS,则是一款完全相容于POSIX(可移植作业系统界面)的RTOS,适用于MCU、DSC、DSP、SoC、FPGA等32位的硬体开发环境,其好处是特别针对物联网的应用,提升其系统安全性,且核心程式码在某些应用架构可以低到仅1KB。支援Microchip PIC32、Renesas R32C/SH2A、ST STM32、TI ARM Cortex-M3等32位MCU。
  
Micrium的μc/OS-II (microcontroller OS version 2),主打可携、能在ROM执行、弹性、先占式多工的RTOS核心,可管理高达250个应用任务。μc/OS-III则主打无限应用任务、几近于零的岔断,并可提供原始码给客户。
  
其优势在于该系统原始码开放、整洁一致、注释详尽,亦通过FAA认证与DO-178B认证,适合各种嵌入式与物联网的系统开发,核心大小从5或 6KB~24KB。至于μc/OS-III HW-RTOS,则是针对ARM Cortex-M为主的MCU做硬体加速。该RTOS可支援超过100种DSP、MPU、MCU。
  
ARM MCU促使开源RTOS兴起
  
近年来由于ARM架构的处理器横扫全球智能移动设备(手机/平板)市场,除了搭配各MCU/MPU硬体平台所推出的商用RTOS/IDE之外,为进军物联网与可穿戴的MCU级应用,ARM推出Cortex-M与Cortex-R的指令集架构,搭配开源的OS/IDE来抢占MCU的应用市场。
  
例如ARM推出的mbed OS与相关开发环境,便着重于嵌入式设备与IoT的应用,具备连接性、高效率、安全性、生产力的OS,搭配其mbed-rtos函式库,亦可做为RTOS的应用。该mbed开发环境,可开发出智能家庭、智能城市、可穿戴等应用产品。
  
此外,坊间针对ARM平台所推出的开源RTOS/IDE很多,例如FreeRTOS、uKOS-II、Atomthreads、BeRTOS社群版、 ChibiOS/RT、CoActionOS、eCos、Embox、Erika Enterprise/RT-Druid、Keil (ARM) RTX、Lepton、nOS、Nut/OS、NuttX、RIOT、RT-Thread、TI-RTOS-KERNEL(SYS/BIOS)、TNeo 等等,让开发人员有更多的选择。
  
其他专用MCU的非即时OS概述
  
此外,也有许多针对MCU设计的开源OS (非RTOS),但同样具有体积小的特性,有些是针对IoT的WSN(无线传感网路)应用,例如Contiki OS、TinyOS。而有些则具备一般桌上型图形化使用界面(GUI),例如SymbOS、Wheels OS等。
  
Contiki OS是一套开源的微型OS,可应用在Atmel ARM/AVR、LPC、PIC32、TI MSP430/CC2430/2538/2630/2650、STM32W等MCU做IoT应用,也可在博物馆级的8位电脑(Apple II、Atari、Commodore等)做上网连线、甚至在骨灰级游乐器(Atari Jaguar、Game Boy/Advance、GP32、任天堂红白机、PC Engine等)上执行。

至于SymbOS,则是一套能在8位Z80 CPU (如MSX、Amstrad)的古董电脑上执行之免费多媒体图形作业系统,赋予如Windows 95般的操作画面,让旧电脑回春。

来源: eepw.com

围观 473

微控制器(MCU)广泛应用在各行各业,如各式家电、工业自动化,实时控制、资料采集等领域,为因应工控所需的实时(Realtime)控制、快速回应等需求,因此MCU大多搭载RTOS(实时操作系统)运行。随著物联网的兴起,软件业也为RTOS加入物联网的成分,以提早卡位物联网的核心软件市场…

各种处理器专用之OS

在一般功能(General-purpose)的处理器市场分类中,若以功能与执行速度来说,大致分为CPU > MPU > MCU。CPU的功能最强,主要应用在计算机产品;MPU功能次之,其应用多元,主要应用在嵌入式系统与精简型计算机等多种;而MCU则是以单一应用为主,应用在各式家电、电子产品、嵌入式产品、穿戴式装置、物联网(IoT)应用产品等控制应用。

麻雀虽小 五脏俱全:MCU专用RTOS简述

麻雀虽小 五脏俱全:MCU专用RTOS简述

麻雀虽小 五脏俱全:MCU专用RTOS简述

MCU内部集成了KHz~MHz级的CPU、KB~MB级的存储器单元(RAM与ROM/EEPROM/Flash)、时脉产生器(Oscillator;Clock Generator)、与I/O扩充单元等,可视为一种速度较慢的系统单芯片(SoC)。

由于内部存储器容量小,因此大型操作系统如Windows、Linux等是不可能塞入MCU去执行的,且MCU大多被应用在实时控制的环境,因此许多容量小的RTOS(Real-Time Operating System;实时操作系统),便成为开发MCU软件的主要平台。

主打嵌入式应用的中高阶RTOS

RTOS 的种类繁多,主要设计给基于MPU或MCU的嵌入式系统所使用。例如MPU等级专用的有Integrity、QNX、VxWorks等功能强大之 RTOS;至于体积较小巧,主要支持MCU等级为主的RTOS,则有Nucleus、ThreadX、Unison OS、ucOS II/III等等。

以Green Hills Software推出的Integrity OS为例,就是一种支持MPU (甚至CPU等级)为主的RTOS。其强项在于Integrity-178版本已通过EAL 6+?(信息安全)认证与DO-178B(飞安环境) A级认证,被应用在极度重视安全和可靠性的市场,例如战斗机(如B-2、F-16、F-22、F-35)与民航机(如Airbus A380)等领域。该RTOS支持ARM、XScale、Blackfin、Freescale (已并入NXP) ColdFire、MIPS、PowerPC、AMD x86(嵌入式APU)等CPU/MPU平台。

另一个知名的QNX RTOS,采用微核心架构,是唯一成功打入商用市场的OS,其强项是多媒体的实时处理能力,适用于车(机)上娱乐装置与手机等嵌入式市场。QNX于 2010年被BlackBerry购并,并开发出BB 10操作系统。QNX支持IA32、MIPS、PowerPC、SH-4、ARM、StrongARM、XScale等CPU/MPU平台。

至于象是IntervalZero的RTX、RTX64,则是设计来与微软Windows共存共容的RTOS,搭配EtherCAT协定来做为工厂自动化的应用。其中,Windows主要负责GUI、储存、运算,RTX则负责实时工控与资料采集,让工控软件开发更容易。以上的RTOS都是MB至GB等级的 MPU等级OS,不适用于MCU的环境。

主打MCU应用的商用RTOS

中低阶 RTOS部分,主要是把软件功能极尽精简到MB甚至KB等级,使整个OS与主要应用程序,均可以塞入MCU里的ROM/EEPROM/Flash。由于 MCU应用的领域更加广泛,其软件必须力求更加精简,因此MCU专用的RTOS大多具备非常高度模块化的架构,从核心、驱动程序、档案系统、外围I/O、网络支持等,都可以量身订作,以利产品快速上市。

商用的RTOS有些会提供原始码给授权客户,而开源的RTOS则更能自由使用,让开发人员可以编译出程序码最小、最佳化的执行环境。

由于各芯片厂所推出的MCU产品/开发板,都会有其对应的OS与IDE(集成软件开发环境),但这些OS与软件开发环境可能只适用于该厂的MCU产品,因此第三方软件厂商,就开发出跨芯片/跨硬件平台的OS与IDE,让开发人员不须因为换了硬件平台,软件就必须全部改写。

目前MCU OS/IDE市场占有率最高的,大多是软件公司所推出商用RTOS(搭配各厂商的MCU产品),然随著ARM推出Cortex-M、Cortex-R等指令集架构,进军穿戴式与物联网应用市场,使得ARM架构(采开源码)的RTOS开始有提升的趋势。

Mentor Graphics旗下Accelerated Technology公司所推出的Nucleus,采Microkernel设计,号称有30亿个装置导入,优势是核心长度可以小至2KB,且开发人员不需要撰写嵌入式装置专用BSP(开发板支持软件包),因此被广泛应用到消费性电子、行动装置、车用电子、智能能源、医疗仪器、工业/工控等领域。

早期采用联发科MT6217芯片的大陆山寨、白牌、双卡2G手机,就是执行Nucleus RTOS。该RTOS支持ARM、MicroBlaze、MIPS、Nios II、Power、SuperH、XScale等嵌入式MCU架构。

Express Logic推出的ThreadX,则是一套免收权利金的RTOS,其优点是具备超快速的开机时间、反应时间,其Picokernel核心长度低于2KB,并通过安全规范,号称有21亿个装置导入使用。例如HP的旗下打印机和事务机便采用该RTOS。可广泛支持各式32位元MCU,包含ARM、Atmel、 BlackFin、CoreFire/68K、EFM32、Freescale (NXP)、FM3、H8、XMC、M-Core、MicroBlaze、MIPS、Nios II、Power、STM32、StrongARM、Synopsys ARC、TI、Win32、x86/x386、XScale等等。

Wind River公司所推出的VxWorks,主要针对嵌入式系统设计,采Monolithic (单体式)核心,优势是具备先占式多工处理核心、循环执行、岔断快速反应等特性,原生支持64位元处理器架构(x64)、可进行平行(SMP)/非平行 (AMP)处理,累积至今有超过15亿个装置导入。

新版VxWorks 7则瞄准IoT所需要的可扩充性、安全性、连结性、绘图能力、虚拟化等做强化,而全功能的VxWorks微核心长度只要20KB。

VxWorks广受科技业界的采用,登陆火星的Curiosity(好奇号)便采用VxWorks。该RTOS支持Intel x86(包含Quark SoC与x86-64)、MIPS、PowerPC、SH-4、ARM等CPU/MPU架构。

RoweBots公司的Unison OS,则是一款完全兼容于POSIX(可移植操作系统接口)的RTOS,适用于MCU、DSC、DSP、SoC、FPGA等32位元的硬件开发环境,其好处是特别针对物联网的应用,提升其系统安全性,且核心程序码在某些应用架构可以低到仅1KB。支持Microchip PIC32、Renesas R32C/SH2A、ST STM32、TI ARM Cortex-M3等32位元MCU。

Micrium的μc/OS-II (microcontroller OS version 2),主打可携、能在ROM执行、弹性、先占式多工的RTOS核心,可管理高达250个应用任务。μc/OS-III则主打无限应用任务、几近于零的岔断,并可提供原始码给客户。

其优势在于该系统原始码开放、整洁一致、注释详尽,亦通过FAA认证与DO-178B认证,适合各种嵌入式与物联网的系统开发,核心大小从5或 6KB~24KB。至于μc/OS-III HW-RTOS,则是针对ARM Cortex-M为主的MCU做硬件加速。该RTOS可支持超过100种DSP、MPU、MCU。

ARM MCU促使开源RTOS兴起

近年来由于ARM架构的处理器横扫全球智能行动装置(手机/平板)市场,除了搭配各MCU/MPU硬件平台所推出的商用RTOS/IDE之外,为进军物联网与穿戴式的MCU级应用,ARM推出Cortex-M与Cortex-R的指令集架构,搭配开源的OS/IDE来抢占MCU的应用市场。

例如ARM推出的mbed OS与相关开发环境,便着重于嵌入式装置与IoT的应用,具备连接性、高效率、安全性、生产力的OS,搭配其mbed-rtos函式库,亦可做为RTOS的应用。该mbed开发环境,可开发出智能家庭、智慧城市、穿戴式等应用产品。

此外,坊间针对ARM平台所推出的开源RTOS/IDE很多,例如FreeRTOS、uKOS-II、Atomthreads、BeRTOS社群版、 ChibiOS/RT、CoActionOS、eCos、Embox、Erika Enterprise/RT-Druid、Keil (ARM) RTX、Lepton、nOS、Nut/OS、NuttX、RIOT、RT-Thread、TI-RTOS-KERNEL(SYS/BIOS)、TNeo 等等,让开发人员有更多的选择。

其它专用MCU的非实时OS概述

此外,也有许多针对MCU设计的开源OS (非RTOS),但同样具有体积小的特性,有些是针对IoT的WSN(无线感测网络)应用,例如Contiki OS、TinyOS。而有些则具备一般桌上型图形化使用接口(GUI),例如SymbOS、Wheels OS等。

Contiki OS是一套开源的微型OS,可应用在Atmel ARM/AVR、LPC、PIC32、TI MSP430/CC2430/2538/2630/2650、STM32W等MCU做IoT应用,也可在博物馆级的8位元计算机(Apple II、Atari、Commodore等)做上网联机、甚至在骨灰级游乐器(Atari Jaguar、Game Boy/Advance、GP32、任天堂红白机、PC Engine等)上执行。

至于SymbOS,则是一套能在8位元Z80 CPU (如MSX、Amstrad)的古董计算机上执行之免费多媒体图形操作系统,赋予如Windows 95般的操作画面,让旧计算机回春。

来源:网络

围观 303

来源: 21ic电子网

一、区别

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

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

1. 对密集乘法的支持

从架构到RTOS 详解DSP和MCU的区别和联系

2. 存储器结构

从架构到RTOS 详解DSP和MCU的区别和联系

此外,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模式之间的模式转换。

DSPMCU
首先让我们回顾一下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目前应用领域提供许多应用。

围观 344

摘要

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

概述

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

1

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

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

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

2

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

3

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

微控制器性能的提升让一些实时操作系统RTOS有了“容身之地”,在32位 的ARM Cortex-M系列产品中,越来越多的产品用上了RTOS。也为一些中间件/协议栈或一些高级的应用提供了一个平台基础。产品的系统化设计成为了可能,为物联网大规模开发部署提供了发展机会。

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

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

4

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

5

常用的一些中间件:

6

ARM mbed.org

值得一提的是mbed.org项目。mbed.org项目不仅仅是一个操作系统那么简单,而是构建了一个全方位的物联网产品原型开发框架。凭借ARM Cortex-M系列的产品的市场优势,ARM公司联络了一些MCU厂商和合作伙伴推出了基于ARM Cortex-M的物联网产品原型开发平台。ARM及其合作伙伴的提出的口号就是“连接一切”。

在业内能提供如此全方面开放的面向物联网开发的平台几乎没有,也值得物联网从业者关注。

ARM mbed物联网平台系统如下:

7

mbed OS系统图:

8

mbed Device server系统图:

9

开发平台选择

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

● 微控制器
做一个“跟随者”,参考同行中的产品选型。不做“第一个吃螃蟹”的,这样可以避免走一些不必要的弯路,不会有产品开发风险。但新机会往往会都是会眷顾那些“敢为天下先”的人。新的产品层出不穷,也为开发者提供了更多的选择空间。
对于遥控、小家电/家电、智能卡、玩具等市场应用而言,4位/8位/16位仍然有很大的选择空间。毕竟一些应用的数据处理要求并不高,在原有产品基础上开发,开发成本低。

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

● 嵌入式实时操作系统(RTOS)
32位MCU的流行,开发者越来越爱使用RTOS了。有的甚至在8位MCU上跑RTOS。RTOS提供了开发的便捷性,但在资源紧张的8位微控制器上运行还是有一些局限性的。建议还是在资源丰富的产品上运行RTOS。

选择活跃度比较高的开源的RTOS会得到后续更好的升级维护,学习成本低,社区众多人的支持和参与会使得RTOS不断改进不断完善。国内的RTOS操作系统近几年也多了起来,如:RT-Thread、 MiCo、DJYOS、μTenux等等。开发者可以根据项目需求选择适合的RTOS。

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

10

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

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

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

11

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

物联网的发展

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

12

作者简介:
王志杰(王志杰_ST_MCU),目前就职于大联大商贸有限公司,从事技术推广工作,负责ST MCU产品。

来源:CSDN

围观 375

作为基于ARM7、Cortex-M3硬件开发的嵌入式工程师,本人一直反对使用RTOS。不仅因为不恰当的使用RTOS会给项目带来额外的稳定性风险,更重要的是个人认为绝大多数基于ARM7、Cortex-M3硬件的项目,还没复杂到使用RTOS的地步,使用状态机就足够了。

对于现代的微处理器,特别是资源相对丰富ARM7、Cortex-M3硬件来说,RTOS占用的硬件资源已经越来越可以忽略。所以在当今环境下,我们无需担心RTOS会拖累性能。相反,RTOS提供的事件驱动型设计方式,使得RTOS只是在处理实际任务时才会运行,这能够更合理的利用CPU。

在实际项目中,如果程序等待一个超时事件,传统的无RTOS情况下,要么在原地一直等待而不能执行其它任务,要么使用复杂(相对RTOS提供的任务机制而言)的状态机机制。如果使用RTOS,则可以很方便的将当前任务阻塞在该事件下,然后自动去执行别的任务,这显然更方便,并且可以高效的利用CPU。处理这类事件,是使用RTOS的最大动力,但考虑到系统的稳定性,不得不再三权衡RTOS可能带来的一些弊端:

1、大多数RTOS代码都具有一定规模,任何代码都可能带来BUG,何况是代码具有一定规模的RTOS,因此引入RTOS的同时也可能会引入该RTOS的BUG,这些RTOS本身的BUG一旦被触发,影响可能是是灾难性的。

2、熟练的使用RTOS是一项技能,需要专业的知识储备和长期的经验积累。不将RTOS分析透彻,很容易为项目埋下错误。典型的,像中断优先级、任务堆栈分配、可重入等,都是更容易出错的地方。

3、RTOS的优先级嵌套使得任务执行顺序、执行时序更难分析,甚至变成不可能。任务嵌套对所需的最大堆栈RAM大小估计也变得困难。这对于很多对安全有严格要求的场合是不可想象的。

4、RTOS应该用于任务复杂的场合,以至于对任务调度的需求可以抵消RTOS所带来的稳定性影响,但大部分的应用并非复杂到需要RTOS。
以上原因是本人拒绝在实际项目中使用RTOS的理由,但是否使用RTOS跟是否学习RTOS完全是两码事。个人认为任何嵌入式软件设计人员都应该至少学习一种RTOS,不仅是需要掌握RTOS背后的操作系统原理、学习RTOS的编程方式,更是为将来做准备。

即便个人认为现在的物联网有点言过其实,但依然看好物联网的发展前景。随着物联网的发展,未来的嵌入式产品必然更为复杂、连接性更强以及需要更丰富的用户界面。当处理这些任务时,一个好的RTOS就变得不可缺少了。

书到用时方恨少,希望大家永远不会有这种感觉。

为什么选用FreeRTOS?

对比了许多RTOS,最后选择FreeRTOS,原因是多方面的:

1、SafeRTOS便是基于FreeRTOS而来,前者是经过安全认证的RTOS,因此对于FreeRTOS的安全性也有了信心。

2、大量开发者使用,并保持高速增长趋势。2011、2012、2013、2014、2015连续5年的EEtimes杂志嵌入式系统市场报告显示,FreeRTOS在RTOS内核使用榜和RTOS内核计划使用榜上都名列前茅。更多的人使用可以促进发现BUG,增强稳定性。

3、简单。内核只有3个.c文件,全部围绕着任务调度,没有任何其它干扰,便于理解学习。而且,根本不需要其它繁多的功能,只要任务调度就够了。

4、文档齐全。在FreeRTOS官方网站上,可以找到所有你需要的资料。

5、免费、开放源码。完全可以免费用于商业产品,开放源码更便于学习操作系统原理、从全局掌握FreeRTOS运行机理、以及对操作系统进行深度裁剪以适应自己的硬件。

学习的资料来源主要是FreeRTOS的官方网站(www.freertos.org)和源代码。FreeRTOS的创始人RichardBarry编写了大量的移植代码和配套文档,只不过是沿着Richard Barry铺好的路前进,所以,这没什么困难的。

附录1:2010~2014年嵌入式市场调查报告有关RTOS使用榜截图

↑↑2010和2011年RTOS使用榜

↑↑2012和2013年RTOS使用榜

↑↑2013年和2014年RTOS使用榜

↑↑2014年和2015年RTOS使用榜
围观 530

微控制器(MCU)广泛应用在各行各业,如各式家电、工业自动化,实时控制、资料采集等领域,为因应工控所需的实时(Realtime)控制、快速回应等需求,因此MCU大多搭载RTOS(实时操作系统)运行。随著物联网的兴起,软件业也为RTOS加入物联网的成分,以提早卡位物联网的核心软件市场…

各种处理器专用之OS

在一般功能(General-purpose)的处理器市场分类中,若以功能与执行速度来说,大致分为CPU > MPU > MCU。CPU的功能最强,主要应用在计算机产品;MPU功能次之,其应用多元,主要应用在嵌入式系统与精简型计算机等多种;而MCU则是以单一应用为主,应用在各式家电、电子产品、嵌入式产品、穿戴式装置、物联网(IoT)应用产品等控制应用。


MCU内部集成了KHz~MHz级的CPU、KB~MB级的存储器单元(RAM与ROM/EEPROM/Flash)、时脉产生器(Oscillator;Clock Generator)、与I/O扩充单元等,可视为一种速度较慢的系统单芯片(SoC)。

由于内部存储器容量小,因此大型操作系统如Windows、Linux等是不可能塞入MCU去执行的,且MCU大多被应用在实时控制的环境,因此许多容量小的RTOS(Real-Time Operating System;实时操作系统),便成为开发MCU软件的主要平台。

主打嵌入式应用的中高阶RTOS

RTOS的种类繁多,主要设计给基于MPU或MCU的嵌入式系统所使用。例如MPU等级专用的有Integrity、QNX、VxWorks等功能强大之RTOS;至于体积较小巧,主要支持MCU等级为主的RTOS,则有Nucleus、ThreadX、Unison OS、ucOS II/III等等。

以Green Hills Software推出的Integrity OS为例,就是一种支持MPU (甚至CPU等级)为主的RTOS。其强项在于Integrity-178版本已通过EAL 6+?(信息安全)认证与DO-178B(飞安环境) A级认证,被应用在极度重视安全和可靠性的市场,例如战斗机(如B-2、F-16、F-22、F-35)与民航机(如Airbus A380)等领域。该RTOS支持ARM、XScale、Blackfin、Freescale (已并入NXP) ColdFire、MIPS、PowerPC、AMD x86(嵌入式APU)等CPU/MPU平台。

另一个知名的QNX RTOS,采用微核心架构,是唯一成功打入商用市场的OS,其强项是多媒体的实时处理能力,适用于车(机)上娱乐装置与手机等嵌入式市场。QNX于2010年被BlackBerry购并,并开发出BB 10操作系统。QNX支持IA32、MIPS、PowerPC、SH-4、ARM、StrongARM、XScale等CPU/MPU平台。

至于象是IntervalZero的RTX、RTX64,则是设计来与微软Windows共存共容的RTOS,搭配EtherCAT协定来做为工厂自动化的应用。其中,Windows主要负责GUI、储存、运算,RTX则负责实时工控与资料采集,让工控软件开发更容易。以上的RTOS都是MB至GB等级的MPU等级OS,不适用于MCU的环境。

主打MCU应用的商用RTOS

中低阶RTOS部分,主要是把软件功能极尽精简到MB甚至KB等级,使整个OS与主要应用程序,均可以塞入MCU里的ROM/EEPROM/Flash。由于MCU应用的领域更加广泛,其软件必须力求更加精简,因此MCU专用的RTOS大多具备非常高度模块化的架构,从核心、驱动程序、档案系统、外围I/O、网络支持等,都可以量身订作,以利产品快速上市。

商用的RTOS有些会提供原始码给授权客户,而开源的RTOS则更能自由使用,让开发人员可以编译出程序码最小、最佳化的执行环境。

由于各芯片厂所推出的MCU产品/开发板,都会有其对应的OS与IDE(集成软件开发环境),但这些OS与软件开发环境可能只适用于该厂的MCU产品,因此第三方软件厂商,就开发出跨芯片/跨硬件平台的OS与IDE,让开发人员不须因为换了硬件平台,软件就必须全部改写。

目前MCU OS/IDE市场占有率最高的,大多是软件公司所推出商用RTOS(搭配各厂商的MCU产品),然随著ARM推出Cortex-M、Cortex-R等指令集架构,进军穿戴式与物联网应用市场,使得ARM架构(采开源码)的RTOS开始有提升的趋势。

Mentor Graphics旗下Accelerated Technology公司所推出的Nucleus,采Microkernel设计,号称有30亿个装置导入,优势是核心长度可以小至2KB,且开发人员不需要撰写嵌入式装置专用BSP(开发板支持软件包),因此被广泛应用到消费性电子、行动装置、车用电子、智能能源、医疗仪器、工业/工控等领域。

早期采用联发科MT6217芯片的大陆山寨、白牌、双卡2G手机,就是执行Nucleus RTOS。该RTOS支持ARM、MicroBlaze、MIPS、Nios II、Power、SuperH、XScale等嵌入式MCU架构。

Express Logic推出的ThreadX,则是一套免收权利金的RTOS,其优点是具备超快速的开机时间、反应时间,其Picokernel核心长度低于2KB,并通过安全规范,号称有21亿个装置导入使用。例如HP的旗下打印机和事务机便采用该RTOS。可广泛支持各式32位元MCU,包含ARM、Atmel、BlackFin、CoreFire/68K、EFM32、Freescale (NXP)、FM3、H8、XMC、M-Core、MicroBlaze、MIPS、Nios II、Power、STM32、StrongARM、Synopsys ARC、TI、Win32、x86/x386、XScale等等。

Wind River公司所推出的VxWorks,主要针对嵌入式系统设计,采Monolithic (单体式)核心,优势是具备先占式多工处理核心、循环执行、岔断快速反应等特性,原生支持64位元处理器架构(x64)、可进行平行(SMP)/非平行(AMP)处理,累积至今有超过15亿个装置导入。

新版VxWorks 7则瞄准IoT所需要的可扩充性、安全性、连结性、绘图能力、虚拟化等做强化,而全功能的VxWorks微核心长度只要20KB。VxWorks广受科技业界的采用,登陆火星的Curiosity(好奇号)便采用VxWorks。该RTOS支持Intel x86(包含Quark SoC与x86-64)、MIPS、PowerPC、SH-4、ARM等CPU/MPU架构。

RoweBots公司的Unison OS,则是一款完全兼容于POSIX(可移植操作系统接口)的RTOS,适用于MCU、DSC、DSP、SoC、FPGA等32位元的硬件开发环境,其好处是特别针对物联网的应用,提升其系统安全性,且核心程序码在某些应用架构可以低到仅1KB。支持Microchip PIC32、Renesas R32C/SH2A、ST STM32、TI ARM Cortex-M3等32位元MCU。

Micrium的μc/OS-II (microcontroller OS version 2),主打可携、能在ROM执行、弹性、先占式多工的RTOS核心,可管理高达250个应用任务。μc/OS-III则主打无限应用任务、几近于零的岔断,并可提供原始码给客户。

其优势在于该系统原始码开放、整洁一致、注释详尽,亦通过FAA认证与DO-178B认证,适合各种嵌入式与物联网的系统开发,核心大小从5或6KB~24KB。至于μc/OS-III HW-RTOS,则是针对ARM Cortex-M为主的MCU做硬件加速。该RTOS可支持超过100种DSP、MPU、MCU。

ARM MCU促使开源RTOS兴起

近年来由于ARM架构的处理器横扫全球智能行动装置(手机/平板)市场,除了搭配各MCU/MPU硬件平台所推出的商用RTOS/IDE之外,为进军物联网与穿戴式的MCU级应用,ARM推出Cortex-M与Cortex-R的指令集架构,搭配开源的OS/IDE来抢占MCU的应用市场。

例如ARM推出的mbed OS与相关开发环境,便着重于嵌入式装置与IoT的应用,具备连接性、高效率、安全性、生产力的OS,搭配其mbed-rtos函式库,亦可做为RTOS的应用。该mbed开发环境,可开发出智能家庭、智慧城市、穿戴式等应用产品。

此外,坊间针对ARM平台所推出的开源RTOS/IDE很多,例如FreeRTOS、uKOS-II、Atomthreads、BeRTOS社群版、ChibiOS/RT、CoActionOS、eCos、Embox、Erika Enterprise/RT-Druid、Keil (ARM) RTX、Lepton、nOS、Nut/OS、NuttX、RIOT、RT-Thread、TI-RTOS-KERNEL(SYS/BIOS)、TNeo等等,让开发人员有更多的选择。

其它专用MCU的非实时OS概述

此外,也有许多针对MCU设计的开源OS (非RTOS),但同样具有体积小的特性,有些是针对IoT的WSN(无线感测网络)应用,例如Contiki OS、TinyOS。而有些则具备一般桌上型图形化使用接口(GUI),例如SymbOS、Wheels OS等。

Contiki OS是一套开源的微型OS,可应用在Atmel ARM/AVR、LPC、PIC32、TI MSP430/CC2430/2538/2630/2650、STM32W等MCU做IoT应用,也可在博物馆级的8位元计算机(Apple II、Atari、Commodore等)做上网联机、甚至在骨灰级游乐器(Atari Jaguar、Game Boy/Advance、GP32、任天堂红白机、PC Engine等)上执行。

至于SymbOS,则是一套能在8位元Z80 CPU (如MSX、Amstrad)的古董计算机上执行之免费多媒体图形操作系统,赋予如Windows 95般的操作画面,让旧计算机回春。

文章来源:电子时报

围观 538
订阅 RSS - RTOS