迪文屏幕T5L平台学习笔记一：开发环境搭建注意事项

前面一直用T5UID3平台的屏幕开发，但是吐槽下《DWIN C Compiler 1》编译器bug太多，项目能不能做好，全靠运气；售后说T5L平台支持keil开发，我感觉挺好，于是从新学习T5L，现在把学习过程记录下来，希望能够帮助入门的人吧。

一、keil环境搭建

现在mdk5一个软件就可以支持开发ARM/C51/迪文，当然需要安装对应插件，所以我个人建议用MDK5开发即可，没必要用keil4了。

mdk5安装请看：MDK5安装破解以及安装stm32与C51支持包(附安装包)，

迪文插件安装请看：迪文屏幕T5L平台学习笔记零：KEIL环境搭建

具体安装过程不在详细叙述，这里说下注意点：

1、先安装MDK，再安装J-FLASH，后安装C51，再安装迪文插件；

2、mdk高版本增强了j-link防盗版检测功能，原来低版本下能够用的调试器，在高级版本下不能下载和仿真（注意：J-LINK仿真器不能用于开发迪文屏幕和C51，仅能用于ARM平台开发），解决方案是：

（1）删除Keil_v5\ARM\Segger文件夹下所有文件（目前我用的mdk v5.36）；

（2）把低版本Keil_v5\ARM\Segger文件夹下所有文件拷贝到高版本Segger文件夹下（目前我要用的MDK V5.23）；

（3）上述步骤操作完成，再安装JLink_Windows_*.exe软件（目前我用的 JLink_Windows_V754b_x86_64.exe），下面一定要选中，否则一些新MCU下载不支持。

注意：mdk需要安装对应的pack包，才有对应型号。

3、安装C51时候，下面一定选Skip，否则MDK开发ARM会有问题。

4、最后安装agdi_installation_dwin.exe，迪文C51开发插件，安装HME05_usbjtag_installer.exe，迪文调试器驱动。

安装完后，新建工程，有三个选项如下，则安装成功：

5、最新版的C51软件c51v960a.exe有个BUG（请看：KEIL/LX51: WARNING L48: IGNORED RECURSIVE CALL 解决办法_萤火虫的电子笔记-CSDN博客），LX51.exe是V4.66.97.0，需要升级为LX51.66.99.0，下载地址：Documentation – Arm Developer

升级前：

升级后：

6、中文乱码问题，请看：keil mdk中文乱码，两种解决方法，字体不再难看_自由的天空-CSDN博客_mdk 乱码

7、生产bin文件

我自己写了一个批处理文件，具有一下优点：

（1）自动寻找 Objects下的HEX文件；

（2）输出bin在bin文件夹，需要在工程文件夹下手动建立bin文件夹；

（3）输出bin文件名格式：T5L51_hex文件名字_当天日期.bin；

（4）需要把tools拷贝到自己的工程文件夹下；

（5）在USER RUN添加：.\tools\bin.bat


@Rem set varRootPath=%cd%
set varRootPath=%~dp0
set varCatToolPath=%varRootPath%\srec_cat.exe
set varCmpToolPath=%varRootPath%\srec_cmp.exe
set varInfoToolPath=%varRootPath%\srec_info.exe
set varCalculateToolPath=%varRootPath%\crc_calculate.exeset "year=%date:~0,4%"
set "month=%date:~5,2%"
set "day=%date:~8,2%"set "hour_ten=%time:~0,1%"
set "hour_one=%time:~1,1%"
set "minute=%time:~3,2%"
set "second=%time:~6,2%"set varScrAppFile=%varRootPath%\..\Objects\*.hexfor /f "delims=" %%a in ('dir /b /a-d /oN "%varScrAppFile%"') do if not defined d set d=%%~naset varOutProductionFile=%varRootPath%\..\bin\T5L51_%d%_%year%%month%%day%.bin@Rem set varOffset=-0x00010000@Rem Hex--->Bin
@Rem %varCatToolPath% %varSrcFile% -intel -o -hex-dump
@Rem %varCatToolPath% %varScrAppFile% -intel -offset %varOffset% -o %varOutProductionFile% -binary%varCatToolPath% %varScrAppFile% -intel -o %varOutProductionFile% -binary

对应资料下载地址：链接：https://pan.baidu.com/s/1FlZMbbWnzQQe_JVS9TIxqQ
提取码：urzp

二、T5L开发

1、根据屏幕型号，首先看基本参数，我的屏幕型号DMG80480C070_03WTC：

两个重要参数：分辨率800*480，电源5V/500ma

DGUS开发软件：

V7.618
此版本只适用于T5L（生成icl文件的需要配套GUI内核V36以下版本，
若使用V40的内核请使用V7.623PC软件生成.icl文件，否则会造成显示异常黑屏，可重新用sd卡插卡下载对应的icl或内核文件恢复）
主要增加功能：
(1)、优化文本显示预览功能；
(2)、修正一些已知bug

V7.623
(1)、优化icl工具；（能兼容各版本内核平台）
(2)、修复icl预览不显示问题

注：为了更好的兼容中英文版本demo，以上版本之后的生成的13 14*.bin文件都为英文命名

如果是V40内核，请用 V7.622及以上版本，迪文官网是V7.622，论坛是V7.624（【PC软件】DGUS ToolV7.624（T5L ASIC平台 DGUSII开发模式）），高版本兼容低版本。这里我用的V7.624。

内核更新地址：T5L_DGUSII内核固件升级20211216

注意：不要用V45内核，我用V45白屏，用V36或者V41都正常，把内核BIN拷贝到SD卡的DWIN_SET文件夹即可。

2、画图

我用的PS CS6，注意如下：

这里和T5平台有两个不同点：

（1）图片需要用PC工具生产ICL库，工具如下：

（2）ICL的序号需要在CFG文件的0x08处指定，即0x08处的值等于ICL序号；

注意：

1、没有改变的文件，下载一次即可，节省时间，如0号字库；

显示如下：

PS：有个问题就是汉字乱码，已经做了字库了，等问题解决了，再发上来。

<------------------------------------------------------------------------------------------------------------------------->

2021.12.21

今天把中文显示乱码问题解决了，记录下，希望能够帮助到你吧。

我想显示汉字或者温度符号“℃”，但是显示如上图所示，是乱码。查看手册，字库ID号没有说要在CFG文件配置，查看工程配置，把X=Y，或者2X=Y都是了不行，把文本显示控件高度>Y，全部是偶数，还是不行。用TS4软件测试字库，显示没有问题，这个是80*80的，难道不行，测试64*64的还是不行，哎心累。

百度了下，说C51编译器不支持0xFD，请看：Keil C51汉字内码0xfd BUG问题解决办法

原文如下：

关于keil C51编译时会将汉字（或者其他语言）的内码0xFD忽略掉的原因以及解决方法，基于版本的不断升级，晓奇工作室出来的那个打补丁软件已经难以成效了，当然可以通过手动搜索C51.exe，Cx51.exe(还有将A51.exe，Ax51.exe)中的80FBFD，改为80FBFF也是暂时可以解决这一问题，但是个人更倾向于使用keil官网的解释以及解决方法。

现摘录keil官网的解释以及解决方法（Documentation – Arm Developer），阐述如下：

GENERAL: COMPILER IGNORES 0XFD, 0XFE, 0XFF VALUES IN STRINGS

Information in this article applies to:

C166 Compiler All Versions

Cx51 Compiler All Versions
C251 Compiler All Versions

QUESTION

I have a problem with the interpretation of Russian strings in the Keil C51 compiler. Some Russian characters are using the encoding 0xFD. It looks like this encoding is ignored by the compiler and is not included in the program code.

Example:

code char RussianString[] = "??? ????";

Why does this problem exist and how can I avoid this behavior?

ANSWER

The character encodings 0xFD, 0xFE, and 0xFF are used internally by the C compiler. The ANSI standard only requires support for ASCII characters in the range 0x00 - 0x7F.

You may insert these characters by using HEX encodings in the string as follows:

code char RussianString[] = "My Text" "\xFD";

A simple text replacement which replaces all 0xFD characters with the string '" "\xFD' should do the job.

大体意思描述一下：0xFD, 0xFE, 和0xFF是作为C编译器的内部来用的，根据ANSI的标准，只需要支持0x00 - 0x7F即可。但是通过十六进制编码（转义字符\x表示）方式来进行字符串处理之后，那么字符串中所有的0xFD就会被字符串'" "\xFD'来代替了。

但是我看了下我的编码号“℃”是0xA1E6，测试了下write_dgusii_vp(0x1000,"0.\xA1\xE6\0",5);还是乱码。

今天无意间看了下字库测试，发现“℃”在测试字库里面不是0xA1E6，是0x8140，难道是因为这个？于是测试write_dgusii_vp(0x1000,"0.\x81\x40\0",5);显示正常了。这是为什么？

我又生成了一遍字库，步骤如下：

1、首先配置好字体大小和点阵大小，我的配置如下：

2、由于我就要几个汉字，所以勾选小字库，点击创建，输入要用得字库，这里测试我就随便写了

3、点击确定，就生成我们要的字库了，注意字库的ID可以随便改，这里写24。

4、用TS4的字库测试功能测试下字库，注意可能第一次打开字库，设置大小、编码格式，点击显示后，没有显示，关闭字库测试，再次打开，点击显示就可以了。

看到没有，℃符号的码号=0x8140，那么为什么是0x8140呢？因为我们的字库是从整个GBK字库中截取了像素，那么位置就从新排序了，0x8140是码号开始的第一个位置。那么其他的软件是不是这样呢？我用字库生成器.exe测试了下，配置好字体编码和大小后，由于℃=0xA1E6，那么我就生成从0xA1E0-0xA1E7

生成后，用TS4测试下，如果0xA1E0变成了0x8140，那么℃=0x8146

果然，码号变了，到此汉字乱码问题解决，说下DGUS Tool V7.624.exe显示汉字一个注意点，就是字体大小设置时候X=Y，不能2X=Y（显示汉字乱码），并且FONT1_ID=字体号；如果是ASCII码，X=Y或者2X=Y都可以。

再说一个小技巧，汉字显示可以在最后加“\0”表示字符串结尾。

我个人感觉感觉还是TS4的小字库好用，可以把我们想用的汉字任意组合；字库生成器.exe只能截取某个字库段，浪费空间。