AleksandrvaСкорость тоже важна, чем выше, тем лучше. По поводу таймаутов я не знаю досконально как работает подсистема COM портов под виндой, но возможно это связано вообще с принципом работы USB.
Как вы могли заметить данные передаются пачками определенного размера. Вот внутри этой пачки, когда прога подряд шлет данные - важен таймаут ответа самого адаптера, т.е. задержки последовательного порта.
видно что разница всего в 1мс между посылками в пачке19:51:09.928 >2BEC8A7C2F28EC81
19:51:09.929 >2C7C2F2C1F010630
19:51:09.930 >2D6FC6307B010620
19:51:09.931 >2E68FC2F2AFE2F28
19:51:09.932 >2F6E846C86790102
19:51:09.933 >20C6127B010A1A84
19:51:09.934 >21A6857A010BCC01
19:51:09.935 >22807A0102EE867E
19:51:09.936 >23010A7B0106CE00
x
Во время посылки этой пачки адаптер не ожидает ответа от прошиваемого модуля и просто льет в шину что есть.
Когда пачка заканчивается программа включает прием и адаптер ждет ответа-подтверждения от модуля.
виден ответ модуля через 55мс19:51:10.969 >22E381ED833BE64A
19:51:10.970 >2331186B4A18EDE0
19:51:10.971 >ATR1
19:51:10.972 <OK
19:51:10.972 >24DC02186DE0DC8D
19:51:11.027 <0276020000000000
x
на самом деле модуль мог ответить и раньше, но вот только ELM выжидает установленный CAN Timeout в 55мс и отправляет уже ответы в комп. Вот в этим таймаутом получается гадание, слишком мало - модуль не успеет ответить и будет "NO DATA", слишком много - можно будет три часа прошивать приборку.
Чтобы понимать о каких порядках цифр идет речь, допустим прошивка модуля 1 000 000 байт, а заливаться она будет блоками по 200 байт. Соответственно адаптер будет выжидать 1000000/200 = 5000 раз по CAN Timeout => 5000*55мс = 4,5 минуты просто тупого ожидания, а если выставить CAN таймаут в 90мс, то уже 7,5 минут. Для прошивки в 6Мб получим 45 минут уже. По правде говоря те 5000 раз надо бы умножить на 3, т.к. адаптер на каждую пачку ждет не один раз ответ.
Но самая засада это задержки между посылками
В строке отправляется 7 значащих байт, и значит получается что 1Мб прошивки будет передан ~150 000 строками. Если между каждой из них будет по 1мс, то это всего 2,5 минуты. Но если между ними будет 16мс (так по дефолту стоит в FTDI) или еще хуже из-за особенностей компа/ОСи, то представляете масштаб бедствия, 2,5 * 16 = 40 минут.
Так вот если честно мне кажется что проблема с "NO DATA" врятли должна решаться увеличением CAN Timeout, т.к. модуль должен бы отвечать за определенное время вне зависимости от типа компа/адаптера. Другое дело что китайская ELM может тупить и неправильно считать таймаут? Эта ошибка с NO DATA в конце пачки может возникать в случае если нарушилась передача самой пачки, но т.к. адаптер ничего не слушает в процессе передачи, то он упустил сообщение об ошибке, а при завершении передачи соответственно ничего и не услышал, т.к. модуль уже с ним перестал общаться
Пока писал это разъяснение возникла мысль добавить повторную передачу пачки если не был получен ответ о корректности её приема, раньше почему-то не догадался этого сделать =)
А для тех кто в логе наблюдает периодически CAN ERROR, у меня плохие новости, это как я полагаю проблема на уровне железа. Т.е. программно я её разрешить не смогу и нужно скорее всего смотреть качество пайки проводов/микросхем на адаптере.