Пакетная скорость DEBUGIN, влияющая на SPI на BASIC Stamp

Похоже, что конец микроконтроллера не настроен для хорошего обслуживания как UART, так и периферийных устройств SPI, и поэтому слишком быстрое поступление последующих символов на UART либо приводит к тому, что SPI не обслуживается, либо, возможно, вызывает некоторые символы в UART будут пропущены.

Надежное решение состоит в том, чтобы понять проблему и исправить ее в архитектуре кода микроконтроллера. Например, вам может понадобиться использовать прерывания и заставить процедуры обслуживания прерываний перемещать символы между более длинными fifo, управляемыми программным обеспечением, и зачастую 1- или 2-глубоким fifo в периферийном оборудовании.

Возможно, работающее, но более рискованное решение состоит в том, чтобы ваше приложение C# вставляло задержки между отправляемыми им символами, чтобы воспользоваться преимуществами очевидной работы быстрого набора текста. Разновидностью этой темы является наличие встроенных эхо-символов устройства и программа C#, ожидающая эхо-сигнала каждого символа перед отправкой следующего (вам также понадобится escape-символ, чтобы очистить встроенный командный буфер и начать заново, если программа C# решает объявить время ожидания встроенного устройства истекшим и начать заново)

Другая идея состоит в том, чтобы сократить данные, которые должны быть отправлены. Удобочитаемые командные языки для встроенных систем — это здорово, потому что, как вы уже заметили, с ними можно играть, используя терминальное приложение. Однако если встроенная система чрезвычайно ограничена, использование упакованного двоичного или шестнадцатеричного формата может упростить анализ. Крайняя односимвольная команда с паузами между их выполнением является простейшим случаем этого (и если вы в основном используете буквенно-цифровые символы, вы снова можете использовать программу терминала)