void USART_SendData()函数在快速发送时存在问题 有丢数据的可能

转自https://blog.csdn.net/qq_27114397/article/details/50601548

STM32库函数void USART_SendData的缺陷和解决方法
使用USART_SendData()函数非连续发送单个字符是没有问题的;当连续发送字符时(两个字符间没有延时),就会发现发送缓冲区有溢出现象。若发送的数据量很小时,此时串口发送的只是最后一个字符,当发送数据量大时,就会导致发送的数据莫名其妙的丢失。

如:

for(TxCounter = 0;TxCounter < RxCounter; TxCounter++)

USART_SendData(USART1, RxBuffer[TxCounter]);

原因

此API函数不完善,函数体内部没有一个判断一个字符是否发送完毕的语句,而是把数据直接放入发送缓冲区,当连续发送数据时,由于发送移位寄存器的速度限制(与通信波特率有关),导致发送缓冲区的数据溢出,老的数据还未及时发送出去,新的数据又把发送缓冲区的老数据覆盖了。

解决方法(目前总结的两种方案)

方案1. 加入延时函数(下下策),不需要修改USART_SendData()函数

for(TxCounter = 0;TxCounter < RxCounter; TxCounter++)
{

USART_SendData(USART1, RxBuffer[TxCounter]);

DelayMS(2); //加入一个小的延时
}

方案2. 修改USART_SendData()函数,在其内部加入发送缓冲区的USART_FLAG_TXE状态检测语句,确保一个字符完全发送出去,才进行下一个字符的发送。

实现方法:每发送一个字符都检测状态寄存器,确保数据已经发送完毕。具体操作步骤如下所示。

修改前的函数定义体

void USART_SendData(USART_TypeDef* USARTx, u16 Data)

{

assert_param(IS_USART_ALL_PERIPH(USARTx));

assert_param(IS_USART_DATA(Data));

USARTx->DR = (Data & (u16)0x01FF);

}

修改后的函数定义体

void USART_SendData(USART_TypeDef* USARTx, u16 Data)

{

assert_param(IS_USART_ALL_PERIPH(USARTx));

assert_param(IS_USART_DATA(Data));

USARTx->DR = (Data & (u16)0x01FF);

while(USART_GetFlagStatus(USARTx, USART_FLAG_TXE) == RESET){} //等待发送缓冲区空才能发送下一个字符

}

方案3. 不修改原来的库函数,在每一个字符发送后检测状态位。

USART_SendData(USART1, RxBuffer[TxCounter]);

while(USART_GetFlagStatus(USARTx, USART_FLAG_TXE) == RESET){} //等待发送缓冲区空才能发送下一个字符

ST这么做的原因是:使用发送中断功能。

STM32库函数void USART_SendData的缺陷和解决方法的更多相关文章

  1. Android开发中怎样用多进程、用多进程的好处、多进程的缺陷、解决方法(转)

    转自:http://blog.csdn.net/spencer_hale/article/details/54968092 1.怎样用多进程 Android多进程概念:一般情况下,一个应用程序就是一个 ...

  2. AsyncTask的缺陷以及解决方法

    1.AsyncTask常用于进行耗时操作,完成后更新主线程的UI. 2.缺陷:AsyncTask中维护着一个长度为128的线程池,同时可以执行5个工作线程,还有一个缓冲队列,当线程池中已有128个线程 ...

  3. STM32串口DMA接收数据错位——暴力解决方法

    背景:两片STM32通过串口通信,为了减小CPU负担,采用DMA进行通信,发送端为STM32F103C8T6,接收端为STM32F407VET6.在调试的过程中发现,一直出现数据错位的问题,接收端尝试 ...

  4. HttpURLConnection的流式输出的缺陷和解决方法

    转自:http://www.mzone.cc/article/198.html 最近在用applet写文件上传控件的时候发现使用URLConnection来对服务器进行流式输出时的一些问题.我们通常要 ...

  5. STM32库函数编程、Keli/MDK、stm32f103zet6

    catalogue . Cortex-M3地址空间 . 基于标准外设库的软件开发 . 基于固件库实现串口输出(发送)程序 . 红外接收实验 . 深入分析流水灯例程 . GPIO再举例之按键实验 . 串 ...

  6. STM32库函数开发使用总结

    一.外设常具备的几类寄存器 控制寄存器xxx_CR (Control/Configuration Register): 用来配置.控制响应外设的工作方式,如GPIOx_CRL.AFIO_EXTICR1 ...

  7. 如何快速上手使用STM32库函数

    一.背景 如前文所述,利用标准库函数的好处在于,可以快速开发,不用去对着数据手册,小心翼翼的一位一位的配置那些繁复的寄存器,因为这些工作意法半导体已经找了一些顶级的工程师帮你做了,杰作既是其库函数.当 ...

  8. STM32库函数实现方法

    一.概述 1.调用STM32库函数配置与直接配置寄存器 ① 直接配置寄存器 使用过51单片机的朋友都知道为了将IO口配置成某种特殊功能或者配置中断控制,我们先将需要如下步骤: 根据需要配置功能计算值- ...

  9. 龙邱STM32单片机用J-LINK下载无法被识别的解决方法

    问题如下: 按照正常步骤使用keil5给龙邱的stm32下载程序,SWD下载方式提示no cortex-m sw device found,JTAG方式提示no cortex-m device fou ...

随机推荐

  1. [LeetCode] 18. 四数之和

    题目链接:https://leetcode-cn.com/problems/4sum/ 题目描述: 给定一个包含 n 个整数的数组 nums 和一个目标值 target,判断 nums 中是否存在四个 ...

  2. C# web项目利用docx文档作为模板~为打印专做的解决方案

    还是那句话:十年河东,十年河西,莫欺少年穷. 目前,web端打印技术有很多,有收费的专业web打印控件,大家可以参考我的上一篇博客.当然,很多公司不愿意出钱,那么今天咱们就探讨下怎么做免费的打印. w ...

  3. python官网几个下载文件的区别

    进入python官方,下载python编译器,提供了如下几个版本进行选择,这些版本分别是什么意思呢? Python 3.7.1 - 2018-10-20 Download Windows x86 we ...

  4. 类 Random

    什么是Random类 此类的实例用于生成伪随机数 Random使用步骤 查看类 java.util.Random :该类需要 import导入使后使用. 查看构造方法 public Random() ...

  5. Python----Kernel SVM

    什么是kernel Kernel的其实就是将向量feature转换与点积运算合并后的运算,如下, 概念上很简单,但是并不是所有的feature转换函数都有kernel的特性. 常见kernel 常见k ...

  6. Tomcat配置实例

    转自:https://www.cnblogs.com/kismetv/p/7228274.html 目录 一.一个server.xml配置实例 二.server.xml文档的元素分类和整体结构 1.整 ...

  7. PHP开发高可用高安全App后端

    基于thinkphp5开发的APP,涵盖阿里大于,七牛云图片上传,RestfulApi,短信验证, 需要联系我:QQ:1844912514

  8. IntellIJ IDEA 配置 Maven 以及 修改 默认 Repository

    转自:IntellIJ IDEA 配置 Maven 以及 修改 默认 Repository 今天将IntellIJ IDEA 关于Maven的配置总结一下,方便以后可参考. IDEA版本: Intel ...

  9. 熟悉常用的HDFS操作

    编程实现以下指定功能,并利用Hadoop提供的Shell命令完成相同任务: 在本地Linux文件系统的“/home/hadoop/”目录下创建一个文件txt,里面可以随意输入一些单词. 在本地查看文件 ...

  10. codeforces510D

    Fox And Jumping CodeForces - 510D Fox Ciel is playing a game. In this game there is an infinite long ...