This thread has been locked.
If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.
工具/软件:Code Composer Studio
您好!
附件是一小段代码、应通过串行链路将电路板数据发送到 PC。 但是、我的 PC 上没有接收到任何内容。
此外、当我在调试模式下检查 UART0_DR 寄存器时、数据位为空。 PuTTY 的设置与电路板中的设置相同(9600、8、1、无)。
#include
#include
#include "C:\ti\TivaWare_C_Series-2.1.4.178\inc\hw_memmap.h"
#include "C:\ti\TivaWare_C_Series-2.1.4.178\inc\hw_types.h"
#include "C:\ti\TivaWare_C_Series-2.1.4.178\driverlib\sysctl.h"
#include "C:\ti\TivaWare_C_Series-2.1.4.178\driverlib\gpio.h"
#include "C:\ti\TivaWare_C_Series-2.1.4.178\inc\tm4c1294ncpdt.h"
空 delayM(int a);
空 UART0Tx (char c);
int main (空)
{
//SysCtlClockFreqSet ((SYSCTL_XTAL_25MHz | SYSCTL_OSC_main | SYSCTL_USE_PLL | SYSCTL_CFG_VCO_480)、120000000);
SYSCTL_RCGCUART_R|=0x01;
while (((SYSCTL_PRUART_R & 0x01)!= 0x01){};
UART0_CTL_R&=~(0x00000000);
UART0_IBRD_R=104;
UART0_FBRD_R=11;
UART0_LCRH_R=0x60;
UART0_CC_R=0x00;
UART0_CTL_R=0X301;
SYSCTL_RCGCGPIO_R=0x01;
while (((SYSCTL_PRGPIO_R & 0x01)!= 0x01){};
//GPIO_PORta_AHB_AMSEL_R=0x00;
GPIO_Porta_AHB_PCTL_R=0X11;
GPIO_PORta_AHB_AFSEL_R|=0x03;
GPIO_PORta_AHB_DEN_R=0x03;
//delayM(1);
while (1)
{
UART0Tx ('t');
UART0Tx ('e');
UART0Tx ("S");
UART0Tx ('t');
UART0Tx ('');
}
}
空 delayM(int n)
{
int i、j;
for (i=0;<n;i++))
{
for (j=0;j<3180;j++)
{
;
}
}
}
空 UART0Tx (char c)
{
while (((UART0_FR_R & 0x80)!= 0x80){};
UART0_DR_R=c;
delayM(10);
}
有人有线索吗?
此致
[引用 user="peter_mm_2018"]是否有任何线索?
确实——但你不会高兴的!
很明显、您被"命令"使用(仅限于)"DRM"型编码、这种编码方式虽然声称 具有"重要的 MCU 理解"、但通常会导致海报降落在这里、无法获得"最基本的功能"来执行! 赦免-但这种(被称为)"高级理解"发生的时间和地点是什么时候? 为什么-您这么多(强制) DRM 研究人员经常失败?
您"将自己从"更成功-并实现"API 群"中大量化、方法是将 代码转换为过时的、延迟的形式、并(始终)经过最小测试(如果完全)的 DRM 类型。
该 API 已成功应用数千种 API -经证明是强大且广泛的-并可与 MCU 手册配合使用-以提供"出色的寄存器行为检查和探测!" (DRM 支持者从未/曾经-甚至"暗示"!)
供应商的 API 中存在多个 UART 示例-这些示例是:经过验证的、良好的注释、并且(大多数情况下)完全避免了"痛苦的缺陷结果"-您和(许多其他)"DRM"用户(定期/可预测)遭受痛苦!
您的"切换到 API"可能会证明是有效/有价值的"线索?" (许多 (对效率和成就感兴趣)认为、"就是这样!")
只有当你发现我的"UCLA 定律"逻辑-有点令人信服时。
情况是否不是(压倒性的)-赞成 API? 如果是这样,"这一解决办法"证明是非常恰当的。"
您将注意到、大多数供应商代理(也是)都不鼓励使用此类"过时方法"。 他们吃时间和精力-什么?
比赛是"对环球银行间金融电信协会(SWIFT)"、而不是过于复杂、其中任何/所有"附加学习"都证明 不支持(也不会接近)成为现实...
这是一种"过于宽泛"和"过于乐观"的说法----系列的说法----是不是吗?
您可能会注意到、"远远优于"的方法-能够(真正)实现两个目标-已经存在。
"困难和乏味"当然是一致的-"回报是伟大的"-基于他们的时间和努力投资-不是太多! 值得高度注意的是、任何/所有 "声称 的"DRM"优势-都(始终)以如此模糊(和不可测量)的术语"掩蔽"! 为什么是这样? 什么奖励? 什么证明"很好?" (超乎想象!)
遗憾的是、我(相当详细)的建议未能获得接受的"线索"状态。 (可能(有些)公平(甚至诚实)(也有)、"在岩石上降落了 DRM 代码?)