Микроконтроллер записывает дополнительные данные при частой записи

Я использую C-Control Pro 128 с процессором Atmega. Я подключил интерфейс rs232 к своему ПК и прочитал входящие данные, запустив на контроллере следующую программу:

void main(void) {
  Serial_Init(0, SR_8BIT | SR_1STOP | SR_EVEN_PAR, SR_BD9600);
  Serial_Write(0, 1);
  Serial_Write(0, 2);
}

Я ожидал, что контроллер выведет байты 1 и 2 . Вместо этого я получаю следующее:

1
2
119
119

Если я пишу, например, восемь байтов вместо двух, 119 добавляется восемь раз к фактическим данным. Если я пишу только один байт, передается только один байт, так что все работает правильно.

Число 119 не зависит от значения байтов и скорости передачи данных.

Если я добавляю инструкцию сна между командами записи (около 50 мс), проблема не возникает.

У кого-нибудь была похожая проблема или есть идеи, где проблема может быть обнаружена?

Когда вы записываете 8 байтов, эти 8 байтов правильно поступают на ПК, тогда вы получаете 8x 119?
Да, сначала весь правильный блок, потом 8х119.
У вас есть логический анализатор или осциллограф?
Ладно, посмотрю график осциллографом.
Просто отправьте один байт, желательно что-то с характерным рисунком, например, букву K.
Спасибо за помощь, это решило мою проблему! Осциллограф показал данные точно так, как и ожидалось, поэтому я использовал другую терминальную программу, которая не показывает дополнительные байты. Проблема должна быть в терминальной программе, которую я использовал первой. Довольно странно, потому что до сих пор я никогда не обнаруживал с этим никаких проблем. Во всяком случае, не осталось проблем. Если вы хотите, чтобы я принял ваш ответ, просто опубликуйте последний комментарий как ответ :)
К вашему сведению: дайте нам знать о ваших предыдущих конфигурациях, я думаю, вы включили режим XON OFF. Где он отправляет управляющие символы через канал данных.
Нет, Xon Xoff не включался, даже в первом терминале разницы нет. Я использовал 9600 бод, 8 бит данных, 1 стоповый бит и даже контроль четности, что также является конфигурацией в коде.

Ответы (1)

Чтобы диагностировать такого рода проблемы, нужно разделить их пополам. Чья это вина? C-Control или ПК? Если мы сможем просмотреть фактические данные, отправленные по сети, мы сможем сказать, где находится неисправность.

Начните с отправки простого, легко узнаваемого символа снова и снова. Мне нравится использовать тот, который используется в качестве примера на странице RS232 в Википедии, потому что вы можете легко увидеть, как должна выглядеть форма сигнала.

К RS232

Теперь вам понадобится осциллограф. Если вы не можете себе это позволить, я настоятельно рекомендую анализатор Saleae Logic . Это не так уж дорого и сэкономит вам буквально дни жизни. Посмотрите на сигнал на шине и убедитесь, что он соответствует ожидаемому. Проверьте наличие любых мошеннических символов, переданных впоследствии.

Если все выглядит нормально, то проблема где-то в ПК. Если появляются мошеннические символы 119, то вы знаете, что проблема в C-Control.