追究编程语言和框架，不如追究软件结构。语言用什么都搞得定，甚至这个需求（只要不是在Windows下）用Shell脚本都搞得定。但软件结构如果出了问题，就会变成什么语言都救不了。

两个要点，不听从就是开发失败：

• 必须分解需求，绝对不要把所有的任务用同一个程序做出来。
• 尽可能异步传输，程序之间尽量在运行上互不影响，只体现数据交换的关系。不到万不得已，不要让多个程序之间发生“假设”、“等待”、“干扰”甚至是“探测”、“监视”等，影响程序运行本身的行为。

首先把PC-MCU的通信单做一个程序（daemon）。从MCU收到数据时存入缓冲队列。不收数据时处理其他程序要求执行的指令，择机发送给MCU。

其次处理数据并存入数据库的再单做一个程序（daemon）。把通信程序的数据缓冲队列处理消化掉，送入本地数据库或数据库服务器永久存档。

Web服务器（很有可能是网上的虚拟主机吧？）向移动端提供Web界面和数据库服务。其实看你的需求，可以考虑Web服务器把数据库服务完全承担下来，本地就不再做数据库了。但是Web服务器向上位机PC推送数据很有可能是不畅通的（首先推送就不好做，其次PC很有可能没有外网IP不能直接访问到），这是一个问题。

所以这时上位机上就又要再做一个监视程序（daemon），监视移动端是否送入了新的指令。则此时移动端下达指令的行为，仅仅是把指令送到Web服务器暂存，等待上位机发现此指令后实际处理。

至于PC的操作程序就随意了，该做什么做什么就行。反正在这种结构下，上位机程序几乎不承担实质工作，只是把用户的指令交给各个守护进程去协调执行。java编写桌面程序已经够强力了。如果你仍然不满意，可以尝试wxWidgets，支持C++和Python等多种语言。Python做快速原型的能力是一流的，值得尝试。

唯一的一个禁区就是：千万不要手贱用VB写程序。很多单片机的上位机教程，是由长期为单片机编程而不了解PC桌面程序的作者编写的。这些作者经常抱着相当陈腐的观念，甚至于直到现在还在用VB来写程序。不要学那些反面教材。