виртуальный компорт очень медленный по сравнению с терминалом

Я пишу приложение, в котором мне нужно отправить файл (~ 600 КБ) на другое устройство через виртуальный последовательный порт.

Когда я отправляю его с помощью терминального приложения (TeraTerm), это занимает менее 10 секунд, но с помощью моей программы это занимает 1-2 минуты.

Мой код очень прост:

port.WriteTimeout = 30000;
port.ReadTimeout = 5000;
port.WriteBufferSize = 1024 * 1024; // Buffer size larger than file size
...
fs = File.OpenRead(filename);
byte[] filedata = new byte[fs.Length];
fs.Read(filedata, 0, Convert.ToInt32(fs.Length));
...
for (int iter = 0; iter < filedata.Length; iter++) {
    port.Write(filedata, iter, 1);
}

Вызов port.Write со всей длиной файла, по-видимому, всегда вызывает тайм-аут записи по неизвестной причине, поэтому я пишу по 1 байту за раз.


person ChewToy    schedule 02.03.2015    source источник
comment
Из документации: если есть слишком много байтов в выходном буфере, а для Handshake задано значение XOnXOff, то объект SerialPort может вызвать исключение TimeoutException, ожидая, пока устройство будет готово принять дополнительные данные.   -  person Sani Singh Huttunen    schedule 02.03.2015
comment
Вы правильно установили Скорость передачи?   -  person spender    schedule 02.03.2015
comment
Попробуйте писать большими пакетами. Попробуйте 16, потом 32 и так до 1024   -  person xanatos    schedule 02.03.2015
comment
@SaniHuttunen Я установил для него значение port.Handshake = Handshake.None (но код в посте опущен, не думаю, что это важно)   -  person ChewToy    schedule 02.03.2015
comment
@spender Это виртуальный comport, скорость не имеет значения. На всякий случай установлено 115.2k   -  person ChewToy    schedule 02.03.2015
comment
@xanatos Я пытался отправить его пакетами по 1024 байта, но, похоже, это не имеет никакого значения.   -  person ChewToy    schedule 02.03.2015
comment
Я отредактировал ваш заголовок. См. Должны ли вопросы включать «теги» в свои заголовки?, если нет единого мнения, не следует.   -  person John Saunders    schedule 02.03.2015
comment
@JohnSaunders Спасибо, я буду иметь это в виду.   -  person ChewToy    schedule 03.03.2015


Ответы (1)


Решил это, вот подробности, если кто-то еще обнаружит это, это может дать некоторые подсказки о том, что не так.

Я неправильно читал файл, каким-то образом приложение использовало \r\n в качестве новой строки при передаче. Сам файл представляет собой файл Intel .hex, который содержит контрольные суммы, которые были рассчитаны с использованием \r в качестве новой строки.

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

Если у вас есть похожие ошибки, я рекомендую использовать программное отслеживание для отслеживания того, что на самом деле отправляется

person ChewToy    schedule 02.03.2015