Ускоряем протокол связи KWP2000 в прошивке J5LS_V43C.

Многие заметили, что загрузка калибровок в прошивку V43C происходит гораздо быстрее, поскольку прошивка поддерживает гораздо меньшие интервалы запросов KWP2000. Это произошло благодаря тому, что я набрел на программу ecucheck и решил немного ее помучить. Не смотря на то, что программа конечно кривая как моя жизнь и методы ее работы не верны как показал опыт - кое какую оценку она все же дает. 

Для тестирования протокола связи было выбрано несколько разных компьютеров и ОС.

- Системный блок на базе платы GA-D525TUD (atom525) c аппаратным COM портом и ОС Windows XP.. 

- Lenovo T61 (centrino) с аппаратным COM портом в док станции и ОС Windows XP. 

- IBM X31 (Pentium-M) с аппаратным COM портом в док станции и ОС Windows XP.

- Lenovo X201s (core I7) с нашим USB K-line адаптером и двумя ОС Windows XP и Windows 7.

- ASUS S200N c картой Argosy и ОС Windows XP. 

Аппаратный COM порт был выбран как эталон интерфейса связи с ЭБУ. Однако, как показала практика - в разных ноутбуках они сильно разные бывают... Эталонным адаптером для COM порта был взят адаптер "Октя 2005" на ИМС MC33199 (т.е. такой же как в самом Январе) и DS275 в преобразователе RS232-TTL...

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

Первый запуск привел меня в уныние - ибо все было плохо с самой прошивкой. По сути 50ms - последний таймаут который работает. Однако я быстро поправил все узкие места. Следующий запуск на другом компьютере, уже с эталонным адаптером и новой прошивкой. Стало сильно лучше, но все же:

Что за фигня тут нарисовалась? спросите вы.. Собственно проблема в том, что точность таймера в Windows XP = 15 миллисекунд. Соответственно, если делать задержку через Sleep(x) то 35-40-45 миллисекунд ничем не отличаются друг от друга по времени, и равно количеству пакетов а следовательно и скорости. Для того, чтоб избавится от этого эффекта, достаточно просто в background запустить "Матрицу" - которая меняет точность таймера любой операционной системы c ядром NT и выше, до одной миллисекунды, чтоб комфортно работать с своей высокоскоростной лямбдой. Ну а как побочный эффект - исправляет кривизну подобных программ.

2-я проблема заключается в том, что заданный таймаут почему то не выставляется в самом первом прогоне теста, из за чего первая строка теста всегда недостоверна (обычно значения характерны  для таймаута 300мс). По этому поводу наверно уместно будет вставить такую картинку c D3:

После фикса первой проблемы результаты теста имеют вот такой вид (в первую строку мы просто не смотрим):

Тут вылезла еще одна  проблема, которая  заключается в том, что как вы видите - программа остановила перебор таймаутов до того, как появились какие то видимые проблемы связи, что же - пропатчим этот момент и попробуем еще раз на разных уже ПК:

Старичок X31 при работе с COM портом почему то уделывает все подряд включая более современный T61. Интересная ситуация... Видимо удачный чипсет на P4M. Кстати, чтоб не ждать лишнее время я поправил не только конечное, но и начальное значение таймаута для теста...

Попробуем теперь  в режиме USB на одном и том же ноутбуке но с разными ОС:

Так же прошивка теперь поддерживает множественные скорости работы по K-line. Скорость 62500 бод была выбрана, как наиболее оптимальная для контроллера (не образуется ошибка задания baudrate при тактовой частоте 16мгц в MCS51). К сожалению такие скорости работы возможны только при работе с USB адаптерами (не всеми конечно - но с нашим точно). 

Но больше всего удивило, что на одном и том же компьютере с разными ОС, семерка почему то уделала XP в этом тесте. Скорее всего, дело в более корректной реализации usbser.sys, либо стека фильтров, либо единичные байты в семерке более корректно в пакеты группируются для отправки... Для того, чтоб проверить это, я быстро дописал измерение времени записи одного и того же блока в "Матрице" программатором (в "Матрице" везде используется только пакетная передача и прием данных - и таким образом она уже оптимизирована по максимуму для данного типа протоколов, и ОС вряд ли сможет там, что то еще "вытянуть"). После проверки времени записи в разных ОС на разных ПК, результаты наоборот очень не существенно различались, даже между совсем разными ПК, а между ОС на одном ПК, различия оказались в сотых долях секунды. Причем - наоборот в пользу XP.

 Ну и наконец последний тест - длинный (инженерный) пакет:

(c) Maxi(РПД) 2016 Копирование материалов ресурса без разрешения автора запрещено.