UC/OS下基于DMA模式的ADC乱码打印的问题

UC/OS下基于DMA模式的ADC乱码打印的问题

• 我在从裸板移植到ucos的时候遇见了一个这样奇怪的问题。ADC在任务调度下循环打印数值是没有问题的。但是当我加上RTC之后就不行啦，ADC打印的全是乱码。本人才学浅陋，总以为是RTC的配置或者说地址对DMA的存储产生了影响，在分析的时候发现，我只要在工程中添加RTC的文件不进行任何操作就会出现乱码的情况。后来把注意力转移到的执行ADC的任务的时候因为受到RTC不间断的中断打断使ADC的数据发生错乱。
• 接着我就实在是搞不懂怎么回事啦，就查了查百度。大概情况是在ucos的移植下不支持浮点数的打印，具体情况不太清楚。只是说明了需要在ADC的任务堆栈前进行数据存储的对齐方式进行声明。
• 
• 前面这个 __align(8)，这个查了查百度，大概功能是进行数据存储的时候地址进行对齐。
• 我们都知道，在32位也就是M3下一个地址下有一个字节的存储空间，对于一个int型的变量需要占用四个字节，也就是它的存储格式是从0x0000 0000—0x0000 0003连续的四个地址，存放这个变量。我们都知道浮点数很大占用的内存也很大，在ucos下也就是arm编译不会对数据的格式进行修改，会出现数据不对齐，这样CPU在访问的时候自然数据就不对啦。而这个关键字就是干这个活的。
• 那为什么在裸机上就可以或者逻辑的使用方式就可以而ucos的使用方式就不行啦呢。首先，ucos的每一个人任务都有自己的堆栈大小，在进行任务调度的时候判定成功都会进行CPU状态和数据的入栈出栈操作。在RTC这种不断发生中断且频率较高的异常中断情况下，会抢夺CPU的控制权，而这个时候ADC的任务必须从运行态转变为挂起态而且要进行现场保护也就数据数据的入栈操作，而这个时候不管是哪种寻址方式还是直接寻址，寄存器内即是操作数，都需要进行入栈操作。而因为浮点数的自身的原因在存储的时候就出现了数据不对齐存储的问题，或者因为数据量占用内存较大而造成溢出，这些原因都是致命的。当数据没有按照正确的存储对齐方式拿出来后再进行合并操作就出现了错误。而像int型这种是存储类型的整数倍叫做自然对齐方式的就不会出现问题，而且执行效率较高。