我目前正在ATMega1284p上编写uart-console。它应该回显字符，以便计算机侧控制台实际上可以看到正在键入的内容。
这是问题所在:使用ASCII可以正常工作，但是如果我发送的内容超出了ASCII，例如我的小型通信设备中的“§”表示无效。如果一切正常，则“§”无效。但是将两者结合起来会使我失望，而且我目前不知道问题出在哪里!
这是我的代码的一部分:
char c;
while(m_uart->recv(c) > 0) {
m_lineBuff[m_lineIndex++] = c;
if(c == '\r') {
c = '\n';
m_lineBuff[m_lineIndex++] = c;
m_sendCount = 2;
} else {
m_sendCount = 1;
}
this->send();
if(c == '\n') {
m_lineBuff[m_lineIndex++] = '\0';
// invoke some callbacks that handle the line at some point
m_lineIndex = 0;
}
}
m_lineBuff是chars的自写(和测试) vector 。 m_uart是用于微型内部硬件uart的自编写(也经过测试)的UART驱动程序。 this->send使用m_sendCount发送m_uart字节。到目前为止我尝试过的是:
我验证了minicom的波特率和我的微型匹配(115200)。我验证了频率在2％的范围内(微型计算机以20MHz运行)。 minicom和micro均设置为8n1。
我通过将minicom钩到我躺在的小板上来验证minicom的工作原理。在该板上任何utf-8数字都可以正常工作。
有人看到我的错误吗，或者有人对我没有考虑的事情有所了解吗？
如果您对我的代码感兴趣，我将很乐意提供。
编辑/阐述:
观察1(开始此项目之前)
PC端程序(minicom)可以发送和接收要响应的字符。从微 Controller 。但是它不显示发送的字符。
结论1(开始此项目之前)
微 Controller 端需要将字符发送回PC，以便您具有控制台的行为。
因此，我立即将收到的任何字符发回。
观察2(实现后)
当我按下“§”(或由1个以上字节组成的任何其他字符)(使用minicom)时，我会看到“·§”。
结论2(实现后)
我无法用我的知识解释的事情正在发生。也许在组成字符的两个字节之间存在很小的延迟会导致minicom首先打印一个'。'，因为第一个字节本身确实是一个无效字符，而当第二个字符出现时minicom意识到它实际上是'§'，但是minicom不会删除/覆盖'。'
如果那是问题，那么我该如何解决？我的微 Controller 是否需要更快地响应/字符之间的延迟更少？
编辑2:
我替换了“？”使用复制和粘贴的功能将其与实际字符'。'
我做了更多测试
我尝试使用字符“😹”，然后扩展(它支持我的结论2)，我得到了“���😹”。顺便说一句，“😹”是一个4字节字符。
将micro和minicom的波特率设置为9600:行为完全相同。
我设法将minicom设置为十六进制模式:它定期发送但输出十六进制...当我发送'😹'时，我得到“f0 9f 98 b9”，这是正确的(至少根据this site而言)...这是否支持我的结论2？更重要的是:我如何摆脱这种行为。它适用于我的小linux板而不是我的micro板。
最佳答案
tl; dr:您的PC应用程序可能无法正确解释显示的UTF-8。
如果我们看一下ISO 8859-1定义的扩展ASCII码，
根据此page，§的UTF-8编码为
因此，我对进行的有根据的猜测是，该符号仍正确打印，因为它属于具有相同值a7的扩展ASCII代码。
您的最终应用程序无法正确解释UTF-8 U(c2)符号，这就是为什么会得到一个？打印出来，或者中间的组件无法正确传递正确的值。我倾向于相信您的输出是第一种情况的实例。
您声称 minicom 有效，但我无法反驳此主张，但建议您先尝试以下方法:
注意::这是一个不完整的答案，但是我无法在注释中得到所有内容。如果您足够耐心，请使用您的发现更新您的问题，并评论此答案以通知我。我会回到这里，并据此更新答案。
关于c++ - 在微 Controller 上编写UART控制台时出现UTF-8问题，我们在Stack Overflow上找到一个类似的问题：https://stackoverflow.com/questions/36551036/