Благодаря. Утре ще ги пробвам да видя дали ще успея да се вържа като е кракната версията.

Здравейте,

Вчера се сдобих с ново ЕКУ, с което вече би трябвало да мога да комуникирам . ЕКУто е от Ауди Б4 1,9 ТДи 95г. и на практика не би трябвало да има проблем с комуникацията . Това което ми направи впечатление, е че няма нищо общо като куплунг и като схема с предишното такова. Става въпрос за това:

Тук обач не виждам къде са К и L линийте за комуникация??? Предполагам, че тази схема комуникира само по К линия и това е пин 2 (dashboard) на схемата. Ама дали е така???? Ще се радвам ако някой е ползвал тази схема и знае къде е К - линията за комуникация. Захранването е ясно! Поздрави.

Може ли да качиш и сорса за проца?

Не знам къде видя процесор.

и дрги хора са илали подобни идеи:


http://www.fis-box.de/




Ето и още нещо (от БГ) което би могло да ви бъде полезно :




http://forums.hondabg.com/index.php?s=0 ... ode=linear

Пробвах и след като версията е "излекувана", ама нямам достъп до въздушните възглавници. Казва ми, че няма такъв модул, което според мен е нелогично. Може би просто с този софтуер да не става или аз пак бъркам някъде.

Действат хората, не се мотат като мене

След хиляди експерименти, успях да намеря кое краче на ЕКУто е комуникационната К - линия и успях да подкарам комуникацията .
Ето една картинка:
В момента съм се конектнал с компютъра в службата ми и затова картинката е малко странна, но реших да го оставя цяла нощ да работи за да съм сигурен, че комуникацията е стабилна. Удобството, е че ще наблюдавам от вкъщи какво става с ЕКУто. Утре започвам експерименти на ЕКУто вече с моя софтуер, но като начало ще тествам с Proteus, за да видя дали е стабилен софтуера. Еми засега е това от мен. Поздрави!

Здравейте,
Не мога да си обясня, защо става така. Тествам ЕКУто с VAGCOM и комуникация има та се къса (оставих я цяла нощ и не се беше дисконектнала). Порта който ползвам е COM1 със стандартните му настройки на Windows.
Обаче нещата при теста с Proteus стоят по различен начин. Вързах ЕКУто вече не към VAGCOMа, а към мойта програмка в Proteus. Програмката е много проста и имаше за цел само да "събуди" ЕКУто. Порта който ползвам пак е COM1 без да правя каквито и да било други настройки. Еми нестава и нестава. Незнам на какво се дължи това???
Опитах и през адаптор USBtoCOM. Проблемът остана! Интересното, е че когато се опитвах да комуникирам с адаптора моделът на компорта в Протеус ми даваше грешка, т.е мигаше error (дясното квадратче). Никъде не можах да намеря инфо при какви грешки мига и каква е разликата м/у лявото и дясното квадратче. Ако някой го е ползвал нека сподели .
Интересното, е че с този лаптоп с който правех експериментите на ЕКУто на мойта кола всичко си заспива. Там използвам същия адаптор USBtoCOM и няма никакви проблеми. Но въпросът, че защо на реален ком не иска да върви, а в случая и с адаптора? Помислих да не би проблема да е в кома в службата и донесох ЕКУто в къщи. Същата работа. Отново никаква комуникация.
Ако проблема е в схемата на връзване и мойта програмка, тогава защо на Лаптропа върви???
Ето това е част от софтуера и схемата на протеус. С тях на Лаптопа всичко е ОК!
Мисля си да не би проблема да е в настроиките на кома или пък не съм вързал правилно DTS, RTS и т.н. Идеята ми е че аз се опитвам да го събудя с 5 бода, но после дали #use RS232(baud=9600,xmit=PIN_C6,rcv=PIN_C7, FORCE_SW) инициализира правилно DTS, RTS и др. за работа с 9600???
Имате ли някакви идеи??? Нищо друго не ми хрумва
Поздрави!

Защо не пробваш да смениш кварца със 7,3728 МНz или кратен на него за да се получи точна честотата спрямо баудрейда.

Идеята ти не е лоша, но мисля че проблемът не е в това. С 16MHz кварц съм и грешката е 0,16%, а това на практика си е нищо. Тук проблема е че не мога да събудя ЕКУто, т.е. така да се каже не съм стигнал още до 9600 комуникация. Всъщност не знаех, че има такъв кварц. Бих опитал с него. В Протеус направих симулация при 7.3728MHz и пак нищо . Благодая все пак! Други идеи!!!

Ако преместиш този ред:
#use RS232(baud=9600,xmit=PIN_C6,rcv=PIN_C7, FORCE_SW)
след "wake_ECU();" не работи ли?

Опитвал съм и това , виж какво ми дава компилатора:
Не мога да си обясня, защо става така. Инициализирам RSa преди да викна функцията която използва getc() и putc (). Би трябвало да стане, но нестава. Явно където и да го сложа този ред (#use RS232(baud=9600,xmit=PIN_C6,rcv=PIN_C7,FORCE_SW)) компилатора го възприема някак глобално като не се влияе на кой ред е сложено или и аз не знам.
Моля, ако някой е ползвал този ..... КОМ порт да каже как се ползва и инициализира, че работата е страшна Поздрави!

Здрасти,
за мен остана загадка как си успял първия път да направиш връзка proteus <--> ЕКУ.
При мен на ком порта в протеуса се задава твърд бод рейт . освен това не винаги симулацията е в реално време. Аз не успях по никакъв начин да събудя еку чрез симулация. В моите тестове ползвах еку емулатор (http://www.geocities.com/darkyp/eng/ecuemulator.html).
Връзката vagcom --> virtual com port --> еcu emu ставаше без проблем но със proteus във емулатора се показваха грешни lo-baud данни. Съжелявам че малко сложно звучи но при интерес може да инсталираш емулатора и да видиш какво имам предвид.

Колкото до usb-to-RS това което съм чувал е че повечето конвертори конвертират само RX/TX пин-овете и така няма как да направиш 5bps инициализацията (RTS/DTR) Освен това самият usb порт си кешира данните и не винаги пакетите хвърчат в реално време.

Дефолтните настройки на ком порта в windows вкючват входно изходни буфери които също може да попречат на правилната комуникация. Те се забраняват от настройките на драйвера в device manager-a на windows.

Аз реших да си улесня малко живота и разкарам всички емулатори. Сега пиша директно на лаптопа в колата и прехвърлям .hex-а на пик-а през bootloader. За тази операция ползвам usb-rs конвертор и за щастие няма проблем.

Ако имаш осцилоскоп може да го закачиш на к-линията и да провериш дали времената са верни.

Каква версия на протеус ползваш. При мен виртуалния осцилоскоп изглежда по-различо и предполагам съм със по-стар софт. В моята версия има доста бъгове при симулация на I2C и 1-Wire устройства. Доста ядове брах докато разбрах че повредата не е в моя телевизор

Успех в борбата и евала за ентусиазма

--- edit
#use RS232(baud=9600,xmit=PIN_C6,rcv=PIN_C7,FORCE_SW)
Този ред няма значение на кой ред се слага и се изпълнява по време на компилация. Пиновете клатят ли се по време на инициализацията? Иначе ми изглежда логично това което си написал и би трябвало да работи.

Може да пробваш и това което ти бях пратил няколко поста по-назад. Да махнеш FORCE_SW и по време на инит да спреш USART-a чрез регистрите.

При мен честотата на кварца няма значение за симулацията. Честотата я задавам в пропъртитата на PIC-a. Може и да се бъркам защото имам странен проблем че при симулация времето тече малко по-бързо от това на реалната платка


Още една идея. Така както си го направил не е ясно дали еку-то не се събужда или просто не ползва друга честота. Може да сложиш едно две съобщения за грешка ако не получиш sync байта или ако протокол id-то е друго. Имай в предвид че ваг сом пробва няколко честоти преди да установи правилната. Може да погледнеш в настройките му Start Boud на колко е сложено. Не се задълбочавах много в сорса ти но ми се струва че не обработваш ехо-то. При всеки изпратен byte трябва да четеш по един за да си сигурен че не ловиш ехото си. Мисля си че getc() ще продължи да виси ако не получи нищо. Самия факт че стигаш до печатане говори че получаваш отговор (най-вероятно ехото си)

Защо не ползваш различен пин на микроконтролера за 5-те бода който го вържеш като жично или или по някакъв друг начин към Тх-са или софтуерно да включваш и изключваш ком порта за да постигнеш необходимия сигнал за ниския баудрейт.
А да не би да е необходимо от инвертирано подаване на сигнала от микроконтролера

Здравейте,
Съжалявам, за това че се забавих няколко дни с отговора (струпа ми се доста служебна работа) , но пък за това имам малки успехи с комуникацията .


Да, и аз не знам как стана (наистина се задава трърд бод рейт) но наистина успявам да прочета нещо макар и не стабилно. Например чета оборотите на колата, но от 3-4 стойности по веднъж ми дава и верната (861оборота на колата). Стойността сравнявам с VAGCOMa.


Аз също направих така и разкарах Proteus. Проблемът беше (както съм писал в горните постове), че през нормалния КОМ немога да направя връзка Протеус - ЕКУ. Това ме накара да се откажа от Протеуса като симулатор да опитам да комуникирам реално с PIC - EKU. Резулата беше задоволителен в известен смисъл. Този път успях да събудя ЕКУто и на дисплея ми се показа Connection ..... OK!, т.е ЕКУто ми изпрати първите 3 байта 55, 01, 8А. Съответно аз му върнах разликата FF-8A и до там. По нататък комуникация на 9600 не се осъществява. Би трябвало да получа от ЕКУто 0F (дължина на блока), но това не става. Предполагам, че проблемът вече е в тея 9600 бода. Интересното, е че чета следващите байтове и с учудване видях че те са пак нещо от рода 01, 55, 8А, 55, 8А, 01, 8А, 01, 55........ и т.н Изрежда в различна последователност тези байтове. Незнам защо е така. След събуждане първото което трябва да ми изпрати е дължина на блока, брояч, заглавие на блока (block title F6). Възможно ли е това да се получва така, защото не инициализира скоростта на комуникация и защо не инициализира като тази инициализация я правя още в началото #use RS232(baud=9600,PARITY=N,xmit=PIN_C6,rcv=PIN_C7,BITS =8,FORCE_SW)???



Това още не съм го пробвал, но е хитро и ще опитам. Точно в тази инициализация е проблемът май, но ... ще видим!



Обработвам ехото, като след всяко putc(); слагам getc(); задължително (виж сорса който изпратих ).

Здравей, Martin_bg1

Опитах и това но не стана. Сега вече събуждам ЕКУто, но по нагоре съм описал какво става. Вместо да продължи да си "говори" с моя контролер, той ми изпраща подобна поредица 01, 55, 8А, 55, 8А, 01, 8А, 01, 55........ и т.н от байтове. На какво се дължи това според теб?
Хайде Поздрави!