DEBUGIN 突发速度影响 BASIC Stamp 上的 SPI
我在 Parallax BASIC Stamp 板上有一个应用程序，它读取文本命令并根据命令执行测试用例。一种通过 SPI 总线发送数据并从 SPI 总线读取数据的测试用例失败，具体取决于 DEBUGIN 文本的突发速率。
Stamp Board 通过串行端口以 19200 波特率连接到 PC（四核 2+ GHZ）。
当我使用 BASIC Stamp 终端或超级终端向 Stamp Board 发送命令时，测试通过。当我通过 C# 应用程序发送相同的命令时，测试失败。主要区别在于文本发送到图章板的突发速率。
人类发送文本的速度比计算机（应用程序）慢。使用超级终端时，以 19200 波特率发送一个字符。应用程序以 19200 波特率发送 8 个字符，字符之间没有停顿。
我正在寻找 DEBUGIN 语句（通过串行端口输入）如何影响 SHIFTIN 或 SHIFTOUT 命令的解释，或者是否有人知道如何解决此问题。
不幸的是，DEBUGIN 命令的波特率无法更改。另一种方法是使用串行端口命令以较慢的速度使用自定义版本（包括将文本转换为数字）（这会使用额外的宝贵空间，而我的项目中很少有这种空间）。
如果在 StackEchange 上发帖是错误的论坛，请迁移并发布迁移原因。
I have an application on a Parallax BASIC Stamp board that reads text commands and executes test cases based on the commands. One test case that sends data via the SPI bus and reads from the SPI bus is failing, depending upon the burst rate of the DEBUGIN text.
The Stamp Board is connected to a PC (Quad core 2+ GHZ), through serial port at 19200 baud.
When I use the BASIC Stamp Terminal or Hyper Terminal to send commands to the Stamp Board, the test passes. When I send the same commands via a C# application, the test fails. The primary difference is the burst rate at which the text is sent to the Stamp Board.
Humans send text slower than computers (the application). When using Hyper Terminal, one character is sent at 19200 baud. The application is sending 8 characters at 19200 baud with no pauses between characters.
I'm looking for an explanation how the DEBUGIN statement (input through the serial port) affects the SHIFTIN or SHIFTOUT commands, or if anybody knows how to resolve this issue.
Unfortunately, the baud rate of the DEBUGIN command cannot be changed. The alternative is have a custom version (including conversion of text to numbers) using the serial port command at a slower speed (which uses extra valuable space, which there is little of on my project).
If posting to StackEchange is the wrong forum, please migrate and post the reason it was migrated.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
听起来微控制器端没有设置好为 UART 和 SPI 外设提供服务，因此后续字符到达 UART 的速度太快，要么导致 SPI 无法得到服务，要么可能导致UART 上的一些字符会被遗漏。
稳健的解决方案是理解问题并在微控制器代码的架构中修复它。例如，您可能需要使用中断并让中断服务例程在较长的软件管理的 fifo 和外围硬件中通常为 1 或 2 深的 fifo 之间移动字符。
一个可能可行但风险更大的解决方案是让 C# 应用程序在发送的字符之间插入延迟，以利用人类快速打字的明显效果。此主题的一个变体是让嵌入式设备回显字符，并让 C# 程序在发送下一个字符之前等待每个字符的回显（您还需要一个转义字符来清除嵌入式命令缓冲区并重新开始，如果C# 程序决定声明嵌入式设备超时并重新开始）
另一个想法是缩短必须发送的数据。对于嵌入式系统来说，人类可读的命令语言非常棒，因为正如您所注意到的，您可以使用终端应用程序来使用它们。但是，如果嵌入式系统受到极大限制，则使用打包的二进制或十六进制格式可以使其更易于解析。最简单的情况是在执行之间有暂停的单字符命令的极端情况（如果您主要使用字母数字，则可以使用终端程序）
It sounds like the microcontroller end is not set up to do a good job of servicing both the UART and the SPI peripherals, and so too rapid an arrival of subsequent characters on the UART is either causing the SPI to not be serviced, or perhaps causing some characters on the UART to be missed.
The robust solution is to understand the problem and fix it in the architecture of the micro controller code. For example, you may need to use interrupts and to have the interrupt service routines move characters between longer software-managed fifos and the often 1- or 2- deep fifo in the peripheral hardware.
A possibly workable but riskier solution is to have your C# application insert delays between the characters it is sending, to take advantage of the apparent working of human-speed typing. A variation on this theme is to have the embedded device echo characters, and have the C# program wait for the echo of each character before it sends the next (you'll also need an escape character to clear the embedded command buffer and start over if the C# program decides to declare the embedded device timed out and start over)
Another idea is to shorten the data that has to be sent. Human readable command languages to embedded systems are great, because as you've noticed you can play with them using a terminal application. However, if the embedded system is extremely constrained, using a packed binary or hex format can make it easier to parse. An extreme of single-character commands with pauses in between for their execution is the simplest case of this (and if you primarily use alphanumerics, you are back to being able to use the terminal program)