DEBUGIN在BASIC Stamp上影响SPI的突发速度

我有一个Parallax BASIC Stamp板上的应用程序，它读取文本命令并根据命令执行测试用例。一个测试用例通过SPI总线发送数据并从SPI总线读取失败，这取决于DEBUGIN文本的突发速率。DEBUGIN在BASIC Stamp上影响SPI的突发速度

印章板通过19200波特的串行端口连接到PC（四核+2GHZ）。

当我使用BASIC Stamp Terminal或超级终端向邮票板发送命令时，测试通过。当我通过C＃应用程序发送相同的命令时，测试失败。主要区别在于文本发送到邮票板的爆率。

人类发送文本比计算机（应用程序）慢。当使用超级终端时，一个字符以19200波特发送。该应用程序以19200波特发送8个字符，字符之间没有间隔。

我正在寻找解释如何DEBUGIN语句（通过串行端口输入）影响SHIFTIN或SHIFTOUT命令，或者如果有人知道如何解决此问题。

不幸的是，DEBUGIN命令的波特率不能改变。另一种方法是使用串行端口命令以较慢的速度（使用额外的宝贵空间，这对我的项目几乎没有任何影响）具有自定义版本（包括将文本转换为数字）。

如果发布到StackEchange是错误的论坛，请迁移并发布它被迁移的原因。

听起来好像微控制器端没有设置好为UART和SPI外设提供服务，因此后续字符到达UART的速度太快会导致SPI无法服务，或者可能导致UART上的某些字符丢失。

强大的解决方案是了解问题并将其修复到微控制器代码的体系结构中。例如，您可能需要使用中断，并让中断服务程序在较长的软件管理的fifo和外设硬件中的常用1-或2-深fifo之间移动字符。

一个可行但风险更大的解决方案是让C＃应用程序在它发送的字符之间插入延迟，以充分利用人类速度键入的显然效果。这个主题的一个变体是让嵌入式设备回显字符，让C＃程序在发送下一个字符之前等待每个字符的回显（您还需要一个转义字符来清除嵌入的命令缓冲区，并重新开始C＃程序决定宣布嵌入式设备超时并重新开始）

另一个想法是缩短必须发送的数据。用于嵌入式系统的人类可读命令语言非常棒，因为您已经注意到可以使用终端应用程序与它们一起玩。但是，如果嵌入式系统受到极大限制，使用打包二进制或十六进制格式可以更容易解析。一个极端的单字符命令在其执行期间暂停是最简单的情况（如果主要使用字母数字，则可以使用终端程序）

2011-02-24 05:18:09

不幸的是，低级代码是Parallax BASIC解释器的一部分，所以我无法控制驱动程序（也无法访问）。在发送字符（来自PC）后，我已经尝试了1秒的延迟而没有任何影响。下一个解决方法是让印章板只从SPI总线上读取并向PC回报。 – 2011-02-24 21:30:16

回答