ucosi用什么编译器
❶ uCOS-ii为什么一部分需要汇编语言而不是全部都是C语言
因为需要做任务切换 即把CPU的寄存器 取出 或 恢复 这些与硬件相关的操作是C语言做不到的
❷ 学习ucos用vs编译器可以么
肯定没有被淘汰,尺有所长、寸有所短:重量级的高级的操作系统(如CE、VxWorks等等)当然支持的功能就比较全面;而轻量级的uCos也有它的优点,最大的优点就是重启时间短,而官方维护的uCos如以太网协议栈、LCD显示驱动等等也都一应俱全。
总之,uCos还是被很多是被广泛应用在强实时性、高可靠性的应用领域,学吧。
❸ UCOS II怎么没有OS_CPU.H OS_CPU_C.C OS_CPU_A.ASM。这个几个文件,还有INCLUDES.H
这个有啊!估计你们有好好找啊!这个在Micrium\software\uC-CPU\ARM-Cortex-M3\IAR(最后的两个是因为我移植在Cortex-M3上,编译器用的是IAR)。如果你用的是别的内核,编译器用的其它的也是有相对应的。希望能对你有帮助!
❹ ucos ii是什么啊
μC/OS-II是一种可移植的,可植入ROM的,可裁剪的,抢占式的,实时多任务操作系统内核。它被广泛应用于微处理器、微控制器和数字信号处理器。 μC/OS-II 的前身是μC/OS,最早出自于1992 年美国嵌入式系统专家Jean J.Labrosse 在《嵌入式系统编程》杂志的5 月和6 月刊上刊登的文章连载,并把μC/OS 的源码发布在该杂志的B B S 上。 μC/OS 和μC/OS-II 是专门为计算机的嵌入式应用设计的, 绝大部分代码是用C语言编写的。CPU 硬件相关部分是用汇编语言编写的、总量约200行的汇编语言部分被压缩到最低限度,为的是便于移植到任何一种其它的CPU 上。用户只要有标准的ANSI 的C交叉编译器,有汇编器、连接器等软件工具,就可以将μC/OS-II嵌入到开发的产品中。μC/OS-II 具有执行效率高、占用空间小、实时性能优良和可扩展性强等特点, 最小内核可编译至 2KB 。μC/OS-II 已经移植到了几乎所有知名的CPU 上。 严格地说uC/OS-II只是一个实时操作系统内核,它仅仅包含了任务调度,任务管理,时间管理,内存管理和任务间的通信和同步等基本功能。没有提供输入输出管理,文件系统,网络等额外的服务。但由于uC/OS-II良好的可扩展性和源码开放,这些非必须的功能完全可以由用户自己根据需要分别实现。 uC/OS-II目标是实现一个基于优先级调度的抢占式的实时内核,并在这个内核之上提供最基本的系统服务,如信号量,邮箱,消息队列,内存管理,中断管理等。 uC/OS-II以源代码的形式发布,但并不意味着它是开源软件。你可以将其用于教学和私下研究(peaceful research);但是如果你将其用于商业用途,那么你必须通过Micrium获得商用许可。
❺ 学习ucos的疑问启动代码和编译器
首先,俺不是高手,呵呵,随便扯两句。
1.启动代码没有必要完全看懂,随着你的应用,会渐渐了解的,主要就是一个SP的初始化和PC的跳转。
2.os_cpu_c.c,如果我记得没错的话,这里面主要是一个任务堆栈初始化的函数,就是要把任务的堆栈初始化成刚刚发生中断压栈的情况一样,你可以好好看一下那个压栈的顺序,多少有点讲究的,总而言之,目的就是把任务的堆栈初始化成刚刚发生中断压栈的情况一样。
os_cpu_a.asm这个主要是为了实现任务的切换,一个是多任务开始时的,一个是中断级的任务切换,一个是任务级的切换,还有一个是滴答时钟的实现,之所以放在汇编文件里,是因为这些函数在绝大多数微控制器或微处理器中需要涉及到寄存器的操作,不能在C中实现。
3.至于先学习51还是arm的移植,这个无所谓的,看你对处理器的掌握程度,熟悉哪个就从哪个先开始,因为移植不是最终目的,只是有个利于熟悉内核运作的过程,主要还是在应用上面。
4.对编译器多少还是要有些了解才行,比如栈操作,不熟悉的话就不能写出c_cpu_c.c中的那个栈初始化函数,对任务的切换也不能有深刻的理解。
以上就是我的一些浅显的回答,
希望能对你有所帮助。。
有具体的问题可以给我的空间留言什么的。。
----------------------------mscfox
❻ ucos ii是如何将代码移植到80x86上的
没错,是borland C上编译的,borland C可以编译.c.h的文件,建立一个工程,把相应的文件添加进去编译就可以了。
❼ 线性卷积在DSP芯片上的实现
DSP的特点
对于没有使用过DSP的初学者来说,第一个困惑就是DSP其他的嵌入式处理器究竟有什么不同,它和单片机,ARM有什么区别。事实上,DSP也是一种嵌入式处理器,它完全可以完成单片机的功能。
唯一的重要的区别在于DSP支持单时钟周期的"乘-加"运算。这几乎是所有厂家的DSP芯片的一个共有特征。几乎所有的DSP处理器的指令集中都会有一条MAC指令,这条指令可以把两个操作数从RAM中取出相乘,然后加到一个累加器中,所有这些操作都在一个时钟周期内完成。拥有这样一条指令的处理器就具备了DSP功能。
具有这条指令就称之为数字信号处理器的原因在于,所有的数字信号处理算法中最为常见的算术操作就是"乘-加"。这是因为数字信号处理中大量使用了内积,或称"点积"的运算。无论是FIR滤波,FFT,信号相关,数字混频,下变频。所有这些数字信号处理的运算经常是将输入信号与一个系数表或者与一个本地参考信号相乘然后积分(累加),这就表现为将两个向量(或称序列)进行点积,在编程上就变成将输入的采样放在一个循环buffer里,本地的系数表或参考信号也放在一个buffer里,然后使用两个指针指向这两个buffer。这样就可以在一个loop里面使用一个MAC指令将二者进行点积运算。这样的点积运算对与处理器来说是最快的,因为仅需一个始终周期就可以完成一次乘加。
了解DSP的这一特点后,当我们设计一个嵌入式系统时,首先要考虑处理器所实现的算法中是否有点积运算,即是否要经常进行两个数组的乘加,(记住数字滤波,相关等都表现为两个数组的点积)如果有的话,每秒要做多少次,这样就能够决定是否采用DSP,采用多高性能的DSP了。
浮点与定点
浮点与定点也是经常是初学者困惑的问题,在选择DSP器件的时候,是采用浮点还是采用定点,如果用定点是16位还是32位?其实这个问题和你的算法所要求的信号的动态范围有关。
定点的计算不过是把一个数据当作整数来处理,通常AD采样来的都是整数,这个数相对于真实的模拟信号有一个刻度因子,大家都知道用一个16位的AD去采样一个0到5V的信号,那么AD输出的整数除以2^16再乘以5V就是对应的电压。在定点DSP中是直接对这个16位的采样进行处理,并不将它转换成以小数表示的电压,因为定点DSP无法以足够的精度表示一个小数,它只能对整数进行计算。
而浮点DSP的优势在于它可以把这个采样得到的整数转换成小数表示的电压,并不损失精度(这个小数用科学记数法来表示),原因在于科学记数法可以表示很大的动态范围的一个信号,以IEEE754浮点数为例,
单精度浮点格式: [31] 1位符号 [30-23]8位指数 [22-00]23位小数
这样的能表示的最小的数是+-2^-149,最大的数是+-(2-2^23)*2^127.动态范围为20*log(最大的数/最小的数)=1667.6dB 这样大的动态范围使得我们在编程的时候几乎不必考虑乘法和累加的溢出,而如果使用定点处理器编程,对计算结果进行舍入和移位则是家常便饭,这在一定程度上会损失是精度。原因在于定点处理处理的信号的动态范围有限,比如16位定点DSP,可以表示整数范围为1-65536,其动态范围为20*log(65536/1)=96dB.对于32定点DSP,动态范围为20*log(2^32/1)=192dB,远小于32位ieee浮点数的1667.6dB,但是,实际上192dB对绝大多数应用所处理的信号已经足够了。
由于AD转换器的位数限制,一般输入信号的动态范围都比较小,但在DSP的信号处理中,由于点积运算会使中间节点信号的动态范围增加,所以主要考虑信号处理流程中中间结果的动态范围,以及算法对中间结果的精度要求,来选择相应的DSP。另外就是浮点的DSP更易于编程,定点DSP编程中程序员要不断调整中间结果的P,Q值,实际就是不断对中间结果进行移位调整和舍入。
DSP与RTOS
TI的CCS提供BIOS,ADI的VDSP提供VDK,都是基于各自DSP的嵌入式多任务内核。DSP编程可以用单用C,也可以用汇编,或者二者结合,一般软件编译工具都提供了很好的支持。我不想在这里多说BIOS,VDK怎么用这在相应的文档里说的很详细。我想给初学者说说DSP的RTOS原理。用短短几段话说这个复杂的东西也是挑战!
其实DSP的RTOS和基于其他处理器的通用RTOS没什么大的区别,现在几乎人人皆知的uCOSii也很容易移植到DSP上来,只要把寄存器保存与恢复部分和堆栈部分改改就可以。一般在用BIOS和VDK之前,先看看操作系统原理的书比较好。uCOS那本书也不错。
BIOS和VDK其实是一个RTOS内核函数集,DSP的应用程序会和这些函数连接成一个可执行文件。其实实现一个简单的多任务内核并不复杂,首先定义好内核的各种数据结构,然后写一个scheler函数,功能是从所有就绪任务中(通过查找就绪任务队列或就绪任务表)找出优先级最高的任务,并恢复其执行。然后在此基础上写几个用于任务间通信的函数就可以了,比如event,message box,等等。
RTOS一般采用抢先式的任务调度方式,举例说当任务A等待的资源available的时候,DSP会执行一个任务调度函数scheler,这个函数会检查当前任务是否比任务A优先级低,如果是的话,就会把它当前挂起,然后把任务A保存在堆栈里寄存器值全部pop到DSP处理器中(这就是所谓的任务现场恢复)。接着scheler还会把从堆栈中取出任务A挂起时的程序执行的地址,pop到PC,使任务A继续执行。这样当前任务就被任务A抢先了。
使用RTOS之后,每个任务都会有一个主函数,这个函数的起始地址就是该任务的入口。一般每个任务的主函数里有一个死循环,这个循环使该任务周期地执行,完成一部分算法模块的功能,其实这个函数跟普通函数没任何区别,类似于C语言中的main函数。一个任务创建的时候,RTOS会把这个函数入口地址压入任务的堆栈中,好象这个函数(任务)刚发生过一次中断一样。一旦这个新创建任务的优先级在就绪队列中是最高的,RTOS就会从其堆栈中弹出其入口地址开始执行。
有一个疑问是,不使用RTOS,而是简单使用一个主循环在程序中调用各个函数模块,一样可以实现软件的调度执行。那么,这种常用的方法与使用RTOS相比有什么区别呢?其实,使用主循环的方法不过是一种没有优先级的顺序执行的调度策略而已。这种方法的缺点在于,主循环中调用的各个函数是顺序执行的,那么,即使是一个无关紧要的函数(比如闪烁一个LED),只要他不主动返回,也会一直执行直到结束,这时,如果发生一个重要的事件(比如DMA buffer full 中断),就会得不到及时的响应和处理,只能等到那个闪烁LED的函数执行完毕。这样就使整个DSP处理的优先次序十分不合理。而在使用了RTOS之后,当一个重要的事件发生时,中断处理会进入RTOS,并调用scheler,这时scheler 会让处理这一事件的任务抢占DSP处理器(因为它的优先级高)。而哪个闪烁LED任务即使晚执行几毫秒都没任何影响。这样整个DSP的调度策略就十分合理。
RTOS要说的内容太多,我只能讲一下自己的一点体会吧
DSP与正(余)弦波
在DSP的应用中,我们经常要用到三角函数,或者合成一个正(余)弦波。这是因为我们喜欢把信号通过傅立叶变换映射到三角函数空间来理解信号的频率特性。信号处理的一些计算技巧都需要在DSP软件中进行三角函数计算。然而三角函数计算是非线性的计算,DSP并没有专门的指令来求一个数的正弦或余弦。于是我们需要用线性方法来近似求解。
一个直接的想法是用多项式拟合,这也正是大多数DSP C编译器提供正余弦库函数所采用的方法。其原理是把三角函数向函数空间{1,x,x^2,x^3....}上投影,从而获得一系列的系数,用这些系数就可以拟合出三角函数。比如,我们在[0,pi/2]区间上拟合sin,只需在matlab中输入以下命令:
x=0:0.05:pi/2;
p=polyfit(x,sin(x),5)
就得到5阶的多项式系数:
p =
0.00581052047605 0.00580963216172 -0.17193865685360
0.00209002716293 0.99969270087312 0.00000809543448
于是在[0,pi/2]区间上:
sin(x)= 0.00000809543448+0.99969270087312*x+ 0.00209002716293*x^2-0.17193865685360*x^3+
0.00580963216172*x^4+0.00581052047605*x^5
于是在DSP程序中,我们可以通过用乘加(MAC)指令计算这个多项式来近似求得sin(x)
当然如果用定点DSP还要把P这个多项式系数表用一定的Q值来改写成定点数。
这样的三角函数计算一般都需要几十个cycle 的开销。这对于某些场合是不能容忍的。
另一种更快的方法是借助于查表,比如,我们将[0,pi/2]分成32个区间,每个区间长度就为pi/64,在每个区间上我们使用直线段拟合sin曲线,每个区间线段起点的正弦值和线段斜率事先算好,存在RAM里,这样就需要在在RAM里存储64个
常数:
32个起点的精确的正弦值(事先算好): s[32]={0,sin(pi/64),sin(pi/32),sin(pi/16)....}
32个线段的斜率: f[32]={0.049,.....}
对于输入的每一个x,先根据其大小找到所在区间i,通常x用定点表示,一般取其高几位就是系数i了,然 后通过下式即可求出sin(x):
sin(x)= s[i]*f[i]
这样一般只需几个CYCLE就可以算出正弦值,如果需要更高的精度,可以将区间分得更细,当然,也就需 要更多的RAM去存储常数表。
事实上,不仅三角函数,其他的各种非线性函数都是这样近似计算的。
❽ 学过UCOS_II 但是不会用 这个系统要怎么才能烧进单片机啊
看你用的是哪款单片机和编译器了,用KEIL4的话,对STM32就直接点LOAD就行了,也可以用专用的烧录软件的
❾ stm32 用什么编译器好
应该IAR好很多。
同样的ucosII本家的移植代码Micrium-ST-uCOS-II-LCD-STM32,
用里面自带的keil工程和IAR工程编译,
都设置为最大尺寸优化,
keil的编译结果:
Program Size: Code=27562 RO-data=4870 RW-data=196 ZI-data=9240
FLASF占用:Code+RO-data+RW-data = 27562 +4870 +196 = 32628字节
RAM占用:RW-data+ZI-data = 196 + 9240 = 9436字节
IAR的编译结果:
13 730 bytes of readonly code memory
5 618 bytes of readonly data memory
8 636 bytes of readwrite data memory
FLASF占用:13 730 + 5 618 = 19348字节
RAM占用:8 636字节
KEIL比IAR占用FLASH多:32628- 19348 = 13280字节
❿ ucos-II移植到51单片机可以吗
可以,只要满足:
1.处理器的C编译器能产生可重入代码。
2.用C语言就可以打开和关闭中断。
3.处理器支持中断,并且能产生定时中断(通常在10至100Hz之间)。
4.处理器支持能够容纳一定量数据(可能是几千字节)的硬件堆栈 。
5.处理器有将堆栈指针和其它CPU寄存器读出和存储到堆栈或内存中的指令。
但是移植麻烦一点,因为没有软件中断,不过可以设一个软件陷阱
需要修改的文件有:
OS_CPU.H,OS_CPU_C.C,OS_CPU_A.ASM
具体这么该请参考网上,肯定有现成的程序