关于数据手册里对0xFD问题的建议
<p>在数据手册里，关于Keil的0xFD问题的章节，解决FD问题，只给出了官方提供的在问题字符后面添加 “\xFD”的方法，以及列出了问题汉字的清单。</p><p>虽然可以解决问题，但是每次按照清单逐一比对，过程比较麻烦。</p>
<p>在AIapp-ISP里的文字生成工具里，有个更贴心的【自动修补】功能。<img alt="qiang" class="emoji" src="https://www.stcaimcu.com/static/image/smiley/default/qiang.gif" title="qiang" /></p>
<p>因为如果在屏幕程序里需要输入汉字等字符，通常都会伴有先取模的过程；如果用的是字库芯片，把字符串一股脑放进去，也可以瞬间直观看到是哪个字符出的问题。</p>
<p>所以个人建议，既然是STC官方的数据手册，应该把这个独有的、更好用的方法，也介绍进去。一方面是更好推广自己的软件，更重要的是这个功能的确可以大大减轻查找问题字符时的工作量。</p>
<p>（关于解决0xFD问题，搜遍论坛都没有提及这个方法的内容）</p>
<p><img src="data/attachment/forum/202412/09/102605y7xl777ipei7clel.png" alt="image.png" title="image.png" /></p>
<p><img src="data/attachment/forum/202412/09/102732kq30mtscodvveuvs.png" alt="image.png" title="image.png" /></p>
<p>////////////////////////////////////////////////////////////////////////////////////////</p>
<p>顺便，手册里给出了GB2312编码里的所有问题汉字的清单</p>
<p>根据编码表，还有两个全角字符的八位，也是FD：</p>
<p>向下箭头 "↓"，和右大括号 "<strong>｝"</strong></p>
<p>也是比较常用的字符，可以补充进问题字符的清单里。</p>
<p>因为在实际使用中，不论是自己取模，还是用带字库的ST7920的LCD12864（包含的是GB2312字库），也会遇到同样的问题。</p>
<p><img src="data/attachment/forum/202412/09/104302yeawt89qgw83q39w.png" alt="image.png" title="image.png" /></p>
<p><img src="data/attachment/forum/202412/09/104359h11c1dm182dhw828.png" alt="image.png" title="image.png" /></p>
<p>////////////////////////////////////////////////////////////////////////////////////////</p>
<p>令外感觉有意思的是，虽然官方解释是字符编码0xFD、0xFE和0xFF由C编译器内部使用，但是实际只有编码低八位是 FD 的字符不正常，而 FE 的却没有影响。<img alt="xieyanxiao" class="emoji" src="https://www.stcaimcu.com/static/image/smiley/default/xieyanxiao.gif" title="xieyanxiao" /></p>
<p><img src="data/attachment/forum/202412/09/104819tiovsnqoqnus8zaq.png" alt="image.png" title="image.png" /></p>
<p>到不如建议一下官方 点阵和字体宽度别限制这么死。。。32有点儿小了，，</p>
还不知道有这功能啊，真贴心啊 <p>对OLED屏幕来说32还好，但是对于分辨率更高的TFT屏幕，32确实有点儿不大够用。<br />
这个在之前的帖子里也建议过，当时好像说的是需要开更大缓存，最后折中到了32。</p>
<p>好在还有其它取模工具当替补，就没再继续纠结这个问题。</p>
soma 发表于 2024-12-9 11:24
还不知道有这功能啊，真贴心啊
<p>对啊<img alt="jingya" class="emoji" src="https://www.stcaimcu.com/static/image/smiley/default/jingya.gif" title="jingya" /> 这个功能很早就藏在文字工具里了，一直这么低调，太可惜了</p>
网页卡了，发重复了 大明狐 发表于 2024-12-9 11:31
对OLED屏幕来说32还好，但是对于分辨率更高的TFT屏幕，32确实有点儿不大够用。
这个在之前的帖子里也建议过 ...
问题就在这里了，市面上一直都是存在同类型的工具，，只要STC这里能涵盖其他工具的功能，并且能优化那些工具的操作，那绝对吹爆了，可实际上看起来挺好的，，真正用起来又差点儿意思。就很难受。纠结难受就在这里了。。那你说如果还需要其他工具来补充，那我为什么不直接用其他工具呢？
果真是专业的事情让专业的来。。。 对于显示乱码的字符,自动添加了0xFD,多了个字符,明显产生了不对齐问题,初始化的数据比没有乱码的字符多了个字节,显示的时候为什么都没有影响呢,我还真不知道是什么原因
struct FONT_DATA
{
char txt;
unsigned char dat;
};
struct FONT_DATA code Font_Data[] =
{
"数\xFD",0x10,0x40,0x92,0x40,0x54,0x40,0xfe,0x78,0x38,0x90,0x54,0x90,0x93,0x50,0x20,0x50, /* 0 */
0xfc,0x50,0x24,0x50,0x64,0x20,0x18,0x20,0x34,0x50,0xc2,0x88,
}; bkeuqoaq 发表于 2024-12-9 13:50
对于显示乱码的字符,自动添加了0xFD,多了个字符,明显产生了不对齐问题,初始化的数据比没有乱码的字符多了个 ...
<p>这个就是C51和C251版的Keil里的0xFD问题，STC数据手册里有解释</p>
<p>这是Keil官方的解释 https://developer.arm.com/documentation/ka004187/</p>
<p><img src="data/attachment/forum/202412/09/144339pjbq1g7p3ppp7iqq.png" alt="image.png" title="image.png" /></p>
大明狐 发表于 2024-12-9 14:47
这个就是C51和C251版的Keil里的0xFD问题，STC数据手册里有解释
这是Keil官方的解释 https://developer.ar ...
自己编译一下看反汇编明白了,谢谢!
页:
[1]
2