Скорость отрыва DEBUGIN влияет на SPI на BASIC Stamp - PullRequest
0 голосов
/ 23 февраля 2011

У меня есть приложение на плате Parallax BASIC Stamp, которое читает текстовые команды и выполняет тестовые примеры на основе этих команд.Один тестовый случай, который отправляет данные через шину SPI и считывает данные с шины SPI, дает сбой в зависимости от скорости пакетной передачи текста DEBUGIN.

Плата штемпеля подключена к ПК (Quad Core 2+ GHZ) через последовательный порт со скоростью 19200 бод.

Когда я использую терминал штампа BASIC или гипертерминал для отправки команд на плату штампа, тест проходит успешно.Когда я посылаю те же команды через приложение C #, тест не проходит.Основным отличием является скорость серийной передачи, с которой текст отправляется на доску штампов.

Люди отправляют текст медленнее, чем компьютеры (приложение).При использовании Hyper Terminal один символ отправляется со скоростью 19200 бод.Приложение отправляет 8 символов со скоростью 19200 бод без пауз между символами.

Я ищу объяснение того, как оператор DEBUGIN (ввод через последовательный порт) влияет на команды SHIFTIN или SHIFTOUT или кто-нибудь знаетКак решить эту проблему.

К сожалению, скорость передачи команды DEBUGIN не может быть изменена.В качестве альтернативы можно использовать пользовательскую версию (включая преобразование текста в числа) с использованием команды последовательного порта на более медленной скорости (которая использует дополнительное ценное пространство, которого мало в моем проекте).

При публикации вStackEchange - неправильный форум. Пожалуйста, перенесите и опишите причину, по которой он был перенесен.

1 Ответ

2 голосов
/ 24 февраля 2011

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

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

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

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

...