Всем откликнувимся огромное Спасибо!
Помогите с написанием программы!
#1
Отправлено 24 Март 2010 - 07:56
Всем откликнувимся огромное Спасибо!
#2
Отправлено 24 Март 2010 - 10:16
Maximus559 (24 Март 2010 - 07:56) писал:
Всем откликнувимся огромное Спасибо!
Поробовал связаться U2K-L-Iine показывает только каналы АЦП
#3
Отправлено 24 Март 2010 - 10:20
#4
Отправлено 24 Март 2010 - 10:47
#5
Отправлено 24 Март 2010 - 10:54
Если кроме стандартных компортовых функций не используешь ничего, то пофиг какой адаптер
#6
Отправлено 24 Март 2010 - 11:08
#7
Отправлено 24 Март 2010 - 11:13
или прога твоя то работает, то нет.
Если в коде не использовано ничего специфичного для FT232 то должно работать с другими адаптерами.
Ну сделай хреновину на 2 транзисторах и опробуй на ком-порте
#8
Отправлено 24 Март 2010 - 11:19
#9
Отправлено 24 Март 2010 - 11:20
#10
Отправлено 24 Март 2010 - 17:51
При работе с СОМ портом программа использует стандартные функции WIN32 API.
При связи с портом (функцией CreateFile(...)) в программе создается еще 2 дочерних потока, выполняемых совершенно независимо друг от друга.
В одном потоке на порт последовательно отправляются запросы из кэша (с интервалом задаваемым в настройках программы - по умолчанию 200 мс - так требует документация АВТОВАЗа),
в другом потоке происходит "слушаение" порта функцией WaitCommEvent(...).
Чтение и запись в порт происходят стандартными Windows API функциями ReadFile(...) и WriteFile(...).
Закрытие порта производит функция CloseHandle(...).
Параметры порта - скорость 10400 и биты четности - все взято из описания протокола KWP2000 (редакции от АВТОВАЗ).
Единственный момент который в этом документе упушен - таймауты порта, которые выставляются функцией API SetCommTimeouts(...)
В моем случае адаптер одинаково стабильно работал при любых таймаутах, и я не уделил особого внимания этому моменту!
В любом случае весь цикл написания и тестирования программы происходил на USB адаптре K-Line лишь ЭМУЛИРУЮЩЕГО работу СОМ порта.
Возможно на реальном СОМ порте необходимо выставть други таймауты или несколько иначе организовать цикл чтения/записи данных.
Наверно придется в ближайщее время спаять адаптер для РЕАЛЬНОГО СОМ порта (которго и нет в моем буке
А то уж какая то сильно аппаратно зависимая релизация получилась : )))
З.Ы: Реально кто-нить пробовал прогу на ВМ 9213? У кого-нить заработало?
#11
Отправлено 28 Март 2010 - 13:57
#12
Отправлено 28 Март 2010 - 14:18
работает и подавно. Я пользовался еще пролификом и CP
Насчет протоколов-самому интересно, но ничего свежее kvp2000 для Е2 не встречал к сожалению.
Сообщение отредактировал Cruiser: 28 Март 2010 - 14:19
#13
Отправлено 03 Апрель 2010 - 16:51
#14
Отправлено 03 Апрель 2010 - 17:03
#15
Отправлено 04 Апрель 2010 - 03:48
Рекомендации:
1. Сделай запись пакетов в лог файл (типа
TxD: ......
RxD:.......
Удобнее гораздо будет откатывать программу.
2. Для задания таймингов при инциализации обмена сделай инишник, в котором их можно было-бы править.
На разных по производительности компьютерах - разные погрешности при установке timeout.
3. Пиды желательно тоже вынести в ини файл свой для каждого типа контроллера, т.к. они отличаются
#16
Отправлено 04 Апрель 2010 - 06:39
У тебя отсутствует задержка между запросом и ответом. Т.е. в ответ ты получаешь только эхо(оно обязательно присутствует в адаптере и его нужно учитывать)
По протоколу KWP2000 вроде бы – 50мс. Но прекрасно работает и 15мс. Интервал между запросами – 150-500мс (проверял - работает).
Программы, которые я привел в пример, уверенно связываются со всеми ВАЗовскими контроллерами.
Прикрепил логи со сниффера
Прикрепленные файлы
#17
Отправлено 05 Апрель 2010 - 06:22
Изменения в версии 1.05
1. Добавлена возможность ведения логов обмена данными с портом в файл.
Для этого в верхней правой части окна появилась соответсвующая галочка.
Когда она установлна все что оправлено\принято с порта пишется в файл log.txt в папке с программой.
Таким образом образом можно записывать выборочные моменты обмена, вовремя ставя и снимая галочку.
Формат сообщений в файле :
[время] [направление] [данные] [описание]
где,
время - время отправки\приема с точностью до милесекунд
напрвление - RCV или SND для получения и отправки данных соответственно
данные - данные в 16-ричном представлении
описание - для SND сообщений это название отправленной команды, для RCV это
просто строка (символьное представление полученных данных)
После отправки данных, если на порту есть пиание, в ответ последует точно такая же команда
(эхо-команда).
И только после нее, если ЭБУ нам ответил, на порт придет команда его ответа. Сам не знаю почему так
устроено
Каждой отправленной команде в файле соответствует одна строка SND, а вот каждой принятой команде
может соответствовать несколько строк RCV, если она была получена за несколько циклов чтения с порта.
Более того - между двуми циклами чтени RCV одной логической команды (пакета), может затисаться одна
команда оправки SND т.к. эти процессы в программе проходят асинхронно! В этом нет ничего страшного,
разве что человеком воспринимается тяжеловато
2. Добавлена возможность настройки таймаутов СОМ-порта.
Для этого нужно зайти в настройки порта и в ручную помнять 5 параметров.
Не знаю, может у кого-то это и повлияет на работоспособность программы, но у меня все работает ПРИ
ЛЮБЫХ значениях таймаутов.
Прикрепленные файлы
#18
Отправлено 05 Апрель 2010 - 06:58
mol78 (04 Апрель 2010 - 06:39) писал:
У тебя отсутствует задержка между запросом и ответом. Т.е. в ответ ты получаешь только эхо(оно обязательно присутствует в адаптере и его нужно учитывать)
По протоколу KWP2000 вроде бы – 50мс. Но прекрасно работает и 15мс. Интервал между запросами – 150-500мс (проверял - работает).
Программы, которые я привел в пример, уверенно связываются со всеми ВАЗовскими контроллерами.
Прикрепил логи со сниффера
Эхо конечно же учитывается )))
В моем случае понятие "задержка между запросом и ответом" не уместно, т.к. чтение запись проясходят (повторюсь) асинхронно!
Основная программа когда нужно что то отправить ложит эти данные в буфер не дожидаясь самого момента их отправки на порт.
В принципе в этом буфере может скопиться хоть 5 хоть 10 команд (но на практике такого не бывает). Поток для записи в порт (выполняемый
отдельно от основого) как только увидит что буфер для отправки не пуст, сразу шлет первую команду с буфера на порт и засыпает на время 200 мс.
(задается в настройках). Как только будет получен ответ на эту команду, она удалится из буфера и сразу будет отправлена следующая команда и т.д.
Если ответ на команду не был получен после 3 попыток она тоже удаляется из буфера и приходит черед след. команды (если она есть).
Таким образом буфер освобождается по принципу ФИФО.
Второй поток (для чтения), постоянно "слушает" порт и запоминает в буфере все что пришло.
Как только последовательность принятых данных (возможно за несколько циклов чтения с порта) будет похожа на комнду KWP2000 (сверяет по заголовку и контрольной сумме),
он передает эту команду основной программе и очишает буфер чтения, для ожидания следующей команды. А основная программа уже исходя из полученных данных просто размещает их
в нужном виде на форме для отображения пользователю!
Таким образом два процесса (чтение\запись) происходят совершенно независимо, и даже не подозревают о сушествовании друг друга )))
#19
Отправлено 05 Апрель 2010 - 08:15
Количество пользователей, читающих эту тему: 0
0 пользователей, 0 гостей, 0 скрытых пользователей















