Forums

LPC2214实时更改BAUD汇率

开始于 ARK48 4 years ago9回复最新回复4年前173浏览
我将LPC2214(#LPC2200)用作我们其中一个控制器板上的控制器。通常,我们使用115200波特进行通信,这对于我们的应用程序来说已经足够了。现在,我们正在尝试将该波特率即时更改为460800,以便我们可以更快地将数据下载到它。为此,我们首先向控制器发送命令,由它解释并更改波特率。然后,在重新发送命令以将波特率重新设置为115200之前,我们可以以更高的速度发送数据。对于波特率的有限更改,代码运行得很好。但是,在第8次尝试更改波特率时,处理器挂起了...或者我实际上与之失去了通信。查看中断,已设置THRE。您能指点我一个可以帮助我的方向吗?
[-]
回覆者 乔里克一月11,2017

我对LPC2214不熟悉,但是我确实使用LPC17xx / LPC40xx系列,因此我将在此基础上给我2美分。恩智浦喜欢在其处理器系列中重用功能。

1.确保UART空闲。什么也没收到,并且发送器和发送保持寄存器为空。

2.更改波特率时禁用中断。所有中断,而不仅仅是UART。您希望快速切换而不会在中间被打断,并且切换时间不长。

在LPC17xx上,波特率除数寄存器与Tx / Rx缓冲区和中断使能寄存器共享。如果在UART处于活动状态时切换到波特率除数寄存器,则可能会造成混乱。最低波特率将更改为随机值,否则中断将消失。

[-]
回覆者 ARK48一月11,2017

感谢您的及时回应。通过事先禁用所有中断并在设置波特率后重新启用,系统可以完美运行。再次感谢....

[-]
回覆者 蒂姆·韦斯科特一月11,2017

我可能在这里宣讲合唱团,但是在尽可能短的时间内禁用中断,并以一种安全的中断方式进行操作(意味着,保存中断状态,禁用然后恢复-如果中断,则以这种方式已被禁用,您将不会在不适当的时候启用它们)。长时间禁用中断只会增加所有情况下最坏情况的中断响应时间。

如果问题是由竞争状况引起的,那么禁用中断只会缩小问题机会的窗口,而不会关闭问题的机会。这可能会导致交换机每千次(甚至随机地)一次禁用串行,而不是每次都禁用第八次。反过来,这意味着您已经将工程实验室中的问题变成了定时炸弹,可能在制造过程中甚至在客户面前都无法解决。

如果是我,禁用该端口,然后更改波特率,然后启用该端口,会更加安全。这并非直接基于您对芯片的任何经验,而只是一般的好习惯(或偏执狂)。

[-]
回覆者 乔里克一月12,2017

以下是我用于设置波特率的代码,该代码位于中断保存和禁用与启用代码之间。这是我的编译器的(修改后的)输出,用于优化空间。汇编器行以反斜杠开头,反斜杠之后的数字是指令执行所需的时钟周期数,取自ARM Infocenter的文档。在120 MHz时,一个时钟为LPC1788的8.33 nS。

总时间为9个时钟,即75 nS,对于几乎所有应用而言,这应该足够短。当然,如果您有一个需要精确中断定时的实时应用程序,则可能需要按照Tim Wescott的要求禁用UART。

注:位带用于允许更快地访问包含位的UART寄存器。

   xptUARTBit->sauwLineControl [UART__LC_DIVISOR_ACCESS] = YES;  // Bit-band
        \ 1   MOVS     R1,#+1
        \ 1   STR      R1,[R8, #+412]
   xptUART->suwBaudRateDivisorMSB = Byte1 (zuwDivisor);
        \ 1   LSLS     R1,R4,#+16
        \ 1   LSRS     R1,R1,#+24
        \ 1   STR      R1,[R7, #+4]
   xptUART->suwBaudRateDivisorLSB = Byte0 (zuwDivisor);
        \ 1   UXTB     R4,R4
        \ 1   STR      R4,[R7, #+0]
   xptUARTBit->sauwLineControl [UART__LC_DIVISOR_ACCESS] = NO;  // Bit-band
        \ 1   MOVS     R1,#+0
        \ 1   STR      R1,[R8, #+412]

[-]
回覆者 蒂姆·韦斯科特一月12,2017

>总时间为9个时钟,即75 nS,对于几乎所有应用而言,这应该足够短。

足够短,不会弄乱其他东西,是的-但是,如果使UART短路的Bad Thing是硬件事件,而不是软件事件的某些冲突,那么这只会使问题发生的频率降低,不会使它消失。

我曾在小组工作过,在那里,我们不太出色的软件工程师会意识到,他们可以通过禁用大块代码周围的中断来解决问题,而无需注意事实是他们制造的问题比他们要解决的要多,因此任何人都可以谈论禁用中断的问题,我不得不指出,您想保留时间SHORT。

[-]
回覆者 乔里克一月12,2017

我也去过那里我下面有一位软件工程师,他将中断加倍,甚至试图在中断中进行SPI事务。幸运的是他不再在这里工作。另一位工程师想要手工完成所有软件构建,并在删除我们所有的构建脚本时设法将自己开除。

通常情况下,我不会在禁止中断的区域中添加更改波特率之类的内容,但是NXP设备除了以某种方式禁用中断外没有关闭UART的方法。禁用UART的中断分为三种级别:

1)从全球来看,如上所述。即使在Debug节点中,代码也很短。

2)在NVIC中禁用UART中断。与#1相比,它涉及更多的工作,并且需要花费更多的时间,因为在重新启用中断之前应清除挂起的中断(NXP UART倾向于在使用此方法启用时触发虚假中断)。至少它不会影响系统中的其他中断,但可能会稍微减慢通信速度。

3)禁用三个UART中断(THRE,RDA和RXIE)。这比#1或#2涉及更多,如果在禁用或启用过程中触发UART中断,则可能是一个实际问题。这些中断应仅由UART处理程序使用,而不能由外部调用程序触及。

因此,我选择提及全局方法,因为代码非常短,除了对时间敏感的应用程序外,不会影响应用程序。

如果这是导致不良事件的硬件事件,则需要进行大量测试以清除故障。在我工作的地方,我们整夜(最少)至一个星期(典型)测试通讯,以确保没有问题。希望OP也能进行广泛的测试。

注意:``我在上一篇文章中提到禁用UART,但是在我发布帖子之后,我才意识到不能真正禁用UART,因此提示了这篇文章。

[-]
回覆者 帕维尔克一月11,2017

如果一切正常,但总是8次,那么对我来说,这听起来像是软件错误。如果您尝试不以快速模式发送所有数据,而只是说10个字节,然后切换,该怎么办?还是8次,还是可以做更多呢?

[-]
回覆者 ARK48一月11,2017

感谢您的及时答复,我已经整理好了。见下文。

[-]
回覆者 凯夫波一月11,2017

除了其他答案外,我还补充说,问题可能出在串行链接的另一端,尤其是(但不是排他性的)如果它是基于Windows的系统。如果没有硬件握手,缓冲延迟和字符丢失将很常见。波特率越高,它越有可能咬你。通常,Windows系统会丢弃一个或多个字符,并且永远不会看到完整的回复消息。