1
调试上位机的必要性
做嵌入式软件开发的朋友大部分时间都在跟底层驱动打交道，也基本上都是一些逻辑、算法或者策略等等。
而一款与用户打交道的产品，为了更加直观和方便的给用户使用，基本上都离不开人机交互，像手持移动设备，往往都会有LCD等屏幕显示；工控行业的大型设备，一般都会与PC端桌面软件结合，也就是常说的上位机。
然而这样的上位机涉及到桌面UI、数据库等等相关的技术知识，所以这样的项目至少也会有两拨人来共同开发，上位机和下位机。
我们知道在嵌入式软件开发的前期都离不开各种仿真器，如果是嵌入式Linux会有比较成熟的终端或者调试手段那就不在这里讨论了。
对于下位机部分基本都会采用仿真器来进行调试，相关驱动和环境部署好以后，就开始进行功能和算法的调试，在该过程中经常涉及到参数的整定、模式的切换、数据的采集获取、以及问题的定位，急需要一个更方便的动态方式来实现这些功能，那就借助调试上位机吧。
调试上位机功能相对比较简单，主要就数据显示和参数下发，如果你想做得强大一点，可以做一些数据采集变换处理等等。
然而大部分上位机的同事没有太多的精力帮忙开发这样一个调试上位机，又或者并不是太符合自己的调试需求，甚至还要经常修改。
那就只能自给自足了，自己写上位机，所以项目实战经验多一点嵌入式工程师多多少少能够做一些桌面应用，比如用QT、C#等等。
很多嵌入式工程师招聘的时候，能够懂一些PC端的桌面应用的开发，也是一项加分项，能够比较方便高效的进行下位机软件开发。
2
问题所在与改善
然而bug菌发现非常多项目的调试上位机千奇百怪，今天工程师A调试平台开发了一个上位机，然而过一段时间交接给工程师B来维护，又出现一个新的调试上位机，导致软件杂乱无章，能够写点桌面应用确实是一种能力的体现，但不对软件加以管束，只会对项目带来诸多的后遗症。
下面谈谈一些看法:
1、不要本末倒置
之前看到一个同事对自己的调试上位机非常的在意，弄了各种UI美化等等，可是下位机软件写得一团糟。也能理解，每个人对赏心悦目的东西都会有一定的追求，但软件的本质都是一样的，更何况调试上位机的定位并不是给用户去使用，仅仅只是一种更加形象的表现嵌入式软件的方式。
所以对于嵌入式工程师真的没有必要花太多的时间把专注点放在这个上面，而是应花更多的精力对下位机的逻辑、算法进行优化，增强其冗余性和稳定性。
话说回来如果项目下位机的软件功能很简单，程序一烧录一把搞定，那真的就没啥可提升的了，倒可以根据自己所要发展得方向来学习。
2、和用户上位机集成
调试和用户上位机并没有什么区别，完全可以统一管理发布，只是非常多的软件项目负责人并没有权衡到系统的各个方面，当然也有做得不错的，比如非常多的软件都有两种管理模式，一种是用户模式，一种是开发者模式，可以通过设置密码来进行使用模式切换。
专门的人做专门的事情，毕竟做上位机的同事对桌面应用的开发还是相对比较擅长的，只是对相关的调试需求并不是很熟悉，此时相应的嵌入式工程师应该把相应的需求整理设计清楚。
整合成一个上位机，一方面能够进行较好的版本管控和功能的迭代。也不会经常出现到了现场解决问题忘记带调试上位机，又或者售后人员经常找你拿调试上位机等等麻烦。
3、功能定位
调试上位机，主要还是用于排查和定位问题。所以与调试上位机相关的交互和设计在下位机软件中不要杂糅在一起，以前同事负责一个项目，到客户现场经常出现问题，而在实验室却怎么也复现不了，后来对比发现在实验室他一直挂着调试上位机，因为调试上位机有定时发一些数据，导致现场不一致。
所以一定要对调试部分功能上定位好，其主要功能就两部分，一方面是查看下位机运行的状态；另外一方面就是可以下发一些数据用于调试参数等等，也可以做一些更强的功能，比如波形分析等等，但都大同小异吧。
在用户上位机正常运行的过程中，调试上位机依然能够正常获取状态和参数下发，所以不要有两个上位机只能有一个在线的互斥设计。
这样黑箱子一样的下位机状态全部在调试界面暴露出来了，也基本没有什么bug能逃得出你的监视，相当于一个在线仿真器。
电子技术干货，第一时间送达
220V灯串电路原理原来是这样的！
国产MCU，王牌对王牌
电视机的按键功能是用什么电路实现的？经典ADC按键电路
小小的电蚊拍居然有这么多个基础电路，你能看懂几个？
220V灯串电路原理原来是这样的！
别小看不起眼的电阻，里面大有学问！
