Мост USB-USART проблемы с ноутбуком

[shyub]

проблемы были у всех, пока не купил MOXA UPort 1110

Попробуйте этот сниффер: Sniffer.rar У меня практически все переходники USB/RS232 секунд через 5 "зависают". Если MOXA UPort 1110 будет работать, то действительно стоящая вещь...

[Godzilla82]

каким образом Вы меняеете настройки драйвера.

В диспетчере устройств.
Порты (COM и LPT) - Нужный порт - Свойства - Параметры порта - Дополнительно.

Не для всех чипов есть дополнительные настройки.

Тем более, что эта настройка влияет всего лишь на задержку (до 200 мс или более) перед отправкой по USB. При таких ошибках, как у вас, эта настройка вряд ли поможет.

Если не секрет - выыложите код для PC и MC, организующий обмен данными. Скоорее всего, ошибка в коде, а не в устройстве.

[alvadep]

Попробуйте этот сниффер: Вложение 77008

Винда ХР. Все работает (и CH340 и FT232RL). Правда все адаптеры с гальваноразвязкой на ADUM1201.

[shurenock]

В общем кто еще помнит о чем речь шла, после месяца другой работы и прочих заморочек, пришло время разобраться в чем дело.
Итог таков: В чем конкретно причина, я так и не дошел, зато как побороть эту засаду нашел 100%.
С каким бы бодрейтом я не работал, важна не частота передачи, а пауза между пакетами.
В моем случае пакет состоит из 6 байтов: два байта служебных (синхро) и четыре байта данные. Для моего стационарного компьютера (4 ядра, 2,6 ГГц, Win7 и пр.) интервал между пакетами должен быть не менее 13 мс. Если меньше, то начинает выдавать ошибку, такую же как на ноутбуке.
Для ноутбука (2 ядра, 1.8 ГГц, Win7 и пр.), минимальный интервал для гарантированной работы без сбоев равен 45 мс.
Все остальное (помехи, гальваническая развязка и пр.) роли не играет.
Предположительно происходит следующее: винда пакет обрабатывает целиком, когда пакет закончен, через некоторое время драйвер ставится в винде в очередь, как ожидающий, за это время выполняются другие проги. Видимо, периодически какая-то прога перекрывает очередь надолго и происходит сбой, если следующий пакет приходит раньше, чем освободится ресурс под драйвер обработки порта.
Так что вот так.
Сейчас с указанными выше интервалами между пакетами связка контроллер - компьютер работает железно, без сбоев.
Тестил на нескольких других компах, как на ноутах так и на стационарах. У каждого свой защитный интервал, но он четко повязан с быстродействием проца компьютера.

[Boba_spb]

Вам же советовали показать как Вы там с СОМом работаете
А Вы рассказываете про какие-то чудеса в решете. Кривизна у Вас в программе, а не в системе. Посмотрите на загрузку проца - кто то там что держит? Иль у Вас загрузка всех ядер под 90%
Поднимите приоритет своему процессу, разрешите ему испоьзовать только одно ядро и посмотрите что с ошибками будет.
А лучше покажите как Вы там с СОМ ом работаете.

[shurenock]

//Событие: по последовательному интерфейсу пришли данные
void serialPortMCU_DataReceived(object sender, System.IO.Ports.SerialDataReceivedEventArgs e)
{
int temp = 0;
try
{
//Считываем, сколько байтов в буфере, создаем временный массив, считываем байты во временный массив
temp= serialPortMCU.BytesToRead;
byte[] tempBuff = new byte[temp];
serialPortMCU.Read(tempBuff, 0, temp);
//Перекидываем байты из временного массива в массив очереди для обработки
for (int i = countByteInBuff, j = 0; i ‹ countByteInBuff + temp; i++, j++)
{
serialInByte[i] = tempBuff[j];
}
}
catch
{
//Остановка генерации
MessageBox.Show("Ошибка приема данных!", "Ошибка!", MessageBoxButtons.OK, MessageBoxIcon.Error);
btStartMode4.Text = "Старт";
}
Настройки последовательного порта тоже стандартные.


Дальше идет разбор принятой информации, поэтому код не привожу. Ошибка возникает на этом куске кода.
Со стороны контроллера все тоже очень просто:

//-----------------------------------------------------------------------------
//Подпрограмма передачи массива данных на PC
//-----------------------------------------------------------------------------
void TransmissionDataToPC(uint8_t data1, uint8_t data2, uint8_t data3, uint8_t data4)
{
USART0_Transmission(USART_SYN_OUT);
USART0_Transmission(USART_SYN_OUT);
USART0_Transmission(data1);
USART0_Transmission(data2);
USART0_Transmission(data3);
USART0_Transmission(data4);
}
//-----------------------------------------------------------------------------


//Подпрограмма передачи байта по USART
uint8_t USART0_Transmission(uint8_t data_byte)
{
loop_until_bit_is_set(UCSR0A,TXC0);
UDR0=data_byte;
_delay_us(300);
return 0;
}

Можно через цикл и массив передавать, но мне так удобней.
Настройки USARTа привести?
Схемотехнику показать?

Загрузка проца конечно маленькая и не на четыре ядра. Жду оценки глюков в программе)))

[Boba_spb]

Какая ошибка вылетает и в каком месте?
serialInByte маленький что ль?

А в передаче delay - это зачем?

[shurenock]

Исключение в блоке try{}.
Разбор номера ошибки я не делал. Хотя наверное стоит сделать.
Завтра допишу кусок кода разбора ошибки, отпишусь.

serialInByte с запасом на 15 пачек информации.

Без паузы вот тоже глючит.

Вообще глючить начинает не сразу, а спустя пару циклов работы. Но точного момента нет. Он плавает.
Была идея, что из-за рассогласования частоты кварца и бодрейта USARTа возникает ошибка, которая накапливается. По даташиту при частоте проца 16 МГц и бодрейте 38,4 bps ошибка 0,2%.

Но это в пределах.

[Boba_spb]

Так лететь то может лишь в двух случаях - либо выход за размер serialInByte, либо порт закрывается и имеете тут temp равный 0, и летите на
tempBuff , который организовали нулевой длины

[shurenock]

Смешно)))
Только раньше было по другому организовано. Я байты сразу в массив выбирал, без промежуточного буфера. Итог тот же.
Опять же, а почему тогда, как только паузу между пачками делаешь больше, глюк уходит. Что порт вдруг открывается?))) Не катит. Логики нет.