首页 文章

LAN和微控制器之间的通信

提问于
浏览
0

所以我有一个奇怪的问题 . 我'm using LAN for the communication with a microcontroller. Everything was working perfect. Meaning: I can send and receive data. For receiving data I'm使用一个简单的方法,在 for 循环中 Thread.sleep(1) ,其中我一直检查 client.GetStream().DataAvailable 为真,而 clientTcpClient 现在,我必须向一个进程发送和接收具有更高波特率的微控制器 . 我使用9600进行所有其他操作,一切都很好 . 现在用115200 client.GetStream().DataAvailable 似乎总是有值 false . 可能是什么问题呢?

PS:与微控制器通信的另一种方式(全部由用户选择)是串行通信 . 波特率越高,这仍然可以正常工作 .

这是一段代码:

using (client = new TcpClient(IP_String, LAN_Port))`
                    {
                        client.SendTimeout = 200;
                        client.ReceiveTimeout = 200;
                        stream = client.GetStream();
                        .
                        .
                        bool OK = false;
                        stream.Write(ToSend, 0, ToSend.Length);
                        for (int j = 0; j < 1000; j++)
                        {   
                            if (stream.DataAvailable)
                            {
                                OK = true;
                                break;
                            }
                                Thread.Sleep(1);
                        }
                        .
                        .
                    }

编辑:在监视与列表设备的通信时,我意识到这些位实际到达并且设备实际应答 . 唯一的问题似乎是 DataAvailable 标志没有被提出 . 我应该找到另一种检查数据可用性的方法 . 有任何想法吗?

1 回答

  • 1

    我一直试图想到我看到过这样做的事情......

    我已经看到串行芯片说他们会做115,200,但实际上不会 . 看看如果将波特率降低一级会发生什么 . 无论哪种方式,你都会学到一些东西 .

    一些微控制器通过让CPU升高和降低数据引脚来“串行”串行端口,并且基本上通过这些位,将1或0敲入串行引脚 . 当一个字节进来时,他们会读取它,并做同样的事情 . 这确实省钱(没有串行芯片),但实际上可靠地工作是绝对地狱般的噩梦 . 115,200可能会过分努力 .

    这可能是一个微妙的微控制器问题 . 假设您有一个接收串行芯片,当一个字节进入时断言一个引脚,通常类似于“数据请求”的DRQ *(DRQ 中的表示0伏是“我们有一个字节”条件)(c 'mon,people,a *并不总是指针:-) . 好吧,DRQ *请求中断,固件和CPU中断,它读取串行芯片的字节,并将其存入一些方便的内存缓冲区 . 然后它从中断返回 .

    如果你假设数据进入,串行芯片得到一个字节(在这个例子中为"#1"),断言DRQ *,我们中断,固件抓取并存入字节#1,并从中断返回,则会出现问题 . 一切都很好 . 但是想想如果在第一个中断仍在运行时另一个字节进入,会发生什么 . 串行芯片现在有字节#2,因此它再次断言已经断言的DRQ *引脚 . 第一个字节的中断完成 . 怎么了?你挂了 .

    这是因为它是DRQ *的-edge-,物理上从5V到0V,实际上导致CPU中断 . 在第二个字节,DRQ *从0开始并设置为0.因此DRQ *(仍然)被置位,但没有-edge-告诉中断硬件/ CPU另一个字节正在等待 . 当然,现在,所有其他传入数据也会被删除 .

    看看为什么它在更高速度下变得更糟?中断例程越来越快地处理数据,并且通常在中断处理程序中进行循环I / O缓冲区计算,并且它必须快速有效,因为快速输入可以将中断处理程序推送到全新字节进入之前中断结束 .

    这就是为什么在中断处理程序中检查DRQ *以查看另一个字节(#2)是否已经在等待(如果是这样,只是读入它,清除串行芯片的DRQ *,并将该字节存入内存)的好主意然后,或使用“水平触发”中断,而不是“边缘触发” . 边缘触发肯定有很好的用途,但你需要注意这一点 .

    我希望这是有帮助的 . 这肯定花了我足够的时间来第一次弄明白 . 现在我非常关心这样的事情 .

    祝你好运,让我知道它是怎么回事 .

    • 谢谢,Dave Small

相关问题