GUI解决方案实训分成两个部分，第一个部分是熟悉STM32H7R7的烧录以及LVGL工程运行调试，第二个部分是对TouchGFX工程的运行调试及二次开发，可以看出来ST官方主要侧重对TouchGFX的推广及应用，但是我个人更喜欢LVGL，LVGL开发的自由度高，移植简单方便，可以在几乎任何带屏幕显示的平台上进行，几乎不受到硬件平台的RAM及FLASH限制（RAM最小4~8K即可运行），相对于TouchGFX的缺点是，缺少TouchGFX独有的炫酷屏幕切换特效，以及无法直接显示视频（需要通过动态显示图片帧的方式进行）。由于实训是以LVGL开始的，所以就先分享LVGL部分的内容，后续更新TouchGFX部分的内容。

0 m3 p! x- {, k- [! S+ b1 \
0 l  A% F8 W* l实验平台为正点原子STM32H7R7开发板，并配套7寸800*480液晶屏：
: r. J+ c6 a) L2 T/ d$ k

8 s" P6 i& c2 e
: h0 \  q# R, M0 w使用的下载器为STLINK V3紧凑型小下载器，即使是SWD模式下，烧写速率比起STLINK V2和JLINKV9都要快很多：

6 D" O5 f0 ?6 c) _" |2 R+ _/ p4 K
7 L: ~2 E2 W) ^5 z

将下载器以及屏幕连接到开发板，开始实训：
! e% \. _; x; k
9 w) Y6 g; S5 S8 d! v

LVGL咖啡机例程是CubeIDE工程，工程分为Boot和Application两个子工程，因为STM32H7R7 MCU是用内部FLASH引导外部FLASH APP运行的方式工作的，因此Boot子工程生成在内部FLASH运行的Bootloader，Application子工程生成在外部FLASH运行的APP，两者都需要烧录，都可以通过CubeProg进行烧录。将Boot工程和Application工程都在CubeIDE下编译完毕：


/ o% b  }9 }2 P2 {) ]& l将正点原子H7R7开发板的外部FLASH（MX25UM25645G_ATK-DNH7R7_HSLV_ExtMemLoader.stldr）烧录算法放到CubeProg目录相应的位置下，并移除跟此算法地址冲突的MT25TL01G_STM32H745I-DISCO.stldr即STM32H745Discovery官方开发板的算法：

7 v0 k% y. W0 |2 e7 x
% J; \% c" z4 h+ n
在CubeProg分别烧录STM32H7R7外部FLASH的APP及内部FLASH的Bootloader，先烧录外部FLASH的APP，APP所对应的HEX文件放在APP子工程的Release目录下：
. Z) h( g! ~+ {0 h) S: ~" Q' h
. Y/ v) G+ M! p& |$ J* S- _& _
/ \2 b& O! g8 o  O& B* X/ h0 a在EL选项卡中选择正确的烧录算法打勾：


: i8 K$ a* m* T连接MCU并烧录成功：
7 b! v6 W0 V6 N/ J  t

使用同样的方式烧录内部FLASH的Bootloader，烧录内部FLASH取消EL的打勾：
' ^; a, i# Q: ?$ q7 c& r
. }0 m9 H  t' [5 W
在16号当天实训的时候，程序是正常加载运行的，但是我分配到了一块疑似晶振有问题的次品开发板，在运行过程中会直接卡死，因此我跟正点原子的LVGL AE 袁工进行交流，在开发板咖啡机例程的btim定时器中断中加入一个闪灯动作来判断是否硬件问题：
$ ?2 n' l0 l4 s7 U

/ |+ \. Q8 h" z3 e! H运行结果是，出现卡死的时候，连btim定时器中断所加入的闪灯动作都停止了，那就可以判断跟软件没有任何关系，是硬件问题了，换了一块开发板之后一切正常。这个小插曲无伤大雅，更看出了正点原子企业对于排查客户硬件问题的认真态度，点赞！
: V+ H" f* k6 Y5 T* `. o/ Y1 V