Победа над скоростью Wifi_K-line
Довольно долго велись поиски проблемы низкой скорости
при прошивке блоков управления при помощи адаптера
Wifi_K-line . Если быть точнее, то пол года, не меньше.
Не скажу, что занимался только этой задачей, но внимания уделялось ей много.
В поисках решений мне много помог Влад qwerty095, за
что ему большое спасибо.
Время чтения прошивки с блока
Январь 7.2 составляло ~2 минуты. Пакеты с адаптера на ПК и обратно летели очень тухло. Было видно как
"редко" моргает светодиод отправки данных. Но стоило просто запустить браузер "Chrome", пошевелить
мышкой на форме и скорость в разы увеличивалась! Установка связи с блоком проходила за пару секунд!
Более наглядно эффект можно посмотреть в видео:
В добавок был разработан свой
протокол общения между программой на ПК и адаптером Wifi_k-line, который в себя включает заголовок, тип
данных, длину и контрольную сумму. Теперь сводится на нет возможность пересечения служебных и полезных
данных.
После проделанных изменений
появилась программа Wifi-OBDII Bridge. По сути, это новая программа, написанная с чистого листа, но
сохранившая интерфейс и фундаментальные принципы Wifi_tuner. Да, название решил сменить т.к., по факту,
она ничего не настраивает и изначально название дал некорректное.
Вот так появился вопрос: "Каким образом активность браузера так увеличивает скорость?!" Поиски были долгими и с разных направлений. Одним из предположений было, что браузер меняет приоритет системы работы с сетью или режим работы служб QoS. Был скачан сниффер TCP и разобран протокол общения ОС с сетью. Были проверены временные задержки между отправкой пакетов на ПК и получением их на адаптере. Всё было красиво, пакеты доставлялись в пределах пинга, меньше 1 мс. Ясным стал лишь факт, что скорость зависела от задержки между отправкой пакетов. Предполагалось, что VSPD вносит свои задержки со стороны COM- моста, но это не подтвердилось. В общем, много было предположений, но всё мимо, пока не наткнулся на интересную забугорную статью о проблемах работы библиотеки System.IO.Ports .NET. В статье очень "красиво" поливали грязью разработчиков этого чуда и были приведены факты, что ряд методов этой библиотеки работают неадекватно и их нельзя использовать при обработке данных. Многие глюки ранее я уже обнаружил и наставил "костылей", а некоторые не знал. Также было сказано, что в библиотеке используется стандартный системный таймер с разрешением 15 мс. После прочтения и осмысливания данной статьи пришлось отказаться от этой библиотеки и разобраться в прямой работе с драйвером Win32 API. Попутно была изучена работа с видеотаймером, который позволяет получить разрешение меньше 1 мс. Также было принято решение полностью переработать программу Wifi_tuner на основе новых знаний с созданием отдельных классов и их взаимодействия без нарушения принципов ООП.
Внешний вид Wifi-OBDII Bridge:
На старом алгоритме при установке связи скорость была 6 п/с, а на новом :
Стало: 27 с.
Время записи прошивки:
Было: 2 мин 17 с.
Стало: 37 с.
Скорость работы с прошивкой ТРС на новом алгоритме:
Разница незначительна. Количество пакетов увеличилось с 10 до 12. Скорость работы с пакМАН на новом алгоритме:
Разницы совсем нет. Видимо на программном уровне реализована выдача диагностики раз в 100 мс. Положительный момент переработки в том, что теперь оболочка работает с типом адаптера USB-FTDI.
Вывод.
— более чем в 4,5 раза увеличить скорость чтения и записи прошивки на Январь;
— стабильно получать 12 п/с при работе с ТРС на длинной диагностике;
— заставить работать оболочку пакМАН с типом адаптера USB-FTDI.
— повысить стабильность связи за счёт применения своего протокола связи и отказа от библиотеки .NET.