先说说项目大概情况:
     请人开发一动画程序,用单片机通过串口给PC发信号,动画程序根据单片机的指令来播放对应的动画片段。并且要求动画程序接收到指令及播放完毕动画片段后都要给单片机回复一下。    动画程序做完后,程序员无法使动画程序直接接收串口发来的命令,后又想方案另请人开发了串口通信命令转接程序,转接程序将接收到的单片机的代码保存到PC的制定INI文件下,动画程序随时读取INI文件下的命令,有新命令就执行。同时将回复信息存入到另一INI的文件下,供通信程序读取后发给单片机。现在发现并不是很稳定及正确。请这方面的专家对这一方案做个解评?
   
   现在非常希望动画程序能够直接跟单片机通信,不知道要怎么处理,怎样的方式来通信?动画程序要怎么做或者通过什么方案来实现?或者谁有能力做这个项目,我们谈谈怎么合作?(单片机部分已经有了,只是PC部分的需要处理)

解决方案 »

  1.   


    你好,有个socket,你说的这种跟socket两种对比的话,哪个更稳定,出错率更低呢?
      

  2.   

    画程序能够直接跟单片机通信
    选要做一个中间软件xxx
    画程序<--->Socket<--->xxxx<--->SerialPort<--->单片机
      

  3.   


    请问:" 动画程序<--->Socket<--->xxxx<--->SerialPort "  这几个部分最终是集合为一个整体程序运行,还是单独运行?
      

  4.   

    如果你的动画程序是用C#写的话就按照这个说的做没问题动画程序<--->Socket<--->xxxx<--->SerialPort "
    ,而且功能很简单程序员做不出来说明是刚毕业的,我带的小弟都可以自学这方面的知识自己做,
      

  5.   

    你帶的小弟沒來CSDN問過問題嗎?
    誰不是這樣一步步走過來的
      

  6.   

    其實,你寫這么多,你的問題我猜,應該是讀寫串口的問題
    這個網上有很多,BAIDU試下
      

  7.   

    只能用串口,不能用socket,因为你的单片机已经是串口通信了,改不了了
      

  8.   

    上位机程序(动画程序<--->SerialPort)<---->下位机串口(下位机程序),
      

  9.   

    帮我做动画程序的程序员说:程序是没有源文件的,直接是脚本编写,速度快,效率高。现在无法直接让程序跟单片机通讯。 
    已经另请程序员开发了串口通讯的插件程序。  目前的方法是:插件程序接收到单片机命令后保存到一个INI文件里,动画程序随时读取INI文件里的命令,有命令读到就执行。给单片机的回复也是,动画程序有命令发送时就把命令写进另一个INI文件里,插件程序读到后就发给单片机。目前这样的方式能通了,只是不知道安全系数怎么样?出错的概率是否大?请有经验的专家分析一下,这种方案是否可行?
      

  10.   

    你的单片机不一定支持socket吧
      

  11.   

    实现楼主所以说的功能并不难。
    1.接收设备指令当然是SerialPort了,还有种方式是通过GPRS
    2.对于接收指令的模块,在从接收指令到解析并处理中最好是使用异步处理,因为要考虑指令会不会漏发、错发。所以需要在模块中加入指令监听,防止因为这些原因而影响效率。这样性能会好些。
      

  12.   

    楼主是个老板,貌似没有基本的技术概念,这样不行,迟早要出大问题的。要么花钱请项目经理帮你做技术上的把关,你的这个问题项目经理完全可以解决;要么,就自己掌握些基本的东西,免得弄错方向,会花冤枉钱的。我亲眼见过的这种原因最终失败的例子,太多了!
    通用单片机(51系列、PIC系列)理论上可以实现socket,但是代价太大,建议这个方案的人一定没有什么工作经验;
    楼主顶楼提到的写入硬盘文件,虽然是个笨办法,但是应该是行得通的,不稳定可能是时序上有问题。但是如果我是你的客户,不会认可,因为这个办法太笨、技术含量太低!
    合理的是使用控件SerialPort,距离短点,码率低点,通讯错误概率可以做到极小,能做到ppm的量级甚至更低!
    相对串口方式而言,GPRS方式不好,首先资料就相对少,不好找,除非你的程序员以前做过,比较熟悉。
      

  13.   

    这个是典型的访问文件的同步问题。微软提供了各种方法解决,你去了解一下文件访问权限的东西,就能解决;此外,简单的使用try{}catch{},也行。
    既然你是客户方,为什么不要求对方采用串口通信方式呢?楼上的几位都建议解释了啊。仅就楼主顶楼的问题,51单片机+SerialPort,毫无疑问就是正确的技术方案!建议你找那个写通信插件的人,应该有能力使用这个方案中的SerialPort控件,但是单片机则需要找玩硬件的了。
      

  14.   

    以前帮别人做过银行的排队机程序,是用过无线接收呼号器指令来操作。
    我想,当时我做的串口通信模里面的接收和发送管理是这样的流程:
    A.接收
    1. 当PC程序接收到指令时,程序根据指令(一般格式是包头+指令长度+操作类型+校验为+结束字节)里包含的长度来完整的从串口接收缓存中截取完整的一条指令。
    2. 验证此条指令是否是正确,正确执行3,不正确执行4。
    3. 将此条指令放入预处理队列(先进先出)中(等待处理线程去处理)。
    4. 抛弃本条指令,接续接收下条指令,结束本次流程。
    5. 处理指令的线程去扫描预处理队列,获取第一条指令,根据指令具体表示含义进行动漫播放,或者返回相应指令告知单片机,并结束本次流程。B.发送
    1. PC程序将要发送的指令传入发送队列。
    2. 发送线程不间断扫描队列,发现队列中存在含有需要发送的指令,执行3,否则执行4
    3. 发送该指令到设备中,并结束本次流程
    4. 结束本次流程。PS:在接收处理指令时,最好将接收和处理的步骤分开,保证能及时完整的接收到指令,且通过异步接收处理,可保证程序的稳定,提高指令处理的效率。
    如果楼主信任在下的话,通信底层模块可以交给我实现,不收费,无偿的。
      

  15.   


    我开始也是这样要求动画程序的,要求程序一定要能跟单片机直接通讯,接受单片机的指令来播放动画,可是他们在交付的时候,测试不能接受指令,说是让单片机发的指令要保存在他指定的INI文件夹下,供动画程序读取命令。  后来我强烈要求动画程序方面要直接跟单片机通讯,甚至另请了做通讯插件程序的帮忙最后整合成一个程序,但是动画程序讲他用的是大型商业引挚, 什么脚本语言编写之类的,意思就是无法整合成一个程序来直接跟单片机来通讯。  所以才采用了目前的方案来处理